Major shrinks

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Major shrinks

Mariano Martinez Peck
Hi folks. I was playing a bit trying to shrink a little a PharoCore image. My idea was to think a shrink that was be acceptable for the most common scenario: a runtime (production) environment where. Of course, some of the things I do in the shrinks has side effects, but most of the times, you can deal with that in such scenarios.

Some of the things came from my mind, others from an OLD version of SystemDictionary >> majorShrink, others from Pavel's PharoKernel, etc.

So...I will post the little code here. I am not completely sure about the side effects of each piece, so if you know, please let me know :)

On the other hand, I wanted to ask you if you think something of this make sense to be part of ScriptLoader >> cleanUpForProduction

Taking a PharoCore 1.1  11277  of 13 MB   I get an image of 9 MB...so 4 MB less and I can still even browse code.
When running the image before the shrink I get 25MB in use and with the image shrinked I get 20MB.

Cheers

Mariano





"Compact all MethodDictionary instances"

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



"To put all all classes with the default category. Still can browse and recompile the whole image.
Most production enviroments don't care about categories...this make sense when developing."

Smalltalk allClassesAndTraitsDo: [:each | each zapOrganization ].


"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 resetCurrentToNewUnnamedChangeSet.
ChangeSet current initialize.
    ChangeSet classPool
        at: #AllChangeSets
        put: (OrderedCollection with: ChangeSet current).

Symbol rehash.

3 timesRepeat: [ Smalltalk garbageCollect. Symbol compactSymbolTable ].


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Major shrinks

Lukas Renggli
What I do on my build server is to unload the tests:

(MCWorkingCopy allManagers
        inject: Gofer new
        into: [ :gofer :each |
                ((each packageName endsWith: 'Test') or: [ each
packageName endsWith: 'Tests' ])
                        ifTrue: [ gofer package: each packageName ].
                gofer ])
        unload.

> Hi folks. I was playing a bit trying to shrink a little a PharoCore image.
> My idea was to think a shrink that was be acceptable for the most common
> scenario: a runtime (production) environment where. Of course, some of the
> things I do in the shrinks has side effects, but most of the times, you can
> deal with that in such scenarios.

Shouldn't most of the code you publish be part of the <cleanup> protocol?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Major shrinks

Mariano Martinez Peck


On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli <[hidden email]> wrote:
What I do on my build server is to unload the tests:

(MCWorkingCopy allManagers
       inject: Gofer new
       into: [ :gofer :each |
               ((each packageName endsWith: 'Test') or: [ each
packageName endsWith: 'Tests' ])
                       ifTrue: [ gofer package: each packageName ].
               gofer ])
       unload.


ScriptLoader >> cleanUpForProduction   do that but similary:

#(#Tests #CollectionsTests #CompilerTests #FreeTypeTests #GraphicsTests #KernelTests #MorphicTests #MultilingualTests #NetworkTests #ToolsTest)
        do: [ :each | (MCPackage named: each) unload ].    "unload SUnit"
    Smalltalk globals
        at: #TestCase
        ifPresent: [ :class | SystemChangeNotifier uniqueInstance noMoreNotificationsFor: class ].
    #(#SUnitGUI #SUnit) do: [ :each | (MCPackage named: each) unload ].


Maybe we you should change it ?

 
> Hi folks. I was playing a bit trying to shrink a little a PharoCore image.
> My idea was to think a shrink that was be acceptable for the most common
> scenario: a runtime (production) environment where. Of course, some of the
> things I do in the shrinks has side effects, but most of the times, you can
> deal with that in such scenarios.

Shouldn't most of the code you publish be part of the <cleanup> protocol?


You refere to the "new" cleanUp protocol ?

The thing is that not everything is a cleanUp, but a shrink. Suppose the code that zap all the organizations...that's not a cleanUp.
So, maybe yes, but not all of them.

Cheers

Mariano
 
 
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Major shrinks

Adrian Lienhard
In reply to this post by Mariano Martinez Peck
Hi Mariano,

Great to see further progress on this! I'll take a closer look at your script this evening. But what I wonder is why PharoCore 1.1 is so big and you only get down to 9MB (is this the size on disk?)?

