Re: [j-devel] Complete backtrace from ABCL/SLIME bug with compilernotes

[Mark E. <mar...@gm...>]

Alex Mizrahi wrote:

> MOP::INITIAL-DISCRIMINATING-FUNCTION is called only for the first time -- it 
> computes discriminating-function via std-compute-discriminating-function and 
> calls it. next time discriminating function will be called directly.
> my theory is that std-compute-discriminating-function produces some junk.
> 
>  ME> What's frustrating is that from the REPL
>  ME> SWANK-BACKEND> (setf c (make-condition 'compiler-condition))
> 
> when i did that i was able to get a normal backtrace just as yours -- before 
> that it barfed to REPL, most likely because it was not able to print 
> compiler-condition correctly and got recursive error.

That's good news.  A reproducible test-case outside of the SLIME code 
would be a great first step.

Where are the discriminating functions "stored"?  On a property list off 
of some symbol or is there some special MOP variable that keeps the 
lookup list?  Being able to clear the definition to re-try the test case 
without restarting ABCL would be a great second step.  I have started to 
read 'clos.lisp', but my attention wanders as I try to take in the whole 
majestics entrails of code that is the Belly of the Bear.

> my backtrace was even more detailed:
> 
> The value #<SWANK-BACKEND:COMPILER-CONDITION {EFC0EE}> is not of type NIL.
>    [Condition of type SIMPLE-TYPE-ERROR]
> 
> i think this error comes from broken discriminating function.
> 
>  ME> SWANK-BACKEND> (describe c )
>  ME>    ORIGINAL-CONDITION   unbound
>  ME>    SEVERITY             NIL
>  ME>    MESSAGE              NIL
> 
> i have unbound slots here, possibly different SLIME version..

Sometimes I get that sort of error as well.  Sometimes a complaint about 
a "Cannot compile CONSTANT-FUNCTION".

[...]

> so, my theory is that recursive compilation mutilates this function placing 
> NIL instead of class.
> however, when i change this piece to display something else, it doesn't 
> help -- still same error.

Interesting, but I don't understand why this would be a case of 
recursive compilation.  The inheritance graph of COMPILE-CONDITION seems 
pretty straightforward.

COMPILER-CONDITION-->CONDITION-->STANDARD-OBJECT-->T


-- 
<Mar...@gm...>

"[T]his is not a disentanglement from, but a progressive knotting into."