<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 4:30 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 id=":592">  You are thinking of this wrong. You just have two (or more) different "representations"/"views" of the same source. Stop thinking in terms of source as "flat ASCII files", you are falling in the same trap that has screwed software development (except for a few odd ball languages that come with their own environment) for 50 years.<br>

<br>
   I believe that the "oddball languages" were correct in not equating source with "flat ACII files" but very wrong in requiring one to work in their "oddball" environment (hence they did not spread widely).  I am claiming that one can get the benefit of not equating source with<br>

"flat ACII files" without requiring "oddball environments".<br>
<div class="im"><br>
> 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.<br>

<br>
</div>   No, only PETSc developers may want to do this, end users would not need or care about this; if they choose to step the debugger through PETSc code they would just see the complete generated code, whatever it may be at that time.<br>
</div></blockquote><div><br></div><div style>Right, anyone that wanted to look at PETSc source code. One of the reasons I started hacking on PETSc is that I could set the Emacs tags file and jump to the implementation so easily. If you do a bunch of magic with a special preprocessor, users won't be able to easily make sense of the code.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":592">
<div class="im"><br>
> Would we use this method in examples or would they all contain CHKERRQ stuff?<br>
><br>
> It would be a disaster to require everyone to run our preprocessor just to compile their code.<br>
<br>
</div> We would not require this. They could (and get nice tracebacks etc) for free or they could use the macros like they can now or they could just write code without the macros (and be stuck like the usual C programmers).<br>
</div></blockquote><div><br></div><div style>What are the PETSc examples going to be? (Everyone starts by copying those.) What about people that start by copying KSPCG to implement their own Krylov method?</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":592">
<div class="im"><br>
> It is tantamount to creating another language.<br>
<br>
</div>  No it is not tantamount to creating another language because the language is C! and the "preprocessor" just works on C!<br></div></blockquote><div><br></div><div style>How does the preprocessor know which functions it should be injecting PetscFunctionBegin and CHKERRQ and which ones it cannot (because they are used in error handling, a callback, or something)? What is the syntax going to be when you want a PetscTryMethod()? Is it going to be based on naming conventions? I submit that these are all extensions of C because the code will not behave as written (if it were actually C).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":592">
We'll be designing this stuff so we won't allow it to be bad.<br></div></blockquote><div><br></div><div style>Cool, I'm glad it's that simple.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":592"><div class="im">
> Wait, which version do we edit when we don't have a bug?<br>
<br>
</div>   That is totally up to you. Remember you explained the version of "smudged" to me, I don't need to explain it to you.<br></div></blockquote><div><br></div><div style>With smudge/clean, we never edit the clean version and they are just different representations of the same thing. We still see diffs against the clean version so it's not totally hidden.</div>
<div style><br></div><div style>Now you seem to be talking about expanding PetscTryMethod or the messy macros in custom Fortran bindings (for which we need _some_ syntax, but it won't be CPP because you're getting rid of CPP), which is not really transparent to connect between the preprocessed and original versions. Clearly the preprocessing does not have a well-defined inverse operation (because it's not surjective), so if you edit the generated code, you will have to mentally translate back to fix the original source.</div>
<div style><br></div><div style>Are you envisioning generating BAIJ kernels too? What about the VecScatter packing routines? Or PetscValid* guards?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":592"><div class="im">
> You must mean C plus some yet-to-be-defined templating system. I've never seen such a thing done well.<br>
<br>
</div>  Before PETSc I'd never seen a decent iterative solver library, should I have concluded that it was impossible and just followed the Jack and Jim approach to numerical software development?<br>
<br>
   The "yet to be defined templating system" will be orthogonal to the C source code. It will work with the AST (likely defined by routines that operate on the AST), it will not be syntax shoved on top of C like C++ templates.</div>
</blockquote></div><br>I mentioned a few cases above where the original source code has to communicate some semantic information to the preprocessor. I think "work with the AST" is far too vague of a concept at this point. Can you state some concrete semantics so we can discuss whether what you want is feasible?</div>
</div>