Visual Anoma: graphical views in the node

Protocol Design
1

Today, we sketched out plans for the node’s graphical inspectability capabilities (I don’t have great terms for referring to this, sorry. The GUI, but not what that word brings to mind right away.)

Taking existing Observer views as all given, we discussed some of the following at length:

  • A node-based view, i.e., a sort of high level dashboard for node parameters, node configuration, editing node configuration, &c.
  • Bespoke individual engine views that go beyond simple process state dumps even if the information is present if you dump enough of them, such as:
    • Storage view, showing current and historical states in their logical, not their compressed physical data structure form.
    • Transaction-oriented view, showing the mempool of pending transactions, their execution state (e.g. running, blocked, completed)
    • Block-oriented view, looking from the perspective of the transactional system checkpoints known as “blocks”.
    • Event-oriented view, showing the replayable event log in an easy-to-read format, allowing you to roll back, roll forward, and inspect.
    • Engine constellation view, showing the engines that make up the node at a higher level than inspecting their processes.
  • Resource views; not sure to what extent the shielded RM is inspectable at runtime but the transparent RM is made to be so.
  • Data structure views: you should be able to graphically inspect structs, basically.
    • Columnizable protocol: oftentimes it’s clearer to look at a collection of structures as a table, rather than a bunch of nested structs. I have a clever design for this which deserves its own thread.
  • Transport view: network activity, foreign connections, and the things discussed in the transport thread
  • Anything else! The collection of views is a wide open set.
2 Likes
2

Brain Storming The Flow

I spent the weekend thinking about the wx library in erlang, and conducting some experiments.

Here are my thoughts.

Please check the references section at the bottom for a full list of links along with some pdfs that are helpful in understanding WX better.

Prep Work

documentation: Erlang WX Document. Each object links to the CPP code.

Something to note is that it’s an erlang library. This is fine… after all we can call :wx.demo() in elixir to see how wx works in practice, but upon inspecting any code you’ll notice these interesting lines

-include_lib("wx/include/wx.hrl").

some_fn() ->
  wx:new(wx:null(),  ?wxID_ANY ...).

...

What is interesting is that hrl files are macro files, and can not easily be imported into erlang… this would be fine, but this file is 5.1k lines long.

In order to combat this and port it to Elixir I’ve made the following file in my personal repository:

In which we can now call with :wx_constant

This approach is manual and I suggest doing the bare minimum of what you need, and we can simply add to the file over time.

WX Implementation Ideas

Now with the annoying prep work out of the way, let us discuss a realistic strategy.

The Insepctor tool we shall make will be a wxNotebook, with each addPage/4 representing a registered view.

Each view is a wx_object, which is an abstraction of a genserver. The reason for it being a glorified genserver is that buttons send events back to the genserver itself, meaning that if we don’t model views as an wx_object but rather as the bare wxObject (I.E. a normal allocation), then we’ll have to have our inspector handle machinery for somehow registering the buttons etc.

Good code to study for this is the observer source:

the wx_object shall take at least the following arguments wrapped in a view datatype:

  1. the Notebook it’s being rendered on.
  2. the inspector process itself.

We will likely need more, but this is the minimum baseline.

Ideas for the View

The following are sketches of thought I’ve had, however they are not fleshed out, and are there for a conversation starter:

  1. Views can be a protocol/behavior
    • Downsides:
      • It can’t be extended
      • How the hell would it work for servers!?
  2. We have an application that is a global view broker
    • This is started at the startup of the VM, and everyone registers their views there.
    • This can be queried for views.
    • We can try to back it with mnesia or something so if the broker magically dies, the data won’t be lost.
    • This can easily be extended.

End Goal

The general idea will be to make creating this process easy and streamlining it.

Once the inspector tool is in place, I suspect creating a view won’t be too much code.

Ideally we can get the requirement of each view being a genserver gone some day as it will add extra files and lines that are barriers to entry.

I think although this will be tied to wx, I think lots of our examples will eventually will become a simple API over it. If wx knowledge is required, I think looking at other views and how they work will replace the need to read documentation.

Only those who are building the system or really wish to push the system with new abstractions ought to read these documents by the end.

I hope in time to replace all of this with glamorous toolkit integration, however I think using wx is the way forward for now.

All References

1 Like