2017-11-14 14:00 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:


> On 14 Nov 2017, at 09:53, Denis Kudriashov <dionisiydk@gmail.com> wrote:
>
> I look at the code, So Zinc provides only binary/character streams. Right?

Yes, Zn streams focus on classic binary(byte) / character streams.

Streaming over arbitrary data is very cool and well covered by the old ones.

While I really like traditional streams I can not agree here. Sometimes it reminds me poor java collections which force writing loops all the time.
For example the most common task in my experience was writing contents of read stream into write stream. And the only possibility now is loop.��
From this point of view XStreams really pushes streams to the level of smalltalk collections.��
��

> About contribution: it is in external repository of Sven. Can we contribute with normal process, create pull request into Pharo repo?
>
> 2017-11-14 9:36 GMT+01:00 Guillermo Polito <guillermopolito@gmail.com>:
> To a package next to block?
>
> On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
> What about contributing to zinc streams? Imaging that I will create block based streams, collecting:/selecting streams like in XSteam. Where I should put them?
>
>
> 2017-11-13 23:51 GMT+01:00 Norbert Hartl <norbert@hartl.name>:
>
>
> > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
> >
> >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
> >> The idea is to have much simpler streams which can be composed to get more sophisticated behaviour.
> >>
> >> The most primitive streams should be binary read or write streams, like a raw file or network connection.
> >>
> >> To add a character encoding/decoding you wrap them in a ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer, cleaner ZnCharacterEncoders).
> >
> > Yes really nice :)
> >
> > And Guille started to use them and we are slowly rewriting all the
> > stream internal users to use Zn and after we will be free.
> >
> >
> No, you will depend on zinc classes. How is that supposed to work in bootstrap?
>
> Norbert
> >> If you want buffering, you wrap a ZnBufferedReadStream or ZnBufferedWriteStream around them.
> >>
> >> And there are some other examples in the system too.
> >>
> >> Have a look at BinaryFileStream and ZdcSocketStream.
> >>
> >> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must die, because they try to be everything at once and are impossible to change.
> >
> >
> > YES YES YES and celebrate. I could never understand anything. My brain
> > is too limited for these kind of games :)
> >
> >
> >
> >> The contract of a stream should be much, much simpler than it is today.
> >
> > Fully agree.
> >
> >>
> >> For writing that means
> >>
> >> #nextPut:
> >> #nextPutAll:
> >> #next:putAll:
> >> #next:putAll:startingAt:
> >>
> >> the 3 last ones can be written in terms of of the first one, but the last one is key because it can be the most efficient.
> >> And maybe also
> >>
> >> #flush
> >> #close
> >>
> >> Some helpers for character writing are
> >>
> >> #space
> >> #tab
> >> #cr
> >> #crlf
> >> #lf
> >>
> >> Maybe #newline
> >
> > :)
> >
> >
> >>
> >> #<< is a handy method too.
> >>
> >> For reading that means
> >>
> >> #atEnd
> >> #next
> >> #next:
> >> #next:into:
> >> #next:into:startingAt:
> >> #nextInto:
> >> #peek
> >> #skip:
> >> #upToEnd
> >> #upTo:
> >> #readInto:startingAt:count:
> >>
> >> Again, they can all be written in terms of #next, but #readInto:startingAt:count: is the core, efficient one.
> >> Note that #peek allows a one character lookahead, which should be sufficient for almost all parsing needs.
> >>
> >> #close is also a necessary operation, #peekFor: a handy one, #nextLine is popular too.
> >>
> >> There is a discussion about positioning (#position , #position: and related) but these cannot be supported _in general_ by the kind of streams described above.
> >>
> >> If you absolutely need these, read #upToEnd and use a regular ReadStream (over a fixed collection).
> >>
> >> The collection based classic Streams should always remain in the system, they are too handy. But have you seen for example, #nextInt32 on PositionableStream ? Good luck with that when the the underlying collection is anything other than bytes.
> >>
> >> All this being said, there is no one, single correct answer.
> >>
> >> But if we all try to simplify what we expect of streams (use a more limited API), we'll be more nimble to make implementation changes later on.
> >>
> >> Sven
> >>
> >>> On 13 Nov 2017, at 19:58, Stephane Ducasse <stepharo.self@gmail.com> wrote:
> >>>
> >>> Hi Evan
> >>>
> >>> I think that we will use the ZnStreams.
> >>> If we use Xtreams we will transform their API because some messages
> >>> are not really good.
> >>> Stef
> >>>
> >>>> On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue <emdonahu@gmail.com> wrote:
> >>>> I've heard mention once or twice on this list and in some release notes of
> >>>> what sounded like possible coming changes to the stream API. Could anyone
> >>>> point me to any concrete details about that? I haven't been able to dig
> >>>> anything up myself by searching. I'm about to write something that I'd like
> >>>> to be polymorphic with the stream API, but if that's about to change, I'd
> >>>> like to plan ahead.
> >>>>
> >>>> Thanks,
> >>>> Evan
> >>>
> >>
> >>
>
>
>
>
>
> --
>
> 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
>
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13
>