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 < [email protected]> 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 >> >> > >
