- Pharo-dev - lists.pharo.org

Kafka protocol

by Robert Withers

This would be awesome in Pharo: https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Prot…. Since we cannot yet call JARs, implementing the wire protocol and API proxies would really be huge from an enterprise pharo standpoint. If other folks are interested in working on this, I could help out. Each topic has many partitions and replicates for fail-over. Say #pharo has 101 partitions with 2 replicas each, totals 300 partitions and two failovers per partition. Incoming pharo events would be partition by some algorithm. The basic consumer talks to zookeeper to get topology and then talks to partitions with "fetchers" to put blocks of in-sequence events into a shed queue. Then single-thread process them in the application level consumer, by having it consume from the shared queue. The basic consumer reads from zookeeper then writes to various partitions. regards, robert

Dec. 27, 2015

Re: [Pharo-dev] Back to Europe

by Mariano Martinez Peck

Thanks Stef (and Esteban). Sometimes people do not realize how much more effort means **doing** than *â¢talking** So....thanks a LOT for DOING! On Sun, Dec 27, 2015 at 11:51 AM, stepharo <stepharo(a)free.fr> wrote: > it is true that it was dense. > I slept the sunday between the lectures to rest a bit :) > > Stef > > Le 27/12/15 14:56, Nicolai Hess a Ã©crit : > > > > 2015-12-27 11:22 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> Hi guys >> >> We are back to Europe. >> >> - I gave 4 days lecture in cameroon and we got a lot of fun even if the >> room was fully packed. >> From 8 to 16h30 with Carambars >> >> - Then in Togo I gave one afternoon lecture to University catholic of >> Lome. >> - Then Esteban arrived and we gave 4 days lecture from 8 to 17h in >> Universtity of Lome. >> >> In the future we hope to get another lecture in Lome - probably two. >> >> People from Center Togo (Paillard and Sabirou) jumped on pharo and >> started to teach it just one week after I went there in September and they >> love it. I hope that they will write a paper for IWST. >> They hope their students will create software for companies within one or >> tewo years. >> >> >> People of the university of Togo may be interested to develop software >> with Pharo. >> >> The TinyBlog tutorial went really really well. Thanks Olivier Auverlot >> for the first version. I'm happy that I push it so much. >> https://ci.inria.fr/pharo-contribution/job/TinyBlogTutorial/6/artifact/book… >> I'm adding a REST chapter. Once the tutorial is finished we will >> translate it in english. >> >> I may go back to togo to give a lecture to teachers in May. We will see :) >> >> Since our flight was cancelled (yes we woke two time at 3h45 and 1h in >> the morning) I wrote the following tutorial >> based on the great lecture esteban did on Voyage. >> >> >> <https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre…> >> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… >> >> Stef >> > > > You are incredible > > > -- Mariano http://marianopeck.wordpress.com

Dec. 27, 2015

Re: [Pharo-dev] Back to Europe

by stepharo

it is true that it was dense. I slept the sunday between the lectures to rest a bit :) Stef Le 27/12/15 14:56, Nicolai Hess a Ã©crit : > > > 2015-12-27 11:22 GMT+01:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi guys > > We are back to Europe. > > - I gave 4 days lecture in cameroon and we got a lot of fun even > if the room was fully packed. > From 8 to 16h30 with Carambars > > - Then in Togo I gave one afternoon lecture to University catholic > of Lome. > - Then Esteban arrived and we gave 4 days lecture from 8 to 17h in > Universtity of Lome. > > In the future we hope to get another lecture in Lome - probably two. > > People from Center Togo (Paillard and Sabirou) jumped on pharo and > started to teach it just one week after I went there in September > and they love it. I hope that they will write a paper for IWST. > They hope their students will create software for companies within > one or tewo years. > > > People of the university of Togo may be interested to develop > software with Pharo. > > The TinyBlog tutorial went really really well. Thanks Olivier > Auverlot for the first version. I'm happy that I push it so much. > https://ci.inria.fr/pharo-contribution/job/TinyBlogTutorial/6/artifact/book… > I'm adding a REST chapter. Once the tutorial is finished we > will translate it in english. > > I may go back to togo to give a lecture to teachers in May. We > will see :) > > Since our flight was cancelled (yes we woke two time at 3h45 and > 1h in the morning) I wrote the following tutorial > based on the great lecture esteban did on Voyage. > > https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… > > Stef > > > > You are incredible

Dec. 27, 2015

Re: [Pharo-dev] Back to Europe

by Nicolai Hess

2015-12-27 11:22 GMT+01:00 stepharo <stepharo(a)free.fr>: > Hi guys > > We are back to Europe. > > - I gave 4 days lecture in cameroon and we got a lot of fun even if the > room was fully packed. > From 8 to 16h30 with Carambars > > - Then in Togo I gave one afternoon lecture to University catholic of > Lome. > - Then Esteban arrived and we gave 4 days lecture from 8 to 17h in > Universtity of Lome. > > In the future we hope to get another lecture in Lome - probably two. > > People from Center Togo (Paillard and Sabirou) jumped on pharo and started > to teach it just one week after I went there in September and they love it. > I hope that they will write a paper for IWST. > They hope their students will create software for companies within one or > tewo years. > > > People of the university of Togo may be interested to develop software > with Pharo. > > The TinyBlog tutorial went really really well. Thanks Olivier Auverlot for > the first version. I'm happy that I push it so much. > https://ci.inria.fr/pharo-contribution/job/TinyBlogTutorial/6/artifact/book… > I'm adding a REST chapter. Once the tutorial is finished we will > translate it in english. > > I may go back to togo to give a lecture to teachers in May. We will see :) > > Since our flight was cancelled (yes we woke two time at 3h45 and 1h in the > morning) I wrote the following tutorial > based on the great lecture esteban did on Voyage. > > > <https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre…> > https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… > > Stef > You are incredible

Dec. 27, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Nicolas Cellier

2015-12-27 2:49 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On Sun, Dec 27, 2015 at 6:13 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > > > 2015-12-25 2:03 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> > >> Ben, > >> > >> _,,,^..^,,,_ (phone) > >> > >> > On Dec 4, 2015, at 12:49 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> > > >> >> On Fri, Dec 4, 2015 at 4:23 AM, Nicolai Hess <nicolaihess(a)gmail.com> > >> >> wrote: > >> >> > >> >> > >> >> 2015-12-03 14:48 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> >>> > >> >>> On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe < > sven(a)stfx.eu> > >> >>> wrote: > >> >>>> > >> >>>>> On 02 Dec 2015, at 15:21, Nicolai Hess <nicolaihess(a)gmail.com> > >> >>>>> wrote: > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> 2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> >>>>> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba < > tudor(a)tudorgirba.com> > >> >>>>> wrote: > >> >>>>>> Hi, > >> >>>>>> > >> >>>>>>> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> > wrote: > >> >>>>>>> > >> >>>>>>> @Doru > >> >>>>>>> Youâre missing the point: #anyOne *fails* for empty collections. > >> >>>>>> > >> >>>>>> I am not missing the point at all. I am saying that if you want > >> >>>>>> sum: > >> >>>>>> to be generic, it cannot assume a specific Zero object. > >> >>>>>> > >> >>>>>> And sum: should be generic because of its name. > >> >>>>> > >> >>>>> I am missing understanding the other use cases. Can you describe > >> >>>>> further the generic nature of #sum & #sum: ? I would have thought > >> >>>>> by > >> >>>>> default they only applied to numbers. > >> >>>>> > >> >>>>> sum can be applied to anything that supports #+, not only numbers > >> >>>>> sum: can be applied to any collection with a block that return > some > >> >>>>> object that supports #+ > >> >>> > >> >>> To me this is a mis-application of polymorphism, that just because > >> >>> something responds to #+ it should be summable. We have overloaded > the > >> >>> semantics of #+ to mean both numeric addition and > >> >>> concatenation/membership, but technically "summation" relates only > to > >> >>> numeric addition. > >> >> > >> >> > >> >> I didn't wanted to argue for or against any change. I just wanted to > >> >> clarify > >> >> that there are situations in which a generic sum/sum: that throws an > >> >> error > >> >> on empty collections and don't assume a null value makes sense. > >> >> > >> >> > >> >>> > >> >>> > >> >>> https://www.google.com.au/search?q=define+sum&oq=define+sum > >> >>> > >> >>> > >> >>> > https://www.google.com.au/search?q=define+concatenate&oq=define+concatenate > >> >>> > >> >>> For example... > >> >>> > >> >>> * KMModifier implements #+ so what is the expected semantic of > " { > >> >>> KMModifier shift . KMModifier meta} sum " ? > >> >>> To me this is more of a concatenation/join/union facility rather > than > >> >>> numeric addition. (btw, that expression actually fails since > >> >>> KMModifier does not understand minus #- ) . > >> >>> > >> >>> * String implements #+ and " { '1' . '2' } sum " --> '3', so > >> >>> actually its doing numeric addition. However " { 'a' . 'b' } sum " > >> >>> produces an error. > >> >>> > >> >>> So actually there seem some existing problems with summing > >> >>> non-numerics. What examples work? > >> >>> > >> >>> * Trait classes implement both #+ and #- , but the semantic seems > >> >>> more to do with membership than numeric addition. I don't how how > to > >> >>> produce an example of using #sum against traits. > >> >>> > >> >>> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 > + > >> >>> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not > >> >>> cause any error in this case. > >> >>> > >> >>> > >> >>> cheers -ben > >> >>> > >> >>> > >> >>>>> > >> >>>>> therefore you can not assume 0 (<- a number) is a proper initial > >> >>>>> value > >> >>>>> therefore you *need* to work with #anyOne > >> >>>>> and as you can not assume a proper initial value, you can not > assume > >> >>>>> a > >> >>>>> default value for empty collections > >> >>>>> -> it should throw an error. If you (the caller of the function) > >> >>>>> knows > >> >>>>> what to do with an empty collection you have > >> >>>>> to check, or call inject:into: directly, with a proper initial > >> >>>>> value. > >> >>>> > >> >>>> I am sorry but I am getting really tired of this, you should read > >> >>>> what > >> >>>> is being said. > >> >> > >> >> > >> >> do that change, I am not against it. Ben just asked for an example > and > >> >> I > >> >> thought it would be helpful. > >> > > >> > It was helpful :) It evolved my thinking. Now thinking further, I > >> > wonder how returning 0 will work with applications using units like > >> > Aconcagua, and if it would over-complicate things to do something > >> > like... > >> > > >> > Collection>>sum > >> > | sum sample | > >> > self isEmpty ifTrue: [ ^ ArithmeticZero ]. > >> > sample := self anyOne. > >> > sum := self inject: sample into: [ :accum :each | accum + each > ]. > >> > ^ sum - sample > >> > > >> > ArithmeticZero class >> + anObject > >> > ^anObject > >> > >> surely you mean > >> > >> Collection>>sum > >> ^self inject: ArithmeticZero into: [ :accum :each | accum + each ] > >> > >> ArithmeticZero class >> + anObject > >> ^anObject > >> > >> and I'd optimise as > >> Collection>>sum > >> | sum | > >> sum := ArithmeticZero. > >> self do: [ :each | sum := sum + each ]. > >> ^sum > >> > >> But in with those that want an error and would use either > >> Collection>>sum > >> ^self inject: self anyOne species zero > >> into: [ :accum :each | accum + each ] > >> > >> or > >> > >> Collection>>sum > >> | sum | > >> sum := self anyOne species zero. > >> self do: [ :each | sum := sum + each ]. > >> ^sum > >> > > > > Not bad, but the class cannot allways determine the correct zero. > > For example Matrix is too generic and can't guess about dimensions which > are > > instance specific. > > So zero should be instance specific. > > So if "species zero" isn't good to implement summing, could we use it > to delegate raising an error. > For example, cases like Matrix where summing an empty collection > should produce an error, this could be done by ArithmeticZero > delegating to the second operand to raise the error there? > > ArithmeticZero >> + operand > operand species zero + operand > > Matrix class >> zero > ErrorZeroDoesn'tMakeSense new signal. > > ? > cheers -ben > > No, becauseItMakesSenseAtInstanceSide, I'd rather say it like this: if we want to adopt injecting zero into the sum, then let's make it an instance side message rather than class side. It's a rather elegant solution, but remember only for a minor problem: - That's only necessary for unordered Collection (since Sequenceable can just inject self first and start looping at index 2). - And that does not solve the case of empty collections which cannot use anyOne Nicolas

