By default, the connection between the lisp and the slime repl is buffered. I would like to propose to have it unbuffered. on the grounds that if the user has a (format t ...), he/she probably wants the message to appear immediately on the screen :-)
Isn't the proper way to make the message appear immediately to use a (force-output) or a (format t "....~%")?
Fred Gilham gilham@csl.sri.com writes:
By default, the connection between the lisp and the slime repl is buffered. I would like to propose to have it unbuffered. on the grounds that if the user has a (format t ...), he/she probably wants the message to appear immediately on the screen :-)
Isn't the proper way to make the message appear immediately to use a (force-output) or a (format t "....~%")?
One could argue about that. But the fact is that if the program makes any output, for whatever reason, and it is directed at a console with a human in front, it makes little sense to keep it in the buffer until that buffer is full.
Note that while your first alternative works, your second alternative doesn't do what you expect in the current slime; that would be line buffering. Currently, these connections are fully buffered.
Regards, Mario.
* Mario S. Mommer [2005-11-11 18:16+0100] writes:
Fred Gilham gilham@csl.sri.com writes:
By default, the connection between the lisp and the slime repl is buffered. I would like to propose to have it unbuffered. on the grounds that if the user has a (format t ...), he/she probably wants the message to appear immediately on the screen :-)
Isn't the proper way to make the message appear immediately to use a (force-output) or a (format t "....~%")?
One could argue about that. But the fact is that if the program makes any output, for whatever reason, and it is directed at a console with a human in front, it makes little sense to keep it in the buffer until that buffer is full.
It's a tradeoff between efficient bulk output or immediate response. Currently SLIME offers the following options:
- with a multi-threaded lisp, full buffering is clearly the right choice, because it's easy to spawn a thread to flush buffers a few times per second. So all this is a non-issue with OpenMCL, Allegro, Lispworks, and threaded SBCL.
- with *use-dedicated-output-stream* = t you get a fully buffered stream.
- for *use-dedicated-output-stream* = nil we use line buffering with a short delay, i.e. the buffer is flushed on newlines, but only if it wasn't flushed 20ms before.
I going to change that so that *use-dedicated-output-stream* = t will use an unbuffered stream by default, but make that customizable with *dedicated-output-stream-buffering*.
On the efficiency side, there doesn't seem to much of a difference between full and no buffering. At least not with the simpleminded `M-x slime-io-speed-test'.
I note however that *use-dedicated-output-stream* = nil is faster than the dedicated stream with certain Lisps, e.g. for CLISP and Lispworks and not much slower for CMUCL (2-3 times slower). Of course the current buffering scheme for the non-dedicated variant doesn't pass the "(dotimes (i 10) (princ i) (sleep 1))" test, but I'm now seriously thinking about removing the dedicated output stream.
Helmut.
-
Fred Gilham -
Helmut Eller -
Mario S. Mommer