In a PharoCore 1.0 running #cleanUpForRelease, #cleanUpForProduction, deleting the class ScriptLoader and all changesets I get an image that is 8.1MB on disk.

Cheers,
Adrian


On Mar 23, 2010, at 10:15 , Mariano Martinez Peck wrote:

> Hi folks. I was playing a bit trying to shrink a little a PharoCore image.
> My idea was to think a shrink that was be acceptable for the most common
> scenario: a runtime (production) environment where. Of course, some of the
> things I do in the shrinks has side effects, but most of the times, you can
> deal with that in such scenarios.
>
> Some of the things came from my mind, others from an OLD version of
> SystemDictionary >> majorShrink, others from Pavel's PharoKernel, etc.
>
> So...I will post the little code here. I am not completely sure about the
> side effects of each piece, so if you know, please let me know :)
>
> On the other hand, I wanted to ask you if you think something of this make
> sense to be part of ScriptLoader >> cleanUpForProduction
>
> Taking a PharoCore 1.1  11277  of 13 MB   I get an image of 9 MB...so 4 MB
> less and I can still even browse code.
> When running the image before the shrink I get 25MB in use and with the
> image shrinked I get 20MB.
>
> Cheers
>
> Mariano
>
>
>
>
>
> "Compact all MethodDictionary instances"
>
> | oldInstances newInstances |
> oldInstances := MethodDictionary allInstances.
> newInstances := oldInstances collect:
>                    [ :md |
>                        (MethodDictionary new: md size)
>                            compactCopyFrom: md;
>                            yourself].
>
> oldInstances elementsForwardIdentityTo: newInstances.
>
>
>
> "To put all all classes with the default category. Still can browse and
> recompile the whole image.
> Most production enviroments don't care about categories...this make sense
> when developing."
>
> Smalltalk allClassesAndTraitsDo: [:each | each zapOrganization ].
>
>
> "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 resetCurrentToNewUnnamedChangeSet.
> ChangeSet current initialize.
>    ChangeSet classPool
>        at: #AllChangeSets
>        put: (OrderedCollection with: ChangeSet current).
>
> Symbol rehash.
>
> 3 timesRepeat: [ Smalltalk garbageCollect. Symbol compactSymbolTable ].
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Major shrinks

Mariano Martinez Peck


On Tue, Mar 23, 2010 at 10:29 AM, Adrian Lienhard <[hidden email]> wrote:
Hi Mariano,

Great to see further progress on this! I'll take a closer look at your script this evening. But what I wonder is why PharoCore 1.1 is so big

I asked that myself. I even think I already asked that in mailing list. Honestly, I don't know.
 
and you only get down to 9MB (is this the size on disk?)?

yes.
 

In a PharoCore 1.0 running #cleanUpForRelease, #cleanUpForProduction, deleting the class ScriptLoader and all changesets I get an image that is 8.1MB on disk.

yes. Ahh be aware....cleanUpForProduction in 1.1 is cool: he kill himself (unload the package ScriptLoader) at the end of the cleanUp ;)
 

Cheers,
Adrian


On Mar 23, 2010, at 10:15 , Mariano Martinez Peck wrote:

> Hi folks. I was playing a bit trying to shrink a little a PharoCore image.
> My idea was to think a shrink that was be acceptable for the most common
> scenario: a runtime (production) environment where. Of course, some of the
> things I do in the shrinks has side effects, but most of the times, you can
> deal with that in such scenarios.
>
> Some of the things came from my mind, others from an OLD version of
> SystemDictionary >> majorShrink, others from Pavel's PharoKernel, etc.
>
> So...I will post the little code here. I am not completely sure about the
> side effects of each piece, so if you know, please let me know :)
>
> On the other hand, I wanted to ask you if you think something of this make
> sense to be part of ScriptLoader >> cleanUpForProduction
>
> Taking a PharoCore 1.1  11277  of 13 MB   I get an image of 9 MB...so 4 MB
> less and I can still even browse code.
> When running the image before the shrink I get 25MB in use and with the
> image shrinked I get 20MB.
>
> Cheers
>
> Mariano
>
>
>
>
>
> "Compact all MethodDictionary instances"
>
> | oldInstances newInstances |
> oldInstances := MethodDictionary allInstances.
> newInstances := oldInstances collect:
>                    [ :md |
>                        (MethodDictionary new: md size)
>                            compactCopyFrom: md;
>                            yourself].
>
> oldInstances elementsForwardIdentityTo: newInstances.
>
>
>
> "To put all all classes with the default category. Still can browse and
> recompile the whole image.
> Most production enviroments don't care about categories...this make sense
> when developing."
>
> Smalltalk allClassesAndTraitsDo: [:each | each zapOrganization ].
>
>
> "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 resetCurrentToNewUnnamedChangeSet.
> ChangeSet current initialize.
>    ChangeSet classPool
>        at: #AllChangeSets
>        put: (OrderedCollection with: ChangeSet current).
>
> Symbol rehash.
>
> 3 timesRepeat: [ Smalltalk garbageCollect. Symbol compactSymbolTable ].
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Major shrinks

Stéphane Ducasse
In reply to this post by Mariano Martinez Peck
mariano

cleanUp: true
support agrresive cleanup = "shrink"

On Mar 23, 2010, at 10:24 AM, Mariano Martinez Peck wrote:

>
>
> On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli <[hidden email]> wrote:
> What I do on my build server is to unload the tests:
>
> (MCWorkingCopy allManagers
>        inject: Gofer new
>        into: [ :gofer :each |
>                ((each packageName endsWith: 'Test') or: [ each
> packageName endsWith: 'Tests' ])
>                        ifTrue: [ gofer package: each packageName ].
>                gofer ])
>        unload.
>
>
> ScriptLoader >> cleanUpForProduction   do that but similary:
>
> #(#Tests #CollectionsTests #CompilerTests #FreeTypeTests #GraphicsTests #KernelTests #MorphicTests #MultilingualTests #NetworkTests #ToolsTest)
>         do: [ :each | (MCPackage named: each) unload ].    "unload SUnit"
>     Smalltalk globals
>         at: #TestCase
>         ifPresent: [ :class | SystemChangeNotifier uniqueInstance noMoreNotificationsFor: class ].
>     #(#SUnitGUI #SUnit) do: [ :each | (MCPackage named: each) unload ].
>
>
> Maybe we you should change it ?
>
>  
> > Hi folks. I was playing a bit trying to shrink a little a PharoCore image.
> > My idea was to think a shrink that was be acceptable for the most common
> > scenario: a runtime (production) environment where. Of course, some of the
> > things I do in the shrinks has side effects, but most of the times, you can
> > deal with that in such scenarios.
>
> Shouldn't most of the code you publish be part of the <cleanup> protocol?
>
>
> You refere to the "new" cleanUp protocol ?
>
> The thing is that not everything is a cleanUp, but a shrink. Suppose the code that zap all the organizations...that's not a cleanUp.
> So, maybe yes, but not all of them.
>
> Cheers
>
> Mariano
>  
>  
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Major shrinks

Mariano Martinez Peck


On Tue, Mar 23, 2010 at 1:52 PM, Stéphane Ducasse <[hidden email]> wrote:
mariano

cleanUp: true
support agrresive cleanup = "shrink"


Thanks...I didn't know.  So...instead of cleanUp: aBoolean   why not to have a method called shrink ?  or something better that someone can think :)

Cheers

Mariano

 
On Mar 23, 2010, at 10:24 AM, Mariano Martinez Peck wrote:

