- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 7 streams API

by Herbert VojÄÃk

Sven Van Caekenberghe wrote on 3. 7. 2018 11:36: > > >> On 3 Jul 2018, at 11:28, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: >> >> >> >> Herbert VojÄÃk wrote on 3. 7. 2018 11:21: >>> Sven Van Caekenberghe wrote on 3. 7. 2018 10:55: >>>> >>>> >>>>> On 3 Jul 2018, at 10:08, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: >>>>> >>>>> >>>>> >>>>> Sven Van Caekenberghe wrote on 2. 7. 2018 16:00: >>>>>>> On 25 Jun 2018, at 12:56, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Peter UhnÃ¡k wrote on 23. 6. 2018 15:39: >>>>>>>> Hi, >>>>>>>> I'm starting to familiarize myself with new streams, and one thing I've noticed is the removal of #lineEndConvention (which I use all the time). >>>>>>>> So a statement like this >>>>>>>> aFile writeStreamDo: [ :stream | >>>>>>>> stream lineEndConvention: #lf. >>>>>>>> stream << '...'> ]. >>>>>>>> has to be written like so >>>>>>>> aFile writeStreamDo: [ :rawStream | |stream| >>>>>>>> stream := (ZnNewLineWriterStream on: rawStream) forLf. >>>>>>>> stream << '...' >>>>>>>> ]. >>>>>>>> which feels very messy because I am mixing writing with the configuration. And I don't even take account for buffered/encoded decorators. Plus it increases the incidental complexity -- I need another variable, and I can accidentally write to the wrong stream, etc. >>>>>>>> Would a method like #writeStream:do: (or #writeStreamTransform:do:) make sense? E.g. >>>>>>>> aFile writeStreamTransform: [ :stream | (ZnNewLineWriterStream on: stream) ] do: [ :stream | >>>>>>>> stream << '...' >>>>>>>> ] >>>>>>> >>>>>>> aFile writeStreamDo: [ :rawStream | >>>>>>> (ZnNewLineWriterStream on: rawStream) in: [ :stream | >>>>>>> stream << '...' ] ]. >>>>>>> >>>>>>> As for transformation, I'd go for some more generic (functional?) approach like: >>>>>>> >>>>>>> aFile writeStreamDo: ([:x | ZnNewLineWriterStream on: x] pipe: [ :stream | >>>>>>> stream << '...' ]). >>>>>> I like the first version with the (little known, but still standard and clear) #in: selector. >>>>>> I can't see how the second is 'better', as it looks equally 'complex' but adds a new selector, #pipe: >>>>>> All this, IMHO. >>>>> >>>>> It's a bit more focused on the task, that being transform incoming argument. Cf. >>>>> >>>>> #asString pipe: [ :aString | ... ] >>>>> >>>>> instead of: >>>>> >>>>> [ :anObject | anObject asString in: [ :aString | ... ] ] >>>>> >>>>> IOW, scope of anObject is limited (and if using #selector you don't even need to come up with a name, like the rawStream in examples before). >>>> >>>> OK, maybe, what is your definition for #pipe: then ? >>> Basically something like this: >>> (BlockClosure | Symbol) >> pipe: aBlock >>> ^ [ :arg | aBlock value: (self value: arg) ] >> >> Now that I think of, it is basically nothing more than function composition, so it could have binary selector instead. That would save parentheses, so the example would look like: >> >> aFile writeStreamDo: >> [ :x | ZnNewLineWriterStream on: x ] ++ >> [ :stream | stream << '...' ]. > > Interesting ;-) > > Why not even #, then ? (It is used to compose Exceptions into an ExceptionSet too, why not blocks into blocks). Doesn't fit in my PoV. The spirit of #, is to produce some collection-like thing. The function composition is not a collection, it's not a BlockSet, it's a single block, welded together from parts, but those are not important any more. IMNSHO. > An 'issue' that I see is that your #pipe: definition only works for single argument blocks, something that is probably unavoidable. IIRC this can be done in CommonLisp, but I am not 100% sure. > > Most probably this idea of functional composition has been discussed before ... > >>>>>>> Herby >>>>>>> >>>>>>>> To separate the composition from the usage? >>>>>>>> Thanks, >>>>>>>> Peter > >

