Adding process tracing

[akoutmos]

This PR implements #159

Continuing the discussion from that issue:

Should we not show the bars if the process already exists or should we show the bar from beginning to end?

At the moment I have the bar starting when a process is spawned and stopped when it exits (both of which have to be present during the trace in order for the bar to appear). In other words, it doesn't look like Mermaid renders anything unless there is both an actor activate and deactivate. That and it doesn't look like we can start bars at arbitrary points on the sequence. Rather it looks like they have to start and stop on events. All this to say, I think if we want to keep the bars, they'll only be present when a process starts and stops during the trace.

Regarding the messages, can we do any sort of mouse over thing? Keep only the label and when you mouse over, you see the whole message?

I'll have to explore this a bit more. I tried setting up a pop up Actor Menu as described in the docs...but the menu never popped up lol.

There are some dotted arrows after the messages... is this the "receive" event? If so, I think we can ignore it. Another option would be for the arrows to not be horizontal, but point to when the messages are received in the other process timeline, but that may be too complicated?

I think the Mermaid diagrams only allow for horizontal lines and cannot be linked back to another event. Do you want me to remove all receive events and just have send events? Or only in certain circumstances? Here is an example with no receives for reference:

We also need to check if we trace :DOWN messages from Process.monitor.

It has been done! I also added that to the example code :).

I have a couple more things that I need to clean up and fix so I am opening this up as a draft PR. Should have those wrapped up during the weekend :). Thanks in advance for the review and have a great weekend!

[josevalim]

@jonatanklosko the current implementation discards the result of the function given to trace and I don't like that. We could instead return {res, kino_markdown}, but then the result of course won't be printed. So here is my suggestion:

1. Have this function return both {res, kino_markdown}
2. Also add Kino.Process.render_trace, that calls trace/2, renders the trace behind the scenes, and returns only res

WDYT?

[josevalim]

Amazing @akoutmos! I have added only some minor final comments!

Do you want me to remove all receive events and just have send events?

Yes, I think we can remove them all. :)

[akoutmos]

Thanks for the review @josevalim! Really appreciate it. I reworked the exception handling a little so that the call to the tracer GenServer was not part of the trace capture. I also need to rework that last reduce to handle the scenario when a process is started prior to the trace, but terminated during the trace. Mermaid throws an error if you attempt to deactivate an actor without it being activated prior.

After that I think it is good to go :). Thanks!

[josevalim]

You can also do nested trys. The nesting is uglier but less code duplication and perhaps easier to understand?

try do
  try do
    fun.()
  after
    stop_trace
  end

  get_trace_events
after
  GenServer.stop
end

[akoutmos]

You can also do nested trys. The nesting is uglier but less code duplication and perhaps easier to understand?

try do
  try do
    fun.()
  after
    stop_trace
  end

  get_trace_events
after
  GenServer.stop
end

It has been done :)

[akoutmos]

I fixed that last issue that was on my TODO list and switched the PR from draft to ready. Let me know if there are any other issues I should address.

I think the only open question at the moment is whether the result is kept from the trace function?

[josevalim]

I will let you know soon. I also just realized that we could name the current process as self() in the diagram. WDYT?

[akoutmos]

I will let you know soon. I also just realized that we could name the current process as self() in the diagram. WDYT?

Sounds good :). I updated how the participating PIDs are generated and the calling PID now show up as self(). I think that makes it nice and clear for users following the trace:

[josevalim]

Hi @akoutmos, let's please change this one to return {res, kino}. Then we will add render_app_tree, render_sup_tree and render_seq_trace that render as a side-effect. The first two will return Kino.nothing, the last one will return the result of the function. WDYT? Can you please push those final changes? :)

[jonatanklosko]

@akoutmos fantastic!!

[akoutmos]

@akoutmos fantastic!!

Thanks @jonatanklosko!

[akoutmos]

Hi @akoutmos, let's please change this one to return {res, kino}. Then we will add render_app_tree, render_sup_tree and render_seq_trace that render as a side-effect. The first two will return Kino.nothing, the last one will return the result of the function. WDYT? Can you please push those final changes? :)

That sounds good to me @josevalim :). I think I implemented it as you described in 9a5b965. Let me know what you think!

[josevalim]

💚 💙 💜 💛 ❤️

[akoutmos]

Thanks for the review and the help @josevalim and @jonatanklosko! Happy to see this merged in :)