Fwd: [squeak-dev] Class var order in Monticello (bogus dirty packages)

> we should check that because indeed from time to time we get the  
> symptoms even if we integrated part of the solution
> long time ago.
>
> Stef
>
>
> Begin forwarded message:
>
>> From: Eliot Miranda <[hidden email]>
>> Date: August 11, 2009 6:21:32 PM CEDT
>> To: The general-purpose Squeak developers list <[hidden email]
>> >
>> Subject: Re: [squeak-dev] Class var order in Monticello (bogus  
>> dirty packages)
>> Reply-To: The general-purpose Squeak developers list <[hidden email]
>> >
>>
>>
>>
>> On Sun, Aug 9, 2009 at 4:36 PM, Andreas Raab <[hidden email]>  
>> wrote:
>> Hi -
>>
>> I have noticed several times that Monticello sometimes reports a  
>> different order of class variables than the one that's in the image  
>> and I think I finally found out what causes it. The problem seems  
>> to be that the MCClassDefinition is constructed from a Set of class  
>> var names (i.e., Delay classVarNames => a Set(#TimerEventLoop  
>> #SuspendedDelays #TimingSemaphore #ActiveDelayStartTime  
>> #ActiveDelay #FinishedDelay #ScheduledDelay #RunTimerEventLoop  
>> #AccessProtect) derived from the class' classPool.
>>
>> The thing is, the order in that class pool can differ. When you add  
>> or remove class var names, the names can get shuffled around and  
>> there is no telling what the exact enumeration order will be. Once  
>> the order is different it's a real pain because Monticello will  
>> always report differences but without a way to correct the issue.
>>
>> I'm wondering what possible fixes might be. In particular  
>> considering that reordering the class var names will mark any  
>> packages dirty for the same reasons.
>>
>> The fix we implemented at Cadence was to sort the classVars array  
>> when initializing an MCClassDefinition, which has the advantage of  
>> being really simple, but the downside of producing false positives  
>> for packages that have been stored with unsorted class vars.  But  
>> this isn't the full fix.  One should also sort the pool n ames.  
>> Fix attached.
>>
>> I think this is a better approach than ignoring sort order when  
>> comparing because it mimics the treatment of class definitions in  
>> the system, where class var names and pool names are also sorted.
>>
>>
>> Any ideas?
>>
>> Cheers,
>> - Andreas
>>
>>
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project