Dec. 27, 2015

Re: [Pharo-dev] Back to Europe

by Ben Coman

On Sun, Dec 27, 2015 at 9:22 PM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > We are back to Europe. > > - I gave 4 days lecture in cameroon and we got a lot of fun even if the room > was fully packed. > From 8 to 16h30 with Carambars > > - Then in Togo I gave one afternoon lecture to University catholic of Lome. > - Then Esteban arrived and we gave 4 days lecture from 8 to 17h in > Universtity of Lome. > > In the future we hope to get another lecture in Lome - probably two. > > People from Center Togo (Paillard and Sabirou) jumped on pharo and started > to teach it just one week after I went there in September and they love it. > I hope that they will write a paper for IWST. > They hope their students will create software for companies within one or > tewo years. > > > People of the university of Togo may be interested to develop software with > Pharo. > > The TinyBlog tutorial went really really well. Thanks Olivier Auverlot for > the first version. I'm happy that I push it so much. > https://ci.inria.fr/pharo-contribution/job/TinyBlogTutorial/6/artifact/book… > I'm adding a REST chapter. Once the tutorial is finished we will > translate it in english. > > I may go back to togo to give a lecture to teachers in May. We will see :) > > Since our flight was cancelled (yes we woke two time at 3h45 and 1h in the > morning) I wrote the following tutorial > based on the great lecture esteban did on Voyage. > > https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… > > Stef Great to hear of their interest, and that Pharo is providing enabling technology for Africa. I checked a map just for curiousity... http://www.distancefromto.net/distance-from/Togo/to/Cameroon cheers -ben

Dec. 27, 2015

Back to Europe

by stepharo

Hi guys We are back to Europe. - I gave 4 days lecture in cameroon and we got a lot of fun even if the room was fully packed. From 8 to 16h30 with Carambars - Then in Togo I gave one afternoon lecture to University catholic of Lome. - Then Esteban arrived and we gave 4 days lecture from 8 to 17h in Universtity of Lome. In the future we hope to get another lecture in Lome - probably two. People from Center Togo (Paillard and Sabirou) jumped on pharo and started to teach it just one week after I went there in September and they love it. I hope that they will write a paper for IWST. They hope their students will create software for companies within one or tewo years. People of the university of Togo may be interested to develop software with Pharo. The TinyBlog tutorial went really really well. Thanks Olivier Auverlot for the first version. I'm happy that I push it so much. https://ci.inria.fr/pharo-contribution/job/TinyBlogTutorial/6/artifact/book… I'm adding a REST chapter. Once the tutorial is finished we will translate it in english. I may go back to togo to give a lecture to teachers in May. We will see :) Since our flight was cancelled (yes we woke two time at 3h45 and 1h in the morning) I wrote the following tutorial based on the great lecture esteban did on Voyage. https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… Stef

Dec. 27, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Ben Coman

