:mouse::bug: Tweaked pattern match of `:supervisor` in tracer.ex

[ghost]

• On my machine, supervisors weren't showing up dark blue. In examining the shape of the supervisor pattern match in Visualixir.Tracer.process_type/1 (pid), the order of the list was backwards, with "$initial_call" at position 0 and "$ancestors" at position 1. So I just switched these two. Now my supervisors are showing dark blue.
  • Erlang 19, Elixir 1.4.0 (but earlier versions of Elixir also exhibited the behavior).
  • I've left in the IO.puts call for your convenience in the code. You may want to remove this before committing the changes.

[ghost]

I'm also tweaking things on my fork if you're interested. If you have any specific recommendations or little ideas for me to meander towards, I could try giving it a go.

[koudelka]

Hey @bill-mybiz,

Thanks! I wonder why I had that pattern match wrong, maybe a previous Erlang version gave that pattern.

I'm more than happy to merge, if (like you mentioned), you want to remove the comments.

As far as tweaks go:

• it'd be cool if you could drag-box select a set of processes and turn on monitoring in bulk.
• option-clicking to turn on monitoring also pins the process movement, that's a bug.

I was actually thinking it'd be really cool to rewrite the entire frontend in Elm, I was holding off on making any major changes until then. I have some neat ideas that I want to try, but you know, job. :(

[ghost]

I'm more than happy to merge, if (like you mentioned), you want to remove the comments.

@koudelka :cool: Apologies if I offended with my mention of you removing the comments. I specifically left in the commented IO.puts code and example for you to double-check that there isn't something different about my environment that would cause a difference on the pattern match (i.e. it isn't just cruft left in). I'd hate to break things to work only on my version (bit me when contributing to vs code :laughing:). Also, perhaps it would be acceptable to have either sequence pattern match. I would be more than happy to remove them if I'm sure that it's been confirmed! :smile:

---

As far as tweaks go:

• it'd be cool if you could drag-box select a set of processes and turn on monitoring in bulk.
• option-clicking to turn on monitoring also pins the process movement, that's a bug.

Both of those tweaks look doable. Drag-box frame possibly similar to this range d3 block and the :bug: obviously seems squashable :high_heel:. But I warn you as far as the pin bug is concerned, in ibGib I had to completely write its own mouse/touch event handler because in addition to needing long-pressing, the default handling doesn't act as expected. One of the quirks is that when you click, it automatically fires the drag events. Perhaps it is different in d3 v3 (I'm using v4). So I could address just that :bug: with a timer for the drag start/end and fix the node accordingly, but no matter what it's going to be hacky like that AFAICT (I couldn't get hammer.js to play nicely either). EDIT: Looking at that bug, it was as simple as testing for the altKey in the drag event's sourceEvent.

I was actually thinking it'd be really cool to rewrite the entire frontend in Elm, I was holding off on making any major changes until then. I have some neat ideas that I want to try, but you know, job. :(

Hrmm, I'm not certain I can help you down that road, as I looked into Elm previously for its reactive style but preferred going with vanilla ES6 JS + d3. I totally understand if you're interested in it though, many seem to be! :smile:

Elixir forums did get me interested in Bucklescript, but I don't have the ability to invest in it for ibGib. Have you checked that out?

Regardless, I'll see about that quick fix for the bug here later, time permitting.