ConfigurationOfPharo and OmniBrowser

> 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" <[hidden email]> 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" <[hidden email]> 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
> | > | > [hidden email]
> | > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
> | > project
> | > |
> | > | --
> | > | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> | > | Alexandre Bergel  http://www.bergel.eu
> | > | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> |
> | --
> | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> | Alexandre Bergel  http://www.bergel.eu
> | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.