July 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] MJpeg and ZdcSocketStream>>upToAll:limit: DNU

by Sven Van Caekenberghe

That is old. I vaguely remember running that, it did work at the time. Indeed #upToAll:limit: is SocketStream specific. I guess you could just (try to) remove the #limit: part, it is just a kind of safety measure to stop when the boundary is not found (as the stream is unlimited). > On 4 Jul 2018, at 15:54, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > > Hi, > > Iâm trying to get a video stream in Pharo from a Pi video stream using this lib on the. Pi (https://github.com/jacksonliam/mjpg-streamer) > > Then I found this library on Pharo (from 2013). > https://www.min.at/prinz/?entry=entry130413-020021 > http://www.min.at/prinz/repo/mjpeg > > I had to change a method relative to Annoucment. #on:do: => #when:do: > > Now I have a problem in Pharo 7 (same in Pharo 6) with ZdcSocketStream>>upToAll:limit: (see pic) > > > > <PastedGraphic-6.png> > > > > TIA, > > CÃ©drick >

July 4, 2018

MJpeg and ZdcSocketStream>>upToAll:limit: DNU

by CÃ©drick BÃ©ler

Hi, Iâm trying to get a video stream in Pharo from a Pi video stream using this lib on the. Pi (https://github.com/jacksonliam/mjpg-streamer <https://github.com/jacksonliam/mjpg-streamer>) Then I found this library on Pharo (from 2013). https://www.min.at/prinz/?entry=entry130413-020021 <https://www.min.at/prinz/?entry=entry130413-020021> http://www.min.at/prinz/repo/mjpeg <http://www.min.at/prinz/repo/mjpeg> I had to change a method relative to Annoucment. #on:do: => #when:do: Now I have a problem in Pharo 7 (same in Pharo 6) with ZdcSocketStream>>upToAll:limit: (see pic) TIA, CÃ©drick

July 4, 2018

Re: [Pharo-users] [Pharo-dev] [ANN] New Academic Partner: SQLab

by Ben Coman

On 4 July 2018 at 17:29, Marcus Denker <marcus.denker(a)inria.fr> wrote: > The Pharo Consortium is very happy to announce that SQLab has joined as a > Academic Partner. > > About > - Software Quality Laboratory, Part of University of Novi Sad: > https://sqlab.pmf.uns.ac.rs > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > > Individuals can support Pharo via the Pharo Association: > > http://association.pharo.org Great to hear of more academic exposure. cheers -ben

July 4, 2018

Re: [Pharo-users] [Pharo-dev] [ANN] New Academic Partner: ENIT

by CÃ©drick BÃ©ler

First of all, thanks for the introduction Marcus. Just that people know, and to introduce myself, Iâm CÃ©drik BÃ©ler, associate professor at ENIT (Nation Engineering School of Tarbes). ENIT is a French generalist engineering school in Tarbes (southwest of France). Iâm very happy that ENIT is now part of the consortium as academic member. Pharo and Smalltalk have been a huge source of inspiration for me during my PHD back in 2004/2008, so Iâm really happy to have a more concrete participation now. My objectives are of two kind: (1) use Pharo as a digital workbench to teach engineering students and experiment ICT trends like IoT (PharoThings/Pi3/PiZero/ESP32), AI, web applications (client/server, MQTT, API usage with Zinc, web scrapping with XPATH and Zinc and Neoâ¦). (2) use Pharo for my research to prototype Cyber-Physical Systems (mainly in the field of predictive maintenance) and Distributed Information Systems (called Singular Information System). Iâll give a talk at ESUG as an experience feedback for point (1). In the future, Iâll present our research development around CPSâs. Iâm also interested in developing a local user group. Some students get interested. In Biarritz, ESTIA, I also have some common interest in developing such CPS researches/platforms. If people from this area are using Pharo/Smalltalk, please do not hesitate to contact me. To conclude, Iâm interested in plenty of Pharo sub-projects like (non exhaustive list): - The web/network stack (Zinc, Zodiac, Neo, XPathâ¦) - PharoThings - Bloc/Brick/Roassal - Wooden3D (VR and AR) - Workflow - Distributed networking (opportunistic, MESH, discovery, â¦) See you soon over there, Cheers, CÃ©drick BÃ©ler ENIT associate professor Discord: cedreek#8178 > Le 4 juil. 2018 Ã 11:27, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > > [ANN] New Academic Partner: ENIT > > The Pharo Consortium is very happy to announce that ENIT has joined as a Academic Partner. > > About > - ENIT Ecole Nationale d'ingÃ©nieurs de Tarbes: http://www.enit.fr > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > > Individuals can support Pharo via the Pharo Association: > > http://association.pharo.org

July 4, 2018

[ANN] New Academic Partner: SQLab

by Marcus Denker

The Pharo Consortium is very happy to announce that SQLab has joined as a Academic Partner. About - Software Quality Laboratory, Part of University of Novi Sad: https://sqlab.pmf.uns.ac.rs - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

July 4, 2018

[ANN] New Academic Partner: ENIT

by Marcus Denker

[ANN] New Academic Partner: ENIT The Pharo Consortium is very happy to announce that ENIT has joined as a Academic Partner. About - ENIT Ecole Nationale d'ingÃ©nieurs de Tarbes: http://www.enit.fr - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

July 4, 2018

Re: [Pharo-users] Pharo 7 streams API

by Steffen MÃ¤rcker

No worries! =) Let me clarify the relation between Transducers and function composition. The main component in the framework are so-called ReducingFunctions, which are the operations you want to perform. They are functions that take two arguments, an 'intermediate value' and a 'current element', and map them to a new intermediate value, i.e., rf : A x I -> A. In the example, #nextPut: is a reducing function, since it takes a stream and an element to put to the stream (I assume #nextPut: returns the stream itself). Basic operations like mapping, filtering, partitioning etc. are generic and independent of streams/collections/whatsoever. Hence, they should be resuable. This can be achieved by Transducers which are objects that take a reducing function and transform it to incorporate the additional functionality, e.g., mapping. The transducers signature is similar to xf : (A x I -> A) -> (A x I -> A). The classic approach adds these basic operations by wrapping the data (collections/streams). In contrast, transducers add them to the operations. Function composition of transducer objects chains multiple basic operations and allows to attach them to a reducing function. In fact, the implementation indeed uses function composition for this purpose. However, its up to the context how to make use of these functions, e.g., via #reduce:init:. Feel free to ask if anything remains unclear! =) Best, Steffen Am .07.2018, 16:20 Uhr, schrieb <herby(a)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

No worries! =) Let me clarify the relation between Transducers and function composition. The basic component in the framework is the so-called ReducingFunction. This are functions that take two arguments, an 'intermediate value' and a 'current element', and map them to a new intermediate value, i.e., rf : A x I -> A. In the example, #nextPut: is a reducing function, since it takes a stream and an element to put to the stream (I assume #nextPut: would return the stream). Basic operations like mapping, filtering, partitioning etc. are generic and independent of streams/collections/whatsoever. Hence, they should be resuable. This can be achieved by Transducers which are objects that take reducing functions and transform them to incorporate the additional functionality, e.g., mapping. Their signature is similar to xf : (A x I -> A) -> (A x I -> A). Function composition of transducer objects chains multiple basic operations and allows to attach them to a reducing function. In fact, the implementation indeed uses function composition for this purpose. However, its up to the context how to make use of these functions, e.g., via #reduce:init:. Feel free to ask if anything remains unclear! =) Best, Steffen Am .07.2018, 16:20 Uhr, schrieb <herby(a)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 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