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