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

[armedbear-devel] FLET incorrectly optimized away
by William Wadsworth 26 Jun '10

26 Jun '10

I forgot to indicate that this happens on the current [as of 26/6/2010] trunk version). I can also confirm that MACROLET and SLOT-VALUE are now working as expected. Thanks Erik and Alessio for your efforts. Martin.

1 0

[armedbear-devel] strange asdf behavior with 0.20.0
by Kevin Raison 25 Jun '10

25 Jun '10

I just installed 0.20.0 and am now unable to load usocket, yet I can still load cl-ppcre and other Edi-ware. Upon rolling back to 0.19.1, the same usocket package compiles and loads just fine. I have tried using the binary distribution of 0.20.0 as well as building my own, with the same result. There does not seem to be anything wrong with the usocket package definition itself. Has anyone else seen this or know what is going on? Here is the output of 0.20.0: raison@mercury:~/.abcl/lib$ abcl Armed Bear Common Lisp 0.20.0 Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) Server VM Low-level initialization completed in 0.614 seconds. Startup completed in 1.739 seconds. Type ":help" for a list of available commands. CL-USER(1): (asdf:oos 'asdf:load-op 'usocket) ; loading system definition from /home/raison/.abcl/systems/usocket.asd into #<PACKAGE "ASDF0"> Error loading /home/raison/.abcl/site/usocket-svn/usocket.asd at line 38 (offset 1255) #<THREAD "interpreter" {373E38}>: Debugger invoked on condition of type LOAD-SYSTEM-DEFINITION-ERROR Error while trying to load definition for system usocket from pathname /home/raison/.abcl/systems/usocket.asd: Unrecognized keyword argument :NAME Restarts: 0: TOP-LEVEL Return to top level. [1] USOCKET-SYSTEM(2): -Kevin

4 4

[armedbear-devel] ASDF 2.003
by Faré 25 Jun '10

25 Jun '10

Can ABCL upgrade its ASDF to 2.003 or whichever is latest in the release branch (if possible NOT the master branch)? That would be great. It should fix several bugs that may have hit ABCL users since then. Xach at least reported that upgrading ASDF on ABCL made his software work. As usual, please test on your specific implementation with a few systems before you commit, and please report any bug. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] One good Husband is worth two good Wives; for the scarcer things are, the more they're valued. — Benjamin Franklin

2 1

[armedbear-devel] compiled MACROLET fails to expand in DEFUN/DEFMETHOD forms
by Mark Evenson 22 Jun '10

22 Jun '10

