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

[armedbear-devel] REMOVE CACHES: r14460 changes FASL entry point name
by Erik Huelsmann 03 Apr '13

03 Apr '13

Hi all, Commits between r14456 and r14460 change the FASL entry point name. Everybody tracking trunk will need to blow their caches away. Bye, Erik.

1 0

[armedbear-devel] Patch for ASDF2.26.32 to support concatenated fasls for ABCL
by Erik Huelsmann 03 Apr '13

03 Apr '13

Hi! In order for these commands to generate a fasl per ASDF system, I had to apply the patch below to ASDF. $ ./abcl CL-USER(1): :ld c:/users/erik/quicklisp/setup CL-USER(2): (ql:quickload :bordeaux-threads) CL-USER(3): (asdf:oos 'asdf:binary-op :bordeax-threads) The commands above work with current trunk (r14460) and produces 2 concatenated fasls in my cache directory: 1 for alexandria and 1 for bordeaux-threads. This patch is required (also attached, to prevent line wrapping): diff --git a/bundle.lisp b/bundle.lisp index 568f894..24fbf90 100644 --- a/bundle.lisp +++ b/bundle.lisp @@ -185,7 +185,7 @@ (or #+ecl (or (equalp type (compile-file-type :type :object)) (equalp type (compile-file-type :type :static-library))) #+mkcl (equalp type (compile-file-type :fasl-p nil)) - #+(or allegro clisp clozure cmu lispworks sbcl scl xcl) (equalp type (compile-file-type))))) + #+(or abcl allegro clisp clozure cmu lispworks sbcl scl xcl) (equalp type (compile-file-type))))) (defgeneric* (trivial-system-p) (component)) diff --git a/uiop/lisp-build.lisp b/uiop/lisp-build.lisp index e2e376d..4b7e819 100644 --- a/uiop/lisp-build.lisp +++ b/uiop/lisp-build.lisp @@ -669,11 +669,12 @@ it will filter them appropriately." ;;; Links FASLs together (with-upgradability () (defun combine-fasls (inputs output) - #-(or allegro clisp clozure cmu lispworks sbcl scl xcl) + #-(or abcl allegro clisp clozure cmu lispworks sbcl scl xcl) (error "~A does not support ~S~%inputs ~S~%output ~S" (implementation-type) 'combine-fasls inputs output) #+clozure (ccl:fasl-concatenate output inputs :if-exists :supersede) #+(or allegro clisp cmu sbcl scl xcl) (concatenate-files inputs output) + #+abcl (sys:concatenate-fasls inputs output) #+lispworks (let (fasls) (unwind-protect

1 0

[armedbear-devel] Support for concatenated fasls
by Erik Huelsmann 03 Apr '13

03 Apr '13

Hi! As we discussed, I'd write FASL concatenation support for ABCL. I'm nearly done, however I'm running into a snag caused by ASDF: Normally, a file "package.lisp" is compiled into a fasl "package.abcl" which is basically a zip with at least one entry: "package._". The "._" file contains instructions for loading the fasl and may contain references to other files in the same zip. My FASL concatenation code currently uses the assumption that the "._" file has exactly the same name as the enclosing package. However, FASLs generated using ASDF violate that assumption: the ._ file in the fasl isn't called "package._" but it's called "package-ASDF_TMP._". How does ABCL know about the suffix when ASDF is loading the FASL "package.abcl" with the suffixed file in it in the regular situation? Bye, Erik.

2 2

[armedbear-devel] bug in format ~f
by Carlos Ungil 03 Apr '13

03 Apr '13

Hello, comparing output from different implementations I've found the following (minor) bug: > (format t "~,2f" 0.999) 1.0 ;; should be 1.00 I think there is a problem here as well: > (format t "~5f" 0.00000001) .0000 ;; should print " 0.0" Only SBCL gives the output I would expect, most implementations print ".0000" as ABCL does. From the HyperSpec 22.3.3.1: "If the parameter d is omitted, then there is no constraint on the number of digits to appear after the decimal point. A value is chosen for d in such a way that as many digits as possible may be printed subject to the width constraint imposed by the parameter w and the constraint that ___no trailing zero digits may appear in the fraction, except that if the fraction to be printed is zero, then a single zero digit should appear after the decimal point___ if permitted by the width constraint." This problem appears only when the value is close to zero, otherwise the output is fine: > (format t "~5f" 1.00000001) 1.0 ;; OK I guess those zero digits are not considered trailing because there is no non-zero digit before but I think the specification still requires the fraction to be printed with a single zero digit after the decimal point. Regards, Carlos Ungil

