[armedbear-devel] strange interaction between ql:quickload and ABCL
Hello. I have very strange behaviour of ql:quickload that I observer only on ABCL. It happens when I run (ql:quickload :modf). Precondition: the system :modf is NOT installed into quicklisp.
java -jar abcl.jar --noinit --nosystem
Armed Bear Common Lisp 1.1.0 Java 1.6.0_26 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.945 seconds. Startup completed in 4.8 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "C:\\Users\\anton\\quicklisp\\setup.lisp") T CL-USER(2): (ql:quickload :modf) Error loading C:/Users/anton/quicklisp/dists/quicklisp/software/closer-mop-20130128-darcs/closer-mop.asd at line 43 (offset 1649) #<THREAD "interpreter" {40773F4B}>: Debugger invoked on condition of type LOAD-SYSTEM-DEFINITION-ERROR Error while trying to load definition for system closer-mop from pathname C:/Users/anton/quicklisp/dists/quicklisp/software/closer-mop-20130128 -darcs/closer-mop.asd: Unrecognized keyword argument ("closer-mop-packages" "closer-mop-shared") Restarts: 0: REINITIALIZE-SOURCE-REGISTRY-AND-RETRY Retry finding system closer-mop after reinitializing the source-registry. 1: ABORT Give up on "modf" 2: TOP-LEVEL Return to top level. [1] ASDF0(3): As you see it is trying to load closer-mop. Why? If :modf ASDF is not available, quicklisp should not load anything other systems yet. Moreover, modf.asd has :depends-on (:alexandria #-abcl :closer-mop :iterate) So on ABCL it does not depend on closer-mop. I got backtrace using this command: [1] ASDF0(3): (with-open-file (stream "C:\\Users\\anton\\unpacked\\abcl\\abcl-bin-1.1.0\\backtrace.txt" :direction :output :if-exists :supersede :if-does-not-exist :create) (let ((*debug-io* stream)) (top-level::backtrace-command "10000"))) The resulting file is here: https://dl.dropbox.com/u/5708042/backtrace.txt. @abcl dvelopers: this backtrace seem to contain not only the current invocation stack, but also previous calls, already finished. For example the (LOAD "C:\\Users\\anton\\quicklisp\\setup.lisp") at the very bottom of the file. Do I retrieve backtrace incorrectly? Back to the ql:quickload problem. I know that if I install :modf with CCL, this problem doesn't happen anymore, and ABCL can load it. Zach, how it works? Best regards, - Anton
On 2/27/13 0402 , Anton Vodonosov wrote:
Hello.
I have very strange behaviour of ql:quickload that I observer only on ABCL. It happens when I run (ql:quickload :modf). Precondition: the system :modf is NOT installed into quicklisp.
java -jar abcl.jar --noinit --nosystem
Armed Bear Common Lisp 1.1.0 Java 1.6.0_26 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.945 seconds. Startup completed in 4.8 seconds. Type ":help" for a list of available commands.
CL-USER(1): (load "C:\\Users\\anton\\quicklisp\\setup.lisp") T CL-USER(2): (ql:quickload :modf)
Unfortunately, I cannot reproduce this error either with abcl-1.1.0 or abcl-1.2.0-dev using quicklisp 2013-02-17 running on UNIX (oi-151a7). In the process of updating my virtualized Windows 7 instance to see if that makes a difference. […]
The resulting file is here: https://dl.dropbox.com/u/5708042/backtrace.txt.
@abcl dvelopers: this backtrace seem to contain not only the current invocation stack, but also previous calls, already finished. For example the (LOAD "C:\\Users\\anton\\quicklisp\\setup.lisp") at the very bottom of the file. Do I retrieve backtrace incorrectly?
The ABCL backtrace is simply a linked list which is pushed/popped by the implementation every time a Lisp frame is executed and sometimes a Java frame, so under certain conditions, typically when running under SLIME, one gets this sort of result for reasons that have never been very clear to me. So, yes, you seem to have retrieved the backtrace correctly. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
27.02.2013, 13:31, "Mark Evenson" <evenson@panix.com>:
Unfortunately, I cannot reproduce this error either with abcl-1.1.0 or abcl-1.2.0-dev using quicklisp 2013-02-17 running on UNIX (oi-151a7).
Well, I wasn't clear about preconditions. It reproduces on quicklisp 2013-01-28 when :closer-mop is already installed into quicklisp but :modf is not yet. Here are complete steps to reproduces (tested with abcl-1.1.0): # install quicklisp wget http://beta.quicklisp.org/quicklisp.lisp (ql-dist:install-dist "http://beta.quicklisp.org/dist/quicklisp/2013-01-28/distinfo.txt" :replace t :prompt nil) java -jar abcl.jar --noinit --nosystem --batch --load quicklisp.lisp --eval "(quicklisp-quickstart:install :path \"quicklisp2/\")" --eval "(ql-dist:install-dist \"http://beta.quicklisp.org/dist/quicklisp/2013-01-28/distinfo.txt\" :replace t :prompt nil)" # fetch closer-mop (doesn't matter that this closer-mop doesn't work on ABCL, we only want to install it) # works the same if closer-mop is installed with another lisp: java -jar abcl.jar --noinit --nosystem --batch --load quicklisp2/setup.lisp --eval "(ql:quickload :closer-mop)" # finally, reproduce the problem java -jar abcl.jar --noinit --nosystem --noinform --load quicklisp2/setup.lisp CL-USER(1): (ql:quickload :modf) Error loading C:/Users/anton/unpacked/abcl/abcl-bin-1.1.0/quicklisp2/dists/quicklisp/software/closer-mop-20130128-darcs/closer-mop.asd at line 43 ....
The ABCL backtrace is simply a linked list which is pushed/popped by the implementation every time a Lisp frame is executed and sometimes a Java frame, so under certain conditions, typically when running under SLIME, one gets this sort of result for reasons that have never been very clear to me.
To me it looks like the entries are sometimes not popped, as the stack contains many frames from previous calls, which are exited already. Zach, so how it works? From this test case it looks like when :modf is not installed, quicklisp is trying to first load the :modf dependencies based on quicklisp own knowledge about dependencies. But once :modf is already installed, quicklisp just loads :modf via ASDF. I always though quicklisp works other way: fetch and unpack the :modf tarball, try to load modf.asd and handle all asdf:missing-component conditions by installing the missing libraries. If it would work so, it would never try to load :closer-mop as modf.asd has #-abcl :closer-mop. The actual behaviour I see is that quicklisp doesn't even try to fetch :modf. Is it by design? Best regards, - Anton
On 2/28/13 0344 , Anton Vodonosov wrote:
27.02.2013, 13:31, "Mark Evenson" <evenson@panix.com>:
Unfortunately, I cannot reproduce this error either with abcl-1.1.0 or abcl-1.2.0-dev using quicklisp 2013-02-17 running on UNIX (oi-151a7).
Well, I wasn't clear about preconditions. It reproduces on quicklisp 2013-01-28 when :closer-mop is already installed into quicklisp but :modf is not yet.
Here are complete steps to reproduces (tested with abcl-1.1.0):
# install quicklisp wget http://beta.quicklisp.org/quicklisp.lisp (ql-dist:install-dist "http://beta.quicklisp.org/dist/quicklisp/2013-01-28/distinfo.txt" :replace t :prompt nil) java -jar abcl.jar --noinit --nosystem --batch --load quicklisp.lisp --eval "(quicklisp-quickstart:install :path \"quicklisp2/\")" --eval "(ql-dist:install-dist \"http://beta.quicklisp.org/dist/quicklisp/2013-01-28/distinfo.txt\" :replace t :prompt nil)"
# fetch closer-mop (doesn't matter that this closer-mop doesn't work on ABCL, we only want to install it) # works the same if closer-mop is installed with another lisp: java -jar abcl.jar --noinit --nosystem --batch --load quicklisp2/setup.lisp --eval "(ql:quickload :closer-mop)"
# finally, reproduce the problem java -jar abcl.jar --noinit --nosystem --noinform --load quicklisp2/setup.lisp CL-USER(1): (ql:quickload :modf)
Error loading C:/Users/anton/unpacked/abcl/abcl-bin-1.1.0/quicklisp2/dists/quicklisp/software/closer-mop-20130128-darcs/closer-mop.asd at line 43 ....
With the information that we're trying this against the "historical" 2013-01-28 Quicklisp, I was able to reproduce your error for abcl-1.1.0 and abcl-1.1.1, while abcl-1.2.0-dev doesn't give this error. So, for some reason, the version of ASDF shipped with abcl-1.1.x (asdf-2.26.6) has a incorrect interaction with the Quicklisp 2013-01-28 dist information whereas abcl-1.2.x (currently asdf-2.30) does not. The abcl-1.1.x version is attempting to load the CLOSER-MOP dependency for MODF in spite of the #-abcl conditional in modf.asd, seems to indicate that Quicklisp is somehow not actually loading the form. Looking at quicklisp/dists/quicklisp/systems.txt which I take to be the dependency graph, I notice that both Quicklisp 2013-02-17 and 2013-01-28 list CLOSER-MOP as a dependency of MODF, which is reasonable as this list is presumably prepared with SBCL which would ignore the #-abcl conditional in modf.asd. Therefore, I speculate that Quicklisp with ASDF-2.30 somehow actually evals the form in modf.asd whereas Quicklisp with ASDF-2.26.6 uses the information parsed from the Quicklisp 2013-01-28 dist information. Why this bad interaction doesn't happen with asdf-2.26.6 on the Quicklisp 2013-02-17 information remains mysterious. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
28.02.2013, 14:45, "Mark Evenson" <evenson@panix.com>:
Therefore, I speculate that Quicklisp with ASDF-2.30 somehow actually evals the form in modf.asd
Important nuance is that modf is not even downloaded by quicklisp, so modf.asd is absent at the time when the error happens
Mark Evenson <evenson@panix.com> writes:
Looking at quicklisp/dists/quicklisp/systems.txt which I take to be the dependency graph, I notice that both Quicklisp 2013-02-17 and 2013-01-28 list CLOSER-MOP as a dependency of MODF, which is reasonable as this list is presumably prepared with SBCL which would ignore the #-abcl conditional in modf.asd. Therefore, I speculate that Quicklisp with ASDF-2.30 somehow actually evals the form in modf.asd whereas Quicklisp with ASDF-2.26.6 uses the information parsed from the Quicklisp 2013-01-28 dist information. Why this bad interaction doesn't happen with asdf-2.26.6 on the Quicklisp 2013-02-17 information remains mysterious.
For reference, systems.txt is used as a guide for what projects to pre-fetch, but it is not used to make loading decisions. Not all projects that are fetched are loaded, and projects that are not fetched might be fetched on demand in the missing-dependency handler. Zach
participants (3)
-
Anton Vodonosov -
Mark Evenson -
Zach Beane