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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Andreas.Raab
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.

Any ideas?

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

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

Bert Freudenberg

On 10.08.2009, at 01:36, Andreas Raab 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.
>
> Any ideas?


Fix: Monticello-bf.281 (29 August 2006, 12:05:21 pm)
- ignore order of class vars and pools when comparing class defs

This version is missing in the trunk version ancestry, but present in  
the latest at

        http://www.squeaksource.com/mc.html

We should switch, but I have not tested how that version works with  
the updating process.

- Bert -



Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by Andreas.Raab


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





MCClassDefinition-initializeWithNamesuperclassNamecategoryinstVarNamesclassVarNamespoolDictionaryNamesclassInstVarNamestypecommentcommentStamp.st (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Bert Freudenberg
On 11.08.2009, at 18:21, Eliot Miranda wrote:

> 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.


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.

- Bert -



Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2


On Tue, Aug 11, 2009 at 9:44 AM, Bert Freudenberg <[hidden email]> wrote:
On 11.08.2009, at 18:21, Eliot Miranda wrote:

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.


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 -






Reply | Threaded
Open this post in threaded view
|

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

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

On Tue, Aug 11, 2009 at 9:44 AM, Bert Freudenberg <[hidden email]> wrote:
On 11.08.2009, at 18:21, Eliot Miranda wrote:

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.


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 -