May 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Alexandre Bergel

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

May 5, 2010

[Pharo-project] [update 1.1] #11336

by StÃ©phane Ducasse

11336 ----- - Issue 2386: milliSeconds: milliCount bad comment -> removed - Issue 2385: Compression missing primitivecall - Issue 2384: DurationTests - Issue 2378: ConfigurationOfPharoCore first try

May 5, 2010