Email list hosting service & mailing list manager

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 Shiro Kawai 21 Jun 2005 00:00 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