- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Dealing with Class and Metaclass instances when using STON

by Max Leske

> On 25 Dec 2015, at 23:27, stepharo <stepharo(a)free.fr> wrote: > > Thanks sven. > PS: the flight did not take off... we are still in Togo. > Merry christmas! > Le 25/12/15 20:44, Sven Van Caekenberghe a Ã©crit : >>> On 25 Dec 2015, at 13:35, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi sven >>> >>> I missed the scenario. >> I guess some people sometimes store a class in some instance variable of a model class, maybe for configuration. In that case STON would not work before, now it does. >> >> In theory, STON can serialise any class without further configuration, but not classes that contain deeply nested/linked/os system objects. >> >>> Stef >>> >>> Le 23/12/15 23:04, Sven Van Caekenberghe a Ã©crit : >>>> Hi, >>>> >>>> In STON #bleedingEdge I added the ability to write and read Class and Metaclass instances by using their global name. >>>> >>>> So, Point will be written as Class[#Point] while Point class will be written as Metaclass[#Point]. This is of course a short-circuit solution for the complex structure that a class actually is, but a reasonable compromise. It is in any case better than not handling these types of instances, which was the case before. >>>> >>>> === >>>> Name: STON-Core-SvenVanCaekenberghe.64 >>>> Author: SvenVanCaekenberghe >>>> Time: 23 December 2015, 10:50:14.195912 pm >>>> UUID: b7ced20a-a7a4-4b0f-8f27-db73231eeecb >>>> Ancestors: STON-Core-SvenVanCaekenberghe.63 >>>> >>>> Added the ability to write and read Class and Metaclass instances using their global name >>>> === >>>> Name: STON-Tests-SvenVanCaekenberghe.59 >>>> Author: SvenVanCaekenberghe >>>> Time: 23 December 2015, 10:51:06.830762 pm >>>> UUID: 9f684bc1-45e1-4bfa-885b-c56ea178bfca >>>> Ancestors: STON-Tests-SvenVanCaekenberghe.58 >>>> >>>> Added unit test for the ability to write and read Class and Metaclass instances using their global name >>>> === >>>> >>>> Thanks to Norbert Hartl for requesting the feature and for test driving it. >>>> >>>> Sven >>>> >>>> >>>> >>> >> >> > >

Dec. 26, 2015

Re: [Pharo-dev] Dealing with Class and Metaclass instances when using STON

by Sven Van Caekenberghe

> On 25 Dec 2015, at 23:27, stepharo <stepharo(a)free.fr> wrote: > > Thanks sven. > PS: the flight did not take off... we are still in Togo. X-mas in the airport then ? It is amazing what you are doing for Pharo ! > Le 25/12/15 20:44, Sven Van Caekenberghe a Ã©crit : >>> On 25 Dec 2015, at 13:35, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi sven >>> >>> I missed the scenario. >> I guess some people sometimes store a class in some instance variable of a model class, maybe for configuration. In that case STON would not work before, now it does. >> >> In theory, STON can serialise any class without further configuration, but not classes that contain deeply nested/linked/os system objects. >> >>> Stef >>> >>> Le 23/12/15 23:04, Sven Van Caekenberghe a Ã©crit : >>>> Hi, >>>> >>>> In STON #bleedingEdge I added the ability to write and read Class and Metaclass instances by using their global name. >>>> >>>> So, Point will be written as Class[#Point] while Point class will be written as Metaclass[#Point]. This is of course a short-circuit solution for the complex structure that a class actually is, but a reasonable compromise. It is in any case better than not handling these types of instances, which was the case before. >>>> >>>> === >>>> Name: STON-Core-SvenVanCaekenberghe.64 >>>> Author: SvenVanCaekenberghe >>>> Time: 23 December 2015, 10:50:14.195912 pm >>>> UUID: b7ced20a-a7a4-4b0f-8f27-db73231eeecb >>>> Ancestors: STON-Core-SvenVanCaekenberghe.63 >>>> >>>> Added the ability to write and read Class and Metaclass instances using their global name >>>> === >>>> Name: STON-Tests-SvenVanCaekenberghe.59 >>>> Author: SvenVanCaekenberghe >>>> Time: 23 December 2015, 10:51:06.830762 pm >>>> UUID: 9f684bc1-45e1-4bfa-885b-c56ea178bfca >>>> Ancestors: STON-Tests-SvenVanCaekenberghe.58 >>>> >>>> Added unit test for the ability to write and read Class and Metaclass instances using their global name >>>> === >>>> >>>> Thanks to Norbert Hartl for requesting the feature and for test driving it. >>>> >>>> Sven >>>> >>>> >>>> >>> >> >> > >

Dec. 25, 2015

Re: [Pharo-dev] Dealing with Class and Metaclass instances when using STON

by stepharo

