[Openmcl-devel] Problems with the SLIME debugger

[Gary Byers]

On Fri, 11 Jun 2004, Christian Hofer wrote:

> Hi,
>
> when I'm working with OpenMCL on Darwin, and SLIME, I just cannot
> figure out, how to use the debugger correctly. I just downloaded the
> newest OpenMCL release and the newest SLIME tarball, and the behaviour
> is getting even worse.
>
> E.g. when I try to evaluate the variable test in the listener, I get -
> as expected - the following error:
>
> Unbound variable: TEST
>     [Condition of type UNBOUND-VARIABLE]
>
> Restarts:
>    0: [CONTINUE] Retry getting the value of TEST.
>    1: [USE-VALUE] Specify a value of TEST to use this time.
>    2: [STORE-VALUE] Specify a value of TEST to store and use.
>    3: [ABORT] Abort handling SLIME request.
>    4: [ABORT-BREAK] #<RESTART ABORT-BREAK #x1692E06>
>    5: [ABORT] #<RESTART ABORT #x1692E2E>
>
> Now, none of the aborts seem to work properly. When I chose 3, I get
> the following error:
>
> Undefined function CCL::SIMPLE-RESTART called with arguments () .
>     [Condition of type CCL::UNDEFINED-FUNCTION-CALL]
>
> When I try, on the other hand option 4 or 5, the listener seems to
> loose contact to OpenMCL.
>
> SBCL on FreeBSD behaves completely different and I did not encounter
> any similiar problems.
>
> Thus I wanted to know, if the lost connection is expected behaviour.
> And on the other hand, if I did s.th. wrong during installation or if
> simple-restart does not work at the moment?

CCL::SIMPLE-RESTART isn't a function (it -is- the name of a type of
restart), so if something's calling it as a function it's not too
surprising that it's undefined.  If something's trying to call it as a
function, there would probably have been undefined-function warnings
during compilation; you might want to look at the *INFERIOR-LISP*
buffer to see if it shows any evidence of this.

I tried to reproduce this with the current SLIME from CVS; I found that
restarts 0-2 worked as expected in this case; 3-5 seemed to all lose
the connection, with messages in the *INFERIOR-LISP* buffer to the
effect that some socket used to communicate between Emacs and the lisp
had received an unexpected EOF.  The thread that's running the SLIME
REPL seems to be in:

(defimplementation receive ()
  (let* ((mbox (mailbox ccl:*current-process*))
         (mutex (mailbox.mutex mbox)))
    (ccl:wait-on-semaphore (mailbox.semaphore mbox))
    (ccl:with-lock-grabbed (mutex)
      (pop (mailbox.queue mbox)))))

waiting on a semaphore that'll probably never be signalled (I don't
know much about the protocol SLIME/SWANK use, but I'd guess that
the unexpected EOF has something to do with this ...

Sorry that's not more helpful.

>
> Thanks,
> Chris
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>