On Tue, Aug 11, 2009 at 9:44 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 11.08.2009, at 18:21, Eliot Miranda wrote:
>
>  On Sun, Aug 9, 2009 at 4:36 PM, Andreas Raab <andreas.raab at gmx.de> 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.
>>
>
>
> It's not "better" but simply half of the solution, if we go by the "be
> generous on input, strict on output" rule. That is, always store sorted from
> now on, but accept unsorted (older) packages.


Agreed :)


>
>
> - Bert -
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090811/6ec315e1/attachment.htm