September 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Vm-dev] I don't understand the GC root table
by Mariano Martinez Peck Sept. 27, 2011

Sept. 27, 2011

Thanks guys. Indeed, I was totally confused. Maybe 'rootTable' is a little bit confusing... What do you think about changing at least the selector from image side (Smalltalk rootTable)? or it would be even more confusing? Thanks! On Mon, Sep 26, 2011 at 2:06 PM, Stefan Marr <squeak(a)stefan-marr.de> wrote: > > Hi: > > On 26 Sep 2011, at 13:22, Andreas Raab wrote: > > > The rootTable is used during incremental GC. Its contents are those > objects in old space that are roots for objects in new space (see > ObjectMemory>>beRootIfOld:). It has nothing to do with the (global) roots of > the interpreter; in fact the root table is cleared right at the beginning of > fullGC (see senders of #clearRootsTable). The global roots are explicitly > enumerated in Interpreter>>markAndTraceInterpreterOops. > > Not sure whether it is worthwhile to change such details, but I belief the > standard terminology would be 'remembered set'. At least that is the typical > name for recorded references between different object sets maintained > separately, AFAIK. > > And it could avoid confusion. > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > -- Mariano http://marianopeck.wordpress.com

1 0

[Pharo-project] System update with .sources file
by Norbert Hartl Sept. 27, 2011

Sept. 27, 2011

I downloaded the 14163 image and did a system update. First I started it without copying the .sources file. While upgrading to 14164 I got a warning which you can see in the attached screenshot. Proceed is working. Then I tested it again with .sources file in place and I didn't got the warning. Is there an easy explanation for this? Norbert

1 0

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

Sept. 27, 2011

14171 ----- Issue 3236: Cuis DateAndTime Enhancement (Part3) http://code.google.com/p/pharo/issues/detail?id=3236 Issue 4845: TestRunner: Show the currently running TestCase with selector and class http://code.google.com/p/pharo/issues/detail?id=4845 -- Marcus Denker -- http://marcusdenker.de

1 0

[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