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

[armedbear-devel] initialization of shared slots
by Didier Verna 26 Jan '11

26 Jan '11

Hello, it seems that until now, I've been relying on a non-standard behavior, namely the fact that shared slots with an :initform are initialized before the first actual class instance is created: (defclass test () ((slot :allocation :class :initform t))) (defmethod initialize-instance :before ((test test) &key) (format t "Slot boundp: ~A~%" (slot-boundp test 'slot))) CL-USER> (make-instance 'test) Slot boundp: NIL #<TEST {C5D3B8}> CL-USER> (make-instance 'test) Slot boundp: T #<TEST {14563D4}> CL-USER> I just fell on this because every other Common Lisp implementation I've tried gives T and T here. Is it due to the way CLOS is implemented in ABCL, and is there a chance that this can be improved? Thanks. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

3 4

Re: [armedbear-devel] Infinite loop loading compiled file
by Greg Baryza 25 Jan '11

25 Jan '11

I have a self-contained directory that has only the QI files needed to reproduce the problem. In it there is a subdirectory called JAR where you should place the ABCL jar file of your choice. _COMPILE.bat compiles files and then loads them; it hangs trying to load the fourth file. _BUILD.bat uses the same files but just loads the lisp sources; it works. I have all this in a 16KB zip file ready to go. Where do you want it? <G> At 09:23 PM 1/25/2011, Erik Huelsmann wrote: >Hi Greg, > >On Tue, Jan 25, 2011 at 3:33 PM, Greg Baryza <baryza(a)intersystems.com> wrote: > > I recently became interested in the language QI. Â Since it did not run on > > ABCL (it does on SBCL, Allegro, LispWorks and others), I decided to see > > what it would take to move it there. Â From the QI mailing list, I found > > several others had tried on earlier versions of ABCL with inconclusive > > results. Â I decided to give it a try on 0.23.1. > > > > When I tried the standard script with compiles and then loads the compiled > > files, ABCL hangs it what appears to be an infinite loop try to load one of > > the compiled files. Â When I switch to just loading them in as Lisp > sources, > > things seem to work (though some of the QI tests later fail). > > > > I tried the compile/load script under 0.24.0 today and the same hang > happens. > > > > I have a small test case consisting only of the needed sources and a couple > > of .bat files for Windows that demonstrates the problem, but before I > > proceed further, has anyone seem anything like this. Â The file in question > > DEFUNs about 85 functions. Â Is that too many to provoke the "large file" > > problem I see mentioned here? > >Could you provide us with a transcript for downloading/installing Qi >so we/I can test? > >If this is the same old bug, the ball is really in Qi's park, but if >it's not, we're really happy to fix what we can! > >Thanks! > > >Bye, > > >Erik.

2 1

[armedbear-devel] Problem with error reporting
by Blake McBride 25 Jan '11

25 Jan '11

I've noticed a problem with error reporting in certain cases. For example, if you type (cons) you get: "Wrong number of arguments for CONS." However, if you type (time) you get: "Wrong number of arguments for ~S." It should be: "Wrong number of arguments for TIME." Of course this is a problem because it doesn't give any pointers when a function fails. I've seen this issue in several instances. Thanks. Blake McBride

3 11

[armedbear-devel] Infinite loop loading compiled file
by Greg Baryza 25 Jan '11

25 Jan '11

I recently became interested in the language QI. Since it did not run on ABCL (it does on SBCL, Allegro, LispWorks and others), I decided to see what it would take to move it there. From the QI mailing list, I found several others had tried on earlier versions of ABCL with inconclusive results. I decided to give it a try on 0.23.1. When I tried the standard script with compiles and then loads the compiled files, ABCL hangs it what appears to be an infinite loop try to load one of the compiled files. When I switch to just loading them in as Lisp sources, things seem to work (though some of the QI tests later fail). I tried the compile/load script under 0.24.0 today and the same hang happens. I have a small test case consisting only of the needed sources and a couple of .bat files for Windows that demonstrates the problem, but before I proceed further, has anyone seem anything like this. The file in question DEFUNs about 85 functions. Is that too many to provoke the "large file" problem I see mentioned here? Thanks.

4 3

