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

[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

[armedbear-devel] [ANNOUNCE] ABCL 0.15.0
by Erik Huelsmann 08 Jun '09

08 Jun '09

On behalf of the developers of ABCL (Armed Bear Common Lisp) - a lisp implementation running on the JVM - I'm glad to be able to announce the 0.15.0 release. This release features - among lots of other things - changes to support Google App Engine, another round of improvements in handling of special variables (compiled code) and a lot of improvements on handling closures (compiled code). Measured by the number of failing ANSI tests, this release is only a small step: most improvements were not detected as errors. Additionally some work has been done on improving performance. For a full list of changes see [1]. If you have questions regarding its license or use, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net The sources can be downloaded in ZIP or .tar.gz form from SourceForge: http://downloads.sourceforge.net/armedbear-j/abc/abcl-src-0.15.0.tgz http://downloads.sourceforge.net/armedbear-j/abc/abcl-src-0.15.0.zip Signatures will become available shortly. When they do, they will be available under: http://downloads.sourceforge.net/armedbear-j/abc/abcl-src-0.15.0.tgz.asc http://downloads.sourceforge.net/armedbear-j/abc/abcl-src-0.15.0.zip.asc Bye, Erik. [1] http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES

1 1