I am running cmucl 20c (unicode version) under slime, with coding-system set to utf-8-unix and quicklisp loaded.
All seems to work well, including loading various quicklisp packages, until I try this:
CL-USER> (ql:quickload "ironclad") To load "ironclad": Load 1 ASDF system: ironclad ; Loading "ironclad" ...
and the slime-repl buffer hangs with the cursor at the last line above.
In the *inferior-lisp* buffer I find this:
;; swank:close-connection: No matching method for the generic function #<STANDARD-GENERIC-FUNCTION STREAM-ELEMENT-TYPE (1) {59232FA9}>, when called with arguments (#<Stream for descriptor 5>). Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
There is nothing untoward in the *slime-events* buffer.
Any idea what could be the problem? I'll be happy to provide backtraces, etc. if you can only tell me how to get them.
I supposed there is something odd about the stream for descriptor 5. Perhaps someone who knows the internals well can tell me what stream that is, and how it is different from other streams?
(Oh, loading ironclad in the *inferior-lisp* buffer works like a charm, after I tweaked the source code a little so it could find libcrypt. All this is on ubuntu, BTW, linux kernel 3.2.0-31-generic.)
- Harald
On Wed, Oct 03 2012, Harald Hanche-Olsen wrote:
I am running cmucl 20c (unicode version) under slime, with coding-system set to utf-8-unix and quicklisp loaded.
All seems to work well, including loading various quicklisp packages, until I try this:
CL-USER> (ql:quickload "ironclad") To load "ironclad": Load 1 ASDF system: ironclad ; Loading "ironclad" ...
and the slime-repl buffer hangs with the cursor at the last line above.
In the *inferior-lisp* buffer I find this:
;; swank:close-connection: No matching method for the generic function #<STANDARD-GENERIC-FUNCTION STREAM-ELEMENT-TYPE (1) {59232FA9}>, when called with arguments (#<Stream for descriptor 5>). Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
There is nothing untoward in the *slime-events* buffer.
Any idea what could be the problem?
Maybe a problem CMUCL's gray streams. Does (require 'gray-streams) work?
I'll be happy to provide backtraces, etc. if you can only tell me how to get them.
SWANK should print a backtrace in such situations but in this case the problem seems to occur also during printing the backtrace. So we need to find out what happens before the error.
The output of (ql:quickload "ironclad" :verbose t) would probably provide some hint in what file the problem occurs.
I supposed there is something odd about the stream for descriptor 5. Perhaps someone who knows the internals well can tell me what stream that is, and how it is different from other streams?
What's the output of: ls -l /proc/<pid>/fd where <pid> is the CMUCL's process id.
Also is swank:*use-dedicated-output-stream* set?
(Oh, loading ironclad in the *inferior-lisp* buffer works like a charm, after I tweaked the source code a little so it could find libcrypt. All this is on ubuntu, BTW, linux kernel 3.2.0-31-generic.)
- Harald
Helmut
[Helmut Eller heller@common-lisp.net (2012-10-03 18:39:42 UTC)]
On Wed, Oct 03 2012, Harald Hanche-Olsen wrote:
Maybe a problem CMUCL's gray streams. Does (require 'gray-streams) work?
Yes.
I'll be happy to provide backtraces, etc. if you can only tell me how to get them.
SWANK should print a backtrace in such situations but in this case the problem seems to occur also during printing the backtrace. So we need to find out what happens before the error.
The output of (ql:quickload "ironclad" :verbose t) would probably provide some hint in what file the problem occurs.
After loading ironclad.asd, it does
; Loading #P"/home/midterm/quicklisp/dists/quicklisp/software/nibbles-20120811-git/nibbles.asd". ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: . ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP C): ; Compiling Top-Level Form: . ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP C): ; Compiling Top-Level Form: . ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP C): ; Compiling Top-Level Form:
and hangs.
Most interestingly, if I start over and do CL-USER> (ql:quickload "nibbles" :verbose t) and then CL-USER> (ql:quickload "ironclad" :verbose t) it works. Immediately after the output shown above, the "nibbles" load continues with To load "nibbles": Load 1 ASDF system: nibbles ; Loading "nibbles" and so forth.
I supposed there is something odd about the stream for descriptor 5. Perhaps someone who knows the internals well can tell me what stream that is, and how it is different from other streams?
What's the output of: ls -l /proc/<pid>/fd where <pid> is the CMUCL's process id.
%; ls -l /proc/15494/fd total 0 lr-x------ 1 midterm midterm 64 Oct 3 21:21 0 -> pipe:[222474] l-wx------ 1 midterm midterm 64 Oct 3 21:21 1 -> pipe:[222473] l-wx------ 1 midterm midterm 64 Oct 3 21:21 2 -> pipe:[222473] lr-x------ 1 midterm midterm 64 Oct 3 21:21 3 -> /opt/cmucl-20c/lib/cmucl/lib/lisp-sse2.core lrwx------ 1 midterm midterm 64 Oct 3 21:21 5 -> socket:[222481] lr-x------ 1 midterm midterm 64 Oct 3 21:21 7 -> pipe:[222478]
So it's a socket, then. The only one open.
Also is swank:*use-dedicated-output-stream* set?
No. Ought it to be set?
- Harald
On Wed, Oct 03 2012, Harald Hanche-Olsen wrote:
[snip]
The output of (ql:quickload "ironclad" :verbose t) would probably provide some hint in what file the problem occurs.
After loading ironclad.asd, it does
; Loading #P"/home/midterm/quicklisp/dists/quicklisp/software/nibbles-2012081\
1-git/nibbles.asd".
; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: . ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP C): ; Compiling Top-Level Form: . ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP C): ; Compiling Top-Level Form: . ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP C): ; Compiling Top-Level Form:
and hangs.
Most interestingly, if I start over and do CL-USER> (ql:quickload "nibbles" :verbose t) and then CL-USER> (ql:quickload "ironclad" :verbose t) it works. Immediately after the output shown above, the "nibbles" load continues with To load "nibbles": Load 1 ASDF system: nibbles ; Loading "nibbles" and so forth.
I think the problem occurs during loading of gray-streams. There is a (defgeneric stream-element-type ...) which removes all methods. After that the compiler adds new methods and generates the dispatch code for STREAM-ELEMENT-TYPE but wants to print some progress information before the code is ready.
It seems that the progress information is printed in QUICKLISP-CLIENT::MACROEXPANAD-PROGRESS-FUN which is bound to *MACROEXPAND-HOOK*. If I change the code in quicklisp/dists/quicklisp/software/ironclad_0.31/src/octed-stream.lisp to
#+cmu (eval-when (:compile-toplevel :load-toplevel :execute) (let ((*macroexpand-hook* #'funcall)) (require :gray-streams)))
the problem seems to go away.
Not sure what the right fix is. PCL::COMPILE-LAMBDA should probably bind *MACROEXPAND-HOOK* hook in any case. SWANK could also load gray-strams early or CMUCL could load gray-streams in the default image. It's also debatable whether Quicklisp should bind *MACROEXPAND-HOOK*.
[snip]
Also is swank:*use-dedicated-output-stream* set?
No. Ought it to be set?
Usually not, but the problem would probably go away as STREAM-ELEMENT-TYPE would not be called.
Helmut
-
Harald Hanche-Olsen -
Helmut Eller