On Thu, Mar 26, 2009 at 1:24 AM, Lukas Renggli
<renggli@iam.unibe.ch> 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