- Pharo-dev - lists.pharo.org

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

by Esteban Lorenzano

> On 28 Dec 2015, at 23:11, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Mon, Dec 28, 2015 at 5:11 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@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? so.. ExternalAddress *should* map to void* by it self. If it does not, there is a bug (please report :P) but yes, using void* as argument should work out of the box so should not get the error below (none of my tests caused that either, so I do not understand why it can happenâ¦ I guess something in your code I do not completely understand). in general, I recommend to use the C type (void*) instead the pharo type (ExternalAddress)â¦ the whole idea below NB was to provide an interfase where you can just copy and paste the C definition from a header fileâ¦ even if thatâs not the case all the time. Esteban > > > 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 <http://marianopeck.wordpress.com/> > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 29, 2015

Re: [Pharo-dev] How can I load GTDebugger in 5.0 ?

by Andrei Chis

I'm working now on a config for cleanly loading GTDebugger plus SUnit and bytecode extensions into Pharo 5. Hopefully it will be done by today or tomorrow. Cheers, Andrei On Tue, Dec 29, 2015 at 2:49 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > I tried: > > Gofer it > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'ConfigurationOfGTDebugger'; > load. > (Smalltalk at: #ConfigurationOfGTDebugger) loadBleedingEdge. > > > but that loads a hell of stuff I don't want...and conflicts and.. > > So.. how can I get simply GTDebugger with the SUnit extensions? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 29, 2015

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

by Ferlicot D. Cyril

Le 29/12/2015 04:03, Ben Coman a Ã©crit : > There is a setting in PharoLauncher > > A different approach to workaround Pharo 5 alpha transition in image > file format... > 1. Download latest VM + Image > http://pharo.org/download -- Development version: Pharo5 > or, get.pharo.org ... 50+vmLatest > > 2. After opening image, from World Menu go Tools > Catalog Browser > > 3. Install Pharo Launcher > > 4. Start PharoLauncher from the World Menu > > Now I guess you will get the same in reverse, this wont open the old > image format. It would be nice for PharoLauncher to handle multiple > VMs, but in the meantime you may want to keep two PharoLauncher: Spur > & pre-Spur. > > cheers -ben > Hi Ben, With the development version of pharo launcher you can give a path to the cog VM and a path to the spur VM. The launcher will know which image need which VM. So with the development version of PharoLauncher you only need 1 version to be able to launch all images. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Dec. 29, 2015

Re: [Pharo-dev] Having Book section using Pillar?

by Damien Cassou

On December 27, 2015 9:59:06 PM GMT+01:00, "Ferlicot D. Cyril" <cyril.ferlicot(a)gmail.com> wrote: >there is not a Pillar syntax for that That's wrong. \part, \chapter, \section... are all handled the same way: configure headingLevelOffset to decide which number of exclamation marks corresponds to which latex command/HTML markup. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Dec. 29, 2015

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

by Ben Coman

There is a setting in PharoLauncher A different approach to workaround Pharo 5 alpha transition in image file format... 1. Download latest VM + Image http://pharo.org/download -- Development version: Pharo5 or, get.pharo.org ... 50+vmLatest 2. After opening image, from World Menu go Tools > Catalog Browser 3. Install Pharo Launcher 4. Start PharoLauncher from the World Menu Now I guess you will get the same in reverse, this wont open the old image format. It would be nice for PharoLauncher to handle multiple VMs, but in the meantime you may want to keep two PharoLauncher: Spur & pre-Spur. cheers -ben On Sun, Dec 27, 2015 at 5:03 AM, SaÅ¡a JaniÅ¡ka <gour(a)atmarama.com> wrote: > 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. 29, 2015

How can I load GTDebugger in 5.0 ?

by Mariano Martinez Peck

I tried: Gofer it smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTDebugger'; load. (Smalltalk at: #ConfigurationOfGTDebugger) loadBleedingEdge. but that loads a hell of stuff I don't want...and conflicts and.. So.. how can I get simply GTDebugger with the SUnit extensions? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Dec. 29, 2015

