July 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by phil＠highoctane.be

Doing the flushCaches... Image size before cleaning a MCSmalltalkhubRepository( http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324017564 Image size after cleaning a MCSmalltalkhubRepository( http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324137232 Image size before cleaning a MCSmalltalkhubRepository( http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324137232 Image size after cleaning a MCSmalltalkhubRepository( http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324195720 Image size before cleaning a MCSmalltalkhubRepository( http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324195720 Image size after cleaning a MCSmalltalkhubRepository( http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324255300 Image size before cleaning a MCSmalltalkhubRepository( http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : 324255300 Image size after cleaning a MCSmalltalkhubRepository( http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : 324314868 Definitely not going down... Phil On Wed, Jul 31, 2013 at 8:53 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > OK, this was was my experiment.... > > Image fresh with all my app and dependencies loades: 30MB > > After using it for some days/weeks: 160MB. > > SpaceTally new printSpaceAnalysis showed: > > Class code space # instances > inst space percent inst average size > ByteString 2785 413144 > 116244078 69.90 281.36 > Array 3712 181772 > 8466668 5.10 46.58 > ByteArray 8574 1319 > 8186802 4.90 6206.82 > Bitmap 3653 303 > 6656340 4.00 21968.12 > CompiledMethod 22467 90554 > 5685374 3.40 62.78 > > > After executing ImageCleaner cleanUpForRelease: 36MB > > Then...I searched which part of #cleanUpForRelease: was making the > difference, and it was: > > Smalltalk cleanUp: true except: #() confirming: false. > > So now it was time to know WHICH class did the diference, so I modified > #cleanUp: aggressive except: exclusions confirming: aBool > > in these lines: > > "Run the cleanup code" > classes > do:[:aClass| > Transcript show: 'Image size before cleaning ', aClass name, ' : ', > Smalltalk imagePath asFileReference size asString. > aClass cleanUp: aggressive. > 3 timesRepeat: [Smalltalk garbageCollect]. > Smalltalk snapshot: true andQuit: false. > Transcript show: 'Image size after cleaning ', aClass name, ' : ', > Smalltalk imagePath asFileReference size asString. > ] > displayingProgress: [:aClass| 'Cleaning up in ', aClass name]. > I then opened a Transcript, and evaluated > > Smalltalk cleanUp: true except: #() confirming: false. > > I went to prepare Mate, and when I come back, the result was, of course: > > "Image size after cleaning MCFileBasedRepository : 39744008" > > That clean up ends up doing: > > flushAllCaches > self allSubInstancesDo: [:ea | ea flushCache] > So it sends #flushCache to all instances of MCHttpRepository and > MCFileBasedRepository. > > Now what I wanted to see if it there was a particular repo that could take > most of the space (like package-cache). > And indeed, it was...I modified #flushCaches to: > > flushAllCaches > | file | > file := 'repos.txt' asFileReference writeStream text. > self allSubInstancesDo: [:each | > file nextPutAll: 'Image size before cleaning ', each printString, ' : ', > Smalltalk imagePath asFileReference size asString; cr. > each flushCache. > 3 timesRepeat: [Smalltalk garbageCollect]. > Smalltalk snapshot: true andQuit: false. > file nextPutAll: 'Image size after cleaning ', each printString, ' : ', > Smalltalk imagePath asFileReference size asString;cr. > ]. > file flush; close. > And then I looked in the 'repos.txt' file. My package cache repo cleaned > 60 MB. Glorp cleaned 35MB. Seaside30 cleaned 10MB. > So...cleaning cache of just 3 repos frees approx 100MB. > > The question is....can we flush the cache safely? If they are called > "cache", then I guess yes, we can. > > Thoughts? > > Thanks, > > > > On Wed, Jul 31, 2013 at 10:48 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Guys, I have images also with seaside, magritte, glorp, postgresV2, etc >> and it is also around 200MB. >> I will try to do some research today and let you know. >> >> Cheers, >> >> >> On Tue, Jul 30, 2013 at 8:55 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >> >>> >>> On Jul 30, 2013, at 1:49 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> >>> wrote: >>> >>> > the changes file contained passwords and I replaced the text. So >>> offsets may be wrong due to that. >>> > >>> Yes, the first thing I wanted to do is to recompile everything. Does not >>> work. >>> >>> > Memorymonitor is not doing fanct stuff. It just counts instances. >>> > >>> Yes, but maybe it holds on to these instances? >>> >>> Marcus >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com >

July 31, 2013

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by phil＠highoctane.be

Well, here is what I do get: (I guess some stuff scrolled up too far in the transcript) Image size before cleaning HashedCollection : 320691776----SNAPSHOT----an Array(1 August 2013 12:21:29 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119932535 Image size after cleaning HashedCollection : 323444020Image size before cleaning RecentMessageList : 323444020----SNAPSHOT----an Array(1 August 2013 12:21:46 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119936948 Image size after cleaning RecentMessageList : 323492924Image size before cleaning ChangeSet : 323492924----SNAPSHOT----an Array(1 August 2013 12:22:01 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119937094 Image size after cleaning ChangeSet : 323557656Image size before cleaning SystemOrganizer : 323557656----SNAPSHOT----an Array(1 August 2013 12:22:16 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119937240 Image size after cleaning SystemOrganizer : 323621024Image size before cleaning MCDefinition : 323621024----SNAPSHOT----an Array(1 August 2013 12:22:31 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119937386 Image size after cleaning MCDefinition : 323685312Image size before cleaning Behavior : 323685312----SNAPSHOT----an Array(1 August 2013 12:22:46 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119937532 Image size after cleaning Behavior : 323749188Image size before cleaning Workspace : 323749188----SNAPSHOT----an Array(1 August 2013 12:23:01 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119937678 Image size after cleaning Workspace : 323797016Image size before cleaning AppRegistry : 323797016----SNAPSHOT----an Array(1 August 2013 12:23:16 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119937824 Image size after cleaning AppRegistry : 323860980Image size before cleaning MCFileBasedRepository : 323860980----SNAPSHOT----an Array(1 August 2013 12:23:34 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119937970 Image size after cleaning MCFileBasedRepository : 323924988Image size before cleaning ClassOrganizer : 323924988----SNAPSHOT----an Array(1 August 2013 12:23:51 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119938116 Image size after cleaning ClassOrganizer : 323989128Image size before cleaning FreeTypeCache : 323989128----SNAPSHOT----an Array(1 August 2013 12:24:06 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119938262 Image size after cleaning FreeTypeCache : 324053128Image size before cleaning NOCCompletionTable : 324053128----SNAPSHOT----an Array(1 August 2013 12:24:21 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119938408 Image size after cleaning NOCCompletionTable : 324117108Image size before cleaning NaturalLanguageTranslator : 324117108----SNAPSHOT----an Array(1 August 2013 12:24:36 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119938554 Image size after cleaning NaturalLanguageTranslator : 324181356Image size before cleaning ScrollBar : 324181356----SNAPSHOT----an Array(1 August 2013 12:24:52 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119938700 Image size after cleaning ScrollBar : 324241728Image size before cleaning FileServices : 324241728----SNAPSHOT----an Array(1 August 2013 12:25:07 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119938846 Image size after cleaning FileServices : 324311268Image size before cleaning EventManager : 324311268----SNAPSHOT----an Array(1 August 2013 12:25:23 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119938992 Image size after cleaning EventManager : 324375192Image size before cleaning PasteUpMorph : 324375192----SNAPSHOT----an Array(1 August 2013 12:25:38 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119939138 Image size after cleaning PasteUpMorph : 324439164Image size before cleaning BitBlt : 324439164----SNAPSHOT----an Array(1 August 2013 12:25:54 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119939284 Image size after cleaning BitBlt : 324156860Image size before cleaning GradientFillStyle : 324156860----SNAPSHOT----an Array(1 August 2013 12:26:11 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119939430 Image size after cleaning GradientFillStyle : 324389584Image size before cleaning NaturalLanguageFormTranslator : 324389584----SNAPSHOT----an Array(1 August 2013 12:26:26 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119939576 Image size after cleaning NaturalLanguageFormTranslator : 324460080Image size before cleaning ProcessBrowser : 324460080----SNAPSHOT----an Array(1 August 2013 12:26:40 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119939722 Image size after cleaning ProcessBrowser : 324524292Image size before cleaning StrikeFont : 324524292----SNAPSHOT----an Array(1 August 2013 12:26:56 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119939868 Image size after cleaning StrikeFont : 324588200Image size before cleaning MCDataStream : 324588200----SNAPSHOT----an Array(1 August 2013 12:27:11 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119940014 Image size after cleaning MCDataStream : 324652584Image size before cleaning CompiledMethod : 324652584----SNAPSHOT----an Array(1 August 2013 12:27:27 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119940160 Image size after cleaning CompiledMethod : 324716520Image size before cleaning SmalltalkImage : 324716520----SNAPSHOT----an Array(1 August 2013 12:27:49 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119940306 Image size after cleaning SmalltalkImage : 324764312Image size before cleaning Symbol : 324764312----SNAPSHOT----an Array(1 August 2013 12:28:07 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119940452 Image size after cleaning Symbol : 324787420Image size before cleaning Browser : 324787420----SNAPSHOT----an Array(1 August 2013 12:28:23 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119940598 Image size after cleaning Browser : 324852504Image size before cleaning MCMethodDefinition : 324852504----SNAPSHOT----an Array(1 August 2013 12:28:39 am) Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1154-Prod_Cleaning.image priorSource: 119940744 Image size after cleaning MCMethodDefinition : 324916888 The image actually grew bigger... Now trying the flush caches thing. Phil On Wed, Jul 31, 2013 at 8:53 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > OK, this was was my experiment.... > > Image fresh with all my app and dependencies loades: 30MB > > After using it for some days/weeks: 160MB. > > SpaceTally new printSpaceAnalysis showed: > > Class code space # instances > inst space percent inst average size > ByteString 2785 413144 > 116244078 69.90 281.36 > Array 3712 181772 > 8466668 5.10 46.58 > ByteArray 8574 1319 > 8186802 4.90 6206.82 > Bitmap 3653 303 > 6656340 4.00 21968.12 > CompiledMethod 22467 90554 > 5685374 3.40 62.78 > > > After executing ImageCleaner cleanUpForRelease: 36MB > > Then...I searched which part of #cleanUpForRelease: was making the > difference, and it was: > > Smalltalk cleanUp: true except: #() confirming: false. > > So now it was time to know WHICH class did the diference, so I modified > #cleanUp: aggressive except: exclusions confirming: aBool > > in these lines: > > "Run the cleanup code" > classes > do:[:aClass| > Transcript show: 'Image size before cleaning ', aClass name, ' : ', > Smalltalk imagePath asFileReference size asString. > aClass cleanUp: aggressive. > 3 timesRepeat: [Smalltalk garbageCollect]. > Smalltalk snapshot: true andQuit: false. > Transcript show: 'Image size after cleaning ', aClass name, ' : ', > Smalltalk imagePath asFileReference size asString. > ] > displayingProgress: [:aClass| 'Cleaning up in ', aClass name]. > I then opened a Transcript, and evaluated > > Smalltalk cleanUp: true except: #() confirming: false. > > I went to prepare Mate, and when I come back, the result was, of course: > > "Image size after cleaning MCFileBasedRepository : 39744008" > > That clean up ends up doing: > > flushAllCaches > self allSubInstancesDo: [:ea | ea flushCache] > So it sends #flushCache to all instances of MCHttpRepository and > MCFileBasedRepository. > > Now what I wanted to see if it there was a particular repo that could take > most of the space (like package-cache). > And indeed, it was...I modified #flushCaches to: > > flushAllCaches > | file | > file := 'repos.txt' asFileReference writeStream text. > self allSubInstancesDo: [:each | > file nextPutAll: 'Image size before cleaning ', each printString, ' : ', > Smalltalk imagePath asFileReference size asString; cr. > each flushCache. > 3 timesRepeat: [Smalltalk garbageCollect]. > Smalltalk snapshot: true andQuit: false. > file nextPutAll: 'Image size after cleaning ', each printString, ' : ', > Smalltalk imagePath asFileReference size asString;cr. > ]. > file flush; close. > And then I looked in the 'repos.txt' file. My package cache repo cleaned > 60 MB. Glorp cleaned 35MB. Seaside30 cleaned 10MB. > So...cleaning cache of just 3 repos frees approx 100MB. > > The question is....can we flush the cache safely? If they are called > "cache", then I guess yes, we can. > > Thoughts? > > Thanks, > > > > On Wed, Jul 31, 2013 at 10:48 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Guys, I have images also with seaside, magritte, glorp, postgresV2, etc >> and it is also around 200MB. >> I will try to do some research today and let you know. >> >> Cheers, >> >> >> On Tue, Jul 30, 2013 at 8:55 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >> >>> >>> On Jul 30, 2013, at 1:49 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> >>> wrote: >>> >>> > the changes file contained passwords and I replaced the text. So >>> offsets may be wrong due to that. >>> > >>> Yes, the first thing I wanted to do is to recompile everything. Does not >>> work. >>> >>> > Memorymonitor is not doing fanct stuff. It just counts instances. >>> > >>> Yes, but maybe it holds on to these instances? >>> >>> Marcus >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com >

July 31, 2013

Re: [Pharo-dev] New PharoVM built

by phil＠highoctane.be

Same for me with the backspace. Caret impossible to type ( ^ ... needless to say, bad...) Umlauts and ~ not working either. Smalltalk vm version 'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Jul 19 2013 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Jul 19 2013 git://gitorious.org/cogvm/blessed.git Commit: 746b609f0323a8db5de2f1aa36f3eed07e312dfe Date: 2013-07-19 13:54:47 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14619 ' erfeklfefeefeâ¦â¦â¦â¦â¦â¦ferf e The things with xes is what I get from copy/pasting the string. 'azeâ¦â¦â¦uiop' asByteArray #[0 0 0 97 0 0 0 122 0 0 0 101 0 0 35 38 0 0 35 38 0 0 35 38 0 0 0 117 0 0 0 105 0 0 0 111 0 0 0 112] Phil On Wed, Jul 31, 2013 at 10:49 PM, Max Leske <maxleske(a)gmail.com> wrote: > I'm seeing the same with latest 3.0. The problem starts occuring as of > build 165. 164 is still ok. > > > On 31.07.2013, at 18:31, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 31 July 2013 17:55, Max Leske <maxleske(a)gmail.com> wrote: > >> > >> On 31.07.2013, at 17:44, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> > >>> works for me. In which platform are you testing? > >> > >> OS X 10.8.4, 64 bit, Pharo 1.3 > > > > can you try it in 3.0 image? > > > >> > >>> > >>> On Jul 31, 2013, at 5:32 PM, Max Leske <maxleske(a)gmail.com> wrote: > >>> > >>>> There seems to be an issue relating to the keyboard. I can't type any > umlauts (option + u) and the delete button produces a question mark. > >>>> > >>>> Max > >>>> > >>>> On 31.07.2013, at 16:59, Max Leske <maxleske(a)gmail.com> wrote: > >>>> > >>>>> Will do. Thanks! > >>>>> > >>>>> > >>>>> On 31.07.2013, at 16:46, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I builded new versions of the vm, integrating latest changes from > Eliot. > >>>>>> This integration should fix some issues, between them the annoying > "SmallInteger" problem. > >>>>>> > >>>>>> You can find it here: > >>>>>> > >>>>>> wget -O- get.pharo.org/20+vmLatest > >>>>>> > >>>>>> or directly here: > >>>>>> > >>>>>> http://files.pharo.org/vm/pharo/ > >>>>>> > >>>>>> (choose the one that fits the best for you, always the "latest") > >>>>>> > >>>>>> can you download and check? > >>>>>> > >>>>>> thanks, > >>>>>> Esteban > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > >

July 31, 2013

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by phil＠highoctane.be

I'll give a shot at trying that on my 300 megs thing! Learning ahead! On Wednesday, July 31, 2013, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > OK, this was was my experiment.... > > Image fresh with all my app and dependencies loades: 30MB > After using it for some days/weeks: 160MB. > SpaceTally new printSpaceAnalysis showed: > > Class code space # instances inst space percent inst average size > ByteString 2785 413144 116244078 69.90 281.36 > Array 3712 181772 8466668 5.10 46.58 > ByteArray 8574 1319 8186802 4.90 6206.82 > Bitmap 3653 303 6656340 4.00 21968.12 > CompiledMethod 22467 90554 5685374 3.40 62.78 > > After executing ImageCleaner cleanUpForRelease: 36MB > Then...I searched which part of #cleanUpForRelease: was making the difference, and it was: > Smalltalk cleanUp: true except: #() confirming: false. > So now it was time to know WHICH class did the diference, so I modified > #cleanUp: aggressive except: exclusions confirming: aBool > in these lines: > "Run the cleanup code" > classes > do:[:aClass| > Transcript show: 'Image size before cleaning ', aClass name, ' : ', Smalltalk imagePath asFileReference size asString. > aClass cleanUp: aggressive. > 3 timesRepeat: [Smalltalk garbageCollect]. > Smalltalk snapshot: true andQuit: false. > Transcript show: 'Image size after cleaning ', aClass name, ' : ', Smalltalk imagePath asFileReference size asString. > ] > displayingProgress: [:aClass| 'Cleaning up in ', aClass name]. > I then opened a Transcript, and evaluated > Smalltalk cleanUp: true except: #() confirming: false. > I went to prepare Mate, and when I come back, the result was, of course: > "Image size after cleaning MCFileBasedRepository : 39744008" > That clean up ends up doing: > flushAllCaches > self allSubInstancesDo: [:ea | ea flushCache] > So it sends #flushCache to all instances of MCHttpRepository and MCFileBasedRepository. > Now what I wanted to see if it there was a particular repo that could take most of the space (like package-cache). > And indeed, it was...I modified #flushCaches to: > flushAllCaches > | file | > file := 'repos.txt' asFileReference writeStream text. > self allSubInstancesDo: [:each | > file nextPutAll: 'Image size before cleaning ', each printString, ' : ', Smalltalk imagePath asFileReference size asString; cr. > each flushCache. > 3 timesRepeat: [Smalltalk garbageCollect]. > Smalltalk snapshot: true andQuit: false. > file nextPutAll: 'Image size after cleaning ', each printString, ' : ', Smalltalk imagePath asFileReference size asString;cr. > ]. > file flush; close. > And then I looked in the 'repos.txt' file. My package cache repo cleaned 60 MB. Glorp cleaned 35MB. Seaside30 cleaned 10MB. > So...cleaning cache of just 3 repos frees approx 100MB. > The question is....can we flush the cache safely? If they are called "cache", then I guess yes, we can. > Thoughts? > Thanks, > > > On Wed, Jul 31, 2013 at 10:48 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: >> >> Guys, I have images also with seaside, magritte, glorp, postgresV2, etc and it is also around 200MB. >> I will try to do some research today and let you know. >> Cheers, >> >> On Tue, Jul 30, 2013 at 8:55 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On Jul 30, 2013, at 1:49 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>> > the changes file contained passwords and I replaced the text. So offsets may be wrong due to that. >>> > >>> Yes, the first thing I wanted to do is to recompile everything. Does not work. >>> >>> > Memorymonitor is not doing fanct stuff. It just counts instances. >>> > >>> Yes, but maybe it holds on to these instances? >>> >>> Marcus >>> >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > -- > Mariano > http://marianopeck.wordpress.com > -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

July 31, 2013

Re: [Pharo-dev] New PharoVM built

by Max Leske

I'm seeing the same with latest 3.0. The problem starts occuring as of build 165. 164 is still ok. On 31.07.2013, at 18:31, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 31 July 2013 17:55, Max Leske <maxleske(a)gmail.com> wrote: >> >> On 31.07.2013, at 17:44, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> works for me. In which platform are you testing? >> >> OS X 10.8.4, 64 bit, Pharo 1.3 > > can you try it in 3.0 image? > >> >>> >>> On Jul 31, 2013, at 5:32 PM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> There seems to be an issue relating to the keyboard. I can't type any umlauts (option + u) and the delete button produces a question mark. >>>> >>>> Max >>>> >>>> On 31.07.2013, at 16:59, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>>> Will do. Thanks! >>>>> >>>>> >>>>> On 31.07.2013, at 16:46, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I builded new versions of the vm, integrating latest changes from Eliot. >>>>>> This integration should fix some issues, between them the annoying "SmallInteger" problem. >>>>>> >>>>>> You can find it here: >>>>>> >>>>>> wget -O- get.pharo.org/20+vmLatest >>>>>> >>>>>> or directly here: >>>>>> >>>>>> http://files.pharo.org/vm/pharo/ >>>>>> >>>>>> (choose the one that fits the best for you, always the "latest") >>>>>> >>>>>> can you download and check? >>>>>> >>>>>> thanks, >>>>>> Esteban >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

July 31, 2013

Re: [Pharo-dev] [Seaside] [ANN] Pharo 2 Summer released

by Tudor Girba

Thank you! Doru On Wed, Jul 31, 2013 at 5:41 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > The Pharo Team is happy to announce the Pharo 2 Summer release, > the regular half of the year bugfix edition. > > For this version, we incorporated really few changes since 2.0 was a > really successful release. Anyway, we managed to sneak in a couple of minor > additions: > > - Integrated ProfStef > - Updated Configurations Browser > > Also, we integrated 42 bugfixes, 20 of them backported from 3. 0 alpha. > > As always, Summer edition can be downloaded at: > > http://www.pharo-project.org/pharo-download > > We want to thank to all members of the community for their help and > support and specially to all who submitted the reports, fixed the bugs and > tested them. > > The Pharo Team > > > List complete of bugfixes and backports: > =============================== > > Fixed: > -------- > > 7345 DNU with Glamour: PaginatedMorphTreeMorph>>setSelectedMorph: > https://code.google.com/p/pharo/issues/detail?id=7345 > > 10014 World menu > System > Switch User serves no purpose > > https://pharo.fogbugz.com/f/cases/10014/World-menu-System-Switch-User-serve… > 10004 SmalltalkImage current reportCPUandRAM > DNU > > https://pharo.fogbugz.com/f/cases/10004/SmalltalkImage-current-reportCPUand… > > 10017 ProtocolCLient do not propagate the erros from the server > https://pharo.fogbugz.com/f/cases/10017 > > 7627 FileReference>>deleteAll follows symlinks > https://pharo.fogbugz.com/f/cases/7627 > > 10027 Failing Test: FileReferenceTest>>#testDeleteAl > https://pharo.fogbugz.com/f/cases/10027 > > 10123 Bug in warning in CriticBrowser > https://pharo.fogbugz.com/f/cases/10123 > > 10196 Change shortcuts default settings of 2.0 to the traditional ones > https://pharo.fogbugz.com/f/cases/10196 > 10195 Replace ugly Keymappings API on:do: > https://pharo.fogbugz.com/f/cases/10195 > 10200 Date instances dayOfWeek wrong > https://pharo.fogbugz.com/f/cases/10200 > 10109 MNU : SmalltalkEditor>>browseItHere: > https://pharo.fogbugz.com/f/cases/10109 > 10394 Duplicated instance #model in NewList (already defined in > MorphicModel) > https://pharo.fogbugz.com/f/cases/10394 > 10336 Port 2.0: Document difference between TextModel and > TextInputFieldModel > https://pharo.fogbugz.com/f/cases/10336 > 10653 Some Jenkins images show a stdout is closed error > https://pharo.fogbugz.com/f/cases/10653 > > 10653 Some Jenkins images show a stdout is closed error > https://pharo.fogbugz.com/f/cases/10653 > 10415 Integrate 2.0: 10411 flush after nextChunkPut: > https://pharo.fogbugz.com/f/cases/10415 > > 10888 Backport 2.0: Compound Extension Methods Unpackaged > > https://pharo.fogbugz.com/f/cases/10888/Backport-2-0-Compound-Extension-Met… > > 10730 Fix for stack serialization with Fuel > > https://pharo.fogbugz.com/f/cases/10730/Fix-for-stack-serialization-with-Fu… > > 10946 HistoryCollection package is empty > https://pharo.fogbugz.com/f/cases/10946 > > 11101 fileOutMethod:on: uncategorized in 2.0 > https://pharo.fogbugz.com/f/cases/11101 > 11179 Config browser buttons broken due to missing method > https://pharo.fogbugz.com/f/cases/11179 > > 10860 option click on list in TestRunner and others: freeze system > https://pharo.fogbugz.com/f/cases/10860 > > Backported: > ---------------- > 10194 Backport to 2.0: special objects array recreation crash > https://pharo.fogbugz.com/f/cases/10194 > 10185 Backport 2.0: 10173 ClassBuilder cannot safely modify a class why > using it > https://pharo.fogbugz.com/f/cases/10185 > 10174 Backport 2.0 Issue 10162: multiple selection of methods in method > pane ... > https://pharo.fogbugz.com/f/cases/10174 > > 10249 Backport 2.0: Red Light when all test are green > https://pharo.fogbugz.com/f/cases/10249 > 10230 backport 2.0: 10229 Fix sender of #copyWithTempsFromMethodNode: > https://pharo.fogbugz.com/f/cases/10230 > 10179 backport 2.0: 10038 Wrong deprecated message > https://pharo.fogbugz.com/f/cases/10179 > > 10260 backport 2.0: 10258 DivideByZero in SystemProgressMorph > https://pharo.fogbugz.com/f/cases/10260 > 10406 backport 2.0: 5819 Implement a way to get the user directories based > on the current OS > https://pharo.fogbugz.com/f/cases/10406 > 10396 backport 2.0 10395 DNU SmallInteger>>#add: when loading metacello > configuration > https://pharo.fogbugz.com/f/cases/10396 > 10387 backport 2.0: 10102 SocketStream>>next: should not signal > ConncetionClosed > https://pharo.fogbugz.com/f/cases/10387 > 10311 Backport 2.0: 10228 Fix tab key for autocompletion > https://pharo.fogbugz.com/f/cases/10311 > > 10537 Backport 2.0: StartupPreferences interferes with zeroconf pharo > binary > https://pharo.fogbugz.com/f/cases/10537 > > 10938 backport 2.0 : an MCOrganizationDefinition should only remove empty > categories during unload > https://pharo.fogbugz.com/f/cases/10938 > 10909 Backport Pharo2.0: Prepare isHeadless for new VMs with double dash > -- arguments > https://pharo.fogbugz.com/f/cases/10909 > > 10994 Backport 2.0: Delays do not work properly directly on image startup > > https://pharo.fogbugz.com/f/cases/10994/Backport-2-0-Delays-do-not-work-pro… > > 10931 Backport 2.0: Filing out extension package in Nautilus produces > empty file > https://pharo.fogbugz.com/f/cases/10931 > 10978 Backport 20: ZipArchive utf8 handling > https://pharo.fogbugz.com/f/cases/10978 > 11125 backport 2.0: 10859 Monticello freezing the image > https://pharo.fogbugz.com/f/cases/11125 > 10569 Backport 2.0: Better Interrruptionche > https://pharo.fogbugz.com/f/cases/10569 > 10940 Backport 2.0: 10925 Use caching in Gofer > https://pharo.fogbugz.com/f/cases/10940 > > 11252 backport 2.0: have SliceMaker use fogbugz > https://pharo.fogbugz.com/f/cases/11252 > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- www.tudorgirba.com "Every thing has its own flow"

July 31, 2013

Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Mariano Martinez Peck

OK, this was was my experiment.... Image fresh with all my app and dependencies loades: 30MB After using it for some days/weeks: 160MB. SpaceTally new printSpaceAnalysis showed: Class code space # instances inst space percent inst average size ByteString 2785 413144 116244078 69.90 281.36 Array 3712 181772 8466668 5.10 46.58 ByteArray 8574 1319 8186802 4.90 6206.82 Bitmap 3653 303 6656340 4.00 21968.12 CompiledMethod 22467 90554 5685374 3.40 62.78 After executing ImageCleaner cleanUpForRelease: 36MB Then...I searched which part of #cleanUpForRelease: was making the difference, and it was: Smalltalk cleanUp: true except: #() confirming: false. So now it was time to know WHICH class did the diference, so I modified #cleanUp: aggressive except: exclusions confirming: aBool in these lines: "Run the cleanup code" classes do:[:aClass| Transcript show: 'Image size before cleaning ', aClass name, ' : ', Smalltalk imagePath asFileReference size asString. aClass cleanUp: aggressive. 3 timesRepeat: [Smalltalk garbageCollect]. Smalltalk snapshot: true andQuit: false. Transcript show: 'Image size after cleaning ', aClass name, ' : ', Smalltalk imagePath asFileReference size asString. ] displayingProgress: [:aClass| 'Cleaning up in ', aClass name]. I then opened a Transcript, and evaluated Smalltalk cleanUp: true except: #() confirming: false. I went to prepare Mate, and when I come back, the result was, of course: "Image size after cleaning MCFileBasedRepository : 39744008" That clean up ends up doing: flushAllCaches self allSubInstancesDo: [:ea | ea flushCache] So it sends #flushCache to all instances of MCHttpRepository and MCFileBasedRepository. Now what I wanted to see if it there was a particular repo that could take most of the space (like package-cache). And indeed, it was...I modified #flushCaches to: flushAllCaches | file | file := 'repos.txt' asFileReference writeStream text. self allSubInstancesDo: [:each | file nextPutAll: 'Image size before cleaning ', each printString, ' : ', Smalltalk imagePath asFileReference size asString; cr. each flushCache. 3 timesRepeat: [Smalltalk garbageCollect]. Smalltalk snapshot: true andQuit: false. file nextPutAll: 'Image size after cleaning ', each printString, ' : ', Smalltalk imagePath asFileReference size asString;cr. ]. file flush; close. And then I looked in the 'repos.txt' file. My package cache repo cleaned 60 MB. Glorp cleaned 35MB. Seaside30 cleaned 10MB. So...cleaning cache of just 3 repos frees approx 100MB. The question is....can we flush the cache safely? If they are called "cache", then I guess yes, we can. Thoughts? Thanks, On Wed, Jul 31, 2013 at 10:48 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Guys, I have images also with seaside, magritte, glorp, postgresV2, etc > and it is also around 200MB. > I will try to do some research today and let you know. > > Cheers, > > > On Tue, Jul 30, 2013 at 8:55 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> On Jul 30, 2013, at 1:49 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> >> wrote: >> >> > the changes file contained passwords and I replaced the text. So >> offsets may be wrong due to that. >> > >> Yes, the first thing I wanted to do is to recompile everything. Does not >> work. >> >> > Memorymonitor is not doing fanct stuff. It just counts instances. >> > >> Yes, but maybe it holds on to these instances? >> >> Marcus >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

July 31, 2013

Re: [Pharo-dev] New PharoVM built

by Igor Stasenko

On 31 July 2013 17:55, Max Leske <maxleske(a)gmail.com> wrote: > > On 31.07.2013, at 17:44, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> works for me. In which platform are you testing? > > OS X 10.8.4, 64 bit, Pharo 1.3 can you try it in 3.0 image? > >> >> On Jul 31, 2013, at 5:32 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> There seems to be an issue relating to the keyboard. I can't type any umlauts (option + u) and the delete button produces a question mark. >>> >>> Max >>> >>> On 31.07.2013, at 16:59, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> Will do. Thanks! >>>> >>>> >>>> On 31.07.2013, at 16:46, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> I builded new versions of the vm, integrating latest changes from Eliot. >>>>> This integration should fix some issues, between them the annoying "SmallInteger" problem. >>>>> >>>>> You can find it here: >>>>> >>>>> wget -O- get.pharo.org/20+vmLatest >>>>> >>>>> or directly here: >>>>> >>>>> http://files.pharo.org/vm/pharo/ >>>>> >>>>> (choose the one that fits the best for you, always the "latest") >>>>> >>>>> can you download and check? >>>>> >>>>> thanks, >>>>> Esteban >>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > -- Best regards, Igor Stasenko.

July 31, 2013

Re: [Pharo-dev] New PharoVM built

by Max Leske

On 31.07.2013, at 17:44, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > works for me. In which platform are you testing? OS X 10.8.4, 64 bit, Pharo 1.3 > > On Jul 31, 2013, at 5:32 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> There seems to be an issue relating to the keyboard. I can't type any umlauts (option + u) and the delete button produces a question mark. >> >> Max >> >> On 31.07.2013, at 16:59, Max Leske <maxleske(a)gmail.com> wrote: >> >>> Will do. Thanks! >>> >>> >>> On 31.07.2013, at 16:46, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I builded new versions of the vm, integrating latest changes from Eliot. >>>> This integration should fix some issues, between them the annoying "SmallInteger" problem. >>>> >>>> You can find it here: >>>> >>>> wget -O- get.pharo.org/20+vmLatest >>>> >>>> or directly here: >>>> >>>> http://files.pharo.org/vm/pharo/ >>>> >>>> (choose the one that fits the best for you, always the "latest") >>>> >>>> can you download and check? >>>> >>>> thanks, >>>> Esteban >>>> >>>> >>>> >>> >> >> > >

July 31, 2013

Re: [Pharo-dev] New PharoVM built

by Esteban Lorenzano

works for me. In which platform are you testing? On Jul 31, 2013, at 5:32 PM, Max Leske <maxleske(a)gmail.com> wrote: > There seems to be an issue relating to the keyboard. I can't type any umlauts (option + u) and the delete button produces a question mark. > > Max > > On 31.07.2013, at 16:59, Max Leske <maxleske(a)gmail.com> wrote: > >> Will do. Thanks! >> >> >> On 31.07.2013, at 16:46, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> Hi, >>> >>> I builded new versions of the vm, integrating latest changes from Eliot. >>> This integration should fix some issues, between them the annoying "SmallInteger" problem. >>> >>> You can find it here: >>> >>> wget -O- get.pharo.org/20+vmLatest >>> >>> or directly here: >>> >>> http://files.pharo.org/vm/pharo/ >>> >>> (choose the one that fits the best for you, always the "latest") >>> >>> can you download and check? >>> >>> thanks, >>> Esteban >>> >>> >>> >> > >

July 31, 2013