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

Re: [Pharo-dev] Windows problem with FilePlugin ?

by Benjamin

Yep :) Thanks for your help. I opened an issue for that (11293) and I will try to tackle it tonight Ben On Aug 1, 2013, at 4:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor did not tell you but I see strange blue window and windows on his machine and red square of deathâ¦. > So he is looking at it. > > Stef > > On Aug 1, 2013, at 1:01 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> On my image, when opened in Windows, opening the File Browser leads to a red square of death :s >> >> And using the UIManager to popup the file picker leads to an infinite loop of halt :s >> >> Do you experienced that too ? >> >> >> Can people using windows try the following line: >> >> (FileSystem disk root) directories >> >> This gives me C:, D:, F:, G: where actually only C: and G: are presentâ¦ >> >> >> It seems to come from >> DiskStore>>#basicEntry:path:nodesDo: >> [â¦] >> >> [ entry isNil ] >> whileFalse: [ >> entry at: 1 put: (Primitives decode: entry first). >> aBlock value: entry. >> index := index + 1. >> entry := Primitives lookupEntryIn: encodedPathString index: index ]. >> >> So I would say it comes from the primitives. >> >> Ben > >

Aug. 1, 2013

Re: [Pharo-dev] Windows problem with FilePlugin ?

by Igor Stasenko

On 1 August 2013 16:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor did not tell you but I see strange blue window and windows on his machine and red square of deathâ¦. > So he is looking at it. > i did in fact.. i was chatting with Ben all the time :) > Stef > > On Aug 1, 2013, at 1:01 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> On my image, when opened in Windows, opening the File Browser leads to a red square of death :s >> >> And using the UIManager to popup the file picker leads to an infinite loop of halt :s >> >> Do you experienced that too ? >> >> >> Can people using windows try the following line: >> >> (FileSystem disk root) directories >> >> This gives me C:, D:, F:, G: where actually only C: and G: are presentâ¦ >> >> >> It seems to come from >> DiskStore>>#basicEntry:path:nodesDo: >> [â¦] >> >> [ entry isNil ] >> whileFalse: [ >> entry at: 1 put: (Primitives decode: entry first). >> aBlock value: entry. >> index := index + 1. >> entry := Primitives lookupEntryIn: encodedPathString index: index ]. >> >> So I would say it comes from the primitives. >> >> Ben > > -- Best regards, Igor Stasenko.

Aug. 1, 2013

Re: [Pharo-dev] Windows problem with FilePlugin ?

by StÃ©phane Ducasse

Igor did not tell you but I see strange blue window and windows on his machine and red square of deathâ¦. So he is looking at it. Stef On Aug 1, 2013, at 1:01 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > On my image, when opened in Windows, opening the File Browser leads to a red square of death :s > > And using the UIManager to popup the file picker leads to an infinite loop of halt :s > > Do you experienced that too ? > > > Can people using windows try the following line: > > (FileSystem disk root) directories > > This gives me C:, D:, F:, G: where actually only C: and G: are presentâ¦ > > > It seems to come from > DiskStore>>#basicEntry:path:nodesDo: > [â¦] > > [ entry isNil ] > whileFalse: [ > entry at: 1 put: (Primitives decode: entry first). > aBlock value: entry. > index := index + 1. > entry := Primitives lookupEntryIn: encodedPathString index: index ]. > > So I would say it comes from the primitives. > > Ben

Aug. 1, 2013

Re: [Pharo-dev] [Pharo-project] A solution to manage units like inches and centimeters in Pharo?

by StÃ©phane Ducasse

