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

[armedbear-devel] [ANNOUNCE] ABCL 0.18.0 released
by Erik Huelsmann 13 Jan '10

13 Jan '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.18.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 - faster initial startup, faster special variable lookup and portable fasl files. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.17.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.18.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.zip.asc

1 0

[armedbear-devel] Folding Lisp application code into a JAR file in the Java CLASSPATH
by Olsen, Peter C. 13 Jan '10

13 Jan '10

Ladies and Gentlemen, Is there an elegant way to have ABCL load Lisp code from a JAR file in the Java CLASSPATH? I'm helping build an application to run under ABCL and I'd like to take all the code and roll it up into a JAR file in the CLASSPATH when I start the interpreter. If possible I'd then like to have ABCL find the file as though it were in the current directory. I know that ABLC is finding its system files in abcl.jar and I can load Lisp code from a local JAR file, but I haven't figured out how to put the two together and load Lisp elegantly from a JAR file in the CLASSPATH. I can do it inelegantly by getting the CLASSPATH from the Java System class, inspecting all its JAR files, then loading the right ones manually, but that seems awkward for a customer application. I'd appreciate any pointers. Finally, please let me apologize in advance if there's some simple answer that I should have found but haven't. Peter -- Peter Olsen, P.E., Ae.E. Registered Professional Engineer, Maryland License 12283 The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road, M/S 17-214 Laurel, Maryland, 20723 Baltimore: 443-778-2577; Washington DC 240-228-2577 Performance and cost must be considered as well as functionality. (RFC 1958)

3 5

[armedbear-devel] Fwd: [Bug] Identically named gensymed coalesced into same object in fasl file
by Erik Huelsmann 12 Jan '10

12 Jan '10

Sent the response below to Tobias privately by accident. ---------- Forwarded message ---------- From: Erik Huelsmann <ehuels(a)gmail.com> Date: Mon, Jan 11, 2010 at 11:40 PM Subject: Re: [armedbear-devel] [Bug] Identically named gensymed coalesced into same object in fasl file To: "Tobias C. Rittweiler" <tcr(a)freebits.de> Hi Tobias, Thanks for your report. This issue has long been in ABCL and it's not fixed yet. I have known about this problem for a while, but was kind of hoping it wouldn't show up in practice. I guess it did. This is what happens: when reading, the fasl loader creates an anonymous package in which it interns uninterned symbols. It "has" to do that, because ABCL doesn't store references to the actual unique objects everywhere; instead it stores the textual representation in some places. These symbols get coalesced by use of the anonymous package. So, generally the system of coalescing is something inherent to this idea. The idea is wrong enough for you to run into and get bitten by it. We'll have to come up with a better idea. Can you add the mail message below to our issue tracker? BTW: Did you happen to find this issue by accident? How did you find it? Bye, Erik. On Mon, Jan 11, 2010 at 10:35 PM, Tobias C. Rittweiler <tcr(a)freebits.de> wrote: > > I'm currently running an old checkout ("0.17.0-dev"), so the issue may > have been fixed meanwhile. > > ### /tmp/foo.lisp > (eval-when (:load-toplevel :execute) > (let ((a '#:foo) > (b '#:foo)) > (setf (fdefinition 'foo) (lambda () (values a b))))) > > (eval-when (:load-toplevel :execute) > (format t "~&(multiple-value-call #'eq (foo)) => ~S~%" > (multiple-value-call #'eq (foo)))) > ### > > CL-USER> (compile-file "/tmp/foo.lisp") > ; Compiling /tmp/foo.lisp ... > ; (LET (# #) ...) > ; (FORMAT T ...) > > ; Compilation unit finished > ; The following functions were used but not defined: > ; FOO > > ; Wrote /tmp/foo.abcl (0.034 seconds) > #P"/tmp/foo.abcl" > NIL > NIL > > That warning is bogus. There some work in this area so this bit may be > fixed already. > > The actual issue of my mail is this one, though: > > CL-USER> (load *) > (multiple-value-call #'eq (foo)) => T > T > > As you can see, ABCL coalesces the two identical named gensyms into the > same object in the fasl file. > > While 3.2.4.2.2 does specify that > > Two apparently uninterned symbols S and C are similar if their names > are similar. > > ABCL's behavior is still wrong because 3.2.4.1 says > > If two literal objects appearing in the source code for a single file > processed with the file compiler are the [sic] identical, the > corresponding objects in the compiled code must also be the > identical. __With the exception of symbols and packages__, any two > literal objects in code being processed by the file compiler may be > coalesced if and only if they are similar; __if they are either both > symbols or both packages, they may only be coalesced if and only if > they are identical__. > > -T. > > > _______________________________________________ > armedbear-devel mailing list > armedbear-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >

2 1

[armedbear-devel] [Bug] Identically named gensymed coalesced into same object in fasl file
by Tobias C. Rittweiler 11 Jan '10

11 Jan '10

I'm currently running an old checkout ("0.17.0-dev"), so the issue may have been fixed meanwhile. ### /tmp/foo.lisp (eval-when (:load-toplevel :execute) (let ((a '#:foo) (b '#:foo)) (setf (fdefinition 'foo) (lambda () (values a b))))) (eval-when (:load-toplevel :execute) (format t "~&(multiple-value-call #'eq (foo)) => ~S~%" (multiple-value-call #'eq (foo)))) ### CL-USER> (compile-file "/tmp/foo.lisp") ; Compiling /tmp/foo.lisp ... ; (LET (# #) ...) ; (FORMAT T ...) ; Compilation unit finished ; The following functions were used but not defined: ; FOO ; Wrote /tmp/foo.abcl (0.034 seconds) #P"/tmp/foo.abcl" NIL NIL That warning is bogus. There some work in this area so this bit may be fixed already. The actual issue of my mail is this one, though: CL-USER> (load *) (multiple-value-call #'eq (foo)) => T T As you can see, ABCL coalesces the two identical named gensyms into the same object in the fasl file. While 3.2.4.2.2 does specify that Two apparently uninterned symbols S and C are similar if their names are similar. ABCL's behavior is still wrong because 3.2.4.1 says If two literal objects appearing in the source code for a single file processed with the file compiler are the [sic] identical, the corresponding objects in the compiled code must also be the identical. __With the exception of symbols and packages__, any two literal objects in code being processed by the file compiler may be coalesced if and only if they are similar; __if they are either both symbols or both packages, they may only be coalesced if and only if they are identical__. -T.

1 0

[armedbear-devel] Preliminary patch for deriving Stream from StructureObject, in preparation for Gray streams support
by Ville Voutilainen 11 Jan '10

11 Jan '10

Please take a look at this patch. With the modifications to clinit orders in Lisp.java, this builds, but it doesn't work well enough to run the ansi tests. Any help is grealy appreciated.

1 0

[armedbear-devel] Gray streams support: plan of attack
by Erik Huelsmann 10 Jan '10

10 Jan '10

Today on IRC, Ville and I had a long discussion on how to get Gray streams supported in ABCL. The outcome is a long description, but I think it's good to write it down, so everybody following trunk understands what we're doing. Of course, if you have any feedback, please send it! The problem The issue with our current support for Gray streams is that we have almost everything in place except for one important thing: without hacking TYPEP and STREAMP, we're not able to fully support user-defined streams. However, hacking TYPEP is extremely fragile, as the compiler may assume things about certain types in the CL package. So, we don't want to go that route. On the other hand, it's not possible to derive classes from built-in classes, which means that in the current situation where STREAM is a built-in class, we cannot get the type of FUNDAMENTAL-STREAM right at all. Since we need to change things anyway, given the above, it would be nice to implement some of the CL streams in Lisp, particularly the ones which are not required to get ABCL booted. The plan We found out that if one declares an empty structure class - meaning a structure without slots - this class can be used in the superclasse list of defclass. What we're now doing is this: * Make STREAM an empty structure class * Create a SYSTEM-STREAM structure class which will contain slots in the future (but none for now) * Derive all internal stream classes from SYSTEM-STREAM * Derive FUNDAMENTAL-STREAM from the empty STREAM structure class (which is now possible with a normal DEFCLASS), making it a real stream At a later stage, we want to move code from all the non-boot-essential streams to Lisp. This should allow for easier maintenance and more compact (yet fully comprehensible) code. Bye, Erik.

1 0

[armedbear-devel] Proposed change to jar:file semantics
by Mark Evenson 09 Jan '10

09 Jan '10

