This problem does not have an actual error message in the REPL, so it's starting to frustrate me a bit.
Loading a couple of large projects from the terminal/REPL works fine, but doing the same operation from SLIME stops, without an error, and with an unresponsive REPL. It never gives an error, or returns control to the prompt. Sometimes the cpu is pegged at 98+% on the sbcl process.
; registering #<SYSTEM :CHUNGA {12B70199}> as CHUNGA ; loading system definition from ; /Users/jonathon/.sbcl/systems/cl-base64.asd into #<PACKAGE "ASDF0"> ; registering #<SYSTEM CL-BASE64 {132F7299}> as CL-BASE64 ; registering #<SYSTEM CL-BASE64-TESTS {1343A3A9}> as CL-BASE64-TESTS ; loading system definition from /Users/jonathon/.sbcl/systems/puri.asd ; into #<PACKAGE "ASDF0"> ; registering #<SYSTEM PURI {136D4251}> as PURI ; registering #<SYSTEM PURI-TESTS {13823489}> as PURI-TESTS ; loading system definition from ; /Users/jonathon/.sbcl/systems/cl-ppcre.asd into #<PACKAGE "ASDF0"> ; registering #<SYSTEM :CL-PPCRE {128692F1}> as CL-PPCRE
CL-USER> 0
* jcm@sdf.lonestar.org [2008-12-17 13:59+0100] writes:
This problem does not have an actual error message in the REPL, so it's starting to frustrate me a bit.
Loading a couple of large projects from the terminal/REPL works fine, but doing the same operation from SLIME stops, without an error, and with an unresponsive REPL. It never gives an error, or returns control to the prompt. Sometimes the cpu is pegged at 98+% on the sbcl process.
This sounds like this problem: http://permalink.gmane.org/gmane.lisp.steel-bank.devel/12464
OTOH, SBCL shouldn't consume so much CPU time if it's deadlocked.
Does the problem also occur if you set SWANK:*COMMUNICATION-STYLE* to something other than :spawn ? Also keep an eye on the *inferior-lisp* buffer; it might contain some error message.
Helmut.
- jcm@sdf.lonestar.org [2008-12-17 13:59+0100] writes:
This problem does not have an actual error message in the REPL, so it's starting to frustrate me a bit.
Loading a couple of large projects from the terminal/REPL works fine, but doing the same operation from SLIME stops, without an error, and with an unresponsive REPL. It never gives an error, or returns control to the prompt. Sometimes the cpu is pegged at 98+% on the sbcl process.
This sounds like this problem: http://permalink.gmane.org/gmane.lisp.steel-bank.devel/12464
OTOH, SBCL shouldn't consume so much CPU time if it's deadlocked.
Does the problem also occur if you set SWANK:*COMMUNICATION-STYLE* to something other than :spawn ? Also keep an eye on the *inferior-lisp* buffer; it might contain some error message.
Actually, I rolled back to the previous official release of SBCL and that solved the problem for now. But maybe I'll cvs up to HEAD and try these other settings.
On Fri, Dec 19, 2008 at 4:58 AM, jcm@sdf.lonestar.org wrote:
Actually, I rolled back to the previous official release of SBCL and that solved the problem for now. But maybe I'll cvs up to HEAD and try these other settings.
Current CVS HEAD should work with :SPAWN as well -- at least as well as it ever did. The way repl-thread talks to Emacs still deadlock prone in theory, but I haven't been able to actually deadlock it since 1.0.23.42.
Cheers,
-- Nikodemus
On Fri, Dec 19, 2008 at 4:58 AM, jcm@sdf.lonestar.org wrote:
Actually, I rolled back to the previous official release of SBCL and that solved the problem for now. But maybe I'll cvs up to HEAD and try these other settings.
Current CVS HEAD should work with :SPAWN as well -- at least as well as it ever did. The way repl-thread talks to Emacs still deadlock prone in theory, but I haven't been able to actually deadlock it since 1.0.23.42.
I rebuilt HEAD, and startup works, but slime-edit-definition will hang when the definition is in another file. So I changed slime-communication-style to :sigio for now, and that seems to work.
On Fri, Dec 19, 2008 at 2:16 PM, jcm@sdf.lonestar.org wrote:
I rebuilt HEAD, and startup works, but slime-edit-definition will hang when the definition is in another file. So I changed slime-communication-style to :sigio for now, and that seems to work.
Will look at this. Thanks for the heads-up.
Cheers,
-- Nikodemus
-
Helmut Eller -
jcm＠sdf.lonestar.org -
Nikodemus Siivola