On Fri, 10 Dec 2010 21:11:47 +0100, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Note that not writing source to the changes file has ancilliary benefits;
change recovery is now not polluted with package loads and the changes file
does not grow as packages are added, only as one's changes are made.
Unloading a package doesn't leave garbage in the changes files.

There are downsides. �Deploying a development image means deploying all the
associated parcel source files as well, and for this a platform-independent
Filename abstraction really helps.

Thanks for the explanation. I wonder how the previous versions of a method can be found using parcels.

I hacked a dreadful implementation of overrides in vw3.0 and I don't think things are much better now. �But in�http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg17714.html I sketched how I think it should be done:

Maintain a global package load order (a stack of loaded packages, removing interior elements on unload).

Maintain a dictionary from method reference to set of package/method pairs for each method that is overridden.

When a package is removed search overrides and compute the overridden methods to be reinstalled, computing the uppermost method depending on the new package order.

So to answer your question, one finds the previous versions directly in the overrides dictionary, and sorts the results according to the current package load order.

Wasn't Levente asking about "regular" replacing of methods?

I thought his question was about that; if the source is not in

the changes file but in a parcel source file, then when I save

a new version of a method and want to look for the old one,

that will not be in the changes file.

When I build up a new image

from parcels, the load script copies all the sources to the

changes file, so I have easy access to the history.

Just wondering...

Peter

best

Eliot

Levente

best
Eliot

Levente