[armedbear-devel] strange interaction between ql:quickload and ABCL

Anton Vodonosov avodonosov at yandex.ru
Thu Feb 28 02:44:51 UTC 2013


27.02.2013, 13:31, "Mark Evenson" <evenson at 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




More information about the armedbear-devel mailing list