[Pharo-project] Removing more classes from Pharo
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/
I've only ever worked with Sound, and when I didn't know how to do much with packages and had to make changes to the Sound package I just saved the whole thing loaded it into a new image, so I think it should be relatively straightforward to do as you suggest. However, if the Polymorph "sound" theme became part of the standard Pharo image, you would need sound, but that's the only thing I have heard people talking about. Umm...probably right with TrueType. Morphic, it seems, you just never know what it might interfere with! The rest I don't really know anything about. Then, maybe you could just publish them via any of the standard options (Universes, etc...) with a standard naming convention? Like Pharo-Sound...etc? Take care, Rob On Mon, Mar 16, 2009 at 5:21 PM, Adrian Lienhard <adi@netstyle.ch> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What do others think?
Yeah, it sounds reasonable to remove those classes. Never used any of them. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Never used any of them as well... Cheers, Alexandre On 16 Mar 2009, at 22:21, Adrian Lienhard 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 <adi@netstyle.ch> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <adi@netstyle.ch> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <adi@netstyle.ch> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 16-Mar-09, at 2:21 PM, Adrian Lienhard 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??)
This is part of the multiple window Ffenestri support people wailed for 5 years back, it's part of the EventSensor logic to at least support WindowEventMetricChange := 1. " size or position of window changed - value1-4 are left/top/right/bottom values " WindowEventClose := 2. " window close icon pressed " WindowEventIconise := 3. " window iconised or hidden etc " WindowEventActivated :=4. " window made active - some platforms only - do not rely upon this " WindowEventPaint := 5. " window area (in value1-4) needs updating. Some platforms do not need to send this, do not rely on it in image I believe MOST VMs now support the WindowEventClose via this logic so that people can choose to terminate an image by clicking on the close window button. I'd consider part of the base kernel since it's VM event related.
- Compression (I think, does not need to be in the kernel) - Sound (dito)
Polymorph-Widgets-Themes uses RestSound, otherwise you could remove all of sound I think, I've done that for an iphone image. You need to alter the Object>beep logic to invoke (somehow) the primtiive beep sound, versus bring up an entire Sound subsystem to beep.
- 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Ffenestri is a possible route to host windows. I am *not* a "native widgets or bust guy" (emulation has its points, performance under scaling being high on the list), but there are reasons to want to use host windows too. I would hesitate to remove this too quickly, unless Pinesoft tells us there is a better way to meet the objective. Compression probably does not need to be in the kernel, but IMHO it does belong in Pharo 1.0. Ditto sounds. Sound is something that people will expect in a well-rounded system. I'm all for cleaning out cruft, but things that are part of the releases are probably more likely to get seen, used, and therefore have bugs detected. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Monday, March 16, 2009 4:21 PM To: Pharo Development Subject: [Pharo-project] Removing more classes from Pharo 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Schwab,Wilhelm K wrote:
Ffenestri is a possible route to host windows. I am *not* a "native widgets or bust guy" (emulation has its points, performance under scaling being high on the list), but there are reasons to want to use host windows too. I would hesitate to remove this too quickly,
And using host windows doesn't mean you need to use native widgets, so it isn't an all or nothing question. Using just what is already there I managed to work with multiple host windows and Rome in some experimental hacking, so we should definitely work towards keeping/supporting this core FFenestri functionality. Michael
Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, March 17, 2009 1:13 AM Subject: Re: [Pharo-project] Removing more classes from Pharo
Ffenestri is a possible route to host windows. I am *not* a "native widgets or bust guy" (emulation has its points, performance under scaling being high on the list), but there are reasons to want to use host windows too. I would hesitate to remove this too quickly, unless Pinesoft tells us there is a better way to meet the objective.
Compression probably does not need to be in the kernel, but IMHO it does belong in Pharo 1.0. Ditto sounds. Sound is something that people will expect in a well-rounded system.
Zip compression is required by Monticello, of course ;-)
I'm all for cleaning out cruft, but things that are part of the releases are probably more likely to get seen, used, and therefore have bugs detected.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Monday, March 16, 2009 4:21 PM To: Pharo Development Subject: [Pharo-project] Removing more classes from Pharo
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The problem is that we should work that way - make a package unloadable/loadable - since we are still fixing a lot the packages should be loaded when we do change (else they will rot). - but first I would go for the closure image
- 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) if unused then we should remove them
- 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (10)
-
Adrian Lienhard -
Alexandre Bergel -
Gary Chambers -
John M McIntosh -
Lukas Renggli -
Michael Rueger -
Pavel Krivanek -
Rob Rothwell -
Schwab,Wilhelm K -
Stéphane Ducasse