- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Metacello doubt

by Guido Chari

I'm in. 2013/6/26 Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> > > > ------------------------------ > > *From: *"Guido Chari" <charig(a)gmail.com> > *To: *"Pharo Development List" <pharo-dev(a)lists.pharo.org> > *Sent: *Wednesday, June 26, 2013 2:49:09 PM > > *Subject: *Re: [Pharo-dev] Metacello doubt > > I understood. Thanks for the answer Dale. The drawback in this case is to > specify a particular dependency to AsmJit in my configuration. Also, > perhaps is the right way since i realized i have a particular dependency on > it. > > But this discussion makes me thing a little and so i have a new question. > > Form what I (mis) undestand from Metacello, when asking for a bleedingEdge > version it loads only the baseline that specifies packages and then last > version of every package specified there. > > As in the projects referenced on the baseline there is no need for > specifying a version, and that's the case of nativeBoost configuration, > wouldn't it be interesting to have some behavior (i mean i new method for > loading like loadDeepSymbolic:) that not only load the symbolicVersion of > the package asked, but also propagate that symbolicVersion (bleedingEdge in > this case) to all the dependencies that don't specify a concrete version? > > Guido. > > Guido, > > With the Metacello Scripting API[1] I've taken a slightly different tack, > but I think that it gets you to the same place. > > I am a big fan of deterministic loads, but I know that from a practical > point of view developers need to have a certain amount of control over > exactly what gets loaded into their DEVELOPMENT environments and they need > to be able to exert this control without having to resort to editing > configurations to match their specific requirements. > > I have accomplished this by arranging for a Notification to be signalled > whenever a project is referenced during a load. The developer can use one > or more of the onUpgrade:, onDowngrade: and onConflict: clauses in their > load scripts to exert fine control over what happens on a project by > project basis ... > > For your specific use case, I would think that you would want to use the > `lock` command[2] and specify that you want to `lock` the projects > (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if > I've got test cases for symbolic versions, but if you are seriously > interested in taking the Scripting API for a spin, I'd be willing to write > some additional tests using the #bleedingEdge symbolic version (if not > already covered) and validate this use case... > > I am entering a phase where I will be doing some work on getting FileTree > and Metacello up to snuff for Pharo3.0 so this would be a good time for me > to add some test cases in anticipation of having some interested users ... > > I haven't released the Scripting API, because I need to have real users > with real use cases take the API for a spin and validate the API. The > Scripting API can be loaded into any version of Pharo/Squeak/GemStone and I > think the Scripting API is (or will be) available in Pharo3.0. > > I'm looking forward to getting feedback as to how the API stands up to > real use ... > > So let me know if you are interested in being another Scripting API guinea > pig:) > > Dale > > [1] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > [2] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > >

June 27, 2013

Re: [Pharo-dev] Metacello doubt

by Guido Chari

The problem is that my use case is a jenkins job. I want to have something that is the more automatically as possible. On the other hand, i like tools that support the user to be as free as possible. More if we are taking about tools for developers. In this case, i guess its not bad to have metacello allowing for developers to automatically load last version of every package. I think i have a clear use case here where i have a need that could be perhaps tackled with Metacello and is hard to tackle other way. 2013/6/27 Igor Stasenko <siguctua(a)gmail.com> > Just adding some comments: > - i avoid using loading bleeding edge > because it has problems which only humans can solve: > - if there are two different branches, not yet merged it may load > not one that you want > - even if dependencies is ok, it doesn't means that if you load two > latest versions of two packages, > they will work > > so, what i do, is loading a known working config, and then go to > monticello and manually picking and loading updated packages. > > On 27 June 2013 01:27, Dale K. Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: > > > > > > ________________________________ > > > > From: "Guido Chari" <charig(a)gmail.com> > > > > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > Sent: Wednesday, June 26, 2013 2:49:09 PM > > Subject: Re: [Pharo-dev] Metacello doubt > > > > I understood. Thanks for the answer Dale. The drawback in this case is to > > specify a particular dependency to AsmJit in my configuration. Also, > perhaps > > is the right way since i realized i have a particular dependency on it. > > > > But this discussion makes me thing a little and so i have a new question. > > > > Form what I (mis) undestand from Metacello, when asking for a > bleedingEdge > > version it loads only the baseline that specifies packages and then last > > version of every package specified there. > > > > As in the projects referenced on the baseline there is no need for > > specifying a version, and that's the case of nativeBoost configuration, > > wouldn't it be interesting to have some behavior (i mean i new method for > > loading like loadDeepSymbolic:) that not only load the symbolicVersion of > > the package asked, but also propagate that symbolicVersion (bleedingEdge > in > > this case) to all the dependencies that don't specify a concrete version? > > > > Guido. > > > > Guido, > > > > With the Metacello Scripting API[1] I've taken a slightly different tack, > > but I think that it gets you to the same place. > > > > I am a big fan of deterministic loads, but I know that from a practical > > point of view developers need to have a certain amount of control over > > exactly what gets loaded into their DEVELOPMENT environments and they > need > > to be able to exert this control without having to resort to editing > > configurations to match their specific requirements. > > > > I have accomplished this by arranging for a Notification to be signalled > > whenever a project is referenced during a load. The developer can use > one or > > more of the onUpgrade:, onDowngrade: and onConflict: clauses in their > load > > scripts to exert fine control over what happens on a project by project > > basis ... > > > > For your specific use case, I would think that you would want to use the > > `lock` command[2] and specify that you want to `lock` the projects > > (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if > > I've got test cases for symbolic versions, but if you are seriously > > interested in taking the Scripting API for a spin, I'd be willing to > write > > some additional tests using the #bleedingEdge symbolic version (if not > > already covered) and validate this use case... > > > > I am entering a phase where I will be doing some work on getting FileTree > > and Metacello up to snuff for Pharo3.0 so this would be a good time for > me > > to add some test cases in anticipation of having some interested users > ... > > > > I haven't released the Scripting API, because I need to have real users > with > > real use cases take the API for a spin and validate the API. The > Scripting > > API can be loaded into any version of Pharo/Squeak/GemStone and I think > the > > Scripting API is (or will be) available in Pharo3.0. > > > > I'm looking forward to getting feedback as to how the API stands up to > real > > use ... > > > > So let me know if you are interested in being another Scripting API > guinea > > pig:) > > > > Dale > > > > [1] > > > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > > [2] > > > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > > > > -- > Best regards, > Igor Stasenko. > >

