sven christophe is restarting to work on versioner and we hope to get a first version out. The idea is that versioner should help people producing and managing configurations Stef

Hi Dale,

Thanks a lot for the quick and helpful reply.

Adding

spec blessing: #release

to all explicit versions did indeed do the trick.

Now I have to update all my configs ;-)

I have still much to learn.

Thx again,

Sven

On 27 Sep 2012, at 18:46, Dale Henrichs <dhenrich@vmware.com> wrote:

...

Sven,

The versions in ConfigurationOfZTimestamp aren't quite defined correctly ... bleedingEdge defaults to loading the latest baseline version. A baseline version is declared by setting the blessing to #baseline:

spec blessing: #baseline.

Your versions in ConfigurationOfZTimestamp are importing from the '1-baseline' but are not changing the blessing, so Metacello doesn't know that 1, 2, and 3 are literal versions and not baselines. So version 3 looks like the "latest baseline version"..

To fix, this remember to set the blessing in your literal version specifications setting the blessing to something other that #baseline like #development:

spec blessing: #development.

while the version is under development or #release:

spec blessing: #release.

when the version is released (i.e., you will not be changing it any more).

Dale

----- Original Message ----- | From: "Sven Van Caekenberghe" <sven@stfx.eu> | To: "Pharo-project@lists.gforge.inria.fr Development" <Pharo-project@lists.gforge.inria.fr> | Sent: Thursday, September 27, 2012 8:31:47 AM | Subject: [Pharo-project] Metacello bleedingEdge question | | Hi, | | I have a question. | | The following works as expected and loads the latest versions of the | code: | | ConfigurationOfZincHTTPComponents project bleedingEdge load. | | The following does not and keeps loading only the #stable one and not | the latest one. | | ConfigurationOfZTimestamp project bleedingEdge load. | | I can't see any difference, but I am a Metacello newbie. | | Has anyone any idea where I should look ? | | Thx, | | Sven | | -- | Sven Van Caekenberghe | http://stfx.eu | Smalltalk is the Red Pill

----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, September 28, 2012 12:59:46 AM | Subject: Re: [Pharo-project] Metacello bleedingEdge question | | | | | On Thu, Sep 27, 2012 at 6:46 PM, Dale Henrichs < dhenrich@vmware.com | > wrote: | | | Sven, | | The versions in ConfigurationOfZTimestamp aren't quite defined | correctly ... bleedingEdge defaults to loading the latest baseline | version. A baseline version is declared by setting the blessing to | #baseline: | | spec blessing: #baseline. | | Your versions in ConfigurationOfZTimestamp are importing from the | '1-baseline' but are not changing the blessing, so Metacello doesn't | know that 1, 2, and 3 are literal versions and not baselines. So | version 3 looks like the "latest baseline version".. | | | | Dale, but baselines are supposed to mandatory have the "spec | blessing: #baseline.", right? so why would metacello think that | versions 1, 2, and 3 are baselines instead of versions? Mariano, Short answer is that literal versions are defined by importing from the baseline, so the literal version inherits the blessing from the baseline. Therefore you have to specify a blessing of #development or #release in the literal version to distinguish it from the baseline. Long answer is... For loading purposes, it actually doesn't matter what the blessing is ... In Metacello, if a package spec has a `file` specified, then the `file` is loaded. if the `file` is not specified then the latest version of the mcz file is loaded ... By convention, when we define baseline versions we don't specify the `file` for the packages. By convention when we define literal versions we do specify the `file` for the packages. The expression: spec package: 'Example-Core' with: 'Example-Core-dkh.25' defines the `file` for the 'Example-Core' package spec to be 'Example-Core-dkh.25'. The blessing is used as an hint by Metacello when using the helper functions like #bleedingEdge or #latestVersion that implement functionality based on the conventions. #bleedingEdge is defined as the latest version with a #baseline blessing. #latestVersion is defined as the latest version whose blessing is neither #baseline nor #development. Versions with a #broken blessing are excluded from consideration... Dale

