Thanks, i have some deadlines this week but i will have a look and give you feedback asap.
2013/7/17 Dale K. Henrichs <[email protected]> > Guido, > > I've just released Metacello Preview 1.0.0-beta.32.8[1] that includes a > bugfix for your issue. Let me know if you need more information. > > Dale > > [1] > http://gemstonesoup.wordpress.com/2013/07/17/metacello-preview-1-0-0-beta-32-8-composed/ > > ------------------------------ > > *From: *"Guido Chari" <[email protected]> > *To: *"Pharo Development List" <[email protected]> > *Sent: *Tuesday, July 2, 2013 12:42:40 PM > > *Subject: *Re: [Pharo-dev] Metacello doubt > > Ok, i will follow the issue on github. Thanks! > > > 2013/7/1 Dale K. Henrichs <[email protected]> > >> Guido, >> >> I created a test case and it turns out that there _is_ a bug in the >> bypass lock logic[1] . I'm going to push out a new version of the Metacello >> Preview (1.0.0-beta.32.8) in the next day or so and the bugfix for Issue >> #174 will _not_ be included in that release ... >> >> Dale >> >> [1] https://github.com/dalehenrich/metacello-work/issues/174 >> >> ------------------------------ >> >> *From: *"Guido Chari" <[email protected]> >> *To: *"Pharo Development List" <[email protected]> >> *Sent: *Thursday, June 27, 2013 10:23:33 AM >> *Subject: *Re: [Pharo-dev] Metacello doubt >> >> I'm in. >> >> >> 2013/6/26 Dale K. Henrichs <[email protected]> >> >>> >>> >>> ------------------------------ >>> >>> *From: *"Guido Chari" <[email protected]> >>> *To: *"Pharo Development List" <[email protected]> >>> *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/MetacelloUserGuide.md >>> [2] >>> https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking >>> >>> >> >> > >
