On Feb 7, 2013, at 1:48 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Thu, Feb 7, 2013 at 1:23 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > Since this is only BLAS-related, we should move all the BLAS-calls to a > > separate package with the sole purpose of providing a unified (binary) > > interface for the PETSc core. This will allow us to keep the PETSc core > > clean and put all the ugly stuff in that 'unification sublibrary'. This > > should eliminate any BLAS-related CPP usage from the PETSc core. > > I agree with this. This beastie may as well expose a C interface and have > proper error handling while we're at it. If it had a SetErrorHandler(), we > could wire it up to call back into PetscError, in which case we'd be able to > call it like a normal C function. > > > > >> Sometime I will send a detailed email explaining why I wish to totally > >> eradicate CPP. > > > > This is a noble goal with my full support, yet very hard to achieve. How do > > we want to tackle CHKERRQ for example? > > This is actually an easy one. Once we have a pure C code that can be > completely represented in a full AST, then it is trivial to have a "pretty > printer" that automatically adds into the code the equivalent of __FUNC__, > PetscFunctionBegin/End, CHKERRQ(), PetscStackCall() etc BEFORE passing the > code into the compiler to be compiled down to object code. > > Thus PETSc will actually ultimately become simpler C code without all the > additional stuff we have added for error checking/handling etc. Happy days > :-) > > I think this would be bad. You are wrong. > It creates lots of build system complexity and will make error messages trace > through the generated code that we never see explicitly. 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. > 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. Barry