July 3, 2018

Re: [Pharo-users] Pharo 7 streams API

by herby＠mailbox.sk

Solutions to different problems. I proposed a simple generic thing that only composes functions, allowing for transformation of block arg. Transducers seem like streaming, data-flow specific, thing. Maybe yours helps the original problem in the long run. I just tried to find something to solve more specific part of it while being such generic that it helps in other places as well. Just pointing it out so there isn't a perception they are competing to solve same problem and only one should be selected. Herby On July 3, 2018 3:57:21 PM GMT+02:00, "Steffen MÃ¤rcker" <merkste(a)web.de> wrote: >I think, streams and functional composition match up nicely and >transducers are a way to do this. I've introduced them earlier on this > >list. (I hesitated to weight into the discussion, as I won't have time >to >work on the Pharo port of Transducers until October.) > >Let me give a simplified example. I assume the basic messages are >#nextPut: and #close: to write to aStream and close it. > > aString > transduce: LineEndCrLf flatMap > reduce: (#nextPut: completing: #close) > init: aStream > >* Let aString be the source, i.e., some object that yields a sequence >of >characters: > a CR b >* Let LineEndConventionLF a function that maps CR to #(CR LF): > a CR b -> a #(CR LF) b >* #flatMap embeds #(CR LF) into the sequence: > a CR LF b >* (#nextPut: completing: #close) puts each character on the stream and > >calls #close at the end: > aStream > nextPut: $a; > nextPut: CR; > nextPut: LF; > nextPut: $b; > close; > yourself. >* #transduce:reduce:init: actually starts the writing process. > >First, (LineEndConventionLF flatMap) is composable with other >transformations, e.g., encoding. The example above would change to: > > aString > transduce: LineEndCrLf flatMap * EncodeUTF8 flatMap > reduce: (#nextPut: completing: #close) > init: aByteStream > >LineEndCrLf and EncodeUTF8 only have to know how to process single >characters. Hence, they are highly reusable. > >Second, as the source the transformations, the writing process and the > >data sink are distinct objects, we can freely interact with them and >build >arbitrary pipelines. It is straight-forward to come up with other >iteration methods than #reduce:init:, e.g., step-wise processing of >streams. > >Best, Steffen

July 3, 2018

Re: [Pharo-users] Pharo 7 streams API

by Steffen MÃ¤rcker

I think, streams and functional composition match up nicely and transducers are a way to do this. I've introduced them earlier on this list. (I hesitated to weight into the discussion, as I won't have time to work on the Pharo port of Transducers until October.) Let me give a simplified example. I assume the basic messages are #nextPut: and #close: to write to aStream and close it. aString transduce: LineEndCrLf flatMap reduce: (#nextPut: completing: #close) init: aStream * Let aString be the source, i.e., some object that yields a sequence of characters: a CR b * Let LineEndConventionLF a function that maps CR to #(CR LF): a CR b -> a #(CR LF) b * #flatMap embeds #(CR LF) into the sequence: a CR LF b * (#nextPut: completing: #close) puts each character on the stream and calls #close at the end: aStream nextPut: $a; nextPut: CR; nextPut: LF; nextPut: $b; close; yourself. * #transduce:reduce:init: actually starts the writing process. First, (LineEndConventionLF flatMap) is composable with other transformations, e.g., encoding. The example above would change to: aString transduce: LineEndCrLf flatMap * EncodeUTF8 flatMap reduce: (#nextPut: completing: #close) init: aByteStream LineEndCrLf and EncodeUTF8 only have to know how to process single characters. Hence, they are highly reusable. Second, as the source the transformations, the writing process and the data sink are distinct objects, we can freely interact with them and build arbitrary pipelines. It is straight-forward to come up with other iteration methods than #reduce:init:, e.g., step-wise processing of streams. Best, Steffen

July 3, 2018

