> On 14 Oct 2014, at 16:42, Marcus Denker <marcus.den...@inria.fr> wrote:
>
>>
>> On 10 Oct 2014, at 12:29, Marcus Denker <marcus.den...@inria.fr
>> <mailto:marcus.den...@inria.fr>> wrote:
>>
>>
>>> On 10 Oct 2014, at 10:57, Jan Kurš <k...@iam.unibe.ch
>>> <mailto:k...@iam.unibe.ch>> wrote:
>>>
>>> Hi All,
>>>
>>> Thank you for the replies. I see it is not an easy bug to fix. Do you have
>>> any idea, when this can be fixed?
>>>
>> I will try to fix it next week...
>>
>>> Or can you suggest me some other way/workaround, how to get/generate the
>>> source code of a block?
>>>
>>
>> The old compiler used a hack to decompile blocks for getting a textual
>> representation… one could port
>> the code from Pharo2 to the Package OpalDecompiler in Pharo4. (but I
>> actually like the current scheme of
>> using the byte code-offset-to-AST mapping more).
>>
>
> step one: A nice tool… GTInspector view of the byte codes that highlights
> what is thinks is the corresponding code in the source.
> (This living Bytecode view replaces what before just printed out the
> #longPrintString of the CompiledMethod):
>
This is now in 4.0 update 306.
e.g. inspect
OrderedCollection>>#do:
then select the “SymbolicBC” tab, click on a byte code, then select in the
second view the “Source” tab.
==> when moving around the byte code, the text highlights the code that
generated the byte code.
Marcus
