armedbear-devel June 2010

armedbear-devel@common-lisp.net

12 participants
25 discussions

[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] 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] r12666 breaks ASDF compilation on Linux
by Alessio Stalla 17 Jul '10

17 Jul '10

I just tried abcl 0.20 with Snow, and compilation (done with asdf:compile-op) fails early with: Compilation failed: Not an absolute pathname #P"\\___jar___file___root___\\**\\*.*" r11664 works fine. Sorry that I didn't check before the release, I remembered checking it not much time ago but evidently I was wrong (r12666 is two weeks old). Alessio

5 24

[armedbear-devel] FLET incorrectly optimized away
by William Wadsworth 28 Jun '10

28 Jun '10

Hi, It appears that the compiler mistakenly optimizes out local functions in, say, definer macros. Below is a transcript of a sample session that clarifies the problem: CL-USER(1): (defmacro define-fn (name &body body) `(defun ,name () (flet ((%one () 1)) ,@body))) DEFINE-FN CL-USER(2): (defmacro do-add1 () `(%one)) DO-ADD1 CL-USER(3): (define-fn fn1 (do-add1)) ; Note: deleting unused local function FLET %ONE FN1 CL-USER(4): (fn1) #<THREAD "interpreter" {6DDDCF}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function %ONE is undefined. Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to %ONE. 3: TOP-LEVEL Return to top level. [1] CL-USER(5): :res Thanks. Martin.

2 2

[armedbear-devel] FLET incorrectly optimized away
by William Wadsworth 26 Jun '10

26 Jun '10

Hi, (It seems that the original message has disappeared, so I repost it.) The attached transcript demonstrates the problem. (I can't seem to be able to put the contents of the REPL transcript inline without the message being labelled as SPAM). Regards, Martin.

1 0

[armedbear-devel] FLET incorrectly optimized away
by William Wadsworth 26 Jun '10

26 Jun '10

I forgot to indicate that this happens on the current [as of 26/6/2010] trunk version). I can also confirm that MACROLET and SLOT-VALUE are now working as expected. Thanks Erik and Alessio for your efforts. Martin.

1 0

[armedbear-devel] strange asdf behavior with 0.20.0
by Kevin Raison 25 Jun '10

25 Jun '10

I just installed 0.20.0 and am now unable to load usocket, yet I can still load cl-ppcre and other Edi-ware. Upon rolling back to 0.19.1, the same usocket package compiles and loads just fine. I have tried using the binary distribution of 0.20.0 as well as building my own, with the same result. There does not seem to be anything wrong with the usocket package definition itself. Has anyone else seen this or know what is going on? Here is the output of 0.20.0: raison@mercury:~/.abcl/lib$ abcl Armed Bear Common Lisp 0.20.0 Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.614 seconds. Startup completed in 1.739 seconds. Type ":help" for a list of available commands. CL-USER(1): (asdf:oos 'asdf:load-op 'usocket) ; loading system definition from /home/raison/.abcl/systems/usocket.asd into #<PACKAGE "ASDF0"> Error loading /home/raison/.abcl/site/usocket-svn/usocket.asd at line 38 (offset 1255) #<THREAD "interpreter" {373E38}>: Debugger invoked on condition of type LOAD-SYSTEM-DEFINITION-ERROR Error while trying to load definition for system usocket from pathname /home/raison/.abcl/systems/usocket.asd: Unrecognized keyword argument :NAME Restarts: 0: TOP-LEVEL Return to top level. [1] USOCKET-SYSTEM(2): -Kevin

4 4

[armedbear-devel] ASDF 2.003
by Faré 25 Jun '10

25 Jun '10

Can ABCL upgrade its ASDF to 2.003 or whichever is latest in the release branch (if possible NOT the master branch)? That would be great. It should fix several bugs that may have hit ABCL users since then. Xach at least reported that upgrading ASDF on ABCL made his software work. As usual, please test on your specific implementation with a few systems before you commit, and please report any bug. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] One good Husband is worth two good Wives; for the scarcer things are, the more they're valued. — Benjamin Franklin

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel June 2010