armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

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

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel