December 2015 - Pharo-dev - lists.pharo.org

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

by Tudor Girba

Hi, I cannot seem to agree with the current line of reasoning, so I am withdrawing from this debate. Itâs late in the year and I know I need a break, so it is likely that I am missing something obvious or that I am just persisting in some sort of bike-shedding point of view :). Thanks for keeping up with this. I wish you all a lovely holiday and see you next year! Doru > On Dec 20, 2015, at 8:23 PM, Max Leske <maxleske(a)gmail.com> wrote: > > I did a pass on all the changes that would be required (whatever the outcome of this discussion). Looks easy enough. One interesting point: FloatArray>>sum is implemented as a primitive in the FloatArrayPlugin and the zero element is explicitly defined as 0.0. The primitive will not fail for an empty collection but return 0.0. That would be in line with our new definition of #sum. > > > One other thing: should the old selectors be marked as deprecated rather than being removed? I think thatâs the general policy, right? > > Cheers, > Max > > >> On 20 Dec 2015, at 18:19, Max Leske <maxleske(a)gmail.com> wrote: >> >> >>> On 20 Dec 2015, at 15:26, Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> On Mon, Dec 21, 2015 at 12:43 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> Doru, >>>> >>>> For me this whole discussion started because you (the standpoint that you take) hijacked the best selector (#sum) for a use case that is much less common than adding a collection of numbers which should give 0 when empty (you hijack it by not wanting to return 0, which I totally understand, but doing so you redefine the meaning/semantics). >>>> >>>> Max's point is to make everything more consistent and remove some API. I support that too. >>>> >>>> Now, I like Max's proposal. >>>> >>>> But, you know, my conclusion when the thread ended was that it might be better to throw all these selectors away, since #inject:into: covers most use cases at least as well and at least as clear. >>>> >>>> Sven >>>> >>>>> On 20 Dec 2015, at 14:10, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Could we not have sum, but sumNumbers instead? So, we would end up with: >>>>> >>>>> sum:ifEmpty: >>>>> sum: (with error) >>>>> sumNumbers (without error) >>>>> >>>>> From the outside, #sum: looks like it should parameterize #sum, but the implementation is actually different. So, given that in this implementation #sum is not a special case of #sum: the two should be named differently to reflect that difference. Hence my proposal is to keep #sumNumbers instead of #sum. >>> >>> >>> I agree somewhat with Duro to avoid #sum and #sum: having different semantics, >>> but I agree more with Sven about keeping #sum for numbers only and >>> returning zero, >>> so why not turn Doru's suggestion around... >>> >>> #sum (empty --> 0) >>> #sumBy: (empty --> error) >>> #sumBy: ifEmpty: (empty --> no error) >>> >>> alternatively could be #sumUsing: or #sumWith: or something similar. >> >> Also a good idea. However, looking at the methods on Collection, the pattern is usually #message and #message:, e.g. #sorted and #sorted:. There used to be #sortBy: but it was removed because the view was that the protocol semantics should be the same across all methods. >> The current case is a bit different of course since weâre dealing with the problem of the zero element which doesnât arise in most other cases. Still, I think from a users point of view it would be strange to have to use #sumBy: when every other message pair uses the #message / #message: pattern. >> >> I feel that this argument (thanks Ben :) ) is also a valid point against Doruâs argument for #sumNumbers. While #sumNumbers may *technically* be the best name (which we canât seem to agree onâ¦), #sum, #sum: and #sum:ifEmpty: form a triple that naturally fits into the naming protocol applied elsewhere. >> >> >> Cheers, >> Max >> >>> >>> >>> >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>>> On Dec 20, 2015, at 1:47 PM, Max Leske <maxleske(a)gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> On 20 Dec 2015, at 13:43, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >>>>>>> >>>>>>> Max, >>>>>>> >>>>>>> sum: aBlock ifEmpty: emptyBlock needs to obtain the sample evaluating the block. >>>>>>> >>>>>>> sum: aBlock ifEmpty: emptyBlock >>>>>>> | sum sample | >>>>>>> self isEmpty ifTrue: [ ^ emptyBlock value ]. >>>>>>> sample := aBlock value: self anyOne. >>>>>>> sum := self >>>>>>> inject: sample >>>>>>> into: [ :accum :each | accum + (aBlock value: each) ]. >>>>>>> ^ sum - sample >>>>>> >>>>>> >>>>>> Thanks! Missed that. >>>>>> >>>>>>> >>>>>>> On Sun, Dec 20, 2015 at 8:59 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>>>>> I would like to wrap up this discussion. >>>>>>> >>>>>>> >>>>>>>> On 05 Dec 2015, at 18:14, stepharo <stepharo(a)free.fr> wrote: >>>>>>>> >>>>>>>> So what is the conclusion? >>>>>>>> I like the idea of Esteban M to have iterator because it moves some behavior out of core classes. >>>>>>>> >>>>>>>> [[[ >>>>>>>> >>>>>>>> aCollection arithmetic sum: [...] or.... aCollection >>>>>>>> arithmetic avg. >>>>>>>> >>>>>>>> ]]] >>>>>>>> >>>>>>> >>>>>>> While I think that iterators are an intriguing idea I also believe that they are beyond the scope of this issue. If anybody wants to follow up on iterators (or unit types for that matter) please start a new thread / issue. >>>>>>> >>>>>>> >>>>>>> I propose to use Svenâs version for #sum:ifEmpty:. The result would be these three methods: >>>>>>> >>>>>>> sum >>>>>>> ^ self >>>>>>> sum: [ :each | each ] >>>>>>> ifEmpty: [ 0 ] >>>>>>> >>>>>>> sum: aBlock >>>>>>> ^ self >>>>>>> sum: aBlock >>>>>>> ifEmpty: [ self errorEmptyCollection ] >>>>>>> >>>>>>> sum: aBlock ifEmpty: emptyBlock >>>>>>> | sum sample | >>>>>>> self isEmpty ifTrue: [ ^ emptyBlock value ]. >>>>>>> sample := self anyOne. >>>>>>> sum := self >>>>>>> inject: sample >>>>>>> into: [ :accum :each | accum + (aBlock value: each) ]. >>>>>>> ^ sum - sample >>>>>>> >>>>>>> >>>>>>> Iâve attached a couple of benchmark results below. To me they show that >>>>>>> 1. the new implementation is maybe a tiny bit slower but insignificantly so (if youâre going for performance youâll probably write your own optimised version anyway) >>>>>>> 2. there is no need to duplicate the code (like #sum and #sum: currently do). Itâs perfectly fine to delegate to #sum:ifEmpty: >>>>>>> >>>>>>> >>>>>>> >>>>>>> In addition to the above changes I would like to remove #detectSum: (-> #sum:) and #sumNumbers (-> #sum). >>>>>>> >>>>>>> >>>>>>> Note that once we agree on changing this API, we will need to also change #detectMin:, #detectMax:, #min, #max as well as all overrides (e.g. RunArray, Interval) of these and of #sum et. al. to stay consistent. The changes would of course be in line with this change, such that every operation has a unary selector with a sensible default, one that takes a block and throws an error for empty collections and a third that takes a block for the iteration and one for the empty case. >>>>>>> >>>>>>> >>>>>>> Please cast your vote for these changes: >>>>>>> >>>>>>> 1. Do you agree to changing #sum and #sum: in the suggested way? >>> yes >>> >>>>>>> 2. Do you agree to the removal of #detectSum:? >>> ?? (not familiar) >>> >>>>>>> 3. Do you agree to the removal of #sumNumbers? >>> yes >>> >>>>>>> 4. Do you agree that the #max and #min selectors also need to be adapted? >>> ?? (not familiar) >> > -- www.tudorgirba.com www.feenk.com "Speaking louder won't make the point worthier."

Dec. 20, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort

by Thierry Goubier

Hi Mariano, Le 20/12/2015 19:54, Mariano Martinez Peck a Ã©crit : > Hi Dimitri, Dave et all. > > First let me do a little disclaimer. Regarding the developments itself > of this sponsorship, we discussed about the topics I said in the first > email. However, those are not written in stone and that's why I also > asked for feedback. As you know, Pharo has relatively little resources > so those should be well spent. If we decide to take a spin into a > project X, it doesn't mean other projects are not worth. It simply means > that we think X will be the most useful for the time being. > > One of the final goals of the discusses topics, is to improve a bit the > infrastructure for using Pharo as scripting (imagine Coral). For such a > thing, we believe that improving FileSystem and OSProcess-like is a good > first step to improve the underlying infrastructure. Would we have access then to a command-line oriented minimal Pharo image? > That being said, I of course like the idea of distributing processing > across multiple images. No wonder, my PhD tool (Marea) and related > sub-projects (Fuel, Ghost proxies, etc) have something to do with the > mentioned topic. Dave already mentioned about RemoteTask, which was > something I was about to mention. There is also Seamless project (now > used by Remote Debugger stuff) and quite other tools. Finally, I think > this project may have a big percentage that could be considered as > "research". So having a PhD / master student working on this would also > be nice. In fact, maybe Denis Kudriashov might work on that topic??? (he > is now in RMOD team). > > Also, not that forking the image is not my main short-term goal. As > said, I will experiment first with a simple tool to execute OS commands > that would be FFI based, trying to make async operations, and that would > help in most cases. Maybe for those that are not supported, then > fallback in OSProcess. Note that Dave (OSProcess author) is very helpful > with me and we are discussing together about this. My guess is that, at least on Linux/Unix, that FFI will be exactly the same as the one used/expressed by the OSProcess plugin, that is popen/system. Now, given some of the difficulties seen when dealing with external processes, I'd be wary of the "async" side of things. Random failures seemingly linked to signal loss are certainly not something I'd like to debug. Something interesting and powerful would be pseudo-tty support. It would allow a Pharo image to maintain an open connection to a shell, for example, reducing the cost and latency of launching external commands and maintaining a context. Regards, Thierry

Dec. 20, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort

by Dimitris Chloupis

yeah I completely agree that any improvement is more than welcomed. Thanks I will check out RemoteTask and Seamless :) On Sun, Dec 20, 2015 at 8:55 PM Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi Dimitri, Dave et all. > > First let me do a little disclaimer. Regarding the developments itself of > this sponsorship, we discussed about the topics I said in the first email. > However, those are not written in stone and that's why I also asked for > feedback. As you know, Pharo has relatively little resources so those > should be well spent. If we decide to take a spin into a project X, it > doesn't mean other projects are not worth. It simply means that we think X > will be the most useful for the time being. > > One of the final goals of the discusses topics, is to improve a bit the > infrastructure for using Pharo as scripting (imagine Coral). For such a > thing, we believe that improving FileSystem and OSProcess-like is a good > first step to improve the underlying infrastructure. > > That being said, I of course like the idea of distributing processing > across multiple images. No wonder, my PhD tool (Marea) and related > sub-projects (Fuel, Ghost proxies, etc) have something to do with the > mentioned topic. Dave already mentioned about RemoteTask, which was > something I was about to mention. There is also Seamless project (now used > by Remote Debugger stuff) and quite other tools. Finally, I think this > project may have a big percentage that could be considered as "research". > So having a PhD / master student working on this would also be nice. In > fact, maybe Denis Kudriashov might work on that topic??? (he is now in > RMOD team). > > Also, not that forking the image is not my main short-term goal. As said, > I will experiment first with a simple tool to execute OS commands that > would be FFI based, trying to make async operations, and that would help in > most cases. Maybe for those that are not supported, then fallback in > OSProcess. Note that Dave (OSProcess author) is very helpful with me and we > are discussing together about this. > > Torsten, thanks about OS. I will check out that project. I started with > OSProcess and Limbo. So it's good to have another to check. > > I will try to make the survey starting next week. > > > > > > On Sun, Dec 20, 2015 at 2:17 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> how the communication is happening via Fuel , does it save to a fuel file >> or it does it through memory some way ? >> >> On Sun, Dec 20, 2015 at 6:04 PM David T. Lewis <lewis(a)mail.msen.com> >> wrote: >> >>> On Sun, Dec 20, 2015 at 05:07:47PM +0800, Pierce Ng wrote: >>> > On Sun, Dec 20, 2015 at 08:56:43AM +0000, Dimitris Chloupis wrote: >>> > > Fuel I assume enters here the equation as a data exchange format , >>> the >>> > > problem I have with fuel is that its not backward compatible which >>> for me >>> > >>> >>> Fuel works well in this case. Version compatibility is not an issue, >>> because >>> when you fork an image/VM the two cooperating images are essentially >>> identical. >>> >>> > Once you have a set of OS processes running Pharo how they talk to >>> each other >>> > is up to you no? E.g. the Pharo instances could use ZeroMQ, XML-RPC, >>> JSONRPC, >>> > msgpack, coordinate via Redis/SQLite/PostgreSQL, etc. >>> >>> Any of those would work, but Fuel is a good way to enable all kinds of >>> objects to be copied from one image to another through a stream. In the >>> case of RemoteTask, all of the results of a remote computation can be put >>> into a single result object (an array or a dictionary or whatever), and >>> that result can be passed back to the parent image by reading the single >>> object. So - fork a copy of the image, have it do some work, and read the >>> result object from a stream. You know you are done when you have read >>> exactly one object. >>> >>> Dave >>> >>> > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 20, 2015

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

by Max Leske

