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

Re: [Pharo-users] question about primitives

by Werner Kassens

Hi Ben, i stumbled upon https://github.com/smarr/RoarVM/blob/master/vm/src/interpreter/obsolete_nam… werner On 03/23/2014 05:56 PM, Ben Coman wrote: > Sorry I'm not able to answer your question - but I'm curious.... with > your espoused lack of vm knowledge :) how did you find that the second > primitive even existed? (I might like to follow the same path) > > cheers -Ben > >

March 23, 2014

Re: [Pharo-users] question about primitives

by Ben Coman

Werner Kassens wrote: > Hi, > i dont know anything about primitives or the vm, hence this could very > well be an extremely stupid question, but anyway: > > i use pharo 2.0 Latest update: #20628 and (i think) pharo VM version: > 3.9-7. (btw how do i look up the vm version?). > > in the package Collections-Arithmetic there is this method > FloatArray>>dot: > > dot: aFloatVector > "Primitive. Return the dot product of the receiver and the argument. > Fail if the argument is not of the same size as the receiver." > | result | > "<primitive:'primitiveFloatArrayDotProduct'>" > self size ......bla bla > > when i change this to: > > dot: aFloatVector > "Primitive. Return the dot product of the receiver and the argument. > Fail if the argument is not of the same size as the receiver." > | result | > <primitive: 'primitiveDotProduct' module: 'FloatArrayPlugin'> > "<primitive:'primitiveFloatArrayDotProduct'>" > self size ......bla bla > > it becomes much faster, iow it uses the primitive, and it seems to > produce the same results. hence my question, was it perhaps just > overlooked, that the primitive has a new name, or what is the reason > for not using it? > werner > > Hi Werner, Sorry I'm not able to answer your question - but I'm curious.... with your espoused lack of vm knowledge :) how did you find that the second primitive even existed? (I might like to follow the same path) cheers -Ben

March 23, 2014

question about primitives

by Werner Kassens

Hi, i dont know anything about primitives or the vm, hence this could very well be an extremely stupid question, but anyway: i use pharo 2.0 Latest update: #20628 and (i think) pharo VM version: 3.9-7. (btw how do i look up the vm version?). in the package Collections-Arithmetic there is this method FloatArray>>dot: dot: aFloatVector "Primitive. Return the dot product of the receiver and the argument. Fail if the argument is not of the same size as the receiver." | result | "<primitive:'primitiveFloatArrayDotProduct'>" self size ......bla bla when i change this to: dot: aFloatVector "Primitive. Return the dot product of the receiver and the argument. Fail if the argument is not of the same size as the receiver." | result | <primitive: 'primitiveDotProduct' module: 'FloatArrayPlugin'> "<primitive:'primitiveFloatArrayDotProduct'>" self size ......bla bla it becomes much faster, iow it uses the primitive, and it seems to produce the same results. hence my question, was it perhaps just overlooked, that the primitive has a new name, or what is the reason for not using it? werner

March 23, 2014

Re: [Pharo-users] NeoJSON and inheritance

by phil＠highoctane.be

