March 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo #sum vs #sumNumbers and the consequence of #average

by Konrad Hinsen

Am 23.03.20 um 14:45 schrieb James Foster: >> On Mar 23, 2020, at 6:06 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> What you found out now is that the clever trick used to avoid picking an additive identity (picking an element, counting it twice and then subtracting it) leads to a loss of precision when floating point numbers are involved. This is an important issue. > > If this approach is to be preserved, then each class should have an additive identity so instead of adding and subtracting an object, we let the object tell us its zero. Or define a singleton class "Zero" with a + method that returns the other operand, and use that Zero object for the additive identity. Konrad.

March 23, 2020

Re: [Pharo-users] Versioning and packaging?

by Guillermo Polito

Hi Bob, > El 21 mar 2020, a las 18:26, Rob Raisch <raisch(a)gmail.com> escribiÃ³: > > Iâve noticed that the majority of projects in which I have an interest, from any repository, like Moose or PetitParser, fail to load into Pharo 8.0 throwing errors related to missing requirements. This is probably because the package mantainers did not have time yet to update to Pharo 8. Maybe you could contact them individually? > > For example, filing in Moose into Pharo 8.0 fails with âError: Cannot resolve symbolic version #release1â. > > In the Catalog browser, Moose is tagged with âPharo3.0â. Does this imply that Moose only works in that version of Pharo only? Nope, this just means the meta-data in the catalog browser is out of dateâ¦ :( > > PetitParser, which Moose requires, is tagged âPharo5.0â and PetitParser2 is tagged âPharo6.0â neither of which will work in Pharo 3.0. > > So, Iâm left wondering if Iâm doing something wrong, and how requirements are supposed to work when there are so many projects that depend on deprecated versions of Pharo. I think you have been doing nothing wrong. In the last year everything has been moving super fast. Lots of projects have moved lately to git, but the meta-data associated to those projects is probably in many places and updating all of that is, so far, human dependant and thus error prone. Guille

March 23, 2020

Re: [Pharo-users] Pharo #sum vs #sumNumbers and the consequence of #average

by James Foster

> On Mar 23, 2020, at 6:06 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > What you found out now is that the clever trick used to avoid picking an additive identity (picking an element, counting it twice and then subtracting it) leads to a loss of precision when floating point numbers are involved. This is an important issue. If this approach is to be preserved, then each class should have an additive identity so instead of adding and subtracting an object, we let the object tell us its zero. James

March 23, 2020

Re: [Pharo-users] Pharo #sum vs #sumNumbers and the consequence of #average

by Sven Van Caekenberghe

Like I said, we have had big discussions about this, I am not sure we want to revisit them. It is not just the problem that summing assumes the elements to be numbers (whatever that it, let's say objects that can be added), it is also the question what the additive identity should be (0 most would say, but for points that would be 0@0, etc), and there is the question what should happen with an empty collection (because we want to avoid testing for that as users). Now, all of this can be solved, the question is what behaviour gets the nicest selectors (#sum being the one that everybody wants). What you found out now is that the clever trick used to avoid picking an additive identity (picking an element, counting it twice and then subtracting it) leads to a loss of precision when floating point numbers are involved. This is an important issue. In the end, #inject:into: is so flexible that it easily solves most issue at the expense of being more verbose. The fight is over the nicest selectors. > On 23 Mar 2020, at 13:25, Tim Mackinnon <tim(a)testit.works> wrote: > > Iâm interested in exploring this - partly because it hit me and wasted my time chasing down why we have a difference in #sum from other languages. It seems that the implementation is trying to be very clever - I guess from the generic usage of collections which donât have to contain only numbers. > > The kicker for me (from below), was that its not obvious that the #average of a collection of floats loses precision due to #sum. > > For me, the generic case is numbers - and looking at senders of #sum they all seem to be expecting numeric summation. So why wouldnât we put the onus on generic summation back on the caller (Iâm assuming checking the collection internally is too expensive to do it automatically?). > > If we were to adjust #sum with the implementation of #sumNumbers, and then introduce a new method #sumObjects (and forward #sumNumbers to #sum for partial compatibility ) would all the test cases in the image catch this and give an indication of the consequences? > > Could we even consider such a change? Its brave - but shouldnât Pharo behave like you would expect (or am I missing an obvious use case). > > Tim > >> On 20 Mar 2020, at 15:24, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Thanks for sharing, this is indeed something quite subtle. >> >>> On 20 Mar 2020, at 16:19, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Actually I can answer my own question - its the difference between #sum and #sumNumbers (and an easy mistake to make - I almost wish that sum was the sumNumbers implementation and there was a sumSample that behaved like now) >> >> There was a *LOT* of debate about that (especially that #() sum isZero). >> >> I also would would prefer #sum to be like you describe. >> >>>> On 20 Mar 2020, at 14:52, Tim Mackinnon <tim(a)testit.works> wrote: >>>> >>>> Hi guys - I recall this came up a few months ago, but Iâm curious about the difference of Pharoâs use of Float64 vs Python - as I assumed that if languages use the same IEEE spec (or whatever spec it is) that simple stuff would be quite similar. >>>> >>>> I am curious why in Python adding these numbers: >>>> >>>> y = 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294 >>>> print(y) >>>> print(y / 15) >>>> >>>> Gives: >>>> >>>> 14832.682458496522 >>>> 988.8454972331015 >>>> >>>> In pharo I have noticed an anomaly which I thought was precision but it may be something odd with iterators. >>>> >>>> y := 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294. >>>> y. >>>> y / 15. >>>> >>>> >>>> Gives the same as Python. >>>> >>>> >>>> BUT: >>>> >>>> z := {987.9504418944 . 815.2627636718801 . 1099.3898999037601 . 1021.6996069333198 . 1019.8750146478401 . 1084.5603759764 . 1008.2985131833999 . 1194.9564575200002 . 893.9680444336799 . 1032.85460449136 . 905.9324633786798 . 1024.2805590819598 . 784.5488305664002 . 957.3522631840398 . 1001.7526196294} sum. >>>> z. >>>> z / 15. >>>> >>>> >>>> Gives >>>> 14832.68245849652 >>>> 988.8454972331014 >>>> >>>> Is this correct? >>>> >>>> >>> >> >> > >

March 23, 2020

Pharo #sum vs #sumNumbers and the consequence of #average

by Tim Mackinnon

Iâm interested in exploring this - partly because it hit me and wasted my time chasing down why we have a difference in #sum from other languages. It seems that the implementation is trying to be very clever - I guess from the generic usage of collections which donât have to contain only numbers. The kicker for me (from below), was that its not obvious that the #average of a collection of floats loses precision due to #sum. For me, the generic case is numbers - and looking at senders of #sum they all seem to be expecting numeric summation. So why wouldnât we put the onus on generic summation back on the caller (Iâm assuming checking the collection internally is too expensive to do it automatically?). If we were to adjust #sum with the implementation of #sumNumbers, and then introduce a new method #sumObjects (and forward #sumNumbers to #sum for partial compatibility ) would all the test cases in the image catch this and give an indication of the consequences? Could we even consider such a change? Its brave - but shouldnât Pharo behave like you would expect (or am I missing an obvious use case). Tim > On 20 Mar 2020, at 15:24, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Thanks for sharing, this is indeed something quite subtle. > >> On 20 Mar 2020, at 16:19, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Actually I can answer my own question - its the difference between #sum and #sumNumbers (and an easy mistake to make - I almost wish that sum was the sumNumbers implementation and there was a sumSample that behaved like now) > > There was a *LOT* of debate about that (especially that #() sum isZero). > > I also would would prefer #sum to be like you describe. > >>> On 20 Mar 2020, at 14:52, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Hi guys - I recall this came up a few months ago, but Iâm curious about the difference of Pharoâs use of Float64 vs Python - as I assumed that if languages use the same IEEE spec (or whatever spec it is) that simple stuff would be quite similar. >>> >>> I am curious why in Python adding these numbers: >>> >>> y = 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294 >>> print(y) >>> print(y / 15) >>> >>> Gives: >>> >>> 14832.682458496522 >>> 988.8454972331015 >>> >>> In pharo I have noticed an anomaly which I thought was precision but it may be something odd with iterators. >>> >>> y := 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294. >>> y. >>> y / 15. >>> >>> >>> Gives the same as Python. >>> >>> >>> BUT: >>> >>> z := {987.9504418944 . 815.2627636718801 . 1099.3898999037601 . 1021.6996069333198 . 1019.8750146478401 . 1084.5603759764 . 1008.2985131833999 . 1194.9564575200002 . 893.9680444336799 . 1032.85460449136 . 905.9324633786798 . 1024.2805590819598 . 784.5488305664002 . 957.3522631840398 . 1001.7526196294} sum. >>> z. >>> z / 15. >>> >>> >>> Gives >>> 14832.68245849652 >>> 988.8454972331014 >>> >>> Is this correct? >>> >>> >> > >

March 23, 2020

[ANN] Pharo Newsletter March 2020

by Marcus Denker

[ANN] Pharo Newsletter March 2020 The Pharo Newsletter March 2020 has been sent to subscribers last week: https://mailchi.mp/pharo/pharo-newsletter-march-2020 To get it as soon as it is released, please subscribe here: http://eepurl.com/bykqWn

March 23, 2020

Re: [Pharo-users] Morph Code problem

by shawon58

thanks after seeing ur solution i can able to delete . -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 22, 2020

Re: [Pharo-users] Morph Code problem

by K K Subbu

On 22/03/20 11:20 AM, shawon58 wrote: > i am new in morph code. so i try this code "Color orange asMorph openInWorld" > . in my screen it shows a line but i cant able to close that. screen shot > added below. thanks > <http://forum.world.st/file/t372453/Capture.png> What you are seeing is a StringMorph containing the name of the color. Inspect just "Color orange asMorph" part to see it. You can bring up a halo morph with Shift-Alt-click on it and then press 'x' to delete it. If you find getting this halo difficult, imagine a box around the morph. Click somewhere outside, press shift and drag around it. You will now see a halo of buttons around it. If you are trying to build a Morph with that color, try: Morph new color: (Color orange); openInHand HTH .. Subbu

March 22, 2020

Morph Code problem

by shawon58

i am new in morph code. so i try this code "Color orange asMorph openInWorld" . in my screen it shows a line but i cant able to close that. screen shot added below. thanks <http://forum.world.st/file/t372453/Capture.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 22, 2020

Re: [Pharo-users] Json encoding

by Vitor Medina Cruz

" But again, have you read everything ? " Yes " Looked at the unit tests ? " Nope, gave up on the documentation :( The examples are better. I will look into it deeper later. Thanks. On Sat, Mar 21, 2020 at 6:51 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Victor, > > But again, have you read everything ? Looked at the unit tests ? > > A mapping can be specified either globally on the class side, or per > reader/writer. > > Have a look a NeoJSONTestObject1, NeoJSONTestObject2 and > NeoJSONTestObject3 and how they are used in tests. > > You can perfectly do a #mapAllInstVarsFor, #map[All]InstVars or > #map[All]InstVars: or you can work based on properties/accessors. And there > is a lot more (and it gets complicated in special cases). > > I know that the DSL is not perfect, it just kind of evolved. > > One of the design goals of NeoJSON is that you can work with > mappings/types without creating intermediate structures (so it is not > JSON->Dictionary->MyObject, but JSON->MyObject). > > For example, there is > > NeoJSONTestObject1 class>>#neoJsonMapping: mapper > mapper for: self do: [ :mapping | > mapping mapInstVars: #(id name). > (mapping mapInstVar: #timestamp to: 'created-at') valueSchema: > DateAndTime. > (mapping mapInstVar: #points) valueSchema: #ArrayOfPoints. > (mapping mapInstVar: #bytes) valueSchema: ByteArray ]. > mapper for: DateAndTime customDo: [ :mapping | > mapping decoder: [ :string | DateAndTime fromString: string ]. > mapping encoder: [ :dateAndTime | dateAndTime printString ] ]. > mapper for: #ArrayOfPoints customDo: [ :mapping | > mapping listOfElementSchema: Point ]. > mapper mapAllInstVarsFor: Point. > mapper for: ByteArray customDo: [ :mapping | > mapping listOfType: ByteArray ] > > which already covers a lot. You could also specify this mapping directly > on either a reader or a writer: > > neoJsonReader > for: NeoJSONTestObject1 do: [ :mapping | > mapping mapInstVars: #(id name). > (mapping mapInstVar: #timestamp to: 'created-at') valueSchema: > DateAndTime. > (mapping mapInstVar: #points) valueSchema: #ArrayOfPoints. > (mapping mapInstVar: #bytes) valueSchema: ByteArray ]; > for: DateAndTime customDo: [ :mapping | > mapping decoder: [ :string | DateAndTime fromString: string ]. > mapping encoder: [ :dateAndTime | dateAndTime printString ] ]; > for: #ArrayOfPoints customDo: [ :mapping | > mapping listOfElementSchema: Point ]; > mapAllInstVarsFor: Point; > for: ByteArray customDo: [ :mapping | > mapping listOfType: ByteArray ] > > In an example like the above, the whole mapping is in one place, but you > could distribute it over class side methods. It would even be possible to > have a special utility object that (automagically) constructs/fills in > these mappings - several users done this already. > > Again, for JSON there cannot be one way to encode types like Dates. > > STON can make such decisions because it stands on its own. > > > On 21 Mar 2020, at 00:43, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > > > > Oh! I understand, desserialize is, indeed, a problem because you don't > have the types..... > > > > I find very hard to follow the mapping instructions, why can't I just > tell the class of my instvars? > > > > jsonReader := NeoJSONReader new configure: MyCustomClass > > > withInstVarMapping: {#name -> String. #dateOrBirth -> Date} > > > > jsonRreader fromJson: { "name":"Joe","dateOfBirth":"19900407"} > > toClass: MyCustomClass > > > > ??? > > > > > > Well, I am going to experiment with STON for now, I used NeoJson some > time ago, but for simpler stuff. > > > > Ignoring the instvar worked. > > > > Thanks!! > > > > > > > > > > > > > > On Fri, Mar 20, 2020 at 7:41 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > I think you have to think harder about this ;-) > > > > It would indeed be relatively easy to allow any object to be written out > to JSON, falling back to just writing out its instance variables. You could > hack that today by overwriting/implementing #neoJsonOn: > > > > But you would never be able to read that back, because you don't known > the types/classes (in general). > > > > Say you have a Person object with a dateOfBirth in it, a Date. > > > > { "name":"Joe","dateOfBirth":"19900407" } > > > > You don't know this is a Person, nor that dateOfBirth is a Date. You > have to tell the JSON reader/parser that explicitly. And even if you tell > it to start with Person, no reflection in Pharo tells you that dateOfBirth > is a Date. > > > > In statically typed languages you do know that. > > > > That is why NeoJSON has mappings (section 5 of the document). These > provide that missing information. But this mechanism is not perfect (it can > become quite complex with deep nesting or variant types). > > > > The unit tests show many usages of mappings. > > > > But even so, the original JSON is not self describing. > > > > This is why STON exists. > > > > It was a design choice to restrict which classes can automatically be > converted to JSON without an explicit mapping to the primitive JSON types. > > > > > On 20 Mar 2020, at 21:47, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > > > > > > Thanks Sven, > > > > > > One of the pages provided one solution I need: to ignore certain > instance variable while encoding. > > > > > > I, however, do not understand the problem for Pharo to produce json > for arbitrary objects just like any Java API â I thought it would even be > simpler. > > > > > > " In Pharo/Smalltalk, contrary to Java, we are not used to full type > descriptions. " > > > > > > Well, but you need to? Java APIs use reflection to do this job, when > looking inside an object you can tell it's type. Every API will do a best > effort to navigate through object nesting and, very often, it will find > known primitive objects down the road. So complex objects are created from > less complex ones, that area created eventually from from primitives. If it > cannot deal with the object serialization, it raises an error and generally > there are mapping features to deal with those border cases. I was surprised > to see that was not the case with STON and NeoJSON (well, it appears that > STON tries to do it for it's format) > > > > > > The serialization is also simple, you do something like: > > > > > > ston forClass: MyComplexObject desserialize: aJsonString > > > > > > > > > And well, that is it. > > > > > > On Fri, Mar 20, 2020 at 8:46 AM PBKResearch <peter(a)pbkresearch.co.uk> > wrote: > > > Vitor > > > > > > > > > > > > First clarification: There are two different serialization formats, > json and STON. The content of a json file can only be number, Boolean, > string, array, dictionary. STON is an extended form based on json, designed > to represent (almost) any Smalltalk object. > > > > > > > > > > > > Second clarification: What are you trying to do? Do you want to > serialize data for your own use, to read back into your own Pharo app? Or > do you want to export data in json format, so that other users, not using > necessarily using Pharo, can import it? For the first case, STON is a very > flexible and convenient system. For the second case, you must stick to > strict json, using only the classes allowed in json. > > > > > > > > > > > > Coming to your specific examples, Date is not a class allowed in json. > This is not a limitation of NeoJson or STON, it is a limitation of the > definition of json. If you want to include a Date in a json file, you must > turn it into an instance of a permitted class. So you could write: > > > > > > > > > > > > STON toJsonString: Date today asString. > > > > > > > > > > > > The only complication here is, if the json is read by other users, > they must understand the format generated by Date>>asString. > > > > > > > > > > > > If you are using STON to serialise objects for your own use, you may > want to exclude some instvars (e.g. block closures). This is described in > the class comments to the STON-Core package. You need to include a class > side message #stonAllInstVarNames in the class, which lists the names of > the instvars that are to be serialized. > > > > > > > > > > > > If you want to go deeper into STON, I think Sven has an article on his > website telling the whole story. This maybe enough to get you started. > > > > > > > > > > > > HTH > > > > > > > > > > > > Peter Kenny > > > > > > > > > > > > From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of > Vitor Medina Cruz > > > Sent: 20 March 2020 01:20 > > > To: Any question about pharo is welcome <Pharo-users(a)lists.pharo.org> > > > Subject: [Pharo-users] Json encoding > > > > > > > > > > > > Hello, > > > > > > > > > > > > I know two projects of json encoding/decoding â NeoJson and STON. > > > > > > > > > > > > In Java I have two most used ones too: Gson and Jackson. Using those I > can simply pass any object and it they can convert to a json string, the > former can't deal with cycles, the latter can with some little config. > > > > > > > > > > > > NeoJson seems to be limited to primitives, for example, in Pharo 8 I > can't run > > > > > > > > > > > > NeoJSONWriter toString: (Date today) > > > > > > > > > > > > Since I got: > > > > > > > > > > > > NeoJSONMappingNotFound: No mapping found for Date in NeoJSONWriter > > > > > > > > > > > > > > > > > > STON works fine with > > > > > > > > > > > > STON toString: (Date today). > > > > > > > > > > > > but fail with: > > > > > > > > > > > > STON toJsonString: (Date today). > > > > > > > > > > > > Also, STON fails if I try to serialize an object which contains an > instance variable pointing to a block closure. I didn't find out how to > ignore these instance variable as it is unnecessary for what I need at the > moment. > > > > > > > > > > > > So, which lib for json or some object/string encoding/decoding should > I be using on Pharo? Is there something better than those libs? Am I doing > something wrong? My experience tells this should be simple, but it is not. > > > > > > > > > > > > Thanks in advance, > > > > > > Vitor > > > > > > > > > >

March 21, 2020