Excellent! Stef > Its not just you, I don't used to write to the lists. > > Phil, thanks for the repo location. > Stef, Aconcagua and Chalten are now on the 2.0 metaRepo. > > > 2013/7/30 Igor Stasenko <siguctua(a)gmail.com> > On 31 July 2013 00:00, Maximiliano Taborda <mtaborda(a)gmail.com> wrote: > > Hi Igor, > > > > Something about me. > > Well, I'm from Buenos Aires, Argentina. I'm fan of the greatest football > > team in the world: Boca Juniors. And I'm a smalltalker since early of the > > 2000. > > > So, you been around for quite a while? :) > Or it is just me, who never seen your name in list? > > Anyways, nice to see people doing useful stuff. > > > I'd been working with Hernan (WiIkinson) when we develop the ancestors of > > Aconcagua and Chalten for one of the financial applications of the company > > for wich we work. > > Then, when I starts my thesis work, I migrate these two frameworks from > > VisualAge to other Smalltalk flavors (VisualWorks, Squeak/Pharo). When we > > publish both frameworks, we named as Aconcagua to the measure model and > > Chalten to the gregorian dates model. > > Then, specificly for my thesis, I extended this initial version of Chalten > > with more abstractions, calendars, behavior and other stuff. > > > > Now, a couple of months ago, I upload both models to SmalltalkHub with some > > packages renamed and with the implementation of ConfigurationOfAconcagua and > > ConfigurationOfChalten for loading it in a easy way. > > > > Thanks for giving us some info :) > > > Regards. > > Maxi. > > > > > > 2013/7/30 Igor Stasenko <siguctua(a)gmail.com> > >> > >> On 30 July 2013 16:23, Maximiliano Taborda <mtaborda(a)gmail.com> wrote: > >> > Hi Stef, people. > >> > > >> > Maybe is a little late to answer to this, but I already migrate > >> > Aconcagua, > >> > and Chalten too, to SmalltalkHub. > >> > Here: > >> > http://smalltalkhub.com/#!/~maxi/Aconcagua > >> > http://smalltalkhub.com/#!/~maxi/Chalten > >> > > >> .. and lurkers do all the hard work :) > >> > >> Hi, mr. Lurker. Please can you tell us about yourself , so we can > >> welcome you properly? > >> > >> :) > >> > >> > >> > Regards. > >> > Maxi > >> > > >> > > >> > 2013/2/24 stephane ducasse <stephane.ducasse(a)free.fr> > >> >> > >> >> Yes I would like to migrate Aconcagua to SmalltalkHub :) > >> >> > >> >> On Feb 23, 2013, at 3:47 PM, Mariano Martinez Peck > >> >> <marianopeck(a)gmail.com> > >> >> wrote: > >> >> > >> >> Yes, I was going to suggest that. > >> >> Maybe Hernan can say more. > >> >> > >> >> > >> >> On Fri, Feb 22, 2013 at 11:04 PM, Ben Coman <btc(a)openinworld.com> > >> >> wrote: > >> >>> > >> >>> Frank Shearar wrote: > >> >>>> > >> >>>> On 22 February 2013 15:45, Guillaume Larcheveque > >> >>>> <guillaume.larcheveque(a)gmail.com> wrote: > >> >>>> > >> >>>>> > >> >>>>> Does something exists because I looked and don't find anything. > >> >>>>> > >> >>>> > >> >>>> > >> >>>> Something like these? > >> >>>> * http://map.squeak.org/package/b546b6af-984e-4e89-a7a5-875ce0435710 > >> >>>> * http://map.squeak.org/package/8664cb28-916b-4e8a-8cd6-b6db73f5024c > >> >>>> > >> >>>> frank > >> >>>> > >> >>>> > >> >>>> > >> >>> > >> >>> I had Aconcagua running on Pharo a year ago before I got sidetracked. > >> >>> Can't remember if or what I needed to tweak, but I found a mcz with my > >> >>> name > >> >>> on it. > >> >>> > >> >>> cheers -ben > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> Mariano > >> >> http://marianopeck.wordpress.com > >> >> > >> >> > >> > > >> > >> > >> > >> -- > >> 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 Guillermo Polito

Ok, we are looking at that with marcus. So, one thing that may be causing problems is that there are some usages of #onAnnouncement: anAnnouncement do: aBlock. And since we don't have ephermerons, the usage of blocks in announcements is leaking references. Also, looking at the usages of onAnnouncement:do:, we found NECController>>setEditor:, which is called for every keystroke in when using autocompletion :D. Maybe the cause is around here? On Thu, Aug 1, 2013 at 1:40 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Yes, I think the announcers of morph might be the cause of the problem... > > > On Thu, Aug 1, 2013 at 1:09 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> I did a little run on those MorphExtensions and got the output file in >> annex. >> >> Cursor wait showWhile: [ >> (FileSystem disk workingDirectory / 'MorphExtensions.txt') >> asFileReference writeStreamDo: [ :s | >> MorphExtension allInstancesDo: [ :each | >> each printOn: s. >> s lf >> ] >> ] >> ]. >> >> Looks like there are a lot of Announcers. >> >> Phil >> >> >> On Thu, Aug 1, 2013 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >> >>> >>> On Aug 1, 2013, at 1:31 AM, 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... >>> >>> >>> No, we already saw that in your case the reason are many,many instances >>> of MorphExtension without the Morphs hanging around. >>> (which should not happen as MorphExtensions are only referenced by the >>> Morph they extend). >>> >>> Your case is not a case of caches, there is a real problem somewhere. >>> >>> Marcus >>> >>> >> > > > -- > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de >