I did a pass on all the changes that would be required (whatever the outcome of this discussion). Looks easy enough. One interesting point: FloatArray>>sum is implemented as a primitive in the FloatArrayPlugin and the zero element is explicitly defined as 0.0. The primitive will not fail for an empty collection but return 0.0. That would be in line with our new definition of #sum. One other thing: should the old selectors be marked as deprecated rather than being removed? I think thatâs the general policy, right? Cheers, Max > On 20 Dec 2015, at 18:19, Max Leske <maxleske(a)gmail.com> wrote: > > >> On 20 Dec 2015, at 15:26, Ben Coman <btc(a)openInWorld.com <mailto:btc@openinworld.com>> wrote: >> >> On Mon, Dec 21, 2015 at 12:43 AM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >>> Doru, >>> >>> For me this whole discussion started because you (the standpoint that you take) hijacked the best selector (#sum) for a use case that is much less common than adding a collection of numbers which should give 0 when empty (you hijack it by not wanting to return 0, which I totally understand, but doing so you redefine the meaning/semantics). >>> >>> Max's point is to make everything more consistent and remove some API. I support that too. >>> >>> Now, I like Max's proposal. >>> >>> But, you know, my conclusion when the thread ended was that it might be better to throw all these selectors away, since #inject:into: covers most use cases at least as well and at least as clear. >>> >>> Sven >>> >>>> On 20 Dec 2015, at 14:10, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >>>> >>>> Hi, >>>> >>>> Could we not have sum, but sumNumbers instead? So, we would end up with: >>>> >>>> sum:ifEmpty: >>>> sum: (with error) >>>> sumNumbers (without error) >>>> >>>> From the outside, #sum: looks like it should parameterize #sum, but the implementation is actually different. So, given that in this implementation #sum is not a special case of #sum: the two should be named differently to reflect that difference. Hence my proposal is to keep #sumNumbers instead of #sum. >> >> >> I agree somewhat with Duro to avoid #sum and #sum: having different semantics, >> but I agree more with Sven about keeping #sum for numbers only and >> returning zero, >> so why not turn Doru's suggestion around... >> >> #sum (empty --> 0) >> #sumBy: (empty --> error) >> #sumBy: ifEmpty: (empty --> no error) >> >> alternatively could be #sumUsing: or #sumWith: or something similar. > > Also a good idea. However, looking at the methods on Collection, the pattern is usually #message and #message:, e.g. #sorted and #sorted:. There used to be #sortBy: but it was removed because the view was that the protocol semantics should be the same across all methods. > The current case is a bit different of course since weâre dealing with the problem of the zero element which doesnât arise in most other cases. Still, I think from a users point of view it would be strange to have to use #sumBy: when every other message pair uses the #message / #message: pattern. > > I feel that this argument (thanks Ben :) ) is also a valid point against Doruâs argument for #sumNumbers. While #sumNumbers may *technically* be the best name (which we canât seem to agree onâ¦), #sum, #sum: and #sum:ifEmpty: form a triple that naturally fits into the naming protocol applied elsewhere. > > > Cheers, > Max > >> >> >> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Dec 20, 2015, at 1:47 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >>>>> >>>>>> >>>>>> On 20 Dec 2015, at 13:43, Gabriel Cotelli <g.cotelli(a)gmail.com <mailto:g.cotelli@gmail.com>> wrote: >>>>>> >>>>>> Max, >>>>>> >>>>>> sum: aBlock ifEmpty: emptyBlock needs to obtain the sample evaluating the block. >>>>>> >>>>>> sum: aBlock ifEmpty: emptyBlock >>>>>> | sum sample | >>>>>> self isEmpty ifTrue: [ ^ emptyBlock value ]. >>>>>> sample := aBlock value: self anyOne. >>>>>> sum := self >>>>>> inject: sample >>>>>> into: [ :accum :each | accum + (aBlock value: each) ]. >>>>>> ^ sum - sample >>>>> >>>>> >>>>> Thanks! Missed that. >>>>> >>>>>> >>>>>> On Sun, Dec 20, 2015 at 8:59 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >>>>>> I would like to wrap up this discussion. >>>>>> >>>>>> >>>>>>> On 05 Dec 2015, at 18:14, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>>>>>> >>>>>>> So what is the conclusion? >>>>>>> I like the idea of Esteban M to have iterator because it moves some behavior out of core classes. >>>>>>> >>>>>>> [[[ >>>>>>> >>>>>>> aCollection arithmetic sum: [...] or.... aCollection >>>>>>> arithmetic avg. >>>>>>> >>>>>>> ]]] >>>>>>> >>>>>> >>>>>> While I think that iterators are an intriguing idea I also believe that they are beyond the scope of this issue. If anybody wants to follow up on iterators (or unit types for that matter) please start a new thread / issue. >>>>>> >>>>>> >>>>>> I propose to use Svenâs version for #sum:ifEmpty:. The result would be these three methods: >>>>>> >>>>>> sum >>>>>> ^ self >>>>>> sum: [ :each | each ] >>>>>> ifEmpty: [ 0 ] >>>>>> >>>>>> sum: aBlock >>>>>> ^ self >>>>>> sum: aBlock >>>>>> ifEmpty: [ self errorEmptyCollection ] >>>>>> >>>>>> sum: aBlock ifEmpty: emptyBlock >>>>>> | sum sample | >>>>>> self isEmpty ifTrue: [ ^ emptyBlock value ]. >>>>>> sample := self anyOne. >>>>>> sum := self >>>>>> inject: sample >>>>>> into: [ :accum :each | accum + (aBlock value: each) ]. >>>>>> ^ sum - sample >>>>>> >>>>>> >>>>>> Iâve attached a couple of benchmark results below. To me they show that >>>>>> 1. the new implementation is maybe a tiny bit slower but insignificantly so (if youâre going for performance youâll probably write your own optimised version anyway) >>>>>> 2. there is no need to duplicate the code (like #sum and #sum: currently do). Itâs perfectly fine to delegate to #sum:ifEmpty: >>>>>> >>>>>> >>>>>> >>>>>> In addition to the above changes I would like to remove #detectSum: (-> #sum:) and #sumNumbers (-> #sum). >>>>>> >>>>>> >>>>>> Note that once we agree on changing this API, we will need to also change #detectMin:, #detectMax:, #min, #max as well as all overrides (e.g. RunArray, Interval) of these and of #sum et. al. to stay consistent. The changes would of course be in line with this change, such that every operation has a unary selector with a sensible default, one that takes a block and throws an error for empty collections and a third that takes a block for the iteration and one for the empty case. >>>>>> >>>>>> >>>>>> Please cast your vote for these changes: >>>>>> >>>>>> 1. Do you agree to changing #sum and #sum: in the suggested way? >> yes >> >>>>>> 2. Do you agree to the removal of #detectSum:? >> ?? (not familiar) >> >>>>>> 3. Do you agree to the removal of #sumNumbers? >> yes >> >>>>>> 4. Do you agree that the #max and #min selectors also need to be adapted? >> ?? (not familiar) >

Dec. 20, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort

by Mariano Martinez Peck

Hi Dimitri, Dave et all. First let me do a little disclaimer. Regarding the developments itself of this sponsorship, we discussed about the topics I said in the first email. However, those are not written in stone and that's why I also asked for feedback. As you know, Pharo has relatively little resources so those should be well spent. If we decide to take a spin into a project X, it doesn't mean other projects are not worth. It simply means that we think X will be the most useful for the time being. One of the final goals of the discusses topics, is to improve a bit the infrastructure for using Pharo as scripting (imagine Coral). For such a thing, we believe that improving FileSystem and OSProcess-like is a good first step to improve the underlying infrastructure. That being said, I of course like the idea of distributing processing across multiple images. No wonder, my PhD tool (Marea) and related sub-projects (Fuel, Ghost proxies, etc) have something to do with the mentioned topic. Dave already mentioned about RemoteTask, which was something I was about to mention. There is also Seamless project (now used by Remote Debugger stuff) and quite other tools. Finally, I think this project may have a big percentage that could be considered as "research". So having a PhD / master student working on this would also be nice. In fact, maybe Denis Kudriashov might work on that topic??? (he is now in RMOD team). Also, not that forking the image is not my main short-term goal. As said, I will experiment first with a simple tool to execute OS commands that would be FFI based, trying to make async operations, and that would help in most cases. Maybe for those that are not supported, then fallback in OSProcess. Note that Dave (OSProcess author) is very helpful with me and we are discussing together about this. Torsten, thanks about OS. I will check out that project. I started with OSProcess and Limbo. So it's good to have another to check. I will try to make the survey starting next week. On Sun, Dec 20, 2015 at 2:17 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > how the communication is happening via Fuel , does it save to a fuel file > or it does it through memory some way ? > > On Sun, Dec 20, 2015 at 6:04 PM David T. Lewis <lewis(a)mail.msen.com> > wrote: > >> On Sun, Dec 20, 2015 at 05:07:47PM +0800, Pierce Ng wrote: >> > On Sun, Dec 20, 2015 at 08:56:43AM +0000, Dimitris Chloupis wrote: >> > > Fuel I assume enters here the equation as a data exchange format , the >> > > problem I have with fuel is that its not backward compatible which >> for me >> > >> >> Fuel works well in this case. Version compatibility is not an issue, >> because >> when you fork an image/VM the two cooperating images are essentially >> identical. >> >> > Once you have a set of OS processes running Pharo how they talk to each >> other >> > is up to you no? E.g. the Pharo instances could use ZeroMQ, XML-RPC, >> JSONRPC, >> > msgpack, coordinate via Redis/SQLite/PostgreSQL, etc. >> >> Any of those would work, but Fuel is a good way to enable all kinds of >> objects to be copied from one image to another through a stream. In the >> case of RemoteTask, all of the results of a remote computation can be put >> into a single result object (an array or a dictionary or whatever), and >> that result can be passed back to the parent image by reading the single >> object. So - fork a copy of the image, have it do some work, and read the >> result object from a stream. You know you are done when you have read >> exactly one object. >> >> Dave >> >> -- Mariano http://marianopeck.wordpress.com

Dec. 20, 2015

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

by Max Leske

> On 20 Dec 2015, at 15:26, Ben Coman <btc(a)openInWorld.com> wrote: > > On Mon, Dec 21, 2015 at 12:43 AM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >> Doru, >> >> For me this whole discussion started because you (the standpoint that you take) hijacked the best selector (#sum) for a use case that is much less common than adding a collection of numbers which should give 0 when empty (you hijack it by not wanting to return 0, which I totally understand, but doing so you redefine the meaning/semantics). >> >> Max's point is to make everything more consistent and remove some API. I support that too. >> >> Now, I like Max's proposal. >> >> But, you know, my conclusion when the thread ended was that it might be better to throw all these selectors away, since #inject:into: covers most use cases at least as well and at least as clear. >> >> Sven >> >>> On 20 Dec 2015, at 14:10, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> Could we not have sum, but sumNumbers instead? So, we would end up with: >>> >>> sum:ifEmpty: >>> sum: (with error) >>> sumNumbers (without error) >>> >>> From the outside, #sum: looks like it should parameterize #sum, but the implementation is actually different. So, given that in this implementation #sum is not a special case of #sum: the two should be named differently to reflect that difference. Hence my proposal is to keep #sumNumbers instead of #sum. > > > I agree somewhat with Duro to avoid #sum and #sum: having different semantics, > but I agree more with Sven about keeping #sum for numbers only and > returning zero, > so why not turn Doru's suggestion around... > > #sum (empty --> 0) > #sumBy: (empty --> error) > #sumBy: ifEmpty: (empty --> no error) > > alternatively could be #sumUsing: or #sumWith: or something similar. Also a good idea. However, looking at the methods on Collection, the pattern is usually #message and #message:, e.g. #sorted and #sorted:. There used to be #sortBy: but it was removed because the view was that the protocol semantics should be the same across all methods. The current case is a bit different of course since weâre dealing with the problem of the zero element which doesnât arise in most other cases. Still, I think from a users point of view it would be strange to have to use #sumBy: when every other message pair uses the #message / #message: pattern. I feel that this argument (thanks Ben :) ) is also a valid point against Doruâs argument for #sumNumbers. While #sumNumbers may *technically* be the best name (which we canât seem to agree onâ¦), #sum, #sum: and #sum:ifEmpty: form a triple that naturally fits into the naming protocol applied elsewhere. Cheers, Max > > > >>> >>> Cheers, >>> Doru >>> >>> >>>> On Dec 20, 2015, at 1:47 PM, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>>> >>>>> On 20 Dec 2015, at 13:43, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >>>>> >>>>> Max, >>>>> >>>>> sum: aBlock ifEmpty: emptyBlock needs to obtain the sample evaluating the block. >>>>> >>>>> sum: aBlock ifEmpty: emptyBlock >>>>> | sum sample | >>>>> self isEmpty ifTrue: [ ^ emptyBlock value ]. >>>>> sample := aBlock value: self anyOne. >>>>> sum := self >>>>> inject: sample >>>>> into: [ :accum :each | accum + (aBlock value: each) ]. >>>>> ^ sum - sample >>>> >>>> >>>> Thanks! Missed that. >>>> >>>>> >>>>> On Sun, Dec 20, 2015 at 8:59 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>>> I would like to wrap up this discussion. >>>>> >>>>> >>>>>> On 05 Dec 2015, at 18:14, stepharo <stepharo(a)free.fr> wrote: >>>>>> >>>>>> So what is the conclusion? >>>>>> I like the idea of Esteban M to have iterator because it moves some behavior out of core classes. >>>>>> >>>>>> [[[ >>>>>> >>>>>> aCollection arithmetic sum: [...] or.... aCollection >>>>>> arithmetic avg. >>>>>> >>>>>> ]]] >>>>>> >>>>> >>>>> While I think that iterators are an intriguing idea I also believe that they are beyond the scope of this issue. If anybody wants to follow up on iterators (or unit types for that matter) please start a new thread / issue. >>>>> >>>>> >>>>> I propose to use Svenâs version for #sum:ifEmpty:. The result would be these three methods: >>>>> >>>>> sum >>>>> ^ self >>>>> sum: [ :each | each ] >>>>> ifEmpty: [ 0 ] >>>>> >>>>> sum: aBlock >>>>> ^ self >>>>> sum: aBlock >>>>> ifEmpty: [ self errorEmptyCollection ] >>>>> >>>>> sum: aBlock ifEmpty: emptyBlock >>>>> | sum sample | >>>>> self isEmpty ifTrue: [ ^ emptyBlock value ]. >>>>> sample := self anyOne. >>>>> sum := self >>>>> inject: sample >>>>> into: [ :accum :each | accum + (aBlock value: each) ]. >>>>> ^ sum - sample >>>>> >>>>> >>>>> Iâve attached a couple of benchmark results below. To me they show that >>>>> 1. the new implementation is maybe a tiny bit slower but insignificantly so (if youâre going for performance youâll probably write your own optimised version anyway) >>>>> 2. there is no need to duplicate the code (like #sum and #sum: currently do). Itâs perfectly fine to delegate to #sum:ifEmpty: >>>>> >>>>> >>>>> >>>>> In addition to the above changes I would like to remove #detectSum: (-> #sum:) and #sumNumbers (-> #sum). >>>>> >>>>> >>>>> Note that once we agree on changing this API, we will need to also change #detectMin:, #detectMax:, #min, #max as well as all overrides (e.g. RunArray, Interval) of these and of #sum et. al. to stay consistent. The changes would of course be in line with this change, such that every operation has a unary selector with a sensible default, one that takes a block and throws an error for empty collections and a third that takes a block for the iteration and one for the empty case. >>>>> >>>>> >>>>> Please cast your vote for these changes: >>>>> >>>>> 1. Do you agree to changing #sum and #sum: in the suggested way? > yes > >>>>> 2. Do you agree to the removal of #detectSum:? > ?? (not familiar) > >>>>> 3. Do you agree to the removal of #sumNumbers? > yes > >>>>> 4. Do you agree that the #max and #min selectors also need to be adapted? > ?? (not familiar)

Dec. 20, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort

by Dimitris Chloupis

how the communication is happening via Fuel , does it save to a fuel file or it does it through memory some way ? On Sun, Dec 20, 2015 at 6:04 PM David T. Lewis <lewis(a)mail.msen.com> wrote: > On Sun, Dec 20, 2015 at 05:07:47PM +0800, Pierce Ng wrote: > > On Sun, Dec 20, 2015 at 08:56:43AM +0000, Dimitris Chloupis wrote: > > > Fuel I assume enters here the equation as a data exchange format , the > > > problem I have with fuel is that its not backward compatible which for > me > > > > Fuel works well in this case. Version compatibility is not an issue, > because > when you fork an image/VM the two cooperating images are essentially > identical. > > > Once you have a set of OS processes running Pharo how they talk to each > other > > is up to you no? E.g. the Pharo instances could use ZeroMQ, XML-RPC, > JSONRPC, > > msgpack, coordinate via Redis/SQLite/PostgreSQL, etc. > > Any of those would work, but Fuel is a good way to enable all kinds of > objects to be copied from one image to another through a stream. In the > case of RemoteTask, all of the results of a remote computation can be put > into a single result object (an array or a dictionary or whatever), and > that result can be passed back to the parent image by reading the single > object. So - fork a copy of the image, have it do some work, and read the > result object from a stream. You know you are done when you have read > exactly one object. > > Dave > >

Dec. 20, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort

by David T. Lewis

On Sun, Dec 20, 2015 at 05:07:47PM +0800, Pierce Ng wrote: > On Sun, Dec 20, 2015 at 08:56:43AM +0000, Dimitris Chloupis wrote: > > Fuel I assume enters here the equation as a data exchange format , the > > problem I have with fuel is that its not backward compatible which for me > Fuel works well in this case. Version compatibility is not an issue, because when you fork an image/VM the two cooperating images are essentially identical. > Once you have a set of OS processes running Pharo how they talk to each other > is up to you no? E.g. the Pharo instances could use ZeroMQ, XML-RPC, JSONRPC, > msgpack, coordinate via Redis/SQLite/PostgreSQL, etc. Any of those would work, but Fuel is a good way to enable all kinds of objects to be copied from one image to another through a stream. In the case of RemoteTask, all of the results of a remote computation can be put into a single result object (an array or a dictionary or whatever), and that result can be passed back to the parent image by reading the single object. So - fork a copy of the image, have it do some work, and read the result object from a stream. You know you are done when you have read exactly one object. Dave

Dec. 20, 2015

Re: [Pharo-dev] [Vm-dev] Re: SecureSession frame types

by Robert Withers

Ok, let me make one last change to this 7 byte alternate proposal for the message specification. In the first 3 bytes with 4 fields, use supersymmetry to specify 6bits per field. SO the alternate would look like below... The whole point of the multicast symbol is to provide for low-level routers to not even have to decode the asn.1 header and distinguish all our message and header types. Just grab the first byte and mask the upper 6bits and shift, there is a destination specifier, at least in the large, as an alternate tunneling capability and would support reuse of 4byte IP addresses for NAT. If we loose that and knock sanguinity back to 2bits, then we are down to a 6 byte spec + payload. I'm mulling iot over, obviously. *msgSpec: 7 bytes binary encoded* * HeaderSpecification: 3 bytes o multicastSymbol: 6 bits o sanguinity: 6 bits o msgVersion: 6 bits o hdrType: 6 bits * msgSize: 2nd word, 4 bytes o 4 bytes (total size with msgSpec, header, payload sizes) -- . .. .. ^,^ robert

Dec. 20, 2015

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

by Ben Coman

On Mon, Dec 21, 2015 at 12:43 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Doru, > > For me this whole discussion started because you (the standpoint that you take) hijacked the best selector (#sum) for a use case that is much less common than adding a collection of numbers which should give 0 when empty (you hijack it by not wanting to return 0, which I totally understand, but doing so you redefine the meaning/semantics). > > Max's point is to make everything more consistent and remove some API. I support that too. > > Now, I like Max's proposal. > > But, you know, my conclusion when the thread ended was that it might be better to throw all these selectors away, since #inject:into: covers most use cases at least as well and at least as clear. > > Sven > >> On 20 Dec 2015, at 14:10, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> Could we not have sum, but sumNumbers instead? So, we would end up with: >> >> sum:ifEmpty: >> sum: (with error) >> sumNumbers (without error) >> >> From the outside, #sum: looks like it should parameterize #sum, but the implementation is actually different. So, given that in this implementation #sum is not a special case of #sum: the two should be named differently to reflect that difference. Hence my proposal is to keep #sumNumbers instead of #sum. I agree somewhat with Duro to avoid #sum and #sum: having different semantics, but I agree more with Sven about keeping #sum for numbers only and returning zero, so why not turn Doru's suggestion around... #sum (empty --> 0) #sumBy: (empty --> error) #sumBy: ifEmpty: (empty --> no error) alternatively could be #sumUsing: or #sumWith: or something similar. >> >> Cheers, >> Doru >> >> >>> On Dec 20, 2015, at 1:47 PM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> >>>> On 20 Dec 2015, at 13:43, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >>>> >>>> Max, >>>> >>>> sum: aBlock ifEmpty: emptyBlock needs to obtain the sample evaluating the block. >>>> >>>> sum: aBlock ifEmpty: emptyBlock >>>> | sum sample | >>>> self isEmpty ifTrue: [ ^ emptyBlock value ]. >>>> sample := aBlock value: self anyOne. >>>> sum := self >>>> inject: sample >>>> into: [ :accum :each | accum + (aBlock value: each) ]. >>>> ^ sum - sample >>> >>> >>> Thanks! Missed that. >>> >>>> >>>> On Sun, Dec 20, 2015 at 8:59 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>> I would like to wrap up this discussion. >>>> >>>> >>>>> On 05 Dec 2015, at 18:14, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> So what is the conclusion? >>>>> I like the idea of Esteban M to have iterator because it moves some behavior out of core classes. >>>>> >>>>> [[[ >>>>> >>>>> aCollection arithmetic sum: [...] or.... aCollection >>>>> arithmetic avg. >>>>> >>>>> ]]] >>>>> >>>> >>>> While I think that iterators are an intriguing idea I also believe that they are beyond the scope of this issue. If anybody wants to follow up on iterators (or unit types for that matter) please start a new thread / issue. >>>> >>>> >>>> I propose to use Svenâs version for #sum:ifEmpty:. The result would be these three methods: >>>> >>>> sum >>>> ^ self >>>> sum: [ :each | each ] >>>> ifEmpty: [ 0 ] >>>> >>>> sum: aBlock >>>> ^ self >>>> sum: aBlock >>>> ifEmpty: [ self errorEmptyCollection ] >>>> >>>> sum: aBlock ifEmpty: emptyBlock >>>> | sum sample | >>>> self isEmpty ifTrue: [ ^ emptyBlock value ]. >>>> sample := self anyOne. >>>> sum := self >>>> inject: sample >>>> into: [ :accum :each | accum + (aBlock value: each) ]. >>>> ^ sum - sample >>>> >>>> >>>> Iâve attached a couple of benchmark results below. To me they show that >>>> 1. the new implementation is maybe a tiny bit slower but insignificantly so (if youâre going for performance youâll probably write your own optimised version anyway) >>>> 2. there is no need to duplicate the code (like #sum and #sum: currently do). Itâs perfectly fine to delegate to #sum:ifEmpty: >>>> >>>> >>>> >>>> In addition to the above changes I would like to remove #detectSum: (-> #sum:) and #sumNumbers (-> #sum). >>>> >>>> >>>> Note that once we agree on changing this API, we will need to also change #detectMin:, #detectMax:, #min, #max as well as all overrides (e.g. RunArray, Interval) of these and of #sum et. al. to stay consistent. The changes would of course be in line with this change, such that every operation has a unary selector with a sensible default, one that takes a block and throws an error for empty collections and a third that takes a block for the iteration and one for the empty case. >>>> >>>> >>>> Please cast your vote for these changes: >>>> >>>> 1. Do you agree to changing #sum and #sum: in the suggested way? yes >>>> 2. Do you agree to the removal of #detectSum:? ?? (not familiar) >>>> 3. Do you agree to the removal of #sumNumbers? yes >>>> 4. Do you agree that the #max and #min selectors also need to be adapted? ?? (not familiar)

Dec. 20, 2015