Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Alan W. Irwin]

On 2018-01-07 11:03- Arjen Markus wrote:


I can now confirm that it [running examples/fortran/x01f built with

local change pl_parse_dynamic = .true.] works for both compilers.

Excellent.  Now that you have confirmed the "_dynamic" versions of
plget_arguments and plparseopts work with modern versions of gfortran
and ifort, I will encourage others with access to other Fortran
compilers to try this test 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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Saturday, January 06, 2018 3:30 AM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: Command-line parsing improvements for both C and Fortran
>
> On 2018-01-05 13:38- Arjen Markus wrote:
>
> [...]
>
> > That [extra printouts of locations reached] limits the possibilities
> considerably ;). I have narrowed it further to the call of 
> max_cstring_length, but of
> course this is merely the location where it is noted something is wrong, not
> necessarily the cause.
>
> Hi Arjen:
>
> Your experiments appear to have nailed exactly where the issue was. So much
> thanks for that work!  As a direct result of that work I discovered I had 
> forgotten an
> essential slice specification in the call to max_cstring_length which I have 
> now fixed
> (commit 70ec495).
> As a result my strong expectation is your next test of Fortran example
> 1 for the allocated length and size case will give perfect results for both 
> modern
> gfortran and ifort

I can now confirm that it works for both compilers. There is a small issue 
though with the gfortran compiler under Cygwin. I do not understand it (*) but 
here is the output to screen if I use the -h option:
$ ./x01f -h
pl_parse_dynamic =  T
argv before call to plparseopts(..., PL_PARSE_SKIP)
i =   0, argument = ./x01f
i =   1, argument = -h
/bin/sh: C:\Program: command not found


This does not happen for Intel Fortran - then I get an overview of all the 
options that are available.

(*) From a closer look at the code I think this is due to the fragment:

#ifdef HAVE_POPEN

FILE *pager = NULL;

if ( getenv( "PAGER" ) != NULL )

pager = (FILE *) popen( "$PAGER", "w" );

if ( pager == NULL )

pager = (FILE *) popen( "more", "w" );

if ( pager != NULL )

outfile = pager;

#endif

It is probably trying to run a pager program like "more" but that does not 
quite work on Cygwin.

BTW, I had to adjust the .def file for Intel Fortran to get it all to build 
correctly. I will submit the changes.

>
> By the way, this fix has nothing to do with the gfortran-4.9.2 issue where the
> allocate length and size command in plget_arguments_dynamic (that already 
> works
> for your modern gfortran and ifort cases) overflows when doing a simple 
> internal
> calculation of the amount of memory needed.  I double-checked with gdb that 
> the
> length and size are properly defined for that allocate command.  Therefore my
> conclusion must be that gfortran-4.9.2 is just plain broken for such allocate
> commands (while your ifort and more modern gfortran are obviously not broken 
> in
> this regard).
>
Pity, that means a newer version is still needed.

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Alan W. Irwin]

On 2018-01-05 08:09- Arjen Markus wrote:


First the C example:

"x01c -dev wingcc" complains that I did not give the value for the -dev option. If I give other 
options like "a b c", I get complaints that these are unknown. If I run "x02c -dev 
wingcc", all works as usual.
$ ./x01c -dev wingcc
Argument missing for -dev option.


Hi Arjen:

I have responded already to your fortran report with a bug fix, but I
respond here also to the above C issue you discovered.

I get a similar error for

examples/c/x01c -dev xwin

but not for the valgrind-clean variant I checked before

examples/c/x01c -dev psc -o test.psc

I have no idea why the former form does not work while the latter form
works perfectly in all regards, but I will definitely look into this
weird difference between these two different parsing results.

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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Alan W. Irwin]

On 2018-01-05 13:38- Arjen Markus wrote:

[...]


That [extra printouts of locations reached] limits the possibilities

considerably ;). I have narrowed it further to the call of
max_cstring_length, but of course this is merely the location where it
is noted something is wrong, not necessarily the cause.

Hi Arjen:

