I would make a distinction between rot code in the image and working and ok code. for the working and ok code I would make sure that we can unload and reload it. and keep it for now. I think that the first goal of pharo is not to be smallish but to be good and modular. So during that process we should avoid to break code that is working. In particular it does not mean that because we don't use it, it is not useful.
Stef On Mar 16, 2009, at 11:44 PM, Adrian Lienhard wrote: > Hi Pavel, > > Nice to see others interested and working on this too :) > > If I apply my cleanup script on your image (see > ScriptLoader>>cleanUpForRelease) I get an image size of 8.6MB, cool! > (A standard Pharo core image is reduced to 9.1MB if you also remove > the MC ancestory). > > I think we should > - step by step extract packages and classes from Pharo core that are > not used anymore > - create a shrink script that allows one to further reduce a Pharo > core image (like removing FreeType) > > Latter would allow us to create minimal Pharo images e.g., for > deployment. > > Could you publish the changes you made so far so we can incorporate > them? > > Cheers, > Adrian > > On Mar 16, 2009, at 22:38 , Pavel Krivanek wrote: > >> Hi Adrian, >> >> I've tried to do some steps in this direction so here's a little >> cleaned exerimental image without sound, with less unimplemented >> calls >> etc.: http://comtalk.eu/public/pub/pharo/Pharo0.1Core-10248.9.zip >> >> FreeType package can be removeable, in fact it is easier to remove >> that TrueType. >> >> -- Pavel >> >> On Mon, Mar 16, 2009 at 10:21 PM, Adrian Lienhard <[email protected]> >> wrote: >>> In quest of modularizing Pharo and reducing its memory footprint, I >>> was wondering whether the following packages should be removed: >>> >>> - TrueType and related classes in Multilingual-Display (are obsolete >>> since we have FreeType, no?) >>> - Services (does not seem to be used, except by a subclass in >>> Polymorph) >>> - Graphics-External-Ffenestri (why is this in the image??) >>> - Compression (I think, does not need to be in the kernel) >>> - Sound (dito) >>> - Traits-LocalSends and Traits-Requires (are not used) >>> - MorphicExtras (I assume at least some of those could extracted) >>> - ...? >>> >>> I would put these in a repository so they can be loaded if needed. >>> The >>> extraction of some of these packages likely needs some work, but >>> would >>> be a first step towards a more modular kernel. >>> >>> What do others think? >>> >>> Adrian >>> >>> ___________________ >>> http://www.adrian-lienhard.ch/ >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
