<div dir="ltr">On Thu, Feb 7, 2013 at 5:07 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Thu, Feb 7, 2013 at 3:50 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>   Why would it not be? Your editor is not capable of ever displaying more than one buffer ever?<br></div>
</blockquote><div><br></div></div><div>Now I'll have two versions of the "same file". I could probably even script Emacs to handle this better than it normally does (like a keybinding to flip between original and preprocessed), but everyone that interacted with the code would have to do the same. Would we use this method in examples or would they all contain CHKERRQ stuff?</div>

<div><br></div><div>It would be a disaster to require everyone to run our preprocessor just to compile their code. It is tantamount to creating another language.</div><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>

<br>
   If you want to think in terms of revision control systems and working directories then when using the debugger your "smudged" version of the code has all the "generated" (CHKERRQ….)<br>
stuff displayed. How it could work: while using the debugger you realize a bug exists, you "fix" the bug in the "smudged" version in your working directory based on what you see in the debugger, run the compile, load the new executable in the debugger, verify your fix works and then "add" in git your smudged (now fixed) code into the "index" at which point it is "desmudged" back into the standard form. You can then commit and push.<br>

</div></blockquote><div><br></div></div><div>Wait, which version do we edit when we don't have a bug?</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>

<br>
Note that this does not even require some GUI development system and is similar to our current work flow. The only "new" concept is the concept of having various "smudged" versions of the code in the working directory.<br>

</div></blockquote><div><br></div></div><div>Yeah, I think that having multiple versions will be much more difficult to work with than you seem to think.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div>
> I agree that CPP is a crappy code generator. In lieu of hygienic macros, we either need to use a separate source language<br>
<br>
</div>   Why? C is a great language, we can just generate from C.<br></div></blockquote><div><br></div></div><div>You must mean C plus some yet-to-be-defined templating system. I've never seen such a thing done well.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div>
<br>
  Generating code on a case by case ad hoc basis will result in a mess. Doing it in a systematic way using a good representation need not.</div></blockquote></div></div><br>If you really believe this, start proposing semantics. I think it will be very difficult to avert a disaster and I don't think it could possibly offer that much value.</div>

</div>
</blockquote></div><br>I think we have all the facts on the high level discussion. Concrete proposals to be voted on:</div><div class="gmail_extra"><br></div><div class="gmail_extra">  1) Get rid of all function-like CPP things</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">  2) Get rid of (Matt says) innocuous CPP things, like CHKERRQ</div><div class="gmail_extra"><br></div><div class="gmail_extra">  3) Generate full functions for missing LAPACK stuff, which will probably necessitate changing petscblaslapack.h</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">    Matt<br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>