I was just reviewing http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/changesets/ ...and focusing on Closure_Usage_Fix.1.cs which has not been loaded in Pharo.
At first glance, I did not see changes about not writing blocks own arguments... Only changes moving some temporaries inside blocks or removing some useless ones, so as to get clean blocks. (Clean blocks which don't write into outside temps should execute faster) Is there a more recent version? Nicolas 2009/4/15 Stéphane Ducasse <[email protected]>: > > > Begin forwarded message: > > From: Eliot Miranda <[email protected]> > Date: April 2, 2009 11:09:14 PM CEDT > To: Lukas Renggli <[email protected]> > Cc: Stéphane Ducasse <[email protected]>, Marcus Denker > <[email protected]>, Michael Rueger <[email protected]>, Adrian Lienhard > <[email protected]>, John McIntosh <[email protected]> > Subject: Re: how can we sync > > > On Thu, Mar 26, 2009 at 1:24 AM, Lukas Renggli <[email protected]> wrote: >> >> Something related ... >> >> In noticed that there are numerous places in the Pharo code that cannot be >> re-compiled anymore, because they assign to block parameters. There are two >> cases: >> >> 1. Things along the following example were a bug in the first place >> anyway, and can be easily fixed: >> >> aCollection inject: 0 into: [ :s :e | s := s + e ] >> >> 2. Then there are also various places where code seems to nil temps to >> avoid garbage collection issues, such as in WeakArray>>#finalizationProcess. >> >> FinalizationDependents do: >> [:weakDependent | >> weakDependent ifNotNil: >> [weakDependent finalizeValues. >> "***Following statement is required to keep >> weakDependent >> from holding onto its value as garbage.***" >> weakDependent := nil]] >> >> I think this is no longer necessary and can be fixed by simply removing >> that assignment as well, however I wanted to get a confirmation by Eliot >> before submitting a batch of fixes in various places of Pharo. > > First of all there is a preference for backward-compatibility (see > preferences category compiler). Turn on allowBlockArgumentAssignment and > the old code can still be compiled (and I believe wrks as it did (yuck)). > The bootstrap enables this preference while it is bootstrapping and then > turns it off once done so that one is discouraged from assigning to block > arguments in new code. At least that's the intent. But since we tend to > load more code than we write I guedss the intent isn't that helpful :) > Second, yes you can get rid of a number of redundant assignments that nil > arguments to prevent retention. Find attached a change set (Closure Usage > Fixes) that includes a few from my image. These either move temporaries > local to a block inside the block (useful for performance) or delete > unnecessary assignments. But beware; these changes should be compared > carefully against the Pharo image as they apply to the current state of the > Qwaq code base which could easily be incompatible. Best to compare > carefully, so to this end... > Third, I wrote a tool to automatically edit methods with method-level temps > that are only used at block level. There's a rather stupid blog post on > developing this. Stupid, because it tries to illustrate programming in the > debugger at the same time and I think it ends up beng confused. Anyway, > find the tool attached. Unsupervised usage is "TempScopeEditor edit". > There is an instance side method editNoCompile that you can use to look at > the output without applying the change, but you'll have to rte tool support > to make this useful. I have a hack for side-by-side method comparisons > based on MethodReference if you want it but I suspect you have more familiar > tools to hand. > Best regards > Eliot > > > >> >> Cheers, >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> > > > > > > _______________________________________________ > 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
