November 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] :case :common
by pjb＠informatimago.com 27 Feb '11

27 Feb '11

CLHS says: 19.2.2.1.2.2 Common Case in Pathname Components For the functions in Figure 19-2, a value of :common for the :case argument that these functions should receive and yield strings in component values according to the following conventions: * All uppercase means to use a file system's customary case. * All lowercase means to use the opposite of the customary case. * Mixed case represents itself. Note that these conventions have been chosen in such a way that translation from :local to :common and back to :local is information-preserving. [pjb@kuiper :0.0 lisp]$ abcl Armed Bear Common Lisp 0.20.0 Java 1.6.0_22 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.265 seconds. Startup completed in 0.718 seconds. Type ":help" for a list of available commands. CL-USER(1): (make-pathname :name "TEST" :type "LISP" :case :common) #P"TEST.LISP" CL-USER(2): (namestring (make-pathname :name "TEST" :type "LISP" :case :common)) "TEST.LISP" I'm on a linux system on a ext3 file system. The customary case is lower case (case significant on this particular file system, but 99.999% of the files on unix are lower case). Therefore I would expect to get #P"test.lisp" Notice that: (make-pathname :name "test" :type "lisp" :case :common) should produce #P"TEST.LISP" and that: (make-pathname :name "Test" :type "Lisp" :case :common) should produce #P"Test.Lisp" And that I understand "yeld strings in component values" to mean that the processing should be done on each parameter independently. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

3 4

[armedbear-devel] Environment not found
by Gabriel Dos Reis 11 Dec '10

11 Dec '10

Hi, I was looking for documentation of the standard options that the `abcl' driver accepts -- but could not find one. The FAQ page http://common-lisp.net/project/armedbear/faq.shtml suggests as first option `Our wiki'. Clicking on the link http://trac.common-lisp.net/project/wiki displays the message as indicated in the $SUBJECT. I take that to indicate that ABCL (website) is relying on a dangling reference... That being reported, where is the documentation of the options accepted by the `abcl' driver? Thanks, -- Gaby

3 8

[armedbear-devel] ASDF 2.011
by Faré 03 Dec '10

03 Dec '10

Dear Lispers, I'm pleased to announce the release of ASDF 2.011. As compared to ASDF 2.010, it only sports a series of minor changes, which I think is sign of ASDF 2 becoming mature: * minor portability tweaks, to make GCL (2.010.1) and Allegro (2.010.5) happy * minor fixes, to an error in error (2.010.8) * minor API cleanups, exporting symbol operation-description (2.010.6) and accepting keywords as component class names (2.010.3) * minor internal refactoring (2.010.4, 2.010.7 + 2.010.9) * minor improvement in dealing with incompatibility, refusing to run if asdf-binary-locations was loaded as it only works with asdf 1, with useful error message (2.010.7) * minor improvements in compatibility with cl-launch (2.010.2) and xcvb (2.010.4) If you missed it, 2.010 had a notable speedup in addition to minor fixes. It would be very nice of vendors to update the version of ASDF they ship with their respective implementations, or to start shipping it when they don't do it yet (LispWorks, SCL; Corman, GCL - if they are still being developed). PS: I think we should create an asdf-announce mailing-list so that vendors may subscribe to it and only get traffic relevant to releases. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Every technique is first developed, then used, important, obsolete, normalized, and finally understood.

2 1

[armedbear-devel] CFFI support for the previous example
by Cyrus Harmon 01 Dec '10

01 Dec '10

I neglected to mention that the previous example requires some changes to CFFI to get things to compile in the first place. The attached patch is my attempt at bringing the ABCL CFFI code forward to support the :calling-convention -> :convention that must have been made a while back. Cyrus

2 3

[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] creating a socket with :element-type 'octet fails on ABCL
by Cyrus Harmon 30 Nov '10

30 Nov '10

I've been trying to get drakma (and cl+ssl and CFFI, etc...) working on ABCL. Now I manage to get most of the way there, but I run into an error down in usocket:socket-connect (well, get-socket-stream really): :ELEMENT-TYPE must be CHARACTER or (UNSIGNED-BYTE 8). [Condition of type SIMPLE-TYPE-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {181CA265}> #<SIMPLE-TYPE-ERROR {644BFFE5}> #<FUNCTION {181CA265}>) 1: (APPLY #<FUNCTION {181CA265}> (#<SIMPLE-TYPE-ERROR {644BFFE5}> #<FUNCTION {181CA265}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<SIMPLE-TYPE-ERROR {644BFFE5}> #<FUNCTION {181CA265}>) 3: (INVOKE-DEBUGGER #<SIMPLE-TYPE-ERROR {644BFFE5}>) 4: (ERROR SIMPLE-TYPE-ERROR :FORMAT-CONTROL ":ELEMENT-TYPE must be CHARACTER or (UNSIGNED-BYTE 8).") 5: (GET-SOCKET-STREAM #<sun.nio.ch.SocketAdaptor Socket[addr=github.com/207.97.22... {2CD5B121}> :ELEMENT-TYPE FLEXI-STREAMS:OCTET) 6: (USOCKET:SOCKET-CONNECT "github.com" 443 :ELEMENT-TYPE FLEXI-STREAMS:OCTET :NODELAY ...) 7: (DRAKMA:HTTP-REQUEST "https://github.com/slyrus") 8: (SYSTEM::%EVAL (DRAKMA:HTTP-REQUEST "https://github.com/slyrus")) 9: (EVAL (DRAKMA:HTTP-REQUEST "https://github.com/slyrus")) --more-- Any ideas if get-socket-stream needs some octet support or what the best way to address this is? thanks, Cyrus

2 1

[armedbear-devel] ANSI regression testing for abcl-0.23.1
by Mark Evenson 30 Nov '10

30 Nov '10

Results for the ANSI tests on abcl-0.22.0, abcl-0.23.0, and the proposed abcl-0.23.1 are attached. The results ANSI> (report 'doit '0.22.0 '0.23.1) NIL ANSI> (report 'compileit '0.22.0 '0.23.1) 0.23.1[SATURN] --> 0.22.0[SATURN] additional failures: (FLET.45) NIL indicate that we still have one regression in the compiled case for flet.45 (this was also present in abcl-0.23.0. FLET.45 fails in compiling (flet ((nil () 'a)) (nil)) getting lost in PRECOMPILE-FUNCTION-CALL: […] 4: (ERROR PROGRAM-ERROR :FORMAT-CONTROL "Wrong number of arguments for ~S." :FORMAT-ARGUMENTS (NIL)) 5: (SYSTEM::ARG-COUNT-ERROR DEFMACRO NIL NIL (SYSTEM::INSTANCE) 1 ...) 6: (#<FUNCTION (LAMBDA (#:G44218)) {5298DB1F}> (NIL)) 7: (SYSTEM::EXPAND-SOURCE-TRANSFORM-1 (NIL)) 8: (SYSTEM:EXPAND-SOURCE-TRANSFORM (NIL)) 9: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (NIL)) 10: (PRECOMPILER::PRECOMPILE1 (NIL)) 11: (PRECOMPILER::PRECOMPILE-FLET/LABELS (FLET ((NIL NIL 'A)) (NIL))) 12: (PRECOMPILER::PRECOMPILE1 (FLET ((NIL NIL 'A)) (NIL))) 13: (PRECOMPILER::PRECOMPILE-BLOCK (BLOCK FOO (FLET (#) (NIL)))) 14: (PRECOMPILER::PRECOMPILE1 (BLOCK FOO (FLET (#) (NIL)))) 15: (PRECOMPILER::PRECOMPILE-LAMBDA (LAMBDA NIL (BLOCK FOO (FLET # #)))) 16: (PRECOMPILER::PRECOMPILE1 (LAMBDA NIL (BLOCK FOO (FLET # #)))) -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Bug with spaces in directory for abcl-0.23.0
by Mark Evenson 29 Nov '10

29 Nov '10

I noticed that splittist reported on #abcl that abcl-0.23.0 has fails to start if it is in a directory that contains #\Space characters. The problem is related to my "fix" for loading Pathnames that contain #\+ characters which reveals that we are too undecided with our encoding of a JAR Pathname. The problem arises by not rigorously treating Pathnames with "jar:" and "file:" prefixes as having URLEncoded DIRECTORY, NAME, and TYPE components, which seems to be how the java.net.URL classes treat them. Although this seems innocent, when ABCL loads its FASLs it always using this code so this deeply effects the system operation, although normally no one actually constructs such URLs. My proposed fix would be to treat all inputs to Pathname which construct with "jar:" and "file:" schema as being URLEncoded. Likewise, we would fix the namestring routines to provide such encoding on the "way out" to string representations. There would therefore be a difference between (pathname-directory "file:/containing%20a%20space/") ==> (:ABSOLUTE "containing a space") and (pathname-directory #p"/containing%20a%20space/") ==> (:ABSOLUTE "containing%20a%20space") There would be a bit of a surprise that (pathname-directory "file:/cl+ssl!/foo.lisp") ==> (:absolute "cl ssl") It will take some time to chase down all the code paths here, so please comment if this solution is still ambiguous in some way that I haven't anticipated, or if someone has different proposal. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 6

[armedbear-devel] SLOW enumeration of scripting engines via JSR 223 interface...
by Martin Hepperle 27 Nov '10

27 Nov '10

Hi, embedding ABCL using JSR 223 scripting interface I see an nnoyingly long startup time for instances of the ScriptEngineFactory. This is annoying, as e.g. just enumerating all available scrip engines takes rather long because ABCL peforms its complete initailization when I only want to see what its name and script file extensions are. In the class AbclScriptEngineFactory there is a static field which holds a singleeton instance of the script engine: private static final AbclScriptEngine THE_ONLY_ONE_ENGINE = new AbclScriptEngine(); This field is unneccesarily instantiated as soon as the class AbclScriptEngineFactory is instantiated. It would be preferred to intantiate the cript engine only when actually needed, i.e. in getScriptEngine() and instead set it to null so that THE_ONLY_ONE_ENGINE can be tested agianst null inside getScriptEngine(). Thank You, Martin

2 2