Super! On Sat, Mar 22, 2014 at 11:15 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > Phil, > > I finally found time to look in to this in detail and added a test with > inheritance. > > In #bleedingEdge: > > === > Name: Neo-JSON-Core-SvenVanCaekenberghe.25 > Author: SvenVanCaekenberghe > Time: 22 March 2014, 11:03:31.510538 am > UUID: 3051cd7d-a857-4aee-b5ba-d56a4085517b > Ancestors: Neo-JSON-Core-SvenVanCaekenberghe.24 > > Added basic support for mapping using inheritance when using > #neoJonMapping : (see #testObject3) > Renamed #new[Custom|Object]MappingFor: to [custom|object]MappingFor: to > better reflect the new behavior > Thanks Philippe Back for making these suggestions! > === > Name: Neo-JSON-Tests-SvenVanCaekenberghe.23 > Author: SvenVanCaekenberghe > Time: 22 March 2014, 11:04:11.513921 am > UUID: 27fad240-c6b9-4d00-a4e6-6e49fd612dfb > Ancestors: Neo-JSON-Tests-SvenVanCaekenberghe.22 > > Added basic support for mapping using inheritance when using > #neoJonMapping : (see #testObject3) > Renamed #new[Custom|Object]MappingFor: to [custom|object]MappingFor: to > better reflect the new behavior > Thanks Philippe Back for making these suggestions! > === > > On 17 Mar 2014, at 18:01, phil(a)highoctane.be wrote: > > > NeoJSONMapper>>newObjectMappingFor: smalltalkClass > > | mapping | > > > > mapping := self mappings at: smalltalkClass ifAbsent: [ > > mapping := NeoJSONObjectMapping new. > > mapping subjectClass: smalltalkClass. > > self mappings at: smalltalkClass put: mapping. > > ]. > > > > ^ mapping > > > > > > works better ... > > #at:ifAbsentPut: is even better ;-) > > Regards, > > Sven > > > Phil > > > > On Mon, Mar 17, 2014 at 5:40 PM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > > The "super" thing doesn't work. > > > > I have spent a while tracing what was occuring with the custom mappings. > > > > If in a subclass I do: > > > > neoJsonMapping: aMapper > > super neoJsonMapping: aMapper. > > > > aMapper for: self do: [ :mapping | > > mapping > > mapProperty: 'startDate' getter: [ :filter | > filter startDate ] setter: [ :filter :value | filter startDate: value ]; > > mapProperty: 'endDate' getter: [ :filter | filter > endDate ] setter: [ :filter :value | filter endDate: value ]. > > ] > > > > and in the superclass: > > > > neoJsonMapping: aMapper > > aMapper for: self do: [ :mapping | > > mapping mapInstVar: #id to: 'id'. > > ] > > > > (do not pay attention to mapInstVar or mapProperty, I was figuring out > how things worked). > > > > Thing is that the mapping goes fine up to one point. > > > > super neoJsonMapping: aMapper > > > > indeed puts the right 'id' mapping but then > > > > aMapper for:: self do: [ ... > > > > does > > > > for: smalltalkClass do: block > > "Create and add a new standard object mapping for smalltalkClass. > > The code in block should further customize the mapping." > > > > | mapping | > > mapping := self newObjectMappingFor: smalltalkClass. > > block value: mapping. > > ^ mapping > > > > > > which in turn: > > > > newObjectMappingFor: smalltalkClass > > | mapping | > > mapping := NeoJSONObjectMapping new. > > mapping subjectClass: smalltalkClass. > > self mappings at: smalltalkClass put: mapping. > > ^ mapping > > > > > > > > Argh: self mappings at: smalltalkClass put: mapping. > > > > Overwrites the existing contents. > > > > So, only the entries of the subclass are left. > > > > I guess that's a bug. > > > > I'd do: > > > > newObjectMappingFor: smalltalkClass > > | mapping | > > > > mapping := self mappings at: smalltalkClass. > > > > mapping ifNil: [ > > mapping := NeoJSONObjectMapping new. > > mapping subjectClass: smalltalkClass. > > self mappings at: smalltalkClass put: mapping. > > ]. > > > > ^ mapping > > > > instead. > > > > Does this look right? > > > > mapping := self newObjectMappingFor: smalltalkClass. > > > > isn't then really intention revealing. Shouldn't we rename that to > objectMappingFor: smalltalkClass > > > > > > Phil > > > > > > > > > > > > > > On Fri, Sep 27, 2013 at 7:07 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Norbert, > > > > On 26 Sep 2013, at 11:32, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > > How is inheritance supposed to work in NeoJSON? I only figured it out > by doing that manually: > > > > > > neoJsonMapping: aMapper > > > super neoJsonMapping: aMapper. > > > (aMapper mappingFor: self) > > > mapInstVar: #longitude; > > > mapInstVar: #latitude. > > > > > > Is there a better way to do? > > > > > > Norbert > > > > What you figured out yourself is the only inheritance that is available. > > > > The thing is, schema names (which can be plain Symbols or Class objects) > are meant to be used for things like #ArrayOfPoints, > #DictionaryWithUserValues which tell something about subtypes. I hurts to > think of an inheritance for that ;-) > > > > Sven > > > > > > > > > >

