Hello Alan, I'm more than happy to try out the latest release of PLplot, but I am only using a very small subset of the library. I'm using it just for 2D line graphs. I can also build PLplot using the NAG compiler which is one of the most standards conforming compilers available to ensure PLplot is truly portable to different compilers.
Using INT32 does require a 2008 compiler and gfortran 4.5 and above (https://gcc.gnu.org/wiki/GFortran/News#gfortran_4.5), so it makes sense to use the intrinsic function selected_int_kind instead for now until Fortran compilers provide the iso_fortran_env intrinsic module. There is a good guide on the features of Fortran compilers which is reasonably up to date: http://www.fortranplus.co.uk/resources/fortran_2003_2008_compiler_support.pdf It's good that you are dropping the PLINT kind as I personally didn't see a need. I'm sure you are aware, but I would really use the Fortran standard as much as possible to ensure the greatest portability. Best regards, Wadud. -----Original Message----- From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] Sent: 26 April 2016 18:32 To: Wadud Miah <wadud.m...@nag.co.uk>; Arjen Markus <arjen.mar...@deltares.nl> Cc: plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] PLplot Fortran bindings On 2016-04-26 14:47-0000 Wadud Miah wrote: > Hello, > > I tried building the PLplot library with the NAG Fortran compiler and noticed > something unusual in the Fortran code. In plplot_types.f90 the kind constants > are declared as: > > > > integer, parameter :: plint = 4 > > integer, parameter :: plunicode = 4 > > > > These are not portable and neither are part of the standard. To make it > portable and adhere to the Fortran standard, use: > > > > integer, parameter :: plint = selected_int_kind(9) > > integer, parameter :: plunicode = selected_int_kind(9) > > > > Or even better: > > > > use, intrinsic :: iso_fortran_env > > > > integer, parameter :: plint = INT32 > > integer, parameter :: plunicode = INT32 > Hi Wadud: For your information, Arjen and I have finished a major rewrite of our fortran binding, and we are quite pleased with the result which is much more powerful than our old binding and passes all of the tests we have been able to throw at it. However, it isn't quite ready for naive PLplot Fortran users to try until I have finished updating the relevant documentation. But once I am finished with that task, I will be asking those PLplot users who are interested in Fortran to give that new Fortran binding a try to make sure there are no obvious problems with it before we make it part of our forthcoming release. If you want to try out that binding early, then git clone our master branch, and pay attention to the Fortran bits of our (forthcoming) release notes, README.release which documents the changes from our old binding. I just looked at that new binding, and the same kind=4 issue you noted for the old binding occurs for private_plint, private_plunicode, and private_plbool for the new binding as well. Note, however, the semantics are different. These private types are all designed to match the C types reasonably well for internal purposes, but they are not types that are available to users who just need to use the default integer type for arguments equivalent to the C types PLINIT, and PLUNICODE, and the default logical type for arguments equivalent to the C type PLBOOL. Defining private_plint, private_plunicode, and private_plbool to 4 is a leftover from the days when Fortran compilers tended to not be compliant with modern Fortran standards, and the web advice then was to use kind=4 rather than something more complex because of that issue. And it appears that crude approach still works. However, I would be happy to change to something more standards compliant, _IF_ we could be assured it was supported by most/all Fortran compilers. @Arjen: Do you agree we should move to using selected_int_kind(9) in the new binding for private_plint, private_plunicode, and private_plbool in conformity with Wuhad's first idea? According to the gfortran documentation, that function was first introduced with the Fortran 95 standard so surely by now (20 years later!) most Fortran compilers support that function by default (i.e., without requiring any special Fortran compiler options). @Wuhad: Your second idea of using INT32 rather than selected_int_kind(9) is likely a good one for the future, but for now I don't think we should use it since according to <http://fortranwiki.org/fortran/show/iso_fortran_env> INT32 was only introduced in the Fortran 2008 standard, and we would like to stick to Fortran 2003 in our new Fortran binding as much as possible to enhance our chances that the PLplot Fortran binding will work with most Fortran compilers. 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 __________________________ ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. ________________________________________________________________________ ________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Microsoft Office 365. ________________________________ ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel