- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Compiler class>>closureParserClass

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=741 >>>> That is right? >>>> How to install "closureParserClass"?

April 15, 2009

Re: [Pharo-project] *overrides* in polymorph

by StÃ©phane Ducasse

> Will try to have a look tomorrow (the override does have the problem). > > Still waiting for a list of problematic overrides from the group... ahhh Ideally we would like to have none :) Stef > > The infrastructure is in place to make some "Squeak only". > > This one can apply to both Squeak and Pharo though. > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, April 13, 2009 2:39 PM > Subject: [Pharo-project] *overrides* in polymorph > > >> Hi gary >> >> It seems that I already fixed >> SystemProgressMorph>>label:min:max: >> so that the bloack argument is not written. >> Can you check because if I redo it and it gets overridden I will have >> the smae problem. >> >> stef >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > 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] Fonts working great

by StÃ©phane Ducasse

disaser seems a strong word. It is far better than better. And now we will have another one based on alain's work. Now you can also help. On Apr 15, 2009, at 7:25 AM, Geert wrote: > > Scripts like this are indeed useful ... there should however not be > a need for such scripts if the "Preferences" were easier to manage. > From a usability point of view its not just the fonts that need > attention though, the whole preference browser is currently a bit of > a user experience disaster. > -- > View this message in context: http://n2.nabble.com/Fonts-working-great-tp2466458p2637029.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.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

[Pharo-project] [ANN] 10278 who and parser

by StÃ©phane Ducasse

who is now fixed as well as asiignemtn stef

April 15, 2009

Re: [Pharo-project] Fonts working great

by Geert

Scripts like this are indeed useful ... there should however not be a need for such scripts if the "Preferences" were easier to manage. From a usability point of view its not just the fonts that need attention though, the whole preference browser is currently a bit of a user experience disaster. -- View this message in context: http://n2.nabble.com/Fonts-working-great-tp2466458p2637029.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 15, 2009

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

by Geert

http://pharo-project.org/download Will there be pharo-web version too? What is actually the planned naming scheme for the various Pharo image versions? - Pharo-Core - Pharo (Pharo-Core + IDE?) - Pharo-Dev (Pharo-Core + IDE + Dev tools?) - 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? -- View this message in context: http://n2.nabble.com/New-Pharo-dev-based-on-10277-tp2633337p2636969.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 15, 2009