Hi;
When I first started using Slime I was using CMUCL. One of the features I really appreciated was that when running a program under Slime I could modify and recompile a defun and it would take effect the next time it was called by the running program. I subsequently switched to using SBCL, but when I did I seemed to lose this ability to recompile while running. The C-c C-c commands would queue up an not execute until the program finished.
But recently I setup Hunchentoot daemon with Swank in a core image that when run allows me to slime-connect, and when I do so I find that I can recompile stuff and have it take effect without killing the running process. This makes me wonder if there isn't some way to do this under Slime after all.
Clearly I don't fully understand the interactions between Slime, Swank and the inferior lisp. Is there another way I can launch SBCL from within Slime so it works the way CMUCL used to?
Thanks.
--Jeff
On Nov 22, 2007, at 1:05 PM, Jeff Cunningham wrote:
Clearly I don't fully understand the interactions between Slime, Swank and the inferior lisp. Is there another way I can launch SBCL from within Slime so it works the way CMUCL used to?
SBCL and SLIME work for me exactly as you described. The only time that queueing sometimes does not work is if I start a Hunchentoot server without threads enabled. Otherwise, I can interact with my Lisp environment by REPL or C-c C-c (this is on OS X).
John
* Jeff Cunningham [2007-11-22 18:05+0100] writes:
Clearly I don't fully understand the interactions between Slime, Swank and the inferior lisp. Is there another way I can launch SBCL from within Slime so it works the way CMUCL used to?
If you set swank:*communication-style* to :sigio you should get the same behavior. :sigio is a bit dangerous though, because most code isn't reentrant and it's possible that data-structures are in a inconsistent state when the interrupt occurs. And :sigio isn't very useful if your application uses threads.
As a safer alternative you could stop and debug the thread with `M-x slime-list-threads' and pressing d in the right line. If you press : in the debugger buffer, you can evaluate an expression in the debugged thread.
C-c C-c in source buffers usually spawns a new thread. If you (re)compile a defun it's visible in all threads. Setting a global variable is of course also visible in all threads. The new value is not visible in those threads which have a local dynamic binding for the variable. (You can set those local bindings in the debugger.)
Also note that SBCL can optimize tail recursive functions to loops, i.e. a thread executing such a loop never calls the new definition.
Helmut.
-
Helmut Eller -
Jeff Cunningham -
John Wiegley