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