[Pharo-project] 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 <eliot.miranda@gmail.com> Date: August 11, 2009 6:21:32 PM CEDT To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org
Subject: Re: [squeak-dev] Class var order in Monticello (bogus dirty packages) Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org
On Sun, Aug 9, 2009 at 4:36 PM, Andreas Raab <andreas.raab@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.
Any ideas?
Cheers, - Andreas
Yes. I think we still have that problem in Pharo. Adrian On Aug 12, 2009, at 00:19 , Stéphane Ducasse wrote:
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 <eliot.miranda@gmail.com> Date: August 11, 2009 6:21:32 PM CEDT To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org
Subject: Re: [squeak-dev] Class var order in Monticello (bogus dirty packages) Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org
On Sun, Aug 9, 2009 at 4:36 PM, Andreas Raab <andreas.raab@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.
Any ideas?
Cheers, - Andreas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Adrian Lienhard -
Stéphane Ducasse