[petsc-dev] What needs to be done before a release?

[Jed Brown]

On Fri, Jun 1, 2012 at 3:38 PM, Blaise Bourdin <bourdin at lsu.edu> wrote:

> Having the interfaces requires those extra interface files in the includes
> that we already hate so much, and we can't protect the headers (to make
> including the right ones simple like in C) because you have to include them
> for every subroutine.
>
>
> Not really. You don't need to include the modules in each subroutine or
> function if they are included (used) in the Program or Module in which the
> function is defined
>

I was referring to #include *.h90 files.


> Apart for [1], I fully agree. I actually think that there should only be
> two way to use fortran: the old f77 way without any type checking,
> interface, and where all petscobjects are integer, or the right way which
> you described.
>

What about people with legacy code that want to use VecGetArrayF90? Should
they have to rewrite with type(Mat) everywhere just for that change? What
about mixing two Fortran codes, one of which does things the new way and
one does the old way?



> Unfortunately, that forces people to spell out things like type(Mat) [2]
> and XGetContext() either requires an explicit interface written by the user
> [3] or use of the ISO C bindings in the interface [4].
>
> Not really. As long as your context is not too large (so that allocating a
> copy and copying the data won't kill you), you can always write a generic
> interface for XGetContext that returns an array of your favorite data type,
> then use transfer. And when your context is large, you should pass by
> address anyway). Conceptually, it is not really different from casting into
> a *void. McCormick has a nice writeup on this
> http://www.macresearch.org/advanced_fortran_90_callbacks_with_the_transfer_function
>
> How does using iso_c_binding helps with a fortran library called from
> fortran?
>

I had a 50 message conversation about this with Ondrej Certik this winter.
He eventually agreed with me and summarized the various choices here.

http://fortran90.org/src/best-practices.html#type-casting-in-callbacks

Choice 5 (V) is the preferred way to do this. With transfer (choice 6), you
have to write 30 lines of boilerplate to define typeX2data and data2typeX
for each typeX that you want to be able to pass through a callback (but at
least you don't have to write an interface to every function you pass the
context through). Transfer is also a very different (and worse) semantic
because you get a copy of the actual data structure, thus any modifications
that you make from the callback (e.g. logging some statistics) will not be
visible in the external context.

Compare the gists (cited at the bottom of that page)

https://gist.github.com/1665626 (best way I know, uses ISO C bindings)
https://gist.github.com/1665630 (note the need for my_data_type.f90)

I'm relieved that ISO C bindings exist, at least it's possible to write
modular software now, but you know the standards committee was impaired or
sadistic when the foreign function interface is better than the native
function interface.

> I can think of no explanation for this absurdity other than that the
> Fortran language standards committee is the most successful global trolling
> agency in modern history [5].
>
> Not even an emoticon? I thought this was funny.

> [1] Better, but it would be best for them to stop using Fortran.
>
> Why not. But what is the alternative knowing that I am not willing to give
> up array sections, operator overloading and vector operations? Are you
> going to suggest that I switch to C++?
>

You are aware that every use of non-leading dimension stride 1 array
sections involves a dynamic memory allocation, a copy in, and a copy out?


> [2] No #includes means no macros [6] and no equivalent of typedef.
>
> The only macro I would miss are CHKERRQ and SETERRQ. I would actually make
> an exception for these two. For numerical and string types, the fortran way
> of doing typedef is kind.
>

The kind parameter still pollutes the namespace (don't get me started on
how bad they botched namespaces ;-)) and has to appear throughout the code
and can't be used for types like Vec, Mat, etc. Fortran could claim to have
a useful typedef when I can do the equivalent of

typedef struct _p_KSP *KSP;
typedef PetscErrorCode (*TSIFunction)(TS,PetscReal,Vec,Vec,Vec,void*);

> [3] Disaster because (a) it is maintained by the user with no way to check
> that it is correct and (b) the user may need multiple incompatible
> definitions in the same project.
> [4] Indeed, the best way to write a Fortran library called from Fortran is
> to use the ISO C bindings.
> [5] The people who dream up ways to link MKL and the Portland Group
> deserve honorable mention.
> [6] Type macros are terrible anyway because of the aforementioned
> punchcard nostalgia leading to different projects adopting different
> line/format styles and compilers having no portable way to select.
>
> I don't know of any compiler which does not default to free form for
> .f90/.F90 files, do you? Free format has been around for over 20 years.
> That some people insist on coding on 72 cols (or is it 78?) in the days of
> large screens is beyond me indeed.
>

As a library, we should be able to make the library part work the same
regardless of which choice the *user* makes. This is especially important
when coupling two codes written by users with different conventions. You
will notice in PETSc Fortran files that we place the line continuation
character (&) in column 73 so that it is ignored by a fixed form compiler
(because it's not between columns 7 to 72) as well as a continuation
character in column 6 so that fixed form compilers know it's a
continuation. We also avoid using line continuations at all in rows that
have macros because the macro may expand to different length strings.


> So I guess that you guys don't want an explicit interface for
> PetscBagRegisterEnum, right? I'll fix the harmless bugs in the current
> binding, then.
>

It should be there just like VecGetArrayF90 needs one, I just felt like
ranting. ;-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120601/b65ff61f/attachment.html>