[petsc-dev] ugliness due to missing lapack routines

[Jed Brown]

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.


>
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130207/86b5eb01/attachment.html>