armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[armedbear-devel] Losing type information after storing in java.util.ArrayList
by David Kirkman 24 Mar '10

24 Mar '10

I've got a subtle problem: if I create a byte array, store it in a java.util.ArrayList, and then retrieve the stored byte array, what I get back is not quite the same type as the original byte array. I think that everything is the same, except that the JavaObjects have different values for the intendedClass field. Here is an example: (setq array1 (jnew-array "byte" 1)) (setq array2 (let ((array-list (jnew (jconstructor "java.util.ArrayList")))) ;; put the byte array into the ArrayList (jcall (jmethod "java.util.AbstractList" "add" "java.lang.Object") array-list array1) ;; and pull it back out (jcall (jmethod "java.util.AbstractList" "get" "int") array-list 0))) (describe array1) ;#<jarray [B@c4ff22 {4A44DD}> is an object of type JAVA-OBJECT. ;The wrapped Java object is an array of bytes with 1 element.; No value (describe array2) ;#<jarray [B@c4ff22 {5E6B62}> is an object of type JAVA-OBJECT. ;The wrapped Java object is an array of bytes with 1 element.; No value At this point array1 and array2 look pretty compatible, but ... (sys::%make-byte-array-input-stream array1) ; works fine, gives a #S(SYSTEM::SYSTEM-STREAM) (sys::%make-byte-array-input-stream array2) ; gives a TYPE-ERROR, with message "java.lang.Object is not assignable to [B" The TYPE-ERROR comes from JavaObject.javaInstance(Class<?> c) (line 248 of JavaObject.java). It seems that array1 has intendedClass="[B", and array2 has intendedClass="java.lang.Object", so I'm pretty sure that's my problem. Is there a way to specify the intendedClass of array2? Thanks, -david k.

4 6

Re: [armedbear-devel] long
by Alan Ruttenberg 23 Mar '10

23 Mar '10

On Mar 16, 2010, at 8:47 AM, dmiles(a)users.sourceforge.net wrote: > This is because ABCL: > Fixnum => int > Bignum => BigInteger > > ABCL does not have a 'long' type so it is normal workaround to produce > a new 'long in your case. > > So depends who is desiring: There is no real spec other than Allegro > http://www.franz.com/support/documentation/8.0/doc/jlinker.htm#data=types-c… > But Allegro spec here is lossy.. > (meaning if you went from a Lisp Bignum->Java->Lisp.. the number would > scaled back to Long.MAX_VALUE) So their spec is even more > undesirable. Agreed. > It would be possible that when the Bignum is within normal java long > range the javaInstance() could return a java.lang.Long instead. > > Does everyone think this would be better behavior than current ABCL and Allegro? I'm thinking it would be. However, given that there is a workaround I wouldn't put it as high priority - more as a cleanup. -Alan > > > On Mon, Mar 15, 2010 at 11:47 PM, Alan Ruttenberg > <alanruttenberg(a)gmail.com> wrote: >> >> Am I right to observe that abcl coerces any number > fixnum size to bigint? >> I'm having trouble calling a java method that takes a long. I seem to >> have worked around it calling the method with (new 'long >> "9223372036854775807") rather than 9223372036854775807 . >> >> Is this the desired behavior? >> >> -Alan >> >> _______________________________________________ >> armedbear-devel mailing list >> armedbear-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

3 5

[armedbear-devel] Fwd: [Openmcl-devel] [2nd CfP] 7th European Lisp Workshop at ECOOP'10, June 21/22
by Erik Huelsmann 18 Mar '10

18 Mar '10

FYI. ---------- Forwarded message ---------- From: Didier Verna <didier(a)lrde.epita.fr> Date: Wed, Mar 17, 2010 at 2:25 PM Subject: [Openmcl-devel] [2nd CfP] 7th European Lisp Workshop at ECOOP'10, June 21/22 To: Open MCL Development <openmcl-devel(a)clozure.com> +------------------------------------------------------------+ | 2ND CALL FOR PAPERS | | 7th European Lisp Workshop | | June 21/22, Maribor, Slovenia - co-located with ECOOP 2010 | +------------------------------------------------------------+ News ==== Our invited speaker, Manuel Serrano, will talk about "diffuse programming" and HOP. The abstract of his presentation can be found on the website at: http://european-lisp-workshop.org/upcoming/programme.php Important Dates =============== Submission deadline: April 19, 2010 Notification of acceptance: May 05, 2010 ECOOP early registration deadline: May 10, 2010 7th European Lisp Workshop: June 21 or 22, 2010 (tbdl) Please note that registration must be done with ECOOP itself. For more information visit http://www.european-lisp-workshop.org Contact: Didier Verna, didier(a)lrde.epita.fr Invited Speaker =============== Manuel Serrano (INRIA, France) http://www-sop.inria.fr/members/Manuel.Serrano/ Overview ======== "...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bio-informatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." -- Kent Pitman Lisp, one of the eldest computer languages still in use today, is gaining momentum again. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch, making it the ideal candidate for writing Domain Specific Languages. Common Lisp, with the Common Lisp Object System (CLOS), was the first object-oriented programming language to receive an ANSI standard and remains the most complete and advanced object system of any programming language, while influencing many other object-oriented programming languages that followed. This workshop will address the near-future role of Lisp-based languages in research, industry and education. We solicit contributions that discuss the opportunities Lisp provides to capture and enhance the possibilities in software engineering. We want to promote lively discussion between researchers proposing new approaches and practitioners reporting on their experience with the strengths and limitations of current Lisp technologies. The workshop will have two components: there will be formal talks, and interactive turorial/demo/coding sessions. Papers ====== Formal presentations in the workshop should take between 20 minutes and half an hour; additional time will be given for questions and answers. Suggested topics include (but are not limited to): - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Protocol meta-programming and libraries - New language features and abstractions - Software evolution - Development aids - Persistent systems - Dynamic optimization - Implementation techniques - Hardware Support - Efficiency, distribution and parallel programming - Educational approaches and perspectives - Experience reports and case studies Interactive Tutorial/Demo/Coding Sessions ========================================= Additionally, we invite less formal talks in the form of interactive tutorial/demo/coding sessions. The purpose of these sessions is both to demonstrate and receive feedback on any interesting Lisp system, either stable or under development. Being less formal than technical paper presentations, these sessions are expected to be highly interactive. Submission Guidelines ===================== Potential contributors are encouraged to submit: - a long paper (around 10 pages) presenting scientific and/or empirical results about Lisp-based uses or new approaches for software engineering purposes, - a short essay (5 pages) defending a position about where research, practice or education based on Lisp should be heading in the near future, - a proposal for an interactive tutorial/demo/coding session (1-2 pages) describing the involved library or application, and the subject of the session. Papers (both long and short) should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms (see below). Authors will later be required to sign an ACM copyright form, as the workshop proceedings will be published in the ACM Digital Library. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates http://www.acm.org/about/class/1998 Submissions should be uploaded to Easy Chair, at the following address: http://www.easychair.org/conferences/?conf=elw2010 Organizers ========== Didier Verna, EPITA Research and Development Laboratory, Paris Charlotte Herzeel, Programming Technology Lab, Vrije Universiteit, Brussel Robert Strandh, LaBRI, University of Bordeaux 1, France Christophe Rhodes, Goldsmiths College, University of London -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com _______________________________________________ Openmcl-devel mailing list Openmcl-devel(a)clozure.com http://clozure.com/mailman/listinfo/openmcl-devel

1 0

[armedbear-devel] 0.19 release status
by Mark Evenson 17 Mar '10

17 Mar '10

Some quick notes on status of 0.19 for release where I see things. 1. [r12550][1] should probably be backported if anything. [1]: http://trac.common-lisp.net/armedbear/changeset/12550 2. [r12549][2] is probably mostly just cosmetic, but brings up questions of how well the Pathname use of :UNSPECIFIC should be. [2]: http://trac.common-lisp.net/armedbear/changeset/12549 3. I'm still unhappy about the state of the Pathname support, but its a goal that should be postponed until 0.20, as the current implementation is no worse that what shipped in 0.18.1. Most notably, I think I really need to a) support URLs as Pathnames and b) allow all Pathnames to be arguments of OPEN which probably means subclassing Stream.java. And this is a whole lot of work, so postpone. 4. Disturbingly, I uncovered a [compiler stack inconsistency error][3] today in working on ASDF. I checked that this was *NOT* induced by the recent PROGV fix, and exists at least as far back at 0.18.1. So, it should not affect the decision to release unless we feel we should fix it before release. [3]: http://trac.common-lisp.net/armedbear/ticket/89 So, if we're in a "lets get this thing out the door", just release what's on 0.19 (after updating the README). If you want to backport [r12550], I think it should not affect any of the existing test results, but they should be re-run just to make sure. I probably won't have such time until tomorrow (Wednesday). -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 1

Re: [armedbear-devel] [asdf-devel] ABCL trunk r12551 works with asdf-1.643
by Faré 17 Mar '10

17 Mar '10

> Attached is a (trivial) patch so that 'run-tests.sh' actually uses the flags > argument. Thanks. It was applied, and many small bugs were fixed in ASDF 1.647 as I did more testing and improved the test infrastructure. > ABCL now passes the ASDF test suite: > > -#--------------------------------------- > Using abcl --noinit > Ran 21 tests: > 21 passing and 0 failing > all tests apparently successful > -#--------------------------------------- > Yay! > After discussion on IRC and further thought, I no longer advocate that ASDF2 > not make the relocating the FASLs the default. There are certainly decent > arguments for it, and we do want progress in ASDF2, right? Instead, I would > advise that you make a section in the (really excellent looking) manual that > explicates the changes that an ASDF1 user—both with and without using > ASDF-BINARY-LOCATIONS—should expect in ASDF2. And I would include the > *LOAD-TRUENAME*/*LOAD-PATHNAME* issue (i.e. use a conditionalized > ASDF:SYSTEM-DEFINITION-PATHNAME invocation) in that section. > Yes. We need a FAQ section for migration from ASDF1 to ASDF2, with questions each in its own subsection, and a rationale for each change. Sigh. > Otherwise, ASDF2 looks quite cool. What's your timeframe for an official > release? I'd include it as-is in ABCL, but don't want to chase all the > release candidates to ASDF2. > Hopefully we'd like to release ASDF2 before summer. I suggest that at some point (e.g. now) you pick one of the release candidates that you consider not too broken after testing, then upgrade to the real ASDF2 release when it's out, and otherwise only upgrade when there's a good reason to (i.e. fixing major brokenness, or adding major feature, or there's been a stable version for 6 months that you haven't upgraded to yet). Thanks a lot for your support! And don't forget to implement the long DEFINE-METHOD-COMBINATION :) [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] What a lot of trouble to prove in political economy that two and two make four; and if you succeed in doing so, people cry, 'It is so clear that it is boring.' Then they vote as if you had never proved anything at all. — Frederic Bastiat, "What Is Seen and What is Not Seen", 1850

1 0

[armedbear-devel] pathname-directory
by Alan Ruttenberg 16 Mar '10

16 Mar '10

CL-USER(1): (PATHNAME-DIRECTORY #P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.abcl") -> (:RELATIVE "lsw" "jss") I think that's wrong. Should be :absolute, right? -Alan

4 21

[armedbear-devel] ABCL and ASDF 1.636
by Faré 16 Mar '10

16 Mar '10

In ASDF 1.636, I removed the dreaded DEFINE-METHOD-COMBINATION that has made ASDF hard to port to ABCL. Can someone in the ABCL team check whether the latest ABCL works with ASDF? Can you contribute a patch to run-tests.sh so it will run with ABCL? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Nothing is particularly hard if you divide it into small jobs. — Henry Ford

2 1

[armedbear-devel] long
by Alan Ruttenberg 16 Mar '10

16 Mar '10

Am I right to observe that abcl coerces any number > fixnum size to bigint? I'm having trouble calling a java method that takes a long. I seem to have worked around it calling the method with (new 'long "9223372036854775807") rather than 9223372036854775807 . Is this the desired behavior? -Alan

1 0

Re: [armedbear-devel] [armedbear-cvs] r12546 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 15 Mar '10

15 Mar '10

Now that we need to do 0.19.1 anyway, this looks like a nice candidate for inclusion. Bye, Erik. On Mon, Mar 15, 2010 at 5:09 PM, Mark Evenson <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Mon Mar 15 12:09:42 2010 > New Revision: 12546 > > Log: > nreverse() *command-line-arguments-list* to natural order. > > Found by Alan Ruttenburg. > > > Modified: > trunk/abcl/src/org/armedbear/lisp/Interpreter.java > > Modified: trunk/abcl/src/org/armedbear/lisp/Interpreter.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/Interpreter.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/Interpreter.java Mon Mar 15 12:09:42 2010 > @@ -247,6 +247,7 @@ > } > } > } > + arglist.nreverse(); > > _COMMAND_LINE_ARGUMENT_LIST_.setSymbolValue(arglist); > } > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

2 1

[armedbear-devel] startup message
by Alan Ruttenberg 15 Mar '10

15 Mar '10

Is there a way to suppress the startup banner: Armed Bear Common Lisp 0.20.0-dev Java 1.5.0_19 Apple Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.374 seconds. Startup completed in 0.912 seconds. ? Thanks, Alan

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel