plplot-devel — Technical discussion about PLplot development

[Plplot-devel] ocaml cairo

[Orion P. <or...@co...>]

Re:

commit 893625ca34ed22f4d8941f9902aa71bf30eaf8fb
Author: Alan W. Irwin <ai...@us...>
Date:   Sat Oct 24 13:30:10 2015 -0700

    Build system: Disable OCAML_HAS_CAIRO

    I have taken this step because substantial maintenance will be
    required before this component of PLplot will configure, build, or run
    again because of backwards incompatibilities that have been introduced
    in ocaml support of cairo. For example, the package name "cairo2" no
    longer exists any more and should probably be replaced by the package
    name cairo, but that is just the start of the backwards
    incompatibilities.

diff --git a/cmake/modules/ocaml.cmake b/cmake/modules/ocaml.cmake
index 0403abd..a106ed2 100644
--- a/cmake/modules/ocaml.cmake
+++ b/cmake/modules/ocaml.cmake
@@ -2,7 +2,7 @@
 #
 # Copyright (C) 2008 Andrew Ross
 # Copyright (C) 2009 Hezekiah M. Carty
-# Copyright (C) 2009-2014 Alan W. Irwin
+# Copyright (C) 2009-2015 Alan W. Irwin
 #
 # This file is part of PLplot.
 #
@@ -196,6 +196,9 @@ if(ENABLE_ocaml)
   if(OCAMLFIND)
     if(PLD_extcairo)
       option(OCAML_HAS_CAIRO "OCaml has the cairo package" ON)
+      # Disable since substantial maintenance is required before this component
+      # of PLplot will configure, build, and/or run.
+      set(OCAML_HAS_CAIRO OFF CACHE BOOL "OCaml has the cairo package" FORCE)
       if(OCAML_HAS_CAIRO)
        set(text_cairo "module C = Cairo")
        file(WRITE ${CMAKE_BINARY_DIR}/test_cairo.ml ${text_cairo})


It would be nice if the message was changed to something like "plplot ocaml
cairo support currently disabled", so avoid having people like me spend time
figuring out why it's not finding the cairo package.  Thanks.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                   http://www.nwra.com

Re: [Plplot-devel] octave 4

[Alan W. I. <ir...@be...>]

On 2016-07-19 16:48-0600 Orion Poplawski wrote:

> -- OCTAVE_VERSION = 4.0.3
> -- WARNING: Octave-4 has been found which is likely to lead to build errors
> for PLplot.
> -- WARNING: TRY_OCTAVE4 = ON so experimentally trying Octave-4
>
> Is this still experimental?  Octave 4 has been out for a while now.

Hi Orion:

Yes, I believe Octave-4 is still experimental.  Part of the issue is I don't have good
access to Octave 4 at this time so I have to rely on other's
comprehensive test reports.  So far Arjen is the only one that has
done that for the Octave-4 case.  He ran the equivalent of

scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON  -DDEFAULT _NO_BINDINGS=ON -DENABLE_octave=ON -DTRY_OCTAVE4=ON" --do_test_interactive no

for his Cygwin platform.  From the report tarball generated by that
script, it appears the octave binding and examples
built with no obvious issues, but at run-time there were UTF-8 related
errors such as

*** PLPLOT ERROR, ABORTING OPERATION ***
UTF-8 string is malformed: Фазовый сдви<D0>@, aborting operation

so my impression is we are close, but not there yet at least on
Cygwin.

If you would be willing to run the same script (which I believe will
take only ~10 minutes or so because of all the above constraints to
limit the test just to Octave and the ps device driver) and send me
the report tarball that is generated (typically in
../comprehensive_test_disposeable/comprehensive_test.tar.gz), then I
will know a lot more about how mature our Octave-4 support is on
Linux.  Of course, if you have success, then I would plan to change
our build system to only emit the above octave-4 WARNING messages only
for non-Linux platforms.  Or if you have exactly the same run-time
failure as Arjen, and know of a patch to fix it, that would be great
as well.

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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

Linux-powered Science
__________________________

[Plplot-devel] octave 4

[Orion P. <or...@co...>]

-- OCTAVE_VERSION = 4.0.3
-- WARNING: Octave-4 has been found which is likely to lead to build errors
for PLplot.
-- WARNING: TRY_OCTAVE4 = ON so experimentally trying Octave-4

Is this still experimental?  Octave 4 has been out for a while now.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                   http://www.nwra.com

[Plplot-devel] PLplot now appears to be ready for CMake 3.6.0

[Alan W. I. <ir...@be...>]

