On Wed, Aug 1, 2018 at 11:19 AM Guillermo Polito <guillermopolito@gmail.com> wrote:
On Tue, Jul 31, 2018 at 6:41 PM Damien Pollet < damien.pollet+pharo@gmail.com> wrote:
On Tue, 31 Jul 2018 at 18:28, Damien Pollet < damien.pollet+pharo@gmail.com> wrote:
Hi Sven⦠a couple questions:
For context, I'm considering options in Clap, for providing accessors to Stdio that: - are convenient in most cases - discourage users from explicitly referencing the Stdio global (so that one can inject other streams instead if needed)
Yes. And to me it's ok if Clap defines his own good usages of streams. Clap's usage of stream is not a typical file access.
For instance, it seems to make sense to provide stdout already wrapped with ZnNewLineWriterStream,
Also, ZnNewLineWriterStream needs only to be used when interacting with the external word. The rationale of keeping it separate is twofold: - Zn* streams are meant to be reusable with other kind of streams that are not files (such as streams in memory) where the newline conventions do not need to be *always* enforced because the image has internally its own convention (crs). - Zn* streams are meant to be reusable with other kind of streams that are not files (such as sockets) where maybe we want *also* to enforce line ending convention.
And I'll just add that this also makes it simple to "skip" line end convention transformations.
but that precludes users from buffering.
Yeap. This makes me remember I tried a buffered file stream on /dev/urandom and the buffering introduced some funny effects :)
- is there a preferred order of composition between the encoding and
buffering streams ? If yes, it the same for read and write stream, or reversed ? E.g. if Stdio binaryStdin was implemented, Stdio stdin should be decoded, but buffering it as well would be a problem for interactive applications.
- what's your opinion on convenience composition messages, e.g. aBinaryStream buffered decoded: 'utf-8' ?
On Tue, 24 Jul 2018 at 10:13, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 23 Jul 2018, at 12:07, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Stdio stdout and friends just return a binary stream, hence they need wrapping for encoding.
Maybe
Stdio stdoutAsText
might be an idea, but this is so uncommon that I am not sure this is a good idea.
Given all remarks and comments (thanks BTW), I now think that
- textual stdio streams are the more common case - binary stdio streams are the primitive ones that are seldom used - another encoding than UTF-8 seems uncommon - these are streams that exist and need no real opening/closing
So,
Stdio stdout
should return return a character write stream with UTF-8 encoding while
Stdio binaryStdout
should be the lower level binary one. This would be more in line with the other streams. A non-UTF-8 encoding can be used as per Pavel's example.
--
Guille Polito
Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>*
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13
-- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13