On 11.08.2009, at 20:11, Eliot Miranda wrote:

> 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 :)

Fine. I dug out my fix for order-independent comparison from 2006,  
added your fix to *both* versions of the initialize method, and  
committed as Monticello-bf.316.

- Bert -


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090812/10b3e076/attachment.htm