Hi.
I've noticed that when one's program is running, one is still free to use SLIME. However, attempting to evaluate an expression produces the message "Lisp is not ready for requests from the REPL". Pretty understandable, because Lisp can only do one thing at a time. But I was wondering if it is possible to 'fix' this. Ie I would like to be able to inspect variables and redefine functions etc. *while the program is running*. Can SLIME help me do this? Or should I post a question to comp.lang.lisp?
Thanks in advance,
Dirk Gerrits
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jan 13, 2004, at 4:50 PM, Dirk Gerrits wrote:
Hi.
I've noticed that when one's program is running, one is still free to use SLIME. However, attempting to evaluate an expression produces the message "Lisp is not ready for requests from the REPL". Pretty understandable, because Lisp can only do one thing at a time. But I was wondering if it is possible to 'fix' this. Ie I would like to be able to inspect variables and redefine functions etc. *while the program is running*. Can SLIME help me do this? Or should I post a question to comp.lang.lisp?
Thanks in advance,
Dirk Gerrits
Hi,
What you're attempting to do requires threading. There has been work on that, described on the list. You might check the list archives. Hopefully within a month, you should be able to do just that :-)
Brian
- -- Brian Mastenbrook bmastenb@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
Brian Mastenbrook wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jan 13, 2004, at 4:50 PM, Dirk Gerrits wrote:
Hi.
I've noticed that when one's program is running, one is still free to use SLIME. However, attempting to evaluate an expression produces the message "Lisp is not ready for requests from the REPL". Pretty understandable, because Lisp can only do one thing at a time. But I was wondering if it is possible to 'fix' this. Ie I would like to be able to inspect variables and redefine functions etc. *while the program is running*. Can SLIME help me do this? Or should I post a question to comp.lang.lisp?
Thanks in advance,
Dirk Gerrits
Hi,
What you're attempting to do requires threading. There has been work on that, described on the list. You might check the list archives. Hopefully within a month, you should be able to do just that :-)
Threads might be the preferred way, but I'm pretty sure ilisp can do this. I think it just interrupts the current computation, does what you ask, and continues the computation.
I like this feature of ilisp.
Ray
Raymond Toy rtoy@earthlink.net writes:
Threads might be the preferred way, but I'm pretty sure ilisp can do this. I think it just interrupts the current computation, does what you ask, and continues the computation.
Neat idea!
Brian Mastenbrook wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jan 13, 2004, at 4:50 PM, Dirk Gerrits wrote:
[snip]
Ie I would like to be able to inspect variables and redefine functions etc. *while the program is running*. Can SLIME help me do this? Or should I post a question to comp.lang.lisp?
Thanks in advance,
Dirk Gerrits
Hi,
What you're attempting to do requires threading. There has been work on that, described on the list. You might check the list archives. Hopefully within a month, you should be able to do just that :-)
Ah I didn't find this. I guess I didn't look hard enough... But that's great news! I'm anxiously anticipating this. :)
Regards,
Dirk Gerrits
Brian Mastenbrook bmastenb@cs.indiana.edu writes:
What you're attempting to do requires threading. There has been work on that, described on the list. You might check the list archives. Hopefully within a month, you should be able to do just that :-)
I don't think we've discussed a UI that would support what Dirk wants. It sounds like separate threads for REPL and lisp-mode commands. I suppose ELI works like this with thread-per-request.
My UI thoughts so far have been limited to "SLIME uses one thread for requests, but other threads can also do user input/output and enter the debugger". That way SLIME could be used to debug multithreaded programs. I don't know how to handle I/O from threads or how to keep order in Emacs if lots of threads go mad in Lisp - this seems like the main area for experimentation.
Thoughts?
BTW, this morning I got some multithreading working in CMUCL with the new connection-per-thread model. This is different to the previous incarnation in that different threads can talk to Emacs at the same time ("Peter Siebel style" :-)).
I have to understand SERVE-EVENT+threads better before it's usable/checkin'able, but I'll get something to experiment with in this week. Currently one thread seems to "starve" the other even while waiting on I/O, even with the sockets set non-blocking. If I can't fix that quick I'll try SBCL.
-Luke
Luke Gorrie luke@bluetail.com writes:
Brian Mastenbrook bmastenb@cs.indiana.edu writes:
What you're attempting to do requires threading. There has been work on that, described on the list. You might check the list archives. Hopefully within a month, you should be able to do just that :-)
I don't think we've discussed a UI that would support what Dirk wants. It sounds like separate threads for REPL and lisp-mode commands. I suppose ELI works like this with thread-per-request.
My UI thoughts so far have been limited to "SLIME uses one thread for requests, but other threads can also do user input/output and enter the debugger". That way SLIME could be used to debug multithreaded programs. I don't know how to handle I/O from threads or how to keep order in Emacs if lots of threads go mad in Lisp - this seems like the main area for experimentation.
Thoughts?
I'm not sure I understand what you mean by "lots of therads go mad in Lisp". Do you mean, they generate a lot of output. I assumed that each Lisp thread would have a buffer in emacs where it's output went. But maybe you're talking about something else.
BTW, this morning I got some multithreading working in CMUCL with the new connection-per-thread model. This is different to the previous incarnation in that different threads can talk to Emacs at the same time ("Peter Siebel style" :-)).
:-)
-Peter
Luke Gorrie luke@bluetail.com writes:
My UI thoughts so far have been limited to "SLIME uses one thread for requests, but other threads can also do user input/output and enter the debugger". That way SLIME could be used to debug multithreaded programs. I don't know how to handle I/O from threads or how to keep order in Emacs if lots of threads go mad in Lisp - this seems like the main area for experimentation.
Thoughts?
The Lispworks editor seems to create a thread for each evaluation request (commands ala C-x C-e). Well, at least for the first 2 requests. The 3 thread seems to be blocked or delayed. So, when you start 2 endless loops you get 2 threads. The output of both threads is printed in the "Output" buffer. C-g interrupts/stops (not sure) the first thread. Pressing C-g a second time has no effect :-).
Edwin (the Emacs clone in MIT-Scheme) behaves in a similar way. It's customizable if the done an "inferior" thread or in the editor thread itself. The output goes usually to the REPL buffer (that's the moral equivalent to Emacs *scratch*), but this is configurable. Apparently quite a few options; haven't tried them. Debugging multiple threads was very confusing, or at least I was unable to figure out how to do it.
It would probably good if we provide this "evaluation in a separate thread" as an option.
Helmut.
-
Brian Mastenbrook -
Dirk Gerrits -
Helmut Eller -
Luke Gorrie -
Peter Seibel -
Raymond Toy