plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] uncrustify msys2

[Alan W. I. <Ala...@gm...>]

On 2019-07-31 12:44+0100 Phil Rosenberg wrote:

> Thanks Alan
> I've just tried again with the style_source script, but I'm hitting
> another problem. I now get the error:
>
> File "scripts/convert_comment.py", line 72
>    raise RuntimeError, "Cannot interpret trailing character(s) after
> */ for this line"
>                      ^
> SyntaxError: invalid syntax
> ERROR: scripts/convert_comment.py failed for file plplot_config.h.in
>
>
> Any suggestions? I have both python 2 and 3 installed.

That error message comes from this logic in scripts/convert_comment.py
which hasn't been changed (from git blame -w) since 2010.

     # Note trailing "\n" has not (yet) been removed from line so
     # that the next to last character is at position len(line) - 3.
     if end_comment >=0 and end_comment !=  len(line) - 3:
         if ifsingleline and start_comment >=0:
             # Skip most further processing for a line with embedded
             # comments outside of multiline blocks of comments.
             start_comment = -1
             end_comment = -1
         else:
             sys.stderr.write(line)
             raise RuntimeError, "Cannot interpret trailing character(s) after */ for this line"

So that error message should have included the results from sys.stderr.write(line)
from the line in plplot_config.h.in that is stored in the Python "line" variable
that appears to be causing this python logic problem.

The usual interpretation of this error message is you have commentary
in plplot_config.h.in which is not in legitimate form.  For example,
you might have forgotten the trailing "*/" on a comment.  So I would
test that possibility by attempting to build the plplot target before
styling, which would necessarily attempt to compile the configured
plplot_config.h.

However, if that "easy" answer is not the correct one, please send the
complete error message including the output of the Python "line" variable
that is causing the issue.

Of course, the above Python logic only works if there are no
line-ending issues in Python, i.e., the Python "line" variable
contains a string that is terminated simply by \n rather than
\r\n. And note that by git default plplot_config.h.in will have \r\n
line endings on MSYS2.  But the discussion in
<https://stackoverflow.com/questions/10785131/line-endings-in-python>
seems to imply that on Python automatically converts all \r and \r\n
line endings for text files to \n.  Also, my impression is you have
exercised the above scripts/convert_comment.py logic from 2010 with no
issues in the past on Cygwin (where again, the checked out
plplot_config.h.in should have \r\n line endings.) So I would only
look at this potential line ending issue (by dumping out each raw byte
of the above line) only as a last resort (i.e., only if the line that
is causing this error compiles with no issues).

Alan
__________________________
Alan W. Irwin

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.org); 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] Preliminary good PLplot results with Brad King's fork of Ninja

[Alan W. I. <Ala...@gm...>]

P.S.

@Brad:

I should have also mentioned that the build script does the following inside the git repository:

# For rebuilds *using a separate build tree*, "git status" reveals
# ninja has a build bug where re2c modifies src/lexer.cc in the source
# tree.  So remove this source-code change so you are guaranteed to start
# with a completely fresh source tree:
git checkout -- src/lexer.cc

Which works around a ninja source-tree contamination bug that needs fixing.

Alan
__________________________
Alan W. Irwin

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.org); 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] Preliminary good PLplot results with Brad King's fork of Ninja

[Alan W. I. <Ala...@gm...>]

To the PLplot developers and Brad King:

@Brad:

I am including you in this discussion because I thought you might be
interested in these good PLplot results with your fork of Ninja.

@Developers:
Ninja should be of interest to us as a back-end for CMake because
ninja works on all platforms and has a reputation for being fast
because of its design philosophy (which is to execute all the low-level
build system stuff as quickly as possible while leaving all the
complex decision making for builds to higher-level build system software
such as CMake).  And Brad King's fork of ninja is of interest to us
because it fixes Fortran issues with the upstream version.

I. Building, testing, and installing Brad King's fork of ninja.

I attach a bash script to do that.  It should be run as follows:

./king_ninja_git_build.sh v1.9.0.g99df1.kitware.dyndep-1.jobserver-1

Here are the extra messages (i.e., those without leading '[') that are generated by ninja_test
The last one of these should be "passed".
Raise [ulimit -n] above 1025 (currently 1024) to make this test go
ninja: warning: -jN forced on command line; ignoring GNU make jobserver.
passed

@Brad:

In response to that first message I tried

ulimit -n 1026

(which worked according to ulimit -a), but then
after that ninja_test failed with
ninja: fatal: pipe: Too many open files

and the only way to fix that was to go back to "ulimit -n 1024"

I don't know the significance of the second message, but I thought you should
be informed of it.

II. PLplot testing of Brad's fork on ninja

@Everybody:

This is a preliminary test of PLplot because I found that the
Java, Octave, and Ada components of PLplot did not work with
ninja.  I need to investigate further to decide whether
these issues are due to our own language-support issues for
Ada, build-system issues for all three components, and/or CMake/ninja
issues. But for now I shut down those components with
-DENABLE_java=OFF -DENABLE_octave=OFF -DENABLE_ada=OFF and under these
conditions the times required to configure PLplot with cmake were as follows:

-G"Ninja"
real    0m8.732s
user    0m6.867s
sys     0m3.156s

-G"Unix Makefiles"
real    0m9.730s
user    0m7.781s
sys     0m3.134s

==> Significant configuration time advantage for Ninja

Here were the times required to build the test_noninteractive target after each of the above
clean configurations:

-G"Ninja"
software@merlin> time env PATH=/home/software/ninja/install-v1.9.0.g99df1.kitware.dyndep-1.jobserver-1/bin:$PATH ninja -j16 test_noninteractive >& test_noninteractive.out

real    1m5.298s
user    7m19.614s
sys     0m47.019s


-G"Unix Makefiles
software@merlin> time (make -j16 test_noninteractive >& test_noninteractive.out)

real    1m21.388s
user    7m31.672s
sys     0m58.231s

==> Significant run-time advantage for Ninja

In both cases the resulting test_noninteractive.out file showed no obvious run-time issues
and gave a clean difference report for the default svg device, e.g.,

c++
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
d
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
fortran
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
lua
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
ocaml
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
python
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
tcl
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            :

By the way, I haven't tested this, but apparently an even more
significant speed advantage for Ninja is it reduces the CMake
reconfiguration time when, for example, you have edited one PLplot
file and wish to reconfigure/rebuild.

So for now, I would advise all those that are not interested in the Java, Octave, or Ada
components of PLplot to give the Brad King fork of ninja a try.  In particular since
ninja has been designed from the ground up to support parallel builds while parallel
builds are an add-on for the GNU-make case it is likely you should get good parallel build
results for ninja on the Cygwin and MSYS2 platforms where Arjen's experience is that
parallel builds are not reliable on those two platforms for GNU-make.

I haven't tried upstream ninja, but since Brad's fork of that software
is designed to fix fortran issues, then I assume everything that
worked above except the fortran component should work well if one of
you prefers to try the upstream version of ninja.

Alan
__________________________
Alan W. Irwin

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.org); 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] uncrustify msys2

[Alan W. I. <Ala...@gm...>]