Stef, #latestVersion is there for backward compatibility. The #stable symbolic version is the preferred mechanism for declaring the "latest version". Dale ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, September 28, 2012 11:37:30 AM | Subject: Re: [Pharo-project] Metacello bleedingEdge question | | dale | | at the end do we really need latestVersion because I'm still confused | by it. | | On Sep 28, 2012, at 3:42 PM, Dale Henrichs wrote: | | > #latestVersion is defined as the latest version whose blessing is | > neither #baseline nor #development. | | |

On 29 Sep 2012, at 21:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

On Sep 29, 2012, at 5:39 PM, Dale Henrichs wrote:

...

Stef,

#latestVersion is there for backward compatibility.

Ok I would simply remove it.

Stef

I was about to say: what's that 'backward compatibility' ? ;-) No seriously, unless there is a very good, important reason to keep it, confusing stuff should be removed going forward. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

OK so we should not talk about it anymore and ban it from all the configurations. It would be good to have specific rules for configurations. BTW: what do we do with the chapter I'm working on the new book and now I'm puzzled because I have invested a large amount of time and I get a chapter that you never gave feedback on and that is probably not correct or up to date. So may be the only thing I can do is to drop it. And after people will tell that pharo does not have documentation but I often fell alone. Stef

#latestVersion actually has a very good reason for existing, just not for use by end users in loading code ...

It _has_ been dropped from the _convention_, and it shouldn't be dropped from the code base...

Dale

----- Original Message ----- | From: "Sven Van Caekenberghe" <sven@stfx.eu> | To: Pharo-project@lists.gforge.inria.fr | Sent: Saturday, September 29, 2012 1:02:17 PM | Subject: Re: [Pharo-project] Metacello bleedingEdge question | | | On 29 Sep 2012, at 21:38, Stéphane Ducasse | <stephane.ducasse@inria.fr> wrote: | | > On Sep 29, 2012, at 5:39 PM, Dale Henrichs wrote: | > | >> Stef, | >> | >> #latestVersion is there for backward compatibility. | > | > Ok | > I would simply remove it. | > | > Stef | | I was about to say: what's that 'backward compatibility' ? | | ;-) | | No seriously, unless there is a very good, important reason to keep | it, confusing stuff should be removed going forward. | | Sven | | -- | Sven Van Caekenberghe | http://stfx.eu | Smalltalk is the Red Pill | | | | |

----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Sunday, September 30, 2012 11:25:28 PM | Subject: Re: [Pharo-project] Metacello bleedingEdge question | | OK | so we should not talk about it anymore and ban it from all the | configurations. | It would be good to have specific rules for configurations. The Metacello Scripting api is intended to accomplish this particular goal ... the scripting api does not send class-side messages to configurations ... with the scripting api, the configuration reverts back to its original role of specification and #latestVersion isn't part of the specification. | | BTW: what do we do with the chapter I'm working on the new book and | now I'm puzzled | because I have invested a large amount of time and I get a chapter | that you never gave feedback on and | that is probably not correct or up to date. So may be the only thing | I can do is to drop it. | And after people will tell that pharo does not have documentation but | I often fell alone. I think you have produced an excellent piece of documentation ... While my english language skills may be better than yours, your writing skills are far superior to mine ... I am a very poor writer ... I keep approaching the chapter as a writer and I want to completely rewrite things ... perhaps I should just act as a fact checker and copy editor? Pointing out factual errors and correcting the english to the best of my ability? Dale

