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

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

[armedbear-devel] How to .... generate abcl-diff9.html?
by Erik Huelsmann 30 Mar '13

30 Mar '13

Hi Anton, The test run has completed. How do I generate a new difference report? Bye, Erik.

2 1

[armedbear-devel] test results for 1.2.0-dev
by Anton Vodonosov 29 Mar '13

29 Mar '13

Hello. Got the test results from Erik's machine few days ago, but only now have time to report them to the mailing list. Comparison of 1.1.1 and 1.2.0-dev on quicklisp 2013-03-12: http://common-lisp.net/project/cl-test-grid/abcl/abcl-diff3.html It doesn't present big difference as I hoped, because closer-mop now compiles on any version of ABCL, including 1.1.1. Maybe runtime behavior will be different, but we have no test suites which highlight this difference. Note some regressions: uiop, metacopy-with-contextl, xcvb-bridge. I haven't analyzed what is the cause. Probably something ASDF-related. To give you sense of ABCL progress, here is the report comparing ABCL 1.1.1 on two quicklisps: 2013-02-17 and 2013-03-12: http://common-lisp.net/project/cl-test-grid/abcl/abcl-diff4.html As you see, much more libraries compile OK in new quicklisp. Note, these two quicklisps were tested on different machines, and the later quicklisp was tested with absence of gcc. This explains failure of cl-gss for example, which can be ignored. Pay attention to some CRASH results in new quicklisp. These crashes reproduce in 1.2.0-dev too and are caused by various errors in ABCL (like index out of bounds, assertion failed). Command line to reproduce it at the cl-test-grid.cloud.efficito.com machine, as user testgrid: rm -r .cache/common-lisp/ java -XX:MaxPermSize=1024m -jar /home/testgrid/lisps/abcl/dist/abcl.jar --noinit --nosystem --batch --eval '(require :abcl-contrib)' --load /home/testgrid/quicklisp/setup.lisp --eval '(ql:quickload :cl-l10n)' > log 2>&1 Finally, here is the load failures report for 1.2.0-dev: http://common-lisp.net/project/cl-test-grid/abcl/abcl-1-2-0-load-failures.h… Recall, that the default sorting in this report tries to present on top the libraries fixing which will give bigger "outcome". More detailed explanation of the report columns is here: https://github.com/cl-test-grid/cl-test-grid/tree/master/reporting#combinin… As you see, there are several directions to dig further, depending on what you are more interested to start with. Let me know what other reports you want to see, or what configurations to test, or how to reproduce certain errors. Best regards, - Anton

3 17

[armedbear-devel] Fwd: cl-l10n: GETENV on ABCL
by Erik Huelsmann 26 Mar '13

26 Mar '13

---------- Forwarded message ---------- From: Attila Lendvai <attila.lendvai(a)gmail.com> Date: Tue, Mar 26, 2013 at 6:28 AM Subject: Re: cl-l10n: GETENV on ABCL To: Erik Huelsmann <ehuels(a)gmail.com> Cc: Armed Bear <armedbear-devel(a)common-lisp.net> hi Erik, > cl-l10n seems to lack a GETENV for ABCL. > Could you use the the function > EXT:GETENV for it? sure, pushed. thanks! -- attila Notice the erosion of your (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39

1 0

[armedbear-devel] Bordeaux-threads test hangs
by Erik Huelsmann 25 Mar '13

25 Mar '13

>From a mail by Stellian Ionescu: From: Stelian Ionescu <sionescu(a)cddr.org> To: armedbear-devel(a)common-lisp.net Cc: Date: Sat, 23 Mar 2013 01:07:04 +0000 (UTC) Subject: Bordeaux-threads test hangs The B-T test suite hangs on test "condition-variable". If I do a ^C ABCL exits, so I'm not sure how to debug it. CL-USER(1): (lisp-implementation-version) "1.1.1" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_17-b02" "amd64-Linux-3.7.10-10-default"

4 5

[armedbear-devel] cl-l10n: GETENV on ABCL
by Erik Huelsmann 24 Mar '13

24 Mar '13

Hi Attila, cl-l10n wants to use GETENV. Now that ABCL seems to support closer-mop rather well, we're testing many more libraries to see if they're loading correctly on ABCL. cl-l10n seems to lack a GETENV for ABCL. Could you use the the function EXT:GETENV for it? Example: (ext:getenv "PATH") --> "some path string" Or NIL if no env var by the given name exists. Thanks in advance! Bye, Erik.

1 0