finishing output translating stream Shiro Kawai (25 May 2005 00:05 UTC)
Re: finishing output translating stream Michael Sperber (06 Jun 2005 15:15 UTC)
Re: finishing output translating stream Shiro Kawai (07 Jun 2005 10:41 UTC)
Re: finishing output translating stream bear (07 Jun 2005 16:12 UTC)
Re: finishing output translating stream Michael Sperber (08 Jun 2005 07:19 UTC)
Re: finishing output translating stream Shiro Kawai (08 Jun 2005 07:37 UTC)
Re: finishing output translating stream Michael Sperber (08 Jun 2005 07:52 UTC)
Re: finishing output translating stream Shiro Kawai (08 Jun 2005 09:08 UTC)
Re: finishing output translating stream Shiro Kawai (08 Jun 2005 09:10 UTC)
Re: finishing output translating stream bear (08 Jun 2005 18:10 UTC)
Re: finishing output translating stream bear (09 Jun 2005 02:16 UTC)
Re: finishing output translating stream Michael Sperber (09 Jun 2005 05:51 UTC)
Re: finishing output translating stream Shiro Kawai (21 Jun 2005 00:00 UTC)
Re: finishing output translating stream Michael Sperber (22 Jun 2005 07:56 UTC)

Re: finishing output translating stream bear 09 Jun 2005 02:16 UTC


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.

				Bear