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

[Alan Ruttenberg]

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 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
>
>
> _______________________________________________
> slime-devel site list
> slime-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/slime-devel