A simpler alternative to cogdebugger.ui.structure.GraphViewer.
A graph viewer that is module-aware.
A graph viewer that is module-aware. Rather than displaying the entire graph at once (which may be quite large), it only draws the contents of a single module of interest at a time.
The user navigates the module hierarchy through the use of a navigation toolbar as well as by clicking on the vertices on the graph that correspond to modules The vertices corresponding to fields are colored blue; those corresponding to modules are a shade of gray.
An event indiciating the user has left-clicked an edge.
An event indiciating the user has left-clicked an edge.
The object bound to the edge
An event indiciating the user has right-clicked an edge.
An event indiciating the user has right-clicked an edge.
The object bound to the edge
Presents a graphical representation of the structure of a Cog ComputeGraph, i.e.
Presents a graphical representation of the structure of a Cog ComputeGraph, i.e. a display of its fields and their inputs and outputs.
Each (probed) field in the compute graph is represented as a single vertex in a directed graph. Each field is then connected to its inputs and outputs via directed edges. Forward edges in the graph are rendered in one color, while recurrence or "backward" edges are rendered in another.
Clicking a field vertex or edge raises an cogdebugger.ui.structure.InteractiveGraphEvent that other debugger components (such as cogdebugger.ui.Desktop) may react to.
The graph viewer operates in one of two modes: the default simple mode simply shows everything at once - each vertex represents a (probed) field, every input/ouput it has is represented by an incoming/outgoing edge. The second mode, referred to as the Drill-Down view, tries to compact the visual presentation by taking advantage of any module structure defined in the input Compute Graph.
The module hierarchy of a cmpute graph is implied from the organization of its fields and other classes. Essentially, each class instance that contains fields is considered a module, including the top-level compute graph instance itself (for many of the short example apps, this top-level module is the only module). The name of a module is not based on the class name, but rather the val/var name to which it is first bound. Consider the following pseudo-code:
class ModuleExample extends ComputeGraph { class ModuleA() { val aField = ScalarField(...) } val modA = new ModuleA() probeAll }
The above code defines a ScalarField aField
within a ModuleA instance
modA
, which is itself within a ComputeGraph instance. Keep in mind that
modules and fieldsa are named after the val/var to which they are bound.
The long name of a field includes its path in the app's module structure.
The full name of the singular field in the above compute graph is
'modA.aField'.
In the Drill-Down view, only a single module is "in focus" at a time. The children of that module (fields and other modules) are displayed as well as inputs and outputs to the module. Clicking a field raises an event as in the simple graph viewer, but clicking a module makes that module the new focus and redraws the display. A toolbar at the top of the display allows for focusing the parent of the current module or jumping back to the top level.
An event signalling that a user has interacted with a graph view in some way.
An event indiciating the user has left-clicked a vertex.
An event indiciating the user has left-clicked a vertex.
The object bound to the vertex
An event indiciating the user has right-clicked a vertex.
An event indiciating the user has right-clicked a vertex.
The object bound to the vertex
A simpler alternative to cogdebugger.ui.structure.GraphViewer. Just a big list of buttons, one per ProbedField in the given Cog model/app. Buttons are labelled with the long name of the field they represent, and appear sorted by that name. Clicking a button raises an cogdebugger.ui.structure.InteractiveGraphEvent event indicating the clicked field.