At first glance, I did not see changes about not writing blocks own arguments...
>
>
> Begin forwarded message:
>
> From: Eliot Miranda <
[hidden email]>
> Date: April 2, 2009 11:09:14 PM CEDT
> To: Lukas Renggli <
[hidden email]>
> Cc: Stéphane Ducasse <
[hidden email]>, Marcus Denker
> <
[hidden email]>, Michael Rueger <
[hidden email]>, Adrian Lienhard
> <
[hidden email]>, John McIntosh <
[hidden email]>
> Subject: Re: how can we sync
>
>
> On Thu, Mar 26, 2009 at 1:24 AM, Lukas Renggli <
[hidden email]> 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
>
[hidden email]
>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project>
Locked
Closure Usage Fixes.1.cs (69K)