March 22, 2014

Re: [Pharo-users] NeoJSON and inheritance

by Sven Van Caekenberghe

Phil, I finally found time to look in to this in detail and added a test with inheritance. In #bleedingEdge: === Name: Neo-JSON-Core-SvenVanCaekenberghe.25 Author: SvenVanCaekenberghe Time: 22 March 2014, 11:03:31.510538 am UUID: 3051cd7d-a857-4aee-b5ba-d56a4085517b Ancestors: Neo-JSON-Core-SvenVanCaekenberghe.24 Added basic support for mapping using inheritance when using #neoJonMapping : (see #testObject3) Renamed #new[Custom|Object]MappingFor: to [custom|object]MappingFor: to better reflect the new behavior Thanks Philippe Back for making these suggestions! === Name: Neo-JSON-Tests-SvenVanCaekenberghe.23 Author: SvenVanCaekenberghe Time: 22 March 2014, 11:04:11.513921 am UUID: 27fad240-c6b9-4d00-a4e6-6e49fd612dfb Ancestors: Neo-JSON-Tests-SvenVanCaekenberghe.22 Added basic support for mapping using inheritance when using #neoJonMapping : (see #testObject3) Renamed #new[Custom|Object]MappingFor: to [custom|object]MappingFor: to better reflect the new behavior Thanks Philippe Back for making these suggestions! === On 17 Mar 2014, at 18:01, phil(a)highoctane.be wrote: > NeoJSONMapper>>newObjectMappingFor: smalltalkClass > | mapping | > > mapping := self mappings at: smalltalkClass ifAbsent: [ > mapping := NeoJSONObjectMapping new. > mapping subjectClass: smalltalkClass. > self mappings at: smalltalkClass put: mapping. > ]. > > ^ mapping > > > works better ... #at:ifAbsentPut: is even better ;-) Regards, Sven > Phil > > On Mon, Mar 17, 2014 at 5:40 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > The "super" thing doesn't work. > > I have spent a while tracing what was occuring with the custom mappings. > > If in a subclass I do: > > neoJsonMapping: aMapper > super neoJsonMapping: aMapper. > > aMapper for: self do: [ :mapping | > mapping > mapProperty: 'startDate' getter: [ :filter | filter startDate ] setter: [ :filter :value | filter startDate: value ]; > mapProperty: 'endDate' getter: [ :filter | filter endDate ] setter: [ :filter :value | filter endDate: value ]. > ] > > and in the superclass: > > neoJsonMapping: aMapper > aMapper for: self do: [ :mapping | > mapping mapInstVar: #id to: 'id'. > ] > > (do not pay attention to mapInstVar or mapProperty, I was figuring out how things worked). > > Thing is that the mapping goes fine up to one point. > > super neoJsonMapping: aMapper > > indeed puts the right 'id' mapping but then > > aMapper for:: self do: [ ... > > does > > for: smalltalkClass do: block > "Create and add a new standard object mapping for smalltalkClass. > The code in block should further customize the mapping." > > | mapping | > mapping := self newObjectMappingFor: smalltalkClass. > block value: mapping. > ^ mapping > > > which in turn: > > newObjectMappingFor: smalltalkClass > | mapping | > mapping := NeoJSONObjectMapping new. > mapping subjectClass: smalltalkClass. > self mappings at: smalltalkClass put: mapping. > ^ mapping > > > > Argh: self mappings at: smalltalkClass put: mapping. > > Overwrites the existing contents. > > So, only the entries of the subclass are left. > > I guess that's a bug. > > I'd do: > > newObjectMappingFor: smalltalkClass > | mapping | > > mapping := self mappings at: smalltalkClass. > > mapping ifNil: [ > mapping := NeoJSONObjectMapping new. > mapping subjectClass: smalltalkClass. > self mappings at: smalltalkClass put: mapping. > ]. > > ^ mapping > > instead. > > Does this look right? > > mapping := self newObjectMappingFor: smalltalkClass. > > isn't then really intention revealing. Shouldn't we rename that to objectMappingFor: smalltalkClass > > > Phil > > > > > > > On Fri, Sep 27, 2013 at 7:07 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Norbert, > > On 26 Sep 2013, at 11:32, Norbert Hartl <norbert(a)hartl.name> wrote: > > > How is inheritance supposed to work in NeoJSON? I only figured it out by doing that manually: > > > > neoJsonMapping: aMapper > > super neoJsonMapping: aMapper. > > (aMapper mappingFor: self) > > mapInstVar: #longitude; > > mapInstVar: #latitude. > > > > Is there a better way to do? > > > > Norbert > > What you figured out yourself is the only inheritance that is available. > > The thing is, schema names (which can be plain Symbols or Class objects) are meant to be used for things like #ArrayOfPoints, #DictionaryWithUserValues which tell something about subtypes. I hurts to think of an inheritance for that ;-) > > Sven > > >

