April 2009 - Pharo-dev - lists.pharo.org

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

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

by Nicolas Cellier

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

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

by Damien Cassou

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. -- Damien Cassou http://damiencassou.seasidehosting.st

April 15, 2009

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

by Dennis Schetinin

*[: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... -- Dennis Schetinin

April 15, 2009

Re: [Pharo-project] New Pharo-dev based on 10277

by Damien Cassou

On Wed, Apr 15, 2009 at 7:03 AM, Geert <geert.wl.claes(a)gmail.com> wrote: > http://pharo-project.org/download > Will there be pharo-web version too? I've built a pharo-web last week. I'll build a new one beginning of May. > What is actually the planned naming scheme for the various Pharo image versions? > - Pharo-Core Pharo-Core is a coherent small set of packages on which pharo-code developers can work and which will be used for web servers. > - Pharo (Pharo-Core + IDE?) Pharo is the current pharo-dev > - Pharo-Dev (Pharo-Core + IDE + Dev tools?) pharo-dev won't exist anymore and will be renamed Pharo. > - Pharo-Web (Pharo-Core + IDE + Dev tools? + Web tools?) > Is there really a need to have both Pharo-Dev and Pharo-Web or just a Pharo-Web? I don't know what we want to do with pharo-web. -- Damien Cassou http://damiencassou.seasidehosting.st

April 15, 2009