[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: finishing output translating stream

This page is part of the web mail archives of SRFI 68 from before July 7th, 2015. The new archives for SRFI 68 contain all messages, not just those from before July 7th, 2015.

On Wed, 8 Jun 2005, bear wrote:

>On Tue, 7 Jun 2005, Shiro Kawai wrote:
>>If the translate-proc doesn't know about flush-output-stream,
>>and a log message happen to end with a non-ascii character,
>>it won't write out the closing escape sequence ESC '(' 'B'
>>at the end of log message, for it doesn't know if more non-ascii
>>character is coming or not.   If the application crashes then,
>>the log file remains in the non-ascii state.  Subsequent run
>>of the applicaion starts adding messages, assuming the file begins
>>with ascii state---resulting that the first ascii portion of
>>the new message becomes illegible.

> This argues that the translate-proc should "wrap" the output
> stream, so that it always knows about flush messages.  It does
> what it must do, then passes the "flush" message on to the
> primitive output stream.  Right?

Sorry to follow-up to my own post, but there's another
possibility I didn't think of initially;

Translate-chars and flush-translator could be "callbacks"
handed to the I/O port on opening, and the I/O port code
would be responsible for calling them appropriately when
reading/writing or flushing, respectively.  They'd have
to be exported from a closure together, with a scope that
allows them to access common datastructures not visible
to other code, but that's not too hard.