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.mira...@gmail.com> >> Date: August 11, 2009 6:21:32 PM CEDT >> To: The general-purpose Squeak developers list >> <squeak-...@lists.squeakfoundation.org >> > >> Subject: Re: [squeak-dev] Class var order in Monticello (bogus >> dirty packages) >> Reply-To: The general-purpose Squeak developers list >> <squeak-...@lists.squeakfoundation.org >> > >> >> >> >> On Sun, Aug 9, 2009 at 4:36 PM, Andreas Raab <andreas.r...@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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
