Marcus Denker wrote:
On 14 Oct 2014, at 16:42, Marcus Denker <marcus.den...@inria.fr
<mailto: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
This is be great to pull more people into understanding (and helping)
the dark depths. What about a tab in the second pane named "Help" that
describes what each bytecode does? (half serious)
For example, line 32, what is the "2" in "pushTemp: 2", and "1" in
"pushConstant: 1".
cheers -ben
