Tooling Ideas - LucPrestin/Hidden-Modularity GitHub Wiki

The Workflow we are currently using does not have to serve the sole purpose of finding out about a feature of squeak. It can also be used to gain insight into dynamic behavior when programming ones own software. For this, however, the workflow has to be adapted. As strongly manual as it is now, it is not usefully in daily work. Ideas how this can be achieved are documented on this page.

Improvement of other tools

The data extracted with the HMTraceParser are also interesting for other tools, because they can form a good heuristic depending on the application. Here we refer to the future work page.

Integration into the ecosystem

In Squeak, a tool never stands alone. It must seamlessly integrate into the existing ecosystem. Here is a schematic of how that can happen:

Data sources for the tool would be the usual do-its, tests, etc. For this, we would create a new menu item along with a shortcut. (e.g. trace it (t)).

As soon as code is executed with this shortcut, the execution is traced in the background using the TraceDebugger. The trace then gets loaded into the tool together with the traced code snippet.

Inside the tool one could then interact with the code and its elements as usual, e.g. by using shortcuts. In addition, the code would be editable and the new version could be executed and traced again. The updated data would then be displayed by the tool again.

Tool

The tool itself has four things it must be able to do.

  1. Display all the needed information
  • The code snipped used as input and where it came from
  • Statistics calculated based on the trace (see future work)
  • The visualizations, now pulled into squeak (see future work)
  1. Allow for adaptations of the code and a refreshed fresh trace
  2. Interact with the code as usual
  • inspect objects
  • browse objects
  • execute normally
  • ...
  1. Allow to display multiple visualizations next to each other in order to compare multiple views of the same data

Overview

As a first design, the tool could look like this:

It consists of three main parts.

  1. A code pane
  2. A container for the calculated statistics
  3. A container for the visualizations

Code Pane

The code pane consists of three main parts. At the top, there is the information about the code's origin. Here, it came from a Workspace. For a TestCase, the test case would be displayed here. Do-its from a System browser would be displayed accordingly.

Below that, we have the code itself. It would sit in a PluggableTextMorphPlus that ects as a code mirror, with the usual interaction techniques. This, of course, includes tracing only parts of the code too.

The third part is the button that allows for re-tracing the whole code insight the code pane.

Statistics Container

The statistics container does exactly what it is named after. It displays the statistics for the current trace. For which statistics that could be, have a look at the future work page.

Visualization Container

The visualization container can normally display exactly one visualization. Which one can be selected via a drop-down menu.

In the visualization, all interactions that are possible so far would be supported: moving around in the canvas by dragging, zooming, etc. Additionally, it would also be possible to click on a node, as noted in the the related spike, to inspect the data behind it.

To still get multiple views of the data, a new visualization window could be opened as a pop-out: