> On 14 Nov 2017, at 14:18, Denis Kudriashov <dionisi...@gmail.com> wrote: > > > 2017-11-14 14:00 GMT+01:00 Sven Van Caekenberghe <s...@stfx.eu>: > > > > On 14 Nov 2017, at 09:53, Denis Kudriashov <dionisi...@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.
Yes, I agree, Xtreams is much better (but steep learning curve). I just wanted to point out that my contributions in Zn streams focus and better/simpler byte/character IO. Improvement on the classic streams are, of course, welcome. > > 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 <guillermopol...@gmail.com>: > > To a package next to block? > > > > On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov <dionisi...@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 <norb...@hartl.name>: > > > > > > > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse <stepharo.s...@gmail.com>: > > > > > >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe <s...@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.s...@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 <emdon...@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 > > > > >
