I have a question since i'm trying to create some jenkins job for the first time. Sorry if this was already discussed... I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?
On Wed, Jun 26, 2013 at 4:27 PM, Guido Chari <charig@gmail.com> wrote:
I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?
you can't I guess. Each package maintainer decides what is best for the dependencies. If you want to override this, I still guess you have to make your package depend on all the dependencies of all your dependencies (recursively). -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Guido, If the maintainer of a configuration would like to support bleeding edge loads that propagate through the dependent projects then they should specify which baseline version to use for each dependent project. For Native Boost the entry for AsmJit in the #baseline13: method could be changed to: project: 'AsmJit' with: [ spec className: 'ConfigurationOfAsmJit'; "==>" versionString: #bleedingEdge; repository: 'http://www.smalltalkhub.com/mc/Pharo/AsmJit/main' ]; Then the bleedingEdge load would be propagated through to the dependents ... but then you'd want the AsmJit configuration modified as well:) Dale ----- Original Message ----- | From: "Guido Chari" <charig@gmail.com> | To: pharo-dev@lists.pharo.org | Sent: Wednesday, June 26, 2013 7:27:19 AM | Subject: [Pharo-dev] Metacello doubt | I have a question since i'm trying to create some jenkins job for the | first time. Sorry if this was already discussed... | I have a dependency with for example NativeBoost. And i want | NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" | NativeBoost is on its last version on every package but not its own | dependencies as for example AsmJit. Is this the right behavior? How | can i express to have not only my dependency but also the | dependencies of my dependencies in its bleedingEdge version?
While we are at it, is there any documentation for the MetacelloToolbox? Couldn't find... Saw Sean's thing but nothing else. Would be great! TIA Phil --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Wed, Jun 26, 2013 at 9:21 PM, Dale K. Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Guido,
If the maintainer of a configuration would like to support bleeding edge loads that propagate through the dependent projects then they should specify which baseline version to use for each dependent project. For Native Boost the entry for AsmJit in the #baseline13: method could be changed to:
project: 'AsmJit' with: [ spec className: 'ConfigurationOfAsmJit'; "==>" versionString: #bleedingEdge; repository: ' http://www.smalltalkhub.com/mc/Pharo/AsmJit/main' ];
Then the bleedingEdge load would be propagated through to the dependents ... but then you'd want the AsmJit configuration modified as well:)
Dale
------------------------------
*From: *"Guido Chari" <charig@gmail.com> *To: *pharo-dev@lists.pharo.org *Sent: *Wednesday, June 26, 2013 7:27:19 AM *Subject: *[Pharo-dev] Metacello doubt
I have a question since i'm trying to create some jenkins job for the first time. Sorry if this was already discussed...
I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?
Phil, Check out the System Help ... the API is documented under Metacello>>MetacelloToolBox ... under PrfStef>>Browse tutorials>>Inside Metacello Toolbox there are 5-6 lessons there are other Metacello tutorials there as well ... Dale ----- Original Message ----- | From: phil@highoctane.be | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Wednesday, June 26, 2013 1:45:36 PM | Subject: Re: [Pharo-dev] Metacello doubt | While we are at it, is there any documentation for the | MetacelloToolbox? | Couldn't find... Saw Sean's thing but nothing else. | Would be great! | TIA | Phil | --- | Philippe Back | Dramatic Performance Improvements | Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 | Mail:phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be | Twitter: @philippeback | Youtube: http://www.youtube.com/user/philippeback/videos | High Octane SPRL | rue cour Boisacq 101 | 1301 Bierges | Belgium | Featured on the Software Process and Measurement Cast | http://spamcast.libsyn.com | Sparx Systems Enterprise Architect and Ability Engineering EADocX | Value Added Reseller | On Wed, Jun 26, 2013 at 9:21 PM, Dale K. Henrichs < | dale.henrichs@gemtalksystems.com > wrote: | | Guido, | | | If the maintainer of a configuration would like to support bleeding | | edge loads that propagate through the dependent projects then they | | should specify which baseline version to use for each dependent | | project. For Native Boost the entry for AsmJit in the #baseline13: | | method could be changed to: | | | project: 'AsmJit' | | | with: [ | | | spec | | | className: 'ConfigurationOfAsmJit'; | | | "==>" versionString: #bleedingEdge; | | | repository: ' http://www.smalltalkhub.com/mc/Pharo/AsmJit/main ' ]; | | | Then the bleedingEdge load would be propagated through to the | | dependents ... but then you'd want the AsmJit configuration | | modified | | as well:) | | | Dale | | | | From: "Guido Chari" < charig@gmail.com > | | | | | | To: pharo-dev@lists.pharo.org | | | | | | Sent: Wednesday, June 26, 2013 7:27:19 AM | | | | | | Subject: [Pharo-dev] Metacello doubt | | | | | | I have a question since i'm trying to create some jenkins job for | | | the | | | first time. Sorry if this was already discussed... | | | | | | I have a dependency with for example NativeBoost. And i want | | | NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" | | | NativeBoost is on its last version on every package but not its | | | own | | | dependencies as for example AsmJit. Is this the right behavior? | | | How | | | can i express to have not only my dependency but also the | | | dependencies of my dependencies in its bleedingEdge version? | | |
I loaded ConfigurationOfProfStef but there is no MetacelloToolbox documentation in there. What do I miss? Phil --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Wed, Jun 26, 2013 at 11:56 PM, Dale K. Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Phil,
Check out the System Help ... the API is documented under Metacello>>MetacelloToolBox ... under PrfStef>>Browse tutorials>>Inside Metacello Toolbox there are 5-6 lessons there are other Metacello tutorials there as well ...
Dale
------------------------------
*From: *phil@highoctane.be *To: *"Pharo Development List" <pharo-dev@lists.pharo.org> *Sent: *Wednesday, June 26, 2013 1:45:36 PM *Subject: *Re: [Pharo-dev] Metacello doubt
While we are at it, is there any documentation for the MetacelloToolbox?
Couldn't find... Saw Sean's thing but nothing else.
Would be great!
TIA Phil
--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Wed, Jun 26, 2013 at 9:21 PM, Dale K. Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Guido,
If the maintainer of a configuration would like to support bleeding edge loads that propagate through the dependent projects then they should specify which baseline version to use for each dependent project. For Native Boost the entry for AsmJit in the #baseline13: method could be changed to:
project: 'AsmJit' with: [ spec className: 'ConfigurationOfAsmJit'; "==>" versionString: #bleedingEdge; repository: ' http://www.smalltalkhub.com/mc/Pharo/AsmJit/main' ];
Then the bleedingEdge load would be propagated through to the dependents ... but then you'd want the AsmJit configuration modified as well:)
Dale
------------------------------
*From: *"Guido Chari" <charig@gmail.com> *To: *pharo-dev@lists.pharo.org *Sent: *Wednesday, June 26, 2013 7:27:19 AM *Subject: *[Pharo-dev] Metacello doubt
I have a question since i'm trying to create some jenkins job for the first time. Sorry if this was already discussed...
I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?
Ah, at one point in time the tutorial was loaded by default ... sorry about that. to get the Metacello tutorial execute: ConfigurationOfMetacello project currentVersion load: 'Tutorial' Then you can find the Metacello documentation under the Help menu in the Help Browser ... Dale ----- Original Message ----- | From: phil@highoctane.be | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Friday, June 28, 2013 6:48:59 AM | Subject: Re: [Pharo-dev] Metacello doubt | I loaded ConfigurationOfProfStef but there is no MetacelloToolbox | documentation in there. | What do I miss? | Phil | --- | Philippe Back | Dramatic Performance Improvements | Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 | Mail:phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be | Twitter: @philippeback | Youtube: http://www.youtube.com/user/philippeback/videos | High Octane SPRL | rue cour Boisacq 101 | 1301 Bierges | Belgium | Featured on the Software Process and Measurement Cast | http://spamcast.libsyn.com | Sparx Systems Enterprise Architect and Ability Engineering EADocX | Value Added Reseller | On Wed, Jun 26, 2013 at 11:56 PM, Dale K. Henrichs < | dale.henrichs@gemtalksystems.com > wrote: | | Phil, | | | Check out the System Help ... the API is documented under | | Metacello>>MetacelloToolBox ... under PrfStef>>Browse | | tutorials>>Inside Metacello Toolbox there are 5-6 lessons there are | | other Metacello tutorials there as well ... | | | Dale | | | | From: phil@highoctane.be | | | | | | To: "Pharo Development List" < pharo-dev@lists.pharo.org > | | | | | | Sent: Wednesday, June 26, 2013 1:45:36 PM | | | | | | Subject: Re: [Pharo-dev] Metacello doubt | | | | | | While we are at it, is there any documentation for the | | | MetacelloToolbox? | | | | | | Couldn't find... Saw Sean's thing but nothing else. | | | | | | Would be great! | | | | | | TIA | | | | | | Phil | | | | | | --- | | | | | | Philippe Back | | | | | | Dramatic Performance Improvements | | | | | | Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 | | | | | | Mail:phil@highoctane.be | Web: http://philippeback.eu | | | | | | Blog: http://philippeback.be | Twitter: @philippeback | | | | | | Youtube: http://www.youtube.com/user/philippeback/videos | | | | | | High Octane SPRL | | | | | | rue cour Boisacq 101 | 1301 Bierges | Belgium | | | | | | Featured on the Software Process and Measurement Cast | | | | | | http://spamcast.libsyn.com | | | | | | Sparx Systems Enterprise Architect and Ability Engineering EADocX | | | Value Added Reseller | | | | | | On Wed, Jun 26, 2013 at 9:21 PM, Dale K. Henrichs < | | | dale.henrichs@gemtalksystems.com > wrote: | | | | | | | Guido, | | | | | | | | | | If the maintainer of a configuration would like to support | | | | bleeding | | | | edge loads that propagate through the dependent projects then | | | | they | | | | should specify which baseline version to use for each dependent | | | | project. For Native Boost the entry for AsmJit in the | | | | #baseline13: | | | | method could be changed to: | | | | | | | | | | project: 'AsmJit' | | | | | | | | | | with: [ | | | | | | | | | | spec | | | | | | | | | | className: 'ConfigurationOfAsmJit'; | | | | | | | | | | "==>" versionString: #bleedingEdge; | | | | | | | | | | repository: ' http://www.smalltalkhub.com/mc/Pharo/AsmJit/main | | | | ' | | | | ]; | | | | | | | | | | Then the bleedingEdge load would be propagated through to the | | | | dependents ... but then you'd want the AsmJit configuration | | | | modified | | | | as well:) | | | | | | | | | | Dale | | | | | | | | | | | From: "Guido Chari" < charig@gmail.com > | | | | | | | | | | | | | | | To: pharo-dev@lists.pharo.org | | | | | | | | | | | | | | | Sent: Wednesday, June 26, 2013 7:27:19 AM | | | | | | | | | | | | | | | Subject: [Pharo-dev] Metacello doubt | | | | | | | | | | | | | | | I have a question since i'm trying to create some jenkins job | | | | | for | | | | | the | | | | | first time. Sorry if this was already discussed... | | | | | | | | | | | | | | | I have a dependency with for example NativeBoost. And i want | | | | | NativeBoost in its bleedingEdge version. If I | | | | | "loadBleedingEdge" | | | | | NativeBoost is on its last version on every package but not | | | | | its | | | | | own | | | | | dependencies as for example AsmJit. Is this the right | | | | | behavior? | | | | | How | | | | | can i express to have not only my dependency but also the | | | | | dependencies of my dependencies in its bleedingEdge version? | | | | | | | | | |
Much better indeed! Now, it would be useful to have the same in HTML format on the web as this is really not super easy to find. (I am often looking that what is on pages like https://code.google.com/p/metacello/wiki/CreateMetacelloConfiguration) Thanks! Phil --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Fri, Jun 28, 2013 at 3:55 PM, Dale K. Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Ah, at one point in time the tutorial was loaded by default ... sorry about that. to get the Metacello tutorial execute:
ConfigurationOfMetacello project currentVersion load: 'Tutorial'
Then you can find the Metacello documentation under the Help menu in the Help Browser ...
Dale ------------------------------
*From: *phil@highoctane.be *To: *"Pharo Development List" <pharo-dev@lists.pharo.org> *Sent: *Friday, June 28, 2013 6:48:59 AM *Subject: *Re: [Pharo-dev] Metacello doubt
I loaded ConfigurationOfProfStef but there is no MetacelloToolbox documentation in there.
What do I miss?
Phil
--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Wed, Jun 26, 2013 at 11:56 PM, Dale K. Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Phil,
Check out the System Help ... the API is documented under Metacello>>MetacelloToolBox ... under PrfStef>>Browse tutorials>>Inside Metacello Toolbox there are 5-6 lessons there are other Metacello tutorials there as well ...
Dale
------------------------------
*From: *phil@highoctane.be *To: *"Pharo Development List" <pharo-dev@lists.pharo.org> *Sent: *Wednesday, June 26, 2013 1:45:36 PM *Subject: *Re: [Pharo-dev] Metacello doubt
While we are at it, is there any documentation for the MetacelloToolbox?
Couldn't find... Saw Sean's thing but nothing else.
Would be great!
TIA Phil
--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Wed, Jun 26, 2013 at 9:21 PM, Dale K. Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Guido,
If the maintainer of a configuration would like to support bleeding edge loads that propagate through the dependent projects then they should specify which baseline version to use for each dependent project. For Native Boost the entry for AsmJit in the #baseline13: method could be changed to:
project: 'AsmJit' with: [ spec className: 'ConfigurationOfAsmJit'; "==>" versionString: #bleedingEdge; repository: ' http://www.smalltalkhub.com/mc/Pharo/AsmJit/main' ];
Then the bleedingEdge load would be propagated through to the dependents ... but then you'd want the AsmJit configuration modified as well:)
Dale
------------------------------
*From: *"Guido Chari" <charig@gmail.com> *To: *pharo-dev@lists.pharo.org *Sent: *Wednesday, June 26, 2013 7:27:19 AM *Subject: *[Pharo-dev] Metacello doubt
I have a question since i'm trying to create some jenkins job for the first time. Sorry if this was already discussed...
I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?
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. 2013/6/26 Dale K. Henrichs <dale.henrichs@gemtalksystems.com>
Guido,
If the maintainer of a configuration would like to support bleeding edge loads that propagate through the dependent projects then they should specify which baseline version to use for each dependent project. For Native Boost the entry for AsmJit in the #baseline13: method could be changed to:
project: 'AsmJit' with: [ spec className: 'ConfigurationOfAsmJit'; "==>" versionString: #bleedingEdge; repository: ' http://www.smalltalkhub.com/mc/Pharo/AsmJit/main' ];
Then the bleedingEdge load would be propagated through to the dependents ... but then you'd want the AsmJit configuration modified as well:)
Dale
------------------------------
*From: *"Guido Chari" <charig@gmail.com> *To: *pharo-dev@lists.pharo.org *Sent: *Wednesday, June 26, 2013 7:27:19 AM *Subject: *[Pharo-dev] Metacello doubt
I have a question since i'm trying to create some jenkins job for the first time. Sorry if this was already discussed...
I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?
----- Original Message ----- | From: "Guido Chari" <charig@gmail.com> | To: "Pharo Development List" <pharo-dev@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/MetacelloUser... [2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser...
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@gemtalksystems.com> wrote:
________________________________
From: "Guido Chari" <charig@gmail.com>
To: "Pharo Development List" <pharo-dev@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/MetacelloUser... [2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser...
-- Best regards, Igor Stasenko.
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Thursday, June 27, 2013 4:26:14 AM | Subject: Re: [Pharo-dev] Metacello doubt | | 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. | But once the human has solved the problem, the solution should be encoded in a script that can be used by others to solve the same problem ... It's the manual bits that I'm trying to address with the Scripting API ... if you know you want to deviate from the standard load directives, you should be able to construct a load expression that allows you to specify your deviations so you can do your next build without requiring manual intervention... Dale
On 27 June 2013 15:43, Dale K. Henrichs <dale.henrichs@gemtalksystems.com> wrote:
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Thursday, June 27, 2013 4:26:14 AM | Subject: Re: [Pharo-dev] Metacello doubt | | 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. |
But once the human has solved the problem, the solution should be encoded in a script that can be used by others to solve the same problem ...
It's the manual bits that I'm trying to address with the Scripting API ... if you know you want to deviate from the standard load directives, you should be able to construct a load expression that allows you to specify your deviations so you can do your next build without requiring manual intervention...
Well, the "bleeding edge" called this way exactly for reasons that it is unsafe/unpredictable and hardly formalizeable. I don't see what can be done there: trying to predict a developer's next move is not something you can do with software :) As i said, if there at least two persons working on project , each in his own branch, a term "bleeding edge" will mean something different for each of them. Only when one person takes an effort to merge and update config, you'll have new development version, but before that, if they will commit often without merging, the bleeding edge will jump between one branch and another, and i do not see how that can be useful to anyone.
Dale
-- Best regards, Igor Stasenko.
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Thursday, June 27, 2013 11:19:03 AM | Subject: Re: [Pharo-dev] Metacello doubt | | On 27 June 2013 15:43, Dale K. Henrichs | <dale.henrichs@gemtalksystems.com> wrote: | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | > | Sent: Thursday, June 27, 2013 4:26:14 AM | > | Subject: Re: [Pharo-dev] Metacello doubt | > | | > | 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. | > | | > | > But once the human has solved the problem, the solution should be | > encoded in a script that can be used by others to solve the same | > problem ... | > | > It's the manual bits that I'm trying to address with the Scripting | > API ... if you know you want to deviate from the standard load | > directives, you should be able to construct a load expression that | > allows you to specify your deviations so you can do your next | > build without requiring manual intervention... | > | | Well, the "bleeding edge" called this way exactly for reasons that it | is unsafe/unpredictable | and hardly formalizeable. You are putting too much emphasis of the "what" at the expense of "why"... In Metacello #bleedingEdge is a version like any other version. The statement "if you know you want to deviate from the standard load directives" applies to whether you want to "deviate" by loading the #bleedingEdge version of a project or to "deviate" by loading the #stable version of a project, the mechanism in the Scripting API is exactly the same. | I don't see what can be done there: trying to predict a developer's | next move is not something you can do | with software :) The point is not to predict the developers needs ... the point is to allow the developer to express how he wants to deviate, without forcing him into manual operations... and this is something you can do in software:) | As i said, if there at least two persons working on project , each in | his own branch, a term "bleeding edge" will mean | something different for each of them. Only when one person takes an | effort to merge and update config, you'll have new development | version, but before that, if they will commit often without merging, | the bleeding edge will jump between one branch and another, and i do | not see how that can be useful to anyone. Your comments are specific to the #bleedingEdge version ... as I said earlier, the mechanism that I have described does not apply to only the #bleedingEdge case, but to all versions ... When I said that I would "add test cases for the #bleedingEdge use case," I was actually thinking that I wasn't sure that symbolic versions would work as _I_ expected, since I don't recall adding any tests involving _symbolic versions ... I generally don't want to add features to Metacello that are specifically tied to support a narrow range of use cases, unless I can generalize the feature to cover a wide range. I also don't want to forbid certain use cases just because I don't think they are useful. The Scripting API was invented to give developers explicit control over what gets loaded by Metacello, because the vanilla load of a project and it's dependents is not always what a developers needs ... Dale
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@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@gemtalksystems.com> wrote:
________________________________
From: "Guido Chari" <charig@gmail.com>
To: "Pharo Development List" <pharo-dev@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/MetacelloUser...
[2]
https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser...
-- Best regards, Igor Stasenko.
I'm in. 2013/6/26 Dale K. Henrichs <dale.henrichs@gemtalksystems.com>
------------------------------
*From: *"Guido Chari" <charig@gmail.com> *To: *"Pharo Development List" <pharo-dev@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/MetacelloUser... [2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser...
Allright ... I'll add a test case covering #bleedingEdge loads (perhaps not today...) and let you know if it's already functional or not ... if not I'll plan on getting it supported ... Dale ----- Original Message ----- | From: "Guido Chari" <charig@gmail.com> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Thursday, June 27, 2013 10:23:33 AM | Subject: Re: [Pharo-dev] Metacello doubt | I'm in. | 2013/6/26 Dale K. Henrichs < dale.henrichs@gemtalksystems.com > | | | From: "Guido Chari" < charig@gmail.com > | | | | | | To: "Pharo Development List" < pharo-dev@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/MetacelloUser... | | | [2] | | https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser... |
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 ----- Original Message ----- | From: "Guido Chari" <charig@gmail.com> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Thursday, June 27, 2013 10:23:33 AM | Subject: Re: [Pharo-dev] Metacello doubt | I'm in. | 2013/6/26 Dale K. Henrichs < dale.henrichs@gemtalksystems.com > | | | From: "Guido Chari" < charig@gmail.com > | | | | | | To: "Pharo Development List" < pharo-dev@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/MetacelloUser... | | | [2] | | https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser... |
Ok, i will follow the issue on github. Thanks! 2013/7/1 Dale K. Henrichs <dale.henrichs@gemtalksystems.com>
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" <charig@gmail.com> *To: *"Pharo Development List" <pharo-dev@lists.pharo.org> *Sent: *Thursday, June 27, 2013 10:23:33 AM *Subject: *Re: [Pharo-dev] Metacello doubt
I'm in.
2013/6/26 Dale K. Henrichs <dale.henrichs@gemtalksystems.com>
------------------------------
*From: *"Guido Chari" <charig@gmail.com> *To: *"Pharo Development List" <pharo-dev@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/MetacelloUser... [2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser...
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... ----- Original Message ----- | From: "Guido Chari" <charig@gmail.com> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | 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 < dale.henrichs@gemtalksystems.com > | | 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" < charig@gmail.com > | | | | | | To: "Pharo Development List" < pharo-dev@lists.pharo.org > | | | | | | Sent: Thursday, June 27, 2013 10:23:33 AM | | | | | | Subject: Re: [Pharo-dev] Metacello doubt | | | | | | I'm in. | | | | | | 2013/6/26 Dale K. Henrichs < dale.henrichs@gemtalksystems.com > | | | | | | | | From: "Guido Chari" < charig@gmail.com > | | | | | | | | | | | | | | | To: "Pharo Development List" < pharo-dev@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/MetacelloUser... | | | | | | | | | | [2] | | | | https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser... | | | | | |
Thanks, i have some deadlines this week but i will have a look and give you feedback asap. 2013/7/17 Dale K. Henrichs <dale.henrichs@gemtalksystems.com>
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...
------------------------------
*From: *"Guido Chari" <charig@gmail.com> *To: *"Pharo Development List" <pharo-dev@lists.pharo.org> *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 <dale.henrichs@gemtalksystems.com>
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" <charig@gmail.com> *To: *"Pharo Development List" <pharo-dev@lists.pharo.org> *Sent: *Thursday, June 27, 2013 10:23:33 AM *Subject: *Re: [Pharo-dev] Metacello doubt
I'm in.
2013/6/26 Dale K. Henrichs <dale.henrichs@gemtalksystems.com>
------------------------------
*From: *"Guido Chari" <charig@gmail.com> *To: *"Pharo Development List" <pharo-dev@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/MetacelloUser... [2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser...
participants (5)
-
Dale K. Henrichs -
Damien Cassou -
Guido Chari -
Igor Stasenko -
phil＠highoctane.be