On 2019-07-25 16:09-0700 Alan W. Irwin wrote:

> [.... C]ompletely finishing this project will take much longer
> than expected because of [...] complications with styling the swig directive
> (*.i) files that occur in bindings/<language> where <language> is one
> of java, python, lua, or octave [....]

Those complications have finally been dealt with (see commit
plplot-5.15.0-13-g2ec8daf88), and, as far as I know from my successful
noninteractive and interactive tests on Linux, this commit completes
the work of moving from uncrustify 0.60 to 0.69.0 to style our source
code.  However, the source code styling changes for this topic were
quite intrusive so further testing of these style changes would be a
good idea for non-Linux platforms.

Alan
__________________________
Alan W. Irwin

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.org); 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] uncrustify msys2

[Alan W. I. <Ala...@gm...>]

On 2019-07-25 18:30-0700 Alan W. Irwin wrote:

> For those interested in building uncrustify 0.69.0 from the git tag
> (which should be all developers here who would like to run the bash
> script scripts/style_source.sh to style their source-code updates
> before committing those changes), I have attached my newly implemented
> bash script for building uncrustify.  (I have recently successfully
> used this script to configure, build, install, and test uncrustify
> 0.69.0 for myself with complete success.)
>
> Note this script has a number of useful comments about how to run the
> script, how to tailor it for local conditions, and the details of the
> git clone command that needs to be run just once (in the same
> directory where you have placed this script) to get access to the git
> version of the uncrustify source code *before the first time* you run
> the script.

P.S. I have configured gmail to *not* filter mail with their spam
filtering application, and to deliver all email (regardless of whether
gmail decides it is spam or ham) to my local computer using the
getmail application on that computer.  That application uses procmail
to actually deliver the mail to my local inbox (following the general
"Unix/Linux" philosophy that applications are designed to do just one
thing well, and to hand off to another well-designed application to do
some other step in a chain of steps.)  And because of that procmail
link in my input mail chain, I can use spam_bayes to filter for spam
just in one place in that chain under my sole control.  And this whole
system works well so that very little spam gets into my inbox, and,
for example, the bash script attachment came back to me from the SF
mailing list without being stripped.

However, I now recall others here do not have complete control of
their spam filtering so the possibility exists that such filtering
will silently strip out bash script attachments.  So I resend that
attachment in this e-mail in gzipped form.

And, of course, if you have a spam filter somewhere in your input mail
chain that strips out all attachments including gzipped ones, then it
is time for you to either complain to those who are doing such
complete stripping and/or gain sole control of your spam filtering so
you to can enjoy use of such attachments.  :-)

Alan
__________________________
Alan W. Irwin

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.org); 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] uncrustify msys2

[Alan W. I. <Ala...@gm...>]

For those interested in building uncrustify 0.69.0 from the git tag
(which should be all developers here who would like to run the bash
script scripts/style_source.sh to style their source-code updates
before committing those changes), I have attached my newly implemented
bash script for building uncrustify.  (I have recently successfully
used this script to configure, build, install, and test uncrustify
0.69.0 for myself with complete success.)

Note this script has a number of useful comments about how to run the
script, how to tailor it for local conditions, and the details of the
git clone command that needs to be run just once (in the same
directory where you have placed this script) to get access to the git
version of the uncrustify source code *before the first time* you run
the script.

Alan
__________________________
Alan W. Irwin

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.org); 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] uncrustify msys2

[Alan W. I. <Ala...@gm...>]

On 2019-07-24 01:40-0700 Alan W. Irwin wrote:

> [...]so my current ETA for the above proposed commit is
> late tomorrow (Wednesday) or so.

Sorry, but completely finishing this project will take much longer
than expected because of a complication with align_number_left (which
I have dealt with) and complications with styling the swig directive
(*.i) files that occur in bindings/<language> where <language> is one
of java, python, lua, or octave (which I have not been able to
completely deal with yet).

See the plplot-5.15.0-10-g16d554223 commit message for the details
concerning these complications.  (Use the --name-status option on git
log to insure you get a feel for the large number of files changed in
this commit.)

Although that commit skips styling the swig directive files, it is
otherwise complete so you should now be able to use
scripts/style_source.sh without issues on MSYS2 for either version
(one built from the appropriate git tag, one built from the
appropriate tarball) of uncrustify-0.69.0.  Therefore, please go ahead
and run that script on that platform for your version (built from
the tarball) of uncrustify-0.69.0, and let me know whether that script runs
without issues.

Also because the source code changes included in
plplot-5.15.0-10-g16d554223 are so intrusive it is important to make
additional tests beyond my own strong Linux platform test on non-Linux
platforms.  So along with the tests you normally perform for MSVC
please also try comprehensive testing on MSYS2 (at least for the
non-interactive case) to confirm these extensive source code changes
are not causing any trouble on that platform.

The other issue, of course, is all these source code changes introduce
conflicts for topic branches that have not been rebased to the lastest
master branch.  However, resolution of these conflicts should be
entirely straightforward since "git diff --ignore-all-space" showed
all the source code changes were simply whitespace changes.

Alan
__________________________
Alan W. Irwin

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.org); 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] uncrustify msys2

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

Thanks Alan
I have a commit ready to go that removes a plexit call if the .fnt hershey font files are missing for some reason.

I'll wait for your uncrustify change then before I push it.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Alan W. Irwin <Ala...@gm...>
Sent: Wednesday, July 24, 2019 9:40:16 AM
To: Phil Rosenberg <p.d...@gm...>
Cc: PLplot development list <plp...@li...>
Subject: Re: [Plplot-devel] uncrustify msys2

Hi Phil:

On 2019-07-23 18:44+0100 Phil Rosenberg wrote:

> Hi
> I just wanted to check if anyone on the list has used uncrustfy in
> msys2 to run the style-source script?

<aside> I am very happy to hear you are making progress with MSYS2, and I
look forward to your comprehensive test reports for that platform.</aside>.

>
> I couldn't find an uncrustify package to install via pacman, so I
> built it from source. However, when I run style_source.sh I get the
> following error
>
> Detected uncrustify version = 'Uncrustify-0.69.0_f'.
> This script only works with uncrustify 0.60.

Out of inertia I have stuck with uncrustify 0.60 up to now, but it is obviously
way past time to move to the latest version (0.69.0) so I have taken
responsibility for making that change.

One minor issue that I am currently looking at is the following (mild) warning
message I encountered from the CMake-based build system for uncrustify:

-- scripts/make_version.py exited with code 64: Unknown version control system in '/home/software/uncrustify/uncrustify-0.69.0'.

As a fallback, version 'Uncrustify-0.69.0_f' will be used.

Since the version string reported by you is
'Uncrustify-0.69.0_f' I assume your build has the same warning message.

I am virtually positive that warning is due to us both building from
the appropriate tarball rather than appropriate git tag, but I will
know a lot more tomorrow (after getting some sleep) after I finish
implementing a bash script to configure, build, install, and test from
the appropriate git tag corresponding to the desired uncrustify
version.  (For git enthusiasts like me such a build is actually easier
to do than a build from a tarball).  But my guess at this stage is
that script result will be the above minor issue will be fixed (since
git is virtually certainly the version control system that their build
system is looking for) and the uncrustify executable version string we
both encountered with the tarball build of 'Uncrustify-0.69.0_f' will
likely be replaced by 'Uncrustify-0.69.0'.  But I will see about that
version string tomorrow and see also the FIXME note below concerning
that.

