<div dir="ltr"><div class="gmail_extra">Hi Kostis,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for the comments. Answers inline.</div><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 - What does the mechanism that finds the source code have to do with the new chunk which is stored in the .beam file?  These two are totally orthogonal mechanisms, aren't they?<br></blockquote><div><br></div><div>The new proposed Dbgi chunk does not follow the same format as the Abst chunk. It is made of three fields:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>{debug_info_v1, Backend, Metadata | none}</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>The backend field must be a module that knows how to:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>- How to convert Metadata to different formats. For example, Elixir will likely store Elixir AST in the Metadata field and be able to convert the Metadata field to Elixir AST, Erlang AST and Core AST.</div><div><br></div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>- How to retrieve the AST from source if Metadata is none. The process will likely involve: 1. find the source for the beam file in the :compile attributes 2. parse the source file and 3. convert it to desired format. That's exactly how fetching abstract code from source works today on tools like cover and debugger</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><div>The proposed API for the Backend is outlined in the PR: <a href="https://github.com/erlang/otp/pull/1367">https://github.com/erlang/otp/pull/1367</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 - How is finding "the respective Erlang source" related to solving the problems that LFE or other languages (existing and future ones) may be facing?  Does the proposal come with some magic mechanism to "find" (I guess "generate" is a more appropriate word here) Erlang source code from e.g. LFE source?<br></blockquote><div><br></div><div>As per above, the Dbgi chunk contains the backend module and the backend module has the implementation of how to retrieve the AST from source. That's why it is important for functions like beam_lib:strip/1 to not erase the Dbgi chunk but instead set the metadata field to none.</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Don't misunderstand me, I am not necessarily against the proposal.  It's just that I do not see why/how renaming a BEAM chunk is helping us solve problems that are orthogonal to the info that gets stored in this particular chunk.</blockquote><div><br></div><div>Hopefully the points above clarify it. We are not only renaming the chunk, we are adding extra information to it as well and changing the shape of the metadata stored (which is why a new chunk is required).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"></span>
Does this mean that it will be impossible to hide the original source code from now on?<br></blockquote><div><br></div><div>This behaviour will be the same as today. To fully answer the question, let's outline how tools that need the AST work today:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>1. Attempt to load the AST from the beam chunk</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>2. If the AST is not available, see if there is a source file on disk</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>3. If the source file is available, parse it and convert to AST</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>In other words, the process of hiding a source from a tool is:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>1. You can encrypt debug_info</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>2. Or you can pass debug_info false and remove the source from disk</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Today, if you set debug_info to false but the source is still on disk, most tools will end-up building the AST from source. If you don't want that reconstruction then the source must not be available on disk. I aim to keep this behaviour.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Does this mean that if I have a .beam file lying around from long ago or I have written a compiler that generates .beam files without a .Dbgi chuck this is not a valid .beam file anymore?  How is that "backwards compatible"?  (as claimed in the PR)<br></blockquote><div><br></div><div>The beam_lib:chunk(BinOrPath, [:abstract_code]) will continue to look for the Abst chunk for at least 3 releases for backwards compatibility reasons. It will work like this:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>* Look for the Dbgi chunk, if it is available, it will ask the backend to convert the metadata to Erlang format</div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>* If the Dbgi chunk is not available, it will look at the old Abst chunk and return it</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>This means that beam_lib will be able to handle the differences between old and new beams. The only exception is if you lookup directly for the "Abst" chunk, which now will no longer be available, but that should not cause errors because the chunk has always been optional.</div><div><br></div><div>Your feedback here is very valuable because you have built many tools that work on core. With the proposal above, I hope such tools will have code like this:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div><div>case beam_lib:chunks(Beam, [debug_info]) of</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>  {ok,{Module,[{debug_info, {debug_info_v1, Backend, Metadata}}]}} -></div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>    case Backend:debug_info(core, Module, Metadata, [allow_source_lookup]) of</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>      {ok, CoreAST} -></div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>      {error, Reason} -></div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>        %% handle error</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>    end</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>  {error, Reason} -></div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>    %% handle error</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>end</div></div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><div><div class="gmail_signature"><div dir="ltr"><div><div><span style="font-size:13px"><div><span style="border-collapse:collapse"><b><br></b></span></div><div><span style="border-collapse:collapse">The tool no longer needs to retrieve Erlang AST and translate it to core nor know how to perform source lookups. Furthermore, the tool will work with any language that knows how to emit Core AST from the information stored in the Dbgi chunk.</span></div><div><span style="border-collapse:collapse"><br></span></div><div><span style="border-collapse:collapse">Please let me know if there are more questions or points I should clarify,</span></div><div><br></div><div><span style="border-collapse:collapse"><b>José Valim</b></span></div><div><span style="border-collapse:collapse"><div><span style="font-family:verdana,sans-serif;font-size:x-small"><a href="http://www.plataformatec.com.br/" target="_blank" style="color:rgb(42,93,176)">www.plataformatec.com.br</a></span></div><div><span style="font-family:verdana,sans-serif;font-size:x-small">Skype: jv.ptec</span></div><div><span style="font-family:verdana,sans-serif;font-size:x-small">Founder and Director of R&D</span></div><div><br></div></span></div></span></div></div></div></div></div></div></div></div></div>