Re: [Pharo-users] Pharo 7 streams API

by Damien Pollet

On Tue, 3 Jul 2018 at 11:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Most probably this idea of functional composition has been discussed > before ... > Transducers (aka. Reducers) come to mindâ¦

July 3, 2018

Re: [Pharo-users] Pharo 7 streams API

by Sven Van Caekenberghe

> On 3 Jul 2018, at 11:28, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: > > > > Herbert VojÄÃk wrote on 3. 7. 2018 11:21: >> Sven Van Caekenberghe wrote on 3. 7. 2018 10:55: >>> >>> >>>> On 3 Jul 2018, at 10:08, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: >>>> >>>> >>>> >>>> Sven Van Caekenberghe wrote on 2. 7. 2018 16:00: >>>>>> On 25 Jun 2018, at 12:56, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Peter UhnÃ¡k wrote on 23. 6. 2018 15:39: >>>>>>> Hi, >>>>>>> I'm starting to familiarize myself with new streams, and one thing I've noticed is the removal of #lineEndConvention (which I use all the time). >>>>>>> So a statement like this >>>>>>> aFile writeStreamDo: [ :stream | >>>>>>> stream lineEndConvention: #lf. >>>>>>> stream << '...'> ]. >>>>>>> has to be written like so >>>>>>> aFile writeStreamDo: [ :rawStream | |stream| >>>>>>> stream := (ZnNewLineWriterStream on: rawStream) forLf. >>>>>>> stream << '...' >>>>>>> ]. >>>>>>> which feels very messy because I am mixing writing with the configuration. And I don't even take account for buffered/encoded decorators. Plus it increases the incidental complexity -- I need another variable, and I can accidentally write to the wrong stream, etc. >>>>>>> Would a method like #writeStream:do: (or #writeStreamTransform:do:) make sense? E.g. >>>>>>> aFile writeStreamTransform: [ :stream | (ZnNewLineWriterStream on: stream) ] do: [ :stream | >>>>>>> stream << '...' >>>>>>> ] >>>>>> >>>>>> aFile writeStreamDo: [ :rawStream | >>>>>> (ZnNewLineWriterStream on: rawStream) in: [ :stream | >>>>>> stream << '...' ] ]. >>>>>> >>>>>> As for transformation, I'd go for some more generic (functional?) approach like: >>>>>> >>>>>> aFile writeStreamDo: ([:x | ZnNewLineWriterStream on: x] pipe: [ :stream | >>>>>> stream << '...' ]). >>>>> I like the first version with the (little known, but still standard and clear) #in: selector. >>>>> I can't see how the second is 'better', as it looks equally 'complex' but adds a new selector, #pipe: >>>>> All this, IMHO. >>>> >>>> It's a bit more focused on the task, that being transform incoming argument. Cf. >>>> >>>> #asString pipe: [ :aString | ... ] >>>> >>>> instead of: >>>> >>>> [ :anObject | anObject asString in: [ :aString | ... ] ] >>>> >>>> IOW, scope of anObject is limited (and if using #selector you don't even need to come up with a name, like the rawStream in examples before). >>> >>> OK, maybe, what is your definition for #pipe: then ? >> Basically something like this: >> (BlockClosure | Symbol) >> pipe: aBlock >> ^ [ :arg | aBlock value: (self value: arg) ] > > Now that I think of, it is basically nothing more than function composition, so it could have binary selector instead. That would save parentheses, so the example would look like: > > aFile writeStreamDo: > [ :x | ZnNewLineWriterStream on: x ] ++ > [ :stream | stream << '...' ]. Interesting ;-) Why not even #, then ? (It is used to compose Exceptions into an ExceptionSet too, why not blocks into blocks). An 'issue' that I see is that your #pipe: definition only works for single argument blocks, something that is probably unavoidable. IIRC this can be done in CommonLisp, but I am not 100% sure. Most probably this idea of functional composition has been discussed before ... >>>>>> Herby >>>>>> >>>>>>> To separate the composition from the usage? >>>>>>> Thanks, >>>>>>> Peter

