Marcus Denker wrote:
On 14 Oct 2014, at 16:42, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 10 Oct 2014, at 12:29, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 10 Oct 2014, at 10:57, Jan Kurš <kurs@iam.unibe.ch <mailto:kurs@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