>
>
> On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli <[hidden email]> wrote:
> What I do on my build server is to unload the tests:
>
> (MCWorkingCopy allManagers
>        inject: Gofer new
>        into: [ :gofer :each |
>                ((each packageName endsWith: 'Test') or: [ each
> packageName endsWith: 'Tests' ])
>                        ifTrue: [ gofer package: each packageName ].
>                gofer ])
>        unload.
>
>
> ScriptLoader >> cleanUpForProduction   do that but similary:
>
> #(#Tests #CollectionsTests #CompilerTests #FreeTypeTests #GraphicsTests #KernelTests #MorphicTests #MultilingualTests #NetworkTests #ToolsTest)
>         do: [ :each | (MCPackage named: each) unload ].    "unload SUnit"
>     Smalltalk globals
>         at: #TestCase
>         ifPresent: [ :class | SystemChangeNotifier uniqueInstance noMoreNotificationsFor: class ].
>     #(#SUnitGUI #SUnit) do: [ :each | (MCPackage named: each) unload ].
>
>
> Maybe we you should change it ?
>
>
> > Hi folks. I was playing a bit trying to shrink a little a PharoCore image.
> > My idea was to think a shrink that was be acceptable for the most common
> > scenario: a runtime (production) environment where. Of course, some of the
> > things I do in the shrinks has side effects, but most of the times, you can
> > deal with that in such scenarios.
>
> Shouldn't most of the code you publish be part of the <cleanup> protocol?
>
>
> You refere to the "new" cleanUp protocol ?
>
> The thing is that not everything is a cleanUp, but a shrink. Suppose the code that zap all the organizations...that's not a cleanUp.
> So, maybe yes, but not all of them.
>
> Cheers
>
> Mariano
>
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Major shrinks

Marcus Denker-4
In reply to this post by Adrian Lienhard

On Mar 23, 2010, at 10:29 AM, Adrian Lienhard wrote:

> Hi Mariano,
>
> Great to see further progress on this! I'll take a closer look at your script this evening. But what I wonder is why PharoCore 1.1 is so big and you only get down to 9MB (is this the size on disk?)?
>
> In a PharoCore 1.0 running #cleanUpForRelease, #cleanUpForProduction, deleting the class ScriptLoader and all changesets I get an image that is 8.1MB on disk.

In 1.1, I get 7.6MB.

-> I added cleanUpForRelease as the last call before deleting the package in cleanUpForProduction.
-> I added the code code to empty the changeset after that.

(I will put these fixes with Mariano's and Noury's (related to the logo) into the release today)

Cleaning the changesets is *important* as they hold on to a lot of stuff...

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Major shrinks

Adrian Lienhard

On Mar 23, 2010, at 14:53 , Marcus Denker wrote:

>
> On Mar 23, 2010, at 10:29 AM, Adrian Lienhard wrote:
>
>> Hi Mariano,
>>
>> Great to see further progress on this! I'll take a closer look at your script this evening. But what I wonder is why PharoCore 1.1 is so big and you only get down to 9MB (is this the size on disk?)?
>>
>> In a PharoCore 1.0 running #cleanUpForRelease, #cleanUpForProduction, deleting the class ScriptLoader and all changesets I get an image that is 8.1MB on disk.
>
> In 1.1, I get 7.6MB.
>
> -> I added cleanUpForRelease as the last call before deleting the package in cleanUpForProduction.
> -> I added the code code to empty the changeset after that.
>
> (I will put these fixes with Mariano's and Noury's (related to the logo) into the release today)
>
> Cleaning the changesets is *important* as they hold on to a lot of stuff...

Cool! We should also not forget to add and run the changeset cleaning to 1.0 before the release.

Adrian

>
> Marcus
>
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Major shrinks

Miguel Cobá
In reply to this post by Mariano Martinez Peck
El mar, 23-03-2010 a las 13:56 +0100, Mariano Martinez Peck escribió:

>
>
> On Tue, Mar 23, 2010 at 1:52 PM, Stéphane Ducasse
> <[hidden email]> wrote:
>         mariano
>        
>         cleanUp: true
>         support agrresive cleanup = "shrink"
>        
>        
>        
>
> Thanks...I didn't know.  So...instead of cleanUp: aBoolean   why not
> to have a method called shrink ?  or something better that someone can
> think :)

Because not only shrinks the image, but also does other clean up tasks
like resetting caches and similar. They have a shrink effect, but mainly
are for cleaning things for example for release.


