<div class="gmail_quote">On 27 September 2011 16:53, Daniel Luna <span dir="ltr"><<a href="mailto:daniel@lunas.se">daniel@lunas.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The checking is all done in core erlang, which unfortunately ruins<br>
readability quite a bit.<br>
<br></blockquote><div><br></div><div>I've been meaning to learn core properly anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
You can use and copy whatever you want from that project<br>
(<a href="https://github.com/dLuna/Erlang-type-checker" target="_blank">https://github.com/dLuna/Erlang-type-checker</a>).<br>
<br>
</blockquote><div><br></div><div>Awesome - thank you very much.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">There are a few caveats:<br>
<br>
1. I have not tested this in a long time, and I'm heavily depending on<br>
Dialyzer for the type parsing.  If Dialyzer has been changed, my code<br>
might break.<br>
<br></blockquote><div><br></div><div>Ok that's perfect - I've struggled to get my head into which parts of Dialyzer can be reused in this way, so just having this as a head start is really helpful!</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2. Something changed in core erlang a few years back, so the code is<br>
broken as it stands today.  Should be an easy fix for someone wiling<br>
to learn a bit about core erlang (or wants to do some io:format<br>
programming).  I have marked the place of offending code.<br>
<br></blockquote><div><br></div><div>Ok thanks - again, a good learning exercise.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
3. Type checking using my current implementation is *slow*.  The<br>
reason for this is that I type convert the full argument even if only<br>
a minor piece is necessary. (e.g. given the type [any()] my code would<br>
still convert a list with a thousand deeply nested elements into its<br>
fully expanded type)  The fix for this is easy, but time consuming.<br>
<br></blockquote><div><br></div><div>I'm not planning on doing real type checking anyway - just seeing whether a specification for a function matches the -spec for any known code without any widening conversion. For instrumentation purposes this is very easy, for search it's a bit harder.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Anyway.  Even if it turns out that the core erlang parts are hard to<br>
reuse, the code server parts should be straight forward to copy.  If<br>
anyone wants to know more detail just ask and I'll see what I can<br>
remember.<br>
<br></blockquote><div><br></div><div>Brilliant - this should get me started playing with instrumentation and hopefully I can glue together the code server parts along with webmachine and a decent search index to make a hoogle-esque search service. Someone with a visually creative mind might then be willing/able to come along and actually make a reasonable looking front end for it then.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
ps. Assume that it's under an MIT license, and I'll add the actual<br>
license statement later this week.<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>Cool. I'll most likely license the instrumentation and code-search projects in the same way.</div><div><br></div><div><br></div><div>Cheers!</div>
<div><br></div><div>Tim</div></div>