Thanks sven. PS: the flight did not take off... we are still in Togo. Le 25/12/15 20:44, Sven Van Caekenberghe a Ã©crit : >> On 25 Dec 2015, at 13:35, stepharo <stepharo(a)free.fr> wrote: >> >> Hi sven >> >> I missed the scenario. > I guess some people sometimes store a class in some instance variable of a model class, maybe for configuration. In that case STON would not work before, now it does. > > In theory, STON can serialise any class without further configuration, but not classes that contain deeply nested/linked/os system objects. > >> Stef >> >> Le 23/12/15 23:04, Sven Van Caekenberghe a Ã©crit : >>> Hi, >>> >>> In STON #bleedingEdge I added the ability to write and read Class and Metaclass instances by using their global name. >>> >>> So, Point will be written as Class[#Point] while Point class will be written as Metaclass[#Point]. This is of course a short-circuit solution for the complex structure that a class actually is, but a reasonable compromise. It is in any case better than not handling these types of instances, which was the case before. >>> >>> === >>> Name: STON-Core-SvenVanCaekenberghe.64 >>> Author: SvenVanCaekenberghe >>> Time: 23 December 2015, 10:50:14.195912 pm >>> UUID: b7ced20a-a7a4-4b0f-8f27-db73231eeecb >>> Ancestors: STON-Core-SvenVanCaekenberghe.63 >>> >>> Added the ability to write and read Class and Metaclass instances using their global name >>> === >>> Name: STON-Tests-SvenVanCaekenberghe.59 >>> Author: SvenVanCaekenberghe >>> Time: 23 December 2015, 10:51:06.830762 pm >>> UUID: 9f684bc1-45e1-4bfa-885b-c56ea178bfca >>> Ancestors: STON-Tests-SvenVanCaekenberghe.58 >>> >>> Added unit test for the ability to write and read Class and Metaclass instances using their global name >>> === >>> >>> Thanks to Norbert Hartl for requesting the feature and for test driving it. >>> >>> Sven >>> >>> >>> >> > >

Dec. 25, 2015

Re: [Pharo-dev] Dealing with Class and Metaclass instances when using STON

by Sven Van Caekenberghe

> On 25 Dec 2015, at 13:35, stepharo <stepharo(a)free.fr> wrote: > > Hi sven > > I missed the scenario. I guess some people sometimes store a class in some instance variable of a model class, maybe for configuration. In that case STON would not work before, now it does. In theory, STON can serialise any class without further configuration, but not classes that contain deeply nested/linked/os system objects. > Stef > > Le 23/12/15 23:04, Sven Van Caekenberghe a Ã©crit : >> Hi, >> >> In STON #bleedingEdge I added the ability to write and read Class and Metaclass instances by using their global name. >> >> So, Point will be written as Class[#Point] while Point class will be written as Metaclass[#Point]. This is of course a short-circuit solution for the complex structure that a class actually is, but a reasonable compromise. It is in any case better than not handling these types of instances, which was the case before. >> >> === >> Name: STON-Core-SvenVanCaekenberghe.64 >> Author: SvenVanCaekenberghe >> Time: 23 December 2015, 10:50:14.195912 pm >> UUID: b7ced20a-a7a4-4b0f-8f27-db73231eeecb >> Ancestors: STON-Core-SvenVanCaekenberghe.63 >> >> Added the ability to write and read Class and Metaclass instances using their global name >> === >> Name: STON-Tests-SvenVanCaekenberghe.59 >> Author: SvenVanCaekenberghe >> Time: 23 December 2015, 10:51:06.830762 pm >> UUID: 9f684bc1-45e1-4bfa-885b-c56ea178bfca >> Ancestors: STON-Tests-SvenVanCaekenberghe.58 >> >> Added unit test for the ability to write and read Class and Metaclass instances using their global name >> === >> >> Thanks to Norbert Hartl for requesting the feature and for test driving it. >> >> Sven >> >> >> > >

Dec. 25, 2015

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

by Henrik Nergaard

Like this? http://smalltalkhub.com/#!/~Latsabben/NumIt Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo Sent: Thursday, December 24, 2015 9:58 AM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: Just a remark. I think that we discarded the proposition of having aCol arithmetic sum but I found it nice because there if was clear that you want to get back 0 for #(). Stef

Dec. 25, 2015

Re: [Pharo-dev] Dealing with Class and Metaclass instances when using STON

by stepharo