March 22, 2014

Re: [Pharo-users] Configuration Browser

by Pharo4Stef

Yes we asked engineer positions to build such kind of infrastructure but it was rejected soâ¦ > >There is no easy solution > > A step along the way would be that CI job uploading the equivalent in STON/JSON format to files.pharo.org (maybe .../updates/catalog or .../extra/catalog) > Having the raw data accessible would facilitate others (or at least me) experimenting with ConfigurationBrowser to display the descriptions. > > cheers -ben >

March 22, 2014

Re: [Pharo-users] Configuration Browser

by Sven Van Caekenberghe

On 22 Mar 2014, at 02:31, Ben Coman <btc(a)openInWorld.com> wrote: > Sven Van Caekenberghe wrote: >> Hi Markus, >> >> On 21 Mar 2014, at 18:44, Markus Fritsche >> <fritsche.markus(a)gmail.com> >> wrote: >> >> >> >>> Hello, >>> >>> is not having a field for description or a link to a description in ConfigurationBrowser a design decision? >>> >>> Best regards, >>> Markus >>> >>> >> >> A Metacello configuration is just a single class inside a Monticello package. The Configuration Browser lists all those MC packages from a repository. >> >> Recently, we started with a convention for a couple of methods that form a meta description of the configuration. >> >> >> https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? >> >> >> It will take a while before all those descriptions are added. >> >> However, in order to see them, you have to load the configuration (not install the code), it is not enough to just look at the MC package. There is no easy solution. >> >> HTH, >> >> Sven >> >> >> >> > >There is no easy solution > > A step along the way would be that CI job uploading the equivalent in STON/JSON format to files.pharo.org (maybe .../updates/catalog or .../extra/catalog) > Having the raw data accessible would facilitate others (or at least me) experimenting with ConfigurationBrowser to display the descriptions. Yes, that would be a solution, it just has to be built ;-)

March 22, 2014

Re: [Pharo-users] Configuration Browser

by Ben Coman

March 22, 2014

Re: [Pharo-users] Configuration Browser

by Sven Van Caekenberghe

Hi Markus, On 21 Mar 2014, at 18:44, Markus Fritsche <fritsche.markus(a)gmail.com> wrote: > Hello, > > is not having a field for description or a link to a description in ConfigurationBrowser a design decision? > > Best regards, > Markus A Metacello configuration is just a single class inside a Monticello package. The Configuration Browser lists all those MC packages from a repository. Recently, we started with a convention for a couple of methods that form a meta description of the configuration. https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? It will take a while before all those descriptions are added. However, in order to see them, you have to load the configuration (not install the code), it is not enough to just look at the MC package. There is no easy solution. HTH, Sven

March 21, 2014

Configuration Browser

by Markus Fritsche

Hello, is not having a field for description or a link to a description in ConfigurationBrowser a design decision? Best regards, Markus

March 21, 2014