On Wed, Aug 1, 2018 at 11:19 AM Guillermo Polito <guillermopol...@gmail.com> wrote:
> > > On Tue, Jul 31, 2018 at 6:41 PM Damien Pollet < > damien.pollet+ph...@gmail.com> wrote: > >> On Tue, 31 Jul 2018 at 18:28, Damien Pollet < >> damien.pollet+ph...@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 <s...@stfx.eu> >>> wrote: >>> >>>> >>>> >>>> > On 23 Jul 2018, at 12:07, Sven Van Caekenberghe <s...@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
