[slime-devel] ABCL reversion in 2008-12-30 (Re: Compilation output goes to *inferior-lisp* buffer under ABCL

Helmut Eller heller at common-lisp.net
Fri Jan 23 14:54:55 UTC 2009


* Mark Evenson [2009-01-23 13:34+0100] writes:

> After some investigation, I still don't understand what is going wrong 
> here, but can report that after 2008-12-30, ABCL's SLIME definitely has 
> the symptom that all output goes to the *inferior-lisp* buffer as 
> opposed to the REPL bugger.  And I should at least report what I have 
> been able to determine more exactly about my confusion.

I have an on old version of ABCL (0.0.9, don't know if that means much)
but the IO redirection seems to work.

>
> My main (mis)undestanding is that it seems as if the use of the 
> WITH-CONNECTION macro is not properly binding *STANDARD-OUTPUT* to the 
> output stream stored in the ENV field of the CONNECTION structure.   Nor 
> does the binding of the rest of the standard streams *ERROR-OUTPUT*, 
> *DEBUG-IO*, *TERMINAL-IO* look correct.  The code in 
> CALL-WITH-CONNECTION, used by the WITH-CONNECTION macro reads:
>
> (defun call-with-connection (connection function)
>    (if (eq *emacs-connection* connection)
>        (funcall function)
>        (let ((*emacs-connection* connection)
>              (*pending-slime-interrupts* '()))
>          (without-slime-interrupts
>            (with-swank-error-handler (*emacs-connection*)
>              (with-io-redirection (*emacs-connection*)
>                (call-with-debugger-hook #'swank-debugger-hook 
> function)))))))
>
> meaning that the WITH-IO-REDIRECTION macro will never be invoked if the 
> REPL is being used as (eq *emacs-connection* connection)?  This is the 
> opposite of what I would expect from my understanding of what 
> *emacs-connection* means.

Well, the name isn't great, but if *emacs-connection* is already bound
then there should be no reason to bind *emacs-connection* and all the
other dynamic bindings again.

If you add some debug code like 
(format *log-output* "stdout: ~a~%" *standard-output*)
you should see the stream that Slime is using as *standard-output*.

>
> But ECL seems to work with this code which is odd as ECL uses the same 
> communication style (NIL) as ABCL, but ECL doesn't exhibit these sort of 
> problems.  I don't really undestand the intricacy of the closure that is 
> made over the reader function created in the invocation of 
> MAKE-REPL-INPUT-STREAM.  The only difference in the code used by SLIME 
> between ECL and ABCL is that ABCL doesn't use Gray streams (it doesn't 
> really have them) as opposed to ECL, which does, in the 
> MAKE-INPUT-STREAM/MAKE-OUTPUT-STREAM definitions.  I can't think of what 
> distinction might make, but I note it in case it strikes a chord with 
> someone else.

MAKE-REPL-INPUT-STREAM makes a stream out of an input stream which polls
the original stream and also Slime's socket for input.  Slime requests
are handled immediately and input for the original stream is just
returned.  In theory it should work to assign *standard-input* to such a
stream and the native REPL would implicitly handle Slime requests.

> The following function
>
> (defun fix-standard-output (connection)
>    (setf *standard-output*
>          (cdr (find '*standard-output*
>                     (connection.env connection)
>                     :test #'equal :key #'car))))
>
> when invoked on the REPL after SLIME starts via
>
> CL-USER> (fix-standard-output swank::*emacs-connection*)
>
> seems to restore the output behavior. Similar functions are probably 
> needed for the other standard streams.
>
> When I tried to bind *STANDARD-OUTPUT* to the value stored in 
> CONNECTION.ENV at the same place *STANDARD-INPUT* is bound in 
> SIMPLE-SERVE-REQUESTS, I get a stack overflow in the running of 
> SWANK-LOADER.

At that point CONNECTION.ENV probably nil.  It is initialized later, in
CREATE-REPL.

Helmut.





More information about the slime-devel mailing list