[MC] Disappearing classes and methods

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

[MC] Disappearing classes and methods

Bert Freudenberg-3
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).

- Bert -




TestA-bf.1.mcz (1K) Download Attachment
TestA-bf.2.mcz (1K) Download Attachment
TestB-bf.1.mcz (1K) Download Attachment
TestB-bf.2.mcz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [MC] Disappearing classes and methods

Steven W Riggins
Thank you!

Reply | Threaded
Open this post in threaded view
|

Re: [MC] Disappearing classes and methods

stéphane ducasse-2
In reply to this post by Bert Freudenberg-3
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>
>


Reply | Threaded
Open this post in threaded view
|

Re: [MC] Disappearing classes and methods

Avi  Bryant
In reply to this post by Bert Freudenberg-3

On Mar 17, 2006, at 7:28 AM, Bert Freudenberg wrote:

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

Cool.  This sounds similar to the fix that Daniel and I struggled  
with (causing similar grey hairs) back in October for merging, so  
it's good to get it working for loading too.  Moving stuff between  
packages has always been a major PITA...

Avi


Reply | Threaded
Open this post in threaded view
|

[MC] suggestion for better (over)loading

timrowledge
(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



Reply | Threaded
Open this post in threaded view
|

Re: [MC] suggestion for better (over)loading

Andreas.Raab
Tim -

There is a useful trick for that purpose which I use all the time.
Simply hit "changes" to see what differs and for each method where you
have a "source same but rev. changed" just right-click and "revert" it.
Typically (e.g., assuming you don't have gazillion of changed methods)
that works fairly well.

Cheers,
   - Andreas

tim Rowledge wrote:

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


Reply | Threaded
Open this post in threaded view
|

Re: [MC] suggestion for better (over)loading

timrowledge

On 17-Mar-06, at 12:04 PM, Andreas Raab wrote:

> Tim -
>
> There is a useful trick for that purpose which I use all the time.  
> Simply hit "changes" to see what differs and for each method where  
> you have a "source same but rev. changed" just right-click and  
> "revert" it. Typically (e.g., assuming you don't have gazillion of  
> changed m
[snip]
Sure, but if the system would automatically do the check for me it  
would save vital seconds I could have spent drinking coffee.
The algorithm could be sometihng like
check for changes in package being loaded (ie what is done now)
if change flag set, do full check
if no changes found, continue without bothering user
if changes found, open change browser ready for user.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: LAG: Load and Garble