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. Bear