Testing ASDF found several bugs in ABCL.
cd ~/cl/asdf/
abcl --noinform --eval '(or`#.(load(string`|test/script-support.lisp|)`:verbose():print())#.(asdf-test::exit-lisp`0))' Failed to require LOOP because 'Illegal function object: (bqv).'
Maximum error depth exceeded (11 nested errors) with 'Illegal function object: (bqv).'.
abcl --noinform --eval "(or'#.(load(string'|test/script-support.lisp|):verbose():print())#.(asdf-test::exit-lisp'0))"
So your backquote parser is broken somehow.
Also, upgrading from ASDF 2.25 or 2.26 used to work, but not anymore. Now 2.27 is needed (as configured in header.lisp, and tested with make u l=abcl ASDF_UPGRADE_TEST_TAGS=2.25).
Finally, there are many instances of abcl in #+ or #- in the test/ directory, including two new ones in test-bundle on Mac (which is a regression from abcl 1.1.0) and in test-stamp-propagation (which is a new test, and a bug shared with XCL).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Not all Law is created equal before Man. Some Law causes least conflict and least perverse incentives. By definition we call it Natural Law.
On 22/10/13 2026 , Faré wrote:
Testing ASDF found several bugs in ABCL.
cd ~/cl/asdf/
abcl --noinform --eval '(or`#.(load(string`|test/script-support.lisp|)`:verbose():print())#.(asdf-test::exit-lisp`0))' Failed to require LOOP because 'Illegal function object: (bqv).'
Maximum error depth exceeded (11 nested errors) with 'Illegal function object: (bqv).'.
abcl --noinform --eval "(or'#.(load(string'|test/script-support.lisp|):verbose():print())#.(asdf-test::exit-lisp'0))"
So your backquote parser is broken somehow.
[…]
Nope, not our backquote parser but [traced down to problems in how `--eval` arguments are evaluated][#334].
[#334]: http://abcl.org/trac/ticket/334
Thanks for the bugs…
On Nov 5, 2013, at 12:38, Mark Evenson evenson@panix.com wrote:
On 22/10/13 2026 , Faré wrote:
Testing ASDF found several bugs in ABCL.
cd ~/cl/asdf/
abcl --noinform --eval '(or`#.(load(string`|test/script-support.lisp|)`:verbose():print())#.(asdf-test::exit-lisp`0))' Failed to require LOOP because 'Illegal function object: (bqv).'
Maximum error depth exceeded (11 nested errors) with 'Illegal function object: (bqv).'.
abcl --noinform --eval "(or'#.(load(string'|test/script-support.lisp|):verbose():print())#.(asdf-test::exit-lisp'0))"
So your backquote parser is broken somehow.
[…]
Nope, not our backquote parser but [traced down to problems in how `--eval` arguments are evaluated][#334].
Yes, it was our backquote parser: fixed in [r14591][]. Now, on to the real ASDF bugs…
[r14591]: http://abcl.org/trac/changeset/14591
On Oct 22, 2013, at 20:26, Faré fahree@gmail.com wrote:
Testing ASDF found several bugs in ABCL.
cd ~/cl/asdf/
abcl --noinform --eval '(or`#.(load(string`|test/script-support.lisp|)`:verbose():print())#.(asdf-test::exit-lisp`0))' Failed to require LOOP because 'Illegal function object: (bqv).'
Maximum error depth exceeded (11 nested errors) with 'Illegal function object: (bqv).'.
abcl --noinform --eval "(or'#.(load(string'|test/script-support.lisp|):verbose():print())#.(asdf-test::exit-lisp'0))"
So your backquote parser is broken somehow.
I have confirmed this bug on my end.
I would file a ticket for this, but we are in the process of moving abcl.org to another machine with better connectivity, so am trying to get that finished (famous last words: “next day or two”) before updating state that will need to be resynced.
Also, upgrading from ASDF 2.25 or 2.26 used to work, but not anymore. Now 2.27 is needed (as configured in header.lisp, and tested with make u l=abcl ASDF_UPGRADE_TEST_TAGS=2.25).
Hmm.
make u l=abcl ASDF_UPGRADE_TEST_TAGS=2.25
works for me with an ASDF at git version
commit 10fa87ab70d7db14b45ad822558382fe3dad4540 Author: Francois-Rene Rideau tunes@google.com Date: Tue Oct 22 23:43:42 2013 -0400
Debian release for 3.0.3 (Also, slight update to web page.)
on ABCL of
"1.3.0-dev" "Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-1.7.0_45-b18" "x86_64-Mac_OS_X-10.9”
How can we narrow the possibilities for why it works for me, but not for you?
Finally, there are many instances of abcl in #+ or #- in the test/ directory, including two new ones in test-bundle on Mac (which is a regression from abcl 1.1.0) and in test-stamp-propagation (which is a new test, and a bug shared with XCL).
That’s an implicit invitation for help quashing bugs, right? Probably I do not have the cycles to help for your impending release, but will throw it on my TODO stack.
--
"A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
Dear Mark,
On Wed, Oct 23, 2013 at 8:23 AM, Mark Evenson evenson@panix.com wrote:
On Oct 22, 2013, at 20:26, Faré fahree@gmail.com wrote:
Testing ASDF found several bugs in ABCL.
cd ~/cl/asdf/
abcl --noinform --eval '(or`#.(load(string`|test/script-support.lisp|)`:verbose():print())#.(asdf-test::exit-lisp`0))' Failed to require LOOP because 'Illegal function object: (bqv).'
Maximum error depth exceeded (11 nested errors) with 'Illegal function object: (bqv).'.
abcl --noinform --eval "(or'#.(load(string'|test/script-support.lisp|):verbose():print())#.(asdf-test::exit-lisp'0))"
So your backquote parser is broken somehow.
I have confirmed this bug on my end.
I would file a ticket for this, but we are in the process of moving abcl.org to another machine with better connectivity, so am trying to get that finished (famous last words: “next day or two”) before updating state that will need to be resynced.
OK. Now is two days later. Are things ready to file a bug?
make u l=abcl ASDF_UPGRADE_TEST_TAGS=2.25works for me with an ASDF at git version
commit 10fa87ab70d7db14b45ad822558382fe3dad4540
Did you change the constant 2.27 to 2.25 near the bottom of header.lisp? I bumped it to 2.27 so that on older versions, it will just rename away package ASDF. But things used to work with 2.25 (strangely, not 2.24, if I trust myself to have put 2.25 for a good reason, though I don't see what could have tripped ABCL in the diff from 2.24 to 2.25)
I get the following error, now with a semi-useful backtrace:
TEST ABORTED: The slot ASDF/BACKWARD-INTERFACE:ON-WARNINGS is missing from the class #<STANDARD-CLASS ASDF/LISP-ACTION:COMPILE-OP {3CEB7830}>. ... (ERROR "The slot ~S is missing from the class ~S." ASDF/BACKWARD-INTERFACE:ON-WARNINGS #<STANDARD-CLASS ASDF/LISP-ACTION:COMPILE-OP {3CEB7830}>) (#<FUNCTION {31B8C5E3}> #<STANDARD-CLASS ASDF/LISP-ACTION:COMPILE-OP {3CEB7830}> #<ASDF/LISP-ACTION:COMPILE-OP > ASDF/BACKWARD-INTERFACE:ON-WARNINGS SLOT-VALUE) (APPLY #<FUNCTION {31B8C5E3}> (#<STANDARD-CLASS ASDF/LISP-ACTION:COMPILE-OP {3CEB7830}> #<ASDF/LISP-ACTION:COMPILE-OP > ASDF/BACKWARD-INTERFACE:ON-WARNINGS SLOT-VALUE)) (#<FUNCTION {29F01381}> (#<STANDARD-CLASS ASDF/LISP-ACTION:COMPILE-OP {3CEB7830}> #<ASDF/LISP-ACTION:COMPILE-OP > ASDF/BACKWARD-INTERFACE:ON-WARNINGS SLOT-VALUE)) (SYSTEM:STD-SLOT-VALUE #<ASDF/LISP-ACTION:COMPILE-OP > ASDF/BACKWARD-INTERFACE:ON-WARNINGS) (#<FUNCTION {4A8270D7}> (#<ASDF/LISP-ACTION:COMPILE-OP >)) (#<STANDARD-GENERIC-FUNCTION ASDF/BACKWARD-INTERFACE:OPERATION-ON-WARNINGS {70B125BD}> #<ASDF/LISP-ACTION:COMPILE-OP >) (#<FUNCTION {4E5FD9FB}> (#<ASDF/LISP-ACTION:COMPILE-OP > #<ASDF/LISP-ACTION:CL-SOURCE-FILE "asdf" "build" "asdf">)) (#<STANDARD-GENERIC-FUNCTION ASDF/ACTION:PERFORM {5C8032DF}> #<ASDF/LISP-ACTION:COMPILE-OP > #<ASDF/LISP-ACTION:CL-SOURCE-FILE "asdf" "build" "asdf">) ... upgrade FAILED for abcl from 2.25 using method 'load-asdf-lisp'load-asdf-system you can retry just that test with: ASDF_UPGRADE_TEST_TAGS="2.25" ASDF_UPGRADE_TEST_METHODS="'load-asdf-lisp'load-asdf-system" ./test/run-tests.sh -u abcl or more interactively (and maybe with rlwrap or in emacs), start with: abcl --noinit --nosystem --noinform then copy/paste: (load "test/script-support.lisp") (asdf-test::da) (test-upgrade 'load-asdf-lisp'load-asdf-system "2.25")
How can we narrow the possibilities for why it works for me, but not for you?
Note that some of the upgrade scenarios work. In this scenario, we load the old version 2.25 as a lisp file, then use it to load version 3.1.0.2 as a system, and it fails. The probable cause is that we are using an object of class COMPILE-OP, but class COMPILE-OP itself is redefined, and more subtly, the name of the slot, as a symbol, is rehomed from package ASDF to package ASDF/LISP-ACTION.
You might have recently changed the way you represent lisp objects or classes as java objects or classes, making the assumption that symbols naming slots will never change package. This assumption is incorrect. Symbols can be made to not have a package anymore, or to have a new package home. The ASDF upgrade from before 2.27 relies on that.
NB: I'm still using Armed Bear Common Lisp 1.2.1 Java 1.6.0_27 Sun Microsystems Inc. OpenJDK 64-Bit Server VM
Finally, there are many instances of abcl in #+ or #- in the test/ directory, including two new ones in test-bundle on Mac (which is a regression from abcl 1.1.0) and in test-stamp-propagation (which is a new test, and a bug shared with XCL).
That’s an implicit invitation for help quashing bugs, right? Probably I do not have the cycles to help for your impending release, but will throw it on my TODO stack.
Yes. There are probably ABCL bugs lurking that cause test-bundle and test-stamp-propagation to fail.
The test-bundle issue only appears on Mac. To trigger it, disable the #+(and darwin (or abcl ecl))
To If you get to test-stamp-propagation, you have to (defparameter asdf::*asdf-cache* nil) and disable the #+(or abcl xcl) to trigger the bug, which is possibly due to some wrongful caching in file-write-date by the runtime.
Regards,
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Hi! I'm a signature virus. Copy me into your sig file and help me spread!
On Oct 25, 2013, at 7:06, Faré fahree@gmail.com wrote:
I would file a ticket for this, but we are in the process of moving abcl.org to another machine with better connectivity, so am trying to get that finished (famous last words: “next day or two”) before updating state that will need to be resynced.
OK. Now is two days later. Are things ready to file a bug?
No, unfortunately, things are still not ready. I’m no longer going to give an ETA on the move other than “soon”, but rest assured that I haven’t forgotten this.
[…]
While testing on Windows, two tests revealed a bug in ABCL: test-nested-components.script test-system-pathnames.script Unsupported case in TRANSLATE-DIRECTORY-COMPONENTS. Is there a good way to get a useful backtrace? We used: (let ((*debug-io* stream)) (top-level::backtrace-command count)) and it yielded no output (count bound to nil, stream to the log file).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The Keyboard is mightier than the Death Ray...
On Tue, Oct 22, 2013 at 2:26 PM, Faré fahree@gmail.com wrote:
Testing ASDF found several bugs in ABCL.
cd ~/cl/asdf/
abcl --noinform --eval '(or`#.(load(string`|test/script-support.lisp|)`:verbose():print())#.(asdf-test::exit-lisp`0))' Failed to require LOOP because 'Illegal function object: (bqv).'
Maximum error depth exceeded (11 nested errors) with 'Illegal function object: (bqv).'.
abcl --noinform --eval "(or'#.(load(string'|test/script-support.lisp|):verbose():print())#.(asdf-test::exit-lisp'0))"
So your backquote parser is broken somehow.
Also, upgrading from ASDF 2.25 or 2.26 used to work, but not anymore. Now 2.27 is needed (as configured in header.lisp, and tested with make u l=abcl ASDF_UPGRADE_TEST_TAGS=2.25).
Finally, there are many instances of abcl in #+ or #- in the test/ directory, including two new ones in test-bundle on Mac (which is a regression from abcl 1.1.0) and in test-stamp-propagation (which is a new test, and a bug shared with XCL).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Not all Law is created equal before Man. Some Law causes least conflict and least perverse incentives. By definition we call it Natural Law.
On Oct 23, 2013, at 2:47, Faré fahree@gmail.com wrote:
While testing on Windows, two tests revealed a bug in ABCL: test-nested-components.script test-system-pathnames.script Unsupported case in TRANSLATE-DIRECTORY-COMPONENTS. Is there a good way to get a useful backtrace? We used: (let ((*debug-io* stream)) (top-level::backtrace-command count)) and it yielded no output (count bound to nil, stream to the log file).
SYS:BACKTRACE is the official interface. See examples of usages in SLIME’s `swank-abcl.lisp`, lines 351++.
If you [look at the implementation of TOP-LEVEL::BACKTRACE-COMMAND][1], you will see that it is merely interrogating the undocumented special EXT:*SAVED-BACKTRACE*, which is set when CL:INVOKE-DEBUGGER is triggered, so for examining the state of your program it is probably not that useful.
[1]: http://abcl.org/trac/browser/trunk/abcl/src/org/armedbear/lisp/top-level.lis...
I can confirm your failure via the shell script entry point, but I had problems trying to run the tests interactively.
I updated “~/work/asdf/“ to the latest rev from git, and invoked ‘make’ to concatenate ASDF into ‘asdf.lisp.
From an ABCL under SLIME started with `—-noinit` with working directory `asdf/test/`, evaluating the form
'(#.(load "script-support.lisp") #.(asdf-test::da) #.(load-asdf) #.(frob-packages) #.(load "test-nested-components”))
gives me the error that “test-nested-components” can’t be loaded. Indeed there is nothing loadable there:
CL-USER> (directory "/Users/evenson/work/asdf/test/test-nested-components*") (#P"/Users/evenson/work/asdf/test/test-nested-components.script" #P"/Users/evenson/work/asdf/test/test-nested-components-1.asd”)
What triggers the creation of of the loadable file? Do I need to initialize something else to look at this interactively?
--
"A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
SYS:BACKTRACE is the official interface. See examples of usages in SLIME’s `swank-abcl.lisp`, lines 351++.
Excellent. I committed something using it in uiop/image.lisp — it's probably rough, but at least it's informative.
I can confirm your failure via the shell script entry point, but I had problems trying to run the tests interactively.
I updated “~/work/asdf/“ to the latest rev from git, and invoked ‘make’ to concatenate ASDF into ‘asdf.lisp.
From an ABCL under SLIME started with `—-noinit` with working directory `asdf/test/`, evaluating the form
'(#.(load "script-support.lisp") #.(asdf-test::da) #.(load-asdf) #.(frob-packages) #.(load "test-nested-components”))
That final load should be (load "test-nested-components.script”) It's a weird bug if the script suggested otherwise.
Note that it's working for me on Linux x64. The bug report was for Windows.
make t l=abcl t='test-nested-components.script test-system-pathnames.script'
What triggers the creation of of the loadable file? Do I need to initialize something else to look at this interactively?
The .script files are loadable, after script-support.lisp has been loaded and initialized, as above.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Theists think all gods but theirs are false. Atheists simply don't make an exception for the last one.
armedbear-devel@common-lisp.net
-
Faré -
Mark Evenson