Thanks to a recent patch by Raphael Kubo da Costa and my subsequent
fix of that (see <https://sourceforge.net/p/plplot/patches/33/>)
PLplot now appears to be ready for CMake-3.6.0.

To verify that change and also the readiness of PLplot for
CMake-3.6.0, I did a complete (both interactive and noninteractive)
comprehensive test of PLplot that had essentially perfect results (see
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>)

So PLplot appears to be ready for CMake-3.6.0.  In addition, these
good comprehensive test results should serve as a comparison for
future comprehensive tests during this release cycle to help establish
no regressions will have been introduced by any further changes leading up to
the release of PLplot-5.12.0.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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

Linux-powered Science
__________________________

[Plplot-devel] Status of the planned release of 5.12.0

[Alan W. I. <ir...@be...>]

Here is the status of the planned release of 5.12.0.

I.  One of the major improvements for 5.12.0 is the new Fortran
binding, and Arjen and I thought we were completely done with that
implementation when we got good test results for both gfortran and
ifort months ago. However, two months ago, Wadud Miah demonstrated
that the new Fortran binding would not build on Linux for the nagfor
compiler (which has the reputation of being the most
standards-compliant Fortran compiler available).  One issue that
absorbed a lot of Arjen's time and which will likely need to be
addressed after 5.12.0 is release is that CMake does not yet have
proper support for the nagfor compiler on Windows. Fortunately, Arjen
does have access to Linux (where CMake does support nagfor) and was
able to sort out the large number of standards compliancy issues
discovered in our Fortran binding by that compiler.  Near the end of
Arjen's work, it became apparent that we needed a massive style change
for our Fortran binding that would remove some 600 lines of duplicated
code from it. I have just now completed that style change, and the
result gives perfect comprehensive tests results on Linux with
gfortran.  So the current status for I. is we are essentially done
with the new Fortran binding, but Arjen still has to do comprehensive
Fortran testing on his 4 different Fortran platforms (nagfor/Linux,
gfortran/Cygwin, gfortran/MinGW-w64/MSYS2, and ifort/MSVC) to confirm
that my massive style change has not introduced any errors or new
warning issues.  And once that is completed, we will also ask Wadud to
run the comprehensive Fortran test on his own Linux platform and also
evaluate the new Fortran binding again for his own Fortran plotting
purposes.

II. One of the major improvements planned for 5.12.0 is to greatly
improve our DocBook documentation including making it much less
specific to C and including a complete update of the Fortran chapter.
I have made a lot of progress on this topic, and I hope to merge the
results to master within a week.

III. Arjen has also been working on his project to support only the
redacted argument lists in Tcl.  My understanding is that topic is
almost completely matured so the prospects of getting this into 5.12.0
are good.

IV. I have a number of additional topics on my ToDo list so I may be
able to squeeze some of those in during the one-month Fortran test period
(see below).

V. Other topics merged by our other active developers during the
Fortran test period?  Please let me know of any plans you may have
in this regard.

VI. Fortran test period.  Once I and II have been completed, then I
plan to publicly ask on the plplot-general mailing list for all
interested Fortran users of PLplot (supported by our new
documentation) to (i) run the comprehensive Fortran test on their
platform of choice, and/or (ii) to evaluate the new Fortran binding
for their own plotting purposes.  I assume this whole Fortran test
period will take something like a month.

Thus, I plan to freeze merges of major topic branches to the master
branch roughly one month from now (end of July), and after comprehensive
testing and debugging of any issues found during that testing, release based on
that master branch a couple of weeks (mid August) after that.

N.B. the ETA for both those release milestones depends critically on
how much participation we get for the Fortran testing month and how
much effort will be required to fix any Fortran binding bugs found
during that testing. However, I am hoping that our nagfor experience
has flushed out most if not all our remaining Fortran binding bugs so
that we will be able to stick fairly closely to those two ETA's.

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
__________________________

Re: [Plplot-devel] NAG whitespace issues

[Alan W. I. <ir...@be...>]

On 2016-05-25 06:25-0000 Arjen Markus wrote:

> I already installed it [NAG Fortran] in a non-default location. The
"EFBuilder 6.1" part of the path comes from the installation itself. I
set the installation directory to "d:\NAG".

> I just examined the PATH variable: it contains the directory
"D:\NAG\EFBuilder 6.1\bin". I suspect that CMake finds pkg-config.exe
via this path. So we are pretty much stuck with this behaviour.

Too bad NAG put spaces in their internal pathnames.  Ugh.  I suggest
you report that issue to them since it gratuitously creates problems for
those building free software packages such as PLplot.

Here is another possible workaround for this situation. I presume you
are working with either Cygwin or MinGW-w64/MSYS2 which have their own
non-NAG versions of pkg-config, freetype, etc., available.  If so, put
"D:\NAG\EFBuilder 6.1\bin" at the end of the PATH and not the start.
The result should be that the non-NAG version of pkg-config is found
and that, in turn, should find the non-NAG version of freetype.  This
idea is based on the assumption that the NAG software installation
does not fiddle with the PKG_CONFIG_PATH environment variable, but
there are ways to get around that if necessary.  The other assumption
I am using here is NAG supplies pkg-config, freetype (and presumably
its own versions of other useful build tools and libraries) for
customer convenience and not as a necessity for the NAG compiler to
work properly.  (If the NAG compiler relied directly on certain free
software tools and libraries, i.e., this is more than just providing a
convenience for customers, then there might be a version mismatch
issue if you substituted Cygwin or MinGW-w64/MSYS2 versions of tools
and free libraries for NAG ones.)

With regard to the eventual build-system fix for spaces in pathnames,
I have been doing a lot of further investigation, and one of the
primary issues is that our build system uses the COMPILE_FLAGS
property virtually everywhere (since that was the only way to work
with compiler flags in CMake a decade ago.) That property is a
space-separated string containing the various compiler flags, and that
makes it difficult/impossible to distinguish spaces in the various
parts of that string from the spaces that are supposed to separate
those parts. It turns out that CMake-3 deprecates COMPILE_FLAGS
(presumably for that space-separated reason) and instead provides the
COMPILE_OPTIONS choice which stores its results in a normal CMake
list.  It is a big undertaking for me to change our build system so
that it uses COMPILE_OPTIONS rather than COMPILE_FLAGS and processes
those results with normal CMake list processing rather than special
code to deal with the space separation. However, I believe that
massive cleanup to our build system will be worth it since I am pretty
sure many of our problems with spaces in path names will disappear as
a result.

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
__________________________

Re: [Plplot-devel] NAG whitespace issues

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, May 24, 2016 9:24 PM
> To: Arjen Markus
> Cc: plp...@li...
> Subject: RE: NAG whitespace issues
>
> On 2016-05-24 17:58-0000 Arjen Markus wrote:
>
> > Having had a closer look at the output I now see what is going on:
> Cmake picks up the location of the pkg-config program that comes as part of the
> NAG compiler installation. Then several directories are added as arguments to -I
> options, only without the quotes to group the various parts.
>
> > As this means Freetype libraries are found, they become part of the
> compiler invocation for plfreetype.c. I have attached the tarball for your reference.
>
> Hi Arjen:
>
> Thanks for that tarball, and I exactly agree with your analysis of the situation.  And
> it should not be too difficult to replicate the issue here.  However, CMake blank in
> directory issues are tricky to fix correctly so I will do my best before the release, but
> I can give no guarantee of success.
>
> Meanwhile, for your case is there any chance you can simply work around the
> problem by using a non-default NAG installation prefix without blanks in that prefix
> name?  If that alternative solution works, then we could advise our Windows NAG
> users (who otherwise are all likely to be caught by this) to avoid blanks in their NAG
> installation prefix in case I cannot find a fix.
>
I already installed it in a non-default location. The "EFBuilder 6.1" part of the path comes from the installation itself. I set the installation directory to "d:\NAG".

I just examined the PATH variable: it contains the directory "D:\NAG\EFBuilder 6.1\bin". I suspect that CMake finds pkg-config.exe via this path. So we are pretty much stuck with this behaviour.

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.

Re: [Plplot-devel] NAG whitespace issues

[Alan W. I. <ir...@be...>]

On 2016-05-24 17:58-0000 Arjen Markus wrote:

> Having had a closer look at the output I now see what is going on:
Cmake picks up the location of the pkg-config program that comes as
part of the NAG compiler installation. Then several directories are
added as arguments to -I options, only without the quotes to group the
various parts.

> As this means Freetype libraries are found, they become part of the
compiler invocation for plfreetype.c. I have attached the tarball for
your reference.

Hi Arjen:

Thanks for that tarball, and I exactly agree with your analysis of the
situation.  And it should not be too difficult to replicate the issue
here.  However, CMake blank in directory issues are tricky to fix
correctly so I will do my best before the release, but I can give no
guarantee of success.

Meanwhile, for your case is there any chance you can simply work
around the problem by using a non-default NAG installation prefix
without blanks in that prefix name?  If that alternative solution
works, then we could advise our Windows NAG users (who otherwise are
all likely to be caught by this) to avoid blanks in their NAG
installation prefix in case I cannot find a fix.

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
__________________________

Re: [Plplot-devel] NAG whitespace issues

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

Hi Alan,

See my reply below.

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, May 24, 2016 12:44 PM
> To: Arjen Markus
> Cc: Phil Rosenberg; plp...@li...
> Subject: NAG whitespace issues
>
> On 2016-05-24 09:32-0000 Arjen Markus wrote:
>
> > I should perhaps have added that I had to get around a somewhat
> similar problem with a directory containing an installation of GTK - how CMake
> determined that it is there, I have no clue, but the directory is
>
> > d:\nag\efbuilder 6.1\gtk
>
> > which is nowhere near the directories normally searched by CMake as
> far as I know. By renaming that directory I solved the problem that CMake included
> directories like "6.1\gtk\include" in the build procedure.
>
> Hi Arjen:
>
> I am virtually positive this build system problem is due to the whitespace before the
> 6.1 since you report CMake is looking for a directory that starts right after that
> whitespace which, of course, is a mistake.  Probably the only way out of it for now
> is renaming as you have done.  But I do plan to make the experiment later in this
> release cycle of using source, build, and install tree with whitespace in the names to
> see how many of the problems that result from that I can address by judicious use
> of quotes.  Let me know the exact CMake variable where "d:\nag\efbuilder 6.1\gtk"
> is being broken up at the whitespace, and I might be able to fix that issue with
> quotes as well.
>

Having had a closer look at the output I now see what is going on: Cmake picks up the location of the pkg-config program that comes as part of the NAG compiler installation. Then several directories are added as arguments to -I options, only without the quotes to group the various parts.

As this means Freetype libraries are found, they become part of the compiler invocation for plfreetype.c. I have attached the tarball for your reference.

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.

Re: [Plplot-devel] NAG whitespace issues

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, May 24, 2016 12:44 PM
> To: Arjen Markus
> Cc: Phil Rosenberg; plp...@li...
> Subject: NAG whitespace issues
>
> On 2016-05-24 09:32-0000 Arjen Markus wrote:
>
> > I should perhaps have added that I had to get around a somewhat
> similar problem with a directory containing an installation of GTK - how CMake
> determined that it is there, I have no clue, but the directory is
>
> > d:\nag\efbuilder 6.1\gtk
>
> > which is nowhere near the directories normally searched by CMake as
> far as I know. By renaming that directory I solved the problem that CMake included
> directories like "6.1\gtk\include" in the build procedure.
>
> Hi Arjen:
>
> I am virtually positive this build system problem is due to the whitespace before the
> 6.1 since you report CMake is looking for a directory that starts right after that
> whitespace which, of course, is a mistake.  Probably the only way out of it for now
> is renaming as you have done.  But I do plan to make the experiment later in this
> release cycle of using source, build, and install tree with whitespace in the names to
> see how many of the problems that result from that I can address by judicious use
> of quotes.  Let me know the exact CMake variable where "d:\nag\efbuilder 6.1\gtk"
> is being broken up at the whitespace, and I might be able to fix that issue with
> quotes as well.
>
Yes, I will do that, but the thing that surprised me is that CMake finds this directory at all! It may be something it finds in the registry, but the directory itself has nothing to do with the MS Visual Studio toolchain nor is it a directory that has an obvious connection to GTK (unless you descend deep enough).

Of course, the whitespace issue is a more pervasive one - it has given much more grief over the years than any benefits I can think.

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.

[Plplot-devel] NAG whitespace issues

[Alan W. I. <ir...@be...>]

On 2016-05-24 09:32-0000 Arjen Markus wrote:

> I should perhaps have added that I had to get around a somewhat
similar problem with a directory containing an installation of GTK –
how CMake determined that it is there, I have no clue, but the
directory is

> d:\nag\efbuilder 6.1\gtk

> which is nowhere near the directories normally searched by CMake as
far as I know. By renaming that directory I solved the problem that
CMake included directories like “6.1\gtk\include” in the build
procedure.

Hi Arjen:

I am virtually positive this build system problem is due to the
whitespace before the 6.1 since you report CMake is looking for a
directory that starts right after that whitespace which, of course, is
a mistake.  Probably the only way out of it for now is renaming as you
have done.  But I do plan to make the experiment later in this release
cycle of using source, build, and install tree with whitespace in the
names to see how many of the problems that result from that I can
address by judicious use of quotes.  Let me know the exact CMake
variable where "d:\nag\efbuilder 6.1\gtk" is being broken up at the
whitespace, and I might be able to fix that issue with quotes as well.

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
__________________________

Re: [Plplot-devel] Distinction between 32-bits and 64-bits libraries

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

Hi Phil,



I should perhaps have added that I had to get around a somewhat similar problem with a directory containing an installation of GTK – how CMake determined that it is there, I have no clue, but the directory is



d:\nag\efbuilder 6.1\gtk



which is nowhere near the directories normally searched by CMake as far as I know. By renaming that directory I solved the problem that CMake included directories like “6.1\gtk\include” in the build procedure.



Regards,



Arjen



From: Arjen Markus [mailto:Arj...@de...]
Sent: Tuesday, May 24, 2016 10:23 AM
To: Phil Rosenberg; plp...@li...
Subject: Re: [Plplot-devel] Distinction between 32-bits and 64-bits libraries


Hi Phil,



Yes, life is much easier if you can stick to just one bit size. I try to be consistent and install only 64 bits stuff, but in this case I reverted to the 32-bits version of the compiler to see if the linkage problem was caused by using 64 bits rather than 32 bits. The problem I described made that diagnostic null and void. But I realised that this may be a more general problem.



Regards,



Arjen



From: Phil Rosenberg [mailto:p.d...@gm...]
Sent: Tuesday, May 24, 2016 10:19 AM
To: Arjen Markus; plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] Distinction between 32-bits and 64-bits libraries

Hi Arjen
I see the same problem. 64 bit windows, 64 bit tcl, linking fails in visual studio for 32 bit builds.

This is the only library I see this problem with, but I think I built all other dependencies myself, whereas I installed tcl with its installer.

My solution is that I have just stopped doing 32 bit builds, but I appreciate there are still a few 32 bit windows installs around that you may need to compile for. For a while I persisted with a separate 32 bit cmake call, which I needed to do anyway to pull in the correct wxWidgets library. I just disabled tcl in that build.

Phil
________________________________
From: Arjen Markus<mailto:Arj...@de...>
Sent: ‎24/‎05/‎2016 07:48
To: plp...@li...<mailto:plp...@li...>
Subject: [Plplot-devel] Distinction between 32-bits and 64-bits libraries

Hello,



Yesterday, while trying to solve an issue with the Tcl binding under bare Windows, I came across the following problem:

-        I have a 64-bits Tcl version installed

-        I use the 32-bits compiler environment (MS Visual Studio, set for 32 bits)

-        CMake finds the Tcl libraries and arranges for the Tcl bindings to be built

-        The build subsequently fails because the import library that is used (64-bits) is not suitable for the compilation and linking (32-bits)



I presume similar things may happen with other external dependencies that come in different varieties. Should we guard against this happening or not? I have no idea how difficult it is to implement that.



