The BEAM contains metadata such as what behaviors a module implements and that would be enough to determine what entities they represent. The tough part is being able to trace what the links between them are. As far as I know, there's no way to determine (from the BEAM attributes) what processes a given supervisor starts, but perhaps there's another way.
Paul On Friday, June 24, 2016, Chris Keele <[email protected]> wrote: > I've had an idea for a little bit of tooling for a while, but I can't > think of a good way to implement it outside of core. > > When I heard about mix xref graph > <https://twitter.com/christhekeele/status/743183215276392448> it > reoccured to me. I'm wondering what other people think about bridging that > concept with :observer's process link graph, to generate a non-runtime view > of what a project's OTP behaviour structure looks like. > > The end product I envision is an ERD PDF artifact in project root that > graphs what different OTP behaviours compiled modules have implemented, and > how they relate to each other. An example might plot the project's main OTP > Application module as a root node, that branches out to show the names of > Supervisors it starts and their Workers, plotted with different shapes if > they're GenEvent handlers, GenServers, or Agents; and perhaps connected > with different line types depending on their restart type. Modules that > start at Application boot like loggers and Ecto repos would optionally show > up alongside the rest. Sort of a map of project entities and their > responsibilities. > > The CLI API I envision is similar to rails-ERD > <https://github.com/voormedia/rails-erd>'s rake task, namely flags and > options to exclude modules of different names/namespaces, behaviour types, > and origins (internal versus external). > > Note I'm not talking about a compile-time graph of all processes and > links, so much as a high-level overview of project structure. Just being > able to see a project's core OTP behaviours at a glance diagrammed and > related to each other would help onboarding, whiteboarding, and project > design. > > Of all the implementations I've brainstormed, the only pleasant one that > occurs to me would be core taking possession of some module attribute names > for this purpose, and have it such that our Supervisor, Behaviour, > GenServer, etc injects proper attributes into using modules. Similarly, > the Supervisor.Spec macros could inject the relational information required > into the module. > > If the structure of the module attributes are designed well, this would > enable an extensible API for other projects with their own Behaviour types > to insert new entity types into the graph, and let end users identify and > annotate project-specific custom behaviours as well. > > I don't see a tenable way to have this exist outside of core as a library > without asking users to exclusively use wrapper GraphableOTP.Supervisors > and so on for everything, so I'm fielding it here rather than pursuing a > proof-of-concept library first. :) Thoughts? > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <javascript:_e(%7B%7D,'cvml','elixir-lang-core%[email protected]');> > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/f2692324-42ef-423c-9f74-e39380cc1179%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/f2692324-42ef-423c-9f74-e39380cc1179%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-TuefXU2PqBPSyWL464twk%3D77K5fgYau9dabQombcMGYuQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