Here is the PLplot commit message I have in mind for tomorrow (adapted
from the git commit message when I updated from 0.58 to 0.60 ~5 years
ago):

     Update from uncrustify version 0.60 to 0.69.0.

     This commit includes the following changes.

     1. Update annotated configuration file using
     uncrustify --update-config-with-doc -c uncrustify.cfg > uncrustify-0.69.0.cfg
     mv uncrustify-0.69.0.cfg uncrustify.cfg

     2. Update scripts/style_source.sh to change from 'uncrustify 0.60' for the
     allowed uncrustify version string to either 'Uncrustify-0.69.0' (built from appropriate
     git tag) or 'Uncrustify-0.69.0_f' (built from appropriate tarball) (FIXME if the git
     version of the build provides a version string different than 'Uncrustify-0.69.0')

     3. Run that script to update the style of a large number of our source code
     files according to the uncrustify 0.69.0 rules.  We ascribe these large number
     of whitespace changes to changes in the implementation (new features
     with default configuration, bug fixes, and/or introduced bugs) between
     uncrustify 0.60 and 0.69.0.  Note that visual sampling of these changes didn't
     reveal any obvious style issues, and these changes also passed the test
     below:

     Tested by Alan W. Irwin <ai...@us...> on Linux
     (Debian Buster) by building the test_noninteractive target in the
     build tree and evaluating the result to demonstrate no build-time or
     run-time errors, and no issues with the SVG difference report.

Finishing implementing the uncrustify build, install, and test script
and all the above changes, tests, and test evaluations is obviously
going to take me a while, but it all appears to be entirely
straightforward so my current ETA for the above proposed commit is
late tomorrow (Wednesday) or so.

More then.

Alan
__________________________
Alan W. Irwin

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.org); 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] uncrustify msys2

[Alan W. I. <Ala...@gm...>]

Hi Phil:

On 2019-07-23 18:44+0100 Phil Rosenberg wrote:

> Hi
> I just wanted to check if anyone on the list has used uncrustfy in
> msys2 to run the style-source script?

<aside> I am very happy to hear you are making progress with MSYS2, and I
look forward to your comprehensive test reports for that platform.</aside>.

>
> I couldn't find an uncrustify package to install via pacman, so I
> built it from source. However, when I run style_source.sh I get the
> following error
>
> Detected uncrustify version = 'Uncrustify-0.69.0_f'.
> This script only works with uncrustify 0.60.

Out of inertia I have stuck with uncrustify 0.60 up to now, but it is obviously
way past time to move to the latest version (0.69.0) so I have taken
responsibility for making that change.

One minor issue that I am currently looking at is the following (mild) warning
message I encountered from the CMake-based build system for uncrustify:

-- scripts/make_version.py exited with code 64: Unknown version control system in '/home/software/uncrustify/uncrustify-0.69.0'.

As a fallback, version 'Uncrustify-0.69.0_f' will be used.

Since the version string reported by you is
'Uncrustify-0.69.0_f' I assume your build has the same warning message.

I am virtually positive that warning is due to us both building from
the appropriate tarball rather than appropriate git tag, but I will
know a lot more tomorrow (after getting some sleep) after I finish
implementing a bash script to configure, build, install, and test from
the appropriate git tag corresponding to the desired uncrustify
version.  (For git enthusiasts like me such a build is actually easier
to do than a build from a tarball).  But my guess at this stage is
that script result will be the above minor issue will be fixed (since
git is virtually certainly the version control system that their build
system is looking for) and the uncrustify executable version string we
both encountered with the tarball build of 'Uncrustify-0.69.0_f' will
likely be replaced by 'Uncrustify-0.69.0'.  But I will see about that
version string tomorrow and see also the FIXME note below concerning
that.

Here is the PLplot commit message I have in mind for tomorrow (adapted
from the git commit message when I updated from 0.58 to 0.60 ~5 years
ago):

     Update from uncrustify version 0.60 to 0.69.0.

     This commit includes the following changes.

     1. Update annotated configuration file using
     uncrustify --update-config-with-doc -c uncrustify.cfg > uncrustify-0.69.0.cfg
     mv uncrustify-0.69.0.cfg uncrustify.cfg

     2. Update scripts/style_source.sh to change from 'uncrustify 0.60' for the
     allowed uncrustify version string to either 'Uncrustify-0.69.0' (built from appropriate
     git tag) or 'Uncrustify-0.69.0_f' (built from appropriate tarball) (FIXME if the git
     version of the build provides a version string different than 'Uncrustify-0.69.0')

     3. Run that script to update the style of a large number of our source code
     files according to the uncrustify 0.69.0 rules.  We ascribe these large number
     of whitespace changes to changes in the implementation (new features
     with default configuration, bug fixes, and/or introduced bugs) between
     uncrustify 0.60 and 0.69.0.  Note that visual sampling of these changes didn't
     reveal any obvious style issues, and these changes also passed the test
     below:

     Tested by Alan W. Irwin <ai...@us...> on Linux
     (Debian Buster) by building the test_noninteractive target in the
     build tree and evaluating the result to demonstrate no build-time or
     run-time errors, and no issues with the SVG difference report.

Finishing implementing the uncrustify build, install, and test script
and all the above changes, tests, and test evaluations is obviously
going to take me a while, but it all appears to be entirely
straightforward so my current ETA for the above proposed commit is
late tomorrow (Wednesday) or so.

More then.

Alan
__________________________
Alan W. Irwin

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.org); 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] uncrustify msys2

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

Hi
I just wanted to check if anyone on the list has used uncrustfy in
msys2 to run the style-source script?

I couldn't find an uncrustify package to install via pacman, so I
built it from source. However, when I run style_source.sh I get the
following error

Detected uncrustify version = 'Uncrustify-0.69.0_f'.
This script only works with uncrustify 0.60.


Phil

Re: [Plplot-devel] CMake problem with hyphen in path

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

Hi Alan, Phil,

-----Original Message-----
From: Alan W. Irwin <Ala...@gm...>
Sent: 13 July 2019 21:15
To: Phil Rosenberg <p.d...@gm...>
Cc: PLplot development list <plp...@li...>
Subject: Re: [Plplot-devel] CMake problem with hyphen in path

On 2019-07-13 08:05-0000 Phil Rosenberg wrote:

> Hi Alan
> You may be right.
> I tried commenting out the offending regex replace, which meant cmake finished with no issues. But, when I tried to compile I found I had a similar problem with header files. I couldn't actually find the offending code that is causing that problem. I tried adding some quotes, but that didn't seem to help.
>
> So whatever workload you thought it was, it is actually double!

Actually there is at least one or two orders of magnitude more work according to my Linux tests if you consider dealing with this problem for all external free software libraries that PLplot depends on rather than just wxwidgets.  And the results would depend on all external libraries (and CMake itself) dealing with blank in pathname issues correctly which some preliminary tests I have done appears to be far from the case.  So the fundamental issue is PLplot has been responsible about its own internal source, build, and install tree blanks in pathname issues, but other free software has not been that responsible.  And a large supplementary issue is that even if external software eventually becomes completely responsible about this case, there would still be a lot more to do on the PLplot side to make "space in external library prefix" case work properly for all external libraries.

>>AM: FWIW, a check that the install directory does not include space would be inline with what a package like Anaconda for Python is doing on Windows. Instead of the more commonly used directory "C:\Program Files", it installs in "C:\ProgramData", to avoid the issue that packages do not take responsibility for spaces in directory names. PLplot might simply issue a warning if the user tries to use such names anyway.

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] CMake problem with hyphen in path

[Alan W. I. <Ala...@gm...>]

On 2019-07-13 08:05-0000 Phil Rosenberg wrote:

> Hi Alan
> You may be right.
> I tried commenting out the offending regex replace, which meant cmake finished with no issues. But, when I tried to compile I found I had a similar problem with header files. I couldn't actually find the offending code that is causing that problem. I tried adding some quotes, but that didn't seem to help.
>
> So whatever workload you thought it was, it is actually double!

Actually there is at least one or two orders of magnitude more work
according to my Linux tests if you consider dealing with this problem
for all external free software libraries that PLplot depends on rather
than just wxwidgets.  And the results would depend on all external
libraries (and CMake itself) dealing with blank in pathname issues
correctly which some preliminary tests I have done appears to be far
from the case.  So the fundamental issue is PLplot has been
responsible about its own internal source, build, and install tree
blanks in pathname issues, but other free software has not been that
responsible.  And a large supplementary issue is that even if external
software eventually becomes completely responsible about this case,
there would still be a lot more to do on the PLplot side to make
"space in external library prefix" case work properly for all external
libraries.

> Would it be relatively straightforward to add a check, so if the user supplies an install or library/header path that contains " -" then we error out at that point?

The problem with *complete* configuration-time detection of that case
is that we would have to have reliable parsing to detect the
difference between hyphenated/spaced pathnames as opposed to the " -"
that delimits linker options.  That said, we could easily warn against
the case where "- " appears anywhere in the options string since that
case is obviously not a linker option.  If you agree, I will take
responsibility for implementing such a check.

But that check would obviously not guard against the case of, say, an
-L option of the form

-L/whatever -hyphen_pathname

where "whatever -hyphen_pathname" was the complete pathname rather
than "whatever" being the pathname with "-hyphen_pathname" being a
separate linker option.  And the check would only be available for
the external wxwidgets library and all external libraries that
use pkg-config.

So to supplement that proposed incomplete configuration-time check I
think we should create a prominent warning in our wiki for users not
to use installation prefixes that contain spaces for external free
software libraries.  I emphasize spaces rather than hyphens here since
it is the spaces that generate all the issues with or without hyphens
according to my Linux tests.  Also, most experienced Unix users would
not try spaces in installed library prefixes, but some might do that
so I think the warning should be a general one rather than Windows
only.

If you agree that wiki "no-space in external library prefixes" warning
would be useful as well, would you take responsibility for updating
the most fundamental PLplot build page in our wiki (whatever that is)
to that effect?

Alan
__________________________
Alan W. Irwin

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.org); 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] CMake problem with hyphen in path

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

Hi Alan
You may be right.
I tried commenting out the offending regex replace, which meant cmake finished with no issues. But, when I tried to compile I found I had a similar problem with header files. I couldn't actually find the offending code that is causing that problem. I tried adding some quotes, but that didn't seem to help.

So whatever workload you thought it was, it is actually double!

Would it be relatively straightforward to add a check, so if the user supplies an install or library/header path that contains " -" then we error out at that point? This way if anyone else hits this problem it would be very clear to the user what the problem is and how to fix it.

I presume we can't check each library individually - or it would be easy to fix. But I am setting cmake_install_prefix to a path that is bad, so maybe that could be checked. I think there are other variables too. Link_directories and include_directories, any more?

I'll set a workaround up on my computer by symlinking my usr directory from c:\usr or something. But it's a work computer and I'll need someone with admin rights to sort it for me next week.

Phil

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Alan W. Irwin <Ala...@gm...>
Sent: Saturday, July 13, 2019 6:42:20 AM
To: Phil Rosenberg
Cc: PLplot development list
Subject: Re: CMake problem with hyphen in path

On 2019-07-13 00:35+0100 Phil Rosenberg wrote:

> There are no .pc files. I'm building on native windows with visual
> studio (not with Cygwin or MSYS2) so there is no pkg-config. All
> libraries get found with the findXXX.cmake modules. In this case it is
> shapelib and wxwidgets libraries.
>
> On windows CMake basically hunts in certain locations for the libs and
> headers. In this case it finds shapelib by checking in my
> CMAKE_INSTALL_PREFIX and it finds wxWidgets via the WXWIN environment
> variable.

[...]
> Output
> (original _link_flags_list) = debug;C:/Users/earpros/OneDrive -
> University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib;

[...]

> (post regex replace _link_flags_list) =
> debug;C:/Users/earpros/OneDrive;- University of
> Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib;

[...]

Hi Phil:

Thanks for the above detailed information which contradicted some of
my assumptions (natch).

However, I am frankly beginning to get cold feet about working much
further on this topic since from my Linux test of the case where
external libraries have blanks and hyphens in their installation
prefixes, there are a huge bunch of issues we would have to deal with
before that case worked, i.e., it would be a lot of work for little
real gain.

For example, my understanding is Windows installers typically give you
a choice of any installation prefix you want.  So wouldn't it be a lot
easier to ask our Windows users to be careful of that choice, i.e.,
pick installation prefixes without blanks or hyphens?  For example,
MSYS2 allows users to choose any installation prefix they like.  And
I think they even recommend not choosing an installation prefix with
spaces because of all the trouble that causes with free software.

Alan
__________________________
Alan W. Irwin

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.org); 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] CMake problem with hyphen in path

[Alan W. I. <Ala...@gm...>]

On 2019-07-13 00:35+0100 Phil Rosenberg wrote:

> There are no .pc files. I'm building on native windows with visual
> studio (not with Cygwin or MSYS2) so there is no pkg-config. All
> libraries get found with the findXXX.cmake modules. In this case it is
> shapelib and wxwidgets libraries.
>
> On windows CMake basically hunts in certain locations for the libs and
> headers. In this case it finds shapelib by checking in my
> CMAKE_INSTALL_PREFIX and it finds wxWidgets via the WXWIN environment
> variable.

[...]
> Output
> (original _link_flags_list) = debug;C:/Users/earpros/OneDrive -
> University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib;

[...]

> (post regex replace _link_flags_list) =
> debug;C:/Users/earpros/OneDrive;- University of
> Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib;

[...]

Hi Phil:

Thanks for the above detailed information which contradicted some of
my assumptions (natch).

However, I am frankly beginning to get cold feet about working much
further on this topic since from my Linux test of the case where
external libraries have blanks and hyphens in their installation
prefixes, there are a huge bunch of issues we would have to deal with
before that case worked, i.e., it would be a lot of work for little
real gain.

For example, my understanding is Windows installers typically give you
a choice of any installation prefix you want.  So wouldn't it be a lot
easier to ask our Windows users to be careful of that choice, i.e.,
pick installation prefixes without blanks or hyphens?  For example,
MSYS2 allows users to choose any installation prefix they like.  And
I think they even recommend not choosing an installation prefix with
spaces because of all the trouble that causes with free software.

Alan
__________________________
Alan W. Irwin

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.org); 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] CMake problem with hyphen in path

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

cmake_link_flagsHi Alan
There are no .pc files. I'm building on native windows with visual
studio (not with Cygwin or MSYS2) so there is no pkg-config. All
libraries get found with the findXXX.cmake modules. In this case it is
shapelib and wxwidgets libraries.

On windows CMake basically hunts in certain locations for the libs and
headers. In this case it finds shapelib by checking in my
CMAKE_INSTALL_PREFIX and it finds wxWidgets via the WXWIN environment
variable.

However I have attached below, the value of _link_flag_list just
before and just after the regex replace in cmake_link_flags

Cmake code
    message("(original _link_flags_list) = ${_link_flags_in}")
    # Convert link flags to a list.  Note some link flags are blank-delimited
    # (such as "-framework whatever") so preserve those by splitting into
    # separate list elements only if the next element starts with a hyphen.
    string(REGEX REPLACE " -" ";-" _link_flags_list "${_link_flags_in}")
    message("(post regex replace _link_flags_list) = ${_link_flags_list}")


Output
(original _link_flags_list) = debug;C:/Users/earpros/OneDrive -
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30u.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxmsw30ud_core.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxmsw30u_core.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxpngd.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxpng.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxtiffd.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxtiff.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxjpegd.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxjpeg.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxzlibd.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxzlib.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxregexud.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxregexu.lib;debug;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxexpatd.lib;optimized;C:/Users/earpros/OneDrive
- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxexpat.lib;winmm;comctl32;oleacc;rpcrt4;shlwapi;version;wsock32
(post regex replace _link_flags_list) =
debug;C:/Users/earpros/OneDrive;- University of
Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib;optimized;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30u.lib;debug;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxmsw30ud_core.lib;optimized;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxmsw30u_core.lib;debug;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxpngd.lib;optimized;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxpng.lib;debug;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxtiffd.lib;optimized;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxtiff.lib;debug;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxjpegd.lib;optimized;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxjpeg.lib;debug;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxzlibd.lib;optimized;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxzlib.lib;debug;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxregexud.lib;optimized;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxregexu.lib;debug;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxexpatd.lib;optimized;C:/Users/earpros/OneDrive;-
University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxexpat.lib;winmm;comctl32;oleacc;rpcrt4;shlwapi;version;wsock32

To be honest Alan, I'm not sure what differenc quoting will make.
Won't the regex just ignore the quotes anyway?


On Fri, 12 Jul 2019 at 20:55, Alan W. Irwin <Ala...@gm...> wrote:
>
> Oops, I sent this to the wrong list so I am correcting that now.
>
> On 2019-07-12 05:05-0700 Alan W. Irwin wrote:
>
> > I am virtually positive pkg-config has a way (likely with quotes) to
> > properly distinguish between these two cases, but I am going to have
> > to find what that is and adjust the above parsing logic accordingly
> > for the general fix.
>
> Hi Phil:
>
> It turns out that the correct *.pc file syntax to handle blanks in
> pathnames is to quote all -L and -I options, e.g., -L"whatever blank".
> Could you send me all the *.pc files (wrapped in a tarball for my
> convenience) for the external libraries used by PLplot that you have
> installed with " - " in the pathname?  Unless I am missing something
> those *.pc files will have " - " embedded in every pathname mentioned
> in those files.  And if so, then I want to check that those pathnames are
> all quoted correctly.
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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.org); 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] CMake problem with hyphen in path

[Alan W. I. <Ala...@gm...>]

Oops, I sent this to the wrong list so I am correcting that now.

On 2019-07-12 05:05-0700 Alan W. Irwin wrote:

> I am virtually positive pkg-config has a way (likely with quotes) to
> properly distinguish between these two cases, but I am going to have
> to find what that is and adjust the above parsing logic accordingly
> for the general fix.

Hi Phil:

It turns out that the correct *.pc file syntax to handle blanks in
pathnames is to quote all -L and -I options, e.g., -L"whatever blank".
Could you send me all the *.pc files (wrapped in a tarball for my
convenience) for the external libraries used by PLplot that you have
installed with " - " in the pathname?  Unless I am missing something
those *.pc files will have " - " embedded in every pathname mentioned
in those files.  And if so, then I want to check that those pathnames are
all quoted correctly.

Alan
__________________________
Alan W. Irwin

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.org); 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] Possible Windows development agendas for the next 6 months

[Alan W. I. <Ala...@gm...>]

On 2019-06-14 13:10+0100 Phil Rosenberg wrote:

> Just a note about MSVC, what are the ABI concerns you have? It is of
> note that GCC for windows does not provide ABI forward compatibility
> https://stackoverflow.com/a/23521099. My understanding is that MSVC's
> C ABI is consistent across versions and I just did a quick google and
> found that for C++ MSVC2015, 2017 and 2019 are all ABI compatible.
> https://devblogs.microsoft.com/cppblog/cpp-binary-compatibility-and-pain-free-upgrades-to-visual-studio-2019/

My concern is gcc/g++ ABI changes fairly often between versions as
noted in the stackoverflow link you provided.  But as the link implied
modern gcc/g++ does provide an option to allow users to specify some
older ABI version.  So that is what Arjen had to do some time ago when
he ran into a MSYS2 library that was compiled with a dated gcc suite
of compilers with an older ABI.  That condition is caused by the fact
it takes a while for Alex to to rebuild every library to be ABI
consistent with the latest gcc suite of compilers provided by MSYS2
so with MSYS2 you do run into this temporary (until libraries are rebuilt)
problem periodically whenever the
gcc suite of compilers has an ABI change.

Note, Arjen recently also ran into the opposite problem (MSYS2
compiler had older ABI than compiler used to build the MSYS2
libraries), but that was an artifact of him attempting to use an MSYS2
platform that was not consistently updated.

In sum, if using gcc/g++ to be ABI safe you should always build PLplot
with exactly the same version of that suite of compilers that are used
to build the libraries from the distribution (Cygwin, MSYS2, Debian,
etc.).  And mixing MSVC-built PLplot with gcc-built libraries or vice
versa is not a good idea.  However, it sounds from your experience,
that if you stick with MSVC that compiler suite ABI does not change very
often with version allowing you to use downloaded or built free
software libraries that are built with a fairly different MSVC version
(but same ABI).

> Interestingly it looks like Microsoft is also developing some sort of
> open source library packaging system, called Vcpkg, to reduce the
> existing pain of having to build all open source libraries from
> scratch https://devblogs.microsoft.com/cppblog/vcpkg-a-tool-to-acquire-and-build-c-open-source-libraries-on-windows/.
> Might be worth looking into. Had a quick scan down the list of
> available libraries and Cairo, Pango, Curl, wxWidgets are there. HA HA
> - JUST CHECKED AND SO IS PLPLOT!!! At version 5.13.

That additional distribution of free software for Windows does sound
like it is worth checking out.  But the link you gave only provided a
list of libraries so I am not sure whether the bash, cmp, diff, etc.,
Unix tools necessary for comprehensive testing are included or not.
If so, then you have found a third free software distribution for
Windows that generally provides what is available from MSYS2 and
Cygwin.  However, if not, in theory you can put the MSYS2 versions of
those tools at the bottom of your PATH to allow comprehensive testing
on the platform using nmake.  But that workaround (which historically
has worked once for Arjen when he was testing an MSVC environment with
no free software libraries) makes testing life a bit tricky so you may
want to just stick with pure MSYS2 instead.

Alan
__________________________
Alan W. Irwin

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.org); 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] Possible Windows development agendas for the next 6 months

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

Hi Alan, Jim, Arjen

I will try and sort that submitted patch asap.

I will also experiment with MSYS2 - I now have a windows laptop at
work and need a linux-like system on there. I did intend to use the
Ubuntu Bash on Windows System, but my IT dept seem to have blocked
this - at least for now. So I may try MSYS2 ather than Cygwin.

I would also like to get the wxWidgets driver sorted as you described.
This is time limited unfortunately.

Just a note about MSVC, what are the ABI concerns you have? It is of
note that GCC for windows does not provide ABI forward compatibility
https://stackoverflow.com/a/23521099. My understanding is that MSVC's
C ABI is consistent across versions and I just did a quick google and
found that for C++ MSVC2015, 2017 and 2019 are all ABI compatible.
https://devblogs.microsoft.com/cppblog/cpp-binary-compatibility-and-pain-free-upgrades-to-visual-studio-2019/

Interestingly it looks like Microsoft is also developing some sort of
open source library packaging system, called Vcpkg, to reduce the
existing pain of having to build all open source libraries from
scratch https://devblogs.microsoft.com/cppblog/vcpkg-a-tool-to-acquire-and-build-c-open-source-libraries-on-windows/.
Might be worth looking into. Had a quick scan down the list of
available libraries and Cairo, Pango, Curl, wxWidgets are there. HA HA
- JUST CHECKED AND SO IS PLPLOT!!! At version 5.13.

Phil

On Thu, 13 Jun 2019 at 00:10, Alan W. Irwin <Ala...@gm...> wrote:
>
> On 2019-06-12 12:27-0700 Alan W. Irwin wrote:
>
> >> On 2019-06-11 17:29-0400 Jim Dishaw wrote:
> >> I think the earliest version of windows we should
> >> support is win7. Keeping XP support will be a challenge.
> >
> > According to <https://en.wikipedia.org/wiki/Windows_XP>, XP was introduced in
> > 2001, Microsoft
> > quit fundamental support for it in 2014, and the percentage of Windows users
> > who
> > are still using it has dropped to ~2 per cent as of a few months ago.  So
> > yes, I am fine
> > with us dropping XP support as well.
>
> I have just discovered my answer above did not go far enough because I
> forgot XP was followed by Vista which was followed by Windows 7.  From
> <https://en.wikipedia.org/wiki/Windows_Vista> Vista share of the
> Windows market is down to 0.5% while from
> <https://en.wikipedia.org/wiki/Windows_7> the Windows 7 share is still
> at 33% with both numbers sampled just a few months ago.  So I agree we
> should drop support for both XP AND Vista now so that the earliest
> version we should support is Windows 7.
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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.org); 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 mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [EXTERNAL] Re: Patch for PLPLOT

[Alan W. I. <Ala...@gm...>]

On 2019-06-13 16:31-0000 Daniel Eliason wrote:

> Hi Alan,
>
> Unfortunately I made mistakes in the commit messages of the patches - here they are again, but I edited the messages.  The correct messages mention the "acc" parameter, and that artifacts appear when the "acc" parameter is set false.

Hi Daniel:

I am Ccing the plplot-devel list because other PLplot developers there may
be interested in these changes.

I have pushed (see
<https://sourceforge.net/p/plplot/plplot/ci/9394d4358f9dc385d38e052311adfd5b557625f5/>
and
<https://sourceforge.net/p/plplot/plplot/ci/7cd47798470a816c083d4c706f3c2ff23272aff4/>)
your two commits, and these two changes will become part of the next
release of PLplot (currently planned in early December this year).

I left the first commit (memcpy to memmove) exactly as it was because
it is obviously a good change in general.  However, it might interest
you to know that this commit did not change results here at all (with
or without a local change to make acc true both places in example
17). From this evidence on my platform (and also a hint in the man
page that some platforms do this) I believe that memcpy is implemented
on Debian as an alias of memmove, but from your results (as given by
your spectacularly bad screenshots of example 17 results without your
changes) that is obviously not the case for CentOS.

I have modified your second ("commentary and style") commit as follows:

* Styled your commit with our standard script.  The net effect of this
   modification was to move to our desired "//" form of commentary.

* Removed three of your changes where either it was obvious to me the
   the effect of your change would be to actually change the result or
   where I was not sure what the effect would be.  The motivation for
   dropping those changes is I discovered that the effect of your
   unmodified commit changed results here, but that issue (for what
   purports to be a style and commentary change) disappeared when I
   dropped your 3 problematic changes.

Please test the git master tip version from the SF git server yourself
now, and if it turns out you actually need one or more of your 3
dropped changes, we can add another commit to that effect with an
explanation why that further change is necessary.  And if you have any
other desired change you would like to make to PLplot, please contact
me again directly (or ideally on the plplot-devel mailing list for the
reason given above).

Best wishes,

Alan

__________________________
Alan W. Irwin

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.org); 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] Possible Windows development agendas for the next 6 months

[Alan W. I. <Ala...@gm...>]

On 2019-06-12 12:27-0700 Alan W. Irwin wrote:

>> On 2019-06-11 17:29-0400 Jim Dishaw wrote:
>> I think the earliest version of windows we should 
>> support is win7. Keeping XP support will be a challenge.
>
> According to <https://en.wikipedia.org/wiki/Windows_XP>, XP was introduced in 
> 2001, Microsoft
> quit fundamental support for it in 2014, and the percentage of Windows users 
> who
> are still using it has dropped to ~2 per cent as of a few months ago.  So 
> yes, I am fine
> with us dropping XP support as well.

I have just discovered my answer above did not go far enough because I
forgot XP was followed by Vista which was followed by Windows 7.  From
<https://en.wikipedia.org/wiki/Windows_Vista> Vista share of the
Windows market is down to 0.5% while from
<https://en.wikipedia.org/wiki/Windows_7> the Windows 7 share is still
at 33% with both numbers sampled just a few months ago.  So I agree we
should drop support for both XP AND Vista now so that the earliest
version we should support is Windows 7.

Alan
__________________________
Alan W. Irwin

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.org); 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] Possible Windows development agendas for the next 6 months

[Alan W. I. <Ala...@gm...>]

On 2019-06-11 17:29-0400 Jim Dishaw wrote:

> I found this in my spam--sorry for the delay and sorry for too posting. I'll take a look at the list and work a plan of action.  My quick read is that it should be doable. I think the earliest version of windows we should support is win7. Keeping XP support will be a challenge.

Hi Jim:

I hope you can figure out a way to tune up your spam filters so PLplot
traffic is not interfered with.  The spam filter I use is
called [SpamBayes](http://spambayes.sourceforge.net), and it works
well for me.

In any case, I am glad you reviewed your spam folder and as a result we
are now back in e-mail contact again.

According to <https://en.wikipedia.org/wiki/Windows_XP>, XP was introduced in 2001, Microsoft
quit fundamental support for it in 2014, and the percentage of Windows users who
are still using it has dropped to ~2 per cent as of a few months ago.  So yes, I am fine
with us dropping XP support as well.

@Jim: I am glad to hear you think this agenda is doable for you during
this release cycle (especially when not worrying about XP support).

Alan
__________________________
Alan W. Irwin

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.org); 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] Possible Windows development agendas for the next 6 months

[Alan W. I. <Ala...@gm...>]

This post is Windows-centric so it is principally directed to our
developers with access to Windows (Arjen, Phil, and Jim).

I have decided that the release of 5.16.0 should be near December 1st this
year to stick close to the 6-month-long release cycle that worked so well for
the 5.15.0 release.

MinGW-w64/MSYS2 (MSYS2 for short), Cygwin, and MSVC are the three
Windows platforms that are of interest to us, and I would like to
summarize here some comments I have made before for each of these
platforms since that information is so relevant to the Windows
development plans for PLplot that I will be discussing below.

* MSYS2.  This is our primary Windows platform since it supplies most
   of the free software libraries in Windows native form (i.e., no link
   to msys2.dll that turns executables/libraries into non-native form)
   that provide PLplot with its power and *always* (since there is no X
   wrapper implemented for MSYS2) displays results efficiently using
   native Windows display functionality.  Because of this capability
   interactive comprehensive testing on this platform should be
   reasonably quick, but nobody has actually tried that yet.  On the
   other hand, for 5.15.0 Arjen supplied good noninteractive
   comprehensive test results (see
   <https://sourceforge.net/p/plplot/wiki/Testing_Reports/>) for this
   platform which demonstrate its excellent quality (at least for the
   noninteractive case) for the needs of our Windows users.

* Cygwin.  This is a secondary platform for us because all Cygwin
   libraries are non-native (i.e., linked to cygwin.dll to give
   non-native behaviour) and some of its free software display
   libraries (IIRC wxwidgets is a definite example of this issue, and
   pango/cairo and Qt may also have the same display issue) have been
   packaged incorrectly (in my view) to perform their display via a
   slow/inefficient X wrapper for Windows display rather than the
   direct Windows display capability that is available for all of these
   free software display libraries.  As a result, Arjen has found via
   one attempt in the past that *interactive* comprehensive testing on
   Cygwin is effectively impossible because the X-wrapped display
   functionality is so incredibly slow.

* MSVC is generally a low priority for us since ABI issues limit what
   free software libraries can be used on this platform so as a result
   PLplot is quite weak on this platform.  The exception, of course, is
   Phil has gotten our wxwidgets components to work with a wxwidgets
   library he downloaded? or built? on this platform that apparently
   was ABI compatible with the MSVC compiler.  Also, in the past Arjen
   has had success adding both library power and bash
   power to this platform by putting MSYS2 libraries and bash on
   his PATH.  But that mode is likely too complex for users so is
   only likely useful for the important comprehensive testing of this platform
   that can be done by knowledgeable PLplot developers.

@Arjen, Phil, and Jim:

I acknowledge all of you have told me in the past about your severe
family and job time constraints that leaves very little time for
PLplot, but having said that, I nevertheless assume all of you will
still have at least some time to work on PLplot during this 6-month
release cycle so during that precious limited time for PLplot you
should set good priorities.  Here are my ideas about what your
individual PLplot priorities should be, but, of course, if you prefer
other PLplot priorities for yourself during this next 6 months, please
let me know what those are!

@Arjen:

Here are the priorities I believe you should have in reverse priority
order.  Of course, if you think these priorities should be reordered
or there are more important ones that I forgot, please let me know.

1. Although Cygwin is of secondary importance some users do attempt to
    use PLplot on this platform.  Therefore, I think your immediate
    priority for this release cycle should be to finish up your
    comprehensive testing efforts on Cygwin that you tried to complete
    before the 5.15.0 release.  Time is of the essence (which is my
    motivation for giving this effort a high priority) since although
    you did not complete this effort in time for the 5.15.0 release, it
    is almost as good to complete it as soon as possible after the
    5.15.0 release to reassure Windows users (with finalized results
    mentioned at
    <https://sourceforge.net/p/plplot/wiki/Testing_Reports/>) that
    at least noninteractive PLplot-5.15.0 is as good on Cygwin as it is on MSYS2.

2. Update all our MSYS2-related wiki pages based on your recent good
    experiences with this platform. I think this project will take
    advantage of your good English technical writing skills, and
    up-to-date wiki information will also be extremely useful in
    helping both Phil and Jim to get started with this platform (see
    their priorities below).

3. Be prepared (via at least one preliminary testing effort this summer) to
    "turn the crank" to replicate your current good MSYS2 comprehensive
    test just before we release 5.16.0 on or near December 1st.

4. Comprehensively test the MSVC platform?  I put a question mark by
    that priority since this platform is not of primary importance to
    us.  Nevertheless, just to remind you, you were able to create a
    good comprehensive test of this platform a long time ago by putting
    native MSYS2 libraries and MSYS2 bash on your PATH (to add PLplot
    power and especially bash testing power to the otherwise low-power
    MSVC platform), and it "would be nice" if you can replicate that
    good MSVC result again for 5.16.0.

5. Package PLplot on Cygwin??  This is an even lower "would be nice"
    priority.  However, See remarks about why there is a need for this
    packaging effort that I recently made at
    <https://sourceforge.net/p/plplot/feature-requests/16/>.

@Phil:

Here are the priorities I believe you should have in reverse priority
order.  Of course, if you think these priorities should be reordered
or there are more important ones that I forgot, please let me know.

1. Deal with <https://sourceforge.net/p/plplot/patches/34/>.

2. Become familiar with our primary Windows platform, MSYS2.  You have
    already told me off-list that you would be willing to do this, and
    I think this release cycle would be an excellent time for you to
    achieve this goal not only for your own personal benefit (because this
    really is a powerful PLplot platform) but also to ease the testing
    burden carried by Arjen right now and also to eventually extend the
    scope of his current testing (i.e., by including interactive tests
    in the comprehensive test script that you run).
    See <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/> for the details
    concerning testing PLplot including how to run the comprehensive test script.

    A very good source of information for the MSYS2 platform is
    <https://github.com/msys2/msys2/wiki> and links you can follow from
    there that should make it easy to install the basic version of this
    platform and enhance it by using the pacman installer to install
    all the native Windows libraries provided by MSYS2 that provide
    extra power to PLplot.  For example, pango/cairo, Qt, and wxwidgets
    libraries already provide good noninteractive results (or have the
    potential to do so in the wxwidgets case, remember the wxpng device
    driver) and should potentially also provide rapid, high-quality
    interactive results for comprehensive tests.

3. This one is a cross-platform issue rather than just limited to
    Windows.  Fix the wxwidgets device so that its display event loop
    checks to see whether the plot commands in the buffer have been
    extended and adds those plot commands to the display of the plot
    whenever such an extension occurs rather than waiting until the
    buffer of all plot commands for a given page is complete before
    running all those plot commands.  This fundamental improvement for
    new wxwidgets should bring the new wxwidgets device in line with
    the old wxwidgets device as well as the wincairo (or xcairo on
    Linux) and qtwidget interactive devices.  For all those other
    interactive device alternatives the -np (no pause) option works
    properly, and the 17th example displays like a video as the plot
    unfolds rather than just plotting the final plot for the page.
    (You should be able to prove this for yourself by trying the
    wincairo and qtwidget devices on MSYS2 for example 17).  In sum,
    this fundamental change to the new wxwidgets device needs to be
    done before it can gain those same good -np and 17th example
    display results showed by the other interactive devices.

4. Help with packaging PLplot for MSYS2?  Of course, Arjen could
    likely be able to do this instead of you, but it is a good way to
    take some of the load off him, and it should not be that big a
    burden for you since packaging on this platform is really simple.

    See my recent comments at
    <https://sourceforge.net/p/plplot/feature-requests/16/> concerning
    the importance of such binary packaging.  I should add here that my
    old estimate of binary package use of PLplot (via the fraction of
    Debian users that used it actively each month on Debian) was very
    roughly 100000 users when you apply that fraction to an estimate
    of the free software desktops in the world while downloaders of our source code typically
    are only ~5000 per release according to SF statistics.  So that
    comparison is quite rough, but the important point is binary package
    users of PLplot far outweigh those who build PLplot from source which
    is why I view binary packaging to be so important
    for PLplot.

    From the MSYS2 wiki reference above, you can discover that
    packaging for MSYS2 is really quite simple, and there is already a
    very good start on that at
    <https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-plplot>
    to help you further.  However, if you just look at the PKGBUILD
    file there you should notice some problematic configuration issues
    (relying on the gd library and associated png and jpeg device
    drivers that have been deprecated for a very long time, and
    dropping (!) the high-quality qt device driver that is working so
    well for Arjen).  So once you are familiar with building PLplot on
    MSYS2, you should be able to give Alex (the primary MSYS2 developer
    and also the author of the PLplot package for that platform) some
    good advice (through patches to that PKGBUILD file and testing the
    effect of those changes on the plplot binary package results) about
    how to substantially improve that PLplot package.

@Jim:

Here are the priorities I believe you should have in reverse priority
order.  Of course, if you think these priorities should be reordered
or there are more important ones that I forgot, please let me know.

1. Phil has already told me he is willing to give MSYS2 a try so
    I hope you are in as well during this release cycle.  See topic
    2. in my remarks to him.

2. Deal with <https://sourceforge.net/p/plplot/bugs/195/>.  My feeling
    is there is a reasonable chance you can replicate this guy's Cygwin
    issue on MSYS2 (since MSYS2 is a fork of Cygwin), and if that
    proves to be the case, that should provide some essential help
    to your effort to fix this bug.

3. If the wingdi device is anything like my memory of the wingcc
    device results long ago when I was testing that device on Wine, it
    has problems with the -np option and example 17.  See topic 3 in my
    remarks to Phil about a similar issue for the wxwidgets device and
    the MSYS2 interactive device comparisons he can use to discover the
    correct behaviour of all interactive devices.  And if you verify
    this bug for wingdi on MSYS2, it would be great if you could also
    come up with a fix for it.  But I would not bother with fixing
    wingcc in this regard since I hope we will be able to retire that device
    driver soon (see below).

4. Enhance the wingdi device so it can properly handle UTF-8 text?
    This is the obvious and long-discussed next step for this device that would allow us
    to permanently retire wingcc so I hope you have some time during
    this release cycle to finish off this topic.

@ Arjen, Phil, and Jim:

Don't take what I said too seriously above because my Windows experience
is from quite a while ago on the Wine platform with MinGW/MSYS (as opposed
to the modern alternative to that ancient platform, MinGW-w64/MSYS2).
But I do hope to stir up some discussion from you three PLplot developers
with access to Windows.  So I am looking forward to your individual
replies to my remarks above.

Alan
__________________________
Alan W. Irwin

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.org); 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] My recent PLplot support-request triage

