- Pharo-dev - lists.pharo.org

[Pharo-project] New problem with rehash [WAS] Re: MethodDictionary fast #rehash
by Mariano Martinez Peck Sept. 27, 2011

Sept. 27, 2011

Hi. With this latest new #rehash there is a problem. I took Levente changes from Squeak. @Levente: the same happens in squeak so this may interest you. The #rehash is right now rehash | newInstance | newInstance := self species new: self basicSize - 1. "Make sure it has the same capacity" 1 to: self basicSize do: [ :index | (self basicAt: index) ifNotNil: [ :key | newInstance at: key put: (array at: index) ] ]. self copyFrom: newInstance The problem is that #new: does: new: numberOfElements "Create an instance large enough to hold numberOfElements without growing. Note that the basic size must be a power of 2. It is VITAL (see grow) that size gets doubled if numberOfElements is a power of 2" | size | size := self sizeFor: numberOfElements. ^(self basicNew: size) initialize: size And #sizeFor: does: sizeFor: numberOfElements "Return the minimum capacity of a dictionary that can hold numberOfElements elements. At least 25% of the array must be empty and the return value must be a power of 2." ^1 bitShift: (numberOfElements * 4 // 3) highBit So....the problem is that you always increase the size of the MD. So when you do: newInstance := self species new: self basicSize - 1. "Make sure it has the same capacity" if fact you are creating a MD of a different size, which means that the capacity is different and hence, using #copyFrom: will create inconsisten MD loosing methods, which causes the crash now. You could add a newInstance capacity = self capacity ifTrue: [ self copyFrom: newInstance ] ifFalse: [ self becomeForward: newInstance ] but that doesn't make sense because you always increase, so you will end up using always the become. I guess you can change to this: newInstance := self species new: self size. "Make sure it has the same capacity" but the problem is if in the future we change again #sizeFor. So....I think a correct solution could be something like this: newInstance := (self species basicNew: self basicSize) initialize: self basicSize. "Make sure it has the same capacity" or..move that to MethodDict class side and do: newInstance := (self species newWithExactBasicSize: self basicSize) "Make sure it has the same capacity" newWithExactBasicSize: basicSize ^(self basicNew: basicSize) initialize: basicSize what do you think ? Cheers On Sun, Sep 18, 2011 at 8:13 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sun, Sep 18, 2011 at 5:40 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> I'm not quite sure it is correct. >> The problem is if another Process want to use this MethodDictionary >> while it is in an inconsistent state... >> Or if you are rehashing on of the MethodDictionary which contains one >> of the methods used by the rehashing itself. >> > > Interesting. Thanks Nicolas for the pointer. > > >> See recent changes from Levente in trunk. >> >> > heheheheh it seems Levente is still reading the Pharo mailing list. > So...I took his commits of today, and I have made a Pharo change set. > I have put all the information here: > http://code.google.com/p/pharo/issues/detail?id=4826 > > Basically, he used #copyFrom: which is primitive and hence it avoids the > inconsistent state. > > If someone can check the changeset and give the OK, we can integrate it. > > Thanks a lot > > >> Nicolas >> >> 2011/9/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > >> > >> > On Sat, Sep 17, 2011 at 10:26 PM, Nicolas Cellier >> > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >> >> 2011/9/17 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> > Hi guys. I was checking MethodDictionary >> rehash and this is >> terribly >> >> > slow >> >> > because of the #become. Then I saw #rehashWithoutBecome but it >> answers >> >> > a >> >> > different instance. I need a #rehash that does the rehash in the real >> >> > object >> >> > and answers self. So...I need the regular #rehash but I want to avoid >> >> > the >> >> > #become. Is that possible somehow? >> >> > >> >> > This is the current implementation: >> >> > >> >> > rehashWithoutBecome >> >> > >> >> > | newInstance | >> >> > newInstance := self species new: self basicSize - 1. "Make sure >> it >> >> > has >> >> > the same capacity" >> >> > 1 to: self basicSize do: [ :index | >> >> > (self basicAt: index) ifNotNil: [ :key | >> >> > newInstance at: key put: (array at: index) ] ]. >> >> > ^newInstance >> >> > >> >> > I am terrible bad with Collection and friends, but cannot we do >> >> > soemthing >> >> > like this: >> >> > >> >> > rehashWithoutBecome >> >> > >> >> > | newInstance | >> >> > newInstance := self species new: self basicSize - 1. "Make sure >> it >> >> > has >> >> > the same capacity" >> >> > >> >> > 1 to: self basicSize do: [ :index | >> >> > (self basicAt: index) ifNotNil: [ :key | >> >> > newInstance at: key put: (array at: index) ] ]. >> >> > >> >> > 1 to: newInstance basicSize do: [ :index | >> >> > (newInstance basicAt: index) ifNotNil: [ :key | >> >> > self at: key put: (newInstance array at: index) ] ]. >> >> > >> >> > ^ self >> >> > >> >> >> >> I guess you should at least also copy the nil entries... >> >> Maybe something like >> >> >> >> 1 to: newInstance basicSize do: [ :index | >> >> self basicAt: index put: (newInstance basicAt: index). >> >> array at: index put: (newInstance array at: index)]. >> >> >> > >> > >> > Good point. So....I was not that mistaken ;) >> > I have just replaced CompiledMethod >> hash with this new method and at >> > least all the tests in MethodDictionaryTest are green. >> > Do you think this implementation is correct or there can be problems? >> > because it is really MUCH faster than the original one. >> > >> > Thanks in advance >> > >> >> >> >> > >> >> > Thanks for any help. >> >> > >> >> > >> >> > -- >> >> > Mariano >> >> > http://marianopeck.wordpress.com >> >> > >> >> > >> >> >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

2 3

[Pharo-project] OSProcess bug affecting OSP 4.4.4 on Windows
by David T. Lewis Sept. 27, 2011

Sept. 27, 2011

If you are using OSProcess and have updated to version 4.4.4 posted to SqueakSource 10-Sept-2011, please update once more to the latest version 4.4.5 posted today. Version 4.4.4 contained a bug that hangs the image during startup on Windows. Version 4.4.5 reverts the changes that cause the problem. Thanks to Radoslav Hodnicak for finding and reporting the problem, and my apologies for any problems that this may have caused. Dave

2 1

[Pharo-project] windows vm to open large images
by Tudor Girba Sept. 27, 2011

Sept. 27, 2011

Hi, I am raising the issue regarding opening large images (400+ MB) on Windows. I currently have a Pharo 1.3 image and I cannot load it anymore once I save it. The behavior is rather odd now: it shows the window and then it crashes silently without leaving anything behind. Igor provided a fix some months ago, but it seems it is not in the released Cog VM (neither the one from the Pharo website 13307, nor the latest one of Elliot). So: - Igor, do you know what is the status of your fix? - Where can I actually get a Stack VM for Windows (I tried all places I could think of and did not find it)? Cheers, Doru -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

2 2

Re: [Pharo-project] google issue 3236
by Marcus Denker Sept. 27, 2011

Sept. 27, 2011

On Sep 26, 2011, at 4:36 PM, Norbert Hartl wrote: > Does anybody know what happened to > > http://code.google.com/p/pharo/issues/detail?id=3236 > > In pharo-1.3 and pharo-1.4 they aren't in. Well, that matches the status of FixedWaitingToBePharoed. Last change by Marcus is from April 7th. > Every issue not closed has yet to be done. So the anwer is: Nothing happend. Marcus -- Marcus Denker -- http://marcusdenker.de

3 6

[Pharo-project] [update 1.4] #14168
by Marcus Denker Sept. 27, 2011

Sept. 27, 2011

14168 ----- Issue 4809: PluggableListMorph improvment http://code.google.com/p/pharo/issues/detail?id=4809 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] new Cog VMs available...
by Eliot Miranda Sept. 26, 2011

Sept. 26, 2011

...in http://www.mirandabanda.org/files/Cog/VM/VM.r2495/. These fix the regression introduced in r2487 in introducing faster MNu processing. The bug was the leaking up of an error code that was misinterpreted as a valid target machine code method. Thanks /very/ much to those of you who tested the 2493 & 2494 VMs. With your help this bug was found quickly. I now have reason to hope that these VMs will be quite stable. Here's the readme: CogVM binaries as per VMMaker.oscog-eem.127/r2495. Fix MNU PIC creation not to answer an error code to the interpreter. This is the call 0x00000013 bug. again thanks -- best, Eliot

2 3

[Pharo-project] [update 1.4] #14167
by Marcus Denker Sept. 26, 2011

Sept. 26, 2011

14167 ----- Issue 4861: Enhance TickDialog http://code.google.com/p/pharo/issues/detail?id=4861 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] google issue 3236
by Norbert Hartl Sept. 26, 2011

Sept. 26, 2011

Does anybody know what happened to http://code.google.com/p/pharo/issues/detail?id=3236 In pharo-1.3 and pharo-1.4 they aren't in. Well, that matches the status of FixedWaitingToBePharoed. Last change by Marcus is from April 7th. Norbert

1 0

[Pharo-project] www.squeakdbx.org temporally moved
by Mariano Martinez Peck Sept. 26, 2011

Sept. 26, 2011

Hi guys. www.squeakdbx.org was temporally moved to http://dbxtalk.smallworks.com.ar/ (thanks SmallWorks for always host our image) We didn't yet update the website to match DBXTalk project, but soon we will do it and when that happens we will register www.dbxtalk.org and shut down http://dbxtalk.smallworks.com.ar/ Cheers DBXTalk team

1 0

[Pharo-project] [update 1.4] #14165
by Marcus Denker Sept. 26, 2011

Sept. 26, 2011

14165 ----- Issue 4858: Fix some undeclareds in Scriptloader http://code.google.com/p/pharo/issues/detail?id=4858 Issue 4857: Move Finder to Tools package http://code.google.com/p/pharo/issues/detail?id=4857 Issue 4859: Ballon package contains tests http://code.google.com/p/pharo/issues/detail?id=4859 -- Marcus Denker -- http://marcusdenker.de

1 0