For now, I suggest we warn about the possibility of this confusion in the documentation.



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.
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.

Re: [Plplot-devel] Distinction between 32-bits and 64-bits libraries

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

Hi Phil,



Yes, life is much easier if you can stick to just one bit size. I try to be consistent and install only 64 bits stuff, but in this case I reverted to the 32-bits version of the compiler to see if the linkage problem was caused by using 64 bits rather than 32 bits. The problem I described made that diagnostic null and void. But I realised that this may be a more general problem.



Regards,



Arjen



From: Phil Rosenberg [mailto:p.d...@gm...]
Sent: Tuesday, May 24, 2016 10:19 AM
To: Arjen Markus; plp...@li...
Subject: RE: [Plplot-devel] Distinction between 32-bits and 64-bits libraries

Hi Arjen
I see the same problem. 64 bit windows, 64 bit tcl, linking fails in visual studio for 32 bit builds.

This is the only library I see this problem with, but I think I built all other dependencies myself, whereas I installed tcl with its installer.

My solution is that I have just stopped doing 32 bit builds, but I appreciate there are still a few 32 bit windows installs around that you may need to compile for. For a while I persisted with a separate 32 bit cmake call, which I needed to do anyway to pull in the correct wxWidgets library. I just disabled tcl in that build.

Phil
________________________________
From: Arjen Markus<mailto:Arj...@de...>
Sent: ‎24/‎05/‎2016 07:48
To: plp...@li...<mailto:plp...@li...>
Subject: [Plplot-devel] Distinction between 32-bits and 64-bits libraries

Hello,



Yesterday, while trying to solve an issue with the Tcl binding under bare Windows, I came across the following problem:

-        I have a 64-bits Tcl version installed

-        I use the 32-bits compiler environment (MS Visual Studio, set for 32 bits)

-        CMake finds the Tcl libraries and arranges for the Tcl bindings to be built

-        The build subsequently fails because the import library that is used (64-bits) is not suitable for the compilation and linking (32-bits)



I presume similar things may happen with other external dependencies that come in different varieties. Should we guard against this happening or not? I have no idea how difficult it is to implement that.



For now, I suggest we warn about the possibility of this confusion in the documentation.



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.
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.

Re: [Plplot-devel] Distinction between 32-bits and 64-bits libraries

[Phil R. <p.d...@gm...>]

Hi Arjen
I see the same problem. 64 bit windows, 64 bit tcl, linking fails in visual studio for 32 bit builds.

This is the only library I see this problem with, but I think I built all other dependencies myself, whereas I installed tcl with its installer.

My solution is that I have just stopped doing 32 bit builds, but I appreciate there are still a few 32 bit windows installs around that you may need to compile for. For a while I persisted with a separate 32 bit cmake call, which I needed to do anyway to pull in the correct wxWidgets library. I just disabled tcl in that build.

Phil

-----Original Message-----
From: "Arjen Markus" <Arj...@de...>
Sent: ‎24/‎05/‎2016 07:48
To: "plp...@li..." <plp...@li...>
Subject: [Plplot-devel] Distinction between 32-bits and 64-bits libraries

Hello,
 
