> On 14 Nov 2017, at 16:49 , Denis Kudriashov wrote:
>
>
> squares := (1 to: 1000) ~> #squared map ~> 1000 take ~> Set.
> fileIn readStream ~> #isSeparator filter ~> fileOut writeStream.
I’ve actually done something very similar for collections in Grace, except that
I use >> as the operator s
> On 14 Nov 2017, at 14:07 , Sven Van Caekenberghe wrote:
>
> I am curious though, why do you need it ?
>
> I mean, I got away (and try hard) to only use 1-element peeking and managed
> to implement STON, NeoJSON, NeoCSV, Stomp, PostgresSQL, Redis, and other
> protocols.
>
> A syntax that re
I have a meta-comment here.
As a community I feel sometimes that we are trying to make people converge.
"Somebody already wrote a transducers library, I cannot write another
transducers library, we have to merge". Now, I understand that sometimes we
don't have the "manpower" to solve all the probl
Please note, the port on GitHub is not the most recent version. I had
trouble porting it to Pharo and code exchange in general. For now it's
unfinished due to a lack of time.
Am .11.2017, 16:30 Uhr, schrieb Steffen Märcker :
I forgot to mention, that the most recent code for Pharo is alread
Short: No. =)
Actually, the <~ notation was originally proposed by another Smalltalker
on the vwnc list. The idea was that <~ visualizes the flow into the
variable, which I find nice (see first expression). However, I do
understand that this alienates others. Hence, I am non-religious about
Sven
>From the thread discussion here my take.
- I do not think that we want to reuse any of the old streams.
- So first Zn to replace the binary and MultiUglyStream and after we
will have to check
if we should port the design of Xtream (but not the API) to Pharo.
Stef
On Tue, Nov 14, 2017 at 5
Denis I agree. I do not like to code in reverse order.
On Tue, Nov 14, 2017 at 4:49 PM, Denis Kudriashov wrote:
> 2017-11-14 16:30 GMT+01:00 Steffen Märcker :
>>
>> I forgot to mention, that the most recent code for Pharo is already on
>> Github: https://github.com/Pharophile/Transducers
>>
>> R
2017-11-14 16:30 GMT+01:00 Steffen Märcker :
> I forgot to mention, that the most recent code for Pharo is already on
> Github: https://github.com/Pharophile/Transducers
>
> Reducers was the name of the first very first implementation.
>
> (In fact, I was originally inspired by clojures Reducers l
I forgot to mention, that the most recent code for Pharo is already on
Github: https://github.com/Pharophile/Transducers
Reducers was the name of the first very first implementation.
(In fact, I was originally inspired by clojures Reducers lib. After
implementing it in Smalltalk, I developed
> On 14 Nov 2017, at 16:00, Steffen Märcker wrote:
>
> Hi,
>
>> Are transducers the subject of your thesis ?
>
> No. Transducers is my side project. I've implemented a package for
> VisualWorks. Unfortunately, I did not finish the port to Pharo yet, simply
> due to a lack of time. Originall
Hi,
Are transducers the subject of your thesis ?
No. Transducers is my side project. I've implemented a package for
VisualWorks. Unfortunately, I did not finish the port to Pharo yet, simply
due to a lack of time. Originally, transducers evolved in the clojure
community. I figured, the c
> On 14 Nov 2017, at 15:33, Steffen Märcker wrote:
>
> Hi!
>
>>> 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.
>>
>> Yes, and it is really nice.
>> Intere
Hi!
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.
Yes, and it is really nice.
Interesting how many users we have in system for general streams?
(created on arbitrary
2017-11-14 14:25 GMT+01:00 Sven Van Caekenberghe :
>
> > 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 rem
> On 14 Nov 2017, at 14:18, Denis Kudriashov wrote:
>
>
> 2017-11-14 14:00 GMT+01:00 Sven Van Caekenberghe :
>
>
> > On 14 Nov 2017, at 09:53, Denis Kudriashov wrote:
> >
> > I look at the code, So Zinc provides only binary/character streams. Right?
>
> Yes, Zn streams focus on classic bin
2017-11-14 14:00 GMT+01:00 Sven Van Caekenberghe :
>
>
> > On 14 Nov 2017, at 09:53, Denis Kudriashov 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 dat
> On 14 Nov 2017, at 10:20, Prof. Andrew P. Black wrote:
>
>
>> On 13 Nov 2017, at 20:27 , Sven Van Caekenberghe wrote:
>>
>> There is a discussion about positioning (#position , #position: and related)
>> but these cannot be supported _in general_ by the kind of streams described
>> above
> On 14 Nov 2017, at 09:53, Denis Kudriashov 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.
> About contribut
> On 13 Nov 2017, at 20:27 , Sven Van Caekenberghe wrote:
>
> There is a discussion about positioning (#position , #position: and related)
> but these cannot be supported _in general_ by the kind of streams described
> above.
I agree with that. But I think that general streams can, and shoul
2017-11-14 9:53 GMT+01:00 Denis Kudriashov :
> 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 wi
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 :
> To a package next to block?
>
> On Tue,
To a package next to block?
On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov
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 Hart
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 :
>
>
> > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse >:
> >
> >> On Mon, Nov 13, 2017 at
2017-11-13 23:51 GMT+01:00 Norbert Hartl :
>
>
> > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse >:
> >
> >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe
> wrote:
> >> The idea is to have much simpler streams which can be composed to get
> more sophisticated behaviour.
> >>
> >> The
> Am 13.11.2017 um 21:08 schrieb Stephane Ducasse :
>
>> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe 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 stre
Thanks Sven, we should take that list of selectors and make a document or
Lint rules on them.
On Mon, Nov 13, 2017 at 9:08 PM, Stephane Ducasse
wrote:
> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe
> wrote:
> > The idea is to have much simpler streams which can be composed to get
> mo
On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe 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 chara
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 ZnChara
Xtreams has very good performance, but the API’s are messy. I haven’t compared
the performance of ZnStreams, but it shouldn’t be radically different.
From: Stephane Ducasse
Sent: Monday, November 13, 2017 1:59 PM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Stream API
Hi
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 wrote:
> I've heard mention once or twice on this list and in some release notes of
> what sounded like poss
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
31 matches
Mail list logo
