Ok. Thanks Dale. Alexandre On 5 May 2010, at 12:15, Dale Henrichs wrote:
Alexandre,
Using Metacello 1.0-beta.26 and PharoCore-1.1-11335-UNSTABLE (latest update), I get the same results:
SHOUT uses the deprecated registerMenu API Refactoring Browser AST-Core-lr.66 is loaded first and the AST-Core- lr.67 is loaded but this probably isn't a problem, although moving the refactoring browser project in the baseline should eliminate the "double load" Nile-Clients-MarianoMartinezPeck.178 still has an issue with #isInMemory not understood, while doing NSAbstractDataStream class>>initialize
So I don't think these are Metacello issues...just more work to port these projects to Pharo 1.1:)
Dale ----- "Alexandre Bergel" <alexandre@bergel.eu> wrote:
| > I'm actually working through this scenario right now. | | Hi Dale! | | Any progress? | | Cheers, | Alexandre | | | > Moving OB BEFORE AutomaticMethodCategorizer will load the proper | > version of OB ... with this load order the older version of OB | > shouldn't be loaded by AutomaticMethodCategorizer (this is the area | | > where I suspected a bug in 1.0-beta.26 that is fixed in 1.0-beta. | > 26.1). | > | > However, I have run into an issue with SHOUT using the deprecated | > API and then I ran into an MNU in another part of the system (doing | | > initialization) so I'm trying to determine if this is a problem for | | > Metacello or not ... when I have characterized the issues, I'll send | | > mail... | > | > Dale | > | > | > ----- "Alexandre Bergel" <alexandre@bergel.eu> wrote: | > | > | > Thanks Dale for the dedicated answer. I understood you | > correclty? If | > | | > | > I change baseline11: and I put | > | > | > | > project: 'AutomaticMethodCategorizer' | > | > with: | > | > [ spec | > | > className: | > | > 'ConfigurationOfAutomaticMethodCategorizer'; | > | > file: | > | > 'ConfigurationOfAutomaticMethodCategorizer'; | > | > repository: | > | 'http://www.squeaksource.com/MetacelloRepository' | > | > ]; | > | > | > | > | > | > AFTER | > | > | > | > project: 'OB Dev' | > | > with: | > | > [ spec | > | > className: | > | > 'ConfigurationOfOmniBrowser'; | > | > loads: #('Dev'); | > | > file: | > 'ConfigurationOfOmniBrowser'; | > | > repository: | > | 'http://www.squeaksource.com/MetacelloRepository' | > | > ]; | > | > | > | > | > | > then it should work ok ? | > | | > | I understand that if you do this, then the version 1.1.3 of | > | Omnibrowser will be loaded, then AutomaticMethodCategorizer will | | > load | > | | > | the old version of OB. | > | | > | I think that ConfigurationOfAutomaticMethodCategorizer needs to | be | > | updated. | > | I work on it now... | > | | > | Cheers, | > | Alexandre | > | | > | > | > | > | > | > | > | > This implies that ConfigurationOfAutomaticMethodCategorizer will | | > not | > | | > | > load correctly into Pharo 1.1, so the solution is to create a | new | > | > version ConfigurationOfAutomaticMethodCategorizer that will | load | > | > into Pharo 1.1 (i.e. referencing version 1.1.3 of | > | > ConfigurationOfOmniBrowser) and then update | ConfigurationOfPharo | > | > accordingly... | > | > | > | > yes...the problem is that you have to do that in all the confs | | > that | > | | > | > points to OB. | > | > | > | > ..... | > | > | > | > | > | > 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] | > | > | > | > Thanks a lot for the explanation dale! | > | > | > | > mariano | > | > | > | > _______________________________________________ | > | > Pharo-project mailing list | > | > Pharo-project@lists.gforge.inria.fr | > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- | > project | > | | > | -- | > | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | > | Alexandre Bergel http://www.bergel.eu | > | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.