>
> Cheers
>
> Mariano
>
>  
>         On Mar 23, 2010, at 10:24 AM, Mariano Martinez Peck wrote:
>        
>         >
>         >
>         > On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli
>         <[hidden email]> wrote:
>         > What I do on my build server is to unload the tests:
>         >
>         > (MCWorkingCopy allManagers
>         >        inject: Gofer new
>         >        into: [ :gofer :each |
>         >                ((each packageName endsWith: 'Test') or:
>         [ each
>         > packageName endsWith: 'Tests' ])
>         >                        ifTrue: [ gofer package: each
>         packageName ].
>         >                gofer ])
>         >        unload.
>         >
>         >
>         > ScriptLoader >> cleanUpForProduction   do that but similary:
>         >
>         > #(#Tests #CollectionsTests #CompilerTests #FreeTypeTests
>         #GraphicsTests #KernelTests #MorphicTests #MultilingualTests
>         #NetworkTests #ToolsTest)
>         >         do: [ :each | (MCPackage named: each) unload ].
>          "unload SUnit"
>         >     Smalltalk globals
>         >         at: #TestCase
>         >         ifPresent: [ :class | SystemChangeNotifier
>         uniqueInstance noMoreNotificationsFor: class ].
>         >     #(#SUnitGUI #SUnit) do: [ :each | (MCPackage named:
>         each) unload ].
>         >
>         >
>         > Maybe we you should change it ?
>         >
>         >
>         > > Hi folks. I was playing a bit trying to shrink a little a
>         PharoCore image.
>         > > My idea was to think a shrink that was be acceptable for
>         the most common
>         > > scenario: a runtime (production) environment where. Of
>         course, some of the
>         > > things I do in the shrinks has side effects, but most of
>         the times, you can
>         > > deal with that in such scenarios.
>         >
>         > Shouldn't most of the code you publish be part of the
>         <cleanup> protocol?
>         >
>         >
>         > You refere to the "new" cleanUp protocol ?
>         >
>         > The thing is that not everything is a cleanUp, but a shrink.
>         Suppose the code that zap all the organizations...that's not a
>         cleanUp.
>         > So, maybe yes, but not all of them.
>         >
>         > Cheers
>         >
>         > Mariano
>         >
>         >
>         > Lukas
>         >
>         > --
>         > Lukas Renggli
>         > http://www.lukas-renggli.ch
>         >
>         > _______________________________________________
>         > Pharo-project mailing list
>         > [hidden email]
>         >
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>         >
>         > _______________________________________________
>         > Pharo-project mailing list
>         > [hidden email]
>         >
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>        
>        
>         _______________________________________________
>         Pharo-project mailing list
>         [hidden email]
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>        
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Major shrinks

Mariano Martinez Peck


2010/3/23 Miguel Enrique Cobá Martinez <[hidden email]>
El mar, 23-03-2010 a las 13:56 +0100, Mariano Martinez Peck escribió:
>
>
> On Tue, Mar 23, 2010 at 1:52 PM, Stéphane Ducasse
> <[hidden email]> wrote:
>         mariano
>
>         cleanUp: true
>         support agrresive cleanup = "shrink"
>
>
>
>
> Thanks...I didn't know.  So...instead of cleanUp: aBoolean   why not
> to have a method called shrink ?  or something better that someone can
> think :)

Because not only shrinks the image, but also does other clean up tasks
like resetting caches and similar. They have a shrink effect, but mainly
are for cleaning things for example for release.

You didn't understand me. When not to call it agressiveClean instead of having a fac.. boolean and having to do
 aBoolean ifTrue: [ blah blag]  ifFalse: [ blah blah blah]

There is something I don't see ? I would have:

cleanUp

agressiveCleanUp

where this last one, may call cleanUp too
 


