[petsc-dev] ugliness due to missing lapack routines

[Jed Brown]

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

>
> On Feb 7, 2013, at 5:56 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> >
> > On Thu, Feb 7, 2013 at 5:51 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >    These are in the category of  those that CANNOT be trivially
> converted to C functions. They are the tough nuts to crack. We need to
> categorize them and see what makes sense to do with them.
> >
> > Do you agree that the "new" version of those constructs will not be
> plain C? Either you will be moving non-trivial logic from C to the
> preprocessor itself (thus distributing logic between preprocessor
> implementation and "normal" source files) or you will be adding some extra
> semantics to the dialect of "C" that will be understood by the preprocessor?
>
> 1)   All of the "sticking in extra error processing stuff" like
> PetscFunctionBegin/CHKERRQ()/PetscStackCall()  does not require any new
> syntax in the C language.
>

It's just syntax, easily produced automatically from our editors, and easy
to "look past". Either we put it in automatically everywhere, with some
annotation or list of rules about where to _not_ put it in, or we put it in
everywhere we need it. There are a lot of ways that we could handle this so
let's focus on the more interesting parts.


>
> 2)   Macros like PetscTryMethod() won't be needed. Instead the user
> interface functions like KSPGMRESSetRestart() would be completely
> auto-generated from the underlying implementation routines
> KSPGMRESSetRestart_GMRES().
>

Recall that there are multiple different implementations of the same
interface (_GMRES and _FGMRES in this case).


>
>     Now the question of how the system knows that the routine
> KSPGMRESSetRestart_GMRES() should auto-generate KSPGMRESSetRestart() is a
> good question. I don't think we need to resolve that now; it could be a
> formatted comment in the code, it could be based on the function naming
> convention; it is really associated with our class structure (whether we
> want to teach our "source tools" about the class structure comes later).
> But it doesn't need to require adding syntax to C.
>

No, you're just changing the behavior of the code by annotating using
comments. I.e., extending the language. It's not plain C because the
"comments" are semantically significant and not even optional.


> 3)   Code generation for different types and block sizes
>
>    No matter what we do it couldn't be worse then the absolutely horrible
> stuff you added recently in the top of sfbasic.c Didn't you feel all
> itching when you were typing that stuff in?
>

Sure, but it's more contained and more generic than vpscat.h/vpscat.c. I
would have used C++ templates there (very isolated) if we could use such a
thing. I actually think C++ templates solve that problem about as well as
any system could. (It's everything else templates are used for that is the
disaster.)


>
>    I actually would like the original routine(s) to be pure C and then to
> separately indicate what other functions to build from that original one.
> So for example if you have myfunction(int a,double *b, int *c) and you want
> a version of the function build from my function() with arguments
> int,int*,double*. You would tell the system this and it would generate the
> new version. Note that because the AST "understands" the routine as C  (not
> ascii) there is no reason to do all the <type> crap that C++ templates or
> your horrific sfbasic.c code requires.
>

HOW does it "understand" the semantics you are writing down? Is it through
more annotation that you're going to put in the comments? Or magic names
and a piece of code in the preprocessor that recognizes that name and
pattern?


>
>   So my answer is yes there will be no new language syntax added and yes
> the "non-trivial" logic will be in a different place from the code.  But I
> submit that the "non-trivial" logic will generally be trivial certainly it
> will be trivial to reproduce all the horrible stuff we manage now with CPP.
> And the logic isn't associated with any one particular chunk of C code so
> doesn't need to be with that particular source code.
>

The PetscOptions macros are far from trivial logic.


>
>    Is what I propose possible? I don't know, nor do I particularly care,
> but I do know that the stuff at the top of sfbasic.c is not a good approach
> and the more stuff we add like that the more difficult it will ever get to
> do things "a better way" since that kind of CPP can never be represented in
> a way that allows manipulating the source code via source code tools
> (because CPP plus C is not a language).
>

How would you like to manipulate that code? What would that achieve?


>
>    Barry
>
> Jed,
>
>     I am not meaning to attack you in particular for utilizing CPP in this
> way. I am very guilty of it as well, because at those times I felt it was
> the only "reliable" way to do things.  I am now hoping I was wrong.
>

I felt it was the least-bad of the available choices in this case. I'd like
to have a better mechanism, but that code only took a couple hours to write
and it's working reliably now. I believe MPI should provide a way for us to
avoid writing code like that, but not now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130207/04a76b34/attachment.html>