Your experiments appear to have nailed exactly where the issue was. So
much thanks for that work!  As a direct result of that work I
discovered I had forgotten an essential slice specification in the
call to max_cstring_length which I have now fixed (commit 70ec495).
As a result my strong expectation is your next test of Fortran example
1 for the allocated length and size case will give perfect results for
both modern gfortran and ifort.

By the way, this fix has nothing to do with the gfortran-4.9.2 issue
where the allocate length and size command in plget_arguments_dynamic
(that already works for your modern gfortran and ifort cases)
overflows when doing a simple internal calculation of the amount of
memory needed.  I double-checked with gdb that the length and size are
properly defined for that allocate command.  Therefore my conclusion
must be that gfortran-4.9.2 is just plain broken for such allocate
commands (while your ifort and more modern gfortran are obviously not
broken in this regard).

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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Arjen Markus]

Hi Alan,



The crash I reported before occurs somewhere between the call to 
interface_plparseopts(...) and max_cstring_length:


$ ./x01f -dev wingcc
pl_parse_dynamic =  T
argv before call to plparseopts(..., PL_PARSE_SKIP)
i =   0, argument = ./x01f
i =   1, argument = -dev
i =   2, argument = wingcc
In plparse_opts_dynamic
After character_array_to_c
After interface_plparseopts

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:



That limits the possibilities considerably ;). I have narrowed it further to 
the call of max_cstring_length, but of course this is merely the location where 
it is noted something is wrong, not necessarily the cause.

Regards,

Arjen

From: Arjen Markus
Sent: Friday, January 05, 2018 9:10 AM
To: 'Alan W. Irwin'
Cc: PLplot development list
Subject: RE: Command-line parsing improvements for both C and Fortran


Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]

> Furthermore, I would appreciate you following the parsing testing advice in
> README.release section 2.7.2 to discover which parts of this API work for 
> gfortran
> with version > 4.9.2 (e.g., for your Cygwin and MinGW-w64/MSYS2 platforms) as
> well as the ifort compiler you have access to (and possibly the nagfor 
> compiler you
> have arranged access to in the past).
>
> By the way, I am not sure of the correct terminology for character arrays 
> that have
> both length and size allocated.  I refer to them above as "dynamic length and 
> size",
> but I have also seen the term "deferred-length" used for character strings 
> with
> allocated length.
>
I did the tests yesterday and found quite some problems with the dynamic case, 
but also with the C example.

First the C example:

"x01c -dev wingcc" complains that I did not give the value for the -dev option. 
If I give other options like "a b c", I get complaints that these are unknown. 
If I run "x02c -dev wingcc", all works as usual.
$ ./x01c -dev wingcc
Argument missing for -dev option.

Usage:
./x01c [options]

x01c options:
[-pl_parse_skip] [-locate] [-xor] [-font number] [-save filename]

PLplot options:

...

Then the Fortran example:

-With the static-character-length, allocatable array option, all works, 
also for the static-character-length, fixed-size array option. Surprisingly, I 
can specify "-dev wingcc" and the window pops up immediately. This is for both 
gfortran 6.4.0 and Intel Fortran 2015.

-However, with both compilers the deferred-character-length, 
allocatable array option fails miserably. The result is a coredump like the one 
you have seen with the older version of gfortran.

My conclusion therefore is that there is something wrong with the code. I have 
not been able to figure out yet what is wrong - which part, but I will try to 
do so today, using a few strategic print statements to at least find the point 
where things go awry.

(A minor pleasant surprise is that maybe after correction the code will work 
for gfortran 4.x 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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]


> Furthermore, I would appreciate you following the parsing testing advice in
> README.release section 2.7.2 to discover which parts of this API work for 
> gfortran
> with version > 4.9.2 (e.g., for your Cygwin and MinGW-w64/MSYS2 platforms) as
> well as the ifort compiler you have access to (and possibly the nagfor 
> compiler you
> have arranged access to in the past).
>
> By the way, I am not sure of the correct terminology for character arrays 
> that have
> both length and size allocated.  I refer to them above as "dynamic length and 
> size",
> but I have also seen the term "deferred-length" used for character strings 
> with
> allocated length.
>
I did the tests yesterday and found quite some problems with the dynamic case, 
but also with the C example.

First the C example:

