[petsc-dev] ugliness due to missing lapack routines

[Jed Brown]

On Thu, Feb 7, 2013 at 4:30 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

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

Right, anyone that wanted to look at PETSc source code. One of the reasons
I started hacking on PETSc is that I could set the Emacs tags file and jump
to the implementation so easily. If you do a bunch of magic with a special
preprocessor, users won't be able to easily make sense of the code.


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

What are the PETSc examples going to be? (Everyone starts by copying
those.) What about people that start by copying KSPCG to implement their
own Krylov method?


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

How does the preprocessor know which functions it should be injecting
PetscFunctionBegin and CHKERRQ and which ones it cannot (because they are
used in error handling, a callback, or something)? What is the syntax going
to be when you want a PetscTryMethod()? Is it going to be based on naming
conventions? I submit that these are all extensions of C because the code
will not behave as written (if it were actually C).


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

Cool, I'm glad it's that simple.


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

With smudge/clean, we never edit the clean version and they are just
different representations of the same thing. We still see diffs against the
clean version so it's not totally hidden.

Now you seem to be talking about expanding PetscTryMethod or the messy
macros in custom Fortran bindings (for which we need _some_ syntax, but it
won't be CPP because you're getting rid of CPP), which is not really
transparent to connect between the preprocessed and original versions.
Clearly the preprocessing does not have a well-defined inverse operation
(because it's not surjective), so if you edit the generated code, you will
have to mentally translate back to fix the original source.

Are you envisioning generating BAIJ kernels too? What about the VecScatter
packing routines? Or PetscValid* guards?


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

I mentioned a few cases above where the original source code has to
communicate some semantic information to the preprocessor. I think "work
with the AST" is far too vague of a concept at this point. Can you state
some concrete semantics so we can discuss whether what you want is feasible?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130207/b0308752/attachment.html>