Yesterday, while trying to solve an issue with the Tcl binding under bare Windows, I came across the following problem:
-        I have a 64-bits Tcl version installed
-        I use the 32-bits compiler environment (MS Visual Studio, set for 32 bits)
-        CMake finds the Tcl libraries and arranges for the Tcl bindings to be built
-        The build subsequently fails because the import library that is used (64-bits) is not suitable for the compilation and linking (32-bits)
 
I presume similar things may happen with other external dependencies that come in different varieties. Should we guard against this happening or not? I have no idea how difficult it is to implement that.
 
For now, I suggest we warn about the possibility of this confusion in the documentation.
 
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. 

[Plplot-devel] Distinction between 32-bits and 64-bits libraries

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

Hello,



Yesterday, while trying to solve an issue with the Tcl binding under bare Windows, I came across the following problem:

-        I have a 64-bits Tcl version installed

-        I use the 32-bits compiler environment (MS Visual Studio, set for 32 bits)

-        CMake finds the Tcl libraries and arranges for the Tcl bindings to be built

-        The build subsequently fails because the import library that is used (64-bits) is not suitable for the compilation and linking (32-bits)



I presume similar things may happen with other external dependencies that come in different varieties. Should we guard against this happening or not? I have no idea how difficult it is to implement that.



For now, I suggest we warn about the possibility of this confusion in the documentation.



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.

[Plplot-devel] Freeze date for substantial changes to master still not settled for current release cycle

[Alan W. I. <ir...@be...>]

That freeze date is at least a month away because I am currently
bogged down in a series of substantial updates to the documentation;
there are several more substantial changes on my agenda for this
release cycle after that documentation effort is completed; and Arjen
is currently working on another substantial change which is to adapt
our new Fortran binding and examples so they work with the NAG Fortran
compiler.  (That compiler is noted for being persnickety about
standards compliance so once we can build our new Fortran binding and
examples with that compiler, there is a much-improved chance that we
will be compatible with additional Fortran compilers beyond the NAG
compiler and our current tested list of the ifort and gfortran
compilers.)

In sum, there continues to be a window of opportunity for PLplot
developers (in addition to Arjen and me) to mature their favorite
topic branches to the point where they can be pushed to the SF
repository master branch and can be made part of the forthcoming
release.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Working with the NAG compiler

[Chris M. <dev...@gm...>]

As a user, I loved the ABBS since for unix-ish systems it would largely 
"just work".

However, there are two problems that I consistently ran into:
* autotools doesn't work on windows due to unix-ish requirements
* I could never understand autotools enough to use them myself

 From that point of view, Cmake is young but clean. Initially, it was 
awkward to run but things are getting better. In my experience, the main 
issues now are of maturity in that when cmake doesn't correctly detect 
things then often the build breaks and it is up to the end-user (not 
necessarily a guru) to figure out the mystical arguments to make things 
work.

It is informative that you can use VERBOSE=1 to debug the problem 
oneself (I'll have to give that a try) but it is even better if the 
build process had clear diagnostics on what exactly the failure is and 
how to fix the problem as a package builder/consumer.

In addition, there is the usual confusion of build processes for cygwin 
platforms but since the cmake process is compiler specific, the correct 
use for windows vs cygwin is a matter of the build scripts and not the 
fault of cmake.

--Chris

On 5/13/2016 18:28, Alan W. Irwin wrote:
> On 2016-05-13 12:58-0700 Alan W. Irwin wrote:
>
>> To summarize, your suggestion to move back to an ABBS has fallen on
>> somewhat stony soil.  :-) The reason for that is we had a chance to do
>> a head-to-head comparison between a new CBBS that had been developed
>> for a month or so and an ABBS alternative that had been developed for
>> many years, and there was absolutely no contest.  So I would
>> encourage you to give CMake a second chance especially now that you
>> know about that VERBOSE=1 option.  :-)
> More general points concerning PLplot and CMake.  Since 2006, the
> open-source (OSI-approved BSD 3-clause License) CMake code that is
> written in C++ has attracted a large band of volunteer developers who
> are lead by CMake code gurus from KitWare such as Brad King.  As a
> result there has been extremely strong development of CMake in the
> last decade.
>
> All this development of CMake itself has occurred in a way that was
> backwards compatible for the CMake-2 series of releases.  Some
> well-publicized backwards incompatiblities (most of which had long
> been deprecated) were introduced for CMake-3 which was a substantial
> rewrite of CMake-2.  The series of CMake-3 releases has also been
> backwards compatible within the series.  So that is a great boon to a
> mature project that is not being actively developed because that
> project's build system "just works" regardless of CMake-3 version.
>
> That said, the early releases of the CMake-3 had a number of bugs
> introduced by that rewrite that had to be flushed out by user testing
> so I strongly recommend using the highest version possible of CMake-3
> (currently 3.5.2 which works fine for me on Linux).  Also, I continue
> to develop the PLplot CBBS to support any new directions that PLplot
> development takes and to make our build system easier to maintain.
>
> With regard to that maintainability point, I try to replace use of
> CMake features that have become officially deprecated or which are
> advertised as problematic in the CMake-3 series with improved CMake-3
> logic that has become available.  However, I do that in a conservative
> way so that our build system continues to work for CMake-3.0.2.  That
> is the minimum CMake version we allow on Linux to support such
> distributions as Debian jessie where 3.0.2 is the latest version of
> CMake that is available.  (Note, the minimum version of CMake I have
> adopted for all non-Linux operating systems is currently 3.3.2, but
> that will likely get bumped just as soon as both the Cygwin and
> MinGW-w64/MSYS2 distributions provide a binary package for a later
> version of CMake.
>
> To summarize, I have pretty much become the "CMake guru" for this
> project, but it is not that much of a burden so I feel confident that
> when I retire from PLplot someone else will be able to continue
> developing our CBBS without many issues with the same motivations as
> above (support new PLplot development and improve maintainability of
> our CBBS). Or if some keener wants to try some other build system that
> does not interfere with our CBBS, I will probably be too invested in
> our CBBS to help with development of that additional build system, but
> I do intend to follow Rafael's good example, and challenge that person
> to "show me the code" since sometimes great things (such as our
> present CBBS) happen as a result of such challenges.
>
> 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
> __________________________
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Working with the NAG compiler

[Alan W. I. <ir...@be...>]

On 2016-05-13 12:58-0700 Alan W. Irwin wrote:

> To summarize, your suggestion to move back to an ABBS has fallen on
> somewhat stony soil.  :-) The reason for that is we had a chance to do
> a head-to-head comparison between a new CBBS that had been developed
> for a month or so and an ABBS alternative that had been developed for
> many years, and there was absolutely no contest.  So I would
> encourage you to give CMake a second chance especially now that you
> know about that VERBOSE=1 option.  :-)

