On Tue, May 4, 2010 at 9:23 PM, Dale Henrichs <[email protected]>wrote:
> > ----- "Mariano Martinez Peck" <[email protected]> wrote: > > > | > The nesting level for '1.1.3 [ConfigurationOfOmniBrowser]' and '1.1 > | > [ConfigurationOfAutomaticMethodCategorizer]' are the same which > | means that > | > they are both referenced in '1.1 [ConfigurationOfPharo]'. That was > | enough to > | > solve this particular problem, but in an Inspector, you can dive > | into the > | > directives themselves and actually get to the MetacelloSpec that was > | used to > | > create the directive... > | > > | > > | > > | Here is what I don't understand. If you have that directive, and you > | have > | ALL that information, can't you guess that if you need to load the N > | version > | of a package and then the version M, where M > N, then you can skip to > | load > | N and just load M directly ? > | > | In this example, can you DO NOT load OmniBrowser-lr.458 as you know > | that > | after you will load OmniBrowser-lr.469 ? > | Or maybe directly about conf: Do not load 1.1 > | [ConfigurationOfOmniBrowser] if you know that then you will need to > | load > | 1.1.3 [ConfigurationOfOmniBrowser] > > Mariano, > > If you were using #atomic loads then what you are suggesting would happen > ... Metacello would recognize that OmniBrowser-lr.469 was later and would > use that instead of the older mcz file. > > With #linear loads it isn't necessarily safe to substitute a newer version > of an mcz file earlier into the load sequence, because the newer version may > have dependencies that wouldn't necessarily be satisfied this early in the > load sequence...The only safe way is to explicitly move the project earlier > in the sequence. > > Ahhhh those ones ;) Now is much clear. Thanks Dale. I forgot sbout those friends. Now I wonder.... if we select #linear is cool because all the packages will be loaded and initialized one after one. But we usually would need to update a lot of configurations to load ONLY the last version in a conflic. On the other hand, if we use #atomic most of the times the newests verions will ONLY be loaded automatically, but we may have a problem as all the postDoIts are done all together at the end. So...which one do you think is the best approach for ConfogurationOfPharo ? I guess linear and update the others confs....what do you think ? cheers mariano > Moving the specification of OmniBrowser before the spec for > AutomaticMethodCategorizer does result in the correct mcz file for > OB-Standard to be loaded, however, other issues are exposed: > > SHOUT uses the deprecated registerMenu API > Refactoring Browser needs to be moved earlier to avoid double > loading. I didn't notice any ill effects of loading earlier version of > Refactoring Browser. > Nile-Clients-MarianoMartinezPeck.178 has an issue with #isInMemory not > understood > > Perhaps the MNU is due to the fact that I haven't updated > PharoCore-1.1-11326-UNSTABLE. > > My tests to this point were done with Metacello 1.0-beta.26.1 (in > development) to eliminate any (known) Metacello bugs from the equation. > > At this point I don't think 1.0-beta.26.1 is needed, but I will run an > additional test and let you know... > > Dale >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
