#decompileBlock: eats names of block arguments

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

#decompileBlock: eats names of block arguments

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: #decompileBlock: eats names of block arguments

Damien Cassou
2009/4/15 Dennis Schetinin <[hidden email]>:

> [: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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: #decompileBlock: eats names of block arguments

Nicolas Cellier
2009/4/15 Damien Cassou <[hidden email]>:

> 2009/4/15 Dennis Schetinin <[hidden email]>:
>> [: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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: #decompileBlock: eats names of block arguments

Nicolas Cellier
Issue http://code.google.com/p/pharo/issues/detail?id=743

2009/4/15 Nicolas Cellier <[hidden email]>:

> 2009/4/15 Damien Cassou <[hidden email]>:
>> 2009/4/15 Dennis Schetinin <[hidden email]>:
>>> [: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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project