Helmut Eller e9626484@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