Hi!
I got some trouble running sbcl in the slime environment.
I have the usual SLIME init-file: (setq inferior-lisp-program "/usr/local/bin/sbcl") (add-to-list 'load-path "/usr/local/slime-cvs/slime/") (require 'slime) (slime-setup)
I start SBCL by M-m M-x slime
SLIME does start up, I get a lisp prompt and it seems to behave normally. However, the connection between SBCL and SLIME is rather shaky. At some point during working with SBCL, I lose the function parameter info, I also can't break running code then.
Even more, the function (quit) has no effect whatsoever, i.e. SBCL is not stopped, but I get a message "Evaluation aborted." CL-USER> (quit) ; Evaluation aborted. CL-USER>
That is, I can't just quit SBCL, I have to kill the lisp process when exiting Emacs.
SBCL works normally if invoked in the bash shell.
The inferior-lisp output from SBCL startup is pasted in below.
I run an Ubuntu (debian) linux with kernel 2.6.20-16 on a x86 computer, using Xemacs 21.4 (patch 19), sbcl 1.0.11 and the current slime cvs-build.
I can reproduce the same behavior using Emacs 22.1.1 on the same machine, and on another machine running kernel 2.6.18-5-amd64 with sbcl 0.9.16, the same XEmacs version, and Emacs 21.4.1
The PROBLEMS file states that there is trouble with kernels 2.6.5-2.6.10 (related to multi-threading?), but I'm well beyond that kernel version; also, to my knowledge, I don't use multi-threading. I tried to use nohup in connection with sbcl (as I read that somewhere as well), but I can't get that to work.
Any info or ideas are very much appreciated.
Kai-Florian
This is SBCL 1.0.11, an implementation of ANSI Common Lisp. More information about SBCL is available at http://www.sbcl.org/.
SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. STYLE-WARNING: redefining SB-IMPL::DEFAULT-EXTERNAL-FORMAT in DEFUN * ; loading #P"/usr/local/slime-cvs/slime/swank-loader.lisp" ;; loading #P"/home/slobo/.slime/fasl/2007-11-06/sbcl-1.0.11-linux-x86/swank-backend.fasl" ;; loading #P"/home/slobo/.slime/fasl/2007-11-06/sbcl-1.0.11-linux-x86/nregex.fasl" ;; loading #P"/home/slobo/.slime/fasl/2007-11-06/sbcl-1.0.11-linux-x86/swank-source-path-parser.fasl" ;; loading #P"/home/slobo/.slime/fasl/2007-11-06/sbcl-1.0.11-linux-x86/swank-source-file-cache.fasl" ;; loading #P"/home/slobo/.slime/fasl/2007-11-06/sbcl-1.0.11-linux-x86/swank-sbcl.fasl" ;; loading #P"/home/slobo/.slime/fasl/2007-11-06/sbcl-1.0.11-linux-x86/swank-gray.fasl" STYLE-WARNING: implicitly creating new generic function STREAM-READ-CHAR-WILL-HANG-P ;; loading #P"/home/slobo/.slime/fasl/2007-11-06/sbcl-1.0.11-linux-x86/swank.fasl" WARNING: These Swank interfaces are unimplemented: (CALLS-WHO DISASSEMBLE-FRAME SLDB-BREAK-AT-START SLDB-BREAK-ON-RETURN WHO-SPECIALIZES) ;; Swank started at port: 41489. 41489 *
* Kai-Florian Richter [2007-11-13 23:00+0100] writes:
SLIME does start up, I get a lisp prompt and it seems to behave normally. However, the connection between SBCL and SLIME is rather shaky. At some point during working with SBCL, I lose the function parameter info, I also can't break running code then.
Without further context, it's hard to say what problem you are seeing. There are plenty of ways to screw things up :-) Not everything is SLIME's fault.
If you can't interrupt running code, save the contents of the *slime-events* buffer. That's often useful for debugging SLIME.
Even more, the function (quit) has no effect whatsoever, i.e. SBCL is not stopped, but I get a message "Evaluation aborted." CL-USER> (quit) ; Evaluation aborted. CL-USER>
I think that QUIT in SBCL terminates the current thread only, unless it is called in the initial thread. SLIME starts a new listener thread if the old was killed (that's sometimes nice, but sometimes not). The second prompt above is a bit irritating, because at that time there is no REPL thread, a new one is created for the next request.
That is, I can't just quit SBCL, I have to kill the lisp process when exiting Emacs.
You could try sb-int:unix-exit or the REPL shortcut `, quit' which is the same as `M-x slime-quit-lisp'.
The PROBLEMS file states that there is trouble with kernels 2.6.5-2.6.10 (related to multi-threading?), but I'm well beyond that kernel version; also, to my knowledge, I don't use multi-threading. I tried to use nohup in connection with sbcl (as I read that somewhere as well), but I can't get that to work.
For SBCL/x86 we use threads by default. You could change that with with swank:*communication-style*, but the alternatives are usually worse.
Helmut.
Hi again!
SLIME does start up, I get a lisp prompt and it seems to behave normally. However, the connection between SBCL and SLIME is rather shaky. At some point during working with SBCL, I lose the function parameter info, I also can't break running code then.
Without further context, it's hard to say what problem you are seeing. There are plenty of ways to screw things up :-) Not everything is SLIME's fault.
Well, I don't doubt that. And I tried to provide as much context as possible, but oh well...
If you can't interrupt running code, save the contents of the *slime-events* buffer. That's often useful for debugging SLIME.
I will as soon as SLIME/SBCL reaches that state again. Hasn't happened all day.
Even more, the function (quit) has no effect whatsoever, i.e. SBCL is not stopped, but I get a message "Evaluation aborted." CL-USER> (quit) ; Evaluation aborted. CL-USER>
I think that QUIT in SBCL terminates the current thread only, unless it is called in the initial thread. SLIME starts a new listener thread if the old was killed (that's sometimes nice, but sometimes not). The second prompt above is a bit irritating, because at that time there is no REPL thread, a new one is created for the next request.
Looking at the output below, this seems to be the case. The current thread is "repl-thread", if I type in (quit) it is killed and immediately replaced by "new-repl-thread". That is, either SLIME or SBCL (which I doubt) seems to catch and prevent this quit. BTW, in the new "repl-thread" everyting I defined before is known as well, i.e. all symbols, functions etc. are still defined. It is as if nothing happened.
(swank-backend:current-thread) #<SB-THREAD:THREAD "repl-thread" {A7ED6D1}> CL-USER> (swank-backend:all-threads) (#<SB-THREAD:THREAD "repl-thread" {A7ED6D1}> #<SB-THREAD:THREAD "reader-thread" {A7ED5F1}> #<SB-THREAD:THREAD "control-thread" {A7ED509}> #<SB-THREAD:THREAD "auto-flush-thread" {A7ED339}> #<SB-THREAD:THREAD "initial thread" {A6DD731}>) CL-USER> (quit) ; Evaluation aborted. CL-USER> (swank-backend:all-threads) (#<SB-THREAD:THREAD "new-repl-thread" {A96B239}> #<SB-THREAD:THREAD "reader-thread" {A7ED5F1}> #<SB-THREAD:THREAD "control-thread" {A7ED509}> #<SB-THREAD:THREAD "auto-flush-thread" {A7ED339}> #<SB-THREAD:THREAD "initial thread" {A6DD731}>) CL-USER>
That is, I can't just quit SBCL, I have to kill the lisp process when exiting Emacs.
You could try sb-int:unix-exit or the REPL shortcut `, quit' which is the same as `M-x slime-quit-lisp'.
unix-exit is in package sb-unix, but apart from that it works; ,quit as well. And (sb-ext:quit :recklessly-p t) as well. So, for quitting I just need to change my habbits, it seems :)
For SBCL/x86 we use threads by default. You could change that with with swank:*communication-style*, but the alternatives are usually worse.
Mmmh, considering that it works most of the time that doesn't sound like a great idea :)
Kai-Florian
-
Helmut Eller -
Kai-Florian Richter