March 2010 - armedbear-devel - mailman3.common-lisp.net

[armedbear-devel] json-rpc?
by Axel Rauschmayer 27 Apr '11

27 Apr '11

I think ABCL would make an excellent Ajax server. As such, it would have to support json-rpc. Any suggestions as to how to make this happen? The first part is obviously the server, where the two choices that I can see are Hunchentoot and a servlet container such as Tomcat. In the latter case, I would expect to use a technique like abcl-web (which seems a little bit complicated, but doable). The second part is the JSON parsing. How would I do that? Via CL-JSON? Via Yason? Via a Java library? Sorry for these newbie questions. I’m just getting started with Common Lisp and ABCL. Thanks, Axel -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/

4 10

[armedbear-devel] is there a good method to read/write java byte arrays?
by David Kirkman 01 Dec '10

01 Dec '10

Does anybody know of a good way to serialize lisp objects into java byte arrays? I've got a method that almost works, but if anybody has a better/canonical way of doing this I'd love to know! I've been trying to use cl-store, outputting to a stream I create with sys::%make-byte-array-output-stream, and then getting the byte array with sys::%get-output-stream-bytes. I've only been using abcl for a few days, and I found those functions by grepping through the sources, so I apologize if I'm inviting trouble by messing around with functions you never meant users to play with. Anyway, the output works fine. But I can't find the equivalent of sys::%make-byte-array-output-stream to create an input stream, so I attempted to make my own (defun make-byte-array-input-stream (bytes) (let ((bis (jnew (jconstructor "java.io.ByteArrayInputStream" "[B") bytes))) (jnew (jconstructor "org.armedbear.lisp.Stream" "java.io.InputStream") bis))) This almost seems to work, but if I try to use it I get a java exception and a (very long) java stack trace. I put a copy of the stack trace at the end of this message. Here is an expression which will produce the problem in abcl-18.1 (let ((outbytes (with-open-stream (stream (sys::%make-byte-array-output-stream)) (write-byte 101 stream) (sys::%get-output-stream-bytes stream)))) ;; now open the byte array as an input stream (with-open-stream (stream (make-byte-array-input-stream outbytes)) ;; all works fine until here (read-byte stream))) I don't need to read the stream, asking for the element type of the input stream is enough to cause trouble ... (let ((outbytes (with-open-stream (stream (sys::%make-byte-array-output-stream)) (write-byte 101 stream) (sys::%get-output-stream-bytes stream)))) (with-open-stream (stream (make-byte-array-input-stream outbytes)) (stream-element-type stream))) I can fix the problem and make my code work, but I have to change Stream.java to make it work. I added elementType = UNSIGNED_BYTE_8; to the initAsBinaryInputStream(InputStream in) method. I did this because the stack trace suggested that the problem was stream_element_type.execute() was returning null. Anyway, that fixes the problem, and I'm happily serializing/deserializing lisp objects to a Berkeley DB ... so I guess I'm happy! But I don't know how rational that fix is, because I don't really know how Stream is supposed to work. I suspect that my 'fix' probably breaks something else that I'm just not using yet. Any ideas? Thanks, -david k. Here's the first few lines of the stack trace ... CL-USER(2): Debugger invoked on condition of type SIMPLE-TYPE-ERROR: java.lang.NullPointerException at org.armedbear.lisp.Primitives$49.execute(Primitives.java:795) at org.armedbear.lisp.Symbol.execute(Symbol.java:781) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.print_8.execute(print.lisp:127) at org.armedbear.lisp.Symbol.execute(Symbol.java:781) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.print_14.execute(print.lisp:279) ... (and it ends with) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.Symbol.execute(Symbol.java:760) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:415) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:546) at org.armedbear.lisp.Interpreter.run(Interpreter.java:310) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:613) READ-BYTE: unsupported element type Debugger invoked on condition of type ERROR: Caught java.lang.NullPointerException. Restarts: 0: TOP-LEVEL Return to top level.

3 14

[armedbear-devel] ABCL introductory user documentation
by Paul Reiners 07 Jun '10

07 Jun '10

Some introductory user documentation I wrote on ABCL if anyone's interested: http://www.automatous-monk.com/jvmlanguages/abcl/Armed_Bear_Common_Lisp.html It's spread across a bunch of slides right now, because I first prepared it as a multi-slide presentation. I think I want to combine it all into one HTML page later this week when I get around to it. At the very least, I want to give each slide a meaningful title so that the Table of Contents is more meaningful. Any criticism, constructive or destructive, is welcome. Paul

5 11

[armedbear-devel] Patches for ABCL against asdf-1.641
by Mark Evenson 01 May '10

01 May '10

Attached are patches in 'abcl-asdf.patch' to get asdf-1.641 to work against ABCL for the run-tests.sh. Unfortunately, you will need to build [ABCL from trunk][1] using at least svn r12550, because I had to patch ABCL to work with ASDF. And you'll need to apply the 'abcl-translate-pathname.patch'. [1]: svn://common-lisp.net/project/armedbear/svn/trunk/abcl Notes: 1. The fugliness of the conditional around ASDF:GET-UID works around a bug in the ABCL compiler. We are in the process of [analyzing the error][2]. [2]: http://trac.common-lisp.net/armedbear/ticket/89 2. There is some undiagnosed problem in translating the binary location for the new ASDF2 "~/.cache" conventions, as ABCL seems to "collapses" everything into a single directory. Somehow, the default *output-translations* have a "/**/**/*.*" where there should be "/**/*.*". I'm not sure if this is a problem in "abcl-translate-pathname.patch", which is why I didn't apply this to ABCL trunk. 3. ASDF's run-tests.sh seems to ignore the "flags" setting, which seems to be broken on the ASDF side. 4. The changes for ASDF look quite interesting. However I would advocate that you should make ASDF2 work *exactly* like ASDF1 out of the box, meaning you shouldn't do any of the subsumed ASDF-BINARY-LOCATIONS stuff without being asked to by configuration. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

6 28

[armedbear-devel] Proposal for URL to be used as Pathnames
by Mark Evenson 02 Apr '10

02 Apr '10

I've [committed to an initial design][1] for URLs to be used as Pathnames, which I am in the process of implementing. The primary use of this functionality will be to be able to eventually express OSGi bundles within ASDF system definitions. [1]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/design/url-pat… The gist of the proposal is to represent a URL with a Pathname whose HOST component is a list. The list will be an association list with the key :SCHEME containing the URL scheme and :AUTHORITY containing the URL authority. The DIRECTORY, NAME, and TYPE components will be used to construct the PATH of the URL. As an example, "http://example.org:8080/org/armedbear/lisp/boot.lisp" would be converted to a Pathname as follows pathname: { host: (:SCHEME "http" :AUTHORITY "example.org:8080"), directory: (:ABSOLUTE "org" "armedbear" "lisp"), name: "boot", type: "lisp" } As an answer to Alessio's question (long ago) about whether URLs should really be a Pathname or if we are better off using a class, I think that they really are better abstracted as a Pathname because they a) have a hierarchical path b) the network location has a strong resemblance to how HOST is used for UNC mounts under Windows and c) being able to express OSGi bundles in ASDF has a chance of working. Critique welcome. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

5 10

Re: [armedbear-devel] [armedbear-cvs] r12577 - branches/metaclass
by Erik Huelsmann 28 Mar '10

28 Mar '10

This commit completes the METACLASS functionality I was planning to provide on trunk/. The only thing which remains is writing regression tests. I don't see any problems to do that with the code on trunk, as the ANSI tests show no new breakage. Since 0.20 is scheduled to be released beginning of may - as per our normal release cycle - please test this functionality as much as possible and report any issues you find. It will help improve the quality of our 0.20 release: this functionality has the potential of destabilizing our code, although I haven't found that to have acctually happened. Thanks in advance, Erik. On Sun, Mar 28, 2010 at 9:20 PM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Sun Mar 28 16:20:09 2010 > New Revision: 12577 > > Log: > Re #38: Delete merged metaclass branch. > > Removed: > branches/metaclass/ > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] SEQUENCE == SlotClass?
by Erik Huelsmann 27 Mar '10

27 Mar '10

Hi Alessio, You implemented the user-extensible sequence protocol. Did you by any chance change the type of Sequence from BUILT-IN-CLASS to SLOT-CLASS? If so, I have a little bit of a negative interaction with my METACLASS changes. Nothing that can't be fixed; I'll probably need to study AMOP for the solution, but I was just wondering. Does crhodes specify the new class of SEQUENCE in his protocol? Should we switch it to STANDARD-CLASS? Bye, Erik.

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.19.1 released
by Erik Huelsmann 27 Mar '10

27 Mar '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.19.1 release. Version 0.19.0 was never released. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. This release features - among lots of other things - a fix for unbinding PROGV bound variables upon exiting the PROGV scope and a much improved integration of access to filenames specified by URLs. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.19.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/abcl-src-0.19.1.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.19.1.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.19.1.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.19.1.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.19.1.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.19.1.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.19.1.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.19.1.zip.asc

1 0

[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

[armedbear-devel] *command-line-argument-list* backwards
by Alan Ruttenberg 15 Mar '10

15 Mar '10

java -cp ~/Desktop/test.jar org.armedbear.lisp.Main --noinit -a -b -c -d 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.364 seconds. Startup completed in 0.893 seconds. lType ":help" for a list of available commands. CL-USER(1): *command-line-argument-list* ("-d" "-c" "-b" "-a")

3 2

Re: [armedbear-devel] [armedbear-ticket] [armedbear] #38: CLOS :metaclass support
by Erik Huelsmann 13 Mar '10

13 Mar '10

The mail below was induced by the "automatic ticket annotator" from Trac. While I installed it many moons ago, I was under the impression it wasn't working. Nothing like that was the case: I just didn't get it enough. See http://trac.edgewall.org/browser/branches/0.11-stable/contrib/trac-post-com… on how you can annotate or close tickets from your commit message. Bye, Erik. On Sat, Mar 13, 2010 at 8:05 PM, armedbear <armedbear-devel(a)common-lisp.net> wrote: > #38: CLOS :metaclass support > -------------------------+-------------------------------------------------- > Reporter: ehuelsmann | Owner: ehuelsmann > Type: defect | Status: accepted > Priority: major | Milestone: 0.20 > Component: other | Version: > Resolution: | Keywords: > -------------------------+-------------------------------------------------- > > Comment(by ehuelsmann): > > (In [12527]) Make all class accessor functions generic functions instead > of normal ones, to support METACLASS. Additionally, make > it possible to store general objects in Layout.lispClass. > Because classes may be of a different Java type than > StandardClass, fall back to the generic functions to access > the required fields from Java. > > See #38. > > -- > Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/38#comment:2> > armedbear <http://common-lisp.net/project/armedbear> > armedbear > _______________________________________________ > armedbear-ticket mailing list > armedbear-ticket(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-ticket >

1 0

[armedbear-devel] Maxima status: Can't compile due to i18n changes
by Erik Huelsmann 13 Mar '10

13 Mar '10

Dear Robert, Maxima developers, >From time to time, I check ABCL's status with Maxima. Today I updated to the latest, but found that I can't compile anymore. The issue is with intl.lisp: the defvar form defining *default-domain* contains an _N reader macro, which expands into multiple symbols on ABCL: This is what I found after expansion: --- fasl content (DEFVAR *DEFAULT-DOMAIN* "maxima" NIL "The message-lookup domain used by INTL:GETTEXT and INTL:NGETTEXT. Use (INTL:TEXTDOMAIN \"whatever\") in each source file to set this.") --- fasl content As you see, there's an additional NIL there. I'm hoping to work out together with you what's going on here, as support for Maxima is one of the important items on the list of ABCL developers. With kind regards, Erik ABCL developer

2 1

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

13 Mar '10

This e-mail was caused by me testing the post-commit hookscript. Sorry. Bye, Erik. On Sat, Mar 13, 2010 at 7:49 PM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Fri Mar 12 17:38:32 2010 > New Revision: 12526 > > Log: > Fix ticket #85: CL-JSON throws an error where SBCL doesn't. > > Modified: > trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp Fri Mar 12 17:38:32 2010 > @@ -1078,9 +1078,9 @@ > ;; (dolist (name (second symbols-form)) > ;; (let ((variable (make-variable :name name :special-p t))) > ;; (push > - (setf (progv-form block) > - `(progv ,symbols-form ,values-form ,@(p1-body body)) > - (progv-environment-register block) t) > + (setf (progv-environment-register block) t > + (progv-form block) > + `(progv ,symbols-form ,values-form ,@(p1-body body))) > block)) > > (defknown rewrite-progv (t) t) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] Error: value is not of type CONS
by Axel Rauschmayer 12 Mar '10

12 Mar '10

CL-JSON throws an error under ABCL where SBCL doesn't. The code is: (require 'asdf) (asdf:operate 'asdf:load-op :cl-json) (json:decode-json-from-string "{\"foo\": [10,20,50], \"bar\": true}") The error message is: The value 50 is not of type CONS. I'm using Yason as a work-around, but thought that you guys might want to know, maybe this points to a deeper issue. Greetings, Axel -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/

2 2

[armedbear-devel] integrating abcl into Protege
by Alan Ruttenberg 12 Mar '10

12 Mar '10

Protege is an ontology development tool. I'm interested in using abcl to develop plugins and TIm Redmond was kind enough to have a stab at doing a first pass integration, but ran into trouble. I wonder if his report makes rings a bell? -Alan ---------- Forwarded message ---------- From: Timothy Redmond <tredmond(a)stanford.edu> Date: Wed, Mar 10, 2010 at 2:12 PM Subject: [POSSIBLE VIRUS:###] Re: further on common lisp integration To: Alan Ruttenberg <alanruttenberg(a)gmail.com> There is something of a difficulty in using this library. It is doing some funky stuff with urls and class loaders and this doesn't work with Protege. Probably could be made to work by making some changes to the abcl sources. In particular it seems to detect that it is loading through the class loader if the prefix begins with jar which is not a correct assumption in general. But here is a start if you want to debug a bit more. -Timothy java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.zip.ZipFile.<init>(ZipFile.java:75) at org.armedbear.lisp.ZipCache.getZip(ZipCache.java:54) at org.armedbear.lisp.Lisp.readFunctionBytes(Lisp.java:1305) at org.armedbear.lisp.AutoloadedFunctionProxy$2.execute(AutoloadedFunctionProxy.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:767) at org.armedbear.lisp.dotimes.execute(dotimes.java:105) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Load.faslLoadStream(Load.java:628) at org.armedbear.lisp.Load.access$100(Load.java:70) at org.armedbear.lisp.Load$1.execute(Load.java:485) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Load$4.execute(Load.java:774) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:158) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:69) at org.sciencecommons.protege.lisp.LispContext.<init>(LispContext.java:14) at org.sciencecommons.protege.lisp.LispContext.getInstance(LispContext.java:20) at org.sciencecommons.protege.lisp.Activator.start(Activator.java:13) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902) at org.protege.editor.core.BundleManager.startPlugins(BundleManager.java:110) at org.protege.editor.core.BundleManager.loadPlugins(BundleManager.java:41) at org.protege.editor.core.ProtegeApplication.loadPlugins(ProtegeApplication.java:277) at org.protege.editor.core.ProtegeApplication.initApplication(ProtegeApplication.java:171) at org.protege.editor.core.ProtegeApplication.start(ProtegeApplication.java:113) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619) java.lang.Error at org.armedbear.lisp.Primitives$70.execute(Primitives.java:1462) at org.armedbear.lisp.Primitive.execute(Primitive.java:108) at org.armedbear.lisp.Symbol.execute(Symbol.java:770) at org.armedbear.lisp.Lisp.error(Lisp.java:354) at org.armedbear.lisp.Lisp.readFunctionBytes(Lisp.java:1329) at org.armedbear.lisp.AutoloadedFunctionProxy$2.execute(AutoloadedFunctionProxy.java:307) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Lisp.processTagBody(Lisp.java:767) at org.armedbear.lisp.dotimes.execute(dotimes.java:105) at org.armedbear.lisp.Lisp.eval(Lisp.java:449) at org.armedbear.lisp.Load.faslLoadStream(Load.java:628) at org.armedbear.lisp.Load.access$100(Load.java:70) at org.armedbear.lisp.Load$1.execute(Load.java:485) at org.armedbear.lisp.LispThread.execute(LispThread.java:579) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Load$4.execute(Load.java:774) at org.armedbear.lisp.LispThread.execute(LispThread.java:562) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:494) at org.armedbear.lisp.Lisp.eval(Lisp.java:459) at org.armedbear.lisp.Load.loadStream(Load.java:593) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:556) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:499) at org.armedbear.lisp.Load.loadSystemFile(Load.java:415) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:158) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:69) at org.sciencecommons.protege.lisp.LispContext.<init>(LispContext.java:14) at org.sciencecommons.protege.lisp.LispContext.getInstance(LispContext.java:20) at org.sciencecommons.protege.lisp.Activator.start(Activator.java:13) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902) at org.protege.editor.core.BundleManager.startPlugins(BundleManager.java:110) at org.protege.editor.core.BundleManager.loadPlugins(BundleManager.java:41) at org.protege.editor.core.ProtegeApplication.loadPlugins(ProtegeApplication.java:277) at org.protege.editor.core.ProtegeApplication.initApplication(ProtegeApplication.java:171) at org.protege.editor.core.ProtegeApplication.start(ProtegeApplication.java:113) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:639) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700) at org.apache.felix.framework.Felix.startBundle(Felix.java:1622) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619)

5 14

[armedbear-devel] class-prototype
by Alan Ruttenberg 10 Mar '10

10 Mar '10

Hi, Thanks for adding class-prototype. Unfortunately I realize that the specification doesn't guarantee the behavior I was looking for, so I though I would solicit advise. Basically I want to be able to access class-allocated slot values before I create any real instances. I thought I could grab the class prototype and do slot value on them, but according to the doc below initialize is not called, which I guess is when class-allocated slots are being set up. Is there a portable way of asking for the values of class slots absent the creation of at least one initialized instance? -Alan http://www.franz.com/support/documentation/8.2/doc/mop/dictionary.html#clas… Generic Function class-prototype class Returns a prototype instance of class. Whether the instance is initialized is not specified. The results are undefined if a portable program modifies the binding of any slot of prototype instance. This generic function signals an error if class has not been finalized.

3 11