Merry Christmas everyone. Over the last two weeks I have been focussed on following up on a private topic branch implementation by Arjen of a new Fortran binding for PLplot. This implementation uses the modern Fortran's iso_c_binding module to do virtually all the interfacing with our core C library, and I thought it would be appropriate to let everyone on this list know how this topic is maturing.
Just to give some background, Arjen's new approach is quite powerful, and has the following desireable properties: * It is implemented using much more compact code with virtually none of the interfacing done in C (i.e., the plplotf95c library has shrunk to a tiny fraction of its previous size). * It is much easier to understand and maintain than the previous effort. * Linking issues are simplified. (nm --undefined-only shows that the Fortran examples only need to be linked to libplplotf95 and not libplplotf95c or libplplot) * There is no need anymore for the "c_" prefixes on our C API to avoid nameclashes with the Fortran versions of the routines. For now, I am keeping those prefixes, but once the new Fortran binding is completed and well-tested, I intend to follow up by dropping all the "braindead" "c_" prefixes in our C library. For backwards compatibility (just in case some user has latched onto the "c_" prefixed form of our C API) I will replace, e.g., #define plcol0 c_plcol0 with #define c_plcol0 plcol0 But the second form of these #defines will be the only place that the "c_" prefix will occur in our C code, and the "c_" prefix will also be gone from all our routine names in the C library. I am looking forward to these C simplifications/side benefits due to the Fortran binding reimplementationn, and I assume everyone else here will be looking forward to this side benefit as well. * The Fortran user will no longer be forced to use one particular Fortran real precision that agrees with however PLFLT was configured (which can be double or single precision depending on how the PLplot library build was configured). Instead, they can conveniently use single precision or double precision (even mixed in the same code so long as a given PLplot call has consistent real precision), and our new Fortran binding does the appropriate conversions to PLFLT using modern Fortran's overloading mechanism. My work so far consists of 24 separate commits on top of Arjen's (large) initial effort that he sent me as a tarball, and Arjen plans to start sending additional commits to me as well on this joint private topic. The current status is that as a result of our combined effort, libplplotf95, libplplotf95c, and many of the Fortran examples build, and that same list of examples produce identical results to the corresponding C examples and also perfect (0 errors, no leaks are possible) valgrind results. Here is a sumary of what still needs to be dealt with for the new Fortran binding. f95 Missing examples : 09 14 14a 15 16 18 19 20 21 22 23 28 31 Differing graphical output : Missing stdout : Differing stdout : The missing examples 09 14 14a 15 16 (and 16a which is a variant of 16) are due just to plcont, plshade, and plshades missing from the new Fortran API. Arjen has apparently thought up a good way to deal with the callback function arguments to those functions so he is taking responsibility for their implementation with a good chance that he will finish before January 1st. While he is working on those I hope to add the rest of the missing routines to our Fortran API so that 18 19 20 21 22 23 28 31 all build and produce perfect results by that same date as well. In sum, I anticipate this private topic is going to mature and land on the master branch quite soon (likely within a week) due to our collaborative work on it. Furthermore, after a month or two of further testing on as many Fortran platforms as we can get our hands on, we should all feel confident of making this new Fortran binding part of our next release. 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
