[slime-devel] Slime presentation marker bug (updated patch attached)

[Matthias Koeppe]

On Thu, Sep 30, 2010 at 7:44 AM, Nathan Bird <nathan at acceleration.net> wrote:
>  On 9/29/2010 4:37 PM, Matthias Koeppe wrote:
>>>
>>> * slime-stream-p can be dynamically overridden with *slime-stream-p*;
>>> useful when writing to a mem buffer or some other location that will be
>>> dumped to a slime stream but is natively detectable as such.
>>
>> I'm not sure about the last change. I don't think it can work in a
>> non-dedicated stream setup because the presentation boundaries are
>> signalled out-of-band.
>
> Yeah, that use case I gave only works for dedicated output streams, but it
> at least doesn't get in the way for non-dedicated.

I don't agree. For non-dedicated, it can cause presentation markup on
the wrong text.

More importantly, I am concerned about effects on unintended streams,
for instance by condition handlers, debugger, etc.  So I don't think
this is safe.

> The use case I have (a
> stream logger who's printed objects are automatically presentations where
> appropriate) is precisely as above though: I want to print to a memory
> buffer and then dump that to the dedicated stream. When running a bunch of
> threads this still isn't threadsafe behavior by any means but it reduces the
> critical section to just (write-sequence <short-message> stream).

I would suggest to create a solution with a dynamic variable that is a
list of eligible streams. And it should only kick in dedicated mode.

For your use case, an interesting solution could also be a custom
string stream class that queues up the strings and presentation
markers. This would be in parallel to the pretty printing streams in
Allegro CL and my patched version of SBCL's.

Matthias
-- 
Matthias Koeppe -- http://www.math.ucdavis.edu/~mkoeppe