Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser
----- "Mariano Martinez Peck" <marianopeck@gmail.com> 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
On Tue, May 4, 2010 at 9:23 PM, Dale Henrichs <dale.henrichs@gemstone.com>wrote:
----- "Mariano Martinez Peck" <marianopeck@gmail.com> 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
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" <marianopeck@gmail.com> wrote: | On Tue, May 4, 2010 at 9:23 PM, Dale Henrichs | <dale.henrichs@gemstone.com>wrote: | | > | > ----- "Mariano Martinez Peck" <marianopeck@gmail.com> 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 | >
participants (2)
-
Dale Henrichs -
Mariano Martinez Peck