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

[armedbear-devel] class-direct-subclasses has duplicates
by Alan Ruttenberg 18 Jan '10

18 Jan '10

It should be a set according to http://www.alu.org/mop/dictionary.html *Generic Function* *class-direct-subclasses* *class* Returns a set of the direct subclasses of *class*. The elements of this set are class metaobjects that all mention this class among their direct superclasses. The empty set is returned if *class* has no direct subclasses. This value is maintained by the generic functions *add-direct-subclass*<http://www.alu.org/mop/dictionary.html#add-direct-subclass> and *remove-direct-subclass*<http://www.alu.org/mop/dictionary.html#remove-direct-subclass> . (map nil 'print (system:class-direct-subclasses (find-class 'ido-pathway-block))) #<STANDARD-CLASS PARSED-SHEET-INFO-BLOCK {895391}> #<STANDARD-CLASS PARSED-EVIDENCE-BLOCK {C422A5}> #<STANDARD-CLASS PARSED-COMPLEX-BLOCK {90AD53}> #<STANDARD-CLASS PARSED-PROCESS-BLOCK {14D509}> #<STANDARD-CLASS PARSED-HANDLE-BLOCK {5AFFB3}> #<STANDARD-CLASS PARSED-SHEET-INFO-BLOCK {895391}> #<STANDARD-CLASS PARSED-EVIDENCE-BLOCK {C422A5}> #<STANDARD-CLASS PARSED-COMPLEX-BLOCK {90AD53}> #<STANDARD-CLASS PARSED-PROCESS-BLOCK {14D509}> #<STANDARD-CLASS PARSED-HANDLE-BLOCK {5AFFB3}> -Alan

2 2

[armedbear-devel] patch for ensure-directories-exist
by Alan Ruttenberg 18 Jan '10

18 Jan '10

ensure-directories-exist fails when passed a logical pathname. (defun ensure-directories-exist (pathspec &key verbose) - (let ((pathname (pathname pathspec)) + (let ((pathname (translate-logical-pathname (pathname pathspec))) (created-p nil)) (when (wild-pathname-p pathname) ....

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.18.1 released
by Erik Huelsmann 18 Jan '10

18 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. Because of some regressions which had gone undetected during testing for the release, we have released ABCL 0.18.1. Anyone using 0.18.0 should consider updating to 0.18.1 because the .0 release may exhibit seemingly random behavior. In addition, some enhancements have been included which were developed on user request. Bye, Erik.

1 0

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

15 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.18.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 This time with the correct url to the release notes. Bye, Erik.

3 2

[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