Chris, didn't you do something about this in Squeak? It would be nice to keep consistent if possible...
Yes, but no one liked it because it employed the Proxy design-pattern and requires a become. Perhaps if I'd gotten it perfect the first time it'd have been better-received. But, I didn't, and the ensuing backlash wiped out any motivation for me to fix it. Marcus' suggestion is more explicit, and so might be better received by the community. There's a tradeoff between the two designs: In my design, you have to make sure you get it right or the image could lock up. In Marcus' design, you have to sprinkle multiple checks for #reload in the code and make sure you get it right, or you might end up saving corrupt MCZ packages (e.g., with #reload as the ancestry). Either way, its a wasteful part of the design of MC that should be addressed. I'm partial to fixing the Proxy solution, but I'd be in favor of ripping it out and adopting a stable alternative from Pharo if it becomes available.
Eliot (phone)
On Feb 20, 2015, at 6:41 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
The current Pharo4 contains *a lot* of MCVersionInfo instances.
MCVersionInfo allInstances size
11095
The hold on to strings, Date, UUID⦠a lot of stuff. All in all, this is around 10% of the current image.
If you do
MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ].
you image is a couple of MB smaller.
In the past, when this information started to be >8MB, we did that. With the bad effect that we can not merge anymore across this boundary: we kill the past.
Now this information is of course continained in the last MCZ file, too (all of them contain the complete historyâ¦)
So would the following work?
-> we set the âancestorsâ of MCVersionInfo to #reload -> the accessor, when it sees #reload, takes the name, deduces from that the package, and goes to the repo to load the ancestry info from the MCZFile.
This means that e.g when saving a MCZFile, it would first re-create history info and then save it completely (like now), yet someone who just uses the system would never need to have this info in the image.
Marcus