Would it be possible to change `slime-input-stream' to become a real stream rather than just a struct?
As a non-stream struct it tends to wreak havoc when some non-slime aware code tries to operate on *standard-input*.
My concrete problem is with Paul Foleys (mycroft@actrix.gen.nz) repl-ext package that allows one to do Allegro style repl commands, and I have come to absolutely love this. This wants to replace the toplevel REPL but does not know how to handle slime-input-streams. The fix is rather simple, but I think it would make slime more robust if it would not be necessary to fix all packages that needs to operate on *standard-input* one by one.
Obviously, I have no idea how difficult such a thing would be, but it may be worth keeping in the back of your heads :-)
Another thing would be to consider integrating repl-ext into slime, it is really nice, IMHO.
------------------------+----------------------------------------------------- Christian Lynbech | christian #@ defun #. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)
Christian Lynbech christian.lynbech@ericsson.com writes:
Would it be possible to change `slime-input-stream' to become a real stream rather than just a struct?
slime-input-stream is a subclass of lisp::lisp-stream, so it a real stream. (typep *standard-input* 'stream) returns T.
As a non-stream struct it tends to wreak havoc when some non-slime aware code tries to operate on *standard-input*.
My concrete problem is with Paul Foleys (mycroft@actrix.gen.nz) repl-ext package that allows one to do Allegro style repl commands, and I have come to absolutely love this. This wants to replace the toplevel REPL but does not know how to handle slime-input-streams. The fix is rather simple, but I think it would make slime more robust if it would not be necessary to fix all packages that needs to operate on *standard-input* one by one.
The repl-ext has a function wait-for-input-available that dispatches on the type of the stream, but only fd-stream, synonym-stream, and two-way-stream are covered. As a workaround you could add a clause (stream nil).
Obviously, I have no idea how difficult such a thing would be, but it may be worth keeping in the back of your heads :-)
Paul Foleys code assumes that the stream is a fd-stream (or a wrapper around a fd-stream). It would be fairly difficult to make slime-input-streams a subclass of fd-stream. I think it isn't worth the trouble. Modifying wait-for-input-available as above or turning it into a generic function with a method for slime-input-streams would be much easier.
Another thing would be to consider integrating repl-ext into slime, it is really nice, IMHO.
The current REPL is partly implement in ELisp and partly in CL. If we implement the REPL entirely in Lisp we lose some control. We couldn't tell ordinary output from the prompt or the return value. I think that isn't desirable.
We could implement some of the commands in Emacs Lisp, e.g by special-casing input like ":pwd" or perhaps better ",pwd". Would you like to work on this?
Helmut.
"Helmut" == Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Helmut> Christian Lynbech christian.lynbech@ericsson.com writes:
Would it be possible to change `slime-input-stream' to become a real stream rather than just a struct?
Helmut> slime-input-stream is a subclass of lisp::lisp-stream, so it a real Helmut> stream. (typep *standard-input* 'stream) returns T.
Ahh, I just saw
(defstruct (slime-input-stream
and missed the inclusion of `string-stream' and jumped to conclusions. Sorry about that.
As a non-stream struct it tends to wreak havoc when some non-slime aware code tries to operate on *standard-input*.
My concrete problem is with Paul Foleys (mycroft@actrix.gen.nz) repl-ext package that allows one to do Allegro style repl commands, and I have come to absolutely love this. This wants to replace the toplevel REPL but does not know how to handle slime-input-streams. The fix is rather simple, but I think it would make slime more robust if it would not be necessary to fix all packages that needs to operate on *standard-input* one by one.
Helmut> The repl-ext has a function wait-for-input-available that dispatches Helmut> on the type of the stream, but only fd-stream, synonym-stream, and Helmut> two-way-stream are covered. As a workaround you could add a clause Helmut> (stream nil).
I have added the clause
(swank::slime-input-stream (swank::sis/misc stream :listen))
to `wait-for-input-available' and that seems to work and appears to me to be a semi-correct solution.
Helmut> Paul Foleys code assumes that the stream is a fd-stream (or a wrapper Helmut> around a fd-stream).
I wasn't thinking so much in terms of repl-ext as in terms of the generic problem. Some slime versions ago I managed to consistently throw the lisp into a tight loop of errors involving *standard-input* falling through an etypecase. It might just have been repl-ext blowing up, but I got the worry that there could be other corners of CMUCL that would respond badly to the non-fd-stream-ness of *standard-input*.
Anyway, I fully accept this to be "be fairly difficult to make".
Helmut> The current REPL is partly implement in ELisp and partly in CL. If we Helmut> implement the REPL entirely in Lisp we lose some control. We couldn't Helmut> tell ordinary output from the prompt or the return value. I think Helmut> that isn't desirable.
It was not my intention to change the spirit of the REPL control of slime, only to integrate the concept of command line interface commands into slime, however we could do it.
Helmut> We could implement some of the commands in Emacs Lisp, e.g by Helmut> special-casing input like ":pwd" or perhaps better ",pwd". Would you Helmut> like to work on this?
I do not think that hacking the emacs side would be the way to go. An important part would to allow applications to add new commands that would be fully integrated into the REPL (including help texts etc).
I think the operation should go something like this:
(emacs) user types :pwd (emacs) slime sends ":pwd" to swank (lisp) swank recognises ":pwd" as a command and look up its defintion (lisp) :pwd definition is executed
I will try to see if I can make any sense out of Pauls hacked up toplevel and how swank operates its end of the slime repl and see if I can come with a suggestion.
If somebody has better suggestions of REPL extensions or how to do this, now is the time to speak up :-)
------------------------+----------------------------------------------------- Christian Lynbech | christian #@ defun #. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)
-
Christian Lynbech -
Helmut Eller