Help with conf

Okay,

I see that you are doing an atomic load. When you do an atomic load, the definitions from each package are munged together into one giant load by the Monticello package loader ... so a method override could get lost, since load order is not strictly enforced and I don't know what the Monticello package loader does when it comes across multiple definitions for the same method...

If you use a linear load, then each package is loaded in order and the override should be preserved...

Dale

Mariano Martinez Peck wrote:

Hi Dale. Probably it is my fault and not a Metacello issue, but I need another eye to find it :(

If you take Pharo 1.1 and INSPECT:

Gofer new
   squeaksource: 'MetacelloRepository';
   package: 'ConfigurationOfGlorpDBX';
   load.

(ConfigurationOfGlorpDBX project version: '1.2') load: 'All with PostgreSQL native'


you will see:

a MetacelloFetchingMCSpecLoader(linear load :
   atomic load : 1.2 [ConfigurationOfGlorpDBX]
       load : Glorp-MarianoMartinezPeck.53
       load : GlorpPostload-YanniChiu.5
       load : GlorpTest-MarianoMartinezPeck.30
       load : GlorpTestPostload-noha.3
       load : GlorpPharoPort-Mariano.4
       load : PostgresV2-Maiano.24
       load : GlorpDriverPostgreSQL-MarianoMartinezPeck.2
       postload : GlorpDriverPostgreSQL >> postLoadGlorpDriverPostgreSQL)

Now..once everything was loaded, check the code method

UnitOfWork >> registeredObjects
   ^self correspondenceMap keys

Notice there is NO asSet at the end. This method is defined in Glorp-MarianoMartinezPeck.53  but then overriten in GlorpPharoPort-Mariano.4

In GlorpPharoPort-Mariano.4  I override that method like this:

#registeredObjects
   ^self correspondenceMap keys asSet

with a *GlorpPharoPort   as category.

So....shouldn't I get the method that has the asSet at the end?   I thought that maybe the problem was the order...but when I inspect the spec, the order seems correct.

Any hints?

Thanks in advance,

Mariano

Mariano Martinez Peck wrote:

On Wed, Aug 11, 2010 at 1:18 AM, Dale Henrichs <[hidden email] <mailto:[hidden email]>> wrote:

   Okay,

   I see that you are doing an atomic load. When you do an atomic load,
   the definitions from each package are munged together into one giant
   load by the Monticello package loader ... so a method override could
   get lost, since load order is not strictly enforced and I don't know
   what the Monticello package loader does when it comes across
   multiple definitions for the same method...


Thanks Dale. Changing loadType: to #linear worked. However, I still don't understand the problem. I think it is important. If I understand well, even if I put all the "requieres" perfect, and the metacello policy seems to be correct, you cannot load them in that order?  sorry if I understood wrong.

The atomic load takes all of the packages and lumps them together into one load, so in the end the package order is lost ... this is a "feature" of the MC package loaders ... The Seaside folks use linear loading because the "lost" package order affects the order in which initializations are performed ...

So the short answer is that package load order is "ignored" when you use #atomic load ... It's the main reason that I have made #linear load the default for Metacello.

Dale

Mariano Martinez Peck wrote:

On Wed, Aug 11, 2010 at 7:30 PM, Dale Henrichs <[hidden email] <mailto:[hidden email]>> wrote:

   Mariano Martinez Peck wrote:



       On Wed, Aug 11, 2010 at 1:18 AM, Dale Henrichs
       <[hidden email] <mailto:[hidden email]>

       <mailto:[hidden email] <mailto:[hidden email]>>> wrote:

          Okay,

          I see that you are doing an atomic load. When you do an
       atomic load,
          the definitions from each package are munged together into
       one giant
          load by the Monticello package loader ... so a method
       override could
          get lost, since load order is not strictly enforced and I
       don't know
          what the Monticello package loader does when it comes across
          multiple definitions for the same method...


       Thanks Dale. Changing loadType: to #linear worked. However, I
       still don't understand the problem. I think it is important. If
       I understand well, even if I put all the "requieres" perfect,
       and the metacello policy seems to be correct, you cannot load
       them in that order?  sorry if I understood wrong.


   The atomic load takes all of the packages and lumps them together
   into one load, so in the end the package order is lost ... this is a
   "feature" of the MC package loaders ... The Seaside folks use linear
   loading because the "lost" package order affects the order in which
   initializations are performed ...


   So the short answer is that package load order is "ignored" when you
   use #atomic load ... It's the main reason that I have made #linear
   load the default for Metacello.



Ok....but...if I understood correct, then all your #requires that you specify does not have sense anymore when using #atomic ??
In such case, I think Metacello should warn about that, document it, or something. Because otherwise, people will believe that when using #requires, all they packages will load in the correct order, despite if they are done atomically or not.

I think that the requires are still doing their job ... not necessarily from the load order perspective (for atomic load order doesn't have meaning), but from the perspective that requires is ensuring that the needed packages are included ... so it is still performing a function ...

BTW, perhaps these kinds of somewhat obscure but important issues can be covered in our presentation at ESUG...

Dale

Dale