Thierry
this is really interesting. Could you add the logic in some class
comments for the future?
Stef
Le 26/2/15 10:15, Thierry Goubier a écrit :
Ok,
a first slice is in, it's the first solution for now (second is just
extending the scheme).
Loading the slice should install the lazy version and flush the caches
(does merging would initialize the class?)
Thierry
2015-02-26 9:33 GMT+01:00 Marcus Denker <[email protected]
<mailto:[email protected]>>:
And it behaves as the non-lazy one.
There are a few things to change GUI-side to avoid an unnecessary
loading of the complete ancestry of all the packages in the
image, but this is workable.
I see two ways of using it:
as an "install, flush package cache before release and gain 5MB
of RAM". If you start regularly developping (loading packages,
etc...) then new packages will revert to non-lazy version info
(without: 'please wait, I'm loading ancestry' moments).
as a permanent change in MC. The change is a bit more intrusive
(need to change how working copies are created) but, well, as
long as the worked on packages are inside the in-memory MC
package cache, behavior is exactly the same as a non-lazy version
info.
As you prefer.
My focus is that we ship an image that is not growing
indefinitely… so this means it needs to be part of the release.
I don’t care too much that the image is large when I work, but it
should not come with all this data in memory when it can be
calculated (or lazyly loaded) when needed.
I added an issue:
https://pharo.fogbugz.com/default.asp?14997
Thanks!
Marcus
