Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend query syntax #110

Open
gomoripeti opened this issue Nov 9, 2017 · 0 comments
Open

Extend query syntax #110

gomoripeti opened this issue Nov 9, 2017 · 0 comments
Assignees
Projects
Milestone

Comments

@gomoripeti
Copy link
Collaborator

In order to add more functionality we need to extend the query syntax to allow more options and alternatives. (eg #108 )

Requirements:

  • It must be parsable (at list tokenize, then split, then parse - this is how query processing in erlang-syntax mode already works) and have familiar syntax in both Erlang and Elixir.
  • (Maybe) It also has to be generated from a list of options (oposit of parsing, one-one mapping)

1. Action-functions

One option is to extend the match-spec syntax by allowing more action-functions.

  • examples
    mod:fun(_,A,_) -> argdist(A)
    mod:fun(_,A,B) -> argdist(A+B)
    mod:fun(_,A,_) -> argdist(A >= 0, enum)
    mod:fun(_,A,_) -> argdist(A >= 0, [{enum, 2}, {interval, 5}])
    
    mod:fun(_,_,_) when caller(mod2,fun2,_)
  • advantages: compact, allows some small sugars in the match-spec (like caller guard)
  • disadvantage: limited, what if a feature does not work on mfas at all (eg gc profiling)

2. Record/Struct/Keyword list

Other choice is to have something like records or structs:

  • construction:

    • starts with a special character
    • followed by a named-command
    • then key-value pairs of named-arguments
    • last one is the match-spec (to allow special parsing)
    • no enclosing {}
  • examples (multiple lines for readability)
    Erlang:

    #argdist enum = 2,
      interval = "5sec",
      derive: if A > 0 -> positive; true -> neg_or_zero end,
      mfa = mod:fun(_, A, _)
    
    #funlatency caller: xprof_core_lib:detect_mod/0, mfa : lists:keymember/3

    Elixir:

    %Argdist int: -100..100,
        interval: "5sec",
        mfa: Mod.fun(_, a, _)
    %Funlatency caller: String.split/3, mfa : Keyword.get/3
  • advantage: more flexible, it is easier to generate (even on the frontend)

  • disadvantage: more verbose (how will this fit in graph title?)

We can still expose the raw/parsed Erlang API:
xprof_core:monitor_pp(QueryString) would parse the query and convert into a lower level xprof_core:monitor(Command, Options) format.
Current xprof_core:monitor({Mod,Fun,Arity}) would be equal with xprof_core:monitor(funlatency, [{mfa, {Mod,Fun,Arity}}])

3. Options

Alternatively we can keep current query syntax and add option buttons/widgets on the gui. They map to a separate option list in the Erlang API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Hackathon
  
In progress
Development

No branches or pull requests

2 participants