[petsc-dev] ugliness due to missing lapack routines

[Barry Smith]

On Feb 7, 2013, at 4:07 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> 
> On Thu, Feb 7, 2013 at 3:50 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>    Why would it not be? Your editor is not capable of ever displaying more than one buffer ever?
> 
> Now I'll have two versions of the "same file".

   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.

   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 
"flat ACII files" without requiring "oddball environments".

> 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.

   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.

> Would we use this method in examples or would they all contain CHKERRQ stuff?
> 
> It would be a disaster to require everyone to run our preprocessor just to compile their code.

 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).

> It is tantamount to creating another language.

  No it is not tantamount to creating another language because the language is C! and the "preprocessor" just works on C!

  I think you (like Matt) got turned off to "generated" code because of bad experiences in the past. I submit that your bad experiences were the result of badly implemented generated code, not because generated code by its nature must be painful to work with.

We'll be designing this stuff so we won't allow it to be bad.


>  
> 
>    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….)
> 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.
> 
> Wait, which version do we edit when we don't have a bug?

   That is totally up to you. Remember you explained the version of "smudged" to me, I don't need to explain it to you.
>  
> 
> 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.
> 
> Yeah, I think that having multiple versions will be much more difficult to work with than you seem to think.
>  
> > I agree that CPP is a crappy code generator. In lieu of hygienic macros, we either need to use a separate source language
> 
>    Why? C is a great language, we can just generate from C.
> 
> You must mean C plus some yet-to-be-defined templating system. I've never seen such a thing done well.

  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?

   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.

 Barry

>  
> 
>   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.
> 
> 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.