> Why you changed `printSymbol: aClass name`
> for `nextPutAll: aClass name`?
Because there is no #printSymbol: anywhere in Pharo 7 or Pharo 8> ,
so I had to *guess* what it does, and the only reason I could see for
using #printSymbol: instead of #print: is that class names are symbols
and #print:
On 11/09/19 9:14 a. m., Herby Vojčík wrote:
> On 11. 9. 2019 11:46, Herby Vojčík wrote:
>> On 11. 9. 2019 3:23, Richard O'Keefe wrote:
>>> #write: really does not seem to be any improvement over #nextPutAll:.
>>
>> Will post.
>
> Actually, I won't. I don't care any more.
>
> I found Contributor C
On 11. 9. 2019 11:46, Herby Vojčík wrote:
On 11. 9. 2019 3:23, Richard O'Keefe wrote:
#write: really does not seem to be any improvement over #nextPutAll:.
Will post.
Actually, I won't. I don't care any more.
I found Contributor Covenant-derived Code of Conduct was added to Pharo,
three mo
On 11. 9. 2019 3:23, Richard O'Keefe wrote:
It is good that you have a coherent idea of how << can work.
After the changes sent by Sven, Pharo 8 seems to have the exactly same
idea. IMNSHO.
The question I was addressing is how << *DOES* work in Pharo.
Having simple things working, if they a
It is good that you have a coherent idea of how << can work.
The question I was addressing is how << *DOES* work in Pharo.
Having simple things working, if they are kept consistent,
is indeed good. The problem is that in Pharo 7 they are NOT
consistent, and << does NOT work consistently, because t
On 10. 9. 2019 15:20, Sven Van Caekenberghe wrote:
Development happens in Pharo 8 first, with possible back ports if really
necessary.
The last relevant change was the following:
https://github.com/pharo-project/pharo/pull/2698
That's a very nice change, indeed. Thank you.
But there's still
On 10. 9. 2019 14:54, Richard O'Keefe wrote:
I think it's fair to say that #<< *is* a bug.
There does not seem to be any coherent description of what it means.
It's overloaded to mean *either* #nextPut: *or* #nextPutAll: *or*
something else, in some confusing ways.
CommandLineHandler #n
Development happens in Pharo 8 first, with possible back ports if really
necessary.
The last relevant change was the following:
https://github.com/pharo-project/pharo/pull/2698
> On 10 Sep 2019, at 14:54, Richard O'Keefe wrote:
>
> I think it's fair to say that #<< *is* a bug.
> There does no
I think it's fair to say that #<< *is* a bug.
There does not seem to be any coherent description of what it means.
It's overloaded to mean *either* #nextPut: *or* #nextPutAll: *or*
something else, in some confusing ways.
CommandLineHandler #nextPutAll: (sent somewhere else)
Integer
Herby,
It's a feature. ;-)
<< sends putOn: message to the non-collection args.
Integer>>#putOn: aStream
aStream isBinary
ifTrue: [ self asByteArray do: [ :each | aStream nextPut: each
] ]
ifFalse: [ self asString putOn: aStream ]
String>>#putOn: aStream
> 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
Le 1 juil. 2015 à 14:42, Torsten Bergmann a écrit :
> Christophe Demarey
>> I tried to create an in-memory file as following:
>> (MemoryFileSystemFile named: 'Foo')
>> writeStreamDo: [ :stream | stream nextPutAll: 'bar' ]
>>
>> Then I get an improper store into ByteArray. It looks like Cha
41 matches
Mail list logo
