From: Wadud M. <wad...@na...> - 2016-04-26 15:22:21
|
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 Best regards, Wadud. ----------------------------------- Dr. Wadud Miah Computational Scientist Numerical Algorithms Group 01865 518035 ________________________________ 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. ________________________________ |
From: Alan W. I. <ir...@be...> - 2016-04-26 17:31:57
|
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 __________________________ |
From: Wadud M. <wad...@na...> - 2016-04-27 09:26:28
|
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...@be...] Sent: 26 April 2016 18:32 To: Wadud Miah <wad...@na...>; Arjen Markus <arj...@de...> Cc: plp...@li... 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. ________________________________ |
From: Alan W. I. <ir...@be...> - 2016-04-27 21:22:04
|
To Wadud and Arjen: @Arjen: Since you have been unable to answer my quick question in a timely manner concerning adopting selected_int_kind(9) rather than 4 for private_plint, private_plbool, and private_plunicode, I have decided to just go ahead with that change (commit 3442bac). On 2016-04-27 09:11-0000 Wadud Miah wrote: [out of original order] > 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. @Arjen and Wadud: I suspect the kind=4 logic we were using before only worked by a historical accident that that particular kind value corresponded for most Fortran compilers to the 4-byte integers we desired for these private types. So I am much more comfortable with the present selected_int_kind(9) fix for that situation, but that fix does need testing on more than just my (Debian jessie) platform. > 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. @Wadud: Your willingness to test our Fortran binding is much appreciated. Here is the simple cookbook for doing that which internally tests essentially all our Fortran API against the corresponding C API using our standard sets of Fortran and C examples. 1. Select the desired C and Fortran compilers and options for those compilers that you want to test by setting the CC and FC environment variables, e.g., export CC='gcc -O3 -fvisibility=hidden -Wuninitialized' export FC='gfortran -O3 -Wuninitialized -Wunused' 2. Clone the repository, e.g., git clone git://git.code.sf.net/p/plplot/plplot plplot.git where I assume the name you are going to use for the top-level directory of the working tree for the repository is "plplot.git". (Select any name for that directory that you like so long as it doesn't correspond to any current directory that you have.) If you have already cloned the repository, follow the directions in plplot.git/README.developers for updating your local repository to the latest master tip version at SourceForge. 3. Run the comprehensive Fortran test: cd plplot.git scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no 4. Evaluate those results: grep -i error ../comprehensive_test_disposeable/*/*/output_tree/*.out grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable/*/*/output_tree/*.out |less That first grep command should only find ../comprehensive_test_disposeable/nondynamic/noninteractive/output_tree/traditional_clean.out:*_*.txt test.error \ ../comprehensive_test_disposeable/shared/noninteractive/output_tree/traditional_clean.out:*_*.txt test.error \ ../comprehensive_test_disposeable/static/noninteractive/output_tree/traditional_clean.out:*_*.txt test.error \ and the second grep command should find the 12 instances (for various build configurations) of the summary of tests to compare PostScript results from our Fortran examples with corresponding C results. A perfect result for such test summaries is f95 Missing examples : Differing graphical output : Missing stdout : Differing stdout : which indicates in order that there are no missing Fortran examples, the PostScript results for those examples are identical (except for the date stamp) with the corresponding C results, and the stdout exists from the Fortran results and is identical with the corresponding C stdout result. 5. Send a complete summary of your test to me. That summary is collected by the script into the report tarball whose name is ../comprehensive_test_disposeable/comprehensive_test.tar.gz That report tarball gets overwritten each time you run the script (say for different Fortran compiler choices) so remember to rename it to something else to preserve those report results if you are going to run the script more than once. If you look at the commit message <https://sourceforge.net/p/plplot/plplot/ci/3442bac79bf5a5c63a79bcc45cf0de51420dd8a5/> you will see in the Tested by: paragraphs I followed the above directions for invoking the script and got perfect results from that. That script completed for me in only 7 minutes so running that script with the same arguments should take a similar amount of time for your case. I then summarized my testing results at <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Fortran%20Testing%20Reports>. @Arjen: Could you follow up with similar test results for the latest git master tip for both your Cygwin and MinGW-w64/MSYS2 platforms? That wiki table documents your previous (good) Cygwin Fortran result. Previously you also sent me your good MinGW-w64/MSYS2 platform results for Fortran, but I was holding off on posting that result to our wiki because that report also revealed a MinGW-w64/MSYS2 installation update issue that requires you to reinstall the MinGW-w64/MSYS2 platform to get access to the much more convenient/reliable updating available for the latest version of that platform. @Wadud: I would be very happy to post your comprehensive Fortran testing results in the same place in our Wiki once you sent the report tarball(s) to me that are generated by setting the CC and FC environment variables and running the above script with exactly those 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 __________________________ |
From: Arjen M. <Arj...@de...> - 2016-04-28 06:35:13
|
Hi Alan, Wadud, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Wednesday, April 27, 2016 11:22 PM > To: Wadud Miah > Cc: Arjen Markus; plp...@li... > Subject: RE: [Plplot-devel] PLplot Fortran bindings > > To Wadud and Arjen: > > @Arjen: > Since you have been unable to answer my quick question in a timely manner > concerning adopting selected_int_kind(9) rather than 4 for private_plint, > private_plbool, and private_plunicode, I have decided to just go ahead with that > change (commit 3442bac). > Yesterday was a national holiday here, so I paid little attention to my inbox :). However, considering the portability of these two types, why don't we use C_INT32_T from ISO_C_BINDING? This maps to C's int32_t type (for the companion C compiler to be precise). Essentially the same thing, except if the platform does not have 32 bits integers, I'd say, but it conveys the one-to-one relation between the Fortran and C side. This does not rely on the Fortran 2008 standard, only on the Fortran 2003 standard and we require that for the new binding anyway. > > @Arjen and Wadud: I suspect the kind=4 logic we were using before only worked > by a historical accident that that particular kind value corresponded for most Fortran > compilers to the 4-byte integers we desired for these private types. So I am much > more comfortable with the present selected_int_kind(9) fix for that situation, but that > fix does need testing on more than just my (Debian jessie) platform. > Quite possibly, something like unit 5 in Fortran being attached to the keyboard and unit 6 to the console. Nothing that is 100% guaranteerd, but so likely that you begin to think it is guaranteed. > > @Arjen: Could you follow up with similar test results for the latest git master tip for > both your Cygwin and MinGW-w64/MSYS2 platforms? > That wiki table documents your previous (good) Cygwin Fortran result. > Previously you also sent me your good MinGW-w64/MSYS2 platform results for > Fortran, but I was holding off on posting that result to our wiki because that report > also revealed a MinGW-w64/MSYS2 installation update issue that requires you to > reinstall the MinGW-w64/MSYS2 platform to get access to the much more > convenient/reliable updating available for the latest version of that platform. > Will do. I should have time today to do that. That testing should cover the other issue (the temporary files) as well. Regards, Arjen 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. |
From: Alan W. I. <ir...@be...> - 2016-04-28 07:32:25
|
On 2016-04-28 06:35-0000 Arjen Markus wrote: > Hi Alan, Wadud, > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@be...] >> Sent: Wednesday, April 27, 2016 11:22 PM >> To: Wadud Miah >> Cc: Arjen Markus; plp...@li... >> Subject: RE: [Plplot-devel] PLplot Fortran bindings >> >> To Wadud and Arjen: >> >> @Arjen: >> Since you have been unable to answer my quick question in a timely manner >> concerning adopting selected_int_kind(9) rather than 4 for private_plint, >> private_plbool, and private_plunicode, I have decided to just go ahead with that >> change (commit 3442bac). >> > Yesterday was a national holiday here, so I paid little attention to my inbox :). However, considering the portability of these two types, why don't we use C_INT32_T from ISO_C_BINDING? This maps to C's int32_t type (for the companion C compiler to be precise). Essentially the same thing, except if the platform does not have 32 bits integers, I'd say, but it conveys the one-to-one relation between the Fortran and C side. > This does not rely on the Fortran 2008 standard, only on the Fortran 2003 standard and we require that for the new binding anyway. That argument sounds reasonable to me, but you are the expert here. So please implement this further change yourself. >> @Arjen: Could you follow up with similar test results for the latest git master tip for >> both your Cygwin and MinGW-w64/MSYS2 platforms? >> That wiki table documents your previous (good) Cygwin Fortran result. >> Previously you also sent me your good MinGW-w64/MSYS2 platform results for >> Fortran, but I was holding off on posting that result to our wiki because that report >> also revealed a MinGW-w64/MSYS2 installation update issue that requires you to >> reinstall the MinGW-w64/MSYS2 platform to get access to the much more >> convenient/reliable updating available for the latest version of that platform. >> > Will do. I should have time today to do that. That testing should cover the other issue (the temporary files) as well. I look forward to those comprehensive test results on both platforms. You can constrain those tests to just test the Fortran, C, and the ps device driver components of PLplot (with the script arguments I have indicated) for speed because even that limited result should thoroughly test creating temporary files. I recommend you make that further change you outlined above before these constrained comprehensive tests so you can summarize these tests in the Tested by: paragraph in the commit message. Once I see that commit from you, I plan to follow up by redoing my own constrained Fortran comprehensive test (since it only takes 7 minutes). 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 __________________________ |
From: Arjen M. <Arj...@de...> - 2016-04-28 08:55:17
|
Hi Alan, I made the small change I suggested and the results for Cygwin and MinGW64 look fine - see the attached files. The only platform I still need to test on is bare Windows (not as nicely packaged as the other two, unfortunately). When that turns out to be fine as well, I will do the commit. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Thursday, April 28, 2016 9:32 AM > To: Arjen Markus > Cc: Wadud Miah; plp...@li... > Subject: RE: [Plplot-devel] PLplot Fortran bindings > > On 2016-04-28 06:35-0000 Arjen Markus wrote: > > > Hi Alan, Wadud, > > > >> -----Original Message----- > >> From: Alan W. Irwin [mailto:ir...@be...] > >> Sent: Wednesday, April 27, 2016 11:22 PM > >> To: Wadud Miah > >> Cc: Arjen Markus; plp...@li... > >> Subject: RE: [Plplot-devel] PLplot Fortran bindings > >> > >> To Wadud and Arjen: > >> > >> @Arjen: > >> Since you have been unable to answer my quick question in a timely > >> manner concerning adopting selected_int_kind(9) rather than 4 for > >> private_plint, private_plbool, and private_plunicode, I have decided > >> to just go ahead with that change (commit 3442bac). > >> > > > Yesterday was a national holiday here, so I paid little attention to > my inbox :). However, considering the portability of these two types, why don't we > use C_INT32_T from ISO_C_BINDING? This maps to C's int32_t type (for the > companion C compiler to be precise). Essentially the same thing, except if the > platform does not have 32 bits integers, I'd say, but it conveys the one-to-one > relation between the Fortran and C side. > > > This does not rely on the Fortran 2008 standard, only on the Fortran > 2003 standard and we require that for the new binding anyway. > > That argument sounds reasonable to me, but you are the expert here. So please > implement this further change yourself. > > >> @Arjen: Could you follow up with similar test results for the latest > >> git master tip for both your Cygwin and MinGW-w64/MSYS2 platforms? > >> That wiki table documents your previous (good) Cygwin Fortran result. > >> Previously you also sent me your good MinGW-w64/MSYS2 platform > >> results for Fortran, but I was holding off on posting that result to > >> our wiki because that report also revealed a MinGW-w64/MSYS2 > >> installation update issue that requires you to reinstall the > >> MinGW-w64/MSYS2 platform to get access to the much more > convenient/reliable updating available for the latest version of that platform. > >> > > Will do. I should have time today to do that. That testing should cover the other > issue (the temporary files) as well. > > I look forward to those comprehensive test results on both platforms. > You can constrain those tests to just test the Fortran, C, and the ps device driver > components of PLplot (with the script arguments I have indicated) for speed > because even that limited result should thoroughly test creating temporary files. > > I recommend you make that further change you outlined above before these > constrained comprehensive tests so you can summarize these tests in the Tested > by: paragraph in the commit message. Once I see that commit from you, I plan to > follow up by redoing my own constrained Fortran comprehensive test (since it only > takes 7 minutes). > > 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 > __________________________ 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. |
From: Wadud M. <wad...@na...> - 2016-04-28 10:16:48
|
Hi Arjen/Alan, I will build PLplot for Git late next week as I will busy the next few days. Let me know once you have made all the relevant changes for me to test with the NAG Fortran compiler. I am actually running a workshop in the UK called "Fortran Modernisation Workshop" which covers PLplot: http://www.nag.co.uk/market/training/fortran-modernisation-workshop I've found PLplot the best visualisation libraries for Fortran 90 which I would like to thank you for :-) Best regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: Thursday, April 28, 2016 9:55 AM To: Alan W. Irwin <ir...@be...> Cc: Wadud Miah <wad...@na...>; plp...@li... Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Alan, I made the small change I suggested and the results for Cygwin and MinGW64 look fine - see the attached files. The only platform I still need to test on is bare Windows (not as nicely packaged as the other two, unfortunately). When that turns out to be fine as well, I will do the commit. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Thursday, April 28, 2016 9:32 AM > To: Arjen Markus > Cc: Wadud Miah; plp...@li... > Subject: RE: [Plplot-devel] PLplot Fortran bindings > > On 2016-04-28 06:35-0000 Arjen Markus wrote: > > > Hi Alan, Wadud, > > > >> -----Original Message----- > >> From: Alan W. Irwin [mailto:ir...@be...] > >> Sent: Wednesday, April 27, 2016 11:22 PM > >> To: Wadud Miah > >> Cc: Arjen Markus; plp...@li... > >> Subject: RE: [Plplot-devel] PLplot Fortran bindings > >> > >> To Wadud and Arjen: > >> > >> @Arjen: > >> Since you have been unable to answer my quick question in a timely > >> manner concerning adopting selected_int_kind(9) rather than 4 for > >> private_plint, private_plbool, and private_plunicode, I have decided > >> to just go ahead with that change (commit 3442bac). > >> > > > Yesterday was a national holiday here, so I paid little attention to > my inbox :). However, considering the portability of these two types, why don't we > use C_INT32_T from ISO_C_BINDING? This maps to C's int32_t type (for the > companion C compiler to be precise). Essentially the same thing, except if the > platform does not have 32 bits integers, I'd say, but it conveys the one-to-one > relation between the Fortran and C side. > > > This does not rely on the Fortran 2008 standard, only on the Fortran > 2003 standard and we require that for the new binding anyway. > > That argument sounds reasonable to me, but you are the expert here. So please > implement this further change yourself. > > >> @Arjen: Could you follow up with similar test results for the latest > >> git master tip for both your Cygwin and MinGW-w64/MSYS2 platforms? > >> That wiki table documents your previous (good) Cygwin Fortran result. > >> Previously you also sent me your good MinGW-w64/MSYS2 platform > >> results for Fortran, but I was holding off on posting that result to > >> our wiki because that report also revealed a MinGW-w64/MSYS2 > >> installation update issue that requires you to reinstall the > >> MinGW-w64/MSYS2 platform to get access to the much more > convenient/reliable updating available for the latest version of that platform. > >> > > Will do. I should have time today to do that. That testing should cover the other > issue (the temporary files) as well. > > I look forward to those comprehensive test results on both platforms. > You can constrain those tests to just test the Fortran, C, and the ps device driver > components of PLplot (with the script arguments I have indicated) for speed > because even that limited result should thoroughly test creating temporary files. > > I recommend you make that further change you outlined above before these > constrained comprehensive tests so you can summarize these tests in the Tested > by: paragraph in the commit message. Once I see that commit from you, I plan to > follow up by redoing my own constrained Fortran comprehensive test (since it only > takes 7 minutes). > > 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 > __________________________ 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. ________________________________________________________________________ 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. ________________________________ |
From: Arjen M. <Arj...@de...> - 2016-04-28 10:19:48
|
Hi Wadud, The changes should be there now - I introduced ISO_C_BINDING's C_INT32_T kind to solve the portability issue. On the platforms I have available that works fine. See https://sourceforge.net/p/plplot/plplot/ci/f00ee2a0fb0293e118a359d6e6312b30804b3420/ Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Thursday, April 28, 2016 12:17 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li... Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen/Alan, I will build PLplot for Git late next week as I will busy the next few days. Let me know once you have made all the relevant changes for me to test with the NAG Fortran compiler. I am actually running a workshop in the UK called "Fortran Modernisation Workshop" which covers PLplot: http://www.nag.co.uk/market/training/fortran-modernisation-workshop I've found PLplot the best visualisation libraries for Fortran 90 which I would like to thank you for :-) Best regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: Thursday, April 28, 2016 9:55 AM To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Alan, I made the small change I suggested and the results for Cygwin and MinGW64 look fine - see the attached files. The only platform I still need to test on is bare Windows (not as nicely packaged as the other two, unfortunately). When that turns out to be fine as well, I will do the commit. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Thursday, April 28, 2016 9:32 AM > To: Arjen Markus > Cc: Wadud Miah; plp...@li...<mailto:plp...@li...> > Subject: RE: [Plplot-devel] PLplot Fortran bindings > > On 2016-04-28 06:35-0000 Arjen Markus wrote: > > > Hi Alan, Wadud, > > > >> -----Original Message----- > >> From: Alan W. Irwin [mailto:ir...@be...] > >> Sent: Wednesday, April 27, 2016 11:22 PM > >> To: Wadud Miah > >> Cc: Arjen Markus; plp...@li...<mailto:plp...@li...> > >> Subject: RE: [Plplot-devel] PLplot Fortran bindings > >> > >> To Wadud and Arjen: > >> > >> @Arjen: > >> Since you have been unable to answer my quick question in a timely > >> manner concerning adopting selected_int_kind(9) rather than 4 for > >> private_plint, private_plbool, and private_plunicode, I have decided > >> to just go ahead with that change (commit 3442bac). > >> > > > Yesterday was a national holiday here, so I paid little attention to > my inbox :). However, considering the portability of these two types, why don't we > use C_INT32_T from ISO_C_BINDING? This maps to C's int32_t type (for the > companion C compiler to be precise). Essentially the same thing, except if the > platform does not have 32 bits integers, I'd say, but it conveys the one-to-one > relation between the Fortran and C side. > > > This does not rely on the Fortran 2008 standard, only on the Fortran > 2003 standard and we require that for the new binding anyway. > > That argument sounds reasonable to me, but you are the expert here. So please > implement this further change yourself. > > >> @Arjen: Could you follow up with similar test results for the latest > >> git master tip for both your Cygwin and MinGW-w64/MSYS2 platforms? > >> That wiki table documents your previous (good) Cygwin Fortran result. > >> Previously you also sent me your good MinGW-w64/MSYS2 platform > >> results for Fortran, but I was holding off on posting that result to > >> our wiki because that report also revealed a MinGW-w64/MSYS2 > >> installation update issue that requires you to reinstall the > >> MinGW-w64/MSYS2 platform to get access to the much more > convenient/reliable updating available for the latest version of that platform. > >> > > Will do. I should have time today to do that. That testing should cover the other > issue (the temporary files) as well. > > I look forward to those comprehensive test results on both platforms. > You can constrain those tests to just test the Fortran, C, and the ps device driver > components of PLplot (with the script arguments I have indicated) for speed > because even that limited result should thoroughly test creating temporary files. > > I recommend you make that further change you outlined above before these > constrained comprehensive tests so you can summarize these tests in the Tested > by: paragraph in the commit message. Once I see that commit from you, I plan to > follow up by redoing my own constrained Fortran comprehensive test (since it only > takes 7 minutes). > > 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 > __________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. |
From: Alan W. I. <ir...@be...> - 2016-04-28 19:04:42
|
On 2016-04-28 10:19-0000 Arjen Markus wrote: > Hi Wadud, > The changes should be there now - I introduced ISO_C_BINDING's C_INT32_T kind to solve the portability issue. On the platforms I have available that works fine. See https://sourceforge.net/p/plplot/plplot/ci/f00ee2a0fb0293e118a359d6e6312b30804b3420/ Hi Arjen and Wadud: @ Arjen: I followed up (commit 4ec18f8) by doing a similar change for our private Fortran types (using c_float and c_double rather than kind(1.0) and kind(1.0d0)). My Fortran-constrained comprehensive test on Debian jessie of that change and Arjen's previous change gave perfect results. As far as I know commit 4ec18f8 is our last Fortran change (other than documentation) for our forthcoming release. Now that you are all set up to do constrained Fortran tests on your three Windows platforms, you will likely want to follow up by repeating those tests for commit 4ec18f8. But before running those tests, please give me an hour or so to look at the report tarballs you sent me recently for both the Cygwin and MinGW-w64/MSYS2 platforms in case I spot some issue with the contents of those report tarballs. > From: Wadud Miah [mailto:wad...@na...] > Sent: Thursday, April 28, 2016 12:17 PM > To: Arjen Markus; Alan W. Irwin > Cc: plp...@li... > Subject: RE: [Plplot-devel] PLplot Fortran bindings > > Hi Arjen/Alan, > [...] > I've found PLplot the best visualisation libraries for Fortran 90 which I would like to thank you for :-) @Wadud: On behalf of Arjen (who is the principal developer of both the old and new Fortran bindings) and myself, thanks for those kind words about our old Fortran binding. I think you will like our new Fortran binding even better, but if you find some issue with it, please let us know, and we will attempt to fix it. 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 __________________________ |
From: Wadud M. <wad...@na...> - 2016-05-09 13:19:42
|
Hi Arjen, Apologies for this question as I am not very familiar with Git, but what is the Git command I use to clone PLplot which has the corrections? Is it just: git clone git://git.code.sf.net/p/plplot/plplot plplot-plplot Regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 28 April 2016 11:20 To: Wadud Miah <wad...@na...>; Alan W. Irwin <ir...@be...> Cc: plp...@li... Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Wadud, The changes should be there now - I introduced ISO_C_BINDING's C_INT32_T kind to solve the portability issue. On the platforms I have available that works fine. See https://sourceforge.net/p/plplot/plplot/ci/f00ee2a0fb0293e118a359d6e6312b30804b3420/ Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Thursday, April 28, 2016 12:17 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen/Alan, I will build PLplot for Git late next week as I will busy the next few days. Let me know once you have made all the relevant changes for me to test with the NAG Fortran compiler. I am actually running a workshop in the UK called "Fortran Modernisation Workshop" which covers PLplot: http://www.nag.co.uk/market/training/fortran-modernisation-workshop I've found PLplot the best visualisation libraries for Fortran 90 which I would like to thank you for :-) Best regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: Thursday, April 28, 2016 9:55 AM To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Alan, I made the small change I suggested and the results for Cygwin and MinGW64 look fine - see the attached files. The only platform I still need to test on is bare Windows (not as nicely packaged as the other two, unfortunately). When that turns out to be fine as well, I will do the commit. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Thursday, April 28, 2016 9:32 AM > To: Arjen Markus > Cc: Wadud Miah; plp...@li...<mailto:plp...@li...> > Subject: RE: [Plplot-devel] PLplot Fortran bindings > > On 2016-04-28 06:35-0000 Arjen Markus wrote: > > > Hi Alan, Wadud, > > > >> -----Original Message----- > >> From: Alan W. Irwin [mailto:ir...@be...] > >> Sent: Wednesday, April 27, 2016 11:22 PM > >> To: Wadud Miah > >> Cc: Arjen Markus; plp...@li...<mailto:plp...@li...> > >> Subject: RE: [Plplot-devel] PLplot Fortran bindings > >> > >> To Wadud and Arjen: > >> > >> @Arjen: > >> Since you have been unable to answer my quick question in a timely > >> manner concerning adopting selected_int_kind(9) rather than 4 for > >> private_plint, private_plbool, and private_plunicode, I have decided > >> to just go ahead with that change (commit 3442bac). > >> > > > Yesterday was a national holiday here, so I paid little attention to > my inbox :). However, considering the portability of these two types, why don't we > use C_INT32_T from ISO_C_BINDING? This maps to C's int32_t type (for the > companion C compiler to be precise). Essentially the same thing, except if the > platform does not have 32 bits integers, I'd say, but it conveys the one-to-one > relation between the Fortran and C side. > > > This does not rely on the Fortran 2008 standard, only on the Fortran > 2003 standard and we require that for the new binding anyway. > > That argument sounds reasonable to me, but you are the expert here. So please > implement this further change yourself. > > >> @Arjen: Could you follow up with similar test results for the latest > >> git master tip for both your Cygwin and MinGW-w64/MSYS2 platforms? > >> That wiki table documents your previous (good) Cygwin Fortran result. > >> Previously you also sent me your good MinGW-w64/MSYS2 platform > >> results for Fortran, but I was holding off on posting that result to > >> our wiki because that report also revealed a MinGW-w64/MSYS2 > >> installation update issue that requires you to reinstall the > >> MinGW-w64/MSYS2 platform to get access to the much more > convenient/reliable updating available for the latest version of that platform. > >> > > Will do. I should have time today to do that. That testing should cover the other > issue (the temporary files) as well. > > I look forward to those comprehensive test results on both platforms. > You can constrain those tests to just test the Fortran, C, and the ps device driver > components of PLplot (with the script arguments I have indicated) for speed > because even that limited result should thoroughly test creating temporary files. > > I recommend you make that further change you outlined above before these > constrained comprehensive tests so you can summarize these tests in the Tested > by: paragraph in the commit message. Once I see that commit from you, I plan to > follow up by redoing my own constrained Fortran comprehensive test (since it only > takes 7 minutes). > > 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 > __________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. ________________________________________________________________________ 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. ________________________________ |
From: Alan W. I. <ir...@be...> - 2016-04-28 21:32:53
|
Hi Arjen: On 2016-04-28 08:55-0000 Arjen Markus wrote: > I made the small change I suggested and the results for Cygwin and MinGW64 look fine - see the attached files. Thanks for those two test report tarballs. Here is my analysis of those results. 1. Cygwin After unpacking your report tarball, I didn't spot anything unusual in your comprehensive test script arguments except for --build_command "make -j4" --ctest_command "ctest -j4" I believe you have sometimes found those parallel options to be problematic for Cygwin in the past so I would drop them from now on (even though they caused no issues for you for this particular comprehensive test). Furthermore, comprehensive_test.sh.out showed no errors; grep -i error */*/output_tree/*.out and grep -B1 -A3 "Missing examples" */*/output_tree/*.out |less gave perfect results; and there were no significant warnings in shared/noninteractive/output_tree/make_noninteractive.out or shared/noninteractive/output_tree/cmake.out. However, a final check grep local shared/noninteractive/output_tree/cmake.out yielded -- FindShapelib: Found shapelib header directory, /usr/local/include, and library, /usr/lib/libshp.a. indicating a potentially serious inconsistency between the Cygwin location of /usr/lib/libshp.a and the headers of some local non-Cygwin version of shapelib. That inconsistency obviously caused no trouble for your current tests, but it is an "accident waiting to happen" which might occur any time you upgrade the Cygwin version of shapelib. A Cygwin package search reveals there is no Cygwin package (at least for up-to-date Cygwin) that includes libshp.a. So I wonder if /usr/lib/libshp.a above is from some older version of Cygwin? Also, the relevant header file being searched for is called shapefil.h, and that (and /usr/lib/libshp.dll.a which is the relevant Cygwin shapefile library that you should have found above) should be installed as part of the libshp-devel-1.3.0-1 package. Anyhow, I suspect this issue will go away once you install the libshp-devel-1.3.0-1 Cygwin package (which should automatically get rid of the above /usr/lib/libshp.a if that is from some previous version of Cygwin). This may or may not be relevant to the above issue, but I notice in comprehensive_env.out that your PATH variable includes /usr/local/bin which significantly affects CMake find capabilities, i.e., in general, if a PATH component is PREFIX/bin, CMake will search other standard locations, (e.g., PREFIX/include) associated with that PREFIX for include files (and similarly for libraries). Anyhow, you only want to depend on pure Cygwin software for these tests, so I suggest you remove /usr/local/bin from your PATH for all subsequent Cygwin tests. In sum, your Fortran test report is encouraging for this platform, but I will wait for your next Cygwin test (of my latest Fortran commit) with the parallel make and ctest options dropped, and this shapelib and /usr/local/bin issue fixed before posting your Cygwin Fortran-constrained comprehensive test reports to our Wiki. 2. MinGW-w64/MSYS2 After unpacking your report tarball, I didn't spot anything unusual in your comprehensive test script arguments. For example, there is no parallel build or ctest option which is correct for this platform (and also Cygwin, see above comment). Furthermore, comprehensive_test.sh.out showed no errors; and grep -i error */*/output_tree/*.out and grep -B1 -A3 "Missing examples" */*/output_tree/*.out |less gave perfect results. However, shared/noninteractive/output_tree/cmake.out showed that libqhull was missing which adds some important core capabilities to PLplot. If you look at the (dated) package list at <https://sourceforge.net/p/msys2/wiki/Packages/> MinGW-w64/MSYS2 does include a qhull-related package. So you should install the latest version of that package to address this issue. Also, I highly recommend (if you haven't done so already) you reinstall MinGW-w64/MSYS2 from scratch following the procedure given in <https://sourceforge.net/p/msys2/wiki/MSYS2 installation/> to get access to the latest much-simplified update procedure before installing PLplot dependencies including the qhull-related package. Furthermore, grep local shared/noninteractive/output_tree/cmake.out found no "local" issue, and no significant warnings appeared in shared/noninteractive/output_tree/make_noninteractive.out other than the expected warnings about libqhull-related functionality being missing. In sum, your Fortran test report is encouraging on this platform, but I will wait for your next MinGW-w64/MSYS2 test (of my latest Fortran commit) with reinstalled MinGW-w64/MSYS2 (if you haven't done that already) and the qhull-related package installed, before posting your MinGW-w64/MSYS2 Fortran-constrained comprehensive test reports to our Wiki. 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 __________________________ |
From: Arjen M. <Arj...@de...> - 2016-04-29 06:40:08
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Thursday, April 28, 2016 11:33 PM > To: Arjen Markus; PLplot development list > Subject: RE: [Plplot-devel] PLplot Fortran bindings > > Hi Arjen: > > On 2016-04-28 08:55-0000 Arjen Markus wrote: > > > I made the small change I suggested and the results for Cygwin and > MinGW64 look fine - see the attached files. > > Thanks for those two test report tarballs. Here is my analysis of those results. > > 1. Cygwin > > After unpacking your report tarball, I didn't spot anything unusual in your > comprehensive test script arguments except for > > --build_command "make -j4" > --ctest_command "ctest -j4" > > I believe you have sometimes found those parallel options to be problematic for > Cygwin in the past so I would drop them from now on (even though they caused no > issues for you for this particular comprehensive test). I guess this is because there was not all that much to be built: just the C library and the Fortran binding plus examples. I have had serious problems with parallel builds indeed. So my script to run the full test suite does set the build command to "make". Perhaps I should do that for the limited test script as well. > > Furthermore, > comprehensive_test.sh.out showed no errors; > > grep -i error */*/output_tree/*.out > > and > > grep -B1 -A3 "Missing examples" */*/output_tree/*.out |less > > gave perfect results; and there were no significant warnings in > shared/noninteractive/output_tree/make_noninteractive.out or > shared/noninteractive/output_tree/cmake.out. > > However, a final check > > grep local shared/noninteractive/output_tree/cmake.out > > yielded > > -- FindShapelib: Found shapelib header directory, /usr/local/include, and library, > /usr/lib/libshp.a. > > indicating a potentially serious inconsistency between the Cygwin location of > /usr/lib/libshp.a and the headers of some local non-Cygwin version of shapelib. > That inconsistency obviously caused no trouble for your current tests, but it is an > "accident waiting to happen" > which might occur any time you upgrade the Cygwin version of shapelib. > > A Cygwin package search reveals there is no Cygwin package (at least for up-to- > date Cygwin) that includes libshp.a. So I wonder if /usr/lib/libshp.a above is from > some older version of Cygwin? > No, I think it is the X shape extension, which allows for non-rectangular window shapes. Apparently CMake gets confused, but the build is done without issues. > Also, the relevant header file being searched for is called shapefil.h, and that (and > /usr/lib/libshp.dll.a which is the relevant Cygwin shapefile library that you should > have found above) should be installed as part of the libshp-devel-1.3.0-1 package. > > Anyhow, I suspect this issue will go away once you install the > libshp-devel-1.3.0-1 Cygwin package (which should automatically get rid of the > above /usr/lib/libshp.a if that is from some previous version of Cygwin). > > This may or may not be relevant to the above issue, but I notice in > comprehensive_env.out that your PATH variable includes /usr/local/bin which > significantly affects CMake find capabilities, i.e., in general, if a PATH component is > PREFIX/bin, CMake will search other standard locations, (e.g., PREFIX/include) > associated with that PREFIX for include files (and similarly for libraries). Anyhow, > you only want to depend on pure Cygwin software for these tests, so I suggest you > remove /usr/local/bin from your PATH for all subsequent Cygwin tests. > Right, this is part of the Cygwin shell. I will have to remove that segment from the PATH variable or else rename that directory. > In sum, your Fortran test report is encouraging for this platform, but I will wait for > your next Cygwin test (of my latest Fortran commit) with the parallel make and ctest > options dropped, and this shapelib and /usr/local/bin issue fixed before posting your > Cygwin Fortran-constrained comprehensive test reports to our Wiki. > Good :) > 2. MinGW-w64/MSYS2 > > After unpacking your report tarball, I didn't spot anything unusual in your > comprehensive test script arguments. For example, there is no parallel build or > ctest option which is correct for this platform (and also Cygwin, see above > comment). > > Furthermore, > comprehensive_test.sh.out showed no errors; and > > grep -i error */*/output_tree/*.out > > and > > grep -B1 -A3 "Missing examples" */*/output_tree/*.out |less > > gave perfect results. > > However, shared/noninteractive/output_tree/cmake.out showed that libqhull was > missing which adds some important core capabilities to PLplot. If you look at the > (dated) package list at <https://sourceforge.net/p/msys2/wiki/Packages/> MinGW- > w64/MSYS2 does include a qhull-related package. So you should install the latest > version of that package to address this issue. Also, I highly recommend (if you > haven't done so already) you reinstall > MinGW-w64/MSYS2 from scratch following the procedure given in > <https://sourceforge.net/p/msys2/wiki/MSYS2 installation/<https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/>> to get access to the > latest much-simplified update procedure before installing PLplot dependencies > including the qhull-related package. > That will take me some time to do - I will try and find time for that over the weekend. > Furthermore, > > grep local shared/noninteractive/output_tree/cmake.out > > found no "local" issue, and no significant warnings appeared in > shared/noninteractive/output_tree/make_noninteractive.out other than the expected > warnings about libqhull-related functionality being missing. > > In sum, your Fortran test report is encouraging on this platform, but I will wait for > your next MinGW-w64/MSYS2 test (of my latest Fortran > commit) with reinstalled MinGW-w64/MSYS2 (if you haven't done that > already) and the qhull-related package installed, before posting your > MinGW-w64/MSYS2 Fortran-constrained comprehensive test reports to our Wiki. > So, to be continued. Regards, Arjen 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. |
From: Arjen M. <Arj...@de...> - 2016-05-09 13:14:54
|
Hi Wadud, That is right. The last argument, plplot-plplot, is actually the name of the directory that will contain the source code and auxiliary data files. You will get an up-to-date repository that way. Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Monday, May 09, 2016 3:05 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li... Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen, Apologies for this question as I am not very familiar with Git, but what is the Git command I use to clone PLplot which has the corrections? Is it just: git clone git://git.code.sf.net/p/plplot/plplot plplot-plplot Regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 28 April 2016 11:20 To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Wadud, The changes should be there now - I introduced ISO_C_BINDING's C_INT32_T kind to solve the portability issue. On the platforms I have available that works fine. See https://sourceforge.net/p/plplot/plplot/ci/f00ee2a0fb0293e118a359d6e6312b30804b3420/ Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Thursday, April 28, 2016 12:17 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen/Alan, I will build PLplot for Git late next week as I will busy the next few days. Let me know once you have made all the relevant changes for me to test with the NAG Fortran compiler. I am actually running a workshop in the UK called "Fortran Modernisation Workshop" which covers PLplot: http://www.nag.co.uk/market/training/fortran-modernisation-workshop I've found PLplot the best visualisation libraries for Fortran 90 which I would like to thank you for :-) Best regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: Thursday, April 28, 2016 9:55 AM To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Alan, I made the small change I suggested and the results for Cygwin and MinGW64 look fine - see the attached files. The only platform I still need to test on is bare Windows (not as nicely packaged as the other two, unfortunately). When that turns out to be fine as well, I will do the commit. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Thursday, April 28, 2016 9:32 AM > To: Arjen Markus > Cc: Wadud Miah; plp...@li...<mailto:plp...@li...> > Subject: RE: [Plplot-devel] PLplot Fortran bindings > > On 2016-04-28 06:35-0000 Arjen Markus wrote: > > > Hi Alan, Wadud, > > > >> -----Original Message----- > >> From: Alan W. Irwin [mailto:ir...@be...] > >> Sent: Wednesday, April 27, 2016 11:22 PM > >> To: Wadud Miah > >> Cc: Arjen Markus; plp...@li...<mailto:plp...@li...> > >> Subject: RE: [Plplot-devel] PLplot Fortran bindings > >> > >> To Wadud and Arjen: > >> > >> @Arjen: > >> Since you have been unable to answer my quick question in a timely > >> manner concerning adopting selected_int_kind(9) rather than 4 for > >> private_plint, private_plbool, and private_plunicode, I have decided > >> to just go ahead with that change (commit 3442bac). > >> > > > Yesterday was a national holiday here, so I paid little attention to > my inbox :). However, considering the portability of these two types, why don't we > use C_INT32_T from ISO_C_BINDING? This maps to C's int32_t type (for the > companion C compiler to be precise). Essentially the same thing, except if the > platform does not have 32 bits integers, I'd say, but it conveys the one-to-one > relation between the Fortran and C side. > > > This does not rely on the Fortran 2008 standard, only on the Fortran > 2003 standard and we require that for the new binding anyway. > > That argument sounds reasonable to me, but you are the expert here. So please > implement this further change yourself. > > >> @Arjen: Could you follow up with similar test results for the latest > >> git master tip for both your Cygwin and MinGW-w64/MSYS2 platforms? > >> That wiki table documents your previous (good) Cygwin Fortran result. > >> Previously you also sent me your good MinGW-w64/MSYS2 platform > >> results for Fortran, but I was holding off on posting that result to > >> our wiki because that report also revealed a MinGW-w64/MSYS2 > >> installation update issue that requires you to reinstall the > >> MinGW-w64/MSYS2 platform to get access to the much more > convenient/reliable updating available for the latest version of that platform. > >> > > Will do. I should have time today to do that. That testing should cover the other > issue (the temporary files) as well. > > I look forward to those comprehensive test results on both platforms. > You can constrain those tests to just test the Fortran, C, and the ps device driver > components of PLplot (with the script arguments I have indicated) for speed > because even that limited result should thoroughly test creating temporary files. > > I recommend you make that further change you outlined above before these > constrained comprehensive tests so you can summarize these tests in the Tested > by: paragraph in the commit message. Once I see that commit from you, I plan to > follow up by redoing my own constrained Fortran comprehensive test (since it only > takes 7 minutes). > > 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 > __________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. |
From: Wadud M. <wad...@na...> - 2016-05-09 15:09:45
|
Hi Arjen, The NAG Fortran compiler has picked up a compilation error which I am struggling to understand: Error: /home/wadud/builds/plplot-plplot/bindings/f95/included_plplot_real_interfaces.f90, line 1112: Cannot IMPORT PLCGRID because it does not exist in the host INTERFACE_PLFCONT detected at ,@PLCGRID Going to the offending line in the code shown in boldface: subroutine transform( x, y, tx, ty, data ) bind(c) import :: private_plflt, PLcGrid implicit none real(kind=private_plflt), value, intent(in) :: x, y real(kind=private_plflt), intent(out) :: tx, ty type(PLcGrid), intent(in) :: data end subroutine transform It is not complaining about importing private_plflt but is complaining about importing PLcGrid and I do not understand how the compiler should know it should get this type definition from plplot_small_modules.f90 even though this works with other compilers, e.g. gfortran. I don't really know if this is significant, but at least I would like to make sense of it. Best regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 09 May 2016 14:15 To: Wadud Miah <wad...@na...>; Alan W. Irwin <ir...@be...> Cc: plp...@li... Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Wadud, That is right. The last argument, plplot-plplot, is actually the name of the directory that will contain the source code and auxiliary data files. You will get an up-to-date repository that way. Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Monday, May 09, 2016 3:05 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen, Apologies for this question as I am not very familiar with Git, but what is the Git command I use to clone PLplot which has the corrections? Is it just: git clone git://git.code.sf.net/p/plplot/plplot plplot-plplot Regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 28 April 2016 11:20 To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Wadud, The changes should be there now - I introduced ISO_C_BINDING's C_INT32_T kind to solve the portability issue. On the platforms I have available that works fine. See https://sourceforge.net/p/plplot/plplot/ci/f00ee2a0fb0293e118a359d6e6312b30804b3420/ Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Thursday, April 28, 2016 12:17 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen/Alan, I will build PLplot for Git late next week as I will busy the next few days. Let me know once you have made all the relevant changes for me to test with the NAG Fortran compiler. I am actually running a workshop in the UK called "Fortran Modernisation Workshop" which covers PLplot: http://www.nag.co.uk/market/training/fortran-modernisation-workshop I've found PLplot the best visualisation libraries for Fortran 90 which I would like to thank you for :-) Best regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: Thursday, April 28, 2016 9:55 AM To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Alan, I made the small change I suggested and the results for Cygwin and MinGW64 look fine - see the attached files. The only platform I still need to test on is bare Windows (not as nicely packaged as the other two, unfortunately). When that turns out to be fine as well, I will do the commit. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Thursday, April 28, 2016 9:32 AM > To: Arjen Markus > Cc: Wadud Miah; plp...@li...<mailto:plp...@li...> > Subject: RE: [Plplot-devel] PLplot Fortran bindings > > On 2016-04-28 06:35-0000 Arjen Markus wrote: > > > Hi Alan, Wadud, > > > >> -----Original Message----- > >> From: Alan W. Irwin [mailto:ir...@be...] > >> Sent: Wednesday, April 27, 2016 11:22 PM > >> To: Wadud Miah > >> Cc: Arjen Markus; plp...@li...<mailto:plp...@li...> > >> Subject: RE: [Plplot-devel] PLplot Fortran bindings > >> > >> To Wadud and Arjen: > >> > >> @Arjen: > >> Since you have been unable to answer my quick question in a timely > >> manner concerning adopting selected_int_kind(9) rather than 4 for > >> private_plint, private_plbool, and private_plunicode, I have decided > >> to just go ahead with that change (commit 3442bac). > >> > > > Yesterday was a national holiday here, so I paid little attention to > my inbox :). However, considering the portability of these two types, why don't we > use C_INT32_T from ISO_C_BINDING? This maps to C's int32_t type (for the > companion C compiler to be precise). Essentially the same thing, except if the > platform does not have 32 bits integers, I'd say, but it conveys the one-to-one > relation between the Fortran and C side. > > > This does not rely on the Fortran 2008 standard, only on the Fortran > 2003 standard and we require that for the new binding anyway. > > That argument sounds reasonable to me, but you are the expert here. So please > implement this further change yourself. > > >> @Arjen: Could you follow up with similar test results for the latest > >> git master tip for both your Cygwin and MinGW-w64/MSYS2 platforms? > >> That wiki table documents your previous (good) Cygwin Fortran result. > >> Previously you also sent me your good MinGW-w64/MSYS2 platform > >> results for Fortran, but I was holding off on posting that result to > >> our wiki because that report also revealed a MinGW-w64/MSYS2 > >> installation update issue that requires you to reinstall the > >> MinGW-w64/MSYS2 platform to get access to the much more > convenient/reliable updating available for the latest version of that platform. > >> > > Will do. I should have time today to do that. That testing should cover the other > issue (the temporary files) as well. > > I look forward to those comprehensive test results on both platforms. > You can constrain those tests to just test the Fortran, C, and the ps device driver > components of PLplot (with the script arguments I have indicated) for speed > because even that limited result should thoroughly test creating temporary files. > > I recommend you make that further change you outlined above before these > constrained comprehensive tests so you can summarize these tests in the Tested > by: paragraph in the commit message. Once I see that commit from you, I plan to > follow up by redoing my own constrained Fortran comprehensive test (since it only > takes 7 minutes). > > 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 > __________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. ________________________________________________________________________ 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. ________________________________ |
From: Arjen M. <Arj...@de...> - 2016-05-09 17:10:43
|
Hi Wadud, I will have a closer look at it. I have never had the opportunity to use your compiler, so maybe we have been "lucky" sofar. Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Monday, May 09, 2016 5:10 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li... Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen, The NAG Fortran compiler has picked up a compilation error which I am struggling to understand: Error: /home/wadud/builds/plplot-plplot/bindings/f95/included_plplot_real_interfaces.f90, line 1112: Cannot IMPORT PLCGRID because it does not exist in the host INTERFACE_PLFCONT detected at ,@PLCGRID Going to the offending line in the code shown in boldface: subroutine transform( x, y, tx, ty, data ) bind(c) import :: private_plflt, PLcGrid implicit none real(kind=private_plflt), value, intent(in) :: x, y real(kind=private_plflt), intent(out) :: tx, ty type(PLcGrid), intent(in) :: data end subroutine transform It is not complaining about importing private_plflt but is complaining about importing PLcGrid and I do not understand how the compiler should know it should get this type definition from plplot_small_modules.f90 even though this works with other compilers, e.g. gfortran. I don't really know if this is significant, but at least I would like to make sense of it. Best regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 09 May 2016 14:15 To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Wadud, That is right. The last argument, plplot-plplot, is actually the name of the directory that will contain the source code and auxiliary data files. You will get an up-to-date repository that way. Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Monday, May 09, 2016 3:05 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen, Apologies for this question as I am not very familiar with Git, but what is the Git command I use to clone PLplot which has the corrections? Is it just: git clone git://git.code.sf.net/p/plplot/plplot plplot-plplot Regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 28 April 2016 11:20 To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Wadud, The changes should be there now - I introduced ISO_C_BINDING's C_INT32_T kind to solve the portability issue. On the platforms I have available that works fine. See https://sourceforge.net/p/plplot/plplot/ci/f00ee2a0fb0293e118a359d6e6312b30804b3420/ Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Thursday, April 28, 2016 12:17 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen/Alan, I will build PLplot for Git late next week as I will busy the next few days. Let me know once you have made all the relevant changes for me to test with the NAG Fortran compiler. I am actually running a workshop in the UK called "Fortran Modernisation Workshop" which covers PLplot: http://www.nag.co.uk/market/training/fortran-modernisation-workshop I've found PLplot the best visualisation libraries for Fortran 90 which I would like to thank you for :-) Best regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: Thursday, April 28, 2016 9:55 AM To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Alan, I made the small change I suggested and the results for Cygwin and MinGW64 look fine - see the attached files. The only platform I still need to test on is bare Windows (not as nicely packaged as the other two, unfortunately). When that turns out to be fine as well, I will do the commit. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Thursday, April 28, 2016 9:32 AM > To: Arjen Markus > Cc: Wadud Miah; plp...@li...<mailto:plp...@li...> > Subject: RE: [Plplot-devel] PLplot Fortran bindings > > On 2016-04-28 06:35-0000 Arjen Markus wrote: > > > Hi Alan, Wadud, > > > >> -----Original Message----- > >> From: Alan W. Irwin [mailto:ir...@be...] > >> Sent: Wednesday, April 27, 2016 11:22 PM > >> To: Wadud Miah > >> Cc: Arjen Markus; plp...@li...<mailto:plp...@li...> > >> Subject: RE: [Plplot-devel] PLplot Fortran bindings > >> > >> To Wadud and Arjen: > >> > >> @Arjen: > >> Since you have been unable to answer my quick question in a timely > >> manner concerning adopting selected_int_kind(9) rather than 4 for > >> private_plint, private_plbool, and private_plunicode, I have decided > >> to just go ahead with that change (commit 3442bac). > >> > > > Yesterday was a national holiday here, so I paid little attention to > my inbox :). However, considering the portability of these two types, why don't we > use C_INT32_T from ISO_C_BINDING? This maps to C's int32_t type (for the > companion C compiler to be precise). Essentially the same thing, except if the > platform does not have 32 bits integers, I'd say, but it conveys the one-to-one > relation between the Fortran and C side. > > > This does not rely on the Fortran 2008 standard, only on the Fortran > 2003 standard and we require that for the new binding anyway. > > That argument sounds reasonable to me, but you are the expert here. So please > implement this further change yourself. > > >> @Arjen: Could you follow up with similar test results for the latest > >> git master tip for both your Cygwin and MinGW-w64/MSYS2 platforms? > >> That wiki table documents your previous (good) Cygwin Fortran result. > >> Previously you also sent me your good MinGW-w64/MSYS2 platform > >> results for Fortran, but I was holding off on posting that result to > >> our wiki because that report also revealed a MinGW-w64/MSYS2 > >> installation update issue that requires you to reinstall the > >> MinGW-w64/MSYS2 platform to get access to the much more > convenient/reliable updating available for the latest version of that platform. > >> > > Will do. I should have time today to do that. That testing should cover the other > issue (the temporary files) as well. > > I look forward to those comprehensive test results on both platforms. > You can constrain those tests to just test the Fortran, C, and the ps device driver > components of PLplot (with the script arguments I have indicated) for speed > because even that limited result should thoroughly test creating temporary files. > > I recommend you make that further change you outlined above before these > constrained comprehensive tests so you can summarize these tests in the Tested > by: paragraph in the commit message. Once I see that commit from you, I plan to > follow up by redoing my own constrained Fortran comprehensive test (since it only > takes 7 minutes). > > 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 > __________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. |
From: Arjen M. <Arj...@de...> - 2016-05-09 17:23:19
|
Hi Wadud, Looking at the code, I deduce that your compiler takes all the names available to the directly encompassing scope, interface_plfcont, rather than the encompassing module. Regardless of whether that is correct behaviour, I think the fix is to add PLcGrid to the imports for interface_plfcont. Could you try that? If it works, I will apply the patch to the repository. I will try and concoct a small example so that I can post it on the comp.lang.fortran newsgroup for further advice. Quite possibly this is an edge case that needs to be sorted out. When I have such a small example, I will send it to you, so that you can check that the NAG compiler indeed doesn't like it. Regards, Arjen From: Arjen Markus [mailto:Arj...@de...] Sent: Monday, May 09, 2016 7:10 PM To: Wadud Miah; Alan W. Irwin Cc: plp...@li... Subject: Re: [Plplot-devel] PLplot Fortran bindings Hi Wadud, I will have a closer look at it. I have never had the opportunity to use your compiler, so maybe we have been "lucky" sofar. Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Monday, May 09, 2016 5:10 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li... Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen, The NAG Fortran compiler has picked up a compilation error which I am struggling to understand: Error: /home/wadud/builds/plplot-plplot/bindings/f95/included_plplot_real_interfaces.f90, line 1112: Cannot IMPORT PLCGRID because it does not exist in the host INTERFACE_PLFCONT detected at ,@PLCGRID Going to the offending line in the code shown in boldface: subroutine transform( x, y, tx, ty, data ) bind(c) import :: private_plflt, PLcGrid implicit none real(kind=private_plflt), value, intent(in) :: x, y real(kind=private_plflt), intent(out) :: tx, ty type(PLcGrid), intent(in) :: data end subroutine transform It is not complaining about importing private_plflt but is complaining about importing PLcGrid and I do not understand how the compiler should know it should get this type definition from plplot_small_modules.f90 even though this works with other compilers, e.g. gfortran. I don't really know if this is significant, but at least I would like to make sense of it. Best regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 09 May 2016 14:15 To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Wadud, That is right. The last argument, plplot-plplot, is actually the name of the directory that will contain the source code and auxiliary data files. You will get an up-to-date repository that way. Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Monday, May 09, 2016 3:05 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen, Apologies for this question as I am not very familiar with Git, but what is the Git command I use to clone PLplot which has the corrections? Is it just: git clone git://git.code.sf.net/p/plplot/plplot plplot-plplot Regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 28 April 2016 11:20 To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Wadud, The changes should be there now - I introduced ISO_C_BINDING's C_INT32_T kind to solve the portability issue. On the platforms I have available that works fine. See https://sourceforge.net/p/plplot/plplot/ci/f00ee2a0fb0293e118a359d6e6312b30804b3420/ Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Thursday, April 28, 2016 12:17 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen/Alan, I will build PLplot for Git late next week as I will busy the next few days. Let me know once you have made all the relevant changes for me to test with the NAG Fortran compiler. I am actually running a workshop in the UK called "Fortran Modernisation Workshop" which covers PLplot: http://www.nag.co.uk/market/training/fortran-modernisation-workshop I've found PLplot the best visualisation libraries for Fortran 90 which I would like to thank you for :-) Best regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: Thursday, April 28, 2016 9:55 AM To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Alan, I made the small change I suggested and the results for Cygwin and MinGW64 look fine - see the attached files. The only platform I still need to test on is bare Windows (not as nicely packaged as the other two, unfortunately). When that turns out to be fine as well, I will do the commit. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Thursday, April 28, 2016 9:32 AM > To: Arjen Markus > Cc: Wadud Miah; plp...@li...<mailto:plp...@li...> > Subject: RE: [Plplot-devel] PLplot Fortran bindings > > On 2016-04-28 06:35-0000 Arjen Markus wrote: > > > Hi Alan, Wadud, > > > >> -----Original Message----- > >> From: Alan W. Irwin [mailto:ir...@be...] > >> Sent: Wednesday, April 27, 2016 11:22 PM > >> To: Wadud Miah > >> Cc: Arjen Markus; plp...@li...<mailto:plp...@li...> > >> Subject: RE: [Plplot-devel] PLplot Fortran bindings > >> > >> To Wadud and Arjen: > >> > >> @Arjen: > >> Since you have been unable to answer my quick question in a timely > >> manner concerning adopting selected_int_kind(9) rather than 4 for > >> private_plint, private_plbool, and private_plunicode, I have decided > >> to just go ahead with that change (commit 3442bac). > >> > > > Yesterday was a national holiday here, so I paid little attention to > my inbox :). However, considering the portability of these two types, why don't we > use C_INT32_T from ISO_C_BINDING? This maps to C's int32_t type (for the > companion C compiler to be precise). Essentially the same thing, except if the > platform does not have 32 bits integers, I'd say, but it conveys the one-to-one > relation between the Fortran and C side. > > > This does not rely on the Fortran 2008 standard, only on the Fortran > 2003 standard and we require that for the new binding anyway. > > That argument sounds reasonable to me, but you are the expert here. So please > implement this further change yourself. > > >> @Arjen: Could you follow up with similar test results for the latest > >> git master tip for both your Cygwin and MinGW-w64/MSYS2 platforms? > >> That wiki table documents your previous (good) Cygwin Fortran result. > >> Previously you also sent me your good MinGW-w64/MSYS2 platform > >> results for Fortran, but I was holding off on posting that result to > >> our wiki because that report also revealed a MinGW-w64/MSYS2 > >> installation update issue that requires you to reinstall the > >> MinGW-w64/MSYS2 platform to get access to the much more > convenient/reliable updating available for the latest version of that platform. > >> > > Will do. I should have time today to do that. That testing should cover the other > issue (the temporary files) as well. > > I look forward to those comprehensive test results on both platforms. > You can constrain those tests to just test the Fortran, C, and the ps device driver > components of PLplot (with the script arguments I have indicated) for speed > because even that limited result should thoroughly test creating temporary files. > > I recommend you make that further change you outlined above before these > constrained comprehensive tests so you can summarize these tests in the Tested > by: paragraph in the commit message. Once I see that commit from you, I plan to > follow up by redoing my own constrained Fortran comprehensive test (since it only > takes 7 minutes). > > 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 > __________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. 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. |
From: Wadud M. <wad...@na...> - 2016-05-10 09:21:00
|
Hi Arjen, Your suggestion has worked with the NAG Fortran compiler: subroutine interface_plfcont( lookup, grid, nx, ny, kx, lx, ky, ly, clevel, nlevel, transform, data ) & bind(c,name='plfcont') import :: c_ptr import :: private_plint, private_plflt, PLcGrid [ ... ] subroutine transform( x, y, tx, ty, data ) bind(c) import :: private_plflt, PLcGrid implicit none This has removed the error. I will look into the sample code to see how the NAG Fortran compiler responds to it. Thanks, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 09 May 2016 18:23 To: Arjen Markus <Arj...@de...>; Wadud Miah <wad...@na...>; Alan W. Irwin <ir...@be...> Cc: plp...@li... Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Wadud, Looking at the code, I deduce that your compiler takes all the names available to the directly encompassing scope, interface_plfcont, rather than the encompassing module. Regardless of whether that is correct behaviour, I think the fix is to add PLcGrid to the imports for interface_plfcont. Could you try that? If it works, I will apply the patch to the repository. I will try and concoct a small example so that I can post it on the comp.lang.fortran newsgroup for further advice. Quite possibly this is an edge case that needs to be sorted out. When I have such a small example, I will send it to you, so that you can check that the NAG compiler indeed doesn't like it. Regards, Arjen From: Arjen Markus [mailto:Arj...@de...] Sent: Monday, May 09, 2016 7:10 PM To: Wadud Miah; Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> Subject: Re: [Plplot-devel] PLplot Fortran bindings Hi Wadud, I will have a closer look at it. I have never had the opportunity to use your compiler, so maybe we have been "lucky" sofar. Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Monday, May 09, 2016 5:10 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen, The NAG Fortran compiler has picked up a compilation error which I am struggling to understand: Error: /home/wadud/builds/plplot-plplot/bindings/f95/included_plplot_real_interfaces.f90, line 1112: Cannot IMPORT PLCGRID because it does not exist in the host INTERFACE_PLFCONT detected at ,@PLCGRID Going to the offending line in the code shown in boldface: subroutine transform( x, y, tx, ty, data ) bind(c) import :: private_plflt, PLcGrid implicit none real(kind=private_plflt), value, intent(in) :: x, y real(kind=private_plflt), intent(out) :: tx, ty type(PLcGrid), intent(in) :: data end subroutine transform It is not complaining about importing private_plflt but is complaining about importing PLcGrid and I do not understand how the compiler should know it should get this type definition from plplot_small_modules.f90 even though this works with other compilers, e.g. gfortran. I don't really know if this is significant, but at least I would like to make sense of it. Best regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 09 May 2016 14:15 To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Wadud, That is right. The last argument, plplot-plplot, is actually the name of the directory that will contain the source code and auxiliary data files. You will get an up-to-date repository that way. Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Monday, May 09, 2016 3:05 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen, Apologies for this question as I am not very familiar with Git, but what is the Git command I use to clone PLplot which has the corrections? Is it just: git clone git://git.code.sf.net/p/plplot/plplot plplot-plplot Regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 28 April 2016 11:20 To: Wadud Miah <wad...@na...<mailto:wad...@na...>>; Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Wadud, The changes should be there now - I introduced ISO_C_BINDING's C_INT32_T kind to solve the portability issue. On the platforms I have available that works fine. See https://sourceforge.net/p/plplot/plplot/ci/f00ee2a0fb0293e118a359d6e6312b30804b3420/ Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Thursday, April 28, 2016 12:17 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen/Alan, I will build PLplot for Git late next week as I will busy the next few days. Let me know once you have made all the relevant changes for me to test with the NAG Fortran compiler. I am actually running a workshop in the UK called "Fortran Modernisation Workshop" which covers PLplot: http://www.nag.co.uk/market/training/fortran-modernisation-workshop I've found PLplot the best visualisation libraries for Fortran 90 which I would like to thank you for :-) Best regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: Thursday, April 28, 2016 9:55 AM To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Alan, I made the small change I suggested and the results for Cygwin and MinGW64 look fine - see the attached files. The only platform I still need to test on is bare Windows (not as nicely packaged as the other two, unfortunately). When that turns out to be fine as well, I will do the commit. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Thursday, April 28, 2016 9:32 AM > To: Arjen Markus > Cc: Wadud Miah; plp...@li...<mailto:plp...@li...> > Subject: RE: [Plplot-devel] PLplot Fortran bindings > > On 2016-04-28 06:35-0000 Arjen Markus wrote: > > > Hi Alan, Wadud, > > > >> -----Original Message----- > >> From: Alan W. Irwin [mailto:ir...@be...] > >> Sent: Wednesday, April 27, 2016 11:22 PM > >> To: Wadud Miah > >> Cc: Arjen Markus; plp...@li...<mailto:plp...@li...> > >> Subject: RE: [Plplot-devel] PLplot Fortran bindings > >> > >> To Wadud and Arjen: > >> > >> @Arjen: > >> Since you have been unable to answer my quick question in a timely > >> manner concerning adopting selected_int_kind(9) rather than 4 for > >> private_plint, private_plbool, and private_plunicode, I have decided > >> to just go ahead with that change (commit 3442bac). > >> > > > Yesterday was a national holiday here, so I paid little attention to > my inbox :). However, considering the portability of these two types, why don't we > use C_INT32_T from ISO_C_BINDING? This maps to C's int32_t type (for the > companion C compiler to be precise). Essentially the same thing, except if the > platform does not have 32 bits integers, I'd say, but it conveys the one-to-one > relation between the Fortran and C side. > > > This does not rely on the Fortran 2008 standard, only on the Fortran > 2003 standard and we require that for the new binding anyway. > > That argument sounds reasonable to me, but you are the expert here. So please > implement this further change yourself. > > >> @Arjen: Could you follow up with similar test results for the latest > >> git master tip for both your Cygwin and MinGW-w64/MSYS2 platforms? > >> That wiki table documents your previous (good) Cygwin Fortran result. > >> Previously you also sent me your good MinGW-w64/MSYS2 platform > >> results for Fortran, but I was holding off on posting that result to > >> our wiki because that report also revealed a MinGW-w64/MSYS2 > >> installation update issue that requires you to reinstall the > >> MinGW-w64/MSYS2 platform to get access to the much more > convenient/reliable updating available for the latest version of that platform. > >> > > Will do. I should have time today to do that. That testing should cover the other > issue (the temporary files) as well. > > I look forward to those comprehensive test results on both platforms. > You can constrain those tests to just test the Fortran, C, and the ps device driver > components of PLplot (with the script arguments I have indicated) for speed > because even that limited result should thoroughly test creating temporary files. > > I recommend you make that further change you outlined above before these > constrained comprehensive tests so you can summarize these tests in the Tested > by: paragraph in the commit message. Once I see that commit from you, I plan to > follow up by redoing my own constrained Fortran comprehensive test (since it only > takes 7 minutes). > > 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 > __________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. ________________________________________________________________________ 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. ________________________________ 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. 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. ________________________________________________________________________ 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. ________________________________ |
From: Alan W. I. <ir...@be...> - 2016-05-09 18:16:07
|
On 2016-05-09 15:09-0000 Wadud Miah wrote: > The NAG Fortran compiler has picked up a compilation error which I am struggling to understand: > > Error: /home/wadud/builds/plplot-plplot/bindings/f95/included_plplot_real_interfaces.f90, line 1112: Cannot IMPORT PLCGRID because it does not exist in the host INTERFACE_PLFCONT > detected at ,@PLCGRID > > Going to the offending line in the code shown in boldface: > > subroutine transform( x, y, tx, ty, data ) bind(c) > import :: private_plflt, PLcGrid > implicit none > real(kind=private_plflt), value, intent(in) :: x, y > real(kind=private_plflt), intent(out) :: tx, ty > type(PLcGrid), intent(in) :: data > end subroutine transform > > It is not complaining about importing private_plflt but is complaining about importing PLcGrid and I do not understand how the compiler should know it should get this type definition from plplot_small_modules.f90 even though this works with other compilers, e.g. gfortran. I don't really know if this is significant, but at least I would like to make sense of it. Hi Wadud: Thanks very much for your build test of PLplot using the NAG Fortran compiler. To help you navigate through our code that is relevant to the above build error for the NAG Fortran compiler, both plplot_double.f90 (which defines the plplot_double module) and plplot_single.f90 (which defines the plplot_single module), contain the line use plplot_types, only: private_plflt, private_plint, private_plbool, private_double, PLcGrid, PLfGrid before they include "included_plplot_real_interfaces.f90". Furthermore, if you look in plplot_small_modules.f90 where the plplot_types module is defined it is straightforward to confirm that module contains both private_plflt and PLcGRID. So my opinion is the above import :: private_plflt, PLcGrid should "just work" for compilers that are compliant with the Fortran 2003 standard. To investigate further why the above logic unexpectedly cannot be compiled with the NAG compiler, I strongly suggest you make a small one-file example containing a simplified plplot_types module that just defines private_plflt, and plcGrid exactly like we do, and which also contains another module that includes the above subroutine transform. Then if that vastly simplified example also fails to compile you have that example to take to the NAG developers concerning a possible bug in their compiler. Or they may respond to your report by saying something like this: "to get that Fortran standards compliant code to compile with the NAG compiler, you need xxx flag". Good luck with your further investigation of the above build error, and let us know how it goes. 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 __________________________ |
From: Arjen M. <Arj...@de...> - 2016-05-09 18:50:15
|
Hi Wadud, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > > Hi Wadud: > > Thanks very much for your build test of PLplot using the NAG Fortran compiler. > > ... > > To investigate further why the above logic unexpectedly cannot be compiled with > the NAG compiler, I strongly suggest you make a small one-file example containing > a simplified plplot_types module that just defines private_plflt, and plcGrid exactly > like we do, and which also contains another module that includes the above > subroutine transform. > Then if that vastly simplified example also fails to compile you have that example to > take to the NAG developers concerning a possible bug in their compiler. Or they > may respond to your report by saying something like this: "to get that Fortran > standards compliant code to compile with the NAG compiler, you need xxx flag". > I prepared a small example (see below) that is generously accepted by the two compilers I have access to. I think it exhibits the characteristics of the code that is not accepted by the NAG compiler. The only difference that may be important is the fact that it does not contain the ISO_C_BINDING features. If this small example is accepted, then I would say it is indeed a problem in the NAG compiler. The alternative is that the example is not accepted and that the NAG compiler doesn't like the import through the nesting of interfaces. I would not think that the example is non-standard, but there can be subtleties that I am overlooking here. That is why it is important to see what the NAG compiler comes up with. Regards, Arjen ! nested_interface.f90 -- ! Attempt to reproduce a problem discovered by Wadud Miah ! module my_types implicit none type xyz integer :: x, y, z end type xyz end module my_types module my_interfaces use my_types implicit none interface subroutine use_transform( transform ) interface subroutine transform( data, result ) import :: xyz type(xyz) :: data real :: result end subroutine transform end interface end subroutine use_transform end interface end module my_interfaces 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. |
From: Wadud M. <wad...@na...> - 2016-05-10 10:15:30
|
Hi Arjen, Your simple example failed with the NAG compiler, but worked when I added the line (shown in boldface): subroutine use_transform( transform ) import :: xyz interface subroutine transform( data, result ) I don't know what the standard says on this topic, but I think I would be explicit and add the additional import statement so that the user defined data type is in scope. Best regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 09 May 2016 19:50 To: Alan W. Irwin <ir...@be...>; Wadud Miah <wad...@na...> Cc: plp...@li... Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Wadud, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > > Hi Wadud: > > Thanks very much for your build test of PLplot using the NAG Fortran compiler. > > ... > > To investigate further why the above logic unexpectedly cannot be compiled with > the NAG compiler, I strongly suggest you make a small one-file example containing > a simplified plplot_types module that just defines private_plflt, and plcGrid exactly > like we do, and which also contains another module that includes the above > subroutine transform. > Then if that vastly simplified example also fails to compile you have that example to > take to the NAG developers concerning a possible bug in their compiler. Or they > may respond to your report by saying something like this: "to get that Fortran > standards compliant code to compile with the NAG compiler, you need xxx flag". > I prepared a small example (see below) that is generously accepted by the two compilers I have access to. I think it exhibits the characteristics of the code that is not accepted by the NAG compiler. The only difference that may be important is the fact that it does not contain the ISO_C_BINDING features. If this small example is accepted, then I would say it is indeed a problem in the NAG compiler. The alternative is that the example is not accepted and that the NAG compiler doesn't like the import through the nesting of interfaces. I would not think that the example is non-standard, but there can be subtleties that I am overlooking here. That is why it is important to see what the NAG compiler comes up with. Regards, Arjen ! nested_interface.f90 -- ! Attempt to reproduce a problem discovered by Wadud Miah ! module my_types implicit none type xyz integer :: x, y, z end type xyz end module my_types module my_interfaces use my_types implicit none interface subroutine use_transform( transform ) interface subroutine transform( data, result ) import :: xyz type(xyz) :: data real :: result end subroutine transform end interface end subroutine use_transform end interface end module my_interfaces 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. ________________________________________________________________________ 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. ________________________________ |
From: Alan W. I. <ir...@be...> - 2016-05-09 19:17:41
|
On 2016-05-09 18:50-0000 Arjen Markus wrote: > Hi Wadud, > > > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@be...] >> >> Hi Wadud: >> >> Thanks very much for your build test of PLplot using the NAG Fortran compiler. >> >> ... > >> To investigate further why the above logic unexpectedly cannot be compiled with >> the NAG compiler, I strongly suggest you make a small one-file example containing >> a simplified plplot_types module that just defines private_plflt, and plcGrid exactly >> like we do, and which also contains another module that includes the above >> subroutine transform. >> Then if that vastly simplified example also fails to compile you have that example to >> take to the NAG developers concerning a possible bug in their compiler. Or they >> may respond to your report by saying something like this: "to get that Fortran >> standards compliant code to compile with the NAG compiler, you need xxx flag". >> > > > I prepared a small example (see below) that is generously accepted by the two compilers I have access to. I think it exhibits the characteristics of the code that is not accepted by the NAG compiler. The only difference that may be important is the fact that it does not contain the ISO_C_BINDING features. If this small example is accepted, then I would say it is indeed a problem in the NAG compiler. > > The alternative is that the example is not accepted and that the NAG compiler doesn't like the import through the nesting of interfaces. I would not think that the example is non-standard, but there can be subtleties that I am overlooking here. That is why it is important to see what the NAG compiler comes up with. > > Regards, > > Arjen > > ! nested_interface.f90 -- > > ! Attempt to reproduce a problem discovered by Wadud Miah > > ! > > module my_types > > implicit none > > > > type xyz > > integer :: x, y, z > > end type xyz > > end module my_types > > > > module my_interfaces > > use my_types > > > > implicit none > > > > interface > > subroutine use_transform( transform ) > > interface > > subroutine transform( data, result ) > > import :: xyz > > type(xyz) :: data > > real :: result > > end subroutine transform > > end interface > > end subroutine use_transform > > end interface > > end module my_interfaces Hi Arjen: You are absolutely right to ask Wadud to try the above simplest possible example of importing a type from another module first. However, another potential issue here is that if the NAG Fortran compiler compiles import :: private_plflt, PLcGrid from left to right, then it had no problem with importing plflt_private which is a type defined in a very similar manner to PLcGrid. So if Wadud verifies the above simple one-type example compiles for the NAG fortran compiler, then you will likely want to make your example more complex using two simple types just in case the NAG Fortran compiler issue is with more than one imported type. Then if that simple two-type case has no NAG problem, try using our exact types for private_plflt and PLcGrid instead. 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 __________________________ |
From: Arjen M. <Arj...@de...> - 2016-05-09 19:27:52
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Hi Arjen: > > You are absolutely right to ask Wadud to try the above simplest possible example > of importing a type from another module first. > > However, another potential issue here is that if the NAG Fortran compiler compiles > > import :: private_plflt, PLcGrid > > from left to right, then it had no problem with importing plflt_private which is a type > defined in a very similar manner to PLcGrid. > Aha, I overlooked that detail. That is another indication that the NAG compiler may be at fault here. Indeed,then it becomes a matter of further extending the example. Regards, Arjen 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. |
From: Wadud M. <wad...@na...> - 2016-05-10 12:26:56
|
Hi Arjen, Further to my previous email, I think the import statement has to have scope in the inner interface by declaring it in the outer interface. I had a look at the Fortran standard and I could not find any statement on this issue. My colleagues are adamant that this is part of the standard and I will be contacting a member of the Fortran standard (Malcom Cohen) to clarify this. Another thing the NAG compiler complained about was the interface declaration of the external subroutines fill() and interface_plfill() which have the same binding label c_plfill in file included_plplot_configured_types.f90. In addition, the external subroutine fill() is not called anywhere so I think could be removed. Regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 09 May 2016 20:26 To: Alan W. Irwin <ir...@be...> Cc: Wadud Miah <wad...@na...>; plp...@li... Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Hi Arjen: > > You are absolutely right to ask Wadud to try the above simplest possible example > of importing a type from another module first. > > However, another potential issue here is that if the NAG Fortran compiler compiles > > import :: private_plflt, PLcGrid > > from left to right, then it had no problem with importing plflt_private which is a type > defined in a very similar manner to PLcGrid. > Aha, I overlooked that detail. That is another indication that the NAG compiler may be at fault here. Indeed,then it becomes a matter of further extending the example. Regards, Arjen 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. ________________________________________________________________________ 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. ________________________________ |
From: Arjen M. <Arj...@de...> - 2016-05-10 12:29:52
|
Hi Wadud, Thanks for running the example and the issue with fill() - that is probably some leftover that was not detected by the compilers I use. Intriguing question regarding the scope of the import statement. I will post this on comp.lang.fortran - some people there know the standard by heart :). Regards, Arjen From: Wadud Miah [mailto:wad...@na...] Sent: Tuesday, May 10, 2016 2:27 PM To: Arjen Markus; Alan W. Irwin Cc: plp...@li... Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Arjen, Further to my previous email, I think the import statement has to have scope in the inner interface by declaring it in the outer interface. I had a look at the Fortran standard and I could not find any statement on this issue. My colleagues are adamant that this is part of the standard and I will be contacting a member of the Fortran standard (Malcom Cohen) to clarify this. Another thing the NAG compiler complained about was the interface declaration of the external subroutines fill() and interface_plfill() which have the same binding label c_plfill in file included_plplot_configured_types.f90. In addition, the external subroutine fill() is not called anywhere so I think could be removed. Regards, Wadud. From: Arjen Markus [mailto:Arj...@de...] Sent: 09 May 2016 20:26 To: Alan W. Irwin <ir...@be...<mailto:ir...@be...>> Cc: Wadud Miah <wad...@na...<mailto:wad...@na...>>; plp...@li...<mailto:plp...@li...> Subject: RE: [Plplot-devel] PLplot Fortran bindings Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Hi Arjen: > > You are absolutely right to ask Wadud to try the above simplest possible example > of importing a type from another module first. > > However, another potential issue here is that if the NAG Fortran compiler compiles > > import :: private_plflt, PLcGrid > > from left to right, then it had no problem with importing plflt_private which is a type > defined in a very similar manner to PLcGrid. > Aha, I overlooked that detail. That is another indication that the NAG compiler may be at fault here. Indeed,then it becomes a matter of further extending the example. Regards, Arjen 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. ________________________________________________________________________ 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. ________________________________ 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. |