I think this is an SBCL problem (as it doesn't happen in CMUCL), but Slime code tickles it so I'm sending it to both lists.
With SBCL, Slime can't find it's way past an infix expression with source-path-stream-position. Because of this, when compiling files with C-c C-k, any notes, warnings, or errors will cause an unrelated infix error.
To test this you'll obviously need to load infix.cl, available from http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/...
Put a file somewhere containing these two lines: (quote #i( 2 )) (quote nothing)
With Swank loaded, in CMUCL: CL-USER> (with-open-file (f "/tmp/test.lisp") (swank-backend::source-path-stream-position '(1 0) f)) 17 22
With SBCL (0.8.21.26, x86/Linux): CL-USER> (with-open-file (f "/tmp/test.lisp") (swank-backend::source-path-stream-position '(1 0) f)) Infix expression ends with NIL. [Condition of type SIMPLE-ERROR]
Restarts: 0: [ABORT] Abort handling SLIME request. 1: [ABORT] Exit debugger, returning to top level.
Backtrace: 0: (INFIX::READ-INFIX #<SB-SYS:FD-STREAM for "file "/tmp/test.lisp"" {9CB17A1}>) 1: (INFIX::INFIX-READER #<SB-SYS:FD-STREAM for "file "/tmp/test.lisp"" {9CB17A1}> #<unavailable argument> #<unavailable argument>) 2: (SB-IMPL::READ-MAYBE-NOTHING #<SB-SYS:FD-STREAM for "file "/tmp/test.lisp"" {9CB17A1}> ##) 3: (SB-IMPL::READ-LIST #<SB-SYS:FD-STREAM for "file "/tmp/test.lisp"" {9CB17A1}> #<unavailable argument>) 4: (READ-PRESERVING-WHITESPACE #<SB-SYS:FD-STREAM for "file "/tmp/test.lisp"" {9CB17A1}> T NIL T) 5: (READ-PRESERVING-WHITESPACE #<SB-SYS:FD-STREAM for "file "/tmp/test.lisp"" {9CB17A1}> T NIL NIL) 6: (READ #<SB-SYS:FD-STREAM for "file "/tmp/test.lisp"" {9CB17A1}> T NIL NIL) 7: (SWANK-BACKEND::READ-SOURCE-FORM 1 #<SB-SYS:FD-STREAM for "file "/tmp/test.lisp"" {9CB17A1}>) 8: (SWANK-BACKEND::SOURCE-PATH-STREAM-POSITION (1 0) #<SB-SYS:FD-STREAM for "file "/tmp/test.lisp"" {9CB17A1}>)
This problem is absolutely NOT critical to me, it just came up while trying to help someone on c.l.l.
-bcd
On Sat, Apr 09, 2005 at 10:07:13PM -0500, Brian Downing wrote:
I think this is an SBCL problem (as it doesn't happen in CMUCL), but Slime code tickles it so I'm sending it to both lists.
It turns out it's a problem with infix. It called READ internally inside its main reader macro. However, it didn't rebind *read-suppress* inside, so it's internals got all mucked up with SBCL's (correct) behavior in this regard.
I see a commit for CMUCL's reader in one of the latest snapshots that mimics the SBCL behavior, so I imagine it would behave the same way with unmodified infix.
Attached is a patch for infix, if anybody cares. It rebinds *read-suppress* to nil inside infix-reader, so the whole infix expression is parsed (and then ignored, since *read-suppress* is t outside).
-bcd