<div dir="ltr"><div><div><span class=""><span class=""><span class=""><span class="">I have now push the first version of dialyzer and LFE on to github in the lfe-dev branch. </span></span></span></span><span class=""><span class="">See the mailing list for more information <a href="https://groups.google.com/forum/#%21forum/lisp-flavoured-erlang" class="" rel="noreferrer" target="_blank">https://groups.google.com/forum/#!forum/lisp-flavoured-erlang</a></span></span><span class=""><span class=""><span class=""><span class=""></span></span></span></span>.<br><br></div>It is possible but dialyzer is not giving up without a fight.<br><br></div>Robert<br><br><div class="gmail_extra"><br><div class="gmail_quote">On 18 November 2014 11:36, Peer Stritzinger <span dir="ltr"><<a href="mailto:peerst@gmail.com" target="_blank">peerst@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2014-11-17 17:26:01 +0000, Robert Virding said:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The reason I would like to be able to handle multiple file types is to simplify checking systems with parts which are written in different languages.<br>
</blockquote>
<br></span>
+1<br>
<br>
This would be useful to my IEC61499 PLC language compiler too, especially since I have some native (here meaning in Erlang) implemented behaviour callback modules which can then be checked if they implement a matching interface to the PLC interface part.<br>
<br>
And since I'm also generating core like LFE opening up this interface to Dialyzer would help me greatly.<br>
<br>
Especially so since I'm compiling a statically typed language anyway and could derive the typespecs of the underlying Erlang types from this information.<br>
<br>
Cheers,<br>
-- Peer<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Robert<br>
<br>
<br>
On 17 November 2014 18:19, Robert Virding <<a href="mailto:rvirding@gmail.com" target="_blank">rvirding@gmail.com</a>> wrote:<br>
Something much naughtier and more basic.<br>
<br>
- Make LFE local copies of the relevant dialyzer modules which have been hacked to be able to handle LFE files as input (with a new --lfe option)<br>
- Run dialyzer using -pa to push the local module directory first so as to use these special modules instead of the standard ones<br>
<br>
This will make it possible to use dialyzer on LFE files and other .erl or .beam files as well. Maybe with a little more hacking fix have multiple file types. Of course if dialyzer was to be opened up so that it would use the filename extension to pick the right versions of the functions Stavros mentioned then this would be much simpler. Wink, wink, nudge nudge. :-)<br>
<br>
This is my plan anyway.<br>
<br>
Robert<br>
<br>
P.S. Having LFE generate erlang AST has never been an option as it is very close to core and it would take a lot of effort to go back to erlang which would then be undone by the erlang compiler.<br>
<br>
<br>
On 17 November 2014 17:49, José Valim <<a href="mailto:jose.valim@plataformatec.com.br" target="_blank">jose.valim@plataformatec.com.<u></u>br</a>> wrote:<br>
Robert, what would a specialized version of dialyzer entail? A fork? A specific front-end? Curious. :)<br>
<br>
On Monday, November 17, 2014, Robert Virding <<a href="mailto:rvirding@gmail.com" target="_blank">rvirding@gmail.com</a>> wrote:<br>
Ah, so then in principle I can make my own specialised versions of the dialyzer load modules which takes the core which the LFE compiler generates and extracts the core and the type/spec data dialyzer needs. This without any Erlang AST which LFE never generates anyway.<br>
<br>
Now we are getting somewhere useful. With this we don't really need to be able to store core in the .beam files if we can accept using source files as input.<br>
<br>
Robert<br>
<br>
<br>
On 17 November 2014 17:32, Stavros Aronis <<a href="mailto:aronisstav@gmail.com" target="_blank">aronisstav@gmail.com</a>> wrote:<br>
For .erl files, dialyzer calls the compiler with 'to_pp', which stops the compilation before code is converted to Core, and reads attributes from there.<br>
<br>
Judging from v3_core, line 170 the two representations should be compatible.<br>
<br>
/Stavros<br>
<br>
On Mon, Nov 17, 2014 at 5:11 PM, Robert Virding <<a href="mailto:rvirding@gmail.com" target="_blank">rvirding@gmail.com</a>> wrote:<br>
>From where does it get it if I have .erl files as input? From the AST as well? Do you know if there is any difference in the data itself between the AST and core? I am guessing not but want to check. If there is no difference then the info could be gotten from Core. This would make it easier to use dialyzer together with LFE.<br>
<br>
Robert<br>
<br>
<br>
On 17 November 2014 17:03, Stavros Aronis <<a href="mailto:aronisstav@gmail.com" target="_blank">aronisstav@gmail.com</a>> wrote:<br>
Hi Robert,<br>
<br>
Dialyzer gets this info from beam_lib:chunks(File, [abstract_code]) which corresponds to the AST and is included in beam files if +debug_info is used while compiling.<br>
<br>
To my knowledge there is no reason to not let sources be combined (except perhaps when building a PLT), but the implementation seems to require uniformity.<br>
<br>
Relevant functions: dialyzer_utils:get_abstract_<u></u>code_from_{src,beam}/{1,2}, get_spec_info/3, get_record_and_type_info/1.<br>
<br>
Regards,<br>
<br>
Stavros<br>
<br>
On Mon, Nov 17, 2014 at 4:53 PM, Robert Virding <<a href="mailto:rvirding@gmail.com" target="_blank">rvirding@gmail.com</a>> wrote:<br>
>From where does dialyzer get the user added type and spec info? From the AST, or from Core erlang which contains the same type/spec data? And why? Can I control it?<br>
<br>
An extra question: why doesn't dialyzer allow me to mix input from both .erl and .beam files? Or does it and I have missed that?<br>
<br>
Robert<br>
<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-- <br>
<br>
<br>
José Valim<br>
<a href="http://www.plataformatec.com.br" target="_blank">www.plataformatec.com.br</a><br>
Skype: jv.ptec<br>
Founder and Lead Developer<br>
</blockquote>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div></div>