[MC] Disappearing classes and methods

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

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

> (Pardon the probably wrong mailing list but I can't find an address for
> the MC list right now)
>
> When we go to load a package the system checks to see if the currently
> loaded version has changes. Good idea - but ... surprisingly often it
> turns out I have no real change in the package because I had changed
> some method (adding a self halt or whatever) and reverted it.
>
> It would be nice to  extend the over-load checking  to do the full check
> - the one I end up manually doing by selecting my current version of the
> package and checking the changes only to be told 'No Changes' - and
> thereby save me one more little bit of sanity in a stressed morning.
> Since the full chaeck can take some time for a big package or a slow
> machine, I'd suggest using a progress indicator to let the user know
> that the system is trying to be extra helpful.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: CDC: Clear Disks and Crash
>
>
>
>