2 1

[armedbear-devel] Other findings (was Re: Questions about r14452 (Fix cl-cont))
by Erik Huelsmann 02 Apr '13

02 Apr '13

> Well, to some extent I can see your problem. Indeed there seem to be no > slots in the 'MOP:FUNCALLABLE-STANDARD-OBJECT class. The > layoutFuncallableStandardClass is what confused me, but that's indeed the > layout of the metaclass. > > So, you're correct that the fix works by accident. The solution should be > to add a slot by the name 'MOP::NAME to the FUNCALLABLE-STANDARD-OBJECT. > That slot can contain the name of the object (ie function) for which the > item is defined. In that case, we should probably remove the direct slot > MOP::NAME on the standard generic function, since it's already defined on > the superclass if we decide to do that. > > While studying this problem using DESCRIBE, it seems our current implementation dispatches (DESCRIBE (MAKE-INSTANCE 'CL-CONT::FUNCALLABLE/CC)) the wrong way: to the T way instead of the STANDARD-OBJECT way... Yet more to investigate... Bye, Erik.

2 2

Re: [armedbear-devel] Questions about r14452 (Fix cl-cont)
by Rudolf Schlatte 02 Apr '13

02 Apr '13

What makes me suspicious is the output of (describe (make-instance 'funcallable-standard-object)) vs (describe (make-instance 'standard-generic-function)) . There's a layout called layoutFuncallableStandardClass, defined in StandardClass.java, which has NAME as first slot, but that's for class objects with metaclass funcallable-standard-class, not for instances of these classes. I'll think a bit in the next days and try to either resolve my doubts or come up with another fix for the problem. Maybe I'm simply confused; wouldn't be the first time. :) Rudi On Apr 2, 2013, at 19:52, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi Rudi, > > Basically the expectation we violated was the fact that %set-lambda-name didn't want to take a funcallable instance as its function argument. The commit changed that and used the first slot of the funcallable instance class layout (called NAME) to store the name. I guess we forget to finalize the class somewhere, so the spots don't appear? > > Bye, > > Erik. > > sent from my phone > > On Apr 2, 2013 7:32 PM, "Rudolf Schlatte" <rudi(a)constantly.at> wrote: > Hi, > > I suspect that the changes in commit r14452 only work by accident. > > The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs FuncallableStandardObject are no problem, since the latter simply isn't used anywhere. But the new methods getName() and setName() assume that a) the FuncallableStandardObject instance has at least one slot, and b) that slot holds a name. Since > (class-slots (find-class 'funcallable-standard-object)) > returns NIL, these assumptions hold only when the objects are in fact generic functions. > > Amusingly, > (function-lambda-expression (make-instance 'funcallable-standard-object)) > runs into the type error on line 2666 of Primitives.lisp ("The value #<FUNCALLABLE-STANDARD-OBJECT {665C5A83}> is not of type FUNCTION.") even though > (typep (make-instance 'funcallable-standard-object) 'function) => T > so I can't trigger the array-out-of-bounds error right now. > > Could I have a recipe for triggering the bug? I'd like to see how cl-cont uses funcallable-standard-objects, and what expectations we violate. I believe I can fix this properly. > > Cheers, > > Rudi >

2 2

Re: [armedbear-devel] Questions about r14452 (Fix cl-cont)
by Erik Huelsmann 02 Apr '13

02 Apr '13

Forgot to mention: Pre 14452 it was enough to just quickload cl-cont to trigger the bug. Bye, Erik sent from my phone On Apr 2, 2013 7:52 PM, "Erik Huelsmann" <ehuels(a)gmail.com> wrote: > Hi Rudi, > > Basically the expectation we violated was the fact that %set-lambda-name > didn't want to take a funcallable instance as its function argument. The > commit changed that and used the first slot of the funcallable instance > class layout (called NAME) to store the name. I guess we forget to finalize > the class somewhere, so the spots don't appear? > > Bye, > > Erik. > > sent from my phone > On Apr 2, 2013 7:32 PM, "Rudolf Schlatte" <rudi(a)constantly.at> wrote: > >> Hi, >> >> I suspect that the changes in commit r14452 only work by accident. >> >> The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs >> FuncallableStandardObject are no problem, since the latter simply isn't >> used anywhere. But the new methods getName() and setName() assume that a) >> the FuncallableStandardObject instance has at least one slot, and b) that >> slot holds a name. Since >> (class-slots (find-class 'funcallable-standard-object)) >> returns NIL, these assumptions hold only when the objects are in fact >> generic functions. >> >> Amusingly, >> (function-lambda-expression (make-instance >> 'funcallable-standard-object)) >> runs into the type error on line 2666 of Primitives.lisp ("The value >> #<FUNCALLABLE-STANDARD-OBJECT {665C5A83}> is not of type FUNCTION.") even >> though >> (typep (make-instance 'funcallable-standard-object) 'function) => T >> so I can't trigger the array-out-of-bounds error right now. >> >> Could I have a recipe for triggering the bug? I'd like to see how >> cl-cont uses funcallable-standard-objects, and what expectations we >> violate. I believe I can fix this properly. >> >> Cheers, >> >> Rudi >> >>

1 0

[armedbear-devel] Fwd: Re: Questions about r14452 (Fix cl-cont)
by Erik Huelsmann 02 Apr '13

02 Apr '13

sent from my phone ---------- Forwarded message ---------- From: ehuels(a)gmail.com Date: Apr 2, 2013 7:51 PM Subject: Re: Questions about r14452 (Fix cl-cont) To: Rudolf Schlatte <rudi(a)constantly.at> Cc: Hi Rudi, Basically the expectation we violated was the fact that %set-lambda-name didn't want to take a funcallable instance as its function argument. The commit changed that and used the first slot of the funcallable instance class layout (called NAME) to store the name. I guess we forget to finalize the class somewhere, so the spots don't appear? Bye, Erik. sent from my phone On Apr 2, 2013 7:32 PM, "Rudolf Schlatte" <rudi(a)constantly.at> wrote: Hi, I suspect that the changes in commit r14452 only work by accident. The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs FuncallableStandardObject are no problem, since the latter simply isn't used anywhere. But the new methods getName() and setName() assume that a) the FuncallableStandardObject instance has at least one slot, and b) that slot holds a name. Since (class-slots (find-class 'funcallable-standard-object)) returns NIL, these assumptions hold only when the objects are in fact generic functions. Amusingly, (function-lambda-expression (make-instance 'funcallable-standard-object)) runs into the type error on line 2666 of Primitives.lisp ("The value #<FUNCALLABLE-STANDARD-OBJECT {665C5A83}> is not of type FUNCTION.") even though (typep (make-instance 'funcallable-standard-object) 'function) => T so I can't trigger the array-out-of-bounds error right now. Could I have a recipe for triggering the bug? I'd like to see how cl-cont uses funcallable-standard-objects, and what expectations we violate. I believe I can fix this properly. Cheers, Rudi

1 0

[armedbear-devel] Questions about r14452 (Fix cl-cont)
by Rudolf Schlatte 02 Apr '13

02 Apr '13

Hi, I suspect that the changes in commit r14452 only work by accident. The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs FuncallableStandardObject are no problem, since the latter simply isn't used anywhere. But the new methods getName() and setName() assume that a) the FuncallableStandardObject instance has at least one slot, and b) that slot holds a name. Since (class-slots (find-class 'funcallable-standard-object)) returns NIL, these assumptions hold only when the objects are in fact generic functions. Amusingly, (function-lambda-expression (make-instance 'funcallable-standard-object)) runs into the type error on line 2666 of Primitives.lisp ("The value #<FUNCALLABLE-STANDARD-OBJECT {665C5A83}> is not of type FUNCTION.") even though (typep (make-instance 'funcallable-standard-object) 'function) => T so I can't trigger the array-out-of-bounds error right now. Could I have a recipe for triggering the bug? I'd like to see how cl-cont uses funcallable-standard-objects, and what expectations we violate. I believe I can fix this properly. Cheers, Rudi

1 0

[armedbear-devel] Using ASDF/BUNDLE for ABCL
by Erik Huelsmann 01 Apr '13

01 Apr '13

Hi, Some time ago Mark Evenson created ASDF-JAR on ABCL. It has some issues packaging ASD files which uses #. syntax to read e.g. version files (version.lisp-sexp) such as bordeaux-threads does. We know ECL started hooking into the ASDF/BUNDLE machinery for ASDF to overcome problems like these. Could you help me/us out and explain how we can plug ABCL into the same machinery? From what I've seen, it's most efficient if the resulting code be committed to ASDF. That's fine by me. At this point, I'd just be happy with an explanation on how to do the hooking up: the new ASDF/BUNDLE functionality doesn't seem to be documented in the manual yet. Thanks for any help you may be able to provide! Bye, Erik.

2 3