2017-11-14 9:53 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>: > I look at the code, So Zinc provides only binary/character streams. Right? > > About contribution: it is in external repository of Sven. Can we > contribute with normal process, create pull request into Pharo repo? >
yes, time to time we make sync with Zinc upstream. -- Pavel > > 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 >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > >
