Alain.Picard@memetrics.com writes:
CL-USER 3 : 1 > :b
Call to SWANK::SWANK-DEBUGGER-HOOK Call to INVOKE-DEBUGGER Call to SWANK::FORCE-USER-OUTPUT Call to SWANK:EVAL-STRING Call to FUNCALL Call to SWANK::READ-FROM-EMACS Call to SWANK::READ-USER-INPUT-FROM-EMACS Call to (SUBFUNCTION 1 SWANK::CREATE-CONNECTION) Call to (METHOD STREAM:STREAM-READ-CHAR (SWANK::SLIME-INPUT-STREAM)) Call to IO::READ-OBJECT Call to IO::RECURSIVE-READ Call to READ-PRESERVING-WHITESPACE Call to EDITOR:RUBBER-READ-A-COMMAND Call to (SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK)
CL-USER 4 : 1 >
It seems that *DISPATCHING-CONNECTION* isn't properly bound. Is this backtrace from the same thread that created the initial connection or a from another thread? Do you use some form of tail call optimization?
SWANK::CURRENT-CONNECTION contains some special code for SBCL perhaps we need something similar for Lispworks.
I think there are fewer problems if I _first_ start multiprocessing, _then_ create a swank-server, then use slime-connect from emacs. But that's not nearly as convenient as just typing M-x slime. :-)
Emacs starts multiprocessing for you if set slime-multiprocessing to t.
Helmut.