Hi, If I specify a stable version for a platform (spec for: #'pharo3.x' version: '3.0.6'.), shouldn't Metacello load that version? Concrete use-case: loading ConfigurationOfMoose in Pharo 3 - ConfigurationOfMoose specifies version 5.0 as stable for Pharo 3 - ConfigurationOfMoose version 5.0 loads ConfigurationOfGlamour #stable - ConfigurationOfGlamour specifies version 3.0.6 as stable for Pharo 3 (spec for: #'pharo3.x' version: '3.0.6') Loading ConfigurationOfMoose [1] in Pharo 3 loads version 3.0.9 for ConfigurationOfGlamour. Updating Monticello leads to the same result. Did I misunderstood something about how monticello works? Any idea how to debug this? Cheers, Andrei [1] (ConfigurationOfMoose project version: #'stable') record loadDirective
Andrei, 1) The old configuration load api is non-deterministic, especially when used with large configurations, Metacello will not downgrade a package, so if (using the old api) Metacello decides that a newer version of a configuration is present, then it will use the newer (and possibly incorrect version). Keep in mind that pre-loaded packages in Pharo can influence this non-deterministic calculation. I don't know for certain that using the old API is the culprit. The only way for me to understand where the issue might lie is for me to look at the Transcript output of a load. 2) I'm not sure that Moose is loadable in Pharo3.0 ... If things are not actively tested then they are likely to quit working over time and I'd guess this is the case for Pharo3.0 and Moose. 3) using #stable is a very inaccurate way of specifying a symbolic version. The Seaside folks have started using version-based symbolic versions like: #'release3', #'release3.1', #'release3.2' a while ago and I think this is a very good way to leverage symbolic versions ... #stable can be changed and in the mind of the developer #stable is now version 4.0.0, while a number of older configurations will consider #stable to be version 3.0.0 ... it doesn't take long the #stable version universe to be completely confused ... While I suspect that the current #stable version of Moose does not run on Pharo3.0, if version-based symbolic versions had been used back then the configurations would likely still be usable ... Again, I am just guessing ... analysis of the Transcript output would give me better clues ... Using the new Metacello scripting API: Metacello new configuration: 'Moose'; version: #stable; repository: '???'; load does a load without without calculating the #currentVersion and should be deterministic with respect to loaded versions ... this only addresses the first point above. If points 2 or 3 are involved, then it may be more difficult to solve the problem ... BTW, sorry for taking so long to get back to you ... in the last month I've taken a long overdue vacation (and did not even open my laptop:) and have been working exclusively on GemStone 3.3 ... I'm nearly finished with my main commitments for GemStone 3.3 and as I come up for air, I'm working off my email backlog:) Dale On 5/18/15 5:56 AM, Andrei Chis wrote:
Hi,
If I specify a stable version for a platform (spec for: #'pharo3.x' version: '3.0.6'.), shouldn't Metacello load that version?
Concrete use-case: loading ConfigurationOfMoose in Pharo 3 - ConfigurationOfMoose specifies version 5.0 as stable for Pharo 3 - ConfigurationOfMoose version 5.0 loads ConfigurationOfGlamour #stable - ConfigurationOfGlamour specifies version 3.0.6 as stable for Pharo 3 (spec for: #'pharo3.x' version: '3.0.6')
Loading ConfigurationOfMoose [1] in Pharo 3 loads version 3.0.9 for ConfigurationOfGlamour. Updating Monticello leads to the same result.
Did I misunderstood something about how monticello works? Any idea how to debug this?
Cheers, Andrei
[1] (ConfigurationOfMoose project version: #'stable') record loadDirective
On Fri, May 29, 2015 at 6:14 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Andrei,
1) The old configuration load api is non-deterministic, especially when used with large configurations, Metacello will not downgrade a package, so if (using the old api) Metacello decides that a newer version of a configuration is present, then it will use the newer (and possibly incorrect version). Keep in mind that pre-loaded packages in Pharo can influence this non-deterministic calculation.
I don't know for certain that using the old API is the culprit. The only way for me to understand where the issue might lie is for me to look at the Transcript output of a load.
2) I'm not sure that Moose is loadable in Pharo3.0 ... If things are not actively tested then they are likely to quit working over time and I'd guess this is the case for Pharo3.0 and Moose.
3) using #stable is a very inaccurate way of specifying a symbolic version. The Seaside folks have started using version-based symbolic versions like: #'release3', #'release3.1', #'release3.2' a while ago and I think this is a very good way to leverage symbolic versions ... #stable can be changed and in the mind of the developer #stable is now version 4.0.0, while a number of older configurations will consider #stable to be version 3.0.0 ... it doesn't take long the #stable version universe to be completely confused ...
For a Configuration newbie it may seem intuitive for a Configuration to dependend on other Configuration's #stable without realising the hole they are digging. You could say its easy to shoot yourself in the foot with #stable? So maybe #stable only makes sense as a *convenience* for interactive users at the "command line." It might be reasonable for the system to block use of #stable within a Configuration (with a deprecation warning and bypass method like #allowNestedStable) cheers -ben
While I suspect that the current #stable version of Moose does not run on Pharo3.0, if version-based symbolic versions had been used back then the configurations would likely still be usable ...
Again, I am just guessing ... analysis of the Transcript output would give me better clues ...
Using the new Metacello scripting API:
Metacello new configuration: 'Moose'; version: #stable; repository: '???'; load
does a load without without calculating the #currentVersion and should be deterministic with respect to loaded versions ... this only addresses the first point above. If points 2 or 3 are involved, then it may be more difficult to solve the problem ...
BTW, sorry for taking so long to get back to you ... in the last month I've taken a long overdue vacation (and did not even open my laptop:) and have been working exclusively on GemStone 3.3 ... I'm nearly finished with my main commitments for GemStone 3.3 and as I come up for air, I'm working off my email backlog:)
Dale
On 5/18/15 5:56 AM, Andrei Chis wrote:
Hi,
If I specify a stable version for a platform (spec for: #'pharo3.x' version: '3.0.6'.), shouldn't Metacello load that version?
Concrete use-case: loading ConfigurationOfMoose in Pharo 3 - ConfigurationOfMoose specifies version 5.0 as stable for Pharo 3 - ConfigurationOfMoose version 5.0 loads ConfigurationOfGlamour #stable - ConfigurationOfGlamour specifies version 3.0.6 as stable for Pharo 3 (spec for: #'pharo3.x' version: '3.0.6')
Loading ConfigurationOfMoose [1] in Pharo 3 loads version 3.0.9 for ConfigurationOfGlamour. Updating Monticello leads to the same result.
Did I misunderstood something about how monticello works? Any idea how to debug this?
Cheers, Andrei
[1] (ConfigurationOfMoose project version: #'stable') record loadDirective
Ben, Hmmm, I could make the use of #stable a Critical Warning: "MetacelloValidationCriticalWarning indicates that there is a logical inconsistency that may not be intentional and that could cause incorrect loads". I've submitted a Metacello issue #350[1] for this. If I thought that folks regularly used configuration validation, I wouldn't have to do much else:) Of course there are ancient configurations where #stable still must be used. There are validation pragmas that allow one to filter out "know exceptions" for the validator so that only new configs would generate the "critical warning" ... I'm reluctant to go much further than this ... of course tools could be more aggressive in stamping out the use of #stable... Dale [1] https://github.com/dalehenrich/metacello-work/issues/350 On 5/28/15 4:57 PM, Ben Coman wrote:
On Fri, May 29, 2015 at 6:14 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Andrei,
1) The old configuration load api is non-deterministic, especially when used with large configurations, Metacello will not downgrade a package, so if (using the old api) Metacello decides that a newer version of a configuration is present, then it will use the newer (and possibly incorrect version). Keep in mind that pre-loaded packages in Pharo can influence this non-deterministic calculation.
I don't know for certain that using the old API is the culprit. The only way for me to understand where the issue might lie is for me to look at the Transcript output of a load.
2) I'm not sure that Moose is loadable in Pharo3.0 ... If things are not actively tested then they are likely to quit working over time and I'd guess this is the case for Pharo3.0 and Moose.
3) using #stable is a very inaccurate way of specifying a symbolic version. The Seaside folks have started using version-based symbolic versions like: #'release3', #'release3.1', #'release3.2' a while ago and I think this is a very good way to leverage symbolic versions ... #stable can be changed and in the mind of the developer #stable is now version 4.0.0, while a number of older configurations will consider #stable to be version 3.0.0 ... it doesn't take long the #stable version universe to be completely confused ... For a Configuration newbie it may seem intuitive for a Configuration to dependend on other Configuration's #stable without realising the hole they are digging. You could say its easy to shoot yourself in the foot with #stable? So maybe #stable only makes sense as a *convenience* for interactive users at the "command line." It might be reasonable for the system to block use of #stable within a Configuration (with a deprecation warning and bypass method like #allowNestedStable) cheers -ben
While I suspect that the current #stable version of Moose does not run on Pharo3.0, if version-based symbolic versions had been used back then the configurations would likely still be usable ...
Again, I am just guessing ... analysis of the Transcript output would give me better clues ...
Using the new Metacello scripting API:
Metacello new configuration: 'Moose'; version: #stable; repository: '???'; load
does a load without without calculating the #currentVersion and should be deterministic with respect to loaded versions ... this only addresses the first point above. If points 2 or 3 are involved, then it may be more difficult to solve the problem ...
BTW, sorry for taking so long to get back to you ... in the last month I've taken a long overdue vacation (and did not even open my laptop:) and have been working exclusively on GemStone 3.3 ... I'm nearly finished with my main commitments for GemStone 3.3 and as I come up for air, I'm working off my email backlog:)
Dale
On 5/18/15 5:56 AM, Andrei Chis wrote:
Hi,
If I specify a stable version for a platform (spec for: #'pharo3.x' version: '3.0.6'.), shouldn't Metacello load that version?
Concrete use-case: loading ConfigurationOfMoose in Pharo 3 - ConfigurationOfMoose specifies version 5.0 as stable for Pharo 3 - ConfigurationOfMoose version 5.0 loads ConfigurationOfGlamour #stable - ConfigurationOfGlamour specifies version 3.0.6 as stable for Pharo 3 (spec for: #'pharo3.x' version: '3.0.6')
Loading ConfigurationOfMoose [1] in Pharo 3 loads version 3.0.9 for ConfigurationOfGlamour. Updating Monticello leads to the same result.
Did I misunderstood something about how monticello works? Any idea how to debug this?
Cheers, Andrei
[1] (ConfigurationOfMoose project version: #'stable') record loadDirective
Hi Dale, Thanks for your answer. Did not know stable is not a good choice for more complex configurations. Moose still has a stable version that loads ok in Pharo 3. There is also a jenkins build: https://ci.inria.fr/moose/job/moose-5.0/ ConfigurationOfMoose is in the main moose repo ( http://www.smalltalkhub.com/#!/~Moose/Moose) For now I fixed the issues we had by deleting a few versions from ConfigurationOfGlamour (ConfigurationOfGlamour-AndreiChis.211) Cheers, Andrei On Fri, May 29, 2015 at 12:14 AM, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Andrei,
1) The old configuration load api is non-deterministic, especially when used with large configurations, Metacello will not downgrade a package, so if (using the old api) Metacello decides that a newer version of a configuration is present, then it will use the newer (and possibly incorrect version). Keep in mind that pre-loaded packages in Pharo can influence this non-deterministic calculation.
I don't know for certain that using the old API is the culprit. The only way for me to understand where the issue might lie is for me to look at the Transcript output of a load.
2) I'm not sure that Moose is loadable in Pharo3.0 ... If things are not actively tested then they are likely to quit working over time and I'd guess this is the case for Pharo3.0 and Moose.
3) using #stable is a very inaccurate way of specifying a symbolic version. The Seaside folks have started using version-based symbolic versions like: #'release3', #'release3.1', #'release3.2' a while ago and I think this is a very good way to leverage symbolic versions ... #stable can be changed and in the mind of the developer #stable is now version 4.0.0, while a number of older configurations will consider #stable to be version 3.0.0 ... it doesn't take long the #stable version universe to be completely confused ...
While I suspect that the current #stable version of Moose does not run on Pharo3.0, if version-based symbolic versions had been used back then the configurations would likely still be usable ...
Again, I am just guessing ... analysis of the Transcript output would give me better clues ...
Using the new Metacello scripting API:
Metacello new configuration: 'Moose'; version: #stable; repository: '???'; load
does a load without without calculating the #currentVersion and should be deterministic with respect to loaded versions ... this only addresses the first point above. If points 2 or 3 are involved, then it may be more difficult to solve the problem ...
BTW, sorry for taking so long to get back to you ... in the last month I've taken a long overdue vacation (and did not even open my laptop:) and have been working exclusively on GemStone 3.3 ... I'm nearly finished with my main commitments for GemStone 3.3 and as I come up for air, I'm working off my email backlog:)
Dale
On 5/18/15 5:56 AM, Andrei Chis wrote:
Hi,
If I specify a stable version for a platform (spec for: #'pharo3.x' version: '3.0.6'.), shouldn't Metacello load that version?
Concrete use-case: loading ConfigurationOfMoose in Pharo 3 - ConfigurationOfMoose specifies version 5.0 as stable for Pharo 3 - ConfigurationOfMoose version 5.0 loads ConfigurationOfGlamour #stable - ConfigurationOfGlamour specifies version 3.0.6 as stable for Pharo 3 (spec for: #'pharo3.x' version: '3.0.6')
Loading ConfigurationOfMoose [1] in Pharo 3 loads version 3.0.9 for ConfigurationOfGlamour. Updating Monticello leads to the same result.
Did I misunderstood something about how monticello works? Any idea how to debug this?
Cheers, Andrei
[1] (ConfigurationOfMoose project version: #'stable') record loadDirective
On 01/06/15 10:56, Andrei Chis wrote:
Moose still has a stable version that loads ok in Pharo 3. There is also a jenkins build: https://ci.inria.fr/moose/job/moose-5.0/ ConfigurationOfMoose is in the main moose repo (http://www.smalltalkhub.com/#!/~Moose/Moose)
Yes, we've done some work to ensure that the stable works. That is because none of the dependencies have already declared a new version stable that only works in Pharo4. At that moment, we need to introduce platform to get the right stable version in Pharo3. As we'll have multiple releases of Moose on Pharo 5, it makes sense to start getting more precise there. Stephan
participants (4)
-
Andrei Chis -
Ben Coman -
Dale Henrichs -
Stephan Eggermont