Consider a separate "GUI mode" for elixir about xprof HOT 6 CLOSED

Very good idea! 👍

I'd not to do the fork of the UI, but rather the UI mode (which can be enabled / disabled).

My proposal is to do the following:

UI

We can introduce a small icon, representing detected language - by default it will be Erlang and in that way we will define filtering. When we detect Elixir (see below how) we can switch to different mode. This icon will be a button which will be able to switch if you want to use Erlang syntax in Elixir.

IMHO this make sense, because effectively Elixir apps runs inside the Erlang environment.

Detection

It is relatively easy, because we can sniff applications or MFA available to trace (which we're listing). Ideally you could sniff application elixir or search for Elixir specific modules like 'Elixir.Enum'.

Transformation

That is an open discussion which I want to start - we can do it either on front-end or back-end. I'm voting for first one, I'd try to argument why:

1. This enables switching and makes it much easier, because it will not introduce any state on the back-end, this will be a purely client-side option.
2. One feature of xprof which is nice is sharing the same UI / view with others that will open app e.g. remotely - question is do we want to share the mode too - if no, there is no other way of doing it than client-side.

from xprof.

I feel convinced to doing this on the UI side. I think, the mode won't be switched very frequently, at least I can't see why would I want to do this on the daily basis. You have my axe!

from xprof.

I would argue for the server side (I've taken steps in #16 to remove erlang function syntax specific regexes from the UI)

• I think mode would be rarely switched (an elixir node/application would be xprof-ed in elixir mode, a purely erlang node/application in erlang mode)
• it would be much easier to do any kind of parsing or more complex logic on the server side (where erlang and elixir parsers/formatters can be used directly)
• it is almost impossible to format terms in either erlang or elixir syntax in the UI (captured args/res)

what are the erlang/elixir specific components and how they could be handled by UI to be mode agnostic:

• function browser textbox ("api/start_mon" endpoint - just a single query string)
• function browser drop-down auto-complete list items ("api/funs" endpoint - server could returns list of strings instead of list of [m, f, a])
• id/label of monitored mfas ("api/mon_get_all" and "api/stop_mon" endpoints - again id/label could be pretty printed string instead of [m, f, a])
• args and res of captured data ("api/caputre_data" endpoint - terms could be formatted accoring to mode in the backed)

drawbacks of server side implementation:

• switching between modes requires re-requesting certain components (not a huge issue)
• it would require state in the server to have different UI's for the same server with different modes
• it could be sometimes desirable to have erlang mode on an elixir node (is this a real need?) in that case mode based on auto-detection is not enough

from xprof.

It looks like you've convinced me, @gomoripeti. 😉

It makes more sense now for me to have it on back-end, even if we need to introduce state on the server. Especially part with having on back-end side parsers / engines.

It looks like you have full plan for it and it is related with your work on match specifications - will you be able to tackle this one too?

from xprof.

😄 I think we have a decision now

There are multiple steps: (and I could probably do with some help )

• convert endpoints to be mode agnostic
• mode detector and/or switch
• Elixir parser for auto-complete and mod.fun/arity tracing
• Elixir parser for match-spec funs (this needs some investigation what should be the syntax, what other tools use)
• Elixir formatter for terms
• Update Readme
• Run elixir tests on travis (nice-to-have)

from xprof.

Great @gomoripeti, this looks complete for me.

For 3rd task please keep in mind that in Elixir you can call Erlang modules with :atom.fun/arity, so colon need to be included in module name.

from xprof.