Re: [Pharo-users] Minimal pharo

Hi Annick. I don't know which image they told you, but if you take a PharoCore 1.1.1 from here:

http://www.pharo-project.org/pharo-download/stable-core

And you evaluate:

ScriptLoader new cleanUpForRelease.

And then save and quite, the image is 6.8 MB.

Another hack I sometimes do is o put all all classes with the default category. You can still can browse and recompile the whole image.
Most production enviroments don't care about categories...they make sense when developing. (not everybody agree).
But anyway, if you then evaluate:

Smalltalk allClassesAndTraitsDo: [:each | each zapOrganization ].
Symbol compactSymbolTable.
Smalltalk garbageCollect


Then the resulted image is 6.1 mb  ;)

If you then evaluate:



"Compact all MethodDictionary instances"

| oldInstances newInstances |
oldInstances := MethodDictionary allInstances.
newInstances := oldInstances collect:
                    [ :md |   
                        (MethodDictionary new: md size)
                            compactCopyFrom: md;
                            yourself].
                       
oldInstances elementsForwardIdentityTo: newInstances.

"Different cleanUps"

TextStyle
        allSubInstancesDo: [:ts | ts
                newFontArray: (ts fontArray
                        copyFrom: 1
                        to: (2 min: ts fontArray size))].

"Clean all Monticello related stuff. You won't be able to browse packages for example"

MCWorkingCopyBrowser allInstancesDo: [:each | each flushAllCaches ].
MCWorkingCopy allInstancesDo:[:wc| SystemChangeNotifier uniqueInstance noMoreNotificationsFor: wc. wc unregister].
SystemChangeNotifier uniqueInstance noMoreNotificationsFor: MCPackageManager.
SystemChangeNotifier uniqueInstance noMoreNotificationsFor: MCWorkingCopy.

"Most application don't need sound"

SoundService default: nil.
SoundService unregister: DummySoundSystem.

SystemChangeNotifier uniqueInstance noMoreNotificationsFor: (Smalltalk at: #RecentMessageSet).

TranscriptStream newTranscript: ThreadSafeTranscript new.

ImageSegment classPool at: #RecentlyRenamedClasses put: Dictionary new.
ExternalSettings classPool at: #RegisteredClients put: Set new.

Locale classPool at: #LocaleChangeListeners put: nil.

"Clean all the changes"

ChangeSet resetCurrentToNewUnnamedChange


You will have a 5.9 MB image :) 
is that enought?   If not, you can start unloading packages. Esteban did a lot of work with this of IPhone images.
You can ask him.

ps: I wonder if any of those scripts should be added to ScriptLoader


Cheers

Mariano

On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote:

> ps: I wonder if any of those scripts should be added to ScriptLoader

Yes, that would be good! Like this we can improve them and other people can contribute.

Esteban, could you share your experience with unloading packages? I assume you had to also reorganize packages to make them cleanly unloadable? If yes these changes should be integrated to improve the modularization.

Cheers,
Adrian

Hi all,

Hi,
I don't think my experience is really usable for general image shrinking. What I was doing is preparing images to run on the iPhone, and then I was cutting a lot of things needed in any other scenarios.
In fact, I named my "technic" as "brute shrinking" :P and what I was using was an adaptation of Pavel's experiments:

1) I run all the cleans provided on Pharo.
2) I change the morphic UI with a dummy one.
3) I remove lots of packages using package unloader (and I said: lots... any package I'm not using).
4) I remove lots of classes (again, any clearly not-used class remaining in not unloaded packages)
5) I remove lots of methods (using Pavel's listing, here)
6) finally I was removing even InputEventFetcher, etc. (no need for a iOS user interface, I'm processing the events in "other way")

with all this, my smallest image were about 4.1M... and it was working properly inside an iPhone :)

as you can see... it doesn't look like it is useful for real non-mars scenarios... I can provide the scripts, of course, if you still think it is useful.
and I thought on reorganize, taking into account all this drops, yes... but the experiments were aborted by the apple clause change... now solved, but no time to continue the work on it yet :)

Cheers,
Esteban


El 05/01/2011, a las 4:58a.m., Adrian Lienhard escribió:

Ah, I forgot to say the the general idea of my "brute shrinking" was opposite to Pavel's idea: Pavel's pharo kernel images is about to have a really tiny image and use that as a foundation to build major images. Mine is: having already a production image, I want to strip from image all things I'm not using, so my *final* image (not my starting image) is as small as possible.

Cheers,
Esteban

El 05/01/2011, a las 4:58a.m., Adrian Lienhard escribió:

send code :)


On Jan 5, 2011, at 9:16 AM, Luc Fabresse wrote:

Hi Esteban,

Yes, I know... So, how do you do the shrinking? ;)

Do you unload by package? If yes, are the remaining MC packages "clean" and there are no obsolete classes etc. in the resulting image?

Cheers,
Adrian

On Jan 5, 2011, at 13:21 , Esteban Lorenzano wrote: