<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 11:29 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=":79i">   Because I didn't have a decent build system/preprocessor/whatever back then :-)<br>
<br>
   You are right there is a lot of potential overlap with configuring more at compile time versus using runtime options. PETSc has always focused on runtime flexibility (and it has served us well) but with things like mixing precisions and small problems I think we need to clean up our act on configuration time flexibility and stop using regexp and CPP as our configuration time tools.<br>

<br>
   My firm believe is that eventually the syntax and mechanism for runtime polymorphism and compile time polymorphism will merge and from the code developers point of view be completely flexible.<br></div></blockquote><div>
<br></div><div style>Yes, the syntactic difference between early and late binding is jarring in most languages.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":79i">
<br>
  So yes eventually I want users to be able to use the same mechanism to say at compile time I want -snes_rtol to be .035  or -dm_grid_x 83  or -ksp_type lgrmes or to instead decide to say it at run time (no, no JIT, they would be using a different library in the two cases).<br>
</div></blockquote><div><br></div><div style>You're going to compile a different library for every combination so that it doesn't need to build it at run-time? Or are you just JITing and caching the result of the JIT pass in a "library" that you'll keep around for a while (maybe several separate runs) before it gets gc'd?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":79i">
<br>
   Yes I am advocating a radical overthrow of the current state of affairs in software, but in an evolutionary way :-)</div></blockquote></div><br>Good luck. I think your proposal is insufficiently specified and has fatal flaws that will prevent it from functioning in anything resembling the form we're currently discussing.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>I'm more interested in addressing specific classes of desired fusion at a local level and in a way that doesn't spoil the user interface. I don't want to write logic in the code manipulator.</div>
</div>