>
> Cheers
>
> Mariano
>
>
>         On Mar 23, 2010, at 10:24 AM, Mariano Martinez Peck wrote:
>
>         >
>         >
>         > On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli
>         <[hidden email]> wrote:
>         > What I do on my build server is to unload the tests:
>         >
>         > (MCWorkingCopy allManagers
>         >        inject: Gofer new
>         >        into: [ :gofer :each |
>         >                ((each packageName endsWith: 'Test') or:
>         [ each
>         > packageName endsWith: 'Tests' ])
>         >                        ifTrue: [ gofer package: each
>         packageName ].
>         >                gofer ])
>         >        unload.
>         >
>         >
>         > ScriptLoader >> cleanUpForProduction   do that but similary:
>         >
>         > #(#Tests #CollectionsTests #CompilerTests #FreeTypeTests
>         #GraphicsTests #KernelTests #MorphicTests #MultilingualTests
>         #NetworkTests #ToolsTest)
>         >         do: [ :each | (MCPackage named: each) unload ].
>          "unload SUnit"
>         >     Smalltalk globals
>         >         at: #TestCase
>         >         ifPresent: [ :class | SystemChangeNotifier
>         uniqueInstance noMoreNotificationsFor: class ].
>         >     #(#SUnitGUI #SUnit) do: [ :each | (MCPackage named:
>         each) unload ].
>         >
>         >
>         > Maybe we you should change it ?
>         >
>         >
>         > > Hi folks. I was playing a bit trying to shrink a little a
>         PharoCore image.
>         > > My idea was to think a shrink that was be acceptable for
>         the most common
>         > > scenario: a runtime (production) environment where. Of
>         course, some of the
>         > > things I do in the shrinks has side effects, but most of
>         the times, you can
>         > > deal with that in such scenarios.
>         >
>         > Shouldn't most of the code you publish be part of the
>         <cleanup> protocol?
>         >
>         >
>         > You refere to the "new" cleanUp protocol ?
>         >
>         > The thing is that not everything is a cleanUp, but a shrink.
>         Suppose the code that zap all the organizations...that's not a
>         cleanUp.
>         > So, maybe yes, but not all of them.
>         >
>         > Cheers
>         >
>         > Mariano
>         >
>         >
>         > Lukas
>         >
>         > --
>         > Lukas Renggli
>         > http://www.lukas-renggli.ch
>         >
>         > _______________________________________________
>         > Pharo-project mailing list
>         > [hidden email]
>         >
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>         >
>         > _______________________________________________
>         > Pharo-project mailing list
>         > [hidden email]
>         >
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>         _______________________________________________
>         Pharo-project mailing list
>         [hidden email]
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Major shrinks

Miguel Cobá
El mar, 23-03-2010 a las 15:04 +0100, Mariano Martinez Peck escribió:

>
>
> 2010/3/23 Miguel Enrique Cobá Martinez <[hidden email]>
>         El mar, 23-03-2010 a las 13:56 +0100, Mariano Martinez Peck
>         escribió:
>         >
>         >
>         > On Tue, Mar 23, 2010 at 1:52 PM, Stéphane Ducasse
>         > <[hidden email]> wrote:
>         >         mariano
>         >
>         >         cleanUp: true
>         >         support agrresive cleanup = "shrink"
>         >
>         >
>         >
>         >
>         > Thanks...I didn't know.  So...instead of cleanUp: aBoolean
>         why not
>         > to have a method called shrink ?  or something better that
>         someone can
>         > think :)
>        
>        
>         Because not only shrinks the image, but also does other clean
>         up tasks
>         like resetting caches and similar. They have a shrink effect,
>         but mainly
>         are for cleaning things for example for release.
>
> You didn't understand me. When not to call it agressiveClean instead
> of having a fac.. boolean and having to do
>  aBoolean ifTrue: [ blah blag]  ifFalse: [ blah blah blah]
>
> There is something I don't see ? I would have:
>
> cleanUp
>
> agressiveCleanUp
>
> where this last one, may call cleanUp too
>  

Oh, I see. No idea, that is how Keith (I think) and Andreas proposed the
change for Squeak that Stef applied to Pharo. :)

Cheers