Re: [Pharo-dev] Preview of new FFI?

by Mariano Martinez Peck

On Wed, Dec 23, 2015 at 10:30 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > I guess Esteban is busy as he is with Stef in Togo. I started porting to > new FFI initial stuff and chatted with Esteban on Slack. > > When you use the latest Pharo 5 image (together with the spur VM) you > have the new FFI right inside. Athens is running already on the new FFI. > > NB is still not unloaded - but it will be unloaded soon. The idea is that > people can recover what they need afterwards. For some cases it should be > straightforward to convert. > > A short summary of my findings: > > - check the "FFI-NB" package in recent Pharo 5 images like Pharo 5 #50510 > as of today > The name is misleading - it is not the NativeBoost but the new FFI > - check the new classes in this package that are prefixed with "FFI" like > FFIExternalObject (replacement for NBExternalObject), > FFIExternalStructure > (replacement for NBExternalStructure), ... > - If you generate fields from a struct the accessors are not generated > into non-package "*generated-code-non-existing-package" but are now > generated into > method category "accessing structure variables" and will therefore be > part of your > MCZ code package > - #nbCall: and #nbCall:module: work for compatibility, I guess we should > add a deprecation > to them > - it is better to use ffiCall:, ffiCall:module: now > - there is no need to have a pragma with NativeBoostPlugin anymore, at > least it > worked for me without it just by using #ffiCall: ... > - there is a new repo: http://smalltalkhub.com/#!/~Pharo/FFI-NB since > last week, > but I guess the code in the image is more recent > > Besides the list mentioned by Torsten, these are the ones I found out: - You now need #ffiLibraryName rather than #nbLibraryNameOrHandle - The #free you should send when you manually #allocate: now clears (put all zeros) in the handle. That means, you must free AFTER having read the value (like getting the handle integer) and kept it. With NB, the #free would only free the external side but would keep the internal value in the handle. That was handy because you could free the resources in one level, pass around the pointer, and get the number later. - Previously, a FFI call to a function that answered an opaque (FFIExternalObject subclass) as return value, AND the answer was a NULL, then NB would answer nil to the FFI call rather than a FFIExternalObject subclass instance. Now, it answers a instance of the FFIExternalObject subclass, which answers true to #isNull. - Previously you could #allocate: and get a NBExternalAddress (a pointer) which could be passed around to a FFI call whose type in the FFI call signature was itself a NBExternalAddress. Right now it seems the new FFI signature must be specified with "void*" ?? > Problems I've experienced so far while trying to port my OS-Windows > project: > - FIICallout does not understand #optionAt:, no support for options like > #WinUnicode so far > - FFIExternalType sizeOf: #ulong failed > Yes, I would appreciate this too. I really need a "NBExternalType sizeOf: #ulong" so that we can easy the future transition to 64 bits. Right now I am hardcoding stuff ;) > - the spur VM for Windows does not include all latest fixes for Windows > VM, like > CTRL keys (https://pharo.fogbugz.com/f/cases/17289) > > Hope this helps a little bit until some more bugs are sorted out/a more > detailed info > for conversion is available. > > Bye > T. > > Gesendet: Mittwoch, 23. Dezember 2015 um 13:55 Uhr > Von: "Mariano Martinez Peck" <marianopeck(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Preview of new FFI? > > We are in the same boat. Even worst, I suspect I am using some parts of > ASMJIT which I guess won't be in new FFI, so I have on clue how I would > make that parts to work.... > > On Wed, Dec 23, 2015 at 9:16 AM, Pierce Ng <pierce(a)samadhiweb.com> > wrote:Hi, > > (For Esteban perhaps...) > > Is there an image/VM combo to preview the new FFI? I just made NBSQLite3 > work > with SQLcipher (for transparent database encryption) but don't want to > spend > any effort refactoring if I need to redo for the new FFI. > > Pierce > > -- > Mariano > http://marianopeck.wordpress.com[http://marianopeck.wordpress.com] > > -- Mariano http://marianopeck.wordpress.com

Dec. 28, 2015

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