Hello,
In recent (or maybe not so recent) changes to swank.lisp, send-repl-results-to-emacs sends a :write-string back to the slime dispatcher instead of :return or :emacs-rex or whatever it was previously. This means that slime-repl-eval-string never gets an :ok result back, so the result printing code in slime-repl-insert-result is of superfluous now (and can be deleted, but don't do that yet!).
There must be a good reason for this change, however I think it is worthwhile to restore that functionality so slime-repl-insert-result can be used as a target for defadvice for getting meaningful results (including multiple values, which putting advice around slime-write-string would not accomplish, besides being more complicated) back from REPL interactions. In particular, I want to slap defadvice before it to resurrect my repl-interaction-to-unit test code (http://common-lisp.net/pipermail/slime-devel/2006-September/005241.html).
What does everyone think, and what would be the issues to changing send-repl-results-to-emacs back?
Vladimir
"Vladimir Sedach" vsedach@gmail.com writes:
In recent (or maybe not so recent) changes to swank.lisp, send-repl-results-to-emacs sends a :write-string back to the slime dispatcher instead of :return or :emacs-rex or whatever it was previously.
The reasons for the change (which I did) were twofold:
1) When long REPL results are sent back, the old code first transferred them to Emacs with one big message, then printed them. Thus for a long time, you would not get any indication of what is happening.
The new code does the usual stream buffering, sending many moderate-size messages to Emacs. So you can see the progress.
2) To support nested presentations in REPL results, when present.lisp is loaded.
Best, Matthias
* "Vladimir Sedach" c07e645b0706061311l1f5beec3lcd3e734499f7dd2a@XXXX :
| In recent (or maybe not so recent) changes to swank.lisp, | send-repl-results-to-emacs sends a :write-string back to the slime | dispatcher instead of :return or :emacs-rex or whatever it was | previously. This means that slime-repl-eval-string never gets an :ok | result back, so the result printing code in slime-repl-insert-result | is of superfluous now (and can be deleted, but don't do that yet!).
I have been using your patch. It does not get the repl results printing right as per the original code.
In particular the issue I noted on "Sun, 22 Apr 2007 22:46:07 +0530" m3bqhgtj9w.fsf@robolove.meer.net
is still present. And I also get results like:
CL-USER> (date) Fri Jun 15NIL 08:14:58 2007 +0530
Is there a way I could use the advice mechanism to get the repl results printed correctly?
I did not get a response from Mathias after he "fixed" the issue in "Fri, 02 Feb 2007 09:58:38 +0530" m3bqkgvoxi.fsf@robolove.meer.net
There is another issue with repl interaction: "Fri, 27 Apr 2007 06:11:04 +0530" m3tzv2vecf.fsf@robolove.meer.net
Would this suggest the repl interaction protocol design is lacking, and needs to be fixed at a more fundamental level? (I don't use presentations myself, so my fix may not be applied to slime in general)
-- Regards Madhu
Hmm, I don't think my patch should have affected REPL printing at all. Do you mean to say that you are using my modification to listener-eval in swank.lisp to replace the :write-string based send-repl-results-to-emacs code?
As far as the interaction protocol goes, I agree that it does need to be cleaned up. Obviously there are big problems with code rot if no one noticed that the old REPL printing code was still there and totally not being used.
Vladimir
PS - Madhu, I tried sending this reply directly to you, but your mail server blacklists gmail.com. I think you may want to fix that.
On 6/14/07, Madhu enometh@meer.net wrote:
- "Vladimir Sedach" c07e645b0706061311l1f5beec3lcd3e734499f7dd2a@XXXX :
| In recent (or maybe not so recent) changes to swank.lisp, | send-repl-results-to-emacs sends a :write-string back to the slime | dispatcher instead of :return or :emacs-rex or whatever it was | previously. This means that slime-repl-eval-string never gets an :ok | result back, so the result printing code in slime-repl-insert-result | is of superfluous now (and can be deleted, but don't do that yet!).
I have been using your patch. It does not get the repl results printing right as per the original code.
In particular the issue I noted on "Sun, 22 Apr 2007 22:46:07 +0530" m3bqhgtj9w.fsf@robolove.meer.net
is still present. And I also get results like:
CL-USER> (date) Fri Jun 15NIL 08:14:58 2007 +0530
Is there a way I could use the advice mechanism to get the repl results printed correctly?
I did not get a response from Mathias after he "fixed" the issue in "Fri, 02 Feb 2007 09:58:38 +0530" m3bqkgvoxi.fsf@robolove.meer.net
There is another issue with repl interaction: "Fri, 27 Apr 2007 06:11:04 +0530" m3tzv2vecf.fsf@robolove.meer.net
Would this suggest the repl interaction protocol design is lacking, and needs to be fixed at a more fundamental level? (I don't use presentations myself, so my fix may not be applied to slime in general)
-- Regards Madhu
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
* "Vladimir Sedach" c07e645b0706191317x5cf3d423xa44d38407cdc2af8@XXX :
| Hmm, I don't think my patch should have affected REPL printing at all. | Do you mean to say that you are using my modification to listener-eval | in swank.lisp to replace the :write-string based | send-repl-results-to-emacs code? | As far as the interaction protocol goes, I agree that it does need to | be cleaned up. Obviously there are big problems with code rot if no | one noticed that the old REPL printing code was still there and | totally not being used.
I didn't meant to imply your patch affected repl printing! I just wanted to note that I've been testing out your patch, and noticed that it removed some older code which used to do repl printing, and that the behaviour of the repl printing code which had superseded the older code was still `flawed' -- Regards Madhu
| PS - Madhu, I tried sending this reply directly to you, but your mail | server blacklists gmail.com. I think you may want to fix that. This is a personal setting, my apologies for the inconvenience this causes. please excuse this.
-
Madhu -
Matthias Koeppe -
Vladimir Sedach