ConfigurationOfPharo and OmniBrowser
Locked
12
12
ConfigurationOfPharo and OmniBrowser
 
|
Hi!
I am now trying to make ConfigurationOfPharo load the last version of OmniBrowser. If I do in a fresh core: ConfigurationOfPharo project lastVersion load Then OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. The loading blocks on the deprecated warning (yes, the registration in the World menu). In ConfigurationOfPharo>>version11: I have spec project: 'PharoNonCorePackages' with: '1.1.0'; project: 'NewInspector' with: '1.1'; project: 'Shout' with: '1.0'; project: 'Shout Tests' with: '1.0'; project: 'OCompletion' with: '1.1'; project: 'OCompletion Tests' with: '1.1'; project: 'OB Dev' with: '1.1.3'; project: 'OB Dev Tests' with: '1.1.3'; ... I therefore assume that the version 1.1.3 of OmniBrowser is loaded. 1.1.3 is indeed the last version specified in ConfigurationOfOmniBrowser: ConfigurationOfOmniBrowser project lastVersion => ~1.1.3 [ConfigurationOfOmniBrowser] But I evaluate: ConfigurationOfOmniBrowser project lastVersion load Then the version OB-Morphic-lr.116, OB-Standard-lr.463 and OmniBrowser- lr.469 are loaded. I find it is very hard to keep track of what is actually loaded. I haven't closely followed the evolution of Metacello, but there is not a way to say: spec project: 'OB Dev' with: 'lastestVersion' Or Something? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ConfigurationOfPharo and OmniBrowser
|
|
On Wed, Apr 28, 2010 at 3:22 PM, Alexandre Bergel <[hidden email]> wrote: Hi! No. If you take a PharoCore 1.0 OR 1.1 and evaluate ConfigurationOfPharo project lastVersion load It installs OmniBrowser-lr.469 and OB-Morphic-lr.116 which are correct as those are defined in ConfigurationOfOmniBrowser version 1.1.2. And ConfigurationOfPharo 1.1 has 1.1.2 of OB. The loading blocks on the deprecated warning (yes, the registration in the World menu). Exactly. And that's correct. Those are the versions that are defined in ConfigurationOfOmnibrowser 1.1.3 I find it is very hard to keep track of what is actually loaded. I don't understand your problem. Everything seems to work as exepected. I haven't closely followed the evolution of Metacello, but there is not a way to say: Yes. Don't put any version. If you don't define a version, metacallo will load the last one. project: 'OB Dev'; or even remove that line from the version method. Even more, if you want ALL the last, you can load the baseline instead of the version. In such case, as you don't specify any version, it will download all the last ones. Cheers Mariano Or Something? _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ConfigurationOfPharo and OmniBrowser
|
|
It is a bit more subtle than that.
If I take a Core 1.1, and doit: ConfigurationOfPharo project lastVersion load Then I get a warning coming from OBSearchBrowser class related to the world menu registration. At that moment, OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. Doing twice a proceed resume the loading. It then blocks on SHWorkspace, for the very same reason. After having manually fixed the Nile problem (isInMemory), Pharo loads well. ProfStef is open. OmniBrowser-lr.469 and OB-Morphic-lr.116 are loaded. This means that OmniBrowser is loaded twice. Is this the intended behavior? Alexandre On 28 Apr 2010, at 11:40, Mariano Martinez Peck wrote: > > > On Wed, Apr 28, 2010 at 3:22 PM, Alexandre Bergel > <[hidden email]> wrote: > Hi! > > I am now trying to make ConfigurationOfPharo load the last version > of OmniBrowser. > If I do in a fresh core: ConfigurationOfPharo project lastVersion load > > Then OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. > > > No. If you take a PharoCore 1.0 OR 1.1 and evaluate > ConfigurationOfPharo project lastVersion load > > It installs OmniBrowser-lr.469 and OB-Morphic-lr.116 > which are correct as those are defined in ConfigurationOfOmniBrowser > version 1.1.2. And ConfigurationOfPharo 1.1 has 1.1.2 of OB. > > > The loading blocks on the deprecated warning (yes, the registration > in the World menu). > In ConfigurationOfPharo>>version11: I have > > spec > project: 'PharoNonCorePackages' with: > '1.1.0'; > project: 'NewInspector' with: '1.1'; > project: 'Shout' with: '1.0'; > project: 'Shout Tests' with: '1.0'; > project: 'OCompletion' with: '1.1'; > project: 'OCompletion Tests' with: > '1.1'; > project: 'OB Dev' with: '1.1.3'; > project: 'OB Dev Tests' with: '1.1.3'; > ... > > I therefore assume that the version 1.1.3 of OmniBrowser is loaded. > 1.1.3 is indeed the last version specified in > ConfigurationOfOmniBrowser: > ConfigurationOfOmniBrowser project lastVersion > => ~1.1.3 [ConfigurationOfOmniBrowser] > > But I evaluate: ConfigurationOfOmniBrowser project lastVersion load > Then the version OB-Morphic-lr.116, OB-Standard-lr.463 and > OmniBrowser-lr.469 are loaded. > > > Exactly. And that's correct. Those are the versions that are defined > in ConfigurationOfOmnibrowser 1.1.3 > > I find it is very hard to keep track of what is actually loaded. > > > I don't understand your problem. Everything seems to work as > exepected. > > > I haven't closely followed the evolution of Metacello, but there is > not a way to say: > spec project: 'OB Dev' with: 'lastestVersion' > > Yes. Don't put any version. If you don't define a version, metacallo > will load the last one. > > project: 'OB Dev'; > > or even remove that line from the version method. Even more, if you > want ALL the last, you can load the baseline instead of the version. > In such case, as you don't specify any version, it will download all > the last ones. > > Cheers > > Mariano > > > Or Something? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ConfigurationOfPharo and OmniBrowser
|
|
On Wed, Apr 28, 2010 at 11:28 PM, Alexandre Bergel <[hidden email]> wrote: It is a bit more subtle than that. Yes, I noticed that. At that moment, OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. yes.. After having manually fixed the Nile problem (isInMemory), Pharo loads well. ProfStef is open. I did the same... OmniBrowser-lr.469 and OB-Morphic-lr.116 are loaded. This means that OmniBrowser is loaded twice. Is this the intended behavior? I saw directly the final versions: 469 and 116. I didn't notice it was first trying to load 458 and 112. I know that in such conflict, Metacello will load the last one, but I didnt know that it actually LOADS also the previous versions. I thought that it only loads the final version, not both of them. In such case, I think it is a metacello bug. See this link: http://groups.google.com/group/metacello/browse_thread/thread/e8a08b3ed1a9b772/edd79873a97a80d9?lnk=gst&q=conflict#edd79873a97a80d9 Dale, can you help us? Thanks Mariano Alexandre _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Mariano and Alexandre,
Sorry for the late reply ... I've been off-line with a cold for the last several days ... I have seen the behavior that you describe while working with GLASS 1.0-beta.8 and have fixed the problem in Metacello 1.0-beta.26.1 ... 1.0-beta.26.1 is still in development, but if you want to give it a try, preload 1.0-beta.26.1 and rerun your test ... if the problem still persists, let me know and I will dive into it. Dale ----- "Mariano Martinez Peck" <[hidden email]> wrote: | On Wed, Apr 28, 2010 at 11:28 PM, Alexandre Bergel < | [hidden email]> wrote: | | > It is a bit more subtle than that. | > | > If I take a Core 1.1, and doit: ConfigurationOfPharo project | lastVersion | > load | > Then I get a warning coming from OBSearchBrowser class related to | the world | > menu registration. | > | > | Yes, I noticed that. | | | > At that moment, OmniBrowser-lr.458 and OB-Morphic-lr.112 are | loaded. | > | > Doing twice a proceed resume the loading. | > It then blocks on SHWorkspace, for the very same reason. | > | > | yes.. | | | > After having manually fixed the Nile problem (isInMemory), Pharo | loads | > well. ProfStef is open. | > | > | I did the same... | | | > OmniBrowser-lr.469 and OB-Morphic-lr.116 are loaded. This means | that | > OmniBrowser is loaded twice. Is this the intended behavior? | > | > | I saw directly the final versions: 469 and 116. I didn't notice it was | first | trying to load 458 and 112. | I know that in such conflict, Metacello will load the last one, but I | didnt | know that it actually LOADS also the previous versions. I thought that | it | only loads the final version, not both of them. In such case, I think | it is | a metacello bug. | | See this link: | http://groups.google.com/group/metacello/browse_thread/thread/e8a08b3ed1a9b772/edd79873a97a80d9?lnk=gst&q=conflict#edd79873a97a80d9 | | Dale, can you help us? | | Thanks | | Mariano | | > Alexandre | > | > | > | > On 28 Apr 2010, at 11:40, Mariano Martinez Peck wrote: | > | > | >> | >> On Wed, Apr 28, 2010 at 3:22 PM, Alexandre Bergel | <[hidden email]> | >> wrote: | >> Hi! | >> | >> I am now trying to make ConfigurationOfPharo load the last version | of | >> OmniBrowser. | >> If I do in a fresh core: ConfigurationOfPharo project lastVersion | load | >> | >> Then OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. | >> | >> | >> No. If you take a PharoCore 1.0 OR 1.1 and evaluate | ConfigurationOfPharo | >> project lastVersion load | >> | >> It installs OmniBrowser-lr.469 and OB-Morphic-lr.116 | >> which are correct as those are defined in | ConfigurationOfOmniBrowser | >> version 1.1.2. And ConfigurationOfPharo 1.1 has 1.1.2 of OB. | >> | >> | >> The loading blocks on the deprecated warning (yes, the registration | in the | >> World menu). | >> In ConfigurationOfPharo>>version11: I have | >> | >> spec | >> project: 'PharoNonCorePackages' | with: | >> '1.1.0'; | >> project: 'NewInspector' with: '1.1'; | >> project: 'Shout' with: '1.0'; | >> project: 'Shout Tests' with: '1.0'; | >> project: 'OCompletion' with: '1.1'; | >> project: 'OCompletion Tests' with: | '1.1'; | >> project: 'OB Dev' with: '1.1.3'; | >> project: 'OB Dev Tests' with: | '1.1.3'; | >> ... | >> | >> I therefore assume that the version 1.1.3 of OmniBrowser is | loaded. | >> 1.1.3 is indeed the last version specified in | ConfigurationOfOmniBrowser: | >> ConfigurationOfOmniBrowser project lastVersion | >> => ~1.1.3 [ConfigurationOfOmniBrowser] | >> | >> But I evaluate: ConfigurationOfOmniBrowser project lastVersion | load | >> Then the version OB-Morphic-lr.116, OB-Standard-lr.463 and | >> OmniBrowser-lr.469 are loaded. | >> | >> | >> Exactly. And that's correct. Those are the versions that are | defined in | >> ConfigurationOfOmnibrowser 1.1.3 | >> | >> I find it is very hard to keep track of what is actually loaded. | >> | >> | >> I don't understand your problem. Everything seems to work as | exepected. | >> | >> | >> I haven't closely followed the evolution of Metacello, but there is | not a | >> way to say: | >> spec project: 'OB Dev' with: 'lastestVersion' | >> | >> Yes. Don't put any version. If you don't define a version, | metacallo will | >> load the last one. | >> | >> project: 'OB Dev'; | >> | >> or even remove that line from the version method. Even more, if | you want | >> ALL the last, you can load the baseline instead of the version. In | such | >> case, as you don't specify any version, it will download all the | last ones. | >> | >> Cheers | >> | >> Mariano | >> | >> | >> Or Something? | >> | >> Cheers, | >> Alexandre | >> -- | >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | >> Alexandre Bergel http://www.bergel.eu | >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | >> | >> | >> | >> | >> | >> | >> _______________________________________________ | >> Pharo-project mailing list | >> [hidden email] | >> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | >> | >> _______________________________________________ | >> Pharo-project mailing list | >> [hidden email] | >> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | >> | > | > | > _______________________________________________ | > Pharo-project mailing list | > [hidden email] | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ConfigurationOfPharo and OmniBrowser
|
|
Ok, I will check.
Alexandre On 29 Apr 2010, at 14:08, Dale Henrichs wrote: > Mariano and Alexandre, > > Sorry for the late reply ... I've been off-line with a cold for the > last several days ... > > I have seen the behavior that you describe while working with GLASS > 1.0-beta.8 and have fixed the problem in Metacello 1.0-beta.26.1 ... > 1.0-beta.26.1 is still in development, but if you want to give it a > try, preload 1.0-beta.26.1 and rerun your test ... if the problem > still persists, let me know and I will dive into it. > > Dale > ----- "Mariano Martinez Peck" <[hidden email]> wrote: > > | On Wed, Apr 28, 2010 at 11:28 PM, Alexandre Bergel < > | [hidden email]> wrote: > | > | > It is a bit more subtle than that. > | > > | > If I take a Core 1.1, and doit: ConfigurationOfPharo project > | lastVersion > | > load > | > Then I get a warning coming from OBSearchBrowser class related to > | the world > | > menu registration. > | > > | > > | Yes, I noticed that. > | > | > | > At that moment, OmniBrowser-lr.458 and OB-Morphic-lr.112 are > | loaded. > | > > | > Doing twice a proceed resume the loading. > | > It then blocks on SHWorkspace, for the very same reason. > | > > | > > | yes.. > | > | > | > After having manually fixed the Nile problem (isInMemory), Pharo > | loads > | > well. ProfStef is open. > | > > | > > | I did the same... > | > | > | > OmniBrowser-lr.469 and OB-Morphic-lr.116 are loaded. This means > | that > | > OmniBrowser is loaded twice. Is this the intended behavior? > | > > | > > | I saw directly the final versions: 469 and 116. I didn't notice it > was > | first > | trying to load 458 and 112. > | I know that in such conflict, Metacello will load the last one, > but I > | didnt > | know that it actually LOADS also the previous versions. I thought > that > | it > | only loads the final version, not both of them. In such case, I > think > | it is > | a metacello bug. > | > | See this link: > | http://groups.google.com/group/metacello/browse_thread/thread/e8a08b3ed1a9b772/edd79873a97a80d9?lnk=gst&q=conflict#edd79873a97a80d9 > | > | Dale, can you help us? > | > | Thanks > | > | Mariano > | > | > Alexandre > | > > | > > | > > | > On 28 Apr 2010, at 11:40, Mariano Martinez Peck wrote: > | > > | > > | >> > | >> On Wed, Apr 28, 2010 at 3:22 PM, Alexandre Bergel > | <[hidden email]> > | >> wrote: > | >> Hi! > | >> > | >> I am now trying to make ConfigurationOfPharo load the last > version > | of > | >> OmniBrowser. > | >> If I do in a fresh core: ConfigurationOfPharo project lastVersion > | load > | >> > | >> Then OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. > | >> > | >> > | >> No. If you take a PharoCore 1.0 OR 1.1 and evaluate > | ConfigurationOfPharo > | >> project lastVersion load > | >> > | >> It installs OmniBrowser-lr.469 and OB-Morphic-lr.116 > | >> which are correct as those are defined in > | ConfigurationOfOmniBrowser > | >> version 1.1.2. And ConfigurationOfPharo 1.1 has 1.1.2 of OB. > | >> > | >> > | >> The loading blocks on the deprecated warning (yes, the > registration > | in the > | >> World menu). > | >> In ConfigurationOfPharo>>version11: I have > | >> > | >> spec > | >> project: 'PharoNonCorePackages' > | with: > | >> '1.1.0'; > | >> project: 'NewInspector' with: > '1.1'; > | >> project: 'Shout' with: '1.0'; > | >> project: 'Shout Tests' with: '1.0'; > | >> project: 'OCompletion' with: '1.1'; > | >> project: 'OCompletion Tests' with: > | '1.1'; > | >> project: 'OB Dev' with: '1.1.3'; > | >> project: 'OB Dev Tests' with: > | '1.1.3'; > | >> ... > | >> > | >> I therefore assume that the version 1.1.3 of OmniBrowser is > | loaded. > | >> 1.1.3 is indeed the last version specified in > | ConfigurationOfOmniBrowser: > | >> ConfigurationOfOmniBrowser project lastVersion > | >> => ~1.1.3 [ConfigurationOfOmniBrowser] > | >> > | >> But I evaluate: ConfigurationOfOmniBrowser project lastVersion > | load > | >> Then the version OB-Morphic-lr.116, OB-Standard-lr.463 and > | >> OmniBrowser-lr.469 are loaded. > | >> > | >> > | >> Exactly. And that's correct. Those are the versions that are > | defined in > | >> ConfigurationOfOmnibrowser 1.1.3 > | >> > | >> I find it is very hard to keep track of what is actually loaded. > | >> > | >> > | >> I don't understand your problem. Everything seems to work as > | exepected. > | >> > | >> > | >> I haven't closely followed the evolution of Metacello, but > there is > | not a > | >> way to say: > | >> spec project: 'OB Dev' with: 'lastestVersion' > | >> > | >> Yes. Don't put any version. If you don't define a version, > | metacallo will > | >> load the last one. > | >> > | >> project: 'OB Dev'; > | >> > | >> or even remove that line from the version method. Even more, if > | you want > | >> ALL the last, you can load the baseline instead of the version. > In > | such > | >> case, as you don't specify any version, it will download all the > | last ones. > | >> > | >> Cheers > | >> > | >> Mariano > | >> > | >> > | >> Or Something? > | >> > | >> Cheers, > | >> Alexandre > | >> -- > | >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > | >> Alexandre Bergel http://www.bergel.eu > | >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > | >> > | >> > | >> > | >> > | >> > | >> > | >> _______________________________________________ > | >> Pharo-project mailing list > | >> [hidden email] > | >> > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | >> > | >> _______________________________________________ > | >> Pharo-project mailing list > | >> [hidden email] > | >> > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | >> > | > > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > [hidden email] > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > project > | > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ConfigurationOfPharo and OmniBrowser
|
|
In reply to this post by Dale
Apparently the bug remains. When I load the last version of
'ConfigurationOfPharo project' in a fresh and updated Core 1.1, then OB-Standard.lr.442 is loaded and initialized. So, the problem persists :-) Thanks Dale for offering your help. Cheers, Alexandre On 29 Apr 2010, at 14:08, Dale Henrichs wrote: > Mariano and Alexandre, > > Sorry for the late reply ... I've been off-line with a cold for the > last several days ... > > I have seen the behavior that you describe while working with GLASS > 1.0-beta.8 and have fixed the problem in Metacello 1.0-beta.26.1 ... > 1.0-beta.26.1 is still in development, but if you want to give it a > try, preload 1.0-beta.26.1 and rerun your test ... if the problem > still persists, let me know and I will dive into it. > > Dale > ----- "Mariano Martinez Peck" <[hidden email]> wrote: > > | On Wed, Apr 28, 2010 at 11:28 PM, Alexandre Bergel < > | [hidden email]> wrote: > | > | > It is a bit more subtle than that. > | > > | > If I take a Core 1.1, and doit: ConfigurationOfPharo project > | lastVersion > | > load > | > Then I get a warning coming from OBSearchBrowser class related to > | the world > | > menu registration. > | > > | > > | Yes, I noticed that. > | > | > | > At that moment, OmniBrowser-lr.458 and OB-Morphic-lr.112 are > | loaded. > | > > | > Doing twice a proceed resume the loading. > | > It then blocks on SHWorkspace, for the very same reason. > | > > | > > | yes.. > | > | > | > After having manually fixed the Nile problem (isInMemory), Pharo > | loads > | > well. ProfStef is open. > | > > | > > | I did the same... > | > | > | > OmniBrowser-lr.469 and OB-Morphic-lr.116 are loaded. This means > | that > | > OmniBrowser is loaded twice. Is this the intended behavior? > | > > | > > | I saw directly the final versions: 469 and 116. I didn't notice it > was > | first > | trying to load 458 and 112. > | I know that in such conflict, Metacello will load the last one, > but I > | didnt > | know that it actually LOADS also the previous versions. I thought > that > | it > | only loads the final version, not both of them. In such case, I > think > | it is > | a metacello bug. > | > | See this link: > | http://groups.google.com/group/metacello/browse_thread/thread/e8a08b3ed1a9b772/edd79873a97a80d9?lnk=gst&q=conflict#edd79873a97a80d9 > | > | Dale, can you help us? > | > | Thanks > | > | Mariano > | > | > Alexandre > | > > | > > | > > | > On 28 Apr 2010, at 11:40, Mariano Martinez Peck wrote: > | > > | > > | >> > | >> On Wed, Apr 28, 2010 at 3:22 PM, Alexandre Bergel > | <[hidden email]> > | >> wrote: > | >> Hi! > | >> > | >> I am now trying to make ConfigurationOfPharo load the last > version > | of > | >> OmniBrowser. > | >> If I do in a fresh core: ConfigurationOfPharo project lastVersion > | load > | >> > | >> Then OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. > | >> > | >> > | >> No. If you take a PharoCore 1.0 OR 1.1 and evaluate > | ConfigurationOfPharo > | >> project lastVersion load > | >> > | >> It installs OmniBrowser-lr.469 and OB-Morphic-lr.116 > | >> which are correct as those are defined in > | ConfigurationOfOmniBrowser > | >> version 1.1.2. And ConfigurationOfPharo 1.1 has 1.1.2 of OB. > | >> > | >> > | >> The loading blocks on the deprecated warning (yes, the > registration > | in the > | >> World menu). > | >> In ConfigurationOfPharo>>version11: I have > | >> > | >> spec > | >> project: 'PharoNonCorePackages' > | with: > | >> '1.1.0'; > | >> project: 'NewInspector' with: > '1.1'; > | >> project: 'Shout' with: '1.0'; > | >> project: 'Shout Tests' with: '1.0'; > | >> project: 'OCompletion' with: '1.1'; > | >> project: 'OCompletion Tests' with: > | '1.1'; > | >> project: 'OB Dev' with: '1.1.3'; > | >> project: 'OB Dev Tests' with: > | '1.1.3'; > | >> ... > | >> > | >> I therefore assume that the version 1.1.3 of OmniBrowser is > | loaded. > | >> 1.1.3 is indeed the last version specified in > | ConfigurationOfOmniBrowser: > | >> ConfigurationOfOmniBrowser project lastVersion > | >> => ~1.1.3 [ConfigurationOfOmniBrowser] > | >> > | >> But I evaluate: ConfigurationOfOmniBrowser project lastVersion > | load > | >> Then the version OB-Morphic-lr.116, OB-Standard-lr.463 and > | >> OmniBrowser-lr.469 are loaded. > | >> > | >> > | >> Exactly. And that's correct. Those are the versions that are > | defined in > | >> ConfigurationOfOmnibrowser 1.1.3 > | >> > | >> I find it is very hard to keep track of what is actually loaded. > | >> > | >> > | >> I don't understand your problem. Everything seems to work as > | exepected. > | >> > | >> > | >> I haven't closely followed the evolution of Metacello, but > there is > | not a > | >> way to say: > | >> spec project: 'OB Dev' with: 'lastestVersion' > | >> > | >> Yes. Don't put any version. If you don't define a version, > | metacallo will > | >> load the last one. > | >> > | >> project: 'OB Dev'; > | >> > | >> or even remove that line from the version method. Even more, if > | you want > | >> ALL the last, you can load the baseline instead of the version. > In > | such > | >> case, as you don't specify any version, it will download all the > | last ones. > | >> > | >> Cheers > | >> > | >> Mariano > | >> > | >> > | >> Or Something? > | >> > | >> Cheers, > | >> Alexandre > | >> -- > | >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > | >> Alexandre Bergel http://www.bergel.eu > | >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > | >> > | >> > | >> > | >> > | >> > | >> > | >> _______________________________________________ > | >> Pharo-project mailing list > | >> [hidden email] > | >> > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | >> > | >> _______________________________________________ > | >> Pharo-project mailing list > | >> [hidden email] > | >> > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | >> > | > > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > [hidden email] > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > project > | > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Okay I'll dig into this...thanks for confirming.
Dale ----- "Alexandre Bergel" <[hidden email]> wrote: | Apparently the bug remains. When I load the last version of | 'ConfigurationOfPharo project' in a fresh and updated Core 1.1, then | | OB-Standard.lr.442 is loaded and initialized. | | So, the problem persists :-) | Thanks Dale for offering your help. | | Cheers, | Alexandre | | | On 29 Apr 2010, at 14:08, Dale Henrichs wrote: | | > Mariano and Alexandre, | > | > Sorry for the late reply ... I've been off-line with a cold for the | | > last several days ... | > | > I have seen the behavior that you describe while working with GLASS | | > 1.0-beta.8 and have fixed the problem in Metacello 1.0-beta.26.1 ... | | > 1.0-beta.26.1 is still in development, but if you want to give it a | | > try, preload 1.0-beta.26.1 and rerun your test ... if the problem | > still persists, let me know and I will dive into it. | > | > Dale | > ----- "Mariano Martinez Peck" <[hidden email]> wrote: | > | > | On Wed, Apr 28, 2010 at 11:28 PM, Alexandre Bergel < | > | [hidden email]> wrote: | > | | > | > It is a bit more subtle than that. | > | > | > | > If I take a Core 1.1, and doit: ConfigurationOfPharo project | > | lastVersion | > | > load | > | > Then I get a warning coming from OBSearchBrowser class related | to | > | the world | > | > menu registration. | > | > | > | > | > | Yes, I noticed that. | > | | > | | > | > At that moment, OmniBrowser-lr.458 and OB-Morphic-lr.112 are | > | loaded. | > | > | > | > Doing twice a proceed resume the loading. | > | > It then blocks on SHWorkspace, for the very same reason. | > | > | > | > | > | yes.. | > | | > | | > | > After having manually fixed the Nile problem (isInMemory), | Pharo | > | loads | > | > well. ProfStef is open. | > | > | > | > | > | I did the same... | > | | > | | > | > OmniBrowser-lr.469 and OB-Morphic-lr.116 are loaded. This means | > | that | > | > OmniBrowser is loaded twice. Is this the intended behavior? | > | > | > | > | > | I saw directly the final versions: 469 and 116. I didn't notice it | | > was | > | first | > | trying to load 458 and 112. | > | I know that in such conflict, Metacello will load the last one, | > but I | > | didnt | > | know that it actually LOADS also the previous versions. I thought | | > that | > | it | > | only loads the final version, not both of them. In such case, I | > think | > | it is | > | a metacello bug. | > | | > | See this link: | > | | http://groups.google.com/group/metacello/browse_thread/thread/e8a08b3ed1a9b772/edd79873a97a80d9?lnk=gst&q=conflict#edd79873a97a80d9 | > | | > | Dale, can you help us? | > | | > | Thanks | > | | > | Mariano | > | | > | > Alexandre | > | > | > | > | > | > | > | > On 28 Apr 2010, at 11:40, Mariano Martinez Peck wrote: | > | > | > | > | > | >> | > | >> On Wed, Apr 28, 2010 at 3:22 PM, Alexandre Bergel | > | <[hidden email]> | > | >> wrote: | > | >> Hi! | > | >> | > | >> I am now trying to make ConfigurationOfPharo load the last | > version | > | of | > | >> OmniBrowser. | > | >> If I do in a fresh core: ConfigurationOfPharo project | lastVersion | > | load | > | >> | > | >> Then OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. | > | >> | > | >> | > | >> No. If you take a PharoCore 1.0 OR 1.1 and evaluate | > | ConfigurationOfPharo | > | >> project lastVersion load | > | >> | > | >> It installs OmniBrowser-lr.469 and OB-Morphic-lr.116 | > | >> which are correct as those are defined in | > | ConfigurationOfOmniBrowser | > | >> version 1.1.2. And ConfigurationOfPharo 1.1 has 1.1.2 of OB. | > | >> | > | >> | > | >> The loading blocks on the deprecated warning (yes, the | > registration | > | in the | > | >> World menu). | > | >> In ConfigurationOfPharo>>version11: I have | > | >> | > | >> spec | > | >> project: 'PharoNonCorePackages' | > | with: | > | >> '1.1.0'; | > | >> project: 'NewInspector' with: | > '1.1'; | > | >> project: 'Shout' with: '1.0'; | > | >> project: 'Shout Tests' with: | '1.0'; | > | >> project: 'OCompletion' with: | '1.1'; | > | >> project: 'OCompletion Tests' | with: | > | '1.1'; | > | >> project: 'OB Dev' with: '1.1.3'; | > | >> project: 'OB Dev Tests' with: | > | '1.1.3'; | > | >> ... | > | >> | > | >> I therefore assume that the version 1.1.3 of OmniBrowser is | > | loaded. | > | >> 1.1.3 is indeed the last version specified in | > | ConfigurationOfOmniBrowser: | > | >> ConfigurationOfOmniBrowser project lastVersion | > | >> => ~1.1.3 [ConfigurationOfOmniBrowser] | > | >> | > | >> But I evaluate: ConfigurationOfOmniBrowser project lastVersion | > | load | > | >> Then the version OB-Morphic-lr.116, OB-Standard-lr.463 and | > | >> OmniBrowser-lr.469 are loaded. | > | >> | > | >> | > | >> Exactly. And that's correct. Those are the versions that are | > | defined in | > | >> ConfigurationOfOmnibrowser 1.1.3 | > | >> | > | >> I find it is very hard to keep track of what is actually | loaded. | > | >> | > | >> | > | >> I don't understand your problem. Everything seems to work as | > | exepected. | > | >> | > | >> | > | >> I haven't closely followed the evolution of Metacello, but | > there is | > | not a | > | >> way to say: | > | >> spec project: 'OB Dev' with: 'lastestVersion' | > | >> | > | >> Yes. Don't put any version. If you don't define a version, | > | metacallo will | > | >> load the last one. | > | >> | > | >> project: 'OB Dev'; | > | >> | > | >> or even remove that line from the version method. Even more, | if | > | you want | > | >> ALL the last, you can load the baseline instead of the version. | | > In | > | such | > | >> case, as you don't specify any version, it will download all | the | > | last ones. | > | >> | > | >> Cheers | > | >> | > | >> Mariano | > | >> | > | >> | > | >> Or Something? | > | >> | > | >> Cheers, | > | >> Alexandre | > | >> -- | > | >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | > | >> Alexandre Bergel http://www.bergel.eu | > | >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | > | >> | > | >> | > | >> | > | >> | > | >> | > | >> | > | >> _______________________________________________ | > | >> Pharo-project mailing list | > | >> [hidden email] | > | >> | > | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | >> | > | >> _______________________________________________ | > | >> Pharo-project mailing list | > | >> [hidden email] | > | >> | > | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | >> | > | > | > | > | > | > _______________________________________________ | > | > Pharo-project mailing list | > | > [hidden email] | > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- | > project | > | > | > | > _______________________________________________ | > Pharo-project mailing list | > [hidden email] | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Alexandre Bergel
----- "Alexandre Bergel" <[hidden email]> wrote: | Apparently the bug remains. When I load the last version of | 'ConfigurationOfPharo project' in a fresh and updated Core 1.1, then | | OB-Standard.lr.442 is loaded and initialized. | | So, the problem persists :-) Alexandre, The short answer is that this isn't really a bug. ConfigurationOfAutomaticMethodCategorizer calls for version 1.1 of ConfigurationOfOmniBrowser which references OB-Standard-lr.442. Version 1.1.3 of ConfigurationOfOmniBrowser (which references OB-Standard-lr.463) is listed after ConfigurationOfAutomaticMethodCategorizer in 1.1-baseline so OB-Standard-lr.442 is loaded first, then OB-Standard-lr.463 will be loaded later. 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... I'll give the long answer here so that folks can have an example of debugging a load issue in Metacello. The first thing I do is find the top MetacelloLoaderPolicy on the debugger stack and inspect loadDirective instance variable. Here's the printString: linear load : explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfOCompletion-Alexandre_Bergel.17 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfProfStef-DaleHenrichs.8 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfOmniBrowser-MarianoMartinezPeck.41 explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfPharoNonCore-MarianoMartinezPeck.2 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfRefactoringBrowser-MarianoMartinezPeck.22 explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfShout-DaleHenrichs.11 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfNile-MarianoMartinezPeck.11 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfAutomaticMethodCategorizer-MarianoMartinezPeck.4 explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfNewInspector-MarianoMartinezPeck.5 explicit load : 1.1 [ConfigurationOfPharo] preload : 1.1 [ConfigurationOfPharo] >> preloadForPharo linear load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] linear load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] linear load : 1.1 [ConfigurationOfOmniBrowser] load : OmniBrowser-lr.458 load : OB-Morphic-lr.112 load : OB-Standard-lr.442 postload : OB-Standard >> postLoadOBStandard load : AutomaticMethodCategorizer-DF.25 load : AutomaticMethodCategorizerOB-DF.1 linear load : 1.0 [ConfigurationOfShout] load : Shout-nice.83 load : ShoutWorkspace.1-tween.4 linear load : 1.0 [ConfigurationOfShout] load : ShoutTests-tween.9 linear load : 1.1.1 [ConfigurationOfOCompletion] load : RoelTyper-DamienCassou.80 load : Ocompletion-RomainRobbes.58 linear load : 1.1.1 [ConfigurationOfOCompletion] load : OcompletionTests-MarianoMartinezPeck.3 explicit load : 1.1.0 [ConfigurationOfPharoNonCore] load : ConfigurationOfPharoSound-MarianoMartinezPeck.8 explicit load : 1.1.0 [ConfigurationOfPharoNonCore] load : ConfigurationOfPharoMorphicExtras-MarianoMartinezPeck.10 preload : 1.1.0 [ConfigurationOfPharoNonCore] >> preloadForPharo linear load : 1.1.0 [ConfigurationOfPharoNonCore] linear load : 2.0 [ConfigurationOfPharoSound] load : Sound-MarianoMartinezPeck.49 load : SoundMorphicUserInterface-MarianoMartinezPeck.9 explicit load : 2.0 [ConfigurationOfPharoMorphicExtras] linear load : 2.0 [ConfigurationOfPharoMorphicExtras] load : MorphExamplesAndDemos-DamienCassou.5 load : LED-StephaneDucasse.1 load : ArchiveViewer-MarianoMartinezPeck.3 postload : 1.1.0 [ConfigurationOfPharoNonCore] >> postloadForPharo linear load : 1.1 [ConfigurationOfNewInspector] load : NewInspector-FredericPluquet.64 linear load : 1.2.1 [ConfigurationOfRefactoringBrowser] load : AST-Core-lr.67 load : Refactoring-Core-lr.115 load : Refactoring-Spelling-lr.19 linear load : 1.2.1 [ConfigurationOfRefactoringBrowser] load : AST-Tests-Core-lr.9 load : Refactoring-Tests-Core-lr.36 load : Refactoring-Tests-Spelling-lr.4 linear load : 1.1 [ConfigurationOfNile] load : Nile-Base-DamienCassou.81 linear load : 1.1 [ConfigurationOfNile] load : Nile-Tests-DamienCassou.75 load : Nile-Clients-MarianoMartinezPeck.178 explicit load : 1.1.3 [ConfigurationOfOmniBrowser] linear load : 1.1.3 [ConfigurationOfOmniBrowser] load : OmniBrowser-lr.469 load : OB-Morphic-lr.116 load : OB-Standard-lr.463 postload : OB-Standard >> postLoadOBStandard load : OB-SUnitIntegration-lr.24 load : OB-Shout-lr.5 load : OB-Refactory-lr.203 load : OB-Regex-lr.22 load : OCForOB-rr.2 explicit load : 1.1.3 [ConfigurationOfOmniBrowser] linear load : 1.1.3 [ConfigurationOfOmniBrowser] load : OB-Tests-Core-lr.81 load : OB-Tests-Morphic-lr.26 load : BogusInfo-lr.18 load : OB-Fake-lr.14 load : OB-Tests-Standard-lr.110 linear load : 1.0 [ConfigurationOfProfStef] load : ProfStef-Core-LaurentLaffont.2 linear load : 1.0 [ConfigurationOfProfStef] load : ProfStef-Tests-LaurentLaffont.2 load : ImageForDevelopers-pharo-MarianoMartinezPeck.224 postload : 1.1 [ConfigurationOfPharo] >> postloadForPharo Since OB-Standard is the problem package you can search for the package in the printString. The first occurrence is here: linear load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] linear load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] linear load : 1.1 [ConfigurationOfOmniBrowser] load : OmniBrowser-lr.458 load : OB-Morphic-lr.112 load : OB-Standard-lr.442 postload : OB-Standard >> postLoadOBStandard and the second occurrence is here: linear load : 1.1.3 [ConfigurationOfOmniBrowser] load : OmniBrowser-lr.469 load : OB-Morphic-lr.116 load : OB-Standard-lr.463 postload : OB-Standard >> postLoadOBStandard 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... Dale _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ConfigurationOfPharo and OmniBrowser
|
|
On Tue, May 4, 2010 at 6:52 PM, Dale Henrichs <[hidden email]> wrote:
ConfigurationOfAutomaticMethodCategorizer in 1.1-baseline so OB-Standard-lr.442 is loaded first, then OB-Standard-lr.463 will be loaded later. 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 ? 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. .....
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 |
Re: ConfigurationOfPharo and OmniBrowser
|
|
In reply to this post by Dale
I understand now.
Thanks, Alexandre On 4 May 2010, at 12:52, Dale Henrichs wrote: > > ----- "Alexandre Bergel" <[hidden email]> wrote: > > | Apparently the bug remains. When I load the last version of > | 'ConfigurationOfPharo project' in a fresh and updated Core 1.1, then > | > | OB-Standard.lr.442 is loaded and initialized. > | > | So, the problem persists :-) > > Alexandre, > > The short answer is that this isn't really a bug. > ConfigurationOfAutomaticMethodCategorizer calls for version 1.1 of > ConfigurationOfOmniBrowser which references OB-Standard-lr.442. > Version 1.1.3 of ConfigurationOfOmniBrowser (which references OB- > Standard-lr.463) is listed after > ConfigurationOfAutomaticMethodCategorizer in 1.1-baseline so OB- > Standard-lr.442 is loaded first, then OB-Standard-lr.463 will be > loaded later. > > 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... > > I'll give the long answer here so that folks can have an example of > debugging a load issue in Metacello. > > The first thing I do is find the top MetacelloLoaderPolicy on the > debugger stack and inspect loadDirective instance variable. Here's > the printString: > > linear load : > explicit load : 1.1 [ConfigurationOfPharo] > load : ConfigurationOfOCompletion-Alexandre_Bergel.17 > explicit load : 1.1 [ConfigurationOfPharo] > load : ConfigurationOfProfStef-DaleHenrichs.8 > explicit load : 1.1 [ConfigurationOfPharo] > load : ConfigurationOfOmniBrowser-MarianoMartinezPeck.41 > explicit load : 1.1 [ConfigurationOfPharo] > explicit load : 1.1 [ConfigurationOfPharo] > explicit load : 1.1 [ConfigurationOfPharo] > load : ConfigurationOfPharoNonCore-MarianoMartinezPeck.2 > explicit load : 1.1 [ConfigurationOfPharo] > load : ConfigurationOfRefactoringBrowser-MarianoMartinezPeck.22 > explicit load : 1.1 [ConfigurationOfPharo] > explicit load : 1.1 [ConfigurationOfPharo] > explicit load : 1.1 [ConfigurationOfPharo] > load : ConfigurationOfShout-DaleHenrichs.11 > explicit load : 1.1 [ConfigurationOfPharo] > load : ConfigurationOfNile-MarianoMartinezPeck.11 > explicit load : 1.1 [ConfigurationOfPharo] > load : ConfigurationOfAutomaticMethodCategorizer- > MarianoMartinezPeck.4 > explicit load : 1.1 [ConfigurationOfPharo] > explicit load : 1.1 [ConfigurationOfPharo] > load : ConfigurationOfNewInspector-MarianoMartinezPeck.5 > explicit load : 1.1 [ConfigurationOfPharo] > preload : 1.1 [ConfigurationOfPharo] >> preloadForPharo > linear load : 1.1 [ConfigurationOfPharo] > explicit load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] > linear load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] > linear load : 1.1 [ConfigurationOfOmniBrowser] > load : OmniBrowser-lr.458 > load : OB-Morphic-lr.112 > load : OB-Standard-lr.442 > postload : OB-Standard >> postLoadOBStandard > load : AutomaticMethodCategorizer-DF.25 > load : AutomaticMethodCategorizerOB-DF.1 > linear load : 1.0 [ConfigurationOfShout] > load : Shout-nice.83 > load : ShoutWorkspace.1-tween.4 > linear load : 1.0 [ConfigurationOfShout] > load : ShoutTests-tween.9 > linear load : 1.1.1 [ConfigurationOfOCompletion] > load : RoelTyper-DamienCassou.80 > load : Ocompletion-RomainRobbes.58 > linear load : 1.1.1 [ConfigurationOfOCompletion] > load : OcompletionTests-MarianoMartinezPeck.3 > explicit load : 1.1.0 [ConfigurationOfPharoNonCore] > load : ConfigurationOfPharoSound-MarianoMartinezPeck.8 > explicit load : 1.1.0 [ConfigurationOfPharoNonCore] > load : ConfigurationOfPharoMorphicExtras-MarianoMartinezPeck.10 > preload : 1.1.0 [ConfigurationOfPharoNonCore] >> preloadForPharo > linear load : 1.1.0 [ConfigurationOfPharoNonCore] > linear load : 2.0 [ConfigurationOfPharoSound] > load : Sound-MarianoMartinezPeck.49 > load : SoundMorphicUserInterface-MarianoMartinezPeck.9 > explicit load : 2.0 [ConfigurationOfPharoMorphicExtras] > linear load : 2.0 [ConfigurationOfPharoMorphicExtras] > load : MorphExamplesAndDemos-DamienCassou.5 > load : LED-StephaneDucasse.1 > load : ArchiveViewer-MarianoMartinezPeck.3 > postload : 1.1.0 [ConfigurationOfPharoNonCore] >> postloadForPharo > linear load : 1.1 [ConfigurationOfNewInspector] > load : NewInspector-FredericPluquet.64 > linear load : 1.2.1 [ConfigurationOfRefactoringBrowser] > load : AST-Core-lr.67 > load : Refactoring-Core-lr.115 > load : Refactoring-Spelling-lr.19 > linear load : 1.2.1 [ConfigurationOfRefactoringBrowser] > load : AST-Tests-Core-lr.9 > load : Refactoring-Tests-Core-lr.36 > load : Refactoring-Tests-Spelling-lr.4 > linear load : 1.1 [ConfigurationOfNile] > load : Nile-Base-DamienCassou.81 > linear load : 1.1 [ConfigurationOfNile] > load : Nile-Tests-DamienCassou.75 > load : Nile-Clients-MarianoMartinezPeck.178 > explicit load : 1.1.3 [ConfigurationOfOmniBrowser] > linear load : 1.1.3 [ConfigurationOfOmniBrowser] > load : OmniBrowser-lr.469 > load : OB-Morphic-lr.116 > load : OB-Standard-lr.463 > postload : OB-Standard >> postLoadOBStandard > load : OB-SUnitIntegration-lr.24 > load : OB-Shout-lr.5 > load : OB-Refactory-lr.203 > load : OB-Regex-lr.22 > load : OCForOB-rr.2 > explicit load : 1.1.3 [ConfigurationOfOmniBrowser] > linear load : 1.1.3 [ConfigurationOfOmniBrowser] > load : OB-Tests-Core-lr.81 > load : OB-Tests-Morphic-lr.26 > load : BogusInfo-lr.18 > load : OB-Fake-lr.14 > load : OB-Tests-Standard-lr.110 > linear load : 1.0 [ConfigurationOfProfStef] > load : ProfStef-Core-LaurentLaffont.2 > linear load : 1.0 [ConfigurationOfProfStef] > load : ProfStef-Tests-LaurentLaffont.2 > load : ImageForDevelopers-pharo-MarianoMartinezPeck.224 > postload : 1.1 [ConfigurationOfPharo] >> postloadForPharo > > Since OB-Standard is the problem package you can search for the > package in the printString. The first occurrence is here: > > linear load : 1.1 [ConfigurationOfPharo] > explicit load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] > linear load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] > linear load : 1.1 [ConfigurationOfOmniBrowser] > load : OmniBrowser-lr.458 > load : OB-Morphic-lr.112 > load : OB-Standard-lr.442 > postload : OB-Standard >> postLoadOBStandard > > and the second occurrence is here: > > linear load : 1.1.3 [ConfigurationOfOmniBrowser] > load : OmniBrowser-lr.469 > load : OB-Morphic-lr.116 > load : OB-Standard-lr.463 > postload : OB-Standard >> postLoadOBStandard > > 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... > > Dale -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ConfigurationOfPharo and OmniBrowser
|
|
In reply to this post by Mariano Martinez Peck
> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Alexandre,
I'm actually working through this scenario right now. 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 | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Alexandre Bergel
----- "Mariano Martinez Peck" <[hidden email]> 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. 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Alexandre Bergel
----- "Dale Henrichs" <[hidden email]> wrote: | 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 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 Dale _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ConfigurationOfPharo and OmniBrowser
|
|
On Tue, May 4, 2010 at 9:49 PM, Dale Henrichs <[hidden email]> wrote:
Thanks Dale. Yes, all of those things you report, and due to the fact that not all external packages are working in Pharo 1.1 Mostly Alexandre is pushing that :) Alexandres: do you want me to commit in Nile the remove of isInMemory ? _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ConfigurationOfPharo and OmniBrowser
|
|
In reply to this post by Dale
On Tue, May 4, 2010 at 9:23 PM, Dale Henrichs <[hidden email]> wrote:
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: _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Mariano,
I think that #linear is the best default loadType...#atomic should only be used when it is really needed... I think that for 1.1 new versions of "all of the configs" will need to be done eventually since they need to load into a 1.1 Pharo Core independently without requiring one to disable the deprecated warning... Since 1.1 is still unstable, it might make sense to wait until _all_ of the issues get resolved so we don't end up spinning multiple versions for 1.1 compatibility reasons... You could put a preload doit that disables deprecation warnings (if they are enabled) and a postload doit that reenables deprecation warnings at the end of the load .... this would only be a temporary measure until 1.1 stabilizes... With my short experience using 1.1 I cannot imagine that anyone would _enable_ deprecation warnings and expect anything to work without lots and lots and lots of proceeds:) Dale ----- "Mariano Martinez Peck" <[hidden email]> wrote: | On Tue, May 4, 2010 at 9:23 PM, Dale Henrichs | <[hidden email]>wrote: | | > | > ----- "Mariano Martinez Peck" <[hidden email]> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ConfigurationOfPharo and OmniBrowser
|
|
In reply to this post by Dale
> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |