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