----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Monday, October 1, 2012 12:26:25 PM | Subject: Re: [Pharo-project] Metacello bleedingEdge question | | > | It would be good to have specific rules for configurations. | > | > The Metacello Scripting api is intended to accomplish this | > particular goal … | | I was thinking in terms of Slime for Seaside. | One PhD student is working on rule and I was thinking that it would | be fun to have a kind of | Metacello checker. | do you have some rule of thumb where to look for potential problems? | Because it can be a fun experience. There is a validator for Metacello called MetacelloMCVersionValidator ... this guy checks for the wellness/correctness of the configuration. You can get a view of the types of things checked for by inspecting the result of `MetacelloMCVersionValidator populateReasonCodeDescriptions`. Let's see with slime we can probably ensure that the configuration specification methods only send messages to the `spec` variable and that the messages being sent or in the `api` category of the MetacelloAbstractVersionConstructor class, this would be real useful... | | > the scripting api does not send class-side messages to | > configurations ... with the scripting api, the configuration | > reverts back to its original role of specification and | > #latestVersion isn't part of the specification. | | Excellent | | > I think you have produced an excellent piece of documentation … | | Thanks but I want more. I ant you to tell me if I do not write | something wrong because people will read it. | | > While my english language skills may be better than yours, your | > writing skills are far superior to mine | | I do not know. I just write so that I can forget :) I need to release | the pressure in my mind. | | > ... I am a very poor writer ... I keep approaching the chapter as a | > writer and I want to completely rewrite things ... perhaps I | > should just act as a fact checker and copy editor? | | Sure | Do whatever you want and fit your energy, I just need feedback and I | want to close it. | I refrain myself to change and rewrite the chapter. I would like it | to be more straight to the point but I do not have the energy | anymore. | | > Pointing out factual errors and correcting the english to the best | > of my ability? | | perfect to me. | | I need feedback So if you can spot where I wrote something wrong this | is what I need. | If you spot englihs mistakes (I certainly do a lot of them) - please | let me know I will address them. | | I have no problem to write. I have problem to write wrong | information. Okay Stef ... I can approach this as an editor rather than a writer and give you my feedback that way ... at this point I have no more excuses ... I plan to devote several hours every week to this so that you can start seeing my feedback this week. Thanks for your perserverance and patience, Dale

Not sure whether or not these are doable with Slime, but they are good ideas Dale ----- Original Message ----- | From: "Alexandre Bergel" <alexandre.bergel@me.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Monday, October 1, 2012 1:30:44 PM | Subject: Re: [Pharo-project] Metacello bleedingEdge question | | > I was thinking in terms of Slime for Seaside. | > One PhD student is working on rule and I was thinking that it would | > be fun to have a kind of | > Metacello checker. | > do you have some rule of thumb where to look for potential | > problems? | > Because it can be a fun experience. | | I had this idea of a checker for Metacello (that can be used with | Versionner before committing), but never got the traction to do it. | Some rules: | - two packages in a graph of dependencies may rely on a different | version of a third package | - identifying cycles in packages | - very important: checking whether the dependencies defined in | Metacello matches with the actual source code. Said in other | words, do I miss some dependencies in a configuration? | | Cheers, | Alexandre | | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | | | | |

Will do ... do't forget `MetacelloMCVersionValidator populateReasonCodeDescriptions` ... Dale ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, October 2, 2012 11:56:26 AM | Subject: Re: [Pharo-project] Metacello bleedingEdge question | | I discussed with andre and we would like to collect some rules. | In fact we would like also to extract the rules from the history of | configuration :) | | - Baseline should have a blessing base line | - Version should have a development | I imagine a lot more of them/ | If you had ideas just send them. | | Stef | | | On Oct 1, 2012, at 11:54 PM, Dale Henrichs wrote: | | > Not sure whether or not these are doable with Slime, but they are | > good ideas | > | > Dale | > | > ----- Original Message ----- | > | From: "Alexandre Bergel" <alexandre.bergel@me.com> | > | To: Pharo-project@lists.gforge.inria.fr | > | Sent: Monday, October 1, 2012 1:30:44 PM | > | Subject: Re: [Pharo-project] Metacello bleedingEdge question | > | | > | > I was thinking in terms of Slime for Seaside. | > | > One PhD student is working on rule and I was thinking that it | > | > would | > | > be fun to have a kind of | > | > Metacello checker. | > | > do you have some rule of thumb where to look for potential | > | > problems? | > | > Because it can be a fun experience. | > | | > | I had this idea of a checker for Metacello (that can be used with | > | Versionner before committing), but never got the traction to do | > | it. | > | Some rules: | > | - two packages in a graph of dependencies may rely on a | > | different | > | version of a third package | > | - identifying cycles in packages | > | - very important: checking whether the dependencies defined in | > | Metacello matches with the actual source code. Said in other | > | words, do I miss some dependencies in a configuration? | > | | > | Cheers, | > | Alexandre | > | | > | -- | > | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | > | Alexandre Bergel http://www.bergel.eu | > | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | > | | > | | > | | > | | > | | > | | |