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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.