<div id="reply-content">
        you could compile using 'P' or 'E' to get a source listing after preprocessing, compile that and debug from that source. not optimal, but better than not having source at all
    </div>
    <div id="A07B935102CB4A439084485F411B7F20"><div><br></div>-- <br>alisdair sullivan<br><div>Sent with <a href="http://www.sparrowmailapp.com/?sig">Sparrow</a></div><div><br></div></div>
     
    <p style="color: #A0A0A8;">On Thursday, 24 May, 2012 at 6:11 AM, Max Bourinov wrote:</p>
    <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
        <div id="quoted-message-content"><div><div>Ah I see :-)</div><div><br></div><div>The "bad" key-word here is "generic tool provider".</div><div><br></div><div>Maybe good README.markdown file will help somehow? It always helps when code cannot solve everything.</div>

<div><br></div><div>Best regards,</div><div>Max</div><br><br>
<br><br><div>On Thu, May 24, 2012 at 4:54 PM, Vlad Dumitrescu <span dir="ltr"><<a href="mailto:vladdu55@gmail.com" target="_blank">vladdu55@gmail.com</a>></span> wrote:<br><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Thu, May 24, 2012 at 2:38 PM, Max Bourinov <<a href="mailto:bourinov@gmail.com">bourinov@gmail.com</a>> wrote:<br>
> You are right, it is nearly impossible to properly work with macros in<br>
> IDE. I never tried erlide. Does it give any coding performance boost? I use<br>
> sublime2 and emacs. Most of Erlangers uses Emacs (as far as I know).<br>
<br>
</div>Well, there's a whole bunch of them at Ericsson use erlide, plus<br>
others that I only have fragmentary information. Of course, I believe<br>
that an IDE helps the development process, but I know that it is a<br>
controversial question. Some people like it, some don't.<br>
<div><br>
> About your example: You can agree within your team which macros you will use<br>
> and which not. For example:<br>
> 1. No complicated code snippets in macros - this is good for code<br>
> simplicity.<br>
> 2. All atoms that are flying between modules must be in macros. Or even<br>
> better - use records for that.<br>
> Simple rules - simple code. Macros are good. They are cool. Use right tool<br>
> and you have no problems.<br>
<br>
</div>Yes, that would be good enough for me -- but as a generic tool<br>
provider, I can't force people to follow any rules. There is also the<br>
issue of legacy code, that nobody will touch as long as it works.<br>
<br>
Anyway, the simple usage you describe above doesn't require a<br>
preprocessor, these could be handled inside the language with some<br>
additions to the compiler. This would enforce the cleanliness and I<br>
don't think anybody would feel sorry about that. For the dirty work,<br>
the preprocessor could still be there, if needed.<br>
<br>
regards,<br>
Vlad<br>
</blockquote></div><br>
<div>_______________________________________________</div><div>erlang-questions mailing list</div><div>erlang-questions@erlang.org</div><div>http://erlang.org/mailman/listinfo/erlang-questions</div></div></div>
         
         
         
         
    </blockquote>
     
    <div>
        <br>
    </div>