ATerm Visualization

Customer: Jurriaan Hage jur@cs.uu.nl

Initial Description

Improve and add new features to the ATerm visualization tool suite.

ATerms are a format of the exchange of tree data such as abstract syntax trees (i.e., similar to XML, but a lot less baroque). Here is an example of an ATerm:

Add(Sub(Const(10), Var("x")), Mul(Var("y"), Call("f", [Const(123)])))

This might represent the expression (10 - x) + (y * f(123)) in some imaginary programming language.

These terms can become very large (say, on the order of megabytes). This is not usually a problem, since ATerms are used for communication between software components (e.g., between the various phases of a compiler) and not intended for "human consumption". However, sometimes you do need to read them yourself, for instance when you are debugging a compiler. Then it is very hard to divine any meaning out of:

ExternalDefinition-p([Declaration1(Declaration2(DeclSpec([],Typedef,[],Unsigned,[Int]),[TCons(Declarator1(IdentifierDeclarator
1(IdDecl(Pointer-s([]),Id("size_t"),None))),TCons(None,TNil))])),Declaration1(Declaration2(DeclSpec([],Typedef,[],Long,[Int]),
[TCons(Declarator1(IdentifierDeclarator1(IdDecl(Pointer-s([]),Id("wchar_t"),None))),TCons(None,TNil))])),Declaration1(Declarat
ion2(DeclSpec([],Typedef,[],StructSpecifier(Struct(None,[MemDecl(TypeSpec([],Int,[]),[Declarator(IdentifierDeclarator1(IdDecl(
Pointer-s([]),Id("quot"),None)))]),MemDecl(TypeSpec([],Int,[]),[Declarator(IdentifierDeclarator1(IdDecl(Pointer-s([]),Id("rem"
...

(This is the start of the abstract syntax of a C module; it continues like this for >700 KB.) To make debugging this sort of beast feasible, a number of students have produced a graphical browser for ATerms in Java. The user can in various ways browse an ATerm, interactively zooming in on the interesting bits.

The browser is not yet perfect, however. There are a number of bugs, missing features, and features that could be implemented in a better way. Some refactoring of the code is also in order. The goal of this project is to implement as many of the customer's requirements.

The browser

You can download a jar file of the browser. There are also some ATerms to play with.

Source code is available from Jurriaan Hage (or Eelco Dolstra).

Todo list

Here is the initial list of suggested improvements.

Bugs in the Bat program

• out of memory after loading a file of say 200KB. Investigate what the bottleneck is and see if it can be improved upon. This might be related to the rather bad implementation of the parser. See the point below about improving the parser.

• when the configuration is changed force the appropriate redraws. But maybe wait with this until a new architecture for updates is developed.

• when the Mode is set to changing only the nodes with the same colour then one level too many is skipped. Also the idea is that the menu should result in some kind of "action" and this action should be applied to some nodes in the tree rooted by the vertex in which the action is initiated. So changing the colour and the annotation information should be considered separate actions in the case. Anyway, changing visibility of annotation does not seem to work as it should anyway. It should be possible to have a modification strategy and an action. The strategy should for a given node decide whether the action should be applied there and whether to apply it to the children as well or stop right there.

• strange things happen sometimes when the root is outside the screen. Sometimes a node and its child (the latter the only one of the two visible) have the same coordinates. Weird. load IPT1.aterm, press down, perform Show Children in the active node: the new child is not shown although we do have place. Is this coincidence? Also happens when you unfold in the Dir view twice.

Improvements

The following elements of the Bat program need modification:

• make setting presentation aspects of attributes have effect.

• does walking around the tree work right as it does. Maybe postpone resetting the node position when moving down when the next node really does not fit on screen.

• HideAction? also shows. Clarify this by changing the name.

• remove unused code.

• the 8 annotations (actually attributes) should be in an array.

• having focus currently resides in Node, I guess it is more a presentational thing.

• I am not too happy about the lines are drawn that go out of the window, this could be done nicer I think. Maybe a simple line with a few dots tagged on at the end seems more natural.

• be more clever when looking for a node matching a click in the program (although when we turn everything back to components this is something which can be skipped). This is not as easy as it may seem, although it should become easy when the view vs. model is better structured (see later). I did make sure he starts looking at paintRoot in LocalView? .

• improve the parser. One way of doing is to use the ATerm library (either from the makers or maybe the one Martin Bravenboer is writing). Then make a mapping to our own datastructure.

• refactor the program. Especially the classes Visual... in view need some work. Seems to me the way this is done now is not a very good one. My idea would be to have the model on the one hand, and that piece of the model that ends up being drawn in either of three windows (two or three different trees that is) including position and information. I would think that the Global view always has a copy of the entire tree, but since only little information is needed about this tree (only the structure and the names of the non-terminals) including some presentation attributes (colour (do we really need it?), visibility), it may be wise to devise a special memory efficient representation (if it does not exist yet). I expect that refactoring can also make the Visualizer a much more important class by moving commonalities from the LocalVisualizer? etc. to the Visualizer. But this also depends a bit on the next point. Also, take a method like setPositions for LocalVisualizer? . To what extent is it used and necessary when the drawing functions paintFrame also have effect.

• using Swing again. The way things are done now in the views is that the three as a whole is a JComponent, but all the separate parts are well, sometimes they are JLabels, sometimes not. Anyway, fact is that drawing is done by paint functions which get called and they are not drawn as JComponents should. This probably saves execution time, but as it is now, my impression is that these things are mixed: sometimes components exist, but the drawing of them is not done by the component, but by a separate function. I also think that a lot of the drawing code is unreadable. I want more structure here. Another option is to go back tto Swing components again, and try to optimize their use. For the Dir view it may be possible to utilize JTree (what happens to zooming and do we need zooming there?) For the Local view I expect that making the Attributes and the Nodes into components again saves a lot of programming (for instance, for the Tooltips. I expect that if the Local view tree only has a component for those elements visible on screen, then things may become a lot more efficient. This implies the need for a tree between the model and the view where we compute sizes and the like so that afterwards we may copy that part of the tree which is actually visible and make only components for those. Another way is to see if we have can do something similar to JTree here by reusing components.

• as regarding naming: we have annotations, attributes, aspects, configuration and so on. We need to fix these names consistently throughout. My proposal is the following: the values which we use in positions 1..8 around various nodes should be referred to as ATTRIBUTES, the PRESENTATION ASPECTS of drawing ATTRIBUTES and NODES will be called ASPECTS. This more or less means that the name giving for Annotations in the program should be changed to Attributes. The main reason for this is that in Aterms, annotations will be used to code the presentation aspects and attributes are part of the tree structure.

• I got the impression that the architecture of the program is a bit bulky with overly many connections between classes. This needs looking at.

• Some operations change the positions of nodes, some only change the color or 'being in focus'. Try to use this fact when updating a view. This may be done by phasing the steps from model to view.

Additions

The following elements of the Bat program need to be added:

• more flexible presentation aspects. This is quite a large undertaking. My idea would be to separate those elements that Bat may change (like colour and visibility) I expect that these aspects will be put in the annotation section of the ATerm. The attributes should be put into the structure of the Aterm. It still remains to be decided how this can be done best. The main idea is that nonmodifiable elements go into the ATerm tree structure, the aspects go into the annotations.

• saving ATerms. One version saves only the structure and leaves out annotations, saving only the parts that are shown. One version saves also all annotations, using visibility annotations to say which parts of the tree are visible. Other export facilities may also be possible: saving to SVG for instance. This may also take the form of an outside program which converts ATERMS to SVG.

• setting presentations aspects for a given non-terminal

• searching for non-terminals, searching for text in attributes

• computing the diff of two ATerms and rendering this graphically. This is quite an undertaking.