> 
> 
> 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 
> <https://pharo.fogbugz.com/default.asp?14997>
> 

Thanks!

        Marcus

Reply via email to