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.

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*.

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.]

* 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