Hi sven I missed the scenario. Stef Le 23/12/15 23:04, Sven Van Caekenberghe a Ã©crit : > Hi, > > In STON #bleedingEdge I added the ability to write and read Class and Metaclass instances by using their global name. > > So, Point will be written as Class[#Point] while Point class will be written as Metaclass[#Point]. This is of course a short-circuit solution for the complex structure that a class actually is, but a reasonable compromise. It is in any case better than not handling these types of instances, which was the case before. > > === > Name: STON-Core-SvenVanCaekenberghe.64 > Author: SvenVanCaekenberghe > Time: 23 December 2015, 10:50:14.195912 pm > UUID: b7ced20a-a7a4-4b0f-8f27-db73231eeecb > Ancestors: STON-Core-SvenVanCaekenberghe.63 > > Added the ability to write and read Class and Metaclass instances using their global name > === > Name: STON-Tests-SvenVanCaekenberghe.59 > Author: SvenVanCaekenberghe > Time: 23 December 2015, 10:51:06.830762 pm > UUID: 9f684bc1-45e1-4bfa-885b-c56ea178bfca > Ancestors: STON-Tests-SvenVanCaekenberghe.58 > > Added unit test for the ability to write and read Class and Metaclass instances using their global name > === > > Thanks to Norbert Hartl for requesting the feature and for test driving it. > > Sven > > >

Dec. 25, 2015

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

by Eliot Miranda

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 > > cheers -ben > >> >> >>> >>>> >>>> I am not suggesting to stop using #anyOne because I like why it is there >>>> and what it can do. >>>> >>>> The change I want is what happens with an empty collection when using >>>> the simplest selector, #sum. >>>> >>>> I do not want to say to some collection of numbers #sumIfEmpty: [0], >>>> because summing numbers starting from zero is the most common case and >>>> everybody expects that, hence the unary selector fits. >>>> >>>> I want the less common cases to use the more complicated API, as in some >>>> collection of colors #sumIfEmpty: [ Color black ] >>>> >>>> In my book that is common sense API design. >>>> >>>> Doing that I do no take anything away, because today you already have to >>>> make sure the collection is not empty. >>>> >>>> The only change would be in the error behaviour. I think that is a >>>> reasonable price to pay. Instead of having #anyOne fail, it will say that #+ >>>> cannot add 0 to some object, and in a comment we can point to the >>>> alternative API. >> >> >> >> >>> >>>> >>>> http://izquotes.com/quote/242740 right ? >>>> >>>>> cheers -ben >>>>> >>>>>> >>>>>>>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo >>>>>>>> <emaringolo(a)gmail.com> wrote: >>>>>>>> >>>>>>>> I don't want to be heretic (or too orthodox), but why not to >>>>>>>> delegate >>>>>>>> this behavior to other class (an iterator maybe?). >>>>>>>> >>>>>>>> It's too tempting adding these convenience methods to Collection >>>>>>>> and/or subclasses, but anything that requires an explicit protocol >>>>>>>> of >>>>>>>> its elements is wrong, IMO. >>>>>>>> >>>>>>>> something like aCollection arithmetic sum: [...] or.... aCollection >>>>>>>> arithmetic avg. > > > On Fri, Dec 4, 2015 at 3:26 AM, Chris Cunningham > <cunningham.cb(a)gmail.com> wrote: >> <uncontrolled snipping> >> >>> On Thu, Dec 3, 2015 at 5:48 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> * 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. >> >> but points aren't commutative: >> >> 2@2 + 1 " = 3@3" >> 1 + 2@2 " = 3@2" >> >> Of course, 0 wouldn't be an issue, unless you wanted to access x or y! >

Dec. 25, 2015

Re: [Pharo-dev] Are Critical Tools Becoming Too Brittle?

by Sean P. DeNigris

Max Leske wrote > Did you send #basicInspect? That should still give you the original > minimal inspector. Good tip! I didn't think of that. I see it's even in the context menu :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Are-Critical-Tools-Becoming-Too-Brittle-tp4867206p486… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 25, 2015

Re: [Pharo-dev] Are Critical Tools Becoming Too Brittle?

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Are you sure your #printString is OK ? Aha! @$!$%!#$!#$#@ I got bitten for the umpteenth time by the #name trap. My custom #printOn: was calling #name, which I hadn't yet defined, and so called the default implementation, which sends #printString => infinite unbreakable loop. Thanks for the help. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Are-Critical-Tools-Becoming-Too-Brittle-tp4867206p486… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 25, 2015

Re: [Pharo-dev] [Moose-dev] AgileVisualization - call for reviewers

by Tudor Girba

Great work! Doru -- www.tudorgirba.com "Every thing has its own flow" > On 23 Dec 2015, at 19:57, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Dear All, > > As you may have heard, AgileVisualization is a book about the Roassal visualization engine. > We hope to have the book released soon, within a couple of months. It would be fantastic to have feedback: > > http://agilevisualization.com > > The book is a fantastic result of the community. You guys made this possible, and we wish to thank you very much for this. > > Beers will flow at ESUG for everybody who comment on the chapters :-) > We also have live discussion on Slack, channel #Roassal (see http://pharo.org/community on how to join Slack) > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Dec. 24, 2015