Re: [Plplot-devel] A possible design of our new Fortran binding

[Arjen M. <Arj...@de...>]

Hi Alan, James,



I am not entirely sure that it is possible to eliminate all intermediate C code, for instance because of storing pointers to callback functions and NULL arguments, but using the iso_c_binding features it will at the very least be possible to let the linker detect missing interfaces: the problem with plbtime and others was that there was a C wrapper, callable from Fortran but no Fortran interface definition. In the new set-up none of the C wrapper code that may still be required will have the name mangling done on the C side - which means the linker will detect any mismatch.



As for James's observations:

Ad 1) I have not noticed anything like that up to now

Ad 2) As far as I know variadic interfaces are indeed impossible (there may be something about that in the so-called technical reports for the Fortran 2015-or-so standard), but luckily PLplot has none.



I should be able to demonstrate the interface set-up I have in mind in a few days, using x00f as an example.



Regards,



Arjen





From: James Tappin [mailto:jt...@gm...]
Sent: Sunday, May 17, 2015 8:42 PM
To: Alan W. Irwin
Cc: Arjen Markus; PLplot development list
Subject: Re: [Plplot-devel] A possible design of our new Fortran binding

If I understand correctly, then this is pretty much what we do in gtk-fortran where a script is able to parse the gtk+ (along with gdk, glib, cairo and the other dependencies) headers to make a set of Fortran interface definitions.
There are only a couple of significant issues that need to be considered (and one I think does not apply to plplot).
1) The compile times can be long, unless a suitable "only" clause is used.
2) Variadic interfaces are not handled (I don't think there is a way to call a C variadic function from Fortran at all).
James

On 17 May 2015 at 17:59, Alan W. Irwin <ir...@be...<mailto:ir...@be...>> wrote:
On 2015-05-17 07:38-0000 Arjen Markus wrote:

> My new bindings would not have prevented this [argument kind error], as it was an omission, not an incorrect implementation.

Hi Arjen:

This is an important point that I think needs more discussion because
the new Fortran binding for ephcom very much prevents such issues from
happening.

There I completely dropped all C code and C headers that helped define
the old fortran binding (the ephcom equivalent to PLplot's plstubs.h,
sc3d.c, sccont.c, and scstubs.c).  Instead, I used the features of the
iso_c_binding module to write the interface virtually entirely in
Fortran (except for the few cases where iso_c_binding did not have
some argument processing feature that I had to write from scratch in
C).  So if I had omitted something from the Fortran interface.f90
file, there was no leftover C infrastructure that would silently
generate a f77 fallback.  Instead, the omission would be immediately
detected when I attempted to use the missing function.

I am pretty sure it should be possible (since argument transformations
from single to double or double to single is the only extra
requirement) to do the same thing for our new Fortran interface.  To
make that specific, I think our first goal should be to write an
interface.f90 file that contains complete information to handle single
or double precision versions of x00f.f90 with no C code required at
all to define the interface.

If you agree, then once that first goal is achieved (again with
plstubs.h, sc3d.c, sccont.c, and scstubs.c removed), we should be able
to expand the interface (using a C layer where necessary for
processing special kinds of arguments) to handle standard examples
that include use of more complicated PLplot arguments.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca<http://astrowww.phys.uvic.ca>).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net<http://freeeos.sf.net>); the Time
Ephemerides project (timeephem.sf.net<http://timeephem.sf.net>); PLplot scientific plotting
software package (plplot.sf.net<http://plplot.sf.net>); the libLASi project
(unifont.org/lasi<http://unifont.org/lasi>); the Loads of Linux Links project (loll.sf.net<http://loll.sf.net>);
and the Linux Brochure Project (lbproject.sf.net<http://lbproject.sf.net>).
__________________________

Linux-powered Science
__________________________

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Plplot-devel mailing list
Plp...@li...<mailto:Plp...@li...>
https://lists.sourceforge.net/lists/listinfo/plplot-devel

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.