Hi!
Today I noticed that there seem to be significant problems with AllegroCL (I'm using 7.0 pro on both Windows and Linux) and completion. SLIME is current from CVS.
For me the problem is reproducible like that:
1. The TAB key is bound to slime-indent-and-complete-symbol.
2. In the REPL buffer type, say,
(use-package :d
3. Now, with the cursor after the "d" type TAB several times in a row very fast.
This suffices to completely trash everything for me. On Windows, Emacs goes up to 60% CPU usage and doesn't react anymore, on Linux AllegroCL goes up to 95% CPU usage.
Any ideas?
Thanks, Edi.
On Mon, 10 Oct 2005 01:49:07 +0200, Edi Weitz edi@agharta.de wrote:
Today I noticed that there seem to be significant problems with AllegroCL (I'm using 7.0 pro on both Windows and Linux) and completion. SLIME is current from CVS.
For me the problem is reproducible like that:
The TAB key is bound to slime-indent-and-complete-symbol.
In the REPL buffer type, say,
(use-package :d
Now, with the cursor after the "d" type TAB several times in a row very fast.
This suffices to completely trash everything for me. On Windows, Emacs goes up to 60% CPU usage and doesn't react anymore, on Linux AllegroCL goes up to 95% CPU usage.
I tried to debug this myself this morning and haven't really found anything yet. However, SLIME's (or maybe AllegroCL's) behaviour at the moment is really erratic and makes it kind of hard to work with it.
For example, all of the stuff below happened in the SLIME REPL buffer without the SLIME debugger popping up and without me typing anything in between:
Warning: stream-unread-char: ignoring #\null (expected #:) Previous error: An allocation request for 268435480 bytes caused a need for 536870912 more bytes of heap. The operating system will not make the space available because the address space reserved for the heap could not be increased. [Current process: repl-thread] [1] CL-USER(7): :pop
Warning: stream-unread-char: ignoring #\null (expected #:)
Error: An allocation request for 268435480 bytes caused a need for 536870912 more bytes of heap. The operating system will not make the space available because the address space reserved for the heap could not be increased. [condition type: STORAGE-CONDITION]
Restart actions (select using :continue): 0: Abort handling SLIME request. 1: Abort entirely from this (lisp) process. [Current process: new-repl-thread] [1] CL-USER(1):
Error: An allocation request for 536870936 bytes caused a need for 1610612736 more bytes of heap. The operating system will not make the space available because the address space reserved for the heap could not be increased. [condition type: STORAGE-CONDITION]
Restart actions (select using :continue): 0: Return to sldb level 2. 1: Abort reading input from Emacs. 2: Return to Debug Level 1 (an "abort" restart). 3: Abort handling SLIME request. 4: Abort entirely from this (lisp) process. [Current process: new-repl-thread] [2] CL-USER(2):
Error: An allocation request for 536870936 bytes caused a need for 1610612736 more bytes of heap. The operating system will not make the space available because the address space reserved for the heap could not be increased. [condition type: STORAGE-CONDITION]
Restart actions (select using :continue): 0: Abort reading input from Emacs. 1: Return to Debug Level 2 (an "abort" restart). 2: Return to sldb level 2. 3: Abort reading input from Emacs. 4: Return to Debug Level 1 (an "abort" restart). 5: Abort handling SLIME request. 6: Abort entirely from this (lisp) process. [Current process: new-repl-thread] [3] CL-USER(3):
Error: An allocation request for 536870936 bytes caused tenuring and a need for 413401088 more bytes of heap. The operating system will not make the space available because the address space reserved for the heap could not be increased. [condition type: STORAGE-CONDITION]
Restart actions (select using :continue): 0: Abort reading input from Emacs. 1: Return to Debug Level 3 (an "abort" restart). 2: Abort reading input from Emacs. 3: Return to Debug Level 2 (an "abort" restart). 4: Return to sldb level 2. 5: Abort reading input from Emacs. 6: Return to Debug Level 1 (an "abort" restart). 7: Abort handling SLIME request. 8: Abort entirely from this (lisp) process. [Current process: new-repl-thread] [4] CL-USER(4):
Error: An allocation request for 536870936 bytes caused tenuring and a need for 413401088 more bytes of heap. The operating system will not make the space available because the address space reserved for the heap could not be increased. [condition type: STORAGE-CONDITION]
Restart actions (select using :continue): 0: Abort reading input from Emacs. 1: Return to Debug Level 4 (an "abort" restart). 2: Abort reading input from Emacs. 3: Return to Debug Level 3 (an "abort" restart). 4: Abort reading input from Emacs. 5: Return to Debug Level 2 (an "abort" restart). 6: Return to sldb level 2. 7: Abort reading input from Emacs. 8: Return to Debug Level 1 (an "abort" restart). 9: Abort handling SLIME request. 10: Abort entirely from this (lisp) process. [Current process: new-repl-thread] [5] CL-USER(5): Warning: stream-unread-char: ignoring #\null (expected #\Newline)
[Current process: new-repl-thread] [1] CL-USER(5):
Error: An allocation request for 536870936 bytes caused tenuring and a need for 413401088 more bytes of heap. The operating system will not make the space available because the address space reserved for the heap could not be increased. [condition type: STORAGE-CONDITION]
Restart actions (select using :continue): 0: Abort reading input from Emacs. 1: Return to Debug Level 1 (an "abort" restart). 2: Abort handling SLIME request. 3: Abort entirely from this (lisp) process. [Current process: new-repl-thread] [2] CL-USER(6):
* Edi Weitz [2005-10-10 10:14+0200] writes:
I tried to debug this myself this morning and haven't really found anything yet. However, SLIME's (or maybe AllegroCL's) behaviour at the moment is really erratic and makes it kind of hard to work with it.
Does this also happen if you set:
(setq slime-complete-symbol-function 'slime-simple-complete-symbol)
?
On Mon, 10 Oct 2005 10:53:29 +0200, Helmut Eller heller@common-lisp.net wrote:
Does this also happen if you set:
(setq slime-complete-symbol-function 'slime-simple-complete-symbol)
?
Yes. In fact, this is obviously not related to symbol completion as I first thought. Here's a much simpler test case: With a freshly started SLIME type x and then the ENTER key. You're thrown into the debugger because the symbol is unbound. Type a to abort. Repeat this two or three times - presto:
; SLIME 2005-10-09 CL-USER> x ; Evaluation aborted CL-USER> x ; Evaluation aborted CL-USER> x ; Evaluation aborted CL-USER> x Error: An allocation request for 268435480 bytes caused a need for 536870912 more bytes of heap. The operating system will not make the space available because the address space reserved for the heap could not be increased. [condition type: STORAGE-CONDITION]
Restart actions (select using :continue): 0: Return to sldb level 1. 1: Try evaluating X again. 2: Use :X instead. 3: Set the symbol-value of X and use its value. 4: Use a value without setting X. 5: Abort handling SLIME request. 6: Abort entirely from this (lisp) process. [Current process: new-repl-thread] [1] CL-USER(1):
At the moment, SLIME seems to be more or less unusable with AllegroCL... :(
Cheers, Edi.
PS: I updated SLIME from CVS yesterday and then began to see these problems. I'm not 100% sure when I updated the last time but it's probably not more than two or three weeks ago.
PPS: AllegroCL is very recent, i.e. I did (SYS:UPDATE-ALLEGRO) last week.
* Edi Weitz [2005-10-10 11:19+0200] writes:
Yes. In fact, this is obviously not related to symbol completion as I first thought. Here's a much simpler test case: With a freshly started SLIME type x and then the ENTER key. You're thrown into the debugger because the symbol is unbound. Type a to abort. Repeat this two or three times - presto:
For me the problem goes away with the patch below. Not sure whether our code or Allegros finish-output on two-way-streams is broken.
Helmut.
--- swank.lisp 9 Oct 2005 18:55:52 -0000 1.343 +++ swank.lisp 10 Oct 2005 14:09:42 -0000 @@ -1002,7 +1002,7 @@ (defun prin1-to-string-for-emacs (object (prin1-to-string object))))
(defun force-user-output () - (finish-output (connection.user-io *emacs-connection*)) + (force-output (connection.user-io *emacs-connection*)) (finish-output (connection.user-output *emacs-connection*)))
On Mon, 10 Oct 2005 16:13:52 +0200, Helmut Eller heller@common-lisp.net wrote:
For me the problem goes away with the patch below.
Yes, for me too. As always - thanks for the quick fix.
Cheers, Edi.
-
Edi Weitz -
Helmut Eller