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)
|
Belated response... >From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de> Subject: Re: finishing output translating stream Date: Thu, 09 Jun 2005 07:51:07 +0200 > Now, this flushing business makes me a little concerned: What you're > proposing means my output data is different depending on when I call > flush. However, I always thought of this invariant as pretty > fundamental to what flush does---that it does not change the data. Hm, that is a reasonable concern. On the other hand, I regard 'flush' as to flush out any pending state in the I/O subsystem and start it over from a clean state---the state includes pending data in the buffer, or an unclosed escape sequence. If you want to keep the invariance, you wouldn't know flushing really flushes the buffer (Cf. <U+30AB> <U+309A> case). What's the use of 'flush', then? > It seems what you really should do to solve your problem is send a > message to the translator to insert the closing escape sequence into > the output stream, and have the *translator* flush after it has > encountered the message and written the closing sequence. You could > just use U+0003 (END OF TEXT) or something for that purpose. Would > this be reasonable? This is probably the logically cleaner solution, although I think it doesn't follow the convention. The application should be agnostic to the presense of translator stream. It used to be customary to call flush to tell I/O subsystem that "I'm done on the output for a while". Another practical (although slightly outdated) example: A command-line interactive application which prompts the user input. The cliche for the application to print the prompt would be something like this: (begin (display *prompt*) (flush-output-port)) If the terminal uses iso2022 encoding, and the prompt contains non-ASCII character---you do want to make sure the closing escape sequence is output before waiting for the user input. But you wouldn't know the user uses these settings. Do you suggest that all applications now should be written as this? (begin (display *prompt*) (display #\EOT) (flush-output-port)) I don't strongly insist my position, though, for there's usually workarounds for this problem. However, the translator can always discard the flushing message if it doesn't need it, so it doesn't hurt if flush-output-stream sends a special message to the translator. --shiro