#45 Some Fortran binding matters since 5.12

[DrO]

1) Upgraded to 5.14 from 5.11 using GCC 7.2 and CMake 3.13.2 on Win 64 MingW. Build worked. Thought you would like to know given the ReadMe comments Re CMake 3.11 etc.

2) Have attached a "cheap & cheerful" conversion of example 32 ("candle stick/whiskers") to Fortran (for some reason that did not exist on line or in the supplied examples). Tested and works on Win 64/gFortran 7.2

3) Had a look at the newer Fortran interfaces, happy to see the changes, especially now the use of "Intent". This would make it a relatively easy step to make most s/r's Pure or Elemental as appropriate. That has certain advantages, which I can detail another time.

Pure/Elemental can't have Write I/O statements. So the current "error" IO would be an issue.

HOWEVER, it did not seem obvious how the error reporting would work in GUI or DLL environments, where there is no "console" output.

==>>In that case, a pure IO error report is NOT seen by anyone, and no way to know that some action is required.

A superior solution would be to have one or two additional Intent(Out) Args: an Integer reporting the "error code" (and which can then be checked easily programmatically to see if the calling s/r should take some action. Another Arg might be a string that returns the error message itself.

Each of these can be created as Optional Arg's, so that existing code can avoid huge re-write.

[Alan W. Irwin]

Thanks for your interest in our Fortran binding and examples. Some responses to your comments below:

Thought you would like to know given the ReadMe comments Re CMake 3.11 etc.

Contrary to what I said (sigh) in README.release our minimum version of CMake is 3.7.2 for Linux platforms and 3.11.0 for non-Linux platforms. But I also said (correctly) there that
we had tested up to 3.13.1 and believed the build system would continue to work substantially beyond that version because of good CMake backwards compatiiity. So we very much appreciate your report that CMake-3.13.2 is working for you consistent with what we said.
Is your good report for the classical MinGW or its successor MinGW-w64 that is developed by a completely independent group? We have tested the combination of MinGW-w64/MSYS2 extensively but not MinGW-w64 or MinGW alone since those platforms have very limited support for optional (from the PLplot perspective) free software libraries that give PLplot a lot of its power.

Have attached a "cheap & cheerful" conversion of example 32

Thanks for that contribution. We will make use of it if we ever make the decision to propagate C example 32 to the rest of our supported language examples.

This would make it a relatively easy step to make most s/r's Pure or Elemental as appropriate.

Such a change would be useful. We will think more about that possibility in conjunction with your suggestion of optional arguments for error code and error string which are likely a good idea in their own right regardless of the Pure or Elemental attribute. Would you consider subscribing to the plplot-devel mailing list to discuss this some more? We far prefer mailing list discussion to the rather limited editing capabilities we have here.

[DrO]

Cheers for that

1) I only added the CMake remarks on account of the PlPlot interest to be
informed of experiences with "higher tested versions".

2) Yes, MinGW is a bit dated, but we really really hate MSys2 for a large
number of reasons, so we stick with MingW ... at least it's all working.

3) Re Pure/Elemental: I was a bit daft when I wrote that (it was really
late :-), and forgot to include the obvious alternative of including those
error return Args via overloaded complimentary functions. In hind sight,
that may make more sense compared to "Optional" in some cases.

Regarding your "mailing list discussion" preference: I recall we made an
attempt at that some time ago, but can't remember why it failed. If you
have some instructions, we might be able to try again :-), but we do have a
rather robust policy regarding internet security, so can't promise it will
pass that.

DrO

-----Original Message-----
From: Alan W. Irwin [mailto:airwin@users.sourceforge.net]
Sent: 21 December 2018 16:43
To: [plplot:support-requests]
Subject: [plplot:support-requests] #45 Some Fortran binding matters since
5.12

Thanks for your interest in our Fortran binding and examples. Some responses
to your comments below:

Thought you would like to know given the ReadMe comments Re CMake 3.11 etc.

Contrary to what I said (sigh) in README.release our minimum version of
CMake is 3.7.2 for Linux platforms and 3.11.0 for non-Linux platforms. But I
also said (correctly) there that
we had tested up to 3.13.1 and believed the build system would continue to
work substantially beyond that version because of good CMake backwards
compatiiity. So we very much appreciate your report that CMake-3.13.2 is
working for you consistent with what we said.
Is your good report for the classical MinGW or its successor MinGW-w64 that
is developed by a completely independent group? We have tested the
combination of MinGW-w64/MSYS2 extensively but not MinGW-w64 or MinGW alone
since those platforms have very limited support for optional (from the
PLplot perspective) free software libraries that give PLplot a lot of its
power.

Have attached a "cheap & cheerful" conversion of example 32

Thanks for that contribution. We will make use of it if we ever make the
decision to propagate C example 32 to the rest of our supported language
examples.

This would make it a relatively easy step to make most s/r's Pure or
Elemental as appropriate.

Such a change would be useful. We will think more about that possibility in
conjunction with your suggestion of optional arguments for error code and
error string which are likely a good idea in their own right regardless of
the Pure or Elemental attribute. Would you consider subscribing to the
plplot-devel mailing list to discuss this some more? We far prefer mailing
list discussion to the rather limited editing capabilities we have here.

---

[support-requests:#45]
https://sourceforge.net/p/plplot/support-requests/45/ Some Fortran
binding matters since 5.12

Status: open
Group:
Created: Fri Dec 21, 2018 11:34 AM UTC by DrO
Last Updated: Fri Dec 21, 2018 11:34 AM UTC
Owner: nobody
Attachments:

• x32f.f90
  https://sourceforge.net/p/plplot/support-requests/45/attachment/x32f.f90
  (7.9 kB; application/octet-stream)

1) Upgraded to 5.14 from 5.11 using GCC 7.2 and CMake 3.13.2 on Win 64
MingW. Build worked. Thought you would like to know given the ReadMe
comments Re CMake 3.11 etc.

2) Have attached a "cheap & cheerful" conversion of example 32 ("candle
stick/whiskers") to Fortran (for some reason that did not exist on line or
in the supplied examples). Tested and works on Win 64/gFortran 7.2

3) Had a look at the newer Fortran interfaces, happy to see the changes,
especially now the use of "Intent". This would make it a relatively easy
step to make most s/r's Pure or Elemental as appropriate. That has certain
advantages, which I can detail another time.

Pure/Elemental can't have Write I/O statements. So the current "error" IO
would be an issue.

HOWEVER, it did not seem obvious how the error reporting would work in GUI
or DLL environments, where there is no "console" output.

==>>In that case, a pure IO error report is NOT seen by anyone, and no way
to know that some action is required.

A superior solution would be to have one or two additional Intent(Out) Args:
an Integer reporting the "error code" (and which can then be checked easily
programmatically to see if the calling s/r should take some action. Another
Arg might be a string that returns the error message itself.

Each of these can be created as Optional Arg's, so that existing code can
avoid huge re-write.

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/plplot/support-requests/45/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Alan W. Irwin]

Reclassified as pending because the discussion appears to be stopped.