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

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

[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

[armedbear-devel] [ANNOUNCE] ABCL 0.23.0
by Erik Huelsmann 25 Nov '10

25 Nov '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.23.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. This release features - among lots of other things - CLOS thread safety fixes and concurrency improvements, support for Oracle's JRockit JVM, and a new (generic) class file writer. In addition, this is the first release to complete the Maxima test suite without failures, thanks to close cooperation between our projects. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.23.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/abcl-src-0.23.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.23.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.23.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.23.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.23.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.23.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.23.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.23.0.zip.asc

1 1

[armedbear-devel] ANSI regressions in proposed 0.23.x
by Mark Evenson 25 Nov '10

25 Nov '10

Unfortunately, I'm seeing the following regressions in the ANSI test suite from 0.22.0 to the 0.23.x branch. I think that we can ignore the PRINT.SYMBOL.RANDOM.3 failure, as that has been present intermittently for a while. ANSI> (REPORT 'compileit '0.22.0 '0.23.0) 0.23.0[SATURN] --> 0.22.0[SATURN] additional failures: (STANDARD-METHOD-CPL ALL-EXPORTED-CL-CLASS-NAMES-ARE-VALID TYPES.9A TYPES.3 FLET.45) NIL ANSI> (REPORT 'doit '0.22.0 '0.23.0) 0.23.0[SATURN] --> 0.22.0[SATURN] additional failures: (PRINT.SYMBOL.RANDOM.3 STANDARD-METHOD-CPL ALL-EXPORTED-CL-CLASS-NAMES-ARE-VALID TYPES.9A TYPES.3) NIL (compileit 0.22.0 :id saturn :uname "x64-solaris-2.11.snv_111b" :jvm "jdk-1.6.0_22" (REINITIALIZE-INSTANCE.ERROR.1 DEFGENERIC.ERROR.20 DEFGENERIC.ERROR.21 DEFGENERIC.30 CALL-NEXT-METHOD.ERROR.1 CALL-NEXT-METHOD.ERROR.2 DEFMETHOD.ERROR.14 DEFMETHOD.ERROR.15 INVOKE-DEBUGGER.1 MAKE-CONDITION.3 MAKE-CONDITION.4 DELETE-PACKAGE.5 DELETE-PACKAGE.6 MAP.48 TYPE-OF.1 TYPE-OF.4 MAKE-PATHNAME.9 PRINT.RANDOM-STATE.1 PPRINT-FILL.14 PPRINT-FILL.15 PPRINT-LINEAR.14 PPRINT-TABULAR.13 PPRINT-LOGICAL-BLOCK.17 PPRINT-POP.7 PPRINT-POP.8 FORMAT.LOGICAL-BLOCK.CIRCLE.1 FORMAT.LOGICAL-BLOCK.CIRCLE.2 FORMAT.LOGICAL-BLOCK.CIRCLE.3 COMPILE-FILE.16 TRACE.8)) (doit 0.22.0 :id saturn (REINITIALIZE-INSTANCE.ERROR.1 DEFGENERIC.ERROR.20 DEFGENERIC.ERROR.21 DEFGENERIC.30 CALL-NEXT-METHOD.ERROR.1 CALL-NEXT-METHOD.ERROR.2 DEFMETHOD.ERROR.14 DEFMETHOD.ERROR.15 INVOKE-DEBUGGER.1 MAKE-CONDITION.3 MAKE-CONDITION.4 DELETE-PACKAGE.5 DELETE-PACKAGE.6 MAP.48 TYPE-OF.1 TYPE-OF.4 MAKE-PATHNAME.9 PRINT.SYMBOL.RANDOM.2 PRINT.STRING.RANDOM.1 PRINT.RANDOM-STATE.1 PPRINT-FILL.14 PPRINT-FILL.15 PPRINT-LINEAR.14 PPRINT-TABULAR.13 PPRINT-LOGICAL-BLOCK.17 PPRINT-POP.7 PPRINT-POP.8 FORMAT.LOGICAL-BLOCK.CIRCLE.1 FORMAT.LOGICAL-BLOCK.CIRCLE.2 FORMAT.LOGICAL-BLOCK.CIRCLE.3 COMPILE-FILE.16)) (compileit 0.23.0 :id saturn (FLET.45 REINITIALIZE-INSTANCE.ERROR.1 DEFGENERIC.ERROR.20 DEFGENERIC.ERROR.21 DEFGENERIC.30 CALL-NEXT-METHOD.ERROR.1 CALL-NEXT-METHOD.ERROR.2 DEFMETHOD.ERROR.14 DEFMETHOD.ERROR.15 INVOKE-DEBUGGER.1 MAKE-CONDITION.3 MAKE-CONDITION.4 DELETE-PACKAGE.5 DELETE-PACKAGE.6 MAP.48 TYPES.3 TYPES.9A ALL-EXPORTED-CL-CLASS-NAMES-ARE-VALID TYPE-OF.1 TYPE-OF.4 STANDARD-METHOD-CPL MAKE-PATHNAME.9 PRINT.RANDOM-STATE.1 PPRINT-FILL.14 PPRINT-FILL.15 PPRINT-LINEAR.14 PPRINT-TABULAR.13 PPRINT-LOGICAL-BLOCK.17 PPRINT-POP.7 PPRINT-POP.8 FORMAT.LOGICAL-BLOCK.CIRCLE.1 FORMAT.LOGICAL-BLOCK.CIRCLE.2 FORMAT.LOGICAL-BLOCK.CIRCLE.3 COMPILE-FILE.16 TRACE.8)) (doit 0.23.0 :id saturn (REINITIALIZE-INSTANCE.ERROR.1 DEFGENERIC.ERROR.20 DEFGENERIC.ERROR.21 DEFGENERIC.30 CALL-NEXT-METHOD.ERROR.1 CALL-NEXT-METHOD.ERROR.2 DEFMETHOD.ERROR.14 DEFMETHOD.ERROR.15 INVOKE-DEBUGGER.1 MAKE-CONDITION.3 MAKE-CONDITION.4 DELETE-PACKAGE.5 DELETE-PACKAGE.6 MAP.48 TYPES.3 TYPES.9A ALL-EXPORTED-CL-CLASS-NAMES-ARE-VALID TYPE-OF.1 TYPE-OF.4 STANDARD-METHOD-CPL MAKE-PATHNAME.9 PRINT.SYMBOL.RANDOM.2 PRINT.SYMBOL.RANDOM.3 PRINT.STRING.RANDOM.1 PRINT.RANDOM-STATE.1 PPRINT-FILL.14 PPRINT-FILL.15 PPRINT-LINEAR.14 PPRINT-TABULAR.13 PPRINT-LOGICAL-BLOCK.17 PPRINT-POP.7 PPRINT-POP.8 FORMAT.LOGICAL-BLOCK.CIRCLE.1 FORMAT.LOGICAL-BLOCK.CIRCLE.2 FORMAT.LOGICAL-BLOCK.CIRCLE.3 COMPILE-FILE.16)) -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 3