[slime-devel] sending form to *inferior-lisp* or *slime-repl*

[Gary Byers]

On Mon, 15 Dec 2003, Sven Van Caekenberghe wrote:

> On 15 Dec 2003, at 10:29, Nicolas Neuss wrote:
>
> > Helmut Eller <e9626484 at stud3.tuwien.ac.at> writes:
> >
> >> Nicolas Neuss <Nicolas.Neuss at 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 at clozure.com