Studio version 2

[lukego]

I have started porting Studio onto the latest release of the GToolkit graphical inspector framework. See raptorjit/raptorjit#227. The new GToolkit is a much improved rewrite and it offers opportunities to do some things better.

The big one is to unify the user-interface, the manual, and the test suite into one living document (a collection of notebooks for individual topics and applications.) This should make Studio much easier to get started with, to master and to maintain. This will also make Studio more extensible because users can create their own notebooks and copy-paste useful snippets e.g. for downloading objects from their CI servers etc.

Screenshot preview:

There are a few changes that seem natural to make while adopting the new framework...

Using Smalltalk code snippets to drive the UI instead of Nix expressions. Nix will be driven by Smalltalk code, not directly by the user. This way we can take advantage of GToolkit's native support for editing Smalltalk snippets with error detection, syntax coloring, completion, etc. This also removes one indirection: the Smalltalk code will know in advance what objects the Nix code is building rather than having to infer that using the .studio/product-info.yaml metadata.

Rethinking the object model for the existing RaptorJIT inspection code. Have we chosen the right set of objects? Should we refactor into a more logical structure? There seem to be some aspects worth improving e.g. to make Profiles into first-class objects that can be sliced and diced. Have a uniform way to look at the profile of a whole process; one VMProfile dataset; one set of traces with a common root; one trace.

Rethinking individual views. Are we over-using "table-trees"? Is there a better way to present IR code in the new GToolkit? It has nice features such as text listings with inline expandable objects. It is also not backwards-compatible with the graphics framework that the existing visualizations are based on (Roassal2). So it seems at least worth rethinking any view that requires major porting effort to preserve.

I'll push a preview branch when I have a chance. Just now I don't have much integrated beyond what you can see in the screenshot above but a lot of existing functionality should be easy to port.