>        
>        
>        
>         >
>         > Cheers
>         >
>         > Mariano
>         >
>         >
>         >         On Mar 23, 2010, at 10:24 AM, Mariano Martinez Peck
>         wrote:
>         >
>         >         >
>         >         >
>         >         > On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli
>         >         <[hidden email]> wrote:
>         >         > What I do on my build server is to unload the
>         tests:
>         >         >
>         >         > (MCWorkingCopy allManagers
>         >         >        inject: Gofer new
>         >         >        into: [ :gofer :each |
>         >         >                ((each packageName endsWith:
>         'Test') or:
>         >         [ each
>         >         > packageName endsWith: 'Tests' ])
>         >         >                        ifTrue: [ gofer package:
>         each
>         >         packageName ].
>         >         >                gofer ])
>         >         >        unload.
>         >         >
>         >         >
>         >         > ScriptLoader >> cleanUpForProduction   do that but
>         similary:
>         >         >
>         >         > #(#Tests #CollectionsTests #CompilerTests
>         #FreeTypeTests
>         >         #GraphicsTests #KernelTests #MorphicTests
>         #MultilingualTests
>         >         #NetworkTests #ToolsTest)
>         >         >         do: [ :each | (MCPackage named: each)
>         unload ].
>         >          "unload SUnit"
>         >         >     Smalltalk globals
>         >         >         at: #TestCase
>         >         >         ifPresent: [ :class | SystemChangeNotifier
>         >         uniqueInstance noMoreNotificationsFor: class ].
>         >         >     #(#SUnitGUI #SUnit) do: [ :each | (MCPackage
>         named:
>         >         each) unload ].
>         >         >
>         >         >
>         >         > Maybe we you should change it ?
>         >         >
>         >         >
>         >         > > Hi folks. I was playing a bit trying to shrink a
>         little a
>         >         PharoCore image.
>         >         > > My idea was to think a shrink that was be
>         acceptable for
>         >         the most common
>         >         > > scenario: a runtime (production) environment
>         where. Of
>         >         course, some of the
>         >         > > things I do in the shrinks has side effects, but
>         most of
>         >         the times, you can
>         >         > > deal with that in such scenarios.
>         >         >
>         >         > Shouldn't most of the code you publish be part of
>         the
>         >         <cleanup> protocol?
>         >         >
>         >         >
>         >         > You refere to the "new" cleanUp protocol ?
>         >         >
>         >         > The thing is that not everything is a cleanUp, but
>         a shrink.
>         >         Suppose the code that zap all the
>         organizations...that's not a
>         >         cleanUp.
>         >         > So, maybe yes, but not all of them.
>         >         >
>         >         > Cheers
>         >         >
>         >         > Mariano
>         >         >
>         >         >
>         >         > Lukas
>         >         >
>         >         > --
>         >         > Lukas Renggli
>         >         > http://www.lukas-renggli.ch
>         >         >
>         >         > _______________________________________________
>         >         > Pharo-project mailing list
>         >         > [hidden email]
>         >         >
>         >
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>         >         >
>         >         > _______________________________________________
>         >         > Pharo-project mailing list
>         >         > [hidden email]
>         >         >
>         >
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>         >
>         >
>         >         _______________________________________________
>         >         Pharo-project mailing list
>         >         [hidden email]
>         >
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>         >
>         >
>         > _______________________________________________
>         > Pharo-project mailing list
>         > [hidden email]
>         >
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>        
>        
>         --
>         Miguel Cobá
>         http://miguel.leugim.com.mx
>        
>        
>        
>         _______________________________________________
>         Pharo-project mailing list
>         [hidden email]
>         http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Major shrinks

Marcus Denker-4
In reply to this post by Marcus Denker-4

On Mar 23, 2010, at 2:53 PM, Marcus Denker wrote:

>
> In 1.1, I get 7.6MB.
>
> -> I added cleanUpForRelease as the last call before deleting the package in cleanUpForProduction.
> -> I added the code code to empty the changeset after that.
>
> (I will put these fixes with Mariano's and Noury's (related to the logo) into the release today)
>
> Cleaning the changesets is *important* as they hold on to a lot of stuff...
>


In 11289:

        ScriptLoader new cleanUpForProduction

-->7.6 MB

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Major shrinks

Stéphane Ducasse
In reply to this post by Mariano Martinez Peck
> You didn't understand me. When not to call it agressiveClean instead of having a fac.. boolean and having to do
>  aBoolean ifTrue: [ blah blag]  ifFalse: [ blah blah blah]
>
> There is something I don't see ? I would have:
>
> cleanUp
>
> agressiveCleanUp
>
> where this last one, may call cleanUp too
>  
discuss with luc
and indeed it looks a bit over-engineered for what it does.

CleanUp and cleanUp are not connected have a look at the logic.
We are not bound to stick with it. If you have something better we can change without any problem.

Stef
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project