Minimal Dr. Geo image
Bug #1705661 reported by
hilaire
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Dr. Geo |
Won't Fix
|
Low
|
Benoît St-Jean |
Bug Description
Pharo is becoming a fat boy (or fat girl if you prefer).
There is a need to build a Dr. Geo image with a minimum size, to not waste resources and make Dr. Geo suitable to configuration with low resources.
With Pharo 6, it is possible to build a minimal image by installing the needed packages -- and not uninstalling the unneeded packages as it was done with previous Dr. Geo release.
However, there are no clear recipe to produce such minimal image:
http://
description: | updated |
Changed in drgeo: | |
milestone: | 18.06 → wip |
importance: | Critical → Low |
Changed in drgeo: | |
status: | Confirmed → Incomplete |
Changed in drgeo: | |
status: | Incomplete → Won't Fix |
To post a comment you must log in.
I ran a simple script to detect how much cruft (classes with no references in Dr. Geo 17-07a) is left into the image. (see script attached)
There are still lots of test classes (subclasses of TestCase), all the rules for the Code Critics, lots of unneeded stuff (for instance, Pharo still has 2 compiler classes, duplicate functionalities with Stream vs Zinc classes), etc. I have never been convinced that the "minimal image" approach is the way to go as it will most likely create a Monticello package nightmare to solve dependencies.
I was thinking of creating a tool to use the stripping approach (e.g. Dolphin Smalltalk Lagoon Wizard, VisualWorks Image Stripper, VisualAge packager, etc), i.e. removing code without any references with a mechanism to provide the packager with directives/ exceptions (à la VisualAge).
First step would be to remove classes with no references. Second step would be to remove unsent methods. Third step could be symbol reduction (strip Pool dictionaries of unreferenced symbols), fifth could be to remove unreferenced instances in class and class instance variables. Of course, the tool would also provide a way to disable programmer functionalities of your choice.
I was planning on creating a simple class with no UI so you could execute the code in a Workspace/ Transcript or from the command line. All the tool output could be saved in files and/or displayed on the Transcript.
Of course, the first step would be to make the Pharo image (5.1 and up or whatever you plan to use) become "packager friendly" by supplying it with #packagerInclud eClassNames, #packagerInclud eKnownSelectors and the like.
What do you think Hilaire?