May 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by StÃ©phane Ducasse

probably flushing the cache of MC and PragmaBuilder Stef On May 9, 2010, at 4:02 AM, Igor Stasenko wrote: > After condensing changes and #destroySourcePointer, > the garbage 12k methods magically disappeared, so now its just: > > (CompiledMethod allInstances reject: #isInstalled) size 67 > > and image after saving shrunk from 14M to 13M > probably some cache somewhere not flushed.. > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 9, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by StÃ©phane Ducasse

> Hi. > I made a little investigation.. Thanks. > The changes file condensing works fine. Yes we got that too. And sometimes it did not finished depending on the actual changes. The problem was in that case that after some methods were impossible to browse. > Except that there something wrong with destroying source pointers of > not-installed methods. > > After commenting a following line: > " CompiledMethod allInstancesDo: [:e | e isInstalled ifFalse: [e > destroySourcePointer]]. " > > It were able to run to an end, and by running this check: > | empty | > empty := Set new. > Smalltalk allClassesAndTraitsDo: [:classOrTrait | > empty addAll: ( classOrTrait methodDict select: [:m | m sourcePointer =0 ]) > ]. > empty isEmpty > -->> prints true > > which means there is no installed methods with sourcePointer = 0 (and > hence with no source code) after condensing the changes. > > > But what makes me really suspicious is following: > > CompiledMethod allInstances size 55797 > (CompiledMethod allInstances reject: #isInstalled) size 12586 > > it looks like #isInstalled is buggy, or otherwise indicating that > there is problem with image, > which keeps so many non-installed methods hanging around. > I would simply put a following at the beginning of #condenseChanges: > > (CompiledMethod allInstances reject: #isInstalled) size > 0 ifTrue: [ > self error: 'first, get rid of any uninstalled methods' ]. > > So, then you would not need to use #destroySourcePointer :) > > Here an alternative version of #destroySourcePointer. But it doesn't > makes any big difference. > > destroySourcePointer > > "We can't change the trailer of existing method, since > it could have completely different format. Therefore we need to > generate a copy with new trailer, and then #become it" > | copy | > copy := self copyWithTrailerBytes: CompiledMethodTrailer empty. > self becomeForward: copy. > ^ copy > > > P.S. runned it on 1.1-11343-UNSTABLE > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 9, 2010

Re: [Pharo-project] NetNameResolver in Pharo 1.1

by Michael Roberts

On Sun, May 9, 2010 at 9:06 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >> We should run the Magma test suite. > > Could you do that? Yes, i'm just asking Chris what the latest packages are. My emails on the subject don't seem to match the repository any more. > >> It was not just related to those NetNameResolver methods IIRC. The API >> changed very slightly. Â Also, the lazy initialization of useOldNetwork >> made it really difficult to see what was going on. > > In my experiments #useOldNetwork was always 'false' on all platforms > (Mac, Linux and Windows). Is this something that depends on the VM? I don't think so. I think it could just get into an odd state. Perhaps when using OSProcess to spawn/fork new images? > Maybe we should rather remove the old network code and throw an error > if somebody is using an old VM that doesn't support the new > primitives. I would really like to remove the old network code. Definitely remove the switch and all the parallel code paths. Also, to me the network should be initialized on image startup once, and not when the first message is sent to the network classes. There are far too many checks for it. We need to be careful what the old and new API are. this is where documentation would really help. I ran your methods quickly. I'm a bit confused. NetNameResolver is now only returning a single address on my machine whereas before it returned a list of many for the local host. This was part of the problem, in that there was no order. There are various threads on it. But what changed to cause this? Did we change 1.1 or the VM has a small change? i didn't track either. cheers, Mike > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 9, 2010

Re: [Pharo-project] NetNameResolver in Pharo 1.1

by Lukas Renggli

> We should run the Magma test suite. Could you do that? > It was not just related to those NetNameResolver methods IIRC. The API > changed very slightly. Â Also, the lazy initialization of useOldNetwork > made it really difficult to see what was going on. In my experiments #useOldNetwork was always 'false' on all platforms (Mac, Linux and Windows). Is this something that depends on the VM? Maybe we should rather remove the old network code and throw an error if somebody is using an old VM that doesn't support the new primitives. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 9, 2010

[Pharo-project] Build squeak vm screencast updated (with FT2Plugin and Alien)

by laurent laffont

on pharocasts: http://pharocasts.blogspot.com/2010/03/build-squeak-vm-on-linux.html Feedback always appreciated :) Cheers, Laurent Laffont

May 9, 2010

Re: [Pharo-project] NetNameResolver in Pharo 1.1

by Michael Roberts

We should run the Magma test suite. It was not just related to those NetNameResolver methods IIRC. The API changed very slightly. Also, the lazy initialization of useOldNetwork made it really difficult to see what was going on. I'll have a dig around. cheers, Mike On Sat, May 8, 2010 at 4:54 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > In Pharo 1.0 there were some problems with the network stack (namely > the NetNameResolver) and the IP6 code was reverted shortly before > release, see the following issue for details: > > Â Â http://code.google.com/p/pharo/issues/detail?id=1884 > > Today I was checking with Stef for the presence of these problems in > Pharo 1.1, but we could not reproduce neither on Mac, Windows nor > Linux. Does anybody have problems with the following expressions in > Pharo 1.1? > > Â Â NetNameResolver localHostAddress. > Â Â NetNameResolver addressForName: 'www.yahoo.com'. > > Or are we doing the wrong thing to reproduce? > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 9, 2010

[Pharo-project] Emerging Languages Camp

by Serge Stinckwich

No one could talk about Pharo at this event ? http://emerginglangs.com/speakers/ -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

May 9, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by Igor Stasenko

After condensing changes and #destroySourcePointer, the garbage 12k methods magically disappeared, so now its just: (CompiledMethod allInstances reject: #isInstalled) size 67 and image after saving shrunk from 14M to 13M probably some cache somewhere not flushed.. -- Best regards, Igor Stasenko AKA sig.

May 9, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by Igor Stasenko

And the last thing... since new trailers using #becomeForward: no wonder that this loop turns into an infinite: CompiledMethod allInstancesDo: [:e | e isInstalled ifFalse: [e destroySourcePointer]]. because #allInstancesDo: walks a heap, and assuming that there is no new instances of it created during walking. But destroySourcePointer creating a new instance, so it can never finish! :) i just replaced it with following: (CompiledMethod allInstances reject: #isInstalled) do: [:e | e isInstalled ifFalse: [e destroySourcePointer]]. and made it to the end.. took about 5 minutes to wait. (12k methods + become on every method is a little time consuming ;) -- Best regards, Igor Stasenko AKA sig.

May 9, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by Igor Stasenko

Oh, and i think there's no problem with #destroySourcePointer it just takes too long, and looks like your image is hung, because you can't wait untill it chews all 12k methods.. Just tried to do it with a random method: CompiledMethod allInstances atRandom copy destroySourcePointer getSource and it works fine. -- Best regards, Igor Stasenko AKA sig.

May 9, 2010