[armedbear-devel] Dynamic classpath settings (ticket #18)
by Erik Huelsmann 24 Jan '11

24 Jan '11

Hi Alessio, There's a ticket (#18, http://trac.common-lisp.net/armedbear/ticket/18) to add dynamic classpath capabilities to ABCL, just as used by invoke.lisp. Browsing through our sources, I think you may have added this capability already. Can the issue be closed? Bye, Erik.

3 3

[armedbear-devel] [ANNOUNCE] ABCL 0.24.0 released
by Erik Huelsmann 22 Jan '11

22 Jan '11

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.24.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 JSR 223: Java scripting API. This release features - among lots of other things - improved embedding support through elimination of System.exit() calls and fixes a regression causing FASLs to be limited in the number of functions they can contain. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.24.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/0.24.0/abcl-src-0.24.0.ta… http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-src-0.24.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/0.24.0/releases/abcl-src-0.24.0.ta… http://common-lisp.net/project/armedbear/0.24.0/releases/abcl-src-0.24.0.zi… In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-bin-0.24.0.ta… http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-bin-0.24.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.24.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.24.0.zip.asc

1 0

[armedbear-devel] Design issue regarding condition printing (was: Error reporting problems)
by Erik Huelsmann 22 Jan '11

22 Jan '11

In order to start addressing our issue with error reporting, I thought I'd start poking around at the source of all Java based exception classes (of which both PROGRAM-ERROR and SIMLE-ERROR are part). This source is the Condition java class. In the class 3 methods have been defined, all related to printing of (java based) errors: * getMessage() [overridden 13 times, 8 call sites] * getConditionReport() [not overridden, 1 call site] * writeToString() While the role of "writeToString()" is clear (it's called by PRINT to print all Java-based objects) and hence should function differently under different circumstances, the role separation between getMessage() and getConditionReport() isn't quite so well defined. This conclusion comes both from the extreme lack of documentation as well as the following: getConditionReport() calls getMessage() to find an "alternative message" to be reported. getMessage() finds out if there's a formatControl string; if there is, it calls writeToString() to generate a message, returning that to getConditionReport(). If getConditionReport() doesn't get an alternative from getMessage() to return back to the caller, it calls Lisp.format() to generate a formatted string to be presented to the user. However, this second path will never get called, except when there's no format string.... Lisp.format() explicitly checks for a null format control string and returns an empty string - which explains why we haven't seen crashes from the above code paths. So, how does that tie into the grand scheme of error reporting? We have two places where errors are being reported: 1. the lisp debugger, which prints errors using the real (lisp based) FORMAT function if it's autoloaded (but falls back to Lisp.format() if FORMAT isn't autoloaded yet) which is invoked by INVOKE-DEBUGGER-REPORT-CONDITION 2. the ERROR place holder Primitives.ERROR() which calls Condition.getConditionReport() The Lisp based FORMAT uses PRINT-OBJECT to print conditions. PRINT-OBJECT.lisp defines specialized instances for several classes in the condition class hieranchy. I know I added some in order to try to address the exact issue we're talking about here. The Java based Lisp.format() function uses <condition>.writeToString() to produce its output. With all these facts on the table, I think we need to do a few things to clean up the mess: - Any condition overriding getMessage() in order to call FORMAT should be removed - getMessage() should be documented *not* to use writeToString() on its own instance - getConditionReport() should be documented not to be overridden, but to override getMessage() instead (maybe declare 'final'?) - Remove all the special methods for classes derived from CONDITION in the print-object.lisp file: they should all fall back to the general method for printing conditions. - Both INVOKE-DEBUGGER-REPORT-CONDITION and Lisp.ERROR should bind the following variables to these listed values, in order to make sure conditions are printed for humans: *print-readably* nil --> all other *print-** variables bound like the values specified for WITH-STANDARD-IO-SYNTAX (except maybe *PRINT-ESCAPE*) The above looks like it should solve our issues. I'd greatly welcome any comments: it's a rather big change, judging by the description above. Ville, you were going to look at it, maybe you can verify if I'm half way right? Bye, Erik.

4 7

[armedbear-devel] Please make getStatus public (thanks :-)
by Didier Verna 18 Jan '11

18 Jan '11

Hello, could you please make the method getStatus from the class ProcessingTerminated public? One need this to mimic what the Main class/function does from /outside/ the ABCL package. Thank you! -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[armedbear-devel] Please make getStatus public (thanks :-)
by Didier Verna 18 Jan '11

18 Jan '11

Hello, could you please make the method getStatus from the class ProcessingTerminated public? One need this to mimic what the Main class/function does from /outside/ the ABCL package. Thank you! -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[armedbear-devel] Another error message enhancement request
by Blake McBride 15 Jan '11

15 Jan '11

I just got the following error: #<THREAD "http-8084-1" {41ABA945}>: Unhandled condition of type SIMPLE-ERROR: The method has the wrong number of required arguments for the generic function. Which method? I have a macro that creates many, many methods. If it gave me the method name I'd be able to track the problem easily. I am embedding ABCL in a very large web application. Starting and stopping the server takes a significant amount of time, and I have no command line access to the code. Giving me the name of the method in question could save me 30 minutes easily. Thanks. Blake McBride

1 0