- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Arg assignement [Fwd: how can we sync]

by Nicolas Cellier

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 <stephane.ducasse(a)inria.fr>: > > > Begin forwarded message: > > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: April 2, 2009 11:09:14 PM CEDT > To: Lukas Renggli <renggli(a)iam.unibe.ch> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, Marcus Denker > <denker(a)iam.unibe.ch>, Michael Rueger <m.rueger(a)acm.org>, Adrian Lienhard > <alienhard(a)netstyle.ch>, John McIntosh <johnmci(a)smalltalkconsulting.com> > Subject: Re: how can we sync > > > On Thu, Mar 26, 2009 at 1:24 AM, Lukas Renggli <renggli(a)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 >> > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 15, 2009

Re: [Pharo-project] WeakArray class>>#finalizationProcess

by StÃ©phane Ducasse

>>> > Was this conversation off-list? I can't find it here, on squeakvm or > squeak.general (or my eyes get old) ;-) I just forward it to the list. We were also checking how we can keep up with the changes of eliot. I should have a look carefully at them. >> Normally we should remove all the argument assignment. >> I just did not get the time to go over the next batch. > > Well, I would have made it on my own (the pharo web image I'm on only > complained about the progressbar and imagesegment methods), Strange I fixed those ones. Can you check if you have the same problem in the latest? > but this one > explicitly stated that WeakArray (and therefor anything "weak") > breaks if > the assignment is deleted (and it would be pointless to nil a temp > val, I > agree), so I'm curious. See the other email :) > Btw., Is there a Closure-FFI somewhere? I tried to load the vanilla > FFI-Kernel-ar.8.mcz (and thereafter fixing the ExternalType method) > but that > seriously killed my image (not sure if anything else interferred). Torsten sent us a loadFFI now available in scriptLoader in one the latest updates. Can you check? > And I > think it was the combination of WeakArrays not being weak and > something of > the FFI-package. But I'm not sure, so I don't want to rant (let's > say it > just happened coincidentally ;)). If you can reproduce that with the latest (updated image). Let us know. We are chasing bugs now. Stef

April 15, 2009

[Pharo-project] Arg assignement [Fwd: how can we sync]

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: April 2, 2009 11:09:14 PM CEDT > To: Lukas Renggli <renggli(a)iam.unibe.ch> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, Marcus Denker <denker(a)iam.unibe.ch > >, Michael Rueger <m.rueger(a)acm.org>, Adrian Lienhard <alienhard(a)netstyle.ch > >, John McIntosh <johnmci(a)smalltalkconsulting.com> > Subject: Re: how can we sync > > > > On Thu, Mar 26, 2009 at 1:24 AM, Lukas Renggli > <renggli(a)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 > >

April 15, 2009

Re: [Pharo-project] WeakArray class>>#finalizationProcess

by Markus Fritsche

StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> There were some notes traded by Eliot, on >> WeakArray>>#finalizationProcess between Stephane, Marcus Denker, >> Michael Rueger, Adrian Lienhard on this topic between march 26th - >> April 2nd. Was this conversation off-list? I can't find it here, on squeakvm or squeak.general (or my eyes get old) ;-) > Normally we should remove all the argument assignment. > I just did not get the time to go over the next batch. Well, I would have made it on my own (the pharo web image I'm on only complained about the progressbar and imagesegment methods), but this one explicitly stated that WeakArray (and therefor anything "weak") breaks if the assignment is deleted (and it would be pointless to nil a temp val, I agree), so I'm curious. Btw., Is there a Closure-FFI somewhere? I tried to load the vanilla FFI-Kernel-ar.8.mcz (and thereafter fixing the ExternalType method) but that seriously killed my image (not sure if anything else interferred). And I think it was the combination of WeakArrays not being weak and something of the FFI-package. But I'm not sure, so I don't want to rant (let's say it just happened coincidentally ;)). Regards, Markus

April 15, 2009

Re: [Pharo-project] WeakArray class>>#finalizationProcess

by StÃ©phane Ducasse

