armedbear-devel October 2010

armedbear-devel@common-lisp.net

14 participants
18 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] asdf-install strangeness
by Kevin Raison 19 Nov '10

19 Nov '10

I recently started using abcl 0.22.0 but have run into issues installing packages using asdf-install. Here is an example error message. Does anyone know of a solution to this? CL-USER(7): (asdf-install:install 'hunchentoot) Install where? 1) System-wide install: System in /usr/local/asdf-install/site-systems/ Files in /usr/local/asdf-install/site/ 2) Personal installation: System in /home/raison/.asdf-install-dir/systems/ Files in /home/raison/.asdf-install-dir/site/ 0) Abort installation. --> 2 ;;; ASDF-INSTALL: Downloading 139617 bytes from http://weitz.de/files/hunchentoot.tar.gz to /home/raison/asdf-install-0.asdf-install-tmp ... #<THREAD "interpreter" {4DA42824}>: Debugger invoked on condition of type STREAM-ERROR Input value 0xdc4a is malformed while recoding with charset UTF-8 Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(8): 0 CL-USER(9): Thanks! Kevin

3 5

[armedbear-devel] Significant increase in build time
by Blake McBride 16 Nov '10

16 Nov '10

Greetings, I hadn't built ABCL in a little while so I checked out the latest version today and built it. It seemed to be significantly slower than before so I decided to investigate. This is what I found. In the past I could build ABCL in 2:43. It now takes me 4:40. That (IMO) represents a pretty significant change in build time. I did a binary search and discovered that all of the change occurred at revision 12918 - Generic Class File Branch Merge. In general, I could't care less about the build time unless it is indicative of a problem that could rear its head in my application. Where is that time being spent? Is there a change in runtime? Loading? Compiling? I'd be real interested in this. Thanks. Blake McBride

4 10

[armedbear-devel] cl+ssl problem
by Cyrus Harmon 15 Nov '10

15 Nov '10

Dear ABCL Developers, Attempting to asdf:load cl+ssl gives the following error: Loadable FASL not found for '/Users/sly/.cache/common-lisp/armedbear-0.23.0-dev-fasl36-darwin-java-1.6/Users/sly/src/clbuild/source/cl+ssl/package.abcl' in 'jar:file:/Users/sly/.cache/common-lisp/armedbear-0.23.0-dev-fasl36-darwin-java-1.6/Users/sly/src/clbuild/source/cl ssl/package.abcl!/package._' [Condition of type FILE-ERROR] A trivial rename of the .asd file (and the contained system) to, say, clssl, allows ABCL to get past this, so it looks like the + in the file name (or ASDF system name) is causing the problem. Of course the trivial fix doesn't really fix things as there's still a CFFI problem, but that's for another email.... thanks, Cyrus

3 3

[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] BUG: armedbear-devel@common-lisp.net
by Alessandro Serra 22 Oct '10

22 Oct '10

Hi, compiling ltk I have the following error: #<THREAD "interpreter" {FE135D}>: Debugger invoked on condition of type SIMPLE-ERROR s2 argument 34666 out of 16-bit signed range. Debugging a bit, I found that the error is in "compiler-pass2.lisp" in the function "code-bytes" during the pass2 (replace labels with calculated offsets). What can I do to avoid this error? Thanks, Alessandro -- The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use the words. How To Build A Universe That Doesn't Fall Apart Two Days Later Philip K. Dick

2 1

[armedbear-devel] basic support for DEFINE-METHOD-COMBINATION (long form) landed on trunk
by Erik Huelsmann 20 Oct '10

20 Oct '10

Just a minute ago, I committed Mark Evenson's work on DEFINE-METHOD-COMBINATION (long form) [short: D-M-C]. It's a port to ABCL of the D-M-C implementation found in XCL which derives from Sacla. That being the case, I expect the implementation to be little tested. Which can definitely be said of the port. However, some testing with a few self-made tests didn't turn up many problems. However, SBCL has a series of tests for D-M-C. It would be nice if we could port those to ABCL too in an effort to smoke out any issues our D-M-C implementation may have. I smoked out the first one already that way: there was a quote missing is a function which returns a part of a method combination form. Compile times just longer once again - however, there should be no measurable impact for any code which doesn't use the long form of D-M-C itself. Serious request: help smoke out problems! Test! Fix! The sooner we get good confidence in the implementation, the sooner we can release 0.23! Bye, Erik.

2 1

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel October 2010