On Sun, Dec 27, 2015 at 6:13 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2015-12-25 2:03 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> Ben, >> >> _,,,^..^,,,_ (phone) >> >> > On Dec 4, 2015, at 12:49 AM, Ben Coman <btc(a)openinworld.com> wrote: >> > >> >> On Fri, Dec 4, 2015 at 4:23 AM, Nicolai Hess <nicolaihess(a)gmail.com> >> >> wrote: >> >> >> >> >> >> 2015-12-03 14:48 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >>> >> >>> On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> >>> wrote: >> >>>> >> >>>>> On 02 Dec 2015, at 15:21, Nicolai Hess <nicolaihess(a)gmail.com> >> >>>>> wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>> 2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >>>>> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> >> >>>>> wrote: >> >>>>>> Hi, >> >>>>>> >> >>>>>>> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >>>>>>> >> >>>>>>> @Doru >> >>>>>>> Youâre missing the point: #anyOne *fails* for empty collections. >> >>>>>> >> >>>>>> I am not missing the point at all. I am saying that if you want >> >>>>>> sum: >> >>>>>> to be generic, it cannot assume a specific Zero object. >> >>>>>> >> >>>>>> And sum: should be generic because of its name. >> >>>>> >> >>>>> I am missing understanding the other use cases. Can you describe >> >>>>> further the generic nature of #sum & #sum: ? I would have thought >> >>>>> by >> >>>>> default they only applied to numbers. >> >>>>> >> >>>>> sum can be applied to anything that supports #+, not only numbers >> >>>>> sum: can be applied to any collection with a block that return some >> >>>>> object that supports #+ >> >>> >> >>> To me this is a mis-application of polymorphism, that just because >> >>> something responds to #+ it should be summable. We have overloaded the >> >>> semantics of #+ to mean both numeric addition and >> >>> concatenation/membership, but technically "summation" relates only to >> >>> numeric addition. >> >> >> >> >> >> I didn't wanted to argue for or against any change. I just wanted to >> >> clarify >> >> that there are situations in which a generic sum/sum: that throws an >> >> error >> >> on empty collections and don't assume a null value makes sense. >> >> >> >> >> >>> >> >>> >> >>> https://www.google.com.au/search?q=define+sum&oq=define+sum >> >>> >> >>> >> >>> https://www.google.com.au/search?q=define+concatenate&oq=define+concatenate >> >>> >> >>> For example... >> >>> >> >>> * KMModifier implements #+ so what is the expected semantic of " { >> >>> KMModifier shift . KMModifier meta} sum " ? >> >>> To me this is more of a concatenation/join/union facility rather than >> >>> numeric addition. (btw, that expression actually fails since >> >>> KMModifier does not understand minus #- ) . >> >>> >> >>> * String implements #+ and " { '1' . '2' } sum " --> '3', so >> >>> actually its doing numeric addition. However " { 'a' . 'b' } sum " >> >>> produces an error. >> >>> >> >>> So actually there seem some existing problems with summing >> >>> non-numerics. What examples work? >> >>> >> >>> * Trait classes implement both #+ and #- , but the semantic seems >> >>> more to do with membership than numeric addition. I don't how how to >> >>> produce an example of using #sum against traits. >> >>> >> >>> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + >> >>> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not >> >>> cause any error in this case. >> >>> >> >>> >> >>> cheers -ben >> >>> >> >>> >> >>>>> >> >>>>> therefore you can not assume 0 (<- a number) is a proper initial >> >>>>> value >> >>>>> therefore you *need* to work with #anyOne >> >>>>> and as you can not assume a proper initial value, you can not assume >> >>>>> a >> >>>>> default value for empty collections >> >>>>> -> it should throw an error. If you (the caller of the function) >> >>>>> knows >> >>>>> what to do with an empty collection you have >> >>>>> to check, or call inject:into: directly, with a proper initial >> >>>>> value. >> >>>> >> >>>> I am sorry but I am getting really tired of this, you should read >> >>>> what >> >>>> is being said. >> >> >> >> >> >> do that change, I am not against it. Ben just asked for an example and >> >> I >> >> thought it would be helpful. >> > >> > It was helpful :) It evolved my thinking. Now thinking further, I >> > wonder how returning 0 will work with applications using units like >> > Aconcagua, and if it would over-complicate things to do something >> > like... >> > >> > Collection>>sum >> > | sum sample | >> > self isEmpty ifTrue: [ ^ ArithmeticZero ]. >> > sample := self anyOne. >> > sum := self inject: sample into: [ :accum :each | accum + each ]. >> > ^ sum - sample >> > >> > ArithmeticZero class >> + anObject >> > ^anObject >> >> surely you mean >> >> Collection>>sum >> ^self inject: ArithmeticZero into: [ :accum :each | accum + each ] >> >> ArithmeticZero class >> + anObject >> ^anObject >> >> and I'd optimise as >> Collection>>sum >> | sum | >> sum := ArithmeticZero. >> self do: [ :each | sum := sum + each ]. >> ^sum >> >> But in with those that want an error and would use either >> Collection>>sum >> ^self inject: self anyOne species zero >> into: [ :accum :each | accum + each ] >> >> or >> >> Collection>>sum >> | sum | >> sum := self anyOne species zero. >> self do: [ :each | sum := sum + each ]. >> ^sum >> > > Not bad, but the class cannot allways determine the correct zero. > For example Matrix is too generic and can't guess about dimensions which are > instance specific. > So zero should be instance specific. So if "species zero" isn't good to implement summing, could we use it to delegate raising an error. For example, cases like Matrix where summing an empty collection should produce an error, this could be done by ArithmeticZero delegating to the second operand to raise the error there? ArithmeticZero >> + operand operand species zero + operand Matrix class >> zero ErrorZeroDoesn'tMakeSense new signal. ? cheers -ben

