- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: Pharo 1,1 -beta

by StÃ©phane Ducasse

:) No political correctness please :) We have the rights to disagree :) Begin forwarded message: > From: Henrik Johansen <henrik.s.johansen(a)veloxit.no> > Date: May 9, 2010 2:09:35 AM GMT+02:00 > To: "stephane.ducasse(a)gmail.com" <stephane.ducasse(a)gmail.com> > Subject: Pharo 1,1 -beta > > Dear Stephane. > Please forward to whomever else it may concern, a bit too rantish to send to the general mailing list though :) > I'd wish we were able to meet face to face, as the 2 points I'd like to make would be much easier to make without creating any sort of animosity if I had an an instant opportunity to clearify any details. > > 1.RevertLinkedLists or not, I don't really care. (though, reading through my late-night posts, some degree of personal pride might wrongfully be read into it, for which I apologize) > It's a trade-off between handling adding objects and links equivalently, or disallowing this. The current implementation is easier to use, while one which allows adding links only is simpler implementation-wise. > It IS important to reach a deciscion for 1.1 though, as it can have long-lasting consequences support-wise. > No matter what the outcome, please don't remove the objective improvements over Squeak, like the swap method, which actually works. ;) > > Point 2: We CAN NOT release a beta version of 1.1 in which WeakDictionaries depend on their users to register them for finalization in order to work correctly/reliably. > The idea behind the new weakdicts is sound (avoid rehashes whenever removals occur), the implementation however is unsound. (independent of the 10 or so issues which have been resolved for it so far). I have detailed some of my frustrations in comments to / new issues, afraid I can't reference those when writing from my iPhone though. > > The weather here at my friend's is really nice, and I hope you (and Lukas?)'ll have better weather tomorrow :D > > Cheers, > Henry

May 9, 2010

Re: [Pharo-project] Issue 2397 fixed and ready to harvest

by StÃ©phane Ducasse

Thanks! On May 9, 2010, at 3:09 AM, Torsten Bergmann wrote: > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > 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

Stef On May 9, 2010, at 3:47 AM, Igor Stasenko wrote: > 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]]. Yes clearly a conceptual bug. But with the solution alain proposed ie not destroying while iterating on methods does not work (yes it condenses well but accessing some methods is broken). Lukas did a cool test that checks whether the we can parse the method. > > 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. > > _______________________________________________ > 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

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