Hello,

I looked in the literature and there are a few paper about exactly the visualization I want.

Examples:

a paper about Graph Layout for Code Flow Visualization�

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.3748&rep=rep1&type=pdf

a bachelor thesis on java control flow graph visualization for compiler optimization

http://ssw.jku.at/General/Staff/TW/Wuerthinger06Bachelor.pdf

Perhaps at some point if we find a bachelor to hire in our team we could ask him to implement such a visualization too (as they did for java seemingly).

But I looked at java's control flow graph I saw they would not increase much my productivity compared to what I have now, back jumps are displayed but not in a so good way. Therefore I'll use what I have now. However it would be nice to have that to teach easily compiler optimizations to people.

Doru,

I *really* need dedicated tools but I have already built them myself. A year ago, I didn't know about GTInspector and Moldable debugger, so I built dedicated inspectors with the old inspector framework of Pharo, then as it was not good enough I built new inspectors based on Spec, and I ported the generic classes of these inspectors in Pharo 3. Specific subclasses of these inspectors exist for my projects. For example, here's an inspector of an object in memory (an object oriented pointer):

With on the left the current address in memory, then what field it is for the object (which is the class MethodDictionary), then the address written at this memory location, and the result of #printString sent to this new address.

The next tool I'm going to built is a read only debugger (I mean without on the fly method edition) to step on x86 disassembled instructions and its abstract representation (similar to Register Transfer Language)�I used in my compilation chain. I discussed once with Andrei and it seems the moldable debugger fits more in the case where you need to debug smalltalk code or at least byte code dependent code. In my case I compile from AST to x86 skipping the byte code so as far as I know it is quite hard to build a tool with what you have. In addition, I'd like to plug the Spec inspectors I built before, which may not be easy if I choose to build the additional tools in Glamour. So the timing is not very good for tools in my projects.

Thanks for offering your help anyway.

However the tool you showed on RB AST is really cool, especially that I use all the time intermediate representations that could perfectly fit this kind of inspectors (mostly graphs). But I prefer visualization like the one of roassal.�

Regards

2014/1/15 Marcus Denker <marcus.denker@inria.fr>

On 14 Jan 2014, at 22:06, Tudor Girba <tudor@tudorgirba.com> wrote:
>
> As far as I can see, the visualization is derived from source code. This can be seen as being similar to how an AST is derived from source code. The GTInspector already provides an implementation of understanding this mapping. For example, in an image with GTInspector (just download the Moose one for quick tests) do:
> (Collection>>#collect:) parseTree inspect
>
> and you get a picture like the attached one.

> <Inspector on a RBMethodNode (coll...ion).png>

This is *very* impressive� :-)

� � � � Marcus