The following form fails to compile correctly: (macrolet ((output-var (var) `(format t "var = ~A~%" ,var))) (defun baz (bat) (output-var bat))) When the above form has been compiled and loaded CL-USER> (baz 3) errors by complaining. The function OUTPUT-VAR is undefined. Interestingly abcl-0.12.0 behaves correctly, but abcl-0.15.0 fails (For some reason, I don't currently have abcl-0.{13,14} handy to test). I distilled this bug down from trying to compile CXML, so this is a "real-world" problem. CXML bombs on compiling its "xml/xml-parse.lisp" at this point: … (macrolet ((with-context ((validator) &body body) `(let ((*ctx* (context ,validator)) (*validate* t)) (with-scratch-pads () ;nicht schoen ,@body)))) (defmethod sax:start-element ((handler validator) uri lname qname attributes) uri lname (with-context (handler) (validate-start-element *ctx* qname) (process-attributes *ctx* qname attributes))) … with Wrong number of arguments for CXML::HANDLER. [Condition of type PROGRAM-ERROR] I assume that my "distilled" version has the same cause, namely that the precompiler is not expanding macros properly for function/method definitions in top-level MACROLET forms, but I explicitly mention my root problem here if the slightly different error turns out to provide a clue that I have missed. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 3

[armedbear-devel] New branch: generic-class-file
by Erik Huelsmann 21 Jun '10

21 Jun '10

Some of you know that I have been working on writing a new class file generator. The new class file generator will be replacing the current version which is strictly written for the current compiler. Due to some of the limitations in the class file generator, I'm not even able to change some patterns I'd like to change in it. The new class file generator will allow much more general class file content. It's the explicit intent to support any method type and argument pattern. This goal will allow us to rewrite runtime-class to use our own class writer. The other purpose is to be able to generate more than two methods in a class file: currently we only support 2 (<init> and one of 8 execute(...) methods). I'd like to be able to have many more; for example I want to move initialization of 'final static' fields to <clinit> to make 100% sure they are only initialized once. But that's just one purpose. Another would be to support multiple &optional parameters (but less than 8) without a need to call fastProcessArgs(), but do it in a much more Java-like fashion by generating multiple execute(...) methods. Each method calls the one with more parameters, until all optionals (which were not provided) have been filled, like this; public LispObject execute() { return execute(default1); } public LispObject execute(LispObject arg1) { return execute(arg1, default2); } public LispObject execute(LispObject arg1, LispObject arg2) { .... do actual processing ...; } I'm creating a README on the branch to say the same, for anybody who comes along but did not read this e-mail. Bye, Erik.

1 0

[armedbear-devel] toplevel MACROLET bug?
by William Wadsworth 21 Jun '10

21 Jun '10

Dear List, Nice work going on on the ABCL compiler. Thanks. I have a file test1.lisp: ----- (in-package #:cl-user) (macrolet ((%mac () '(+ 1 1))) (defun test () (%mac))) ---- Compiling it: CL-USER(1): :cf test1.lisp ; Compiling test1.lisp ... ; (IN-PACKAGE #:CL-USER) ; (DEFUN TEST ...) ; Compilation unit finished ; The following functions were used but not defined: ; %MAC I am not 100% sure, but I think the %MAC should be visible within TEST. --- Martin.

2 1

[armedbear-devel] CL:FLOAT on Java Number objects could call {single, double}Float() on them
by Mario Lang 19 Jun '10

19 Jun '10

Hi. Along the lines of the previously submitted string conversion patch, here is some other possible interoperability thing. Index: src/org/armedbear/lisp/SingleFloat.java =================================================================== --- src/org/armedbear/lisp/SingleFloat.java (revision 12758) +++ src/org/armedbear/lisp/SingleFloat.java (working copy) @@ -635,6 +635,11 @@ return new SingleFloat(((Bignum)obj).floatValue()); if (obj instanceof Ratio) return new SingleFloat(((Ratio)obj).floatValue()); + if (obj instanceof JavaObject) { + final Object jobj = ((JavaObject)obj).getObject(); + if (jobj instanceof Number) + return new SingleFloat(((Number)jobj).floatValue()); + } error(new TypeError("The value " + obj.writeToString() + " cannot be converted to type SINGLE-FLOAT.")); // Not reached. Index: src/org/armedbear/lisp/DoubleFloat.java =================================================================== --- src/org/armedbear/lisp/DoubleFloat.java (revision 12758) +++ src/org/armedbear/lisp/DoubleFloat.java (working copy) @@ -646,6 +646,11 @@ return new DoubleFloat(((SingleFloat)obj).value); if (obj instanceof Ratio) return new DoubleFloat(((Ratio)obj).doubleValue()); + if (obj instanceof JavaObject) { + final Object jobj = ((JavaObject)obj).getObject(); + if (jobj instanceof Number) + return new DoubleFloat(((Number)jobj).doubleValue()); + } error(new TypeError("The value " + obj.writeToString() + " cannot be converted to type DOUBLE-FLOAT.")); // Not reached. P.S.: The following conditional is duplicated and could be removed: Index: src/org/armedbear/lisp/Pathname.java =================================================================== --- src/org/armedbear/lisp/Pathname.java (revision 12758) +++ src/org/armedbear/lisp/Pathname.java (working copy) @@ -1290,7 +1290,7 @@ if (host == NIL) { host = defaults.host; } - if (directory == NIL && defaults != null) { + if (directory == NIL) { directory = defaults.directory; } if (!deviceSupplied) { -- CYa, ⡍⠁⠗⠊⠕

1 0

[armedbear-devel] SLOT-VALUE and SLOT-VALUE-USING-CLASS with DEFSTRUCT
by William Wadsworth 18 Jun '10

18 Jun '10

Hi. The following transcript demonstrates the problem. --- BEGIN Armed Bear Common Lisp 0.20.0 Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.667 seconds. Startup completed in 4.849 seconds. Type ":help" for a list of available commands. CL-USER(1): (defstruct x a b c) X CL-USER(2): (slot-value (make-x :a 10) 'a) #<THREAD "interpreter" {118958E}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function SLOT-VALUE is undefined. Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to SLOT-VALUE. 3: TOP-LEVEL Return to top level. [1] CL-USER(3): :res CL-USER(4): (slot-value (make-x :a 10) 'a) #<THREAD "interpreter" {118958E}>: Debugger invoked on condition of type SIMPLE-ERROR There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION MOP::SLOT-VALUE-USING-CLASS {932FE} > when called with arguments (#<STRUCTURE-CLASS X {11EF443}> #<X {1184326}> A). Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(5): :res CL-USER(6): --- END DEFCLASS seems to work fine, though I would like to keep using DEFSTRUCT. I understand that the MOP is not really complete. However, Is there a workaround that will not resort in using DEFCLASS? --- Martin.

3 5

[armedbear-devel] JVM Compilation
by Mark Evenson 17 Jun '10

17 Jun '10

http://nerds-central.blogspot.com/2009/09/tuning-jvm-for-unusual-uses-have-… Tersely written from my iPod

2 2

Re: [armedbear-devel] SLOT-VALUE and SLOT-VALUE-USING-CLASS with DEFSTRUCT
by William Wadsworth 17 Jun '10

17 Jun '10

Hi Eric, (Apologies for the belated reply, just saw the message today.) On Mon, Jun 14, 2010 at 9:26 PM, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi William, > > Thanks for your report below! > > On Mon, Jun 14, 2010 at 4:09 AM, William Wadsworth > <will.wadsworth.10(a)gmail.com> wrote: >> Hi. >> >> The following transcript demonstrates the problem. >> >> --- BEGIN >> Armed Bear Common Lisp 0.20.0 >> Java 1.6.0_20 Sun Microsystems Inc. >> Java HotSpot(TM) Client VM >> Low-level initialization completed in 0.667 seconds. >> Startup completed in 4.849 seconds. >> Type ":help" for a list of available commands. >> CL-USER(1): (defstruct x a b c) >> X >> CL-USER(2): (slot-value (make-x :a 10) 'a) >> #<THREAD "interpreter" {118958E}>: Debugger invoked on condition of >> type UNDEFINED-FUNCTION >> The function SLOT-VALUE is undefined. > > Well, you seem to have identified an issue here: you're correct our > MOP isn't fully complete, but it's not *that* bad. The function is > defined in clos.lisp. However, loading of that file happens on the > first use of one of the functions inside it. But: there's no trigger > installed on the function to trigger autoloading. > > It seems we need a list of all functions exported from clos.lisp in > order to fix up the auto-loading triggers. Could you create a list > like that? > I don't know whether I read you clearly, but using the following snippet I got the (manually flattened) results below it: (let ((file #P"clos.lisp")) (with-open-file (in file) (loop for form = (read in nil nil) while form when (and (listp form) (eq (car form) 'cl:export)) nconcing (cdr form)))) CLASS-PRECEDENCE-LIST CLASS-SLOTS COMPUTE-APPLICABLE-METHODS COMPUTE-APPLICABLE-METHODS-USING-CLASSES SLOT-DEFINITION-ALLOCATION SLOT-DEFINITION-INITARGS SLOT-DEFINITION-INITFORM SLOT-DEFINITION-INITFUNCTION SLOT-DEFINITION-NAME (Meanwhile, let me see what I can achieve by modifying autoloads.lisp and/or AutoLoads.java?) > > In order to see if a small commit would help you out, I added this > form to the beginning of your transcript: > > (autoload 'slot-value "clos") > --> T > > Turns out that's not all that's required: the next failure I ran into > is that the function either the function SLOT-VALUE is missing a > special case for structures, or SLOT-VALUE-USING-CLASS is missing a > method for structure classes; the error was "No applicable method"... > > Looks like there's no workaround, but maybe there's a quick patch. > I'll need to look into that a bit more. I thought I'd report you my > findings first. > > Thanks again for reporting and welcome to ABCL! > Thanks for the effort you and the rest of the team are putting into it. > > Bye, > > > Erik. > Martin.

1 0