Dec. 27, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Nicolas Cellier

2015-12-25 2:03 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Ben, > > _,,,^..^,,,_ (phone) > > > On Dec 4, 2015, at 12:49 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > >> On Fri, Dec 4, 2015 at 4:23 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> > >> > >> 2015-12-03 14:48 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >>> > >>> On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > >>> wrote: > >>>> > >>>>> On 02 Dec 2015, at 15:21, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >>>>> > >>>>> > >>>>> > >>>>> 2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >>>>> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> > >>>>> wrote: > >>>>>> Hi, > >>>>>> > >>>>>>> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> wrote: > >>>>>>> > >>>>>>> @Doru > >>>>>>> Youâre missing the point: #anyOne *fails* for empty collections. > >>>>>> > >>>>>> I am not missing the point at all. I am saying that if you want sum: > >>>>>> to be generic, it cannot assume a specific Zero object. > >>>>>> > >>>>>> And sum: should be generic because of its name. > >>>>> > >>>>> I am missing understanding the other use cases. Can you describe > >>>>> further the generic nature of #sum & #sum: ? I would have thought by > >>>>> default they only applied to numbers. > >>>>> > >>>>> sum can be applied to anything that supports #+, not only numbers > >>>>> sum: can be applied to any collection with a block that return some > >>>>> object that supports #+ > >>> > >>> To me this is a mis-application of polymorphism, that just because > >>> something responds to #+ it should be summable. We have overloaded the > >>> semantics of #+ to mean both numeric addition and > >>> concatenation/membership, but technically "summation" relates only to > >>> numeric addition. > >> > >> > >> I didn't wanted to argue for or against any change. I just wanted to > clarify > >> that there are situations in which a generic sum/sum: that throws an > error > >> on empty collections and don't assume a null value makes sense. > >> > >> > >>> > >>> > >>> https://www.google.com.au/search?q=define+sum&oq=define+sum > >>> > >>> > https://www.google.com.au/search?q=define+concatenate&oq=define+concatenate > >>> > >>> For example... > >>> > >>> * KMModifier implements #+ so what is the expected semantic of " { > >>> KMModifier shift . KMModifier meta} sum " ? > >>> To me this is more of a concatenation/join/union facility rather than > >>> numeric addition. (btw, that expression actually fails since > >>> KMModifier does not understand minus #- ) . > >>> > >>> * String implements #+ and " { '1' . '2' } sum " --> '3', so > >>> actually its doing numeric addition. However " { 'a' . 'b' } sum " > >>> produces an error. > >>> > >>> So actually there seem some existing problems with summing > >>> non-numerics. What examples work? > >>> > >>> * Trait classes implement both #+ and #- , but the semantic seems > >>> more to do with membership than numeric addition. I don't how how to > >>> produce an example of using #sum against traits. > >>> > >>> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 + > >>> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not > >>> cause any error in this case. > >>> > >>> > >>> cheers -ben > >>> > >>> > >>>>> > >>>>> therefore you can not assume 0 (<- a number) is a proper initial > value > >>>>> therefore you *need* to work with #anyOne > >>>>> and as you can not assume a proper initial value, you can not assume > a > >>>>> default value for empty collections > >>>>> -> it should throw an error. If you (the caller of the function) > knows > >>>>> what to do with an empty collection you have > >>>>> to check, or call inject:into: directly, with a proper initial value. > >>>> > >>>> I am sorry but I am getting really tired of this, you should read what > >>>> is being said. > >> > >> > >> do that change, I am not against it. Ben just asked for an example and I > >> thought it would be helpful. > > > > It was helpful :) It evolved my thinking. Now thinking further, I > > wonder how returning 0 will work with applications using units like > > Aconcagua, and if it would over-complicate things to do something > > like... > > > > Collection>>sum > > | sum sample | > > self isEmpty ifTrue: [ ^ ArithmeticZero ]. > > sample := self anyOne. > > sum := self inject: sample into: [ :accum :each | accum + each ]. > > ^ sum - sample > > > > ArithmeticZero class >> + anObject > > ^anObject > > surely you mean > > Collection>>sum > ^self inject: ArithmeticZero into: [ :accum :each | accum + each ] > > ArithmeticZero class >> + anObject > ^anObject > > and I'd optimise as > Collection>>sum > | sum | > sum := ArithmeticZero. > self do: [ :each | sum := sum + each ]. > ^sum > > But in with those that want an error and would use either > Collection>>sum > ^self inject: self anyOne species zero > into: [ :accum :each | accum + each ] > > or > > Collection>>sum > | sum | > sum := self anyOne species zero. > self do: [ :each | sum := sum + each ]. > ^sum > > Not bad, but the class cannot allways determine the correct zero. For example Matrix is too generic and can't guess about dimensions which are instance specific. So zero should be instance specific. Nicolas

Dec. 26, 2015

Re: [Pharo-dev] VM error in Arch Linux

by SaÅ¡a JaniÅ¡ka

On Uto, 2015-12-22 at 11:56 +0100, Ferlicot D. Cyril wrote: > Since last week a new VM is use for Pharo 5 beta. Beginning Pharo user here...I had the same problem on my Debian box: "This interpreter (vers. 6505) cannot read image file (vers. 6521)." > You need to download the new VM on http://files.pharo.org/vm/pharo-spu > r32/. Then I downloaded the new VM image and tried to use it with latest Pharo Launcher ('Bleeding Edge'), but now I get: "This interpreter (vers. 6521) cannot read image file (vers. 6505)."Â which is kind of catch-22 situation... > Then you need to update Pharo Launcher. ...and it looks that I do not have updated Pharo Launcher. > For now the easiest way I think is to enable the development mode in > PharoLauncher, go in Monticello, and load the last version of Pharo > Launcher core. Tried that as well, but didn't work. > Later I think that a new release of Pharo Launcher will make thing > easier. Let me say that the potential of Pharo Launcher is really great - it allows (if I got it right) to have many development machines available via different VMs, while still keeping developer's machine in sane state which cannot be said when one does regular development with other (mostly compiled) languages, which is "simply wonderful!". Now I wonder if you can provide any further hint how to resolve the above? Is there a plan that in the future Pharo Launcher will become regular part of 'normal' Pharo image? I know that probably there would be more luch with V4.0, but I simply would like to try latest code eagerly anticipating the day to try 64bit VM. Still, kudos to all Pharo devs for providing human development environment in the days when things are going insane all around us. Sincerely, Gour -- As a lamp in a windless place does not waver, so the transcendentalist, whose mind is controlled, remains always steady in his meditation on the transcendent self.

Dec. 26, 2015