"x01c -dev wingcc" complains that I did not give the value for the -dev option. 
If I give other options like "a b c", I get complaints that these are unknown. 
If I run "x02c -dev wingcc", all works as usual.
$ ./x01c -dev wingcc
Argument missing for -dev option.

Usage:
./x01c [options]

x01c options:
[-pl_parse_skip] [-locate] [-xor] [-font number] [-save filename]

PLplot options:

...

Then the Fortran example:

-With the static-character-length, allocatable array option, all works, 
also for the static-character-length, fixed-size array option. Surprisingly, I 
can specify "-dev wingcc" and the window pops up immediately. This is for both 
gfortran 6.4.0 and Intel Fortran 2015.

-However, with both compilers the deferred-character-length, 
allocatable array option fails miserably. The result is a coredump like the one 
you have seen with the older version of gfortran.

My conclusion therefore is that there is something wrong with the code. I have 
not been able to figure out yet what is wrong - which part, but I will try to 
do so today, using a few strategic print statements to at least find the point 
where things go awry.

(A minor pleasant surprise is that maybe after correction the code will work 
for gfortran 4.x 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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Alan W. Irwin]

On 2018-01-03 13:28- Arjen Markus wrote:


-Original Message-
From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]

This commit completes my parsing API changes in bindings/fortran/*.f90 and my
changes to examples/fortran/x01f.f90 to test all of these parsing API's.  I 
would
appreciate your review of my implementation.
Furthermore, I would appreciate you following the parsing testing advice in
README.release section 2.7.2 to discover which parts of this API work for 
gfortran
with version > 4.9.2 (e.g., for your Cygwin and MinGW-w64/MSYS2 platforms) as
well as the ifort compiler you have access to (and possibly the nagfor compiler 
you
have arranged access to in the past).

By the way, I am not sure of the correct terminology for character arrays that 
have
both length and size allocated.  I refer to them above as "dynamic length and 
size",
but I have also seen the term "deferred-length" used for character strings with
allocated length.


Unless I am mistaken the official term is deferred-length.

I have not yet tested this with my compilers, but I have reviewed the 
implementation. I have very few comments about it:

-It is a pity that we cannot disambiguate on the deferred/assumed length alone, but that is 
an issue of the language rules (the type of "assumed-length character string" simply 
encompasses the type of "deferred-length character string". Elaborate workaround might be 
possible, using classes/derived types, but that is not worth the trouble I think).

-If we decide at some point that we need to keep the various implementations, 
then perhaps we could "layer" the versions:

o   The deferred-length variant can call the assumed-length + allocated size 
variant

o   This can in turn call the fixed size variant

It would reduce the amount of code, by a small amount of source lines. But 
again, that may not be worth our while.

I should have time to test the implementation tomorrow. Maybe that will bring 
out more comments ;).


Thanks for your review of the code and your comments above based on
that review.  With regard to the "layering" idea, I would like to keep
the 3 variants completely independent of each other because the
deferred-length + allocated size variant is preferred and the
assumed-length + allocated size and the assumed-length + assumed size
variants are deprecated. Furthermore, I agree the required
disambiguate parameter on the assumed-length + allocated size variant
is a "wart" for that variant, but I don't think we need to be too
concerned about that wart since it is a deprecated variant.

I did look at

and support for "allocatable character length" (what we now
call deferred-length character) is pretty widespread (e.g.,
gfortran-5.2, ifort 17.0, and nagfor 6.1 and above) so I am pretty
sure your tests tomorrow of the modern gfortran and ifort cases
(and presumably your eventual test of nagfor) as well as
my eventual (once I install Debian Stretch with gfortran-6.3.0) 
test of modern gfortran will all go well.


That said, one notable (because they feature PLplot capability)
holdout is Absoft where the box in the above PDF is blank indicating
support for this important Fortran 2003 feature is unknown.  Absoft do
claim they support "essentially all" of Fortran 2003 so that is a good
sign, but a site:www.absoft.com google search showed no mention of
"character(len=:)" or "deferred length" or "allocatable length" so
that is a bad sign.  Anyhow, I plan to reestablish contact with Absoft
(assuming you can demonstrate good test results of the deferred-length
+ allocated size variant for modern gfortran and ifort) and ask them
to do the same test you are doing and temporarily keep or throw away
the deprecated versions of the above API before the release depending
on those results.

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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Arjen Markus]

Hi Alan,



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
>
> This commit completes my parsing API changes in bindings/fortran/*.f90 and my
> changes to examples/fortran/x01f.f90 to test all of these parsing API's.  I 
> would
> appreciate your review of my implementation.
> Furthermore, I would appreciate you following the parsing testing advice in
> README.release section 2.7.2 to discover which parts of this API work for 
> gfortran
> with version > 4.9.2 (e.g., for your Cygwin and MinGW-w64/MSYS2 platforms) as
> well as the ifort compiler you have access to (and possibly the nagfor 
> compiler you
> have arranged access to in the past).
>
> By the way, I am not sure of the correct terminology for character arrays 
> that have
> both length and size allocated.  I refer to them above as "dynamic length and 
> size",
> but I have also seen the term "deferred-length" used for character strings 
> with
> allocated length.
>
Unless I am mistaken the official term is deferred-length.

I have not yet tested this with my compilers, but I have reviewed the 
implementation. I have very few comments about it:

-It is a pity that we cannot disambiguate on the deferred/assumed 
length alone, but that is an issue of the language rules (the type of 
"assumed-length character string" simply encompasses the type of 
"deferred-length character string". Elaborate workaround might be possible, 
using classes/derived types, but that is not worth the trouble I think).

-If we decide at some point that we need to keep the various 
implementations, then perhaps we could "layer" the versions:

o   The deferred-length variant can call the assumed-length + allocated size 
variant

o   This can in turn call the fixed size variant

It would reduce the amount of code, by a small amount of source lines. But 
again, that may not be worth our while.

I should have time to test the implementation tomorrow. Maybe that will bring 
out more comments ;).

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.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Alan W. Irwin]

On 2017-12-27 14:26-0800 Alan W. Irwin wrote:


Hi Arjen:

I have done some further investigation and it appears that even today
allocatable character arrays are problematic to a certain extent for
Fortran compilers. For example, see
. I have no clue
whether that particular modern gfortran bug would affect us.  However,
the existence of such bug reports for a modern version of a Fortran
compiler indicates we should proceed with caution with allocatable
character arrays.

Therefore, once we implement allocatable character array variants of
plget_arguments and plparseopts we should survey the modern versions
of gfortran, ifort, and nagfor to see which of those work well with
that API.  Also we will likely want to retain the the current static
assumed shape character arrays API's for those functions for a while
so that users with access only to older Fortran compilers (e.g.,
gfortran-4.9.2) that are unreliable with the allocatable character
array approach have a plget_arguments and plparseopts API that
they can use.


Hi Arjen:

I have just pushed commit 6f2f4e4 to master which implements dynamic
length and size as well as static length and dynamic size variants of
plget_arguments and plparseopts.  The former does not work with
gfortran-4.9.2, but the latter (as well as the static length and size
variants implemented before) works well.  For more details about how
these tests should be done and results for gfortran-4.9.2, please see
the revised version of README.release section 2.7.2.

This commit completes my parsing API changes in bindings/fortran/*.f90
and my changes to examples/fortran/x01f.f90 to test all of these
parsing API's.  I would appreciate your review of my implementation.
Furthermore, I would appreciate you following the parsing testing
advice in README.release section 2.7.2 to discover which parts of this
API work for gfortran with version > 4.9.2 (e.g., for your Cygwin
and MinGW-w64/MSYS2 platforms) as well as the ifort
compiler you have access to (and possibly the nagfor compiler you have
arranged access to in the past).

By the way, I am not sure of the correct terminology for character
arrays that have both length and size allocated.  I refer to them
above as "dynamic length and size", but I have also seen the
term "deferred-length" used for character strings with allocated
length.

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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Alan W. Irwin]

On 2017-12-27 09:02- Arjen Markus wrote:


I am currently catching up with my e-mail (Christmas is a busy time

...), so this is the first opportunity I have found to respond to your
mails. Sure, I will have a look at this. (I even have a generic
solution for this type of programming problem, but it may not be
better than yours ;) - I respond before having seen it.)

Hi Arjen:

I have done some further investigation and it appears that even today
allocatable character arrays are problematic to a certain extent for
Fortran compilers. For example, see
. I have no clue
whether that particular modern gfortran bug would affect us.  However,
the existence of such bug reports for a modern version of a Fortran
compiler indicates we should proceed with caution with allocatable
character arrays.

Therefore, once we implement allocatable character array variants of
plget_arguments and plparseopts we should survey the modern versions
of gfortran, ifort, and nagfor to see which of those work well with
that API.  Also we will likely want to retain the the current static
assumed shape character arrays API's for those functions for a while
so that users with access only to older Fortran compilers (e.g.,
gfortran-4.9.2) that are unreliable with the allocatable character
array approach have a plget_arguments and plparseopts API that
they can use.

By the way, I am already using this new Fortran parsing feature in one of my
te_gen examples where the command-line has a mixture of PLplot options
and a file name, e.g.,

software@raven> examples/f95/test_asteroids \
-dev psc -o test.psc \
/home/software/time_ephemeris/HEAD/asteroid_ephemerides/ephcom_binary_ast343de430

where that last command-line option (although it could have been
anywhere on the command line) is obviously not relevant to PLplot.
After calling plget_arguments(nargv, argv) to get the nargv and argv
corresponding to that command-line, that example then calls 
plparseopts(nargv, argv, PL_PARSE_SKIP) which parses all the

command-line options that are relevant to PLplot and removes them from
argv.  The result is plparseopts returns nargv = 1 and argv(1) equal
to the asteroid ephemeris filename specified on the command line.  The
example then opens that ephemeris file and uses it to help calculate
the many asteroid results that are plotted by that example.

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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Arjen Markus]

Hi Alan,



I am currently catching up with my e-mail (Christmas is a busy time ...), so 
this is the first opportunity I have found to respond to your mails. Sure, I 
will have a look at this. (I even have a generic solution for this type of 
programming problem, but it may not be better than yours ;) - I respond before 
having seen it.)



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, December 26, 2017 9:16 AM
> To: Arjen Markus; PLplot development list
> Subject: Command-line parsing improvements for both C and Fortran
>
> Hi Arjen:
>
> I have just finished (commit 71944db) implementing the C and Fortran command-
> line parsing improvements that I first brought up with you
> (off-list) just a few days ago. Please see the revised version of 
> README.release
> for the details concerning these changes. Since your modern Fortran 
> experience is
> more extensive than mine, and I felt right on the edge of the limit of my own 
> modern
> Fortran expertise when implementing this, I would appreciate you reviewing the
> Fortran part of this topic, for substance (should it work perfectly in all 
> cases),
> standards-compliance (i.e., should it work for nagfor), and overall style.
>
> On that style point, in the new function c_to_character_array that appears in
> bindings/fortran/plplot_small_modules.f90 I implemented
>
> do i_local = 1, length_column_local
>  character_array(j_local)(i_local:i_local) = string_ptr(i_local) enddo
>
> to copy from a pointer vector of size length_column_local one-byte characters 
> to
> character_array(j_local), an element of a character array whose length is the 
> same
> as the string_ptr size. Is there a more modern Fortran method of implementing 
> the
> equivalent of this loop with just one assignment statement or are we stuck 
> with this
> do-loop style?
>
> One caveat I discussed in README.release with the present parsing-related
> additions to the Fortran API is that API needs to be converted from the 
> present
> assumed shape character arrays to allocatable character arrays to simplify the
> arguments and reduce the necessary size checking required with the present 
> static
> array approach.  But I am holding off from doing that change because 
> allocatable
> character arrays are not reliable on my present Debian Jessie (gfortran-4.9.2)
> platform.  For example, this simple test code,
>
> irwin@raven> cat test_allocatable_character_arrays.f
> c test of allocatable character arrays
>character(len=100), dimension(10)  :: argv_array
> !  character(len=:), dimension(:), allocatable  :: argv_array
> !  allocate(character(len=100) :: argv_array(10))
>
>argv_array(5)(1:10) = "hello, world"
>write(*,'(a)') argv_array(5)(1:10)
>end
>
> works fine as is on my platform, i.e. has perfect Valgrind results (0 errors, 
> no leaks
> are possible). However, if you comment the second line and uncomment the 3rd
> and 4th lines to change this from a static character array test to an 
> allocatable
> character array test, it spectacularly fails (outputs gibberish) and valgrind 
> also
> shows all sorts of memory management issues.
>
> Would you be willing to build and run both versions of the above test code on
> Cygwin (with gfortran-6.4.0) to make sure no obvious problems occur with that
> gfortran version? If your tests indicate no such problems then I would 
> encourage
> you to try updating the API to the allocatable version as indicated in
> README.release, and test that change as indicated there as well.  But if you 
> don't
> have time for that just now, I plan to make the change myself just as soon as 
> I
> upgrade to Debian Stretch.  I am assuming here (especially if you get good 
> results
> for the above test) that gfortran-6.3.0 that comes with that platform will 
> have no
> trouble with the above simple example and also the allocatable version of the 
> new
> code.
>
> Merry Christmas to you, your family, and all others interested in PLplot that 
> are
> lurking here on this list!
>
> 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. 
U

[Plplot-devel] Command-line parsing improvements for both C and Fortran

[Alan W. Irwin]

Hi Arjen:

I have just finished (commit 71944db) implementing the C and Fortran
command-line parsing improvements that I first brought up with you
(off-list) just a few days ago. Please see the revised version of
README.release for the details concerning these changes. Since your
modern Fortran experience is more extensive than mine, and I felt
right on the edge of the limit of my own modern Fortran expertise when
implementing this, I would appreciate you reviewing the Fortran part
of this topic, for substance (should it work perfectly in all cases),
standards-compliance (i.e., should it work for nagfor), and overall
style.

On that style point, in the new function c_to_character_array
that appears in bindings/fortran/plplot_small_modules.f90 I implemented

do i_local = 1, length_column_local
character_array(j_local)(i_local:i_local) = string_ptr(i_local)
enddo

to copy from a pointer vector of size length_column_local one-byte
characters to character_array(j_local), an element of a character
array whose length is the same as the string_ptr size. Is there a more
modern Fortran method of implementing the equivalent of this loop with
just one assignment statement or are we stuck with this do-loop style?

One caveat I discussed in README.release with the present
parsing-related additions to the Fortran
API is that API needs to be converted from the present assumed shape
character arrays to allocatable character arrays to simplify the
arguments and reduce the necessary size checking required with the
present static array approach.  But I am holding off from doing that change
because allocatable character arrays are not reliable on my present
Debian Jessie (gfortran-4.9.2) platform.  For example, this simple
test code,

irwin@raven> cat test_allocatable_character_arrays.f
c test of allocatable character arrays
  character(len=100), dimension(10)  :: argv_array 
!  character(len=:), dimension(:), allocatable  :: argv_array 
!  allocate(character(len=100) :: argv_array(10))


  argv_array(5)(1:10) = "hello, world"
  write(*,'(a)') argv_array(5)(1:10)
  end

works fine as is on my platform, i.e. has perfect Valgrind results (0
errors, no leaks are possible). However, if you comment the second
line and uncomment the 3rd and 4th lines to change this from a static
character array test to an allocatable character array test, it
spectacularly fails (outputs gibberish) and valgrind also shows all
sorts of memory management issues.

Would you be willing to build and run both versions of the above test
code on Cygwin (with gfortran-6.4.0) to make sure no obvious problems
occur with that gfortran version? If your tests indicate no such
problems then I would encourage you to try updating the API to the
allocatable version as indicated in README.release, and test that
change as indicated there as well.  But if you don't have time for
that just now, I plan to make the change myself just as soon as I
upgrade to Debian Stretch.  I am assuming here (especially if you get
good results for the above test) that gfortran-6.3.0 that comes with
that platform will have no trouble with the above simple example and
also the allocatable version of the new code.

Merry Christmas to you, your family, and all others interested in
PLplot that are lurking here on this list!

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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel