- armedbear-devel - mailman3.common-lisp.net

[armedbear-devel] An example of using the ability to dynamically create Java interfaces
by Mark Evenson 05 Dec '10

05 Dec '10

This can probably be cleaned up a lot. Among other things, it shows a nearly constant need to protect the "raw" Java values from ABCL's interpretation to do anything useful. For example (let ((c (jclass "java.io.File"))) (jnew-array-from-array "java.lang.Class" #(c c c))) fails to construct an array as the java.lang.Class members are promoted to JAVA-OBJECT. Does this mean we need JNEW-ARRAY-FROM-ARRAY-RAW? Or do we need to try both interpretations? Onwards through callbacks in CFFI… [1]: http://trac.common-lisp.net/armedbear/changeset/13089 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Idiomatic conversion of file: URLs to file-paths
by Erik Huelsmann 05 Dec '10

05 Dec '10

Hi Mark, To get back to our earlier (irc) discussion of converting URL.getPath() / URI.getPath() to (Windows) pathnames: I found this page: http://weblogs.java.net/blog/2007/04/25/how-convert-javaneturl-javaiofile which contains code on how to do the conversion. I just checked on Windows it even strips the leading '/' which you get from URL.getPath(). My reaction to these findings is to propose a new static function to be added to the Utilities class, which should be used to convert file:/ urls to paths. Our code should then be searched for invocations of URL/URI.getPath() on file urls, changing it to the utility function. Regards, Erik.

1 0

[armedbear-devel] bug in RandomAccessCharacterFile.java
by David Kirkman 05 Dec '10

05 Dec '10

The problem is that in the while loop (line 549), if only part of the byte array is written to the buffer, the position is updated but the length is not. I'm attaching a patch. Here is some code that fails in r13087, and works with the patch. I ran into this while serializing mixed lisp/java objects, which is pretty well reflected in this snippet. Cheers, -david k. (let* ((len 5000) (big-object (jnew-array "double" len))) (dotimes (i len) (setf (jarray-ref big-object i) (+ i 0.1))) (with-open-file (stream "foo.dat" :direction :output :element-type 'unsigned-byte) (let ((p (jnew (jconstructor "java.io.ObjectOutputStream" "java.io.OutputStream") (jcall (jmethod "org.armedbear.lisp.Stream" "getWrappedOutputStream") stream)))) (jcall (jmethod "java.io.ObjectOutputStream" "writeObject" "java.lang.Object") p big-object) (jcall (jmethod "java.io.ObjectOutputStream" "flush") p))) (let ((big-object2 (with-open-file (stream "foo.dat" :direction :input :element-type 'unsigned-byte) (let ((p (jnew (jconstructor "java.io.ObjectInputStream" "java.io.InputStream") (jcall (jmethod "org.armedbear.lisp.Stream" "getWrappedInputStream") stream)))) (jcall (jmethod "java.io.ObjectInputStream" "readObject") p))))) (dotimes (i len) (format t "~A ~A~%" (jarray-ref big-object i) (jarray-ref big-object2 i)))))

2 1

Re: [armedbear-devel] Patch for ABCL against BORDEAUX-THREADS-0.8.0
by Mark Evenson 04 Dec '10

04 Dec '10

On 12/3/10 4:56 PM, Martin Simmons wrote: >>>>>> On Fri, 03 Dec 2010 14:37:52 +0100, Mark Evenson said: >> >> Implement CONDITION-WAIT and CONDITION-NOTIFY for ABCL. > > That version of CONDITION-WAIT won't work properly: Indeed it won't: thanks for the comments, and the kick in the butt. After studying the needed abstractions in more detail I've [reimplemented most of the BORDEAUX-THREADS interfaces for ABCL based on the java.util.concurrent.ReentrantLock][1]. This code should now correctly implement the POSIX-style condition variables, the recursively held locks, and the form of lock acquisition that returns immediately. Please consider the referenced patch for inclusion in BORDEAUX-THREADS. [1]: http://slack.net/~evenson/abcl/hunchentoot/bordeaux-threads-abcl-20101204a.… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[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

Re: [armedbear-devel] [armedbear-cvs] r13078 - in trunk/abcl: nbproject src/org/armedbear/lisp
by Erik Huelsmann 03 Dec '10

03 Dec '10

Hi Mark, On Wed, Dec 1, 2010 at 11:44 PM, Mark Evenson <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Wed Dec 1 17:44:34 2010 > New Revision: 13078 > > Log: > The classfile writer now handles the creation of interfaces. > Modified: > trunk/abcl/nbproject/build-impl.xml > trunk/abcl/nbproject/genfiles.properties ^^^^ Did you intend to commit the NB project file changes? > trunk/abcl/src/org/armedbear/lisp/jvm-class-file.lisp Bye, Erik.

2 1

[armedbear-devel] [ANNOUNCE] ABCL 0.23.1: Fix for loading ABCL from a path with spaces
by Erik Huelsmann 02 Dec '10

02 Dec '10

1 0

[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