[petsc-dev] ugliness due to missing lapack routines

Matthew Knepley knepley at gmail.com
Thu Feb 7 16:31:31 CST 2013


On Thu, Feb 7, 2013 at 5:07 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

>
> On Thu, Feb 7, 2013 at 3:50 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>>    Why would it not be? Your editor is not capable of ever displaying
>> more than one buffer ever?
>>
>
> Now I'll have two versions of the "same file". 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. 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. It is tantamount to creating another language.
>
>
>>
>>    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.
>>
>
> Wait, which version do we edit when we don't have a bug?
>
>
>>
>> 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.
>>
>
> Yeah, I think that having multiple versions will be much more difficult to
> work with than you seem to think.
>
>
>>  > 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.
>>
>
> You must mean C plus some yet-to-be-defined templating system. I've never
> seen such a thing done well.
>
>
>>
>>   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.
>>
>
> If you really believe this, start proposing semantics. I think it will be
> very difficult to avert a disaster and I don't think it could possibly
> offer that much value.
>

I think we have all the facts on the high level discussion. Concrete
proposals to be voted on:

  1) Get rid of all function-like CPP things

  2) Get rid of (Matt says) innocuous CPP things, like CHKERRQ

  3) Generate full functions for missing LAPACK stuff, which will probably
necessitate changing petscblaslapack.h

    Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130207/49e0069f/attachment.html>


More information about the petsc-dev mailing list