Add a process tracing JS.Live widget

[josevalim]

By using :erlang.trace.

[christhekeele]

I'm interested in working on this, I have some tracing experience!

How do you imagine it differing from/expanding on Kino.Process.seq_trace()? I have several ideas given all that's possible with the tracing engine, but interested in your original vision.

[josevalim]

Woot! We don't have a vision per se. I was thinking about something where you can pass a list of Mod.fun/arity (or just Mod or Mod.fun), perhaps something as simple as a text area with one entry per line, and we will start printing the traces. Having some presets in the future may also be nice, such as tracing all distributed messages. :) But I would love to hear your thoughts too!

[christhekeele]

@josevalim: I was thinking about something where you can pass a list of Mod.fun/arity (or just Mod or Mod.fun)

Gotcha, so you are thinking about adding a widget to trace calls in particular, rather than messages between processes, or other tracables like process lifecycle/link/monitor events?

[josevalim]

That was my initial thought but I am not stuck to it. Suggestions are definitely welcome.

[christhekeele]

Winding down for the night, but to kick off discussion:

---

With what I remember from my partially-complete, dormant call tracing work in Matcha, we have a few options beyond the M/F?/A? on what to trace, including:

• where to trace calls: in specific pids, pids in only existing processes at start of trace, or any future newly created processes
• return values from traced calls
• call count, time, and memory stats
  • (fairly new in :trace.function/4, matcha and my knowledge has not caught up with recent erlang)
• where traced function calls return into

So I can see a couple of different UXs around this:

• A frame with an appendable log of traced calls (return values optional)
• A mermaid sequence diagram centering traced function calls and returns into callees
• A breakdown of statistics for traced calls

We could offer many of these, in a Kino.Trace module analogous to the Kino.Process module for process lifecycle visualization, depending on how many options get built out.

---

Having some presets in the future may also be nice, such as tracing all distributed messages.

One perk/downfall of :erlang tracing is that it does this out of the box depending on trace pid configuration, so any such feature should just work ™️ if the livebook is connected to a distributed node (something I've not tried before). :recon places a hard limit of traced calls before aborting the trace, to prevent overwhelming the tracing node with messages, as does Matcha with more bendable rules. So limits are something to think about in the design of this DX.

---

Given these considerations and configurations, one possibility here would be to make the widget a smart cell rather than just a Kino.JS.Live. This would offer a richer UI for experimentation, abstracting the concerns of composing the right matchspecs/tracing calls for your usecase, until you are ready to codify it and tweak it more finely.

[josevalim]

I am open to all of these options. My only concern with the smart cell is that the code it will generate is too verbose... but it comes with the obvious advantage of being changeable and customizable.

I also think we should use the new :trace (it is ok to depend on latest), since it allows us to run multiple tracing sessions at once.

[christhekeele]

Will definitely start to play with this in the upcoming week, then! I've been looking for an opportunity to dive into the new :trace anyhow. Will report in!

[christhekeele]

It does look like the newest :trace API is node-local, so safer out the the box, but we might want to build off of the lower-level trace APIs with our own safeguards so we can eventually support distributed tracing with the same tooling.