April 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] 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] 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] progress with abcl in protege
by Alan Ruttenberg 23 May '10

23 May '10

Alessio found some threading issues with his console, and with those fixed I am able to use it within protege and it no longer hangs after one or two commands. (Thanks!) Using the latest abcl, there also seems to be some bundle: url goodness happening. I no longer see the unbound variable issue, and I see bundle: uris for abcl-defined lisp code being loaded - snap attached - I recorded a screen movie and grabbed the last it showed before crashing. I then go and try to load some other code and the whole thing crashes. I'm including the relevant portion of the console log. The last complaint is: 4/15/10 6:24:59 PM [0x0-0x15e15e].Protege41[3978] Unable to autoload JAVA:JCLASS-FIELDS Not sure why other bundle: code would load but not this. -Alan

3 25

[armedbear-devel] expecting to find integer on stack
by Alan Ruttenberg 10 May '10

10 May '10

Fresh svn update. Compiled with Java 1.5 on OSX File attached. laptop:~/repos/abcl % ./abcl --noinit 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.363 seconds. Startup completed in 0.914 seconds. Type ":help" for a list of available commands. CL-USER(1): (compile-file "/Users/alanr/repos/lsw/trunk/owlapi3/patmatch.lisp") ; Compiling /Users/alanr/repos/lsw/trunk/owlapi3/patmatch.lisp ... ; (DEFUN VARIABLE-P ...) ; (DEFUN PAT-MATCH ...) ; in (DEFUN PAT-MATCH ...) ; Caught STYLE-WARNING: ; Undefined variable NO-BINDINGS assumed special ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; Caught STYLE-WARNING: ; Undefined variable *OWL2-VOCABULARY-FORMS* assumed special ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (DEFUN SEGMENT-PATTERN-P ...) ; (DEFUN SINGLE-PATTERN-P ...) ; (DEFUN SEGMENT-MATCHER ...) ; (DEFUN SINGLE-MATCHER ...) ; (DEFUN SEGMENT-MATCH-FN ...) ; (DEFUN SINGLE-MATCH-FN ...) ; (DEFUN MATCH-IS ...) ; in (DEFUN MATCH-IS ...) ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; (DEFUN MATCH-AND ...) ; in (DEFUN MATCH-AND ...) ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; (DEFUN MATCH-OR ...) ; in (DEFUN MATCH-OR ...) ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; (DEFUN MATCH-NOT ...) ; in (DEFUN MATCH-NOT ...) ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; (DEFUN SEGMENT-MATCH ...) ; in (DEFUN SEGMENT-MATCH ...) ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; (DEFUN FIRST-MATCH-POS ...) ; (DEFUN SEGMENT-MATCH+ ...) ; (DEFUN SEGMENT-MATCH? ...) ; (DEFUN SEGMENT-ATOM-MATCH? ...) ; (DEFUN MATCH-OPTIONAL-ATOM ...) ; in (DEFUN MATCH-OPTIONAL-ATOM ...) ; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special ; (DEFUN MATCH-IF ...) ; Compilation unit finished ; Caught 9 STYLE-WARNING conditions ; The following functions were used but not defined: ; MATCH-VARIABLE java.lang.VerifyError: (class: org/armedbear/lisp/patmatch_19, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find integer on stack at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357) at java.lang.Class.getConstructor0(Class.java:2671) at java.lang.Class.newInstance0(Class.java:321) at java.lang.Class.newInstance(Class.java:303) at org.armedbear.lisp.Lisp.makeCompiledFunctionFromClass(Lisp.java:1286) at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1347) at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1340) at org.armedbear.lisp.AutoloadedFunctionProxy.loadPreloadedFunction(AutoloadedFunctionProxy.java:224) at org.armedbear.lisp.CompiledClosure$1.execute(CompiledClosure.java:232) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_7.execute(compile-file.lisp:71) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_5.execute(compile-file.lisp:71) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_10.execute(compile-file.lisp:103) at org.armedbear.lisp.Symbol.execute(Symbol.java:799) at org.armedbear.lisp.LispThread.execute(LispThread.java:602) at org.armedbear.lisp.compile_file_40.execute(compile-file.lisp:486) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_37.execute(compile-file.lisp:486) at org.armedbear.lisp.compiler_pass2_579.execute(compiler-pass2.lisp:8685) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.compiler_pass2_575.execute(compiler-pass2.lisp:8685) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_35.execute(compile-file.lisp:486) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:497) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Lisp.eval(Lisp.java:460) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:328) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:497) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3720) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:479) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:278) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.top_level_50.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.Symbol.execute(Symbol.java:766) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) 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:552) at org.armedbear.lisp.Interpreter.run(Interpreter.java:319) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:613) #<THREAD "interpreter" {1A3492}>: Debugger invoked on condition of type ERROR Caught java.lang.VerifyError: (class: org/armedbear/lisp/patmatch_19, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find integer on stack. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2):

4 10

Re: [armedbear-devel] [armedbear-cvs] r12620 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 07 May '10

07 May '10

Hi Mark, On Fri, Apr 16, 2010 at 3:41 PM, Mark Evenson <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Fri Apr 16 09:41:21 2010 > New Revision: 12620 > > Log: > Use interpreted form in a FASL if compliation fails. Although I think this is a great fallback, it seems to be automatically selected right now. I'm affraid of the negative side effects of that scenario: people will not notice that their code wasn't compiled, but is now interpreted instead. The ultimate side effect could be that we don't get any reports anymore regarding brokenness of our compiler. In my eyes, there are 2 ways forward with this: 1) We undo this option; this leaves users at a loss when compilation fails; they'll need to use the entire file uncompiled. 2) We make the fallback a selectable restart; this way, compilation gets interrupted, the user is aware and we're much more likely to receive our feedback. But the user isn't restricted to using a fully interpreted file anymore. Quite possibly, you can read my preference through the lines already: I think option (2) is *really* nice. What's your opinion on the matter? Bye, Erik.

3 4

[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] Running "ant test.abcl": Pathname error
by Erik Huelsmann 01 May '10

01 May '10

Hi Mark, Today I tried to run ABCL's tests on Windows. I seem to have an issue, either with the new ASDF stuff, or with the new Pathname stuff. I'm not sure which, but hopefully you do. This is the output I get from "ant test.abcl" on Windows: [java] Error while trying to load definition for system abcl from pathname C:\Users\Erik\Documents\abcl-j\abcl.asd: Pathname has no namestring: #P(:DEVICE "C" :DIRECTORY (:ABSOLUTE "Users" "Erik" "Documents" "abcl-j") :NAME "abcl-test-lisp" :TYPE "asd.lnk" :VERSION :NEWEST) [java] Java Result: 2 [echo] Finished recording test output in abcl-test-20101530-1515.log. While I'm not asking you to fix it, could you indicate where I should start looking? Thanks in advance! Bye, Erik.

3 5

[armedbear-devel] debug stack overflow? (to track down regression)
by Alan Ruttenberg 01 May '10

01 May '10

Hi, This (a call in my LSW system) used to work for me and is now failing in trunk. However I don't seem to have anything to go on in the stack trace. Any suggestions? Thanks, Alan CL-USER(2): (load-ontology "~/repos/obi/ontology/obi.owl") #<THREAD "interpreter" {FE90EF}>: Debugger invoked on condition of type STORAGE-CONDITION Stack overflow. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): :bt 0: (SYSTEM:BACKTRACE) 1: (APPLY #<FUNCTION SYSTEM:BACKTRACE {55C752}> NIL) 2: (SYSTEM:BACKTRACE) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {1985DA}>) 4: org.armedbear.lisp.Lisp$1.execute(Lisp.java:288) 5: org.armedbear.lisp.Symbol.execute(Symbol.java:776) 6: org.armedbear.lisp.top_level_50.execute(top-level.lisp:407) 7: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92)

4 8