[slime-devel] Re: OpenMCL

[Luke Gorrie]

Helmut Eller <e9626484 at stud3.tuwien.ac.at> writes:

> > One of the reasons that we like SLIME so much is the fact that it
> > doesn't choke on asynchroneous output (as ILISP does): when working
> > with a multithreaded server that makes all the difference in the
> > world. The output that non-evaluator threads write to stdout goes to
> > the inferior lisp buffer, we can live with that, but maybe it would be
> > nicer if (optionally) that output was inserted in the normal SLIME
> > REPL buffer (maybe in some other color) - is that possible, maybe the
> > behavior is different on other platforms ?
> 
> That's not yet implemented :-) SLIME is currently only able to talk to
> a single thread.  We hope that we can support this in the future, but
> progress is a bit slow in this direction.

I can do some multiprocessing hacking this weekend.

Here is how I envision "phase 1":

  There is just one thread that SLIME uses for normal requests
  (fetching arglists, evaluation with C-c : or in *slime-repl*, etc
  etc etc). This is just like today, and in a single-threaded system
  this would be the only thread.

  Printed output from other threads can be sent to Emacs. It will be
  inserted into e.g. *slime-repl* in a different colour.

  Other threads can ask to be debugged by SLIME. A small signalling
  protocol would be used to tell Emacs "thread <x> has entered the
  debugger - please debug it when you're ready." The user could then
  see which threads are waiting to be debugged and attach the SLIME
  debugger to them.

Only the debugger would interact with these other threads.

I'm thinking of a user interface similar to the one in Distel (a
"SLIME for Erlang"). There you have a buffer listing all the threads
(erlang "processes") that are waiting to be debugged, like this:
  http://www.bluetail.com/~luke/misc/erlang/dbg-monitor.png

This "monitor" buffer automatically pops up when a new thread becomes
debugable.

If you select a thread with RET or a mouse click, the debugger gets
attached to it. You can either debug it to completion, or just partly
debug it and pop back into the monitor to do something else while it
waits. The attached debugger is like the *sldb* buffer, in Distel it
looks like this:
  http://www.bluetail.com/~luke/misc/erlang/dbg-attach.png
  (The red lines indicate breakpoints.)

How does that sound?

There are more possible features that I think of as "phase 2", such as
multiple *slime-repl* buffers each talking to different threads. I'm
sure we can learn a lot from ELI when we come to that point. Are there
also some ELI features that we should get familiar with for "phase 1"?

Cheers,
Luke