Hi Doru, I agree that custom tools are valuables. I don't know anyone working in VMs that does not have his own tools. Have you ever looked at the StackVM / CogVM Simulator ? They're cool and similar to what I am doing for my research project. I believe Eliot showed it in some presentation. And see how the java Maxine VM guys sold their inspector tool suite. For the roassal visualization, take the image there: https://ci.inria.fr/rmod/view/Mate/job/Sista/ and execute: (Morph>>#invalidRect:from:) liliCFG convertToSSA roassalVisualisation This should work on any method. The alternative, the text visualization that I used before, is: (Morph>>#invalidRect:from:) liliCFG convertToSSA printString. As you can see in complex control flow the roassal visualization is way better. For the 3 other tools I did/am doing the problem is that the other project is not stable currently. It will be stable again in several months. I have one half- stable image for demo, but even there only the Memory inspector works (the stack inspector is not stable). It requires to bootstrap an image in a byte array, the bootstrapped image being in a different object's format. So I guess I could show you some tools this summer (or this autumn) if you are really interested but not now. Basically there's an inspector for the objects in memory, for the stack, and some kind of cpu instructions debugger. Note that the problem is not in writing tools itself but in building a running system where I could apply the tools. Another interesting tool suite is the one from spoon: 3D visu: http://www.youtube.com/watch?v=FQgMlpQpu7w 2D visu: http://www.youtube.com/watch?v=1Uh8v7IzXJk The first tool would be cool as an alternative to the pointer explorer to detect memory leaks. Cheers, 2014/1/16 Tudor Girba <tudor@tudorgirba.com>
Hi Clement,
I am happy you see value in these specific tools and that you built your own. I strongly believe there is great potential for Pharo in showing how development can change dramatically when these custom tools become cheap, and I would want to collect examples that provide incentives for others to do the same. So now, I am even more interested in taking a look :)
Could you point me to: - the way to setup the image (ideally with scripts starting from a Pharo 3.0 image) - the Spec tools and Roassal visualizations you built - some instances of how to trigger the inspectors and visualizations
?
Cheers, Doru
On Wed, Jan 15, 2014 at 9:45 AM, Clément Bera <bera.clement@gmail.com>wrote:
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&t... 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):
[image: Images intégrées 1]
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 R*egister Transfer Language <http://fr.wikipedia.org/wiki/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
-- www.tudorgirba.com
"Every thing has its own flow"
