[slime-devel] Re: OpenMCL

[Peter Seibel]

Luke Gorrie <luke at bluetail.com> writes:

> Peter Seibel <peter at javamonkey.com> writes:
> 
> > Are you planning to make it possible to debug multiple threads
> > simultaneously--I.e. it might be nice to set break points in two
> > places that will be hit be different threads and then debug them both
> > at the same time (in two different debugging buffers); for example
> > step a little way in one thread, then switch to the other; etc.
> 
> Not initially. Is that something you need?

Not initially. ;-)

> This is slightly tricky in SLIME because we support a synchronous
> evaluation interface in Emacs Lisp. In Elisp you can write:
> 
>     (slime-eval '(swank:some-function))
> 
> And it will evaluate the form in Lisp and then return the
> result. However, it might enter the debugger before it finishes, in
> which case Emacs enters a "recursive edit" to do the debugging without
> unwinding the Elisp stack (so that when you finish debugging it can
> return the final result to the `slime-eval' call). If during debugging
> you switched over to another thread and did another `slime-eval'
> there, the stack would end up rather tangled -- you have two
> `slime-eval's on the stack and have to return to one before the other.
>
> A few possible solutions come to mind, but I think it will be better
> to burn this bridge when we come to it and do some experimentation.
> Ideas are always welcome, of course.

Hmmm. I'm pretty ignorant of the details of recursive edits. Which
gives me the advantage of not knowing what's hard. ;-) Here's how I
was envisioning it: when I pick a thread to debug from the list of
debuggable therads SLIME creates a new buffer for interacting with
that thread. I switch between threads by switching between buffers.
Thus I can C-x 2 to split my window and put one thread-buffer in each
window and switch back and forth with C-x o. Peeking at the info page
for recursive edits I see this:

   In general, we try to minimize the use of recursive editing levels
  in GNU Emacs. This is because they constrain you to "go back" in a
  particular order--from the innermost level toward the top level.
  When possible, we present different activities in separate buffers
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  so that you can switch between them as you please.Some commands
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  switch to a new major mode which provides a command to switch back.
  These approaches give you more flexibility to go back to unfinished
  tasks in the order you choose.

I'm not sure I grok all the implications of that underlined portion
but it sort of sounds like if you were following that advice instead
of debugging in a recursive edit you'd debug in a new buffer. Which
you might switch to automatically if you're interacting with the Lisp
synchronously.

-Peter

-- 
Peter Seibel                                      peter at javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp