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