More general points concerning PLplot and CMake.  Since 2006, the
open-source (OSI-approved BSD 3-clause License) CMake code that is
written in C++ has attracted a large band of volunteer developers who
are lead by CMake code gurus from KitWare such as Brad King.  As a
result there has been extremely strong development of CMake in the
last decade.

All this development of CMake itself has occurred in a way that was
backwards compatible for the CMake-2 series of releases.  Some
well-publicized backwards incompatiblities (most of which had long
been deprecated) were introduced for CMake-3 which was a substantial
rewrite of CMake-2.  The series of CMake-3 releases has also been
backwards compatible within the series.  So that is a great boon to a
mature project that is not being actively developed because that
project's build system "just works" regardless of CMake-3 version.

That said, the early releases of the CMake-3 had a number of bugs
introduced by that rewrite that had to be flushed out by user testing
so I strongly recommend using the highest version possible of CMake-3
(currently 3.5.2 which works fine for me on Linux).  Also, I continue
to develop the PLplot CBBS to support any new directions that PLplot
development takes and to make our build system easier to maintain.

With regard to that maintainability point, I try to replace use of
CMake features that have become officially deprecated or which are
advertised as problematic in the CMake-3 series with improved CMake-3
logic that has become available.  However, I do that in a conservative
way so that our build system continues to work for CMake-3.0.2.  That
is the minimum CMake version we allow on Linux to support such
distributions as Debian jessie where 3.0.2 is the latest version of
CMake that is available.  (Note, the minimum version of CMake I have
adopted for all non-Linux operating systems is currently 3.3.2, but
that will likely get bumped just as soon as both the Cygwin and
MinGW-w64/MSYS2 distributions provide a binary package for a later
version of CMake.

To summarize, I have pretty much become the "CMake guru" for this
project, but it is not that much of a burden so I feel confident that
when I retire from PLplot someone else will be able to continue
developing our CBBS without many issues with the same motivations as
above (support new PLplot development and improve maintainability of
our CBBS). Or if some keener wants to try some other build system that
does not interfere with our CBBS, I will probably be too invested in
our CBBS to help with development of that additional build system, but
I do intend to follow Rafael's good example, and challenge that person
to "show me the code" since sometimes great things (such as our
present CBBS) happen as a result of such challenges.

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
__________________________

Re: [Plplot-devel] Working with the NAG compiler

[Alan W. I. <ir...@be...>]

On 2016-05-13 09:10-0000 Wadud Miah wrote:

> I honestly really despise CMake as it hides so many important flags.
I know Autools has been around for some time, but I don't think there
is anything wrong with it. I find it highly flexible, configurable and
easy to use. If you could move PLplot to Autotools, that would be a
big win :-)

Hi Wadud:

I have to respond to your above negative reaction to CMake, but I will
try to be gentle.  :-) Also, I have decided to answer you on list
because there is some background material here that some of our newer
developers might not be aware of.

To answer your specific concern and to also to publicize this
extremely useful option for all developers on this list, CMake does
hide information by default, but it is straightforward to obtain all
flags that are used (at least for the "Unix Makefiles" generator that
is default on Unix systems) by using the the VERBOSE=1 option on make,
e.g.,

make VERBOSE=1 all

when CMake is used to configure those Unix Makefiles. So the next time
you are frustrated by cmake results that seem hidden from you, try
that make option to see _exactly_ what is going on.

Here is the longer story of our conversion from an autotools-based
build system (ABBS) to a CMake-based build system (CBBS).

I was the second-most active maintainer of our ABBS a decade ago, and
at that time I was willing to struggle indefinitely with its many
problems (e.g., different languages for different components of the
system, very slow to configure and build, lots of cross-platform
issues, and lots of consistency issues every time there was a new
autotools release). However, I then read an article about KDE's
conversion from autotools to CMake (motivated by all those autotools
issues I mentioned above). That article demonstrated how the KDE
developers all quickly fell in love with their new CBBS once they got
a chance to play with it.

So I started speculating on this mailing list about what might be
possible with a CBBS for PLplot, and Rafael (Rafael Laboissiere was
our chief Autotools guru) challenged me to "show him the code". I
decided to give CMake a try myself for one minor PLplot library just
as a proof-of-concept, and it was amazingly easy and fast compared to
Autotools.  IIRC, it took me only a few hours to understand the CMake
syntax starting from scratch and implement that proof of concept.  And
the nice thing is that CBBS and ABBS can coexist (with some care about
naming the supporting *.in configuration template files) so I could
commit that working proof of concept CBBS without disrupting our ABBS.
I then followed up in the next few weeks (with help especially from
Arjen, Werner, and Andrew who were all enthusiastic about the
potential of a CBBS) with adding the remaining PLplot components
existing at that time to our CBBS.

Understandably (since he had so much invested in our ABBS) Rafael was
not willing to help develop that CBBS, but to his credit he did not
blight my initial ideas by saying something like "I will never support
that or go along with that". Instead, Rafael (rightly) got tired of
the speculation about what _might_ be possible with CMake and
challenged me to "show him the code". So I did, the advantages were
immediately obvious to the rest of our developers, and within a year
after that first proof of concept we were dropping our ABBS because
Rafael did not have time/energy to keep up with what was possible with
our CBBS.  Of course, since then our CBBS has developed very far
beyond what was possible with our ABBS a decade ago before we
abandoned the ABBS approach.

