Shrinking the image while using Morphic (2021)
Last updated at 1:31 am UTC on 18 December 2021
See
Unload MVC classes
Though it is possible to unload MVC it is not advisable to do so if you are working with Morphic in a way which might break it. MVC is then useful.
A comparatively easy thing is to remove EToys if you do not need it:
How to unload Etoys from Squeak 5.3
Squeak 5.3 release image
Metaclass allInstances size 2737
"After unloading Etoys"
Smalltalk garbageCollect
Metaclass allInstances size 2276
Also Nebraska may be unloaded through the Monticello browser.
"After unloading Nebraska"
Metaclass allInstances size 2238
This gives you an image with 500 classes less.
For suggestions what to remove further see History of Cuis.
Notes 2016
David T. Lewis
Thu, Feb 11, 2016 at 2:00 AM
Reply-To: The general-purpose Squeak developers list
To: The general-purpose Squeak developers list
Cc: pavel.krivanek@gmail.com
On Wed, Feb 10, 2016 at 07:29:28AM -0300, Edgar J. De Cleene wrote:
...
>
> I ask to Board for made a formal invitation to Pavel Krivanek for help going
> to a Squeak kernel
>
Indeed, Pavel has done some great work on image shrinking with Squeak
and Pharo. Frank Shearar pointed to it here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-January/176343.html
Following the links from that email, here is an example of one of Pavel's scripts:
https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKernel3.0-FromTopShrink/lastSuccessfulBuild/artifact/shrink.st
Pavel has done this for Squeak also.
I know that there is strong interest in the community (including the Squeak
oversight board) in pursuing issues of modularity, minimal images, and
unloadable/reloadable packages.
There are a lot of ways to approach these issues. I think Craig Latta's
vision of building full images from very tiny micro-kernel images is
really appealing, and I hope that we will be able to drive that vision
to be widely used and part of (or maybe the real "kernel" of) Squeak.
I also really like Pavel's image shrinking, which is very practical
and maintains a focus on a full working image that can shrink to meet
requirements for a specific deployment.
Personally, I really like the idea of "reloadable" modules that can
be removed and reinstalled without breaking the system. For example,
I made MVC reloadable some time ago, and hope to do the same with Morphic
in the future:
Unload MVC classes
I am probably trying to say too many things in one email, but here is the
point that I want to get to:
When I look at Pavel's work, I see scripts that could be incorporated
as methods in a class in Squeak. We should make this happen. It would
make the scripts accessible, and it would give us a way to ensure that
they are kept up to date and in sync with the image. It would also make
it possible to provide supporting unit tests.
Suppose for example that we were to make Installer () responsible for the
unloading and loading of packages. We should then be able to (for example)
tell Installer to remove MVC (ST80-) from the system, then tell it to
load MVC. When that is done, the ST80 unit test should still pass, and
it should still be possible to open a new MVC project. And we should be
able ask Installer (or whatever class we choose to be responsible for
this) to shrink the image to produce exactly the results that Pavel has
demonstrated in his image shrinking work.
If we keep Pavel's scripts in the image, it should require very little
extra code, and it will give us a way to maintain the scripts and
verify them with unit tests. I think that we should do this for Squeak.
Dave
() I'm not really advocating Installer for this, because it has no
class comments or documentation in the image. Ick. But the name fits,
so I am using it as an example.