[Alan W. I. <Ala...@gm...>]

For the information of the PLplot developers, I have recently gone
through all the open/pending support requests at
<https://sourceforge.net/p/plplot/support-requests/> and changed the
status to "closed" with a comment of "too old" for all the support
requests that were more than two years old since I don't think any of
those (two-years old or more!) support requests can possibly be
relevant to modern PLplot.

That triage left just 4 open/pending support requests where one of
them was an obvious bug report which I moved to our bug reports, and
the 3 remaining ones I have classified as pending since either the
discussion of the support topic appears to be over, or we are waiting
for more feedback from the originator of the support request.

Alan
__________________________
Alan W. Irwin

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.org); 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] plplot-5.15.0 has been released

[Alan W. I. <Ala...@gm...>]

Dear PLplot developers:

I have now released 5.15.0.  See my recent post to plplot-general for
the details concerning that release.

I wish to thank Arjen Markus for his important testing work on
Windows and others here for their indirect contributions via bug
reports, using the git master tip version to make sure it is always
working for your particular needs, participating in development
discussions, etc.

Please take a critical look at plplot.org.  That site has been
regenerated and uploaded as part of the recent release process by me,
and I have clicked on all links mentioned on the site to insure we
have no dead links.  However, I am pretty used to the site so I may be
missing some obvious issue so if you take an independent look you may
find something that needs changing.

Of course, the freeze for pushing commits to SF is now over so I
encourage you to mature your git topic branches and push those as well
as push bug fixes as soon as possible in this new release cycle to
maximize the time we can test such changes during this current release
cycle which I currently plan will be something like 6 months long.

Good luck with your PLplot development and testing during this new
release cycle!

Alan
__________________________
Alan W. Irwin

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] Current status of the PLplot-5.15.0 release process

[Alan W. I. <Ala...@gm...>]

Here is the current status of the PLplot-5.15.0 release process.

N.B. the freeze (with a few well-understood exceptions) on pushes of
source code or build system changes will continue until this release
process is completed.

My apologies that some personal distractions delayed my further work
on this release until today.  However, today I did make some
substantial progress which was to finalize (commit
plplot-5.14.0-47-g4baf2b49a) the release notes for 5.15.0 based on my
review of all the commit messages during this release cycle.

All the rest of the steps in the release process should be largely
mechanical, and you should be able to follow those on git as I do
them.  Therefore, I hope to release PLplot-5.15.0 in another day or
two without further status reports like this one concerning how close
I am to reaching that goal!  :-)

Alan
__________________________
Alan W. Irwin

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 mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel