[slime-devel] sending form to *inferior-lisp* or *slime-repl*
Hi, first thank you very much for Slime. I use it only for a short while now, but I already prefer it to Ilisp. Some questions, though. I have some longer calculations which give some status information during the run. I had a function which sent an S-expression to the *cmulisp* buffer (bringing it up if necessary) and which was defined as (defun copy-eval-last-sexp (arg) "Evaluate the last s-expression in the source buffer in the Lisp listener." (interactive "p") (let ((end (point)) (beg (save-excursion (backward-list 1) (point))) (edit-buffer (current-buffer))) (cmulisp) (end-of-buffer) (switch-to-buffer edit-buffer) (append-to-buffer ilisp-buffer beg end) (switch-to-buffer ilisp-buffer) (return-ilisp))) I have bound this to "C-x M-e" with (define-key lisp-mode-map "\C-x\M-e" 'copy-eval-last-sexp) Question: Is there something similar in Slime or how should I do it in Slime? Should it go to *inferior-lisp* or to *slime-repl*? I also noted that *inferior-lisp* pops up when information is displayed. I do not want this, actually, so how could I switch that off? Thanks, Nicolas.
Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:
Some questions, though. I have some longer calculations which give some status information during the run. I had a function which sent an S-expression to the *cmulisp* buffer (bringing it up if necessary) and which was defined as [...] I have bound this to "C-x M-e" with (define-key lisp-mode-map "\C-x\M-e" 'copy-eval-last-sexp)
The most similar Slime probably command is slime-eval-last-expression, bound to C-x C-e. The result is inserted in the current buffer, if you give a prefix argument. slime-switch-to-output-buffer, C-c C-z, pops you to the slime-repl buffer. Do you need something else?
Question: Is there something similar in Slime or how should I do it in Slime? Should it go to *inferior-lisp* or to *slime-repl*?
There is usually no need to insert the sexp into one of those buffers (unless you want the see the expression there). The preferred interface functions are slime-eval and slime-eval-async. The *inferior-lisp* Lisp buffer is indented as fallback to debug SLIME bugs. You should use *slime-repl* if possible.
I also noted that *inferior-lisp* pops up when information is displayed. I do not want this, actually, so how could I switch that off?
SLIME adds a hook to inferior-lisp-mode-hook. You could remove this hook manually. Helmut.
Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:
Some questions, though. I have some longer calculations which give some status information during the run. I had a function which sent an S-expression to the *cmulisp* buffer (bringing it up if necessary) and which was defined as [...] I have bound this to "C-x M-e" with (define-key lisp-mode-map "\C-x\M-e" 'copy-eval-last-sexp)
The most similar Slime probably command is slime-eval-last-expression, bound to C-x C-e. The result is inserted in the current buffer, if you give a prefix argument. slime-switch-to-output-buffer, C-c C-z, pops you to the slime-repl buffer. Do you need something else?
Yes. I have calculations which need some time and I want that information printed during the calculation is shown as soon as possible. E.g. try (dotimes (i 10) (format t "~a~%" i) (sleep 1)) with "C-xC-e". This will show the result only after everything has finished. Inserting (force-output t) gives continuous output and might be a possible alternative even if it does require to change the application. But even in that case it does not pop up the *slime-repl* buffer if it is hidden. Thanks, Nicolas.
On 15 Dec 2003, at 10:29, Nicolas Neuss wrote:
Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:
[...]
Yes. I have calculations which need some time and I want that information printed during the calculation is shown as soon as possible.
E.g. try
(dotimes (i 10) (format t "~a~%" i) (sleep 1))
with "C-xC-e". This will show the result only after everything has finished. Inserting (force-output t) gives continuous output and might be a possible alternative even if it does require to change the application. But even in that case it does not pop up the *slime-repl* buffer if it is hidden.
I found this annoying as well. It happens in REPL too. For example, when you load a couple of ASDF systems, you won't see much (only partial) output. I am using OpenMCL. Sven
On Mon, 15 Dec 2003, Sven Van Caekenberghe wrote:
On 15 Dec 2003, at 10:29, Nicolas Neuss wrote:
Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:
[...]
Yes. I have calculations which need some time and I want that information printed during the calculation is shown as soon as possible.
E.g. try
(dotimes (i 10) (format t "~a~%" i) (sleep 1))
with "C-xC-e". This will show the result only after everything has finished. Inserting (force-output t) gives continuous output and might be a possible alternative even if it does require to change the application. But even in that case it does not pop up the *slime-repl* buffer if it is hidden.
I found this annoying as well. It happens in REPL too. For example, when you load a couple of ASDF systems, you won't see much (only partial) output. I am using OpenMCL.
Sven
I/O primitives in OpenMCL rarely call FORCE-OUTPUT unless the stream's buffer is full. A background thread wakes up a few times a second and tries to call FORCE-OUTPUT on any output stream that's registered itself for this handling. The initial listener thread (and anything else created with CCL::MAKE-MCL-LISTENER-PROCESS) does this registration. There should probably be some sort of documented, supported way of doing this independently of MAKE-MCL-LISTENER-PROCESS, but if M-M-L-P were itself exported/documented/cleaned up a bit it'd probably be a reasonable way of starting SLIME's REPL thread as well. (Ahem. Of course, I meant to say "... SLIME's REPL threads ..."). I'm not sure if this is the cause of the symptom you're seeing, but OpenMCL's output streams will cretainly sit there (fat dumb and happy) with a buffer (almost) full of data until something convinces them that fORCE-OUTPUT would be a good idea. Gary Byers gb@clozure.com
I just checked in code to use the mechanism Gary suggests. -Alan On Dec 15, 2003, at 6:53 AM, Gary Byers wrote:
On Mon, 15 Dec 2003, Sven Van Caekenberghe wrote:
On 15 Dec 2003, at 10:29, Nicolas Neuss wrote:
Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:
[...]
Yes. I have calculations which need some time and I want that information printed during the calculation is shown as soon as possible.
E.g. try
(dotimes (i 10) (format t "~a~%" i) (sleep 1))
with "C-xC-e". This will show the result only after everything has finished. Inserting (force-output t) gives continuous output and might be a possible alternative even if it does require to change the application. But even in that case it does not pop up the *slime-repl* buffer if it is hidden.
I found this annoying as well. It happens in REPL too. For example, when you load a couple of ASDF systems, you won't see much (only partial) output. I am using OpenMCL.
Sven
I/O primitives in OpenMCL rarely call FORCE-OUTPUT unless the stream's buffer is full. A background thread wakes up a few times a second and tries to call FORCE-OUTPUT on any output stream that's registered itself for this handling. The initial listener thread (and anything else created with CCL::MAKE-MCL-LISTENER-PROCESS) does this registration. There should probably be some sort of documented, supported way of doing this independently of MAKE-MCL-LISTENER-PROCESS, but if M-M-L-P were itself exported/documented/cleaned up a bit it'd probably be a reasonable way of starting SLIME's REPL thread as well. (Ahem. Of course, I meant to say "... SLIME's REPL threads ...").
I'm not sure if this is the cause of the symptom you're seeing, but OpenMCL's output streams will cretainly sit there (fat dumb and happy) with a buffer (almost) full of data until something convinces them that fORCE-OUTPUT would be a good idea.
Gary Byers gb@clozure.com
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:
Yes. I have calculations which need some time and I want that information printed during the calculation is shown as soon as possible.
Ah, I completely misunderstood the original question. Here are some reasons why the output does not show up immediately: (a) the redirected streams are fully buffered. I think CMUCL's normal output stream is line buffer. (b) Emacs shows the output buffer only when an evaluation command is finished and only when there was actually some output. (a) can be solved by inserting FORCE-OUTPUTs in the application code. We could also change the buffering scheme of the stream, but a line buffered stream to Emacs is probably rather slow. There are various alternatives for (b): - we could display the output buffer at the beginning of each evaluation command. But I think that would be annoying, especially when the evaluation produces no output. - display the output buffer every time a chunk of output arrives. This may also be annoying. I wouldn't like it. - display the output buffer when the first chunk of output arrives and when the evaluation is completed. - a new evaluation command that displays the buffer at the beginning Choose one variant and I will implement it. Helmut.
Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
There are various alternatives for (b):
- we could display the output buffer at the beginning of each evaluation command. But I think that would be annoying, especially when the evaluation produces no output.
- display the output buffer every time a chunk of output arrives. This may also be annoying. I wouldn't like it.
- display the output buffer when the first chunk of output arrives and when the evaluation is completed.
- a new evaluation command that displays the buffer at the beginning
I choose this one. I would propose that the new command is C-x M-e, because I used this choice before.
Choose one variant and I will implement it.
Thanks, Nicolas.
Helmut.
participants (5)
-
Alan Ruttenberg -
Gary Byers -
Helmut Eller -
Nicolas Neuss -
Sven Van Caekenberghe