- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] New PharoVM built

by Esteban Lorenzano

still works for me... looks like a keyboard distribution problem, we'll check (bah, Guille will do it :) soon :) can you send which keyboard layour do you use? and exactly which key combinations are you trying? thanks, Esteban On Aug 1, 2013, at 12:01 AM, phil(a)highoctane.be wrote: > 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. > > > > >

Aug. 1, 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 StÃ©phane Ducasse

since years marcus is telling that MC storing ancestor information is doomed but we do not have something to really replace it. Stef On 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

Aug. 1, 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 Mariano Martinez Peck

Phil, and the cleanUpForRelease in general does not help at all? On Wed, Jul 31, 2013 at 8:30 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > 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 >> > > -- Mariano http://marianopeck.wordpress.com

Aug. 1, 2013

Re: [Pharo-dev] New PharoVM built

by Igor Stasenko

Guillermo, do you know why your changes breaking things so bad? On 1 August 2013 00:01, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > 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. >> > >> >> > -- Best regards, Igor Stasenko.

Aug. 1, 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

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