[petsc-dev] ugliness due to missing lapack routines

[Barry Smith]

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

> 
> On Thu, Feb 7, 2013 at 3:23 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>    One would always debug (in the debugger) against the complete generated code, so it would be just like debugging the code we have now. Error message line numbers in generated tracebacks would be managed so they match the original source code.
> 
> Except that the code in the debugger would not be the code in the editor. That's confusing at the very least.

   Why would it not be? Your editor is not capable of ever displaying more than one buffer ever?

   You are still living in the old world of "this is the source code and its exact ASCII formatting is immutable",  you need to move to the new world where the "meaning of the source is immutable" but the display/view of the source code may be different for different people and at different times. 

   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.

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.

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

> or some templating system. I think we can generate the code on a case-by-case basis, but I'm worried that things could easily get out of hand. Having the explicit generated result available (as with ftn-auto) is nice because it helps us debug it. But if every file goes through this pass, it's likely to be a mess to manage all those generated temporary files.

   It could be a mess, but since all the generated versions have the same "base" AST and we will do things in a smart way it won't be a mess.

  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.

   Barry

>  
> 
> > I don't think you can do this sort of source modification without the abstraction being leaky and seemingly magical.
> 
>    We do have to be very careful and smart in how we do this, you are right, if we do it wrong then it will not simplify our life. I submit that it is not terribly difficult to do it right (once we have eliminated CPP) but people in the past who have done and botched things just didn't do it smart.
> In 1994 when starting PETSc 2.0 I debated using some kind of non-trivial (but not particularly flexible) code generation technique but decided to instead actually "manually write all code" including "stuff that could be generated into the code". I think that was the right decision at the time but I now think we don't need to live with that decision forever and think now is the time to try something different. (Like everything with PETSc it would be an evolutionary change in the code base, not an overthrow and revolution.)
> 
>   We are currently using CPP (among other things) as a code generator (Jed in particular is doing it heavily recently).  I submit that CPP is an extremely crappy code generator the only thing going for it is that CPP+C compilers manage the line numbers properly for debugging.
> 
> I agree that CPP is a crappy code generator. In lieu of hygienic macros, we either need to use a separate source language or some templating system. I think we can generate the code on a case-by-case basis, but I'm worried that things could easily get out of hand. Having the explicit generated result available (as with ftn-auto) is nice because it helps us debug it. But if every file goes through this pass, it's likely to be a mess to manage all those generated temporary files.