Sorry for the delay.  After 10 days of no access to a computer, I'm
finally getting back.

> Seems like the change to #named: did the opposite of what it was supposed to
> do in this case ... at least the old registration scheme seems to be at odds

I remember one of the goals for PackageInfo class>>#packageName is to
push for an unambiguous association between the Smalltalk package
domain (e.g, PackageInfos, Classes and MethodReferences) and the
Monticello package domain (MCPackages, MCClassDefinitions,
MCMethodDefinitions).  One to one.

PackageInfo subclasses would implement #packageName on the class-side.
 So, if OMeta declared the following:

OM2PreloadPackageInfo class>>packageName
     ^ 'OMeta2-Preload'

then the correct subclass-instance would be answered and all is fine.
The package name of OMeta can be referenced without a hardcoded
string.

I then used this to solve an aggravation where instances of
PackageInfo had already gotten registered even though they should have
been the subclass instance.  Probably this is no longer necessary, I
have reverted that change and will monitor going forward.

 - Chris


On Tue, Mar 29, 2011 at 12:16 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 29.03.2011, at 18:20, Nikolay Suslov wrote:
>
> On Tue, Mar 29, 2011 at 5:12 PM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
>>
>> On 29.03.2011, at 15:03, Nikolay Suslov wrote:
>>
>> SqueakSource repo's is not really broken, some issues has been appeared
>> with loading OMeta package into the current Squeak 4.2. Manually, first you
>> load OMeta2-Preload-hmm.11.mcz and then you need to merge
>> OMeta2-Postload-hmm.11.mcz (not to load). And this should work.
>>
>> Did we break Monticello? This used to work fine.
>
> No, seems to be Monticello is Ok.
> The problem begins with "PackageInfo-Base-cmm.50" from the trunk, something
> wrong with it.
> Roll-backing to "PackageInfo-Base-cmm.49" brings OMeta to load successfully
> in current Squeak.
>
> Regards,
> Nikolay
>
> Ah. Yes, PackageInfo is quite finicky at times.
> After loading OMeta2-Preload, the default PackageOrganizer correctly holds
> the two special instances for OMeta2-Preload and OMeta2-Preload. Their
> classes are OM2PreloadPackageInfo and OM2PostPackageInfo, respectively.
> That's because they register themselves in their class-side initializers.
> But "PackageInfo named: 'OMeta2-Preload'" does not answer the registered
> instance. It creates a generic "OMeta2" PackageInfo instance instead, and
> answers that.
> Seems like the change to #named: did the opposite of what it was supposed to
> do in this case ... at least the old registration scheme seems to be at odds
> with the new class-side packageName method.
> Reverting #named: to Avi's old version makes the OMeta package infos work
> correctly. Maybe we should get rid of the automagic registration again?
> Chris?
> - Bert -
>
>
>
>
>