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

Re: [Pharo-dev] How to use ExternalAddress in callouts with new FFI?

by Mariano Martinez Peck

On Mon, Dec 28, 2015 at 5:11 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi Esteban, > > Previously, I was doing with NB something like this: > > > *pointer := NativeBoost allocate: 4.* > *self primitiveWhatever: pointer* > > and: > > *primitiveWhatever: pointer* > * <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode >* > * ^ self nbCall: #( int void (NBExternalAddress pointer ) )* > > > But of course that doesn't work with latest FFI. So I tried instead: > > > *pointer := ExternalAddress allocate: 4.* > *primitiveWhatever: pointer* > * <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode >* > * ^ self nbCall: #( int void (ExternalAddress pointer ) )* > > It looks like if I set "void*" rather than ExternalAddress it does work. Is this the expected path? > But then I get a ExternalAddress class #asExternalTypeOn: which is sent > in FFICallout >> resolveType: > > Any idea how can I use ExternalAddress in the signature of the FFI > primitive call? > What am I doing wrong? > > > Thanks in advance, > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Dec. 28, 2015

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

by Robert Withers

This is sounding like a type inference situation. On 12/28/2015 03:20 PM, Sven Van Caekenberghe wrote: > Well, I beg to disagree, #sum on an empty collection should return 0. > > https://en.wikipedia.org/wiki/Empty_sum > > We do not need more tricks, the current trick with #anyOne is more than enough, that is not the problem. > > The problem is that it is impossible to talk about sum (in the general most common sense) without assuming that the collection should have contained numbers, where 0 is the neutral element. > > The #anyOne trick solves the problem of the neutral element for non empty collection, but leaves it unsolved for empty collections. > > Defining it so that empty collections error is really silly: check the senders, most of them are then forced to check before calling #sum. In that case, they could all just as well have used #inject:into: for the same amount of code. > >> On 28 Dec 2015, at 21:08, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> >> On Dec 27, 2015, at 1:52 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> >>> 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. >> +1, so it becomes eg >> >> Collection>>sum >> | sum | >> sum := self anyOne asZero. >> self do: [ :each | sum := sum + each ]. >> ^sum >> >> and a Matrix can respond to asZero by answering a suitably dimensioned zero instance. And if product were implemented, to asUnity with a suitable "one". >> >>> 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 >> I thought the conclusion was that empty collections /should/ error since the type of zero is undefined. So if anyOne errors and sum included in its comment an explanation of it being undefined if empty and why then we're good. >> >>> Nicolas > -- Robert . .. ... ^,^

Dec. 28, 2015

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

by Sven Van Caekenberghe

Well, I beg to disagree, #sum on an empty collection should return 0. https://en.wikipedia.org/wiki/Empty_sum We do not need more tricks, the current trick with #anyOne is more than enough, that is not the problem. The problem is that it is impossible to talk about sum (in the general most common sense) without assuming that the collection should have contained numbers, where 0 is the neutral element. The #anyOne trick solves the problem of the neutral element for non empty collection, but leaves it unsolved for empty collections. Defining it so that empty collections error is really silly: check the senders, most of them are then forced to check before calling #sum. In that case, they could all just as well have used #inject:into: for the same amount of code. > On 28 Dec 2015, at 21:08, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Dec 27, 2015, at 1:52 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >> >> 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. > > +1, so it becomes eg > > Collection>>sum > | sum | > sum := self anyOne asZero. > self do: [ :each | sum := sum + each ]. > ^sum > > and a Matrix can respond to asZero by answering a suitably dimensioned zero instance. And if product were implemented, to asUnity with a suitable "one". > >> 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 > > I thought the conclusion was that empty collections /should/ error since the type of zero is undefined. So if anyOne errors and sum included in its comment an explanation of it being undefined if empty and why then we're good. > >> >> Nicolas

Dec. 28, 2015

How to use ExternalAddress in callouts with new FFI?

by Mariano Martinez Peck

Hi Esteban, Previously, I was doing with NB something like this: *pointer := NativeBoost allocate: 4.* *self primitiveWhatever: pointer* and: *primitiveWhatever: pointer* * <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode >* * ^ self nbCall: #( int void (NBExternalAddress pointer ) )* But of course that doesn't work with latest FFI. So I tried instead: *pointer := ExternalAddress allocate: 4.* *primitiveWhatever: pointer* * <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode >* * ^ self nbCall: #( int void (ExternalAddress pointer ) )* But then I get a ExternalAddress class #asExternalTypeOn: which is sent in FFICallout >> resolveType: Any idea how can I use ExternalAddress in the signature of the FFI primitive call? What am I doing wrong? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Dec. 28, 2015

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

by Eliot Miranda

> On Dec 27, 2015, at 1:52 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 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. +1, so it becomes eg Collection>>sum | sum | sum := self anyOne asZero. self do: [ :each | sum := sum + each ]. ^sum and a Matrix can respond to asZero by answering a suitably dimensioned zero instance. And if product were implemented, to asUnity with a suitable "one". > 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 I thought the conclusion was that empty collections /should/ error since the type of zero is undefined. So if anyOne errors and sum included in its comment an explanation of it being undefined if empty and why then we're good. > > Nicolas >

Dec. 28, 2015

Re: [Pharo-dev] Kafka protocol

by Robert Withers

What I mean is that an undertaking of this scope should be in the Vision and on the roadman for Pharo, with a broader concerted commitment to enterprise BigData integration. robert On 12/28/2015 02:29 PM, Robert Withers wrote: > > > On 12/28/2015 12:19 PM, Frank Shearar wrote: >> On 27 December 2015 at 16:11, Robert Withers >> <robert.w.withers(a)gmail.com> wrote: >>> 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. >> Having a Kafka client in Pharo would indeed be awesome. But who cares >> about calling JARs? It's a wire protocol; write a client against that >> and you're done. > > Yes, although I would still like to load JARs, but for different > reasons. That aside, yes implementing the wire protocol would be > really happening. I'll help. I don't want to own it. It would > definitely be enterprise. > > robert > > >> >> frank >> > -- Robert . .. ... ^,^

Dec. 28, 2015

Re: [Pharo-dev] Kafka protocol

by Robert Withers

On 12/28/2015 12:19 PM, Frank Shearar wrote: > On 27 December 2015 at 16:11, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> 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. > Having a Kafka client in Pharo would indeed be awesome. But who cares > about calling JARs? It's a wire protocol; write a client against that > and you're done. Yes, although I would still like to load JARs, but for different reasons. That aside, yes implementing the wire protocol would be really happening. I'll help. I don't want to own it. It would definitely be enterprise. robert > > frank > -- Robert . .. ... ^,^

Dec. 28, 2015

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

by stepharo

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 We plan to develop a new version of Launcher with Brick. Now we will make sure that it works with Pharo 50. Stef

Dec. 28, 2015

Re: [Pharo-dev] Kafka protocol

by Frank Shearar

On 27 December 2015 at 16:11, Robert Withers <robert.w.withers(a)gmail.com> wrote: > 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. Having a Kafka client in Pharo would indeed be awesome. But who cares about calling JARs? It's a wire protocol; write a client against that and you're done. frank

Dec. 28, 2015

Re: [Pharo-dev] Back to Europe

by stepharo

We are convinced with Esteban that Pharo can really help such countries because you do not need to download 700 Mb or more to get just an IDE. And with Voyage and the stack we have such Teapot, Zinc, Seaside you can build really fast a web app. Stef

Dec. 28, 2015