Re: [Pharo-project] Decompiler problem (leading to infinite loop of opening debuggers)
On May 18, 2011, at 1:26 PM, Toon Verwaest wrote:
I haven't figured out the exact decompiler bug yet, but just so you can easily fix your problem:
I tested on 1.3, and it's fixed there... we synced in 1.3 with some fixes from the old compiler. We could backport the compiler fixes to 1.2...
just move the temp in the whileFalse: [ |newReqd| to the toplevel of the method (if this is semantically equivalent; but it looks like). Then it can actually decompile it ;)
cheers, Toon
On 05/18/2011 12:16 PM, Johan Brichau wrote:
(MetacelloMCVersionSpec compiledMethodAt: #resolveToLoadableSpecs:map:) decompileWithTemps
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
On 05/18/2011 01:30 PM, Marcus Denker wrote:
On May 18, 2011, at 1:26 PM, Toon Verwaest wrote:
I haven't figured out the exact decompiler bug yet, but just so you can easily fix your problem:
I tested on 1.3, and it's fixed there... we synced in 1.3 with some fixes from the old compiler.
We could backport the compiler fixes to 1.2... Oh ok, then I don't even look further. But that decompiler is a mess ... moving to OPAL would be a great improvement I'd say ...
just move the temp in the whileFalse: [ |newReqd| to the toplevel of the method (if this is semantically equivalent; but it looks like). Then it can actually decompile it ;)
cheers, Toon
On 05/18/2011 12:16 PM, Johan Brichau wrote:
(MetacelloMCVersionSpec compiledMethodAt: #resolveToLoadableSpecs:map:) decompileWithTemps
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
thanks guys! I didn't test in 1.3 indeed. btw, since moving to 1.2, after doing pullup or pushdown refactorings, I often get methods that badly reference instance variables. Their instvar index seems to be off in the sense that the name references another variable. I can fix the problem by recompiling the method but it's quite a pain. Unfortunately, I have been unsuccessful in creating a scenario that always works... I hope to do that asap.
2011/5/18 Toon Verwaest <toon.verwaest@gmail.com>:
On 05/18/2011 01:30 PM, Marcus Denker wrote:
On May 18, 2011, at 1:26 PM, Toon Verwaest wrote:
I haven't figured out the exact decompiler bug yet, but just so you can easily fix your problem:
I tested on 1.3, and it's fixed there... we synced in 1.3 with some fixes from the old compiler.
We could backport the compiler fixes to 1.2...
Oh ok, then I don't even look further. But that decompiler is a mess ... moving to OPAL would be a great improvement I'd say ...
Yes this code is very hard to track by just reading code... So hard to maintain too. Too many states in a single class. And you often discover that the processing you were looking for in fact was coded somewhere else (like in MessageNode). The best way to understand the old Decompiler is to debugIt. Nicolas
just move the temp in the whileFalse: [ |newReqd| to the toplevel of the method (if this is semantically equivalent; but it looks like). Then it can actually decompile it ;)
cheers, Toon
On 05/18/2011 12:16 PM, Johan Brichau wrote:
 (MetacelloMCVersionSpec compiledMethodAt: #resolveToLoadableSpecs:map:) decompileWithTemps
-- Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
participants (4)
-
Johan Brichau -
Marcus Denker -
Nicolas Cellier -
Toon Verwaest