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/ ----- Original Message ----- | 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 | | | | | |
