I just realized that this *is* the script from Pharo. I think you need
to carefully check what is applicable for Squeak since I was quite aggressive with respect to deleting objects -- especially bitmaps that we don't need in Pharo anymore but that you may still need in Squeak (e.g., for EToys). > Great List John! I didn't realise that there were so many more. 96 > Classes now respond to #cleanUp in my image. > > http://bugs.squeak.org/view.php?id=7244 > > I added the following to the change set there. > > Keith > >>> 3 timesRepeat: [ Smalltalk garbageCollect. Symbol >>> compactSymbolTable ]. >>> Set rehashAllSets. > does this save memory? yes it does ;) Cheers, Adrian |
In reply to this post by keith1y
ok, got it.
Is there a way to load all the changes at once and/or get a list of the changes that are planned to go into 3.11? Adrian On Feb 12, 2009, at 17:13 , Keith Hodges wrote: > >> Again, what do I miss? I guess, I somehow have to build this image, >> right? How are others supposed to reuse if there is not even a >> prebuilt image linked on the website ready to look into what you did? > > Dear Adrian, > > Ok, sorry I understand what you are saying. > > with LevelPlayingField, and 3.11 we plan the tasks we want to have > included in the image in advance. Then fill in the details. Since > LevelPlayingField applies to any image you want it to, there is no > image > for you to down load with it in. Nevertheless LPF has been around > for a > while. > > There is an image in the 3.11 ftp area called 3.10.2bc which is > essentially 3.10.2+LPF+Sake/Packages > > For this fix all you have to do is Installer mantis ensureFix: 7244. > > I will be updating it shortly, with John's great contributions > > Keith > |
Adrian Lienhard wrote:
> ok, got it. > > Is there a way to load all the changes at once and/or get a list of > the changes that are planned to go into 3.11? > > Adrian There is a set of tasks in the Tasks package that highlighted about 100 fixes. However this is looking a bit untidy, and is being replaced by a new system. In mantis there are two new "status" levels, "testing" and "pending". If you add an installer script to a bug report, switch the status to "pending". If you feel that that fix is ready to be included in 3.11 switch the status to "testing". All of the status - "testing" fixes will go into the 3.11-test-candidate image when Bob performs the next build. All of the status - "resolved" fixes fixed in "3.11" fixes will go into the 3.11-release-candidate. So you can both contribute to and determine what is due to go into 3.11 by querying mantis. == So if you want to see what fixes are in 3.10-build-candidate, search in mantis for fixes with status "resolved" - and fixed in - "3.10bc" regards Keith |
In reply to this post by johnmci
John M McIntosh wrote:
> Ok, there still are a few more subclasses in the MC hierarchy that > need cleanup, one that deals with cached file based repositories for > example. > However when dealing with the cleanup code likely it could be class > allsubclasses do: kind of method. > If you implement #cleanUp in a class, then it will be called on all subclasses anyway. > Also PackageOrganizer seems to hold onto something. The plan is for PackageOrganizer to be the master list of loaded packages. So that you could remove Sake/Packages, SqueakMap, Universes and Monticello and the system would retain sufficient knowledge of what is loaded to be useful, should you choose to reload any of the above. cheers Keith |
In reply to this post by cdavidshaffer
C. David Shaffer wrote:
> Keith Hodges wrote: > >> For this fix all you have to do is Installer mantis ensureFix: 7244. >> >> I will be updating it shortly, with John's great contributions >> >> Keith >> >> > OK, you piqued my interest. FYI If I start with a > Squeak3.9.1-final-7075 image, install LPF, apply this "fix" and then do: > > SmalltalkImage current cleanUpAll > > I get the attached walkback. I haven't investigated it any further. > > inclusion in 3.10.2, I am all in favour of supporting others where possible. The latest version of 7422 has now been tested in 3.9 as well. thanks again Keith |
In reply to this post by keith1y
Keith Hodges wrote:
> MC1.5 has a "trim ancestry" menu item in the right hand column of the > monticello browser. To get the ancestry back just reload the package, so > it is really redundant in a deployed image. Or programatically: MCWorkingCopy allInstancesDo: [ : wc | wc ancestry ifNotNil: [ wc ancestry trimAfterVersionInfo: (wc ancestry). ]]. MCFileBasedRepository flushAllCaches. We also use this for deployment: PartsBin initialize. "I.e. without all the thumbnailing registries." PaintBoxMorph initialize. (PaintBoxMorph bindingOf: #Prototype) value: nil "Hangs on to a bunch of color forms" Cheers, - Andreas |
In reply to this post by johnmci
Also from Ramon Leon:
Squeak Smalltalk Image Maintenance <http://onsmalltalk.com/squeak-smalltalk-image-maintenance> Ken G. Brown At 4:01 AM -0800 2/12/09, [hidden email] apparently wrote: >Date: Wed, 11 Feb 2009 21:13:50 -0800 >From: John M McIntosh <[hidden email]> >Subject: Re: [squeak-dev] ditching Monticello objects. >To: Keith Hodges <[hidden email]> >Cc: The general-purpose Squeak developers list > <[hidden email]> >Message-ID: > <[hidden email]> >Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > >Ok, well I did > >I've been collecting lists of pruning methods so.. > > ScrollBar initializeImagesCache. > GradientFillStyle initPixelRampCache. > NaturalLanguageFormTranslator classPool at: #CachedTranslations put: >nil. > NaturalLanguageTranslator resetCaches. > PartsBin clearThumbnailCache. > PaintBoxMorph classPool at: #ColorChart put: nil. > PaintBoxMorph classPool at: #Prototype put: nil. > ImageMorph classPool at: #DefaultForm put: (Form extent: 1@1 depth: 1). > Utilities classPool at: #ScrapsBook put: nil. > Project allInstancesDo: [ :each | each setThumbnail: nil ]. > ScriptingSystem stripGraphicsForExternalRelease. > ProjectHistory currentHistory initialize. > Utilities zapUpdateDownloader. > Smalltalk forgetDoIts. > Behavior flushObsoleteSubclasses. > CommandHistory allInstancesDo: #initialize. > ChangeSorter removeChangeSetsNamedSuchThat: [ :each | true ]. > ChangeSet resetCurrentToNewUnnamedChangeSet. > MethodChangeRecord allInstancesDo: [ :x | x noteNewMethod: nil ]. > RequiredSelectors initialize. > ProvidedSelectors initialize. > LocalSends initialize. > SendCaches initializeAllInstances. > Utilities cleanseOtherworldlySteppers. > Smalltalk organization removeEmptyCategories. > Browser initialize. > SMSqueakMap default purge. > SystemBrowser removeObsolete. > TheWorldMenu removeObsolete. > AppRegistry removeObsolete. > FileServices removeObsolete. > MCFileBasedRepository flushAllCaches. > MCDefinition clearInstances. > Undeclared removeUnreferencedKeys. > Smalltalk flushClassNameCache. > 3 timesRepeat: [ Smalltalk garbageCollect. Symbol compactSymbolTable ]. > Set rehashAllSets. > Smalltalk garbageCollect. > > > >I added these ones. > > ChangeSorter initializeChangeSetCategories. > MCWorkingCopy inspect. > MCRepositoryGroup inspect. > MCCacheRepository inspect. > >and cleaned up the class instance variables & any class vars via the >inspect. > >That removed all the MC packages and MC http repositories from the MC >Browser > >gave me back 4 megabytes of image space. > >Well brute force, still 4 mb wonderful to get back this late in the >project. > > >On 11-Feb-09, at 6:18 PM, Keith Hodges wrote: > >> John M McIntosh wrote: >>> I'm building an image for a limited memory hardware platform. >>> >>> At the point here where I want to *deploy* things and I can see that >>> various parts of Monticello >>> are consuming well over a megabyte of memory to retain MCVersionInfo >>> instances, MCMethodDefinition(s), time stamps, uuids, etc etc >>> >>> I'm wondering if anyone has some code to strip all that out thus >>> returning I suspect a couple of MB back for more constructive usage? >> You may want to look into the cleanUp/freeSomeSpace conventions. MC1.5 >> has a few implemented. There are many more available from >> http://bugs.squeak.org/view.php?id=7244 >> >> Keith > >-- >= >= >= >======================================================================== >John M. McIntosh <[hidden email]> >Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >= >= >= >======================================================================== |
In reply to this post by keith1y
Keith Hodges wrote:
> > Thanks for the feedback, though this particular fix was aiming for > inclusion in 3.10.2, I am all in favour of supporting others where possible. > > The latest version of 7422 has now been tested in 3.9 as well. > > thanks again > Cool, thanks Keith. I just tested it and it worked fine. David |
In reply to this post by Edgar J. De Cleene-2
If this is what you think...
and you want to get frustrated by that fact this is your choice. But if you read http://www.pharo-project.org then you will see that we will do something else and that our goals are wider. Stef > > > > > On 2/12/09 12:15 PM, "Keith Hodges" <[hidden email]> wrote: > >> What is the point? >> >> Keith > > To prove they also could shrink a image, not matter how many of us > do same > before > > Edgar > > > > > |
On 2/14/09 10:38 AM, "stephane ducasse" <[hidden email]> wrote: > If this is what you think... > and you want to get frustrated by that fact this is your choice. > But if you read http://www.pharo-project.org then you will see that we > will > do something else and that our goals are wider. > > Stef To bad you have the power and decide to use for Squeak weeks... Facts was Pharo exist because Squeak. Believe all is web ? This days we have Aida and Pier and Seaside with his own image too. Facts as we facing the Big Bang effect, as I said many moons ago. And like the whole real Universe, all end in sky without stars and the cold rule forever. Edgar , Advocatus Diaboli and Defensor del Pueblo. |
Free forum by Nabble | Edit this page |