July 3, 2018

Re: [Pharo-users] Pharo 7 streams API

by Herbert VojÄÃk

Herbert VojÄÃk wrote on 3. 7. 2018 11:21: > > > Sven Van Caekenberghe wrote on 3. 7. 2018 10:55: >> >> >>> On 3 Jul 2018, at 10:08, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: >>> >>> >>> >>> Sven Van Caekenberghe wrote on 2. 7. 2018 16:00: >>>>> On 25 Jun 2018, at 12:56, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: >>>>> >>>>> >>>>> >>>>> Peter UhnÃ¡k wrote on 23. 6. 2018 15:39: >>>>>> Hi, >>>>>> I'm starting to familiarize myself with new streams, and one thing >>>>>> I've noticed is the removal of #lineEndConvention (which I use all >>>>>> the time). >>>>>> So a statement like this >>>>>> aFile writeStreamDo: [ :stream | >>>>>> stream lineEndConvention: #lf. >>>>>> stream << '...'> ]. >>>>>> has to be written like so >>>>>> aFile writeStreamDo: [ :rawStream | |stream| >>>>>> stream := (ZnNewLineWriterStream on: rawStream) forLf. >>>>>> stream << '...' >>>>>> ]. >>>>>> which feels very messy because I am mixing writing with the >>>>>> configuration. And I don't even take account for buffered/encoded >>>>>> decorators. Plus it increases the incidental complexity -- I need >>>>>> another variable, and I can accidentally write to the wrong >>>>>> stream, etc. >>>>>> Would a method like #writeStream:do: (or >>>>>> #writeStreamTransform:do:) make sense? E.g. >>>>>> aFile writeStreamTransform: [ :stream | (ZnNewLineWriterStream on: >>>>>> stream) ] do: [ :stream | >>>>>> stream << '...' >>>>>> ] >>>>> >>>>> aFile writeStreamDo: [ :rawStream | >>>>> (ZnNewLineWriterStream on: rawStream) in: [ :stream | >>>>> stream << '...' ] ]. >>>>> >>>>> As for transformation, I'd go for some more generic (functional?) >>>>> approach like: >>>>> >>>>> aFile writeStreamDo: ([:x | ZnNewLineWriterStream on: x] pipe: [ >>>>> :stream | >>>>> stream << '...' ]). >>>> I like the first version with the (little known, but still standard >>>> and clear) #in: selector. >>>> I can't see how the second is 'better', as it looks equally >>>> 'complex' but adds a new selector, #pipe: >>>> All this, IMHO. >>> >>> It's a bit more focused on the task, that being transform incoming >>> argument. Cf. >>> >>> #asString pipe: [ :aString | ... ] >>> >>> instead of: >>> >>> [ :anObject | anObject asString in: [ :aString | ... ] ] >>> >>> IOW, scope of anObject is limited (and if using #selector you don't >>> even need to come up with a name, like the rawStream in examples >>> before). >> >> OK, maybe, what is your definition for #pipe: then ? > > Basically something like this: > > (BlockClosure | Symbol) >> pipe: aBlock > ^ [ :arg | aBlock value: (self value: arg) ] Now that I think of, it is basically nothing more than function composition, so it could have binary selector instead. That would save parentheses, so the example would look like: aFile writeStreamDo: [ :x | ZnNewLineWriterStream on: x ] ++ [ :stream | stream << '...' ]. > >>>>> Herby >>>>> >>>>>> To separate the composition from the usage? >>>>>> Thanks, >>>>>> Peter >> >

July 3, 2018

Re: [Pharo-users] Pharo 7 streams API

by Herbert VojÄÃk

Sven Van Caekenberghe wrote on 3. 7. 2018 10:55: > > >> On 3 Jul 2018, at 10:08, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: >> >> >> >> Sven Van Caekenberghe wrote on 2. 7. 2018 16:00: >>>> On 25 Jun 2018, at 12:56, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: >>>> >>>> >>>> >>>> Peter UhnÃ¡k wrote on 23. 6. 2018 15:39: >>>>> Hi, >>>>> I'm starting to familiarize myself with new streams, and one thing I've noticed is the removal of #lineEndConvention (which I use all the time). >>>>> So a statement like this >>>>> aFile writeStreamDo: [ :stream | >>>>> stream lineEndConvention: #lf. >>>>> stream << '...'> ]. >>>>> has to be written like so >>>>> aFile writeStreamDo: [ :rawStream | |stream| >>>>> stream := (ZnNewLineWriterStream on: rawStream) forLf. >>>>> stream << '...' >>>>> ]. >>>>> which feels very messy because I am mixing writing with the configuration. And I don't even take account for buffered/encoded decorators. Plus it increases the incidental complexity -- I need another variable, and I can accidentally write to the wrong stream, etc. >>>>> Would a method like #writeStream:do: (or #writeStreamTransform:do:) make sense? E.g. >>>>> aFile writeStreamTransform: [ :stream | (ZnNewLineWriterStream on: stream) ] do: [ :stream | >>>>> stream << '...' >>>>> ] >>>> >>>> aFile writeStreamDo: [ :rawStream | >>>> (ZnNewLineWriterStream on: rawStream) in: [ :stream | >>>> stream << '...' ] ]. >>>> >>>> As for transformation, I'd go for some more generic (functional?) approach like: >>>> >>>> aFile writeStreamDo: ([:x | ZnNewLineWriterStream on: x] pipe: [ :stream | >>>> stream << '...' ]). >>> I like the first version with the (little known, but still standard and clear) #in: selector. >>> I can't see how the second is 'better', as it looks equally 'complex' but adds a new selector, #pipe: >>> All this, IMHO. >> >> It's a bit more focused on the task, that being transform incoming argument. Cf. >> >> #asString pipe: [ :aString | ... ] >> >> instead of: >> >> [ :anObject | anObject asString in: [ :aString | ... ] ] >> >> IOW, scope of anObject is limited (and if using #selector you don't even need to come up with a name, like the rawStream in examples before). > > OK, maybe, what is your definition for #pipe: then ? Basically something like this: (BlockClosure | Symbol) >> pipe: aBlock ^ [ :arg | aBlock value: (self value: arg) ] >>>> Herby >>>> >>>>> To separate the composition from the usage? >>>>> Thanks, >>>>> Peter >

July 3, 2018

Re: [Pharo-users] Pharo 7 streams API

by Sven Van Caekenberghe

> On 3 Jul 2018, at 10:08, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: > > > > Sven Van Caekenberghe wrote on 2. 7. 2018 16:00: >>> On 25 Jun 2018, at 12:56, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: >>> >>> >>> >>> Peter UhnÃ¡k wrote on 23. 6. 2018 15:39: >>>> Hi, >>>> I'm starting to familiarize myself with new streams, and one thing I've noticed is the removal of #lineEndConvention (which I use all the time). >>>> So a statement like this >>>> aFile writeStreamDo: [ :stream | >>>> stream lineEndConvention: #lf. >>>> stream << '...'> ]. >>>> has to be written like so >>>> aFile writeStreamDo: [ :rawStream | |stream| >>>> stream := (ZnNewLineWriterStream on: rawStream) forLf. >>>> stream << '...' >>>> ]. >>>> which feels very messy because I am mixing writing with the configuration. And I don't even take account for buffered/encoded decorators. Plus it increases the incidental complexity -- I need another variable, and I can accidentally write to the wrong stream, etc. >>>> Would a method like #writeStream:do: (or #writeStreamTransform:do:) make sense? E.g. >>>> aFile writeStreamTransform: [ :stream | (ZnNewLineWriterStream on: stream) ] do: [ :stream | >>>> stream << '...' >>>> ] >>> >>> aFile writeStreamDo: [ :rawStream | >>> (ZnNewLineWriterStream on: rawStream) in: [ :stream | >>> stream << '...' ] ]. >>> >>> As for transformation, I'd go for some more generic (functional?) approach like: >>> >>> aFile writeStreamDo: ([:x | ZnNewLineWriterStream on: x] pipe: [ :stream | >>> stream << '...' ]). >> I like the first version with the (little known, but still standard and clear) #in: selector. >> I can't see how the second is 'better', as it looks equally 'complex' but adds a new selector, #pipe: >> All this, IMHO. > > It's a bit more focused on the task, that being transform incoming argument. Cf. > > #asString pipe: [ :aString | ... ] > > instead of: > > [ :anObject | anObject asString in: [ :aString | ... ] ] > > IOW, scope of anObject is limited (and if using #selector you don't even need to come up with a name, like the rawStream in examples before). OK, maybe, what is your definition for #pipe: then ? >>> Herby >>> >>>> To separate the composition from the usage? >>>> Thanks, >>>> Peter

