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

[armedbear-devel] armedbear-devel@common-lisp.net
by Anton Vodonosov 05 Jul '09

05 Jul '09

Hello, According to the project page, there is ansi test suite. But 0.15.0 package from sourceforge doesn't contain it. Also I can't find on the project page any reference to source code repository. Is it really the current state of affairs, or I missing something? Best regards, - Anton

2 1

[armedbear-devel] ansi tests
by Anton Vodonosov 05 Jul '09

05 Jul '09

on Sunday, July 5, 2009, 3:27:37 PM Ville wrote: > On Sun, Jul 5, 2009 at 1:51 PM, Anton > Vodonosov<avodonosov(a)gmail.com> wrote: >> According to the project page, there is ansi test suite. >> But 0.15.0 package from sourceforge doesn't contain it. > You need to get it separately, from > svn://common-lisp.net/project/ansi-test/svn/trunk/ansi-tests I checked-out the suite, but it seems to be insufficient. How to run the tests? ant in the abcl directory suggest to use "ant acbl.test.java". It fails with: BUILD FAILED C:\usr\unpacked\abcl\abcl-src-0.15.0-original\build.xml:481: srcdir "C:\usr\unpacked\abcl\abcl-src-0.15.0-original\test\src" does not exist! The project page suggests to run ant test.ansi.interpreted ant test.ansi.compiled This fails with [java] Debugger invoked on condition of type FILE-ERROR: [java] File not found: C:\usr\unpacked\abcl\abcl-src-0.15.0-original/test/lisp/ansi/ansi-tests-interpreted.lisp There is indeed no directory "test" in the 0.15.0 package I downloaded from sourceforge. Best regards, - Anton

1 0

[armedbear-devel] Franz-style Gates implementation
by Mark Evenson 04 Jul '09

04 Jul '09

Tobias Rittweiler writes: > The attached patch adds Gates to ABCL, inspired by what Franz Allegro > Common Lisp provides. > > A GATE is an object with two states, open and closed. It is > created with MAKE-GATE. Its state can be opened (OPEN-GATE) or > closed (CLOSE-GATE) and can be explicitly tested with > GATE-OPEN-P. Usually though, a thread awaits the opening of a > gate by WAIT-OPEN-GATE. > > This will be used to implement the threading communication style in > ABCL's Swank backend. > > I'm not particularly good at writing multiprocessing, or Java code. So > please review carefully. Tobias wrote this to support his version of a multi-threaded SLIME backend, and has proposed it for inclusion in ABCL. When I get some time, I'll do some tests, but post the patch here in case it helps someone else out before that time or if their is any feedback. As it stands, the Gates implementation would go in the EXTENSIONS package. Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

4 6

[armedbear-devel] Threading issue with ERROR (?)
by Erik Huelsmann 04 Jul '09

04 Jul '09

I have an application which uses a combination of DEFINE-CONDITION, ERROR and HANDLER-CASE to handle certain exceptional situations. The call sequence basically looks like this: (when loading the file:) (define-condition model-error (error) ()) (defun foo1 (arg) (if arg (error 'model-error) 3)) (defun foo2 (arg) (handler-case (foo1 arg) (model-error () 0.0d0)) and then, from different threads: (foo2 <some value or NIL>) When I do this in a single-threaded application all goes well. When I do this in a multi threaded application with a single calculation (lisp) thread, all goes well as well. When I do this in a multi threaded application with multiple calculation threads (lisp), I get a NullPointerException somewhere deep in our CLOS code... Has anybody experienced the same? Bye, Erik.

1 0

[armedbear-devel] Patch to add multi-threading to ABCL SLIME CVS HEAD
by Mark Evenson 02 Jul '09

02 Jul '09

Attached is a patch against SLIME CVS HEAD to implement multi-threading (aka the :spawn *COMMUNICATION-STYLE*) as a default in ABCL. In addition this patch muffles various STYLE-WARNING compilation messages via DECLARE forms. Among other things, this seems to fix the fugliness around where *STANDARD-OUTPUT* ends up and the missing CR (or LF) in the NIL *COMMUNICATION-STYLE*. This patch has been tested against ABCL 0.16.0-dev as of [svn r12022] with Emacs 22.3 under OS X. I didn't need to do much to the existing code except fix a typo while comparing against the current 'swank-sbcl.lisp' version, making me somewhat suspicious of why that code was not used in the first place (did someone just cut and paste the SBCL implementation without trying to get it to work? But thanks to whoever got it that far!) -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." diff -r 2225a8f2d322 -r 3c562ce589df swank-abcl.lisp --- a/swank-abcl.lisp Wed Jul 01 05:38:54 2009 +0200 +++ b/swank-abcl.lisp Wed Jul 01 11:06:42 2009 +0200 @@ -17,6 +17,7 @@ (defun sys::break (&optional (format-control "BREAK called") &rest format-arguments) (let ((*saved-backtrace* (backtrace-as-list-ignoring-swank-calls))) + (declare (ignore *saved-backtrace*)) (with-simple-restart (continue "Return from BREAK.") (invoke-debugger (sys::%make-condition 'simple-condition @@ -42,10 +43,16 @@ ;(defun class-finalized-p (class) t) -(defun slot-definition-documentation (slot) #+nil (documentation slot 't)) -(defun slot-definition-type (slot) t) -(defun class-prototype (class)) -(defun generic-function-declarations (gf)) +(defun slot-definition-documentation (slot) + (declare (ignore slot)) + #+nil (documentation slot 't)) +(defun slot-definition-type (slot) + (declare (ignore slot)) + t) +(defun class-prototype (class) + (declare (ignore class))) +(defun generic-function-declarations (gf) + (declare (ignore gf))) (defun specializer-direct-methods (spec) (mop::class-direct-methods spec)) (defun slot-definition-name (slot) @@ -61,9 +68,11 @@ (mop::%method-function method)) (defun slot-boundp-using-class (class object slotdef) + (declare (ignore class)) ; FIXME (system::slot-boundp object (slot-definition-name slotdef))) (defun slot-value-using-class (class object slotdef) + (declare (ignore class)) ; FIXME (system::slot-value object (slot-definition-name slotdef))) (import-to-swank-mop @@ -119,7 +128,7 @@ (defimplementation preferred-communication-style () - nil) + :spawn) (defimplementation create-socket (host port) (ext:make-server-socket port)) @@ -483,8 +492,8 @@ ;;;; Multithreading -(defimplementation startup-multiprocessing () - #+nil(mp:start-scheduler)) +#+nil ; Already started +(defimplementation startup-multiprocessing (continuation)) (defimplementation spawn (fn &key name) (ext:make-thread (lambda () (funcall fn)) :name name)) @@ -513,7 +522,23 @@ (defimplementation thread-status (thread) (format nil "Thread is ~:[dead~;alive~]" (ext:thread-alive-p thread))) +;; XXX should be a weak hash table +(defparameter *thread-description-map* (make-hash-table)) + +(defvar *thread-description-map-lock* + (ext:make-mutex)) + +(defimplementation thread-description (thread) + (ext:with-mutex (*thread-description-map-lock*) + (or (gethash thread *thread-description-map*) + "No description available."))) + +(defimplementation set-thread-description (thread description) + (ext:with-mutex (*thread-description-map-lock*) + (setf (gethash thread *thread-description-map*) description))) + (defimplementation make-lock (&key name) + (declare (ignore name)) (ext:make-thread-lock)) (defimplementation call-with-lock-held (lock function) @@ -525,8 +550,11 @@ (defimplementation all-threads () (copy-list (ext:mapcar-threads #'identity))) +(defimplementation thread-alive-p (thread) + (member thread (all-threads))) + (defimplementation interrupt-thread (thread fn) - (ext:interrupt-thread thread fn)) + (ext:interrupt-thread thread fn)) (defimplementation kill-thread (thread) (ext:destroy-thread thread)) @@ -542,14 +570,13 @@ (setf (getf (gethash thread *thread-props*) 'mailbox) (make-mailbox))))) -(defimplementation send (thread object) +(defimplementation send (thread message) (let ((mbox (mailbox thread))) (ext:with-mutex ((mailbox-mutex mbox)) (setf (mailbox-queue mbox) (nconc (mailbox-queue mbox) (list message)))))) -#+(or) -(defimplementation receive-if (thread &optional timeout) +(defimplementation receive-if (test &optional timeout) (let* ((mbox (mailbox (current-thread)))) (assert (or (not timeout) (eq timeout t))) (loop @@ -561,9 +588,7 @@ (setf (mailbox-queue mbox) (nconc (ldiff q tail) (cdr tail))) (return (car tail)))) (when (eq timeout t) (return (values nil t))) - ;;(java:jcall (java:jmethod "java.lang.Object" "wait") - ;; (mailbox-mutex mbox) 1000) - )))) + (sleep .05))))) (defimplementation quit-lisp () (ext:exit))

2 3

[armedbear-devel] Lisp->Java object conversion
by Alessio Stalla 25 Jun '09

25 Jun '09

ABCL has a built-in way of converting values from Java to Lisp: JavaObject.getInstance(x, true), which covers the most common cases. The contrary AFAIK is not as well-defined: conversion from Lisp to Java is done in ad-hoc ways all over the place. This is not optimal, especially for someone using abcl embedded into Java - someone who might not know the rules and conventions used in abcl. I believe the method LispObject.javaInstance(Class) could be used to provide such a conversion facility. Currently it has not very clear semantics: the one in LispObject does a type check to ensure "this" is an instance of the class passed as parameter, however there are overrides in subclasses which skip the check and happily return a value in all cases, ignoring the parameter. I propose the following unified semantics: x.javaInstance(c) returns a value (x itself, or some other object) that is guaranteed to be of class c (*) and to represent a value "similar" to x, for some meaning of "similar". If such a value cannot be produced, a type error is signaled. Examples: LispObject.javaInstance(Boolean.{class|TYPE}) ==> true if this != NIL, false otherwise LispObject.javaInstance(anythingelse) ==> this if (this instanceof anythingelse), error otherwise (like it does now) Nil.javaInstance(Boolean.{class|TYPE}) ==> false Nil.javaInstance(anything else) ==> null AbstractString.javaInstance(CharSequence and subclasses) ==> the string AbstractString.javaInstance(anything else) ==> error ...etc (numbers, what else?) ... I.e. in general x = y.javaInstance(c); JavaObject.getInstance(x, true).equals(y) ==> true and x = JavaObject.getInstance(y, true); x.javaInstance(y.getClass()).equals(y) ==> true What do you think? Bye, Ale --------------------- (*) or better, assignable to a variable of type c - this includes null while the former doesn't.

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.15.0
by Reinhard Oldenburg 25 Jun '09

25 Jun '09

Dear all, I failed to detect from the source code how to set the working directory from abcl at the lisp value. There is an inital directory in the Interpreter class, but there seems to be no way to change the directory after startup, or is there? Reinhard Oldenburg

2 1

[armedbear-devel] patch: dump-specials
by Alessio Stalla 24 Jun '09

24 Jun '09

Hello folks, I'll be the first to test the new mailing list ;) Some time ago I found myself in need of inspecting abcl's dynamic environment because I wanted to check if a certain variable was rebound somewhere. So, I added a DUMP-SPECIALS primitive that prints the dynamic environment as an alist, taking rebinding into account so that (cdr (assoc 'x (dump-specials))) is equivalent to (symbol-value 'x). I don't know if this functionality was already present, nor if it interests anyone, anyway here's the patch. Bye, Alessio

1 0

[armedbear-devel] Readably printing of #<SINGLE-FLOAT NaN>s and #<DOUBLE-FLOAT NaN>s
by Erik Huelsmann 15 Jun '09

15 Jun '09

Last week I found that - although I requested information to be printed readably - NaNs are printed unreadable, without generating an error. I'd really like to fix this, especially because it broke the expectation of readable input after succesfull save. At first, I thought I'd print it as #.SYS::SINGLE-FLOAT-NAN However, that has the disadvantage that it's definitely non-portable. However, some implementations have a mode where (/ 0.0s0 0.0s0) results in a NaN instead of a DIVISION-BY-ZERO. The new proposal is to print NaN as #.(/ 0.0s0 0.0s0) and #.(/ 0.0d0 0.0d0) respectively, if readable printing is requested; non-readable printing can stay as it is (ie using #<...>). That works (is readable input) for ABCL. For SBCL, this is readable input if it's in IEEE mode. With respect to any of the other Lisps, I have no idea. Comments? With kind regards, Erik.

1 0

[armedbear-devel] CFFI ported to ABCL
by Luís Oliveira 14 Jun '09

14 Jun '09

Hello, I have ported CFFI to ABCL using the Java Native Access (JNA) library. This is a preliminary version that will have to be cleaned up and optimized, etc. Nevertheless, at this point it passes all of the relevant CFFI tests except one. Callbacks and shareable vectors are not implemented yet. The former seem to require functionality that is not yet present in ABCL, IIUC. If anyone is interested in playing with this port, I have uploaded a patch to <http://common-lisp.net/~loliveira/patches/cffi-abcl.diff>. It requires trivial-features 0.5. Cheers. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0