Of course, before 2006 or so virtually every open-source project had
an ABBS and most still do because of inertia.  That inertia is
completely understanable since it is certainly a non-trivial amount of
work to convert from an ABBS to a CBBS.  Thus, if some Autotools guru
is willing to do all that work necessary to support an ABBS, more
power to him.  But if cannot keep up with existing development or if
developers are tired of issues with their ABBS, then they should
consider implementing a CBBS.  When they do make that large
investment, they will be rarely disappointed since their new build
system will typically be faster, will be much more powerful and
flexible, will have better cross-platform support, and will be easier
to maintain than the equivalent ABBS.

To summarize, your suggestion to move back to an ABBS has fallen on
somewhat stony soil.  :-) The reason for that is we had a chance to do
a head-to-head comparison between a new CBBS that had been developed
for a month or so and an ABBS alternative that had been developed for
many years, and there was absolutely no contest.  So I would
encourage you to give CMake a second chance especially now that you
know about that VERBOSE=1 option.  :-)

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
__________________________

Re: [Plplot-devel] Avoiding untyped variables in our Fortran binding and examples

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, May 12, 2016 11:30 AM
> Thanks for clearing up that nomenclature.  It appears then, that the ifort and NAG
> fortran compiler options I found concerned the wrong problem (undefined variable).
> What we need instead is a check of our Fortran binding and Fortran examples code
> for any variable without an explicit declaration, i.e., the easier problem.  Presumably,
> if you put "implicit none" in all the right places, it should detect any such issues, but
> finding all those right places strikes me as an error-prone process so to double-
> check that I hope you are able to find and use a compiler option to check for
> variables that are not explicitly declared for either the ifort or NAG Fortran compilers.
> As far as I can tell, gfortran does not have such an option.
>
For Intel Fortran the option is /warn:declarations (on Windows) or -warn:declaration (on Linux/OSX). Gfortran does have such an option: -Wimplicit, but I guess -Wall will enable it as well. According to the documentation the NAG compiler uses the option -u for this. (Key to these morsels of wisdom: "implicit"). So this issue is indeed covered.

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.

Re: [Plplot-devel] Avoiding untyped variables in our Fortran binding and examples

[Alan W. I. <ir...@be...>]

On 2016-05-12 06:34-0000 Arjen Markus wrote:

[...]
> My intention is to add IMPLICIT NONE anywhere where this is required:
>
> - At the beginning of a module, but not in the contained routines, as they inherit that feature (the module provides the scope)
>
> - At the beginning of a subroutine or function statement inside an interface block, as the interface defines a new scope. These new scopes also make it necessary to import any names used inside the interface. See the problem Wadud reported.
>
> So, all in all, a number of IMPLICIT NONE statements and one or two imports have to be added, but they will not clutter then CONTAINS section.

OK.  Sounds good.

> As for undefined variables: Fortran "standardese" distinguishes
between declarations (affected by IMPLICIT statements) and definitions
(variables having been assigned a value or not). Simply put: An
undefined variable has no reliable value. This can occur in various
contexts, but really is a run-time property. A variable that is not
explicitly declared can be detected at compile-time. Most compilers
have some option to detect that. Detecting undefinedness is much
harder.

Thanks for clearing up that nomenclature.  It appears then, that the
ifort and NAG fortran compiler options I found concerned the wrong
problem (undefined variable).  What we need instead is a check of our
Fortran binding and Fortran examples code for any variable without an
explicit declaration, i.e., the easier problem.  Presumably, if you
put "implicit none" in all the right places, it should detect any such
issues, but finding all those right places strikes me as an
error-prone process so to double-check that I hope you are able to
find and use a compiler option to check for variables that are not
explicitly declared for either the ifort or NAG Fortran compilers.  As
far as I can tell, gfortran does not have such an option.

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
__________________________

Re: [Plplot-devel] Avoiding untyped variables in our Fortran binding and examples

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

Hi Alan,



NOTE: What follows is rather specific to the Fortran language and has little to do with PLplot as such, other than that has some consequences for our Fortran binding and possibly the examples.

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, May 11, 2016 7:51 PM
> To: Arjen Markus
> Cc: Wadud Miah; plp...@li...
> Subject: Re: Avoiding untyped variables in our Fortran binding and examples
>
> P.S.
>
> Hi Arjen:
>
> From
> <https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-
> windows/topic/346554>
> it appears that you should use the /check:uninit option with the ifort compiler to
> detect undefined variables.
>
> I also see from <http://www.nag.com/nagware/np/r53_doc/nagfor.html> that that
> compiler has a -C=undefined option to check for undefined variables.
>
> Note, I am not sure of the exact meaning of "undefined variable" in these two
> references.  My hope is it simply means "undefined type", i.e., implicit declaration,
> but I am not sure.  For example, some use the term "undefined variable" when they
> really mean that a properly typed variable is uninitialized.  And, of course, an
> uninitialized variable is much more difficult to detect than an undefined type.
>
My intention is to add IMPLICIT NONE anywhere where this is required:

- At the beginning of a module, but not in the contained routines, as they inherit that feature (the module provides the scope)

- At the beginning of a subroutine or function statement inside an interface block, as the interface defines a new scope. These new scopes also make it necessary to import any names used inside the interface. See the problem Wadud reported.

So, all in all, a number of IMPLICIT NONE statements and one or two imports have to be added, but they will not clutter then CONTAINS section.

As for undefined variables: Fortran "standardese" distinguishes between declarations (affected by IMPLICIT statements) and definitions (variables having been assigned a value or not). Simply put: An undefined variable has no reliable value. This can occur in various contexts, but really is a run-time property. A variable that is not explicitly declared can be detected at compile-time. Most compilers have some option to detect that. Detecting undefinedness is much harder.

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.

Re: [Plplot-devel] Avoiding untyped variables in our Fortran binding and examples

[Alan W. I. <ir...@be...>]

P.S.

Hi Arjen:

From
<https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/346554>
it appears that you should use the /check:uninit option with the ifort
compiler to detect undefined variables.

