[Pharo-project] Decompiler problem (leading to infinite loop of opening debuggers)

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed May 18 13:00:12 EDT 2011


2011/5/18 Toon Verwaest <toon.verwaest at 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.
>>
>>
>
>
>




More information about the Pharo-dev mailing list