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

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

by StÃ©phane Ducasse

Arghhhhhhh Apparently I did two condenseChanges and I get a problem with code. I could not browse anymore condenseChanges On May 9, 2010, at 1:09 PM, StÃ©phane Ducasse wrote: > Alain > with the latest unstable it seems to work. > You just have to wait a lot once the progress bar is finished to display. > > Then we got only 34/35 methods not installed which is ok. > I will fix condenseSources then :) > Stef > > > > _______________________________________________ > 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

Alain with the latest unstable it seems to work. You just have to wait a lot once the progress bar is finished to display. Then we got only 34/35 methods not installed which is ok. I will fix condenseSources then :) Stef

May 9, 2010

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

by Lukas Renggli

On 9 May 2010 12:06, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > probably flushing the cache of MC and PragmaBuilder PragmaBuilder seems to refer to a couple of compiled methods that are not installed in the system. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 9, 2010

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

by StÃ©phane Ducasse

but do you save and quit the image. I added a fix to avoid iterate while changing the collection and we will see. On May 9, 2010, at 12:29 PM, Alain Plantec wrote: > Hi all, >>> 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). >> > yes but Igor solution is a little bit different because 'e isInstalled' is tested twice, > one for the reject: and the second in the do: block. > But unfortunately, this solution seems to be broken to. It works one time, but while trying to > condenseChanges again several time, my squeak process is killed without flushing any log. > Alain >> 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 >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > > _______________________________________________ > 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] Build squeak vm screencast updated (with FT2Plugin and Alien)

by Alain Plantec

Le 09/05/2010 09:43, laurent laffont a Ã©crit : > on pharocasts: > http://pharocasts.blogspot.com/2010/03/build-squeak-vm-on-linux.html > > Feedback always appreciated :) Hi Laurent, thanks a lot !!!!! Alain > > Cheers, > > Laurent Laffont > > > _______________________________________________ > 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 Alain Plantec

Hi all, >> 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). > yes but Igor solution is a little bit different because 'e isInstalled' is tested twice, one for the reject: and the second in the do: block. But unfortunately, this solution seems to be broken to. It works one time, but while trying to condenseChanges again several time, my squeak process is killed without flushing any log. Alain > 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 >> > > _______________________________________________ > 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] Fwd: Pharo 1,1 -beta

by StÃ©phane Ducasse

> > Dear Stephane. > Please forward to whomever else it may concern, a bit too rantish to send to the general mailing list though :) No it is not :) It is good to talk and have different opinion. This is what makes life more fun. > 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) I do not read it like proud :) > 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. ;) Sure do not worry. This asLink is a no brainer. I just think that linkedList should be an internal only used by the scheduler stuff :). > 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. That more important than the other issues > 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. Ok what can we do? I'm still stupid with weak stuff. Do you have code? :))) > The weather here at my friend's is really nice, and I hope you (and Lukas?)'ll have better weather tomorrow :D No it is cold here. May be we will dare to go to brugges instead of getting stuck in front of our screens. :) > > Cheers, > Henry

May 9, 2010

[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