Pretty-print du code source Elixir à partir d'un chunk Dbgi

Question

Si j'ai un fichier beam compilé à partir de code Erlang avec debug_info il est assez facile d'imprimer le code source correspondant :

{ok, {_, [{debug_info, {debug_info_v1, erl_abstract_code, AbstractCode}}]}} =
    beam_lib:chunks("my_module.beam", [debug_info]).
{ok, Forms} = erl_abstract_code:debug_info(erlang_v1, module_name, AbstractCode, []).
io:format("~s~n", [erl_prettypr:format(erl_syntax:form_list(Forms))]).

Mais qu'en est-il d'Elixir ? Je peux faire les deux premières étapes comme ceci :

{ok, {_, [{debug_info, {debug_info_v1, elixir_erl, AbstractCode}}]}} = 
    beam_lib:chunks("Elixir.MyModule.beam", [debug_info]).
{ok, Forms} = elixir_erl:debug_info(elixir_v1, module_name, AbstractCode).

On obtient ainsi une carte de cette forme :

#{attributes => ...,
  compile_opts => [],
  definitions => ...,
  deprecated => [],
  file => <<"my_module.ex">>,
  line => 95,
  module => 'Elixir.MyModule',
  unreachable => []}

Comment puis-je imprimer cela sous forme de code Elixir lisible par l'homme ?

Answer 1

Il existe un logiciel Visual Studio extension qui peut décoder le fichier BEAM en code source Elixir :

Pour activer l'extension, sélectionnez "Disassemble BEAM" dans le menu contextuel d'un fichier .beam dans la vue de l'explorateur :

Suivant Refs :

1) https://elixirforum.com/t/visual-studio-code-extension-to-view-beam-files/13373/4

2) http://beam-wisdoms.clau.se/en/latest/indepth-beam-file.html

Modifier 1:---

ElixirLS est un autre outil de débogage du code Elixir ou Erlang.

Vos modules .beam compilés n'ont pas les appels de fonction nécessaires pour envoyer ces messages. Dans d'autres langages, vous pourriez compiler deux versions de vos binaires, l'une avec les appels de débogage et l'autre sans, mais en Elixir, cela fonctionne un peu différemment.

Lorsque vous compilez des modules Erlang ou Elixir avec l'option :debug_info les fichiers .beam résultants incluent un morceau avec la représentation du format abstrait Erlang de votre code. Avant de pouvoir déboguer un module, vous devez l'"interpréter" en appelant :int.ni/1 qui lit ce morceau et purge ensuite le module. Ensuite, tous les futurs appels au module sont traités en évaluant les formes abstraites Erlang et en faisant les appels nécessaires au méta-processus après chaque évaluation.

Appel :int.ni/1 sur chaque module de votre projet est fastidieux, donc lorsque vous exécutez une tâche Mix dans le débogueur ElixirLS, il interprète automatiquement tous les modules de votre projet et ses dépendances. C'est un bon choix par défaut pour la plupart des projets, bien que cela puisse causer un décalage notable dans le démarrage de la tâche. Les prochaines versions d'ElixirLS incluront probablement plus d'options de configuration pour spécifier les modules à interpréter.

Remarque : En conséquence de la nécessité d'interpréter les modules avant le débogage, vous ne pouvez pas déboguer le code qui se trouve en dehors de la définition d'un module.

Liens importants :

1) https://medium.com/@JakeBeckerCode/debugging-elixir-in-vs-code-400e21814614

2) http://blog.plataformatec.com.br/2016/04/debugging-techniques-in-elixir-lang/

3) https://zorbash.com/post/debugging-elixir-applications/#otp-behaviour-tracing