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

[Mark Evenson]

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."