June 27, 2013

Re: [Pharo-dev] cleaning pasteUpMorph

by StÃ©phane Ducasse

We should also remove ActiveWorld since there is already World as global! Stef On Jun 27, 2013, at 6:53 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > We will have also to clarify the invariant between > > hands first and currentHand (pointing to the global ActiveHand). > > Stef > On Jun 27, 2013, at 6:45 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > >> there is currentHand, primaryHandâ¦.. >> and lovely code like that >> >> primaryHand >> >> | outer | >> outer := self outermostWorldMorph ifNil: [^ nil]. >> ^ outer activeHand ifNil: [outer firstHand] > >

June 27, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 1 regressions found. KernelTests.Numbers.NumberTest.testUnCategorizedMethods

June 27, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 1 regressions found. KernelTests.Numbers.NumberTest.testUnCategorizedMethods

June 27, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 1 regressions found. KernelTests.Numbers.NumberTest.testUnCategorizedMethods

June 27, 2013

Re: [Pharo-dev] cleaning pasteUpMorph

by StÃ©phane Ducasse

We will have also to clarify the invariant between hands first and currentHand (pointing to the global ActiveHand). Stef On Jun 27, 2013, at 6:45 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > there is currentHand, primaryHandâ¦.. > and lovely code like that > > primaryHand > > | outer | > outer := self outermostWorldMorph ifNil: [^ nil]. > ^ outer activeHand ifNil: [outer firstHand]

June 27, 2013

cleaning pasteUpMorph

by StÃ©phane Ducasse

there is currentHand, primaryHandâ¦.. and lovely code like that primaryHand | outer | outer := self outermostWorldMorph ifNil: [^ nil]. ^ outer activeHand ifNil: [outer firstHand]

June 27, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by StÃ©phane Ducasse

Igor we should document such mistakes This is important can you add such comments in class comment? On Jun 27, 2013, at 5:26 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 27 June 2013 17:14, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> On Jun 27, 2013, at 4:11 , Igor Stasenko wrote: >> >>> >>>> Or is a disclaimer not to use the class for, say, 'char*' elements more >>>> appropriate? >>>> >>> no , it should be fine. >> >> Was thinking of that in conjunction with putting ST object refs in the External arrays, the trying to pass as parameters, it could be a recipe for disaster :) >> Like, say: >> >> "Add a null at end so ExternalArrays basic #readString won't keep on readin'" >> string := 'Hello world!' copyWith: (Character value: 0). >> extArray := (NBExternalArray ofType: 'char*') new: 1. >> "Tenure the string first, lest we invalidate on next scavenge" >> Smalltalk garbageCollectMost. >> extArray at:1 put: string. >> >> "X our fingers, and hope GC doesn't move string. >> Often serves as a nice example that it will :)" >> (extArray at: 1) readString >> string at: 7 put: $W. >> (extArray at: 1) readString >> > hehe.. that certainly a recipe for disaster. > > That's why there should be no NBExternalValue>>address (pointing at Ciprian), > which answers a pointer to oop's first byte, like that given test: > > testOutVoidArg > |x value| > NBTestExternalValue initialize. > value := 12345678. > x := NBTestExternalValue new. > > self outputVoidArg: x address value: value. > > self assert: x value = value. > > may work. > But actually it will not. And this is **WRONG** in same way as your example. > >> Cheers, >> Henry > > > > -- > Best regards, > Igor Stasenko. >

June 27, 2013

Re: [Pharo-dev] [update 3.0] #30228

by Marcus Denker

On Jun 27, 2013, at 6:09 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > â¦ old class builder tests might fail after this one. > They actually failed so hard that the build did bot succeedâ¦ we will try again tomorrow with a slice that removes the tests. > 30228 > ----- > > 11047 Integrate new class builder step 2 > https://pharo.fogbugz.com/f/cases/11047 > > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.8… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/SlotTests-MarcusDenker.24.diff >

June 27, 2013