I also see from <http://www.nag.com/nagware/np/r53_doc/nagfor.html> that
that compiler has a -C=undefined option to check for undefined
variables.

Note, I am not sure of the exact meaning of "undefined variable" in
these two references.  My hope is it simply means "undefined type",
i.e., implicit declaration, but I am not sure.  For example, some use
the term "undefined variable" when they really mean that a properly
typed variable is uninitialized.  And, of course, an uninitialized
variable is much more difficult to detect than an undefined type.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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

Linux-powered Science
__________________________

[Plplot-devel] Avoiding untyped variables in our Fortran binding and examples

[Alan W. I. <ir...@be...>]

On 2016-05-11 09:42-0000 Arjen Markus wrote:

> I was also reminded of a small omission in the current code
regarding the use of IMPLICIT NONE. It is not propagated from the
module to the interface blocks. Therefore I want to add that statement
everywhere where that is appropriate, just to make extra sure that no
argument has been left implicitly declared.

Hi Arjen:

If you are aware of any interface blocks that do not have an "implicit
none" statement please go ahead and make that change.  However, I
would not want to see you add "implicit none" statements
to all our ordinary functions and subroutines that are defined after
the "contains" statement since those are unnecessary.

In other words, we currently follow the style that implicit none is
needed at the start of every module and also in all interface blocks
but nowhere else. This style should be sufficient to insure there are
no implicit declarations (i.e., untyped variables) left in our code according to
<http://stackoverflow.com/questions/24337413/where-to-put-implicit-none-in-fortran>.
Previously, I eliminated the "implicit none" statements not required
by this rule on the principle that "if it is not needed don't use it",
and I also wanted to see a uniform style. (Previously some of those
unneeded "implicit none" statements were included in our code, but not
in all cases.)

Of course, our principal concern here is not one of style, but instead
we just want to confirm there are no untyped variables left in our
code.  The "implicit none" statement checks for such variables, but
you need a lot of those statements (even with the above style) to get
the job done, and it is easy to miss, say, one interface block, and if
you are really unlucky, it will be that interface block that will have
some untyped variables.

The gfortran compiler used to have an option called -Wimplicit which
is currently described in the man page (and info pages) as follows:

"You can request many specific warnings with options beginning -W, for
example -Wimplicit to request warnings on implicit declarations."

So that looked like a good option to check for untyped variables in
our code, but unfortunately that turns out to be a historical note
they haven't removed yet, and the detailed description of the gfortran
options no longer includes -Wimplicit, and I also just confirmed that
gfortran no longer accepts that option.

Do any of the Fortran compilers accessible to you have an option to
check for any untyped variables = implicit declarations left in our
code?  If so, please use that option to check our code.

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
__________________________

Re: [Plplot-devel] PLplot Fortran bindings

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

Hi Wadud,



I guess at this moment it is my turn - I was also reminded of a small omission in the current code regarding the use of IMPLICIT NONE. It is not propagated from the module to the interface blocks. Therefore I want to add that statement everywhere where that is appropriate, just to make extra sure that no argument has been left implicitly declared.



The next interesting bit is to get the examples to pass with the NAG compiler and for that I will gladly accept your offer :).



Regards,



Arjen



From: Wadud Miah [mailto:wad...@na...]
Sent: Tuesday, May 10, 2016 5:06 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

Ah, yes, I see the subroutine being passed as an argument - I totally missed that. So what would you exactly like me to do  now? I was wondering whether you would like a trial version of the NAG Fortran compiler which may make it easier :-) Let me know if you would like a NAG Fortran trial licence and I can arrange one for you.

Best regards,
Wadud.

From: Arjen Markus [mailto:Arj...@de...]
Sent: 10 May 2016 15:41
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,



Well, actually it is: look at lines 3441-3487 for instance:

The label fill() is associated with c_plfill (line 3480) and then that label is passed as an argument to interface_plshade (line 3499). The label interface_plfill() is used as a direct call at line 1518.



I am positive that this will work, but that is what the tests/examples are there for. I imagine that the NAG compiler may find one or two issues in that code as well, so I would like to suggest you to have the examples built too:



cmake ... -DBUILD_TEST=ON



Regards,



Arjen


From: Wadud Miah [mailto:wad...@na...]
Sent: Tuesday, May 10, 2016 4:07 PM
To: Arjen Markus; Alan W. Irwin
Cc: plp...@li...<mailto:plp...@li...>
Subject: RE: [Plplot-devel] PLplot Fortran bindings

Hi Arjen,

I wasn't suggesting removing the c_plfill C function - I meant that its interface should be removed as it is not being called. The NAG compiler is complaining about the multiple binding labels "c_plfill". This may seem valid, but if the fill() subroutine is not being called at all, I don't see the need to declare interfaces to it.

If I change the binding label of interface_plfill to "fill", the NAG compiler does accept it, but will that call the C fill() function?

Regards,
Wadud.

From: Arjen Markus [mailto:Arj...@de...]
Sent: 10 May 2016 14:36
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,



Well, the first answer (by Wolfgang Kilian - https://groups.google.com/forum/?hl=nl#!topic/comp.lang.fortran/-NYIZX-XZag) to my post does support NAG's view. Unless there are strongly opposing replies, I think the best way forward is to apply the workaround.



The fill() problem you mention is of a different order. In its current form it uses two different labels for the same C routine, but the fill routine is actually used, so we cannot simply eliminate it. (You have to look carefully though to see where and how ;)). I can see two ways forward:

-       Use the same label consistently, either will do. This is only a small change in the source code.

-       Use one interface block for c_plfill - right now the block is repeated a number of times, mainly to keep these things as local as possible. (I am not entirely sure if we can prevent "leakage" of the C names, if we do that. I think that was the background for this set-up.)



If you change the label interface_plfill to fill (or vice versa, that is more inline with the rest of the naming scheme), is the code accepted by the NAG compiler? If so, I will apply that to the repository. I will be busy the next few days, but I will try to incorporate it and do the testing.



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.