Aug. 1, 2013

Re: [Pharo-dev] New PharoVM built

by Max Leske

I'm using the US international layout. Not working: - delete button - diaeresis (for umlauts); option + u (+ any character that accepts diaeresis) - probably more (didn't go through more) On 01.08.2013, at 11:47, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 1 August 2013 10:27, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> Keyboard: Belgian french >> >> Key combination that doesn't work: hit the caret key... hit fn-Backspace... >> both things pretty standard. >> > ah, i think its same as for me, when i found my Delete key stop working. > >> Phil >> On Thu, Aug 1, 2013 at 9:14 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >>> >>> 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. >>>>> >>>> >>>> >>> >>> >> > > > > -- > 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 Marcus Denker

Yes, I think the announcers of morph might be the cause of the problem... On Thu, Aug 1, 2013 at 1:09 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > I did a little run on those MorphExtensions and got the output file in > annex. > > Cursor wait showWhile: [ > (FileSystem disk workingDirectory / 'MorphExtensions.txt') asFileReference > writeStreamDo: [ :s | > MorphExtension allInstancesDo: [ :each | > each printOn: s. > s lf > ] > ] > ]. > > Looks like there are a lot of Announcers. > > Phil > > > On Thu, Aug 1, 2013 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> On Aug 1, 2013, at 1:31 AM, 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... >> >> >> No, we already saw that in your case the reason are many,many instances >> of MorphExtension without the Morphs hanging around. >> (which should not happen as MorphExtensions are only referenced by the >> Morph they extend). >> >> Your case is not a case of caches, there is a real problem somewhere. >> >> Marcus >> >> > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Aug. 1, 2013

Re: [Pharo-dev] killing all uses of caseOf: and caseOf:otherwise from the image

by Goubier Thierry

Interestingly, in a base 2.0 image, there isn't any user of caseOf: and very few users of caseOf:otherwise: A sample: ^ places caseOf: {[0]->[1] . [1]->[0.1] . [2]->[0.01] . [3]->[0.001] . [4]->[0.0001] . [5]->[0.00001] . [6]->[0.000001] . [7]->[0.0000001] . [8]->[0.00000001] . [9]->[0.000000001]} otherwise: [(10.0 raisedTo: places negated) asFloat] It looks like your average Pharo programmer is good at avoiding the use of caseOf: :) Thierry Le 01/08/2013 13:15, Frank Shearar a Ã©crit : > On 1 August 2013 12:13, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 1 August 2013 12:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi guys >>> >>> we should not use caseOf: in the image. >>> So I will start removing them. >> >> Other than switching on _type_, what is the problem? >> >> foo caseOf: { >> [1] -> ['one']. >> [2] -> ['two']. >> } otherwise: ['three'] >> >> What's wrong with this? > > I can see a reason for removing #caseOf:, precisely because it doesn't > force you to consider a failed match. (#caseOf:otherwise: is always > exhaustive, in other words.) > > frank > >>> Stef >>> > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Aug. 1, 2013

Re: [Pharo-dev] killing all uses of caseOf: and caseOf:otherwise from the image

by Frank Shearar

On 1 August 2013 12:13, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 1 August 2013 12:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> we should not use caseOf: in the image. >> So I will start removing them. > > Other than switching on _type_, what is the problem? > > foo caseOf: { > [1] -> ['one']. > [2] -> ['two']. > } otherwise: ['three'] > > What's wrong with this? I can see a reason for removing #caseOf:, precisely because it doesn't force you to consider a failed match. (#caseOf:otherwise: is always exhaustive, in other words.) frank >> Stef >>

Aug. 1, 2013

Re: [Pharo-dev] killing all uses of caseOf: and caseOf:otherwise from the image

by Frank Shearar

On 1 August 2013 12:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > we should not use caseOf: in the image. > So I will start removing them. Other than switching on _type_, what is the problem? foo caseOf: { [1] -> ['one']. [2] -> ['two']. } otherwise: ['three'] What's wrong with this? frank > Stef >

Aug. 1, 2013

killing all uses of caseOf: and caseOf:otherwise from the image

by StÃ©phane Ducasse

Hi guys we should not use caseOf: in the image. So I will start removing them. Stef

Aug. 1, 2013

Windows problem with FilePlugin ?

by Benjamin

On my image, when opened in Windows, opening the File Browser leads to a red square of death :s And using the UIManager to popup the file picker leads to an infinite loop of halt :s Do you experienced that too ? Can people using windows try the following line: (FileSystem disk root) directories This gives me C:, D:, F:, G: where actually only C: and G: are presentâ¦ It seems to come from DiskStore>>#basicEntry:path:nodesDo: [â¦] [ entry isNil ] whileFalse: [ entry at: 1 put: (Primitives decode: entry first). aBlock value: entry. index := index + 1. entry := Primitives lookupEntryIn: encodedPathString index: index ]. So I would say it comes from the primitives. Ben

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

I did a little run on those MorphExtensions and got the output file in annex. Cursor wait showWhile: [ (FileSystem disk workingDirectory / 'MorphExtensions.txt') asFileReference writeStreamDo: [ :s | MorphExtension allInstancesDo: [ :each | each printOn: s. s lf ] ] ]. Looks like there are a lot of Announcers. Phil On Thu, Aug 1, 2013 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Aug 1, 2013, at 1:31 AM, 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... > > > No, we already saw that in your case the reason are many,many instances of > MorphExtension without the Morphs hanging around. > (which should not happen as MorphExtensions are only referenced by the > Morph they extend). > > Your case is not a case of caches, there is a real problem somewhere. > > Marcus > >

Aug. 1, 2013

Re: [Pharo-dev] [update 3.0] #30322

by Marcus Denker

On Aug 1, 2013, at 11:46 AM, Sebastian Tleye <stleye(a)gmail.com> wrote: > I think there is a problem in Monticello with this version > Yes, there are many problems. Maybe we need to revertâ¦ which is a lot of work, so I want to check with Ben before if this is not easily fixable somehow. > > > 2013/8/1 Marcus Denker <marcus.denker(a)inria.fr> > 30322 > ----- > > 11282 Removal DependentFields references > https://pharo.fogbugz.com/f/cases/11282 > > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1550.diff > >

Aug. 1, 2013

Re: [Pharo-dev] New PharoVM built

by Igor Stasenko

On 1 August 2013 10:27, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Keyboard: Belgian french > > Key combination that doesn't work: hit the caret key... hit fn-Backspace... > both things pretty standard. > ah, i think its same as for me, when i found my Delete key stop working. > Phil > On Thu, Aug 1, 2013 at 9:14 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: >> >> 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. >>> > >>> >>> >> >> > -- Best regards, Igor Stasenko.

Aug. 1, 2013

Re: [Pharo-dev] [update 3.0] #30322

by Sebastian Tleye

I think there is a problem in Monticello with this version 2013/8/1 Marcus Denker <marcus.denker(a)inria.fr> > 30322 > ----- > > 11282 Removal DependentFields references > https://pharo.fogbugz.com/f/cases/11282 > > Diff information: > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1550.diff > >

Aug. 1, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 122 regressions found. Gofer.Tests.GoferOperationTest.testCleanup Gofer.Tests.GoferOperationTest.testCommit Gofer.Tests.GoferOperationTest.testLoad Gofer.Tests.GoferOperationTest.testLocalChanges Gofer.Tests.GoferOperationTest.testMerge Gofer.Tests.GoferOperationTest.testReinitialize Gofer.Tests.GoferOperationTest.testRemoteChanges Gofer.Tests.GoferOperationTest.testRevert Gofer.Tests.GoferOperationTest.testUnload Gofer.Tests.GoferOperationTest.testUpdate HelpSystem.Tests.Core.UI.HelpBrowserTest.testOpen HelpSystem.Tests.Core.Utilities.CustomHelpTest.testOpenBrowserOnThisHelpType HelpSystem.Tests.Core.Utilities.WikiStyleHelpTest.testOpenBrowserOnThisHelpType RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testAddCategoryCreatesPackage RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testRenameCategoryAlsoRenameAllExtensionProtocols RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testAddCategoryIsAlreadyAPackageDoesNotCreatePackage RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testRenameCategoryChangeTheNameOfThePackage RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testRenameUnknownCategoryCreatesNewRPackage RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testRenameCategoryUpdateTheOrganizer RPackage.SystemIntegration.RPackageClassesSynchronisationTest.testRecategorizeClassWithMetaClassMethodsRegisterAllClassMethodsInTheNewPackage ...

Aug. 1, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… 121 regressions found. Gofer.Tests.GoferOperationTest.testCleanup Gofer.Tests.GoferOperationTest.testCommit Gofer.Tests.GoferOperationTest.testLoad Gofer.Tests.GoferOperationTest.testLocalChanges Gofer.Tests.GoferOperationTest.testMerge Gofer.Tests.GoferOperationTest.testReinitialize Gofer.Tests.GoferOperationTest.testRemoteChanges Gofer.Tests.GoferOperationTest.testRevert Gofer.Tests.GoferOperationTest.testUnload Gofer.Tests.GoferOperationTest.testUpdate HelpSystem.Tests.Core.UI.HelpBrowserTest.testOpen HelpSystem.Tests.Core.Utilities.CustomHelpTest.testOpenBrowserOnThisHelpType HelpSystem.Tests.Core.Utilities.WikiStyleHelpTest.testOpenBrowserOnThisHelpType RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testAddCategoryCreatesPackage RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testRenameCategoryAlsoRenameAllExtensionProtocols RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testAddCategoryIsAlreadyAPackageDoesNotCreatePackage RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testRenameCategoryChangeTheNameOfThePackage RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testRenameUnknownCategoryCreatesNewRPackage RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testRenameCategoryUpdateTheOrganizer RPackage.SystemIntegration.RPackageClassesSynchronisationTest.testRecategorizeClassWithMetaClassMethodsRegisterAllClassMethodsInTheNewPackage ...

Aug. 1, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linu… 121 regressions found. Gofer.Tests.GoferOperationTest.testCleanup Gofer.Tests.GoferOperationTest.testCommit Gofer.Tests.GoferOperationTest.testLoad Gofer.Tests.GoferOperationTest.testLocalChanges Gofer.Tests.GoferOperationTest.testMerge Gofer.Tests.GoferOperationTest.testReinitialize Gofer.Tests.GoferOperationTest.testRemoteChanges Gofer.Tests.GoferOperationTest.testRevert Gofer.Tests.GoferOperationTest.testUnload Gofer.Tests.GoferOperationTest.testUpdate HelpSystem.Tests.Core.UI.HelpBrowserTest.testOpen HelpSystem.Tests.Core.Utilities.CustomHelpTest.testOpenBrowserOnThisHelpType HelpSystem.Tests.Core.Utilities.WikiStyleHelpTest.testOpenBrowserOnThisHelpType RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testAddCategoryCreatesPackage RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testRenameCategoryAlsoRenameAllExtensionProtocols RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testAddCategoryIsAlreadyAPackageDoesNotCreatePackage RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testRenameCategoryChangeTheNameOfThePackage RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testRenameUnknownCategoryCreatesNewRPackage RPackage.SystemIntegration.RPackageCategorySynchronisationTest.testRenameCategoryUpdateTheOrganizer RPackage.SystemIntegration.RPackageClassesSynchronisationTest.testRecategorizeClassWithMetaClassMethodsRegisterAllClassMethodsInTheNewPackage ...

Aug. 1, 2013

[update 3.0] #30322

by Marcus Denker

30322 ----- 11282 Removal DependentFields references https://pharo.fogbugz.com/f/cases/11282 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1550.diff

Aug. 1, 2013

Re: [Pharo-dev] New PharoVM built

by phil＠highoctane.be

Keyboard: Belgian french Key combination that doesn't work: hit the caret key... hit fn-Backspace... both things pretty standard. Phil On Thu, Aug 1, 2013 at 9:14 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > 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 Marcus Denker

On Aug 1, 2013, at 1:31 AM, phil(a)highoctane.be wrote: > Doing the flushCaches... > > Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/estebanlm/EclipsePack/m… : 324017564 > Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/estebanlm/EclipsePack/m… : 324137232 > Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/DripfeedIt… : 324137232 > Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/DripfeedIt… : 324195720 > Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOWebStack… : 324195720 > Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOWebStack… : 324255300 > Image size before cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOExperime… : 324255300 > Image size after cleaning a MCSmalltalkhubRepository(http://smalltalkhub.com/mc/philippeback/HOExperime… : 324314868 > > Definitely not going down... > No, we already saw that in your case the reason are many,many instances of MorphExtension without the Morphs hanging around. (which should not happen as MorphExtensions are only referenced by the Morph they extend). Your case is not a case of caches, there is a real problem somewhere. Marcus

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 Marcus Denker

On Aug 1, 2013, at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > since years marcus is telling that MC storing ancestor information is doomed but we do not have something to really replace it. > This is yet another thing. Monticello keep all history data of all package in image, this is not a cache. When you delete it, your package loses it's history and you can not merge anymore. MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. We did that on Pharo2 release and it saved 8MB (nearly a third of the image). Marcus

Aug. 1, 2013

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