[slime-devel] SLIME 2007-03-24 change to remove the timer for async REPL output
Helmut, the change below (from 2007-03-24) causes the output and the REPL result to be displayed in the wrong order (occasionally, non-deterministically), when *use-dedicated-output-stream* = t. (This was reported on the mailing list on 2007-04-22 and I can reproduce it; however, I am normally not using this mode myself.) The reason is a race between the REPL results (sent through SLIME events) and the regular process output (sent through the dedicated stream). The removed code worked around this race by waiting a small amount of time. 2007-03-24 Helmut Eller <heller@common-lisp.net> * slime.el (slime-repl-insert-prompt): Use insert-before-markers. This fixes some redisplay problems, but I don't know why. Also: remove the timer for async output. (slime-repl-move-output-mark-before-prompt): Removed. I would like to re-introduce (and document the rationale of) the removed code using the patch below, for the benefit of users of *use-dedicated-output-stream* = t. Any objections? Matthias --- slime.el 25 Aug 2007 13:02:47 -0700 1.815 +++ slime.el 25 Aug 2007 16:53:15 -0700 @@ -3710,11 +3716,30 @@ (insert-before-markers prompt)) (set-marker slime-repl-prompt-start-mark prompt-start) (goto-char slime-repl-prompt-start-mark) - (slime-mark-output-start) + ;;(slime-mark-output-start) + ;;; We wish to distinguish between the output of a command + ;;; and asynchronous output (caused by another thread) that happens to be sent. + ;;; The command output should appear before the REPL result; + ;;; the asynchronous output should appear after it. + ;;; + ;;; However, when a dedicated output stream is used, there is a + ;;; race between the REPL results (which appear as a SLIME event) + ;;; and the regular output (which appears on the dedicated + ;;; stream). As a workaround, after a small amount of time, + ;;; decide that all following output is asynchronous output. + (run-at-time 0.2 nil 'slime-repl-move-output-mark-before-prompt + (current-buffer)) (goto-char (point-max)) (slime-mark-input-start)) (slime-repl-show-maximum-output)) +(defun slime-repl-move-output-mark-before-prompt (buffer) + (when (buffer-live-p buffer) + (with-current-buffer buffer + (save-excursion + (goto-char slime-repl-prompt-start-mark) + (slime-mark-output-start))))) + (defun slime-repl-show-maximum-output (&optional force) "Put the end of the buffer at the bottom of the window." (assert (eobp)) -- Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe (currently @math.ucdavis.edu)
[Sorry helmut if you get bored by me repeating the same thing again and again] * Matthias Koeppe <871wdrqhk5.fsf@moose.moosenet> : | the change below (from 2007-03-24) causes the output and the REPL | result to be displayed in the wrong order (occasionally, | non-deterministically), when *use-dedicated-output-stream* = t. (This | was reported on the mailing list on 2007-04-22 and I can reproduce it; | however, I am normally not using this mode myself.) | | The reason is a race between the REPL results (sent through SLIME | events) and the regular process output (sent through the dedicated | stream). The removed code worked around this race by waiting a small | amount of time. The workaround is was response to the bug I reported in my email message[1] to the group. I had reported the problem again[2] (as you refer to above), and requested your rationale in employing this code in the first place. [...] | I would like to re-introduce (and document the rationale of) the | removed code using the patch below, for the benefit of users of | *use-dedicated-output-stream* = t. | | Any objections? The workaround is suspect and introduces more non-deterministic behaviour. There are flaws with this approach and unless you can fix or address the problems mentioned in [1] and [3] I would prefer this not be reintroduced into SLIME. If it must be reintroduced perhaps this stuff should be moved to contrib and core slime should only have something simple and which works reliably and is of sound design. Madhu. [1] Archived-At: <http://permalink.gmane.org/gmane.lisp.slime.devel/5969> Date: Fri, 02 Feb 2007 09:58:38 +0530 Message-ID: <m3hcu589op.fsf@robolove.meer.net> [2] Date: Sun, 22 Apr 2007 22:46:07 +0530 Message-ID: <m3fy6stjmw.fsf@robolove.meer.net> Archived-At: <http://permalink.gmane.org/gmane.lisp.slime.devel/6223> [3] Date: Fri, 27 Apr 2007 06:11:04 +0530 Message-ID: <m3tzv2vecf.fsf@robolove.meer.net> Archived-At: <http://permalink.gmane.org/gmane.lisp.slime.devel/6244>
Madhu <enometh@meer.net> writes:
* Matthias Koeppe <871wdrqhk5.fsf@moose.moosenet> : | [...] race between the REPL results (sent through SLIME events) | and the regular process output (sent through the dedicated | stream). [...] [...] core slime should only have something simple and which works reliably and is of sound design.
I actually agree with you. In my opinion, "*use-dedicated-output-stream* = t" is (and always was) fundamentally flawed because you cannot guarantee anything about the timing of the two streams (the dedicated stream and the slime event stream). (That's why slime-repl-insert-prompt has included a timer kludge to hide the race for a long time -- since revision 1.179 from 2004-01-15.) I don't mind if this mode of output ("*use-dedicated-output-stream* = t") is removed from SLIME. As I said, I don't use it myself. However, there were or are users who are interested in using "*use-dedicated-output-stream* = t" because of performance considerations. I am trying to fix it for the benefit of those users. Matthias -- Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe (currently @math.ucdavis.edu)
* Matthias Koeppe [2007-08-26 02:13+0200] writes:
Any objections?
Yes. The dedicated output stream is an efficiency hack. Those people using it must accept that it may produce incorrect results. Helmut.
Helmut Eller <heller@common-lisp.net> writes:
* Matthias Koeppe [2007-08-26 02:13+0200] writes: [> reintroduce timer for async output]
Any objections?
Yes. The dedicated output stream is an efficiency hack. Those people using it must accept that it may produce incorrect results.
OK. I have changed the documentation instead in CVS, see below. --- slime.texi 04 Feb 2007 09:06:21 -0800 1.54 +++ slime.texi 26 Aug 2007 11:39:22 -0700 @@ -1796,12 +1796,20 @@ @end example @item SWANK:*USE-DEDICATED-OUTPUT-STREAM* -This variable controls an optimization for sending printed output from -Lisp to Emacs. When @code{t} a separate socket is established solely for -Lisp to send printed output to Emacs through. Without the optimization -it is necessary to send output in protocol-messages to Emacs which must -then be decoded, and this doesn't always keep up if Lisp starts -``spewing'' copious output. +This variable controls whether to use an unsafe efficiency hack for +sending printed output from Lisp to Emacs. The default is @code{nil}, +don't use it, and is strongly recommended to keep. + +When @code{t}, a separate socket is established solely for Lisp to send +printed output to Emacs through, which is faster than sending the output +in protocol-messages to Emacs. However, as nothing can be guaranteed +about the timing between the dedicated output stream and the stream of +protocol messages, the output of a Lisp command can arrive before or +after the corresponding REPL results. Thus output and REPL results can +end up in the wrong order, or even interleaved, in the REPL buffer. +Using a dedicated output stream also makes it more difficult to +communicate to a Lisp running on a remote host via SSH +(@pxref{Connecting to a remote lisp}). @item SWANK:*DEDICATED-OUTPUT-STREAM-PORT* When @code{*USE-DEDICATED-OUTPUT-STREAM*} is @code{t} the stream will @@ -1873,7 +1881,7 @@ has the side-effect of giving the entire world access to your lisp image, so we're not going to talk about it} and we'll only have one port open we want to tell swank to not use an extra connection for -output: +output (this is actually the default in current SLIME): @example (setf swank:*use-dedicated-output-stream* nil) -- Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe (currently @math.ucdavis.edu)
participants (3)
-
Helmut Eller -
Madhu -
Matthias Koeppe