My initial code to get LOAD to use "jar:file:" was rather hackish in that it didn't consider enough scope of the impact so I've been looking hard at implementing TRUENAME, PROBE-FILE, MERGE-PATHNAMES (and eventually PROBE-DIRECTORY and DIRECTORY) for "jar:file" entries. I'd like to propose we change the use of the "jar:file:" string to only occur in the namestring representation of a jar file entry, i.e. the device entry would always be a "real" pathname. So what would currently be CL-USER> (pathname-name (pathname-device #p"jar:file:abcl.jar!/foo")) "jar:file:abcl" which would become CL-USER> (pathname-name (pathname-device #p"jar:file:abcl.jar!/foo")) "abcl" under my proposal. This would simplify the needed code quite a bit as one just has to detect we are dealing with a jar entry reference, pull the pathname out of device, and pass it to a sub-routine. And according to the unofficial specification of the "jar:file" URI schema, it is invalid not to have a reference to the entry by the path following the "!/" (i.e. "jar:file:abcl.jar" has no meaning, just "jar:file:abcl.jar!/foo"). I've started to implement this, but would like to float this idea across the list to see if there are objections and/or problems I've not foreseen. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 1

[armedbear-devel] Questions for use in a server
by Blake McBride 09 Jan '10

09 Jan '10

Greetings, I am considering using ABCL as an extension language to a Web server app I have. I know the answer to many of the questions I have in choosing the correct extension language and ABCL seems to fit the bill well. I do have some questions, however. 1. Can ABCL run concurrently in multiple threads without any problems (I understand the ramifications in terms of my application code)? 2. I would like to have some utility code which is loaded once and shared by all the ABCL threads. Each thread can then run code that is independent (i.e. they can have the same function names with different definitions). (Perhaps I'd have to use packages for this.) 3. If I am running a lot of different threads will ABCL allow code to be GC'd when the thread ends (presuming no other thread is using that code)? 4. ABCL seems to have a somewhat heavy startup time. This is okay for the first time, but I need the threads to start much faster (much less than half a second). Thanks for the answers! Blake

4 5

[armedbear-devel] Why does jcall use reflection?
by Axel Rauschmayer 09 Jan '10

09 Jan '10

I hope this is not a stupid question, but: Why does jcall use reflection? Doesn't ABCL compile lisp to byte code? If one could statically declare to the compiler the intended Java class, couldn't method invocations be compiled instead of being performed via reflection? OTOH, I don't know how ABCL handles interpretation versus compilation, so that might be an issue. -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/

3 4

[armedbear-devel] new jcall / jar:file: path functions
by Alan Ruttenberg 09 Jan '10

09 Jan '10

I'm trying to use the new jcall code in place of jss calls. However I am getting an error I don't understand. In the following: (defun directory-in-jar (pathname) (let* ((jarfile (subseq (namestring (pathname-device pathname)) 9)) (rest-pathname (namestring (make-pathname :directory (pathname-directory pathname) :name (pathname-name pathname) :type (pathname-type pathname))))) (if (or (position #\* (namestring rest-pathname)) (wild-pathname-p rest-pathname)) (let ((jar (jnew "java.util.zip.ZipFile" jarfile))) (let ((els (jcall "entries" jar))) (loop while (#"hasMoreElements" els) for name = (jcall "getName" (#"nextElement" els)) when (pathname-match-p (concatenate 'string "/" name) rest-pathname) collect (make-pathname :device (pathname-device pathname) :name (pathname-name name) :type (pathname-type name) :directory `(:absolute ,@(cdr (pathname-directory name))))))) (let ((truename (probe-file-in-jar pathname))) (if truename (list truename) nil))))) If I replace the call (#"hasMoreElements" els) with (jcall "hasMoreElements" els) I get the error: java.lang.IllegalAccessException: Class org.armedbear.lisp.Java can not access a member of class java.util.zip.ZipFile$3 with modifiers "public" at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65) at java.lang.reflect.Method.invoke(Method.java:583) at org.armedbear.lisp.Java.jcall(Java.java:660) ... If I replace the call (#"nextElement" els) with (jcall "nextElement" els) I get the error java.lang.IllegalAccessException: Class org.armedbear.lisp.Java can not access a member of class java.util.zip.ZipFile$3 with modifiers "public volatile" at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65) at java.lang.reflect.Method.invoke(Method.java:583) at org.armedbear.lisp.Java.jcall(Java.java:660) This from http://svn.mumble.net:8080/svn/lsw/trunk/patches/jarfile.lisp where I'm starting to add more path functions that work with the jar:file: pathname scheme. Feel free to steal and incorporate into abcl. -Alan

3 12