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?

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