Normally we should remove all the argument assignment. I just did not get the time to go over the next batch. Stef On Apr 15, 2009, at 8:42 PM, John M McIntosh wrote: > There were some notes traded by Eliot, on > WeakArray>>#finalizationProcess between Stephane, Marcus Denker, > Michael Rueger, Adrian Lienhard on this topic between march 26th - > April 2nd. > > Stephane said he was gong to review some changes sets from Eliot about > this issue. > > On 15-Apr-09, at 11:14 AM, Markus Fritsche wrote: > >> Hello, >> >> I just noticed that WeakArray class>>#finalizationProcess won't >> compile with >> the with the assignment to block args set to off. >> >> Is it okay to change that in the preferences or is the finalization >> process >> broken then? >> >> Kind regards, >> Markus >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 15, 2009

Re: [Pharo-project] WeakArray class>>#finalizationProcess

by John M McIntosh

There were some notes traded by Eliot, on WeakArray>>#finalizationProcess between Stephane, Marcus Denker, Michael Rueger, Adrian Lienhard on this topic between march 26th - April 2nd. Stephane said he was gong to review some changes sets from Eliot about this issue. On 15-Apr-09, at 11:14 AM, Markus Fritsche wrote: > Hello, > > I just noticed that WeakArray class>>#finalizationProcess won't > compile with > the with the assignment to block args set to off. > > Is it okay to change that in the preferences or is the finalization > process > broken then? > > Kind regards, > Markus > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

April 15, 2009

[Pharo-project] WeakArray class>>#finalizationProcess

by Markus Fritsche

Hello, I just noticed that WeakArray class>>#finalizationProcess won't compile with the with the assignment to block args set to off. Is it okay to change that in the preferences or is the finalization process broken then? Kind regards, Markus

April 15, 2009

Re: [Pharo-project] Issue 722: some methods missing in BlockClosure

by StÃ©phane Ducasse

Thanks. I hope to get some time later this evening. stef On Apr 15, 2009, at 6:05 PM, Nicolas Cellier wrote: > I added missing methods for issue > http://code.google.com/p/pharo/issues/detail?id=722 > in PhaoInbox/Services-Base-nice.48 > and PharoInbox/Kernel-nice.renggli.289 > (I did not make a SLICE) > > These two preserve author name and date from BlockContext since they > are pure copies of code. > > PharoInbox/Kernel-nice.renggli.289 also merge PharoInbox/Kernel- > nice.renggli.288 > which solve http://code.google.com/p/pharo/issues/detail?id=726 > (missing BlockClosure>>#sender) > > It does not merge Michael changes about events. > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 15, 2009

Re: [Pharo-project] #decompileBlock: eats names of block arguments

by Nicolas Cellier

Issue http://code.google.com/p/pharo/issues/detail?id=743 2009/4/15 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/4/15 Damien Cassou <damien.cassou(a)gmail.com>: >> 2009/4/15 Dennis Schetinin <chaetal(a)gmail.com>: >>> [:a :b | a+b] decompile decompileString >>> >>> gives '[:t1 :t2 | t1 + t2]' >>> >>> (The same thing when I decompile block defined in method) >>> >>> (In #decompileBlock:) the branch >>> Â Â method fileIndex ~~ 0Â ifTrue: [...] >>> finds all tempVar names including block's arguments but then they are eaten >>> by >>> Â self initSymbols: homeClass >>> where only tempVars defined by method itself survive... >>> >>> ... and I don't know how to fix it... >> >> I think that is perfectly normal. The bytecode do not need the >> variable names, only their indices. >> > > Yes but it is convenient to have a decompileString preserving those names. > Also it would be interesting to check decompilation of nested blocks like: > > [:i :j | (i to: j) collect: [:k | j-k+i]] decompile decompileString > > > '[:t1 :t2 | (t1 to: t2) > Â Â Â Â Â Â Â Â collect: [:t1 | t2 - t1 + t1]]' > > Argh a bug! > > Nicolas > > >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

April 15, 2009

[Pharo-project] Issue 722: some methods missing in BlockClosure

by Nicolas Cellier

I added missing methods for issue http://code.google.com/p/pharo/issues/detail?id=722 in PhaoInbox/Services-Base-nice.48 and PharoInbox/Kernel-nice.renggli.289 (I did not make a SLICE) These two preserve author name and date from BlockContext since they are pure copies of code. PharoInbox/Kernel-nice.renggli.289 also merge PharoInbox/Kernel-nice.renggli.288 which solve http://code.google.com/p/pharo/issues/detail?id=726 (missing BlockClosure>>#sender) It does not merge Michael changes about events. Nicolas

April 15, 2009