[slime-devel] Standard output no longer appears in REPL
It's been a couple of months since I last used SLIME. Today I noticed that when I evaluate expressions in the REPL that write to *standard-output*, the output appears in the *inferior-lisp* buffer, but not in the REPL as it used to. I'm using GNU Emacs on Windows atop the CLISP Cygwin build. SLIME is up to date with CVS. Is there some new configuration required to restore the old behavior with output streams feeding into the REPL output? -- Steven E. Harris
Steven E. Harris wrote:
It's been a couple of months since I last used SLIME. Today I noticed that when I evaluate expressions in the REPL that write to *standard-output*, the output appears in the *inferior-lisp* buffer, but not in the REPL as it used to.
I'm using GNU Emacs on Windows atop the CLISP Cygwin build. SLIME is up to date with CVS. Is there some new configuration required to restore the old behavior with output streams feeding into the REPL output?
I can confirm that the same problem exists on CLISP 2.47 on x64-darwin-9.6.0. It also occurs in ABCL and ECL, both of which use the NIL SWANK::*COMMUNICATION-STYLE*. I don't have a fix, but the same problem has been occurring with ABCL on-and-off for the past half-year. The latest change that broke this for ABCL was the move of WITH-CONNECTION in 'swank.lisp' from MAKE-REPL-INPUT-STREAM to SIMPLE-SERVE-REQUESTS at Fri Mar 27 21:49:49 2009 with the ChangeLog comment: 2009-03-27 Helmut Eller <heller@common-lisp.net> * swank.lisp (encode-message): Handle errors during write, e.g. closed sockets. I thought this was some problem inside ABCL's implementation dealing with compiling closures, but now that its occurring in other implementations, I would suggest reverting the 2009-03-27 change. Mark <evenson@panix.com> -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Mark Evenson <evenson@panix.com> writes:
I thought this was some problem inside ABCL's implementation dealing with compiling closures, but now that its occurring in other implementations, I would suggest reverting the 2009-03-27 change.
I haven't seen any changes come through on this front. Perhaps we have not reached consensus on whether *standard-output* should be making it into the REPL. I note that CLISP's REPL does echo *standard-output*, but I'm not sure what other implementations do. -- Steven E. Harris
Steven E. Harris wrote:
Mark Evenson <evenson@panix.com> writes:
I thought this was some problem inside ABCL's implementation dealing with compiling closures, but now that its occurring in other implementations, I would suggest reverting the 2009-03-27 change.
I haven't seen any changes come through on this front. Perhaps we have not reached consensus on whether *standard-output* should be making it into the REPL. I note that CLISP's REPL does echo *standard-output*, but I'm not sure what other implementations do.
I definitely don't see CLISP echo *standard-output* into the REPL beuffer, so maybe there is some greater variability here. And this thread is getting ignored because it "works for me". This is with CLISP "2.47 (2008-10-23)" with SLIME 2009-05-01 on Emacs 22.3.1. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Mark Evenson <evenson <at> panix.com> writes:
I definitely don't see CLISP echo *standard-output* into the REPL buffer, so maybe there is some greater variability here. And this thread is getting ignored because it "works for me".
Sorry, I wasn't clear. What I meant regarding CLISP is that if I start up its REPL from a shell, just running CLISP bare outside of SLIME, *standard-output* does appear in the CLISP REPL. When I run SLIME over CLISP, *standard-output* does /not/ get echoed to SLIME's REPL. The only way to see *standard-output* is to visit the *inferior-lisp* buffer. -- Steven E. Harris
Steven E. Harris wrote:
Sorry, I wasn't clear. What I meant regarding CLISP is that if I start up its REPL from a shell, just running CLISP bare outside of SLIME, *standard-output* does appear in the CLISP REPL. When I run SLIME over CLISP, *standard-output* does /not/ get echoed to SLIME's REPL. The only way to see *standard-output* is to visit the *inferior-lisp* buffer.
I see the behavior that you describe in my configuration, too. I added the following line to ~/.swank.lisp to restore the earlier behavior: (setq `SWANK:*GLOBALLY-REDIRECT-IO*' t) Here is the description from the Slime manual: `SWANK:*GLOBALLY-REDIRECT-IO*' When true this causes the standard streams (`*standard-output*', etc) to be globally redirected to the REPL in Emacs. When `NIL' (the default) these streams are only temporarily redirected to Emacs using dynamic bindings while handling requests. Note that `*standard-input*' is currently never globally redirected into Emacs, because it can interact badly with the Lisp's native REPL by having it try to read from the Emacs one. You can read the entry in Emacs if you have slime.info properly configured by entering the following in the minibuffer: M-x: (info "(slime) Other configurables")
Mark Harig wrote:
(setq `SWANK:*GLOBALLY-REDIRECT-IO*' t)
Small correction: the above expression should not have the quotes.
It should read:
(setq SWANK:*GLOBALLY-REDIRECT-IO* t)
Placing this statement in a newly created 'site-init.lisp' in the SLIME top directory might be a slightly less non-intrusive place that will co-exist if you update your SLIME from CVS to chase HEAD. Just setting this variable in the REPL after SLIME loads won't do the right thing. Creating such a binding in 'site-init.lisp' now makes *STANDARD-OUTPUT* go to the REPL buffer for me under CLISP, ECL, and ABCL (ABCL seems to be missing a newline somehow, but other than that it works). But needing to set *GLOBALLY-REDIRECT-IO* like this contradicts the behavior of SBCL (and presumably any inferior Lisp using a non-NIL *COMMUNICATION-STYLE*): for these implementation, *STANDARD-OUTPUT* always goes to the REPL buffer regardless of the setting of *GLOBALLY-REDIRECT-IO*. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
* Mark Evenson <4A0005A6.4070003@panix.com> : Wrote on Tue, 05 May 2009 11:23:50 +0200: |> |> (setq SWANK:*GLOBALLY-REDIRECT-IO* t) | | Placing this statement in a newly created 'site-init.lisp' in the SLIME | top directory might be a slightly less non-intrusive place that will | co-exist if you update your SLIME from CVS to chase HEAD. Just setting | this variable in the REPL after SLIME loads won't do the right thing. The ~/.swank.lisp is the place where this statement should be placed. Were you able to reproduce the bug I posted in response to your 1st message when you suggested this? -- Madhu
Madhu wrote:
* Mark Evenson <4A0005A6.4070003@panix.com> : Wrote on Tue, 05 May 2009 11:23:50 +0200:
|> |> (setq SWANK:*GLOBALLY-REDIRECT-IO* t) | | Placing this statement in a newly created 'site-init.lisp' in the SLIME | top directory might be a slightly less non-intrusive place that will | co-exist if you update your SLIME from CVS to chase HEAD. Just setting | this variable in the REPL after SLIME loads won't do the right thing.
The ~/.swank.lisp is the place where this statement should be placed.
Yes, that works. My mistake: I didn't read the original post closely enough.
Were you able to reproduce the bug I posted in response to your 1st message when you suggested this?
[I'll reply to that question in the proper thread.] -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Mark Harig <idirectscm <at> aim.com> writes:
It should read:
(setq SWANK:*GLOBALLY-REDIRECT-IO* t)
Using CLISP with Slime, adding (setq SWANK:*GLOBALLY-REDIRECT-IO* t) to my .swank.lisp makes the output go to the Slime REPL but (read) still expects my input to come from the inferior lisp buffer. Can I get my slime to expect input to come from the Slime REPL buffer as well? One use case that produces this problem is http://landoflisp.com/robots.lisp, about which the author of Land of Lisp writes, "This game is kind of a joke to show off the crazy things you can do with loop and format. But it's also fun to play!"
* Mark Harig <49FFD174.1000804@aim.com> Wrote on Tue, 05 May 2009 01:41:08 -0400: | Steven E. Harris wrote: |> Sorry, I wasn't clear. What I meant regarding CLISP is that if I |> start up its REPL from a shell, just running CLISP bare outside of |> SLIME, *standard-output* does appear in the CLISP REPL. When I run |> SLIME over CLISP, *standard-output* does /not/ get echoed to SLIME's |> REPL. The only way to see *standard-output* is to visit the |> *inferior-lisp* buffer. | | I see the behavior that you describe in my configuration, too. I | added the following line to ~/.swank.lisp to restore the earlier | behavior: | | (setq SWANK:*GLOBALLY-REDIRECT-IO*' t) I think the idea behind Helmut's silence on this question is that he wants to encourage the use of GLOBALLY-REDIRECT-IO T instead of fixing the issues in design. This is not a good idea when you want to decouple the lisp from emacs. Also there are bugs in the implementation: if you drop your connection slime and your current lisp image will become unusable with SLIME. To reproduce: 1. M-x slime-disconnect 2. M-x slime (or however you started it) Emacs asks: Create an additional *inferior-lisp*? (y or n) Answer `n' You are dropped into the debugger with the following error. '---- | Streams already redirected. | | Restart actions (select using :continue): | 0: retry assertion. | 1: Return to Top Level (an "abort" restart). | `---- The problem is that an ASSERT fails in SWANK::INIT-GLOBAL-STREAM-REDIRECTION. <rant> Earlier I have noticed on this list (and mentioned) the problems with the SWANK Emacs<->Lisp implementation especially with CMUCL in the face of errors. After 4-5 years of development on slime, these issues have still not been fixed. A robust minimally-intrusive interaction between ephemeral emacsen and a long lived lisp is still not there. Instead SLIME's implementation of the network and interaction has gotten more and more complicated and harder to work around. Debugging timing bugs which cause connections to be dropped are my latest example. This growth in complexity contrasts sharply with Helmut's arguments in removing of basic functionality in elisp (such as control over filename completion, say), or not binding *read-eval* to NIL when READing the ChangeLog file. Helmut's arguments are that these complicate slime and make it harder to maintain. -- Madhu
Madhu wrote: […]
Also there are bugs in the implementation: if you drop your connection slime and your current lisp image will become unusable with SLIME. To reproduce:
1. M-x slime-disconnect 2. M-x slime (or however you started it) Emacs asks: Create an additional *inferior-lisp*? (y or n) Answer `n'
You are dropped into the debugger with the following error.
'---- | Streams already redirected. | | Restart actions (select using :continue): | 0: retry assertion. | 1: Return to Top Level (an "abort" restart). | `----
The problem is that an ASSERT fails in SWANK::INIT-GLOBAL-STREAM-REDIRECTION.
I cannot reproduce this under SLIME 2009-05-01 with SBCL, ABCL, CLISP, and ECL running under Emacs 22.3.1 with *GLOBALLY-REDIRECT-IO* set to NIL (the default). With *GLOBALLY-REDIRECT-IO* set to t, I get behavior more in line with what you encounter: ABCL fails with a simple STREAM-ERROR. CLISP starts a new inferior Lisp. SBCL and ECL gives the error that you report. Perhaps the maintainers don't test with *GLOBALLY-REDIRECT-IO* set to anything other than the default? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
participants (5)
-
Madhu -
Mark Evenson -
Mark Harig -
Steven E. Harris -
Tom