The problem was mainly that the UI did not show that it was destroying a lot of methods and I thought it was blocked. So if you wait enough it seems ok. Lukas checked and reparse and check the system and it seems ok.
Stef On May 9, 2010, at 6:55 PM, Igor Stasenko wrote: > Probably , a more crash-proof #condenseChanges > would be to use a mass-become. > So, you are not modifying existing methods, but making their copies > with updated source pointers > and copying their source into new changes file. > Then you do a single mass-become and so, all old methods get swapped > with new ones using a single massive blow. > In that way, its more safe, since if you interrupt the > #condenseChanges in the middle, > you can use debugger and browse the code , and if you decide to abort > it, nothing bad happen, > since methods with new source pointers is held in your temp collection > and not yet applied. > > On 9 May 2010 19:48, Igor Stasenko <[email protected]> wrote: >> On 9 May 2010 13:29, Alain Plantec <[email protected]> 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. >> >> This was a result of lack of attention, not my real intent. :) >> >> In bug entry for this issue i added a method which does just: >> (CompiledMethod allInstances reject: #isInstalled) do: #destroySourcePointer. >> >> there's no way how method can become installed when you changin its trailer. >> So, a single test #isInstalled is sufficient. >> A more faster way is to use a mass-become. >> But i think this is not a place where you need to care too much about >> performance. >> >>> 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. >> >> You mean running #condenseChanges multiple times in a row, or >> interrupting it and then start over again? >> You should know, that it is important to not interrupt it in the >> middle, because when you doing that, >> part of your methods having old source pointers, while rest part >> having new ones, >> and there is no way to tell, which one is correct. >> >>> 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 >>>>> [email protected] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
