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

[James T. <jt...@gm...>]

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...> 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).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (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...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>