September 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] [PATCH] Eliminate duplicate lookups in JHandler
by Mario Lang 09 Nov '10

09 Nov '10

Hi. A simple thing, but I spotted it during reading of the code. Index: src/org/armedbear/lisp/JHandler.java =================================================================== --- src/org/armedbear/lisp/JHandler.java (revision 12738) +++ src/org/armedbear/lisp/JHandler.java (working copy) @@ -66,21 +66,22 @@ public static void callLisp (String s, Object o, String as[], int ai[]) { if (table.containsKey(o)) { - Map<String,Entry> entryTable = (Map<String,Entry>)table.get(o); + Map<String,Entry> entryTable = (Map<String,Entry>)table.get(o); if (entryTable.containsKey(s)) { - Function f = ((Entry)entryTable.get(s)).getHandler(); - LispObject data = ((Entry)entryTable.get(s)).getData(); - Fixnum count = ((Entry)entryTable.get(s)).getCount(); - Fixnum[] lispAi = new Fixnum[ai.length]; + final Entry entry = entryTable.get(s); + final Function f = entry.getHandler(); + final LispObject data = entry.getData(); + final Fixnum count = entry.getCount(); + final Fixnum[] lispAi = new Fixnum[ai.length]; for (int i = 0; i < ai.length; i++) { lispAi[i] = Fixnum.getInstance(ai[i]); } - LispObject lispAiVector = new SimpleVector(lispAi); - SimpleString[] lispAs = new SimpleString[as.length]; + final LispObject lispAiVector = new SimpleVector(lispAi); + final SimpleString[] lispAs = new SimpleString[as.length]; for (int i = 0; i < as.length; i++) { lispAs[i] = new SimpleString(as[i]); } - LispObject lispAsVector = new SimpleVector(lispAs); + final LispObject lispAsVector = new SimpleVector(lispAs); LispObject[] args = new LispObject[] //FIXME: count -> seq_num { data, new JavaObject(o), lispAiVector, lispAsVector, internKeyword(s), count }; f.execute(args); -- CYa, ⡍⠁⠗⠊⠕

2 1

[armedbear-devel] ASDF and ABCL
by Faré 31 Oct '10

31 Oct '10

Dear ABCL developers, the one big thing missing in ABCL to fully pass the ASDF test suite is support for (directory "/usr/share/common-lisp/source/**/*.asd") Could you get it to work and update to the latest stable ASDF? That would be great! [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The trouble with opportunity is that it always comes disguised as hard work. — Herbert V. Prochnow

3 12

[armedbear-devel] failure to compile big files
by Carlos Ungil 19 Oct '10

19 Oct '10

Dear ABCL developers, trying to "compile-file" the following fragment of code using the latest release results in an error "s2 argument 32778 out of 16-bit signed range." ----------------------------------------------------- (defmacro many-functions (n) (append '(progn) (loop for i from 1 to n collect `(defun ,(intern (format nil "TEST~A" i)) () (print ,i))))) (many-functions 1525) ----------------------------------------------------- There are no problems with 0.20 (even for much bigger values of the parameter, i.e. bigger output files). I encountered the problem with a file containing several calls to the macro def-java-class in Jfli. It took me some time to discover that splitting the file in two was enough to make the problem go away... This is not a critical bug (it's usually easy to reorganize the code to ensure the files are small enough), but you might want to look at it. Cheers, Carlos

3 4

[armedbear-devel] Patch: top-level::repl keyword evaluation and command case-ignore.
by mahmud 16 Oct '10

16 Oct '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This patch fixes these two issues in ABCL 0.22.0: 1) Keyword evaluation in the repl is broken. The repl assumes all keywords are, in fact, repl commands. 2) Repl commands are case sensitive: :help :HELP mean two different things. The patch also contains tests. Regards. - - mahmud -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMoPZ2AAoJEHC3KbywAoue0/4H/0jjeUEP6wsARhBKEIZLYWGc E3UV+XaPyz38R+IjpJFR1ne2w+ernfjJ+XJXslHwerUjet02tOrNDW10QzyvvJJP UcBNOJwtLn/m8sCbcDhE8+Y/SFergnx6HP9wqPE5N3u2MEoaWqoW/CrufcCxfo2E 0r8RkTOSssQi8jJP6n+mdcVpEuLhPbtL3oxThRKBwfpUaRdxdqn5muDkiO6j8TKZ hjldBHU02vPKWyOPNAsJN6tN1mcChCvc3/TwOPTCngEAY3wNOswQxrOkB/VQX+Wc cQgBsFj5b11FzrpKjmUe5lCQwvba1K2H2hkYqHvdPu2nobOrkDpx7wiI6nbh9So= =U43j -----END PGP SIGNATURE-----

2 3

[armedbear-devel] CLOS thread safety
by Erik Huelsmann 03 Oct '10

03 Oct '10

Hi David, > Are there any known thread safety issues with CLOS? I've been > getting some weird MOP errors that I made go away by redefining > slot-value such that it has to acquire a global lock before it can do > anything. I assume that the problem is in my code: but the threads > that are executing when I get the failures share no code (or > variables), and every time the errors pop up slot-value is on the > callstack someplace. Well, there have not been any specific threading issues mentioned. Over two years ago, back when I started doing ABCL, there were threading issues which looked like threading issues in CLOS. They turned out to be threading issues in the compiler though. Having said that, I see there have not been taken synchronization measures on a high level: there are no locks and threads:synchronized-on blocks in clos.lisp. There are some synchronized calls on the Java side; I'm not sure the low-level protection is good enough to maintain consistency though. Can you share some examples which show the issues here? Adding thread-safety to clos.lisp - in specific, targeted places - should be well doable. Bye, Erik.

5 15

[armedbear-devel] What is the consensus on JFLI and JSS?
by mahmud 27 Sep '10

27 Sep '10

Hi there, First, a big thank you and congratulation on a job well done, everyone! Secondly. What is the community take on jfli[1] and jss[1]? I like them both, and I plan to use them heavily to Lispify a few Java libraries. However, the two are incompatible, they both have features I would like to see merged. Have there been any attempts at wrapping the native FFI with something higher level? I am interested in something that does the following: 1) Automatic importing of java packages and making them into Lisp packages. 2) Succinct, case-indifferent syntax. I would like to extend either of them to do: 3) Subclassing of java classes in Lisp. 4) Ability to implement java interfaces in Lisp classes. I have a few more ideas, most of which are feasible, but would like to get the community's input on FFI wrappers before I head off in a solitary direction. Regards. - mahmud

3 2

[armedbear-devel] [ANNOUNCE] ABCL 0.22.0
by Erik Huelsmann 26 Sep '10

26 Sep '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.20.0 release. 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. The release is a small maintenance release: most efforts were focussed on work happening on branches some of which has already been merged to trunk for 0.23. The release notes can be viewed at http://common-lisp.net/project/armedbear/release-notes-0.22.shtml. and the list of changes at http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES. Latest and older binary and source distributions can be downloaded from http://common-lisp.net/project/armedbear/releases/

1 1

Re: [armedbear-devel] [armedbear-cvs] r12918 - in trunk/abcl: . src/org/armedbear/lisp test/lisp/abcl test/lisp/ansi
by Erik Huelsmann 25 Sep '10

25 Sep '10

Hi Alessio, Thanks! Great to see the branch on trunk now! Bye, Erik. On Sat, Sep 25, 2010 at 12:35 AM, Alessio Stalla <astalla(a)common-lisp.net>wrote: > Author: astalla > Date: Fri Sep 24 18:35:02 2010 > New Revision: 12918 > > Log: > generic-class-file branch merged. > > > Added: > trunk/abcl/src/org/armedbear/lisp/jvm-class-file.lisp > - copied unchanged from r12917, > /branches/generic-class-file/abcl/src/org/armedbear/lisp/jvm-class-file.lisp > trunk/abcl/src/org/armedbear/lisp/jvm-instructions.lisp > - copied unchanged from r12917, > /branches/generic-class-file/abcl/src/org/armedbear/lisp/jvm-instructions.lisp > trunk/abcl/test/lisp/abcl/class-file.lisp > - copied unchanged from r12917, > /branches/generic-class-file/abcl/test/lisp/abcl/class-file.lisp > Removed: > trunk/abcl/src/org/armedbear/lisp/opcodes.lisp > Modified: > trunk/abcl/abcl.asd > trunk/abcl/src/org/armedbear/lisp/compile-file.lisp > trunk/abcl/src/org/armedbear/lisp/compile-system.lisp > trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > trunk/abcl/src/org/armedbear/lisp/jvm.lisp > trunk/abcl/src/org/armedbear/lisp/known-symbols.lisp > trunk/abcl/test/lisp/ansi/parse-ansi-errors.lisp > >

1 0