July 3, 2018

Re: [Pharo-users] Pharo 7 streams API

by Herbert VojÄÃk

Sven Van Caekenberghe wrote on 2. 7. 2018 16:00: > > >> On 25 Jun 2018, at 12:56, Herbert VojÄÃk <herby(a)mailbox.sk> wrote: >> >> >> >> Peter UhnÃ¡k wrote on 23. 6. 2018 15:39: >>> Hi, >>> I'm starting to familiarize myself with new streams, and one thing I've noticed is the removal of #lineEndConvention (which I use all the time). >>> So a statement like this >>> aFile writeStreamDo: [ :stream | >>> stream lineEndConvention: #lf. >>> stream << '...'> ]. >>> has to be written like so >>> aFile writeStreamDo: [ :rawStream | |stream| >>> stream := (ZnNewLineWriterStream on: rawStream) forLf. >>> stream << '...' >>> ]. >>> which feels very messy because I am mixing writing with the configuration. And I don't even take account for buffered/encoded decorators. Plus it increases the incidental complexity -- I need another variable, and I can accidentally write to the wrong stream, etc. >>> Would a method like #writeStream:do: (or #writeStreamTransform:do:) make sense? E.g. >>> aFile writeStreamTransform: [ :stream | (ZnNewLineWriterStream on: stream) ] do: [ :stream | >>> stream << '...' >>> ] >> >> aFile writeStreamDo: [ :rawStream | >> (ZnNewLineWriterStream on: rawStream) in: [ :stream | >> stream << '...' ] ]. >> >> As for transformation, I'd go for some more generic (functional?) approach like: >> >> aFile writeStreamDo: ([:x | ZnNewLineWriterStream on: x] pipe: [ :stream | >> stream << '...' ]). > > I like the first version with the (little known, but still standard and clear) #in: selector. > I can't see how the second is 'better', as it looks equally 'complex' but adds a new selector, #pipe: > All this, IMHO. It's a bit more focused on the task, that being transform incoming argument. Cf. #asString pipe: [ :aString | ... ] instead of: [ :anObject | anObject asString in: [ :aString | ... ] ] IOW, scope of anObject is limited (and if using #selector you don't even need to come up with a name, like the rawStream in examples before). >> Herby >> >>> To separate the composition from the usage? >>> Thanks, >>> Peter > >

July 3, 2018

Re: [Pharo-users] Pharo stable version with git support

by Ben Coman

On 2 July 2018 at 23:32, dario.trussardi(a)tiscali.it < dario.trussardi(a)tiscali.it> wrote: > Ciao, > > i'm interested to port all my code to new Pharo version that > manage git support. > > I found information in pharo.org news, it talk of Pharo 6.1. > > But it run only on macOS 64bits o i can run it on Linux Ubuntu > 16.04 LTS System? > > New information - update about it? > > Thank you for every consideration, > > Dario > > At http://pharo.org/download you can either: 1. At top of page click the "GNU/Linux" to install 64-bit PharoLauncher. This gives you manage multiple 64bit or 32bit images although the latter requires some i386 dependencies to be manually installed. 2. Further down click "Pharo 6.1 for GNU/Linux (64bit)" which provides a single installation you can unzip where you like. cheers -ben

July 2, 2018