cogdebugger
A GUI designed to look and feel like what existed for Cog 3.
Base class for Cog applications that make use of the Cog Browser for the purpose of visualizing field contents.
Base class for Cog applications that make use of the Cog Browser for the purpose of visualizing field contents. It works sort of like SimpleSwingApplication, except that instead of defining some anonymous subclass of a MainFrame, clients will define a ComputeGraph.
A debugger that probes all fields in a compute graph.
A wrapper for for any debugger state that is tied to a particular compute graph.
A wrapper for for any debugger state that is tied to a particular compute graph. If this object is lost/destroyed, any of the GUI state here should be cleaned up.
Created by gonztobi on 1/22/2015.
A leaf node representing a (probed) field.
A leaf node representing a (probed) field.
Represents a single floating point value.
Represents a single floating point value. Can be rendered as a spinner by cogdebugger.ToolFactory.
A utility class for building memoized functions.
A utility class for building memoized functions. Initially an empty
(mutable) Map, the first call to apply with a particular key uses the
function argument to produce a value and store it in the map before
returning it. Subsequent re-use of this key will return the stored value.
Note that the underlying data structure is a scala.collection.mutable.HashMap, which may not be thread-safe.
Created by gonztobi on 2/25/14.
A tree describing the module hierarchy implied in a given Cog model's definition.
A tree describing the module hierarchy implied in a given Cog model's definition. Supports lookups and traversals.
Basically, any class that has Cog fields as members is called a Module. In addition, any class that has a Module as a member is also called a Module, and is considered a parent to all those member Modules. Any Module that doesn't have a parent is attached as a child to a meta-Module that we just call Root.
The actual reflection/introspection code that finds all these module relationships lives in the field auto-naming logic within ComputeGraph. This class is actually determining the relationships by breaking apart field names.
Example:
class Bar { val scalarField = ScalarField( ... ) } class Foo { val bar = new Bar() } val cg = new ComputeGraph { val foo = new Foo() }
In the above compute graph, a single scalar field is created that will be named "foo.bar.scalarField." This name is generated using reflection: the anonymous ComputeGraph has a Foo member named foo which in turn has a Bar member named bar which in turn has a ScalarField member named scalarField. The namer smashes those together to create a long name for the field; this ModuleHierarchyTree class breaks the name back apart to determine relationships between fields and parent objects (the so-called Modules).
A node representing a module.
A node representing a module. ModuleNodes can contain both other other ModuleNodes and FieldNodes as children.
A node in the module tree.
A node in the module tree. One of either cogdebugger.ModuleNode or cogdebugger.FieldNode.
Represents a finite number of states, of which only one is active.
Represents a finite number of states, of which only one is active. Can be rendered as a combobox by cogdebugger.ToolFactory.
Represents part of the state of some GUI element (e.g.
Represents part of the state of some GUI element (e.g. the zoom level of a visualization). Meant to help assist with preservation of UI settings and appearance across application runs.
Setting a Property's value will cause the onPropertyChanged method to be called, which by default calls the apply method of the installed scala.swing.Action. The default Action, however, is scala.swing.Action.NoAction, which of course does nothing. Either install an appropriate Action or override onPropertyChanged if you want to trigger some behavior when the value of the Property is changed.
Each property can produce an XML tag suitable for saving into a properties file, and can later parse that tag to restore the previous state.
A graphical user interface that supports saving/restoring at least some of its state to disk between runs (things like windows position and size).
Sketch of a standalone launcher for the CogDebugger application.
Sketch of a standalone launcher for the CogDebugger application. Right now, all it really does is pop up a splash screen (and that only if you use the right run configuration).
Eventually, will take the name of a .class file defining an extension of ComputeGraph as an argument, and set up the browser for that app.
Created by Dick Carter on 3/5/15.
Created by Dick Carter on 3/5/15.
Simple app for launching the Cog debugger on a model restored from an HDF5 file. This will be obsoleted when the debugger implements a "Load" button.
Use this by entering the filename in the IntelliJ IDEA run config under "Program arguments". The path can be absolute or relative to the launch directory, which is the top-level project directory.
A factory that makes GUI controls for the different types of Properties, and sets them up to keep their states synched.
A factory that makes GUI controls for the different types of Properties, and sets them up to keep their states synched. That is, changes to the property will cause the GUI elements to change state when appropriate, and acting on the controls will change the values stored in the properties.
This synching is implemented primarily for the benefit of XML resore mechanism built into Properties; restoring the state of a Property from a XML file will cause its associated UI elements to be restored as well.
A collection of utility and miscellaneous functions used in the implementation of the Cog Debugger that don't have a compelling reason to be placed in a particular package.
A collection of utility and miscellaneous functions used in the implementation of the Cog Debugger that don't have a compelling reason to be placed in a particular package.
User: gonztobi Date: 8/21/13 Time: 2:40 PM
A GUI designed to look and feel like what existed for Cog 3. Consists of three major UI portions: the main toolbar, the graph viewer, and the probe desktop. The main toolbar goes across the top of the window, the graph graph viewer exists as a sort of sidebar in the main area, the and probe desktop takes up the reaming space (and the builk of the entire UI). This style eschews the menu bar, status bar,a nd message windows.