[MC] Disappearing classes and methods

stéphane ducasse ducasse at iam.unibe.ch
Fri Mar 17 18:59:15 UTC 2006


I understand what you mean with your hairs getting grayer :)
Sounds like a vicious bug to identify.

On 17 mars 06, at 16:28, Bert Freudenberg wrote:

> After getting some more gray hairs out of this ;-) I finally found  
> the problem, and eventually a solution.
>
> Attached are 4 very small MC packages that will demonstrate the bug:
>
> TestA-bf.1 contains class TestA
> TestB-bf.1 contains class TestB
> TestB-bf.1 depends on TestA-bf.1
>
> To test, just load TestB-bf.1, which in turn loads TestA-bf.1, all  
> is fine.
>
> Now I moved the classes between the packages:
>
> TestA-bf.2 contains class TestB
> TestB-bf.2 contains class TestA
> TestB-bf.2 depends on TestA-bf.2
>
> If you now load TestB-bf.2, which in turn loads TestA-bf.2, POOF,  
> both classes TestA and TestB are gone!
>
> I believe this is also the cause for disappearing methods that are  
> moved between packages.
>
> The problem appears to be MCPackageLoader, which does not check the  
> list of removals against the list of additions.
>
> I fixed that (hopefully) in Monticello-bf.279 (http:// 
> source.impara.de/mc.html). If there are more than one versions  
> loaded at once, then an additional step is taken to detect and  
> delete those removals that are also added. Would be nice if someone  
> could comment if there is a better way to do this, but I believe  
> it's not too bad. You only pay the price if indeed there is more  
> than one version to be loaded.
>
> I actually discovered this bug (though we had occasional reports  
> about lost methods) when making MCConfigurations use a simultaneous  
> load strategy (see MonticelloConfigurations-bf.38). With this fix,  
> configs now should be able to deal with methods or classes moved  
> from one package to the next, and be pretty independent of order  
> problems. Perhaps using this could also help the 3.9 team switching  
> to a more efficient work flow, even without the flaws I outlined  
> last year (http://lists.squeakfoundation.org/pipermail/squeak-dev/ 
> 2005-October/096445.html).

Thanks. We will wait (should we :)) for the feedback of colin and  
avi. But indeed I want to try because
the email of marcus created a slowdown on my eagerness to harvest :)

>
> - Bert -
>
> <TestA-bf.1.mcz>
> <TestA-bf.2.mcz>
> <TestB-bf.1.mcz>
> <TestB-bf.2.mcz>
>




More information about the Squeak-dev mailing list