> On Jan 31, 2018, at 3:12 PM, Jed Brown <j...@jedbrown.org> wrote:
>
> I think his point is that Fortran has a one-line if statement (no then
> and no endif), which simplifies the macro and usage.
>
> if (cond) SETERRQ(...)
That doesn't work because the SETERRQ() has both the call to the error
handler followed by a return which is two lines in Fortran.
>
> "Smith, Barry F." <bsm...@mcs.anl.gov> writes:
>
>> No, that is CHKERRQ()
>>
>>
>>> On Jan 31, 2018, at 2:02 PM, Lisandro Dalcin <dalc...@gmail.com> wrote:
>>>
>>> Maybe I'm missing something, but maybe this define is all what you need?
>>>
>>> #define SETERRQ(ierr) if (ierr/=0) call PetscError(comm,ierr,0,"message")
>>>
>>> program main
>>> integer ierr,comm
>>> call something(ierr); SETERRQ(ierr)
>>> end program main
>>>
>>>
>>>
>>> On 6 January 2018 at 02:33, Smith, Barry F. <bsm...@mcs.anl.gov> wrote:
>>>>
>>>>
>>>>> On Jan 5, 2018, at 5:00 PM, Jed Brown <j...@jedbrown.org> wrote:
>>>>>
>>>>> "Smith, Barry F." <bsm...@mcs.anl.gov> writes:
>>>>>
>>>>>>> On Jan 5, 2018, at 4:18 PM, Jed Brown <j...@jedbrown.org> wrote:
>>>>>>>
>>>>>>> "Smith, Barry F." <bsm...@mcs.anl.gov> writes:
>>>>>>>
>>>>>>>>> On Jan 5, 2018, at 12:45 PM, Jed Brown <j...@jedbrown.org> wrote:
>>>>>>>>>
>>>>>>>>> "Smith, Barry F." <bsm...@mcs.anl.gov> writes:
>>>>>>>>>
>>>>>>>>>>> On Jan 4, 2018, at 5:10 PM, Blaise A Bourdin <bour...@lsu.edu>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Jan 4, 2018, at 3:16 PM, Smith, Barry F. <bsm...@mcs.anl.gov>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It's changed a bit. It is better but you need to understand how
>>>>>>>>>>>> the new one works, so take a few minutes to see how it works
>>>>>>>>>>>> before converting.
>>>>>>>>>>> Got it.
>>>>>>>>>>> An example or a link to the fortran macro definition from the man
>>>>>>>>>>> page would be nice
>>>>>>>>>>> I am confused about the rationale for putting the endif in the
>>>>>>>>>>> macro, though.
>>>>>>>>>>
>>>>>>>>>> It matches the C paradigm
>>>>>>>>>
>>>>>>>>> Hardly.
>>>>>>>>
>>>>>>>> It matches the paradigm as close as can be reasonable done.
>>>>>>>>
>>>>>>>> I debated putting the then into the macros also.
>>>>>>>>
>>>>>>>>> #define SETERRQ(c,ierr,s) then ;call
>>>>>>>>> PetscError(c,ierr,0,s);return;endif
>>>>>>>>
>>>>>>>> So usage would be
>>>>>>>>
>>>>>>>> if (bad) SETERRQ();
>>>>>>>>
>>>>>>>> would that be better.
>>>>>>>
>>>>>>> No, Fortran isn't C.
>>>>>>>
>>>>>>> if (bad) then
>>>>>>> SETERRQ(...)
>>>>>>> endif
>>>>>>>
>>>>>>> It doesn't get used so much from Fortran that we need to conceal the
>>>>>>> language constructs.
>>>>>>
>>>>>> It will, eventually I want all Fortran examples/tests to have checks on
>>>>>> every call (like with have in C).
>>>>>
>>>>> CHKERRQ does the if internally, so it also has the endif.
>>>>
>>>> What is the relevance of this statement.
>>>>>
>>>>> SETERRA/SETERRQ is used a total of 34 times in 17 Fortran files.
>>>>> SETERRQ is used a median of zero times and an average of less than 1 in
>>>>> the C examples.
>>>>
>>>> I am not sure why you are saying this. My resistance to change has
>>>> nothing to do with how often it is used.
>>>>
>>>> I am leaning to changing it but don't want to until all the test harness
>>>> branches etc get into master. So it will be a few days.
>>>>
>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> This Fortran:
>>>>>>>>>
>>>>>>>>> #define SETERRQ(c,ierr,s) ;call PetscError(c,ierr,0,s);return;endif
>>>>>>>>>
>>>>>>>>> This would be like writing this C
>>>>>>>>>
>>>>>>>>> #define SETERRQ(c,ierr,s) return PetscError(...); }
>>>>>>>>>
>>>>>>>>> to be used like
>>>>>>>>>
>>>>>>>>> if (BAD) { SETERRQ(comm, ierr, "why")
>>>>>>>>>
>>>>>>>>> which is just bananas and still not as gross as the Fortran. You
>>>>>>>>> might
>>>>>>>>> not have noticed this because SETERRQ is not called from any of
>>>>>>>>> PETSc's
>>>>>>>>> Fortran examples.
>>>>>>>>
>>>>>>>> But SETERRA() is and has the same pattern.
>>>>>>>
>>>>>>> It isn't syntactically correct when !defined(PETSC_USE_ERRORCHECKING).
>>>>>>> The endif isn't going to kill anyone and pulling it out of the macro
>>>>>>> will make it easier to understand and avoid the circus antics when used
>>>>>>> in any context other than a positive conditional with no else clause.
>>>>>>
>>>>>> I'll take this under advisement. Of course in our examples the endif
>>>>>> will ALWAYS be on the same line as the rest. Using three lines for a
>>>>>> SETERRQ() is ugly.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Beside not having unmatched if / end if in my code, in a select
>>>>>>>>>>> case construct, I have to write something as ugly as
>>>>>>>>>>>
>>>>>>>>>>> select case (i)
>>>>>>>>>>> case(1)
>>>>>>>>>>> !do something
>>>>>>>>>>> case(2)
>>>>>>>>>>> !do something else
>>>>>>>>>>> case default
>>>>>>>>>>> if (0 == 0) then
>>>>>>>>>>>
>>>>>>>>>>> SETERRQ(PETSC_COMM_WORLD,PETSC_ERR_ARG_OUTOFRANG,”invalid value”)
>>>>>>>>>>> end select
>>>>>>>>>>>
>>>>>>>>>> What is ugly about this ? except that you put the SETERRQ on a new
>>>>>>>>>> line which you did not need to do.
>>>>>>>>>
>>>>>>>>> Reread the above code. Requiring the dummy opening if statement is
>>>>>>>>> nuts.
>>>>>>>>
>>>>>>>> Agreed. He should not use SETERRQ() in this case, should call the
>>>>>>>> error functions directly)
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> How do you want to write it so it is prettier?
>>>>>>>>>
>>>>>>>>> SETERRQ should not include that endif. CHKERRQ has the opening if and
>>>>>>>>> thus needs the closing too (so it's as intended). Also note that your
>>>>>>>>> first reply to Blaise was talking about CHKERRQ when he was asking
>>>>>>>>> about
>>>>>>>>> SETERRQ.
>>>>>>>>
>>>>>>>> Hmm, I'm not sure about. Oh well, it doesn't matter. You have
>>>>>>>> convinced me of anything.
>>>>
>>>
>>>
>>>
>>> --
>>> Lisandro Dalcin
>>> ============
>>> Research Scientist
>>> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
>>> Extreme Computing Research Center (ECRC)
>>> King Abdullah University of Science and Technology (KAUST)
>>> http://ecrc.kaust.edu.sa/
>>>
>>> 4700 King Abdullah University of Science and Technology
>>> al-Khawarizmi Bldg (Bldg 1), Office # 0109
>>> Thuwal 23955-6900, Kingdom of Saudi Arabia
>>> http://www.kaust.edu.sa
>>>
>>> Office Phone: +966 12 808-0459
