File: ChangeLog.release

package info (click to toggle)
plplot 5.14.0%2Bdfsg-3
links: PTS, VCS
area: main
in suites: buster
size: 30,424 kB
sloc: ansic: 79,613; xml: 28,583; cpp: 20,037; ada: 19,456; tcl: 12,081; f90: 11,423; ml: 7,276; java: 6,863; python: 6,792; sh: 3,185; perl: 828; lisp: 75; makefile: 48; sed: 33; fortran: 5
file content (6079 lines) | stat: -rw-r--r-- 275,343 bytes
commit 9e618c0b187ffe2a274a93b55287b46b9f43ffa7
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Dec 11 17:56:32 2018 -0800

    Prep for 5.14.0: Update instructions followed by the release manager for this release

M	README.Release_Manager_Cookbook

commit 8a75fe2bfec38935e83a9f096e5179ff9cd0c96f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Dec 11 17:28:30 2018 -0800

    Prep for 5.14.0: Update the release tarball generating script
    
    These changes were to change to the JOBS paradigm used for
    other scripts to deal with parallel make processing, and
    changing the way the make verbosity level is controlled
    (using VERBOSE=1 make option rather than the -DCMAKE_VERBOSE_MAKEFILE=ON
    cmake option).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Testing) by running the script and testing its results as
    documented in README.Release_Manager_Cookbook.

M	scripts/make_tarball.sh

commit eb440dda1de4ae74919d3778dadca383445c302d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Dec 11 14:58:53 2018 -0800

    Prep for 5.14.0: RELEASE_DATE=2018-12-12 and adjust for new version of plplot-doc-check
    
    This update of RELEASE_DATE is consistent with the expected UTC date of the 5.14.0 release
    and affects only the generated website documentation.
    
    The new version (thanks to Hal Wang for this) of castxml-ready
    plplot-doc-check code was required because the old version of that
    code used the gccxml app which is not available for Debian Testing
    because it has been completely superseded by castxml.  So this change
    is part of the overall project to make PLplot consistent with the
    modern versions of free software.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Testing) by building a local version of the website using
    
    time (echo irwin$'\n'irwin$'\n'merlin$'\n'/home/irwin/public_html/plplot$'\n'yes |scripts/generate_website.sh)
    
    and checking that the generated documentation had the correct release date.
    
    In addition, PLplot was configured with the cmake option
    -DADD_SPECIAL_CONSISTENCY_CHECKING=ON which configures the
    check_api_xml_consistency target.  Building that target runs
    the castxml-ready plplot-doc-check appropriately.  Building
    that target with an artificially introduced local api.xml
    inconsistency quickly identified that inconsistency.  So
    this golang app seems to be a good one for finding such inconsistencies.
    Finally, building that target without an introduced inconsistency
    showed api.xml is consistent with plplot.h which is a good thing
    to establish since it means our DocBook-generated documentation
    concerning our API is consistent with our actual API!

M	doc/docbook/src/CMakeLists.txt

commit c1871353a12195f7b0df10d5875623f27375dc6b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Dec 11 11:20:00 2018 -0800

    Prep for 5.14.0: Fix release critical bug introduced by commit plplot-5.13.0-47-g124a0c3a2
    
    This bug was initially exposed by example 3 where all graphical elements were lost
    in the results leaving only text that was plotted regardless of device.  But later I discovered any
    use of a non-zero -ori option for any of the rest of the examples also triggered this
    same loss of all graphical elements in plotted results regardless of device.  I used
    
    make -j16 x01c ; make -j16 cairo
    examples/c/x01c -dev xcairo -ori 0.001
    
    as a test case and discovered via git bisect that
    commit plplot-5.13.0-47-g124a0c3a2 was the first
    to show the bad behaviour.  One component of that
    commit was bogus since it changed from calculating
    
    plsc->diclpxmi, plsc->diclpxma, plsc->diclpymi, and
    plsc->diclyma to (incorrectly) calculating those same
    values for the incorrect plsc elements,
    plsc->clpxmi, plsc->clpxma, plsc->clpymi, and
    plsc->clyma.  Assuming the original code was correct,
    for this commit, I have reversed that part of commit plplot-5.13.0-47-g124a0c3a2
    and discovered that solves the above "-ori 0.001" issue (i.e., all graphical
    elements were restored) and also solves the same issue with
    
    examples/c/x03c -dev xcairo
    
    Furthermore, commit plplot-5.13.0-47-g124a0c3a2 fixed a
    different rendering issue (missing graphical elements) in
    
    examples/c/x33c -dev wxwidgets
    
    that did not occur for any other device.  But it turns out the present
    commit preserves the good rendering for the above example as well as
    for -dev xwin, -dev xcairo, and -dev qtwidget.  And I also tried
    
    examples/c/x01c -locate -dev wxwidgets -ori 0.1
    
    and
    
    examples/c/x33c -dev wxwidgets -ori 0.1
    
    with perfect interaction for example 1, and perfect resizing and rendering for both
    examples.
    
    So I think I have found the fix for this bug with no deep
    understanding of why this fix works except that not updating
    plsc->diclpxmi, plsc->diclpxma, plsc->diclpymi, and plsc->diclyma
    exactly like before commit plplot-5.13.0-47-g124a0c3a2 inside
    calc_didev screws up all rendering when that routine is called (e.g.,
    by the chain of calls plsdiori => pldi_ini => calc_diori =>
    calc_didev).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Testing) by doing the rendering tests described above for example 1, example 3
    and example 33 and by running
    
    COMPREHENSIVE_TEST_PREFIX="/home/software/plplot/HEAD/comprehensive_test_disposeable blank"
    time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.13.1/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "$COMPREHENSIVE_TEST_PREFIX" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON -DPLD_extqt=OFF" --build_command "make -j16" --ctest_command "ctest -j16"  --do_submit_dashboard yes)
    
    where -DUSE_INCRTCL_VERSION_4=ON is needed on this Debian Testing
    platform to find Tcl/Tk, and -DPLD_extqt=OFF is needed to skip
    comprehensive tests of qt_example and pyqt5 which sometimes segfault
    in ways that will be investigated post-release.
    
    The above command was followed by the evaluation procedure of
    comprehensive test results documented in
    doc/wiki_source/Testing_PLplot.  That evaluation showed there were no
    configure, build, or obvious run-time errors (i.e., no non-zero return
    codes for any of the steps in this comprehensive test), and the
    difference test results were perfect.
    
    I also regenerated the local version of the website using
    
    time (echo irwin$'\n'irwin$'\n'merlin$'\n'/home/irwin/public_html/plplot$'\n'yes |scripts/generate_website.sh)
    
    and that local website passed all tests documented in
    README.Release_Manager_Cookbook including that the example 3
    screenshot had its graphical elements rendered correctly (where
    the lack of those was the first symptom to set off this bug hunt).

M	src/plcore.c

commit b5108131ff70561d843296945493595f116f8752
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Dec 10 23:51:30 2018 -0800

    Prep for 5.14.0: update handling of parallel build option in scripts used for website update
    
    Previous to this change, we used in these scripts
    an undocumented
    
    PARALLEL_BUILD_OPTION=-j10
    
    or for htdocs-gen_plot-examples.sh we used the incorrect (so I
    have no idea how it worked before without the hyphen)
    
    PARALLEL_BUILD_OPTION=j10
    
    and later in these two scripts we used the style
    
    make $PARALLEL_BUILD_OPTION <targetname>
    
    to handle parallel builds.  But now we use a different style in these
    two scripts which is setting a well-documented value of
    
    JOBS=16
    
    and later in these two scripts we used the style
    
    make -j$JOBS <targetname>
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Testing) by testing local website generation (which uses these
    two scripts) as documented in README.Release_Manager_Cookbook.
    
    N.B. That local website testing found a release-critical bug in
    anything to do with reorientation of plots in the PLplot core library
    which was exposed by example 3 losing all graphical elements so only
    text was left in the plot.  That bug will be addressed next.

M	scripts/generate_website.sh
M	scripts/htdocs-gen_plot-examples.sh

commit c8f41d3197941be632df054674e970e7b17e9cdd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Dec 10 13:47:46 2018 -0800

    Prep for 5.14.0 release: Update swig documentation to be consistent with DocBook documentation
    
    I implemented this change by configuring PLplot with
    -DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the
    check_swig_documentation target.  I checked differences between the
    build-tree version of swig_documentation.i that is generated by that
    target and the older source-tree version.  That diff looked good so I
    copied the build-tree version on top of the source-tree version.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Testing) by configuring PLplot with
    -DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the
    check_swig_documentation target without issues (after the above copy).
    I used "git diff" to evaluate the changes to the source-tree version
    of swig_documentation.i, and I also ran the python and octave
    documentation tests decribed in doc/docbook/README.developers to
    confirm the changes seemed appropriate.
    
    N.B. The Python test showed a (likely long-standing) indentation issue
    in the Python documentation that is associated with the <parameter>
    DocBook tag.  This issue will need further investigation after the
    5.14.0 release.

M	bindings/swig-support/swig_documentation.i

commit 2ac040345edbd84ab004359cbc4cb0397c75f2af
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Dec 10 13:02:17 2018 -0800

    In preparation for the 5.14.0 release, make check_plplot_h.inc target build without deprecation warnings
    
    This commit is also part of the overall upgrade of PLplot to be
    consistent with the modern free software stack (Debian Testing in this
    case).  In this case to stop the deprecation warnings by modern OCaml
    software we adjusted the OCaml logic in touchup.ml to replace the
    deprecated String.lowercase with String.lowercase_ascii.  We made sure
    that this is the only place where we used this deprecated function
    using
    
    software@merlin> find . -type f |grep -v .git |xargs grep String.lowercase
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Testing) by building the check_plplot_h.inc target without
    any warnings or errors.

M	bindings/ocaml/touchup.ml

commit ee1583dece821e68a46be0b4d9114c9a376d2b82
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Dec 10 12:55:04 2018 -0800

    In preparation for the 5.14.0 release, update the instructions for testing our DocBook documentation
    
    This commit is also part of the overall upgrade of PLplot to be consistent with
    the modern free software stack (Debian Testing in this case).

M	doc/docbook/README.developers

commit c89b873fd89f87a8648669f5799321750a63690d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Dec 9 17:08:22 2018 -0800

    Tweak wording: two option ==> two options

M	doc/docbook/src/api.xml

commit 8c92f45af92112d70ec7063f6e2abf61d86e4d3d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Dec 9 14:27:32 2018 -0800

    Update from doxygen 1.8.8 to 1.8.13 in preparation for the release of 5.14.0
    
    This commit is also part of the overall upgrade of our free software
    dependencies to Debian Testing (currently the same as Debian Buster)
    which is a rolling release whose free software versions are typically
    close to the latest upstream releases.  (For example,
    <http://www.doxygen.nl/download.html> states the latest doxygen
    release right now is 1.8.14 so doxygen 1.8.13 that is packaged by
    Debian Testing is behind that upstream version but not by very much.)
    
    To upgrade our doxygen configuration to 1.8.13, I followed
    the directions in (the updated) doc/README.doxygen and executed
    
    doxygen -u Doxyfile.in
    
    I also updated the testing directions in doc/README.doxygen.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Testing) by inspecting the Doxyfile.in change generated above
    with "git diff" and following the additional test directions in the
    updated doc/README.doxygen file.

M	doc/Doxyfile.in
M	doc/README.doxygen

commit 5cac57603d7137d16a2a76240be1c075ea940726
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Dec 9 01:26:11 2018 -0800

    Update version information in preparation for the 5.14.0 release
    
    In particular with regard to library version numbers I looked
    carefully at directory-selected git log and git diff results for this
    release cycle, e.g.,
    
    git log --name-status plplot-${old_plplot_version}..master bindings/fortran
    git diff --ignore-all-space plplot-${old_plplot_version}..master bindings/fortran
    
    to help decide whether one of our libraries was unchanged, had bug
    fixes with no API changes, had API additions, or had
    backwards-incompatible changes in the API, and then updated the
    library versions according to the
    [semantic versioning rules](https://semver.org/).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by using "git diff" to check for typographical
    errors in this change and also by running
    
    COMPREHENSIVE_TEST_PREFIX="/home/software/plplot/HEAD/comprehensive_test_disposeable blank"
    time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.13.1/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "$COMPREHENSIVE_TEST_PREFIX" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON -DPLD_extqt=OFF" --build_command "make -j16" --ctest_command "ctest -j16"  --do_submit_dashboard yes --do_test_interactive no)
    
    followed by the evaluation procedure documented in doc/wiki_source/Testing_PLplot
    
    That evaluation showed there were no configure, build, or obvious
    run-time errors (i.e., non-zero return codes for any of the steps in this
    comprehensive test), and the difference test results were perfect.

M	cmake/modules/plplot_version.cmake
M	www/examples.php

commit 472f35dc84a0cabc666889ef7b56250fd52231b8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Dec 8 21:20:59 2018 -0800

    Finalize the release notes for release 5.14.0
    
    These notes were finalized based on a preliminary version of our ChangeLog for
    this release.
    
    The above finalized release notes are stored in README.release.  I have
    also updated our cumulated release notes as follows:
    
    cat README.release README.cumulated_release > README.cumulated_release_new
    mv README.cumulated_release_new README.cumulated_release

M	README.cumulated_release
M	README.release

commit 6e7b51cae6609bb22a94074eb720b1b16e960970
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Dec 6 01:04:49 2018 -0800

    Interim update of README.release as part of the on-going release process for 5.14.0
    
    In preparation for the 5.14.0 release I added a number of sections to this document, and spell-checked everything.  However, there are likely four more sections to add corresponding to important
    changes made during this release cycle before this document is ready for the release of 5.14.0.

M	README.release

commit 39a15ae66c1429e9358bba3de9b5c5be5427891d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Dec 3 15:01:05 2018 -0800

    Add summaries of Alan's comprehensive tests for Debian Buster to our wiki Testing_Reports page
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by following the directions in README.developers to
    propagate all the markdown format file changes to our SF wiki and test
    them there.

M	doc/wiki_source/Testing_Reports

commit 920d3983bfaa1fd7157f5f9574305171ee30db86
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Dec 2 13:37:33 2018 -0800

    Fix some remaining wiki_source issues
    
    The command
    
    software@merlin> find . -name "*.png"
    ./doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_labels.png
    ./doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_bare.png
    ./doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Non_antialized.png
    ./doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Antialized.png
    
    shows that the recent wiki_source commits introduce *.png files for
    the first time into our git repository.
    
    This introduced two issues that were fixed in this commit.
    
    * I had to change .gitattributes to be consistent with the binary nature of those files.
    
      With the updated .gitattributes I got the following results
    
    doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Antialized.png: text: unset
    doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Non_antialized.png: text: unset
    doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_bare.png: text: unset
    doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_labels.png: text: unset
    
      Previous to that change the results were "auto" instead, and I was
      therefore concerned that those binary files had been corrupted when
      they were committed since the documentation of "auto" says that
      means git will change line endings (and therefore corrupt these
      binary files).  However, no such corruption occurred (see test
      below) so I was probably saved (before the .gitattributes change) by
      Linux native line endings = internal git repo line endings.
    
    * I had to change scripts/remove_trailing_whitespace.sh to ignore *.png files.
    
    This commit also solves three additional issues in doc/wiki_source
    
    * I updated README.wiki to refer to the definitive directions in README.developers for
      propagating markdown format changes in doc/wiki_source to our SF wiki.
    
    * The updated scripts/remove_trailing_whitespace.sh indicated there
      were trailing white space issues in some of the markdown format
      files.  Therefore, I instructed the script to remove the trailing
      white space in all of those.
    
    * I also discovered that the last few lines in some markdown format files were
      inconsistent with the others, e.g., no trailing 'nl' or two of those. This
      commit removes all those inconsistencies.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by downloading the *.png files again from the SF wiki
    and showing there were no differences compared to those same files in
    our git working directory, i.e., no corruption in the latter.  I
    also followed the directions in README.developers to upload all
    the markdown format file changes to SF.

M	.gitattributes
M	doc/wiki_source/Building_PLplot
M	doc/wiki_source/Configure_PLplot_for_cygwin
M	doc/wiki_source/Configure_PLplot_for_msys2
M	doc/wiki_source/Configure_PLplot_for_the_Visual_Studio_IDE
M	doc/wiki_source/Home
M	doc/wiki_source/Mac_OSX_Status
M	doc/wiki_source/MinGW-w64-MSYS2
M	doc/wiki_source/Overview_of_the_status_on_Windows
M	doc/wiki_source/README.wiki
M	doc/wiki_source/Testing_PLplot
M	scripts/remove_trailing_whitespace.sh

commit 46fb96f5f69ba594867356df652960bc6155b3e2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Dec 1 22:35:37 2018 -0800

    Build system bug fix: drop install of recently removed README.testing
    
    (A much newer version of this file is now named
    doc/wiki_source/Testing_Plplot, and along with the other files in that
    directory is not installed but instead used as the source of our SF
    wiki following the directions in README.developers.)
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by building the install target without errors.

M	CMakeLists.txt

commit 0d50e2a2aeb17b5408f55bae701a702f636b0c1a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Dec 1 18:31:10 2018 -0800

    Add summaries of Arjen's comprehensive tests for Cygwin and MinGW-w64/MSYS2 to our wiki Testing_Reports page
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by cutting and pasting the change to the SF edit GUI
    for our Testing_Reports wiki page; saving the results there; and
    testing them by making sure these two table entries were rendered
    correctly, looking at exact differences with the previous version
    using the SF history GUI for Home, etc.

M	doc/wiki_source/Testing_Reports

commit 4537147b35769bc749b8acabf2983b2185f87762
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Nov 30 13:50:49 2018 -0800

    Update our directions for developers
    
    Add a new section on how to update our wiki pages.  Also remove a redundant paragraph
    and tweak the writing.

M	README.developers

commit 38f41b6bf5e04977ba66a77d5a934954a1c96908
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Nov 30 11:32:46 2018 -0800

    Add references to Testing_PLplot and Testing_Reports to our wiki Home page
    
    Thanks, Arjen, for this good suggestion.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by cutting and pasting the change to the SF edit GUI for
    our Home wiki page, saving the results there, and testing them by making
    sure the new links from our home page were working, looking at exact differences
    with previous version using the SF history GUI for Home, etc.

M	doc/wiki_source/Home

commit fbf51065de293fb7c888fa3737864c64cf67fc0d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Nov 27 18:56:00 2018 -0800

    Tweak MinGW-w64-MSYS2 wiki page
    
    These tweaks consisted of spelling changes suggested by the
    ispell-buffer emacs command and updating the Test_Reports wiki item
    (the only wiki URL reference to that new wiki page), MYS2 wiki, and
    OpenWalnut wiki URL references.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by cutting and pasting the revised MinGW-w64-MSYS2
    file to the appropriate edit session of the corresponding wiki page at
    SF, and looking at the wiki results and history diff results generated
    from that edit session for any issues caused by these tweaks.

M	doc/wiki_source/MinGW-w64-MSYS2

commit f7bedc70ad0cab21d36208fa434e540576898ccf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Nov 26 22:47:18 2018 -0800

    Extensive further tweaking of the recently rewritten Testing_PLplot wiki page
    
    Fixed misspellings revealed by the emacs ispell-buffer command.
    Reviewed all URL's (which yielded tweaks for the CDash and our CDash
    server references which were in a wrong form).  To avoid rendering
    issues caused by markdown sensitivity to "*", "<", and ">" had to
    escape those characters as "\*", "&lt;", and "&gt;" when in ordinary
    text.  I also removed many "`" escapes that I previously used in text
    since those created an unwanted different rendering (dark background)
    of what was escaped that way.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by cutting and pasting the revised Testing_PLplot file
    to the appropriate edit session of the corresponding wiki page at SF,
    and looking at the wiki results generated from that edit session for
    any URL or rendering issues.

M	doc/wiki_source/Testing_PLplot

commit ee50dba3489bf15aa9c2626c22680061f16214f0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Nov 26 20:58:35 2018 -0800

    Complete rewrite of our Testing_PLplot wiki page
    
    This long-overdue rewrite included separating off the Testing reports into their own wiki page, Testing_Reports.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by cutting and pasting the (greatly) revised
    Testing_PLplot file and the added Testing_Reports file to appropriate
    edit sessions of our wiki pages at SF, and looking at the wiki results
    generated from those edit sessions for any obvious rendering issues
    caused, e.g., by "*" (rather than "\*") or "_$" (rather than "\_$") in
    text where the former form apparently has some markdown significance
    that needs to be escaped to get properly rendered results.

M	doc/wiki_source/Testing_PLplot
A	doc/wiki_source/Testing_Reports

commit 501ad3dcc22991d39fd92a49e63e6c0dcfc294fd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Nov 24 12:57:40 2018 -0800

    Move definitive source of the markdown version of our wiki pages from our SF wiki editing sessions to git control
    
    This change provides automatic backup and (git) version
    control of our wiki markdown source files, and it allows our developers to
    use the editor of their choice to edit these files.
    
    This change was implemented by inserting the following boilerplate header
    
    -----------------8<-------------------
    <!---
    N.B.  The definitive Markdown source of this file is located in the
    doc/wiki_source subdirectory of the PLplot source tree.  So only use
    the ctrl-v and delete capabilities of the GUI file editor at
    SourceForge to make changes to the SourceForge version of this file,
    where ctrl-v is used to complete a cut and paste from the definitive
    version of this file in the PLplot source tree that is being edited
    with your favorite file editor, and delete used to remove extraneous
    unmodified text whose changed form has been copied with the cut and
    paste.
    -->
    -----------------8<-------------------
    
    at the start of each of the SF markdown sources of our wiki pages
    (accessible by editing each of our wiki pages at SourceForge) then
    using that SF editor to select all text and use the legacy ctrl-c cut command for that
    edit session to start a cut and paste to the equivalent file in the
    doc/wiki_source subdirectory of our source tree.
    
    Note that README.testing was an older version of Testing_PLplot
    created in the same way.  So by copying the modern version of that
    file to doc/wiki_source/Testing_PLplot by the above procedure and by
    deleting README.testing we have effectively moved README.testing to
    doc/wiki_source/Testing_PLplot and updated it to the latest SF
    version.

D	README.testing
A	doc/wiki_source/Additional_notes_for_ifort_users
A	doc/wiki_source/Apply_a_patch
A	doc/wiki_source/Aquaterm
A	doc/wiki_source/Building_PLplot
A	doc/wiki_source/Building_PLplot_with_a_cross-compiler
A	doc/wiki_source/CMake_options_for_PLplot
A	doc/wiki_source/Cairo_pango
A	doc/wiki_source/Configuration_of_wxWidgets_driver
A	doc/wiki_source/Configure_PLplot_for_Borland_CXX_5.5_(free_command_line_tools)
A	doc/wiki_source/Configure_PLplot_for_Borland_Turbo_C++_Explorer_Edition_(free_IDE_and_compiler)
A	doc/wiki_source/Configure_PLplot_for_MinGW_CLI
A	doc/wiki_source/Configure_PLplot_for_Visual_CXX_CLI
A	doc/wiki_source/Configure_PLplot_for_cygwin
A	doc/wiki_source/Configure_PLplot_for_msys2
A	doc/wiki_source/Configure_PLplot_for_the_Visual_Studio_IDE
A	doc/wiki_source/Debugging_code
A	doc/wiki_source/Documenting_the_undocumented
A	doc/wiki_source/Freetype
A	doc/wiki_source/Frequently_Asked_Questions
A	doc/wiki_source/General_CMake_documentation_links
A	doc/wiki_source/Git_miscellanea
A	doc/wiki_source/Home
A	doc/wiki_source/Install_3rd_party_libraries
A	doc/wiki_source/Install_Lua
A	doc/wiki_source/Install_MinGW_MSYS
A	doc/wiki_source/Install_Octave
A	doc/wiki_source/Install_Python
A	doc/wiki_source/Install_SWIG
A	doc/wiki_source/Install_Tcl
A	doc/wiki_source/Libgd
A	doc/wiki_source/Linux
A	doc/wiki_source/List_of_Debian_Ubuntu_packages
A	doc/wiki_source/Lua
A	doc/wiki_source/Mac_OSX
A	doc/wiki_source/Mac_OSX_Status
A	doc/wiki_source/MinGW-w64-MSYS2
A	doc/wiki_source/OCaml_tutorial
A	doc/wiki_source/Overview_of_the_status_on_Windows
A	doc/wiki_source/Qhull
A	doc/wiki_source/Qt
A	doc/wiki_source/README.wiki
A	doc/wiki_source/Setup_Visual_Studio_Express
A	doc/wiki_source/Setup_cygwin
A	doc/wiki_source/Setup_mingw
A	doc/wiki_source/Setup_visualc
A	doc/wiki_source/Setup_watcom
A	doc/wiki_source/Specifics_for_various_platforms
A	doc/wiki_source/Submit_a_patch
A	doc/wiki_source/Swig
A	doc/wiki_source/Testing_PLplot
A	doc/wiki_source/Third-party_libraries
A	doc/wiki_source/Todo_List
A	doc/wiki_source/Using_PLplot
A	doc/wiki_source/WxWidgets
A	doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Antialized.png
A	doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Non_antialized.png
A	doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_bare.png
A	doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_labels.png

commit 48a56ee63d25d24eeb44f392025953a6e9cc6b3f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Oct 19 13:45:01 2018 -0700

    Fix octave test script and example familied file bugs exposed by -DPLPLOT_TEST_DEVICE=svg and -DPLPLOT_TEST_DEVICE=svgcairo
    
    The symptom of these bugs was that octave examples 14a and 31 were
    missing from the PLplot test device diff report for both
    -DPLPLOT_TEST_DEVICE=svg (the default) and
    -DPLPLOT_TEST_DEVICE=svgcairo.  The "14a" fix was to use the correct
    file2 name in the test script for example 14, and to use "plSetOpt(
    "fflen", "2" );" in the 14th example to follow what is done for the
    corresponding C example.  The "31" fix was to change the 31st example
    to drop "Test setting / getting familying parameters across plinit "
    and "Test setting / getting page parameters across plinit" tests which
    had long since been dropped from the standard 31st example for all
    other languages.  (That first test interfered with familying so that
    the plot file output by octave example 31 was misnamed).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by building the test_diff_device target for
    either -DPLPLOT_TEST_DEVICE=svg (the default) or -DPLPLOT_TEST_DEVICE=svgcairo.
    
    The difference report results showed the warnings about missing 14a
    and 31 for octave were removed.  As a result, the svg difference
    report results are now perfect, and the svgcairo difference report
    results are now reduced to
    
    java
      Missing examples            :
      Differing graphical output  :  24
      Missing stdout              :
      Differing stdout            :
    octave
      Missing examples            :
      Differing graphical output  :  00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 14a 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 33
      Missing stdout              :
      Differing stdout            :
    python
      Missing examples            :
      Differing graphical output  :  09 24
      Missing stdout              :
      Differing stdout            :
    tcl
      Missing examples            :
      Differing graphical output  :  03 14a 24
      Missing stdout              :
      Differing stdout            :
    
    Most of the octave graphical differences for svgcairo are due to trivial renaming of
    surface id's, e.g.,
    
    software@merlin> diff examples/test_examples_output_dir/x00[co]01.svgcairo
    109c109
    < <g id="surface1">
    ---
    > <g id="surface66">
    
    I attribute these octave id issues to the octave examples being run from one octave session
    rather than separate octave sessions.
    
    Also, at least some of the non-octave differences are due to trivial
    glyph id changes, i.e., when I looked at the java differences for
    example 24 two glyphs had the same contents as the corresponding C
    result, but different names, and when the name differences were
    accounted for, the order of the glyph definitions in the header of the
    svg file was different between java and C.  (Are these glyph changes
    perhaps due to different threads taking longer/shorter for each
    different language?)
    
    In sum, I think the svgcairo test device is telling us a lot about
    pango/cairo library idiosyncrasies but nothing useful about PLplot
    issues so I intend to ignore svgcairo from now on and instead stick
    with the default svg test device choice since that does give a perfect
    difference report.

M	examples/octave/x14c.m
M	examples/octave/x31c.m
M	plplot_test/test_octave.sh.in

commit 9f53302538879a7113b11de822dd917fda38ac2d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Oct 8 01:24:29 2018 -0700

    Build system upgrade: Generalize how test_diff.sh is implemented and used in our test frameworks
    
    The test_diff.sh(.in) configured script has long been implemented to
    allow comparing results for our standard set of 33 examples
    implemented in any of our language bindings with corresponding C
    results as a test of the PLplot API consistency for each of our
    language bindings.  Up to now that script was configured to allow
    either psc or svg as the device used for the comparison of plot file
    results with rather specific implementation details for the familied
    (separate files for separate pages of examples) svg device.  The svg
    alternative was only usable for our CTest-based test framework
    (through the user specifying -DPLPLOT_TEST_DEVICE=psc or
    -DPLPLOT_TEST_DEVICE=svg) with our CMake-based and traditional (based
    on Makefiles + pkg-config) test frameworks completely ignoring this
    potential choice and always using psc for the comparisons instead.
    
    With this commit all these limitations concerning test_diff.sh have
    been removed.  If the user makes an error so that the specified
    PLPLOT_TEST_DEVICE does not correspond to a enabled file device then
    the build-system response to this error is that test_diff.sh will be
    unused by our three test frameworks.  But if PLPLOT_TEST_DEVICE
    corresponds to an enabled file device, then whether this device is
    familied is automatically detected by the build system, and the device
    and familied information passed on to the updated test_diff.sh via the
    --device and (new) --familied_device options.  The updated
    test_diff.sh implementation automatically accounts for all device and
    familied details depending on the values of those two options.  And
    test_diff.sh is run in the same way for all our three (CMake-based,
    CTest-based, and traditional) test frameworks.  In sum, users should
    be able to specify (via PLPLOT_TEST_DEVICE) any enabled file device,
    and all our standard examples in all supported languages should be run
    for that device with results compared by test_diff.sh for any or all
    of our three test frameworks.
    
    N.B. An important change for this commit is to use "svg" rather than
    "psc" as the default value of PLPLOT_TEST_DEVICE.  These two devices
    share the advantage of having no dependencies and thus being
    immediately available on all platforms.  The SVG XML format of the
    plot file output by the svg device file constitutes a small advantage
    over the PostScript format of the plot file output of the psc device
    because (at least in this author's opinion) SVG XML is fundamentally
    easier for humans to learn than PostScript.  But an even stronger
    advantage of the svg device is it is a modern PLplot device that
    implements alpha-channel transparency and gradients and which gives
    access to virtually all (unicode-accessible) glyphs installed on a
    platform while the psc device is an ancient PLplot device that because
    of the limitations of PostScript is missing the alpha-channel and
    gradient capabilities and which only gives access to an extremely
    limited number of glyphs.  Thus, when the svg device is used for
    comparisons, test_diff.sh compares one good plot file result with
    another for essentially all examples (see below for the one
    exception), but when the psc device is used for comparisons
    test_diff.sh compares one garbage plot file with missing or incorrect
    elements with another for many of our standard examples.  This means
    the svg default choice we have adopted supplies a much stronger
    constraint on our language PLplot API consistency than the old psc
    default.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by running
    
    time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.7.2/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "ctest -j10" --do_test_interactive no --do_submit_dashboard yes)
    
    once to test the default case of the complete set of Linux devices with the default PLPLOT_TEST_DEVICE=svg and
    
    time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.7.2/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON -DDEFAULT_NO_DEVICES=ON -DPLD_<device_name>=ON -DPLPLOT_TEST_DEVICE=<device name>" --build_command "make -j10" --ctest_command "ctest -j10" --do_test_interactive no)
    
    7 different times with <device_name> set to ps, psc, psttf, psttfc, svg, svgqt, or svgcairo to test
    the case when the indicated devices were enabled individually.
    I also ran this test again for the svgqt case and -DENABLE_octave=OFF.
    
    The first of these comprehensive tests yielded three good dashboard
    results (corresponding to the ctest execution in the core build tree
    for our 3 major configurations) at
    <https://my.cdash.org/index.php?project=PLplot_git> on 2018-10-07.
    
    I took a look in detail at the svg results and the results for all
    examples other than example 3 rendered correctly when viewed with the
    eog SVG browser. So as referred to above, svg is much better in this
    regard than psc which has badly rendered results for quite a large
    number of our examples because of the limitations of PostScript.
    
    The svg issue with example 3 is that certain graphical elements are
    missing consistently for all our supported languages.  They are also
    missing if that example is viewed with other SVG browsers such as the
    konqueror and firefox browsers and the "display" application available
    from the ImageMagick software suite (which by the way only works
    correctly for SVG if inkscape is installed as well.)
    
    Those elements for example 3 are also missing for the svgqt and
    svgcairo devices so it is certainly possible that our fundamental C
    API implementation that is exercised directly by C standard example 3
    (and also indirectly by our other language bindings and example 3
    implementations in those languages) is attempting to draw the missing
    graphical elements of this example in a way that is not compatible
    with the SVG standard.  But a lot more investigation and a
    much-simplified test example will likely be required to figure that
    out.
    
    The total of the 9 different comprehensive tests above were evaluated
    in the usual manner (see previous commit messages for details and also
    a future commit for README.testing which will document the usual
    evaluation procedure for comprehensive test results).
    
    In all but two cases there were no configuration or run-time issues
    with these comprehensive tests.  Those two exceptions were the following:
    
    1. Intermittent javac segfault.  This only happened one time, and I
    could never replicate it afterwards.  However, a valgrind run (with
    the recommended for java --smc-check=all option to allow valgrind to
    follow all self-modifying code changes that apparently are common for
    java) for exactly the same (openjdk) javac command that segfaulted
    when compiling x27.java into byte code showed 10 million memory
    management issues before valgrind reached its limits and quit checking
    any further.  So it appears the openjdk javac command is potentially a
    rich source of segfaults, and the only surprise is how little it
    happens!  In any case, I don't think this is our problem so if I ever
    run into this issue again, I will simply repeat the test with a good
    chance it will succeed.
    
    2. Repeatible errors with the combination of svgqt and octave
    
    On Debian Buster at least, octave examples and the svgqt device (or any
    other qt device) are a toxic combination with consistent error
    messages typically like:
    
    (process:17721): GLib-CRITICAL **: 13:36:35.133: g_main_context_pop_thread_default: assertion 'g_queue_peek_head (stack) == context' failed
    double free or corruption (out)
    fatal: caught signal Aborted -- stopping myself...
    
    From <https://bugs.launchpad.net/calibre/+bug/1022019> it appears
    similar errors for the calibre software project were generated by glib
    library inconsistencies.  However, from ldd -r on
    bindings/octave/plplot_octave.oct and other evidence it appears that
    octave does not depend on libglib so perhaps there is something about
    the octave examples that exposes a bug in libqt or else a bug in the
    qt device driver.  Anyhow, I plan to investigate this issue further
    by attempting to determine which octave example generates the above
    message.
    
    There were a large variety of plot different reports for the additional
    wide range of test device possibilities enabled by this commit.
    
    For PLPLOT_TEST_DEVICE=psc or ps, the difference report was perfect
    (i.e., this commit has not introduced any regressions into the psc
    result used before, and ps follows that perfect result.)
    
    For PLPLOT_TEST_DEVICE=psttfc or psttf the difference report was
    
    octave
      Missing examples            :
      Differing graphical output  :  07 24
      Missing stdout              :
      Differing stdout            :
    
    For PLPLOT_TEST_DEVICE=svg the difference report was
    
    octave
      Missing examples            :  14a 31
      Differing graphical output  :
      Missing stdout              :
      Differing stdout            :
    
    For PLPLOT_TEST_DEVICE=svgcairo the difference report was
    
    java
      Missing examples            :
      Differing graphical output  :  24
      Missing stdout              :
      Differing stdout            :
    octave
      Missing examples            :  14a 31
      Differing graphical output  :  00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 33
      Missing stdout              :
      Differing stdout            :
    python
      Missing examples            :
      Differing graphical output  :  09 24
      Missing stdout              :
      Differing stdout            :
    tcl
      Missing examples            :
      Differing graphical output  :  03 14a 24
      Missing stdout              :
      Differing stdout            :
    
    For PLPLOT_TEST_DEVICE=svgqt with -DENABLE_octave=OFF the difference report was
    
    ocaml
      Missing examples            :
      Differing graphical output  :  28
      Missing stdout              :
      Differing stdout            :
    
    In sum, the generalization of the test_diff.sh testing provided by
    this commit provides a powerful new tool to expose issues with our
    bindings and or standard examples for each of our supported languages.
    The above difference report results show no regressions with the
    previous psc results and constitute the best new difference reports we
    can generate at the present time and are a benchmark for future
    changes for all the new diff report test devices that are enabled by
    this commit.  Of course, it is also obvious from these results there
    is clearly a lot of of work to do (especially for the octave binding
    and examples) to reach an important new goal motivated by this commit
    which is difference-free results for all languages for all these
    different test devices.

M	cmake/modules/drivers-finish.cmake
M	cmake/modules/plplot.cmake
A	cmake/modules/test_diff.cmake
M	examples/CMakeLists.txt
M	examples/Makefile.examples.in
M	examples/plplot_configure.cmake_installed_examples.in
M	plplot_test/CMakeLists.txt
M	plplot_test/test_diff.sh.in
M	plplot_test/test_octave.sh.in

commit 115cedd8378bf7627263f0f2c2d7831a0714566a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Oct 5 16:40:51 2018 -0700

    Configure both the ps and psttf device drivers like all other device drivers
    
    Previous to this commit the ps device driver configured its devices
    (i.e., the ps and psc devices) together rather than individually and
    the same for the psttf device driver and the corresponding psttf and
    psttfc devices.  All other device drivers configured their devices
    individually and this anomalous ps and psttf situation generated a lot
    of extra build-system complexity.  We inherited this bad situation
    from our previous autotools-based build system and never addressed
    this issue until this commit which configures both the ps and psttf
    device drivers to implement individual devices just like all the rest of
    our device drivers.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by running
    
    time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.7.2/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "ctest -j10" --do_test_interactive no)
    
    once to test the default case of the complete set of Linux devices and
    
    time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.7.2/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON -DDEFAULT_NO_DEVICES=ON -DPLD_<device_name>=ON" --build_command "make -j10" --ctest_command "ctest -j10" --do_test_interactive no)
    
    5 different times with <device_name> set to ps, psc, psttf, psttfc, and svg to test
    the case when the invidual devices for the ps and psttf device drivers were enabled
    and when none of the devices for the  ps and psttf device drivers were enabled.
    
    These 6 different comprehensive tests were evaluated in the usual
    manner (see previous commit messages for details and also a future
    commit for README.testing which will document the usual evaluation
    procedure for comprehensive test results).  In all cases there were no
    configuration, run-time, or PostScript difference (when the psc device
    was implemented) issues detected so I feel confident that the current
    set of rather intrusive changes has introduced no regressions.

M	cmake/modules/drivers-init.cmake
M	cmake/modules/pstex.cmake
M	cmake/modules/psttf.cmake
M	drivers/ps.c
M	drivers/ps.driver_info.in
M	drivers/pstex.c
M	drivers/psttf.cc
M	drivers/psttf.driver_info.in
M	examples/CMakeLists.txt
M	examples/Makefile.examples.in
M	include/drivers.h
M	include/plDevs.h.in
M	include/plcore.h
M	include/ps.h
M	plplot_test/CMakeLists.txt
M	plplot_test/plplot-test.sh.in

commit 58df034d4ea4682d911b419e296819aa5a8ba242
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Oct 5 16:03:28 2018 -0700

    Build system: Fix undefined LIB_INSTALL_RPATH bug for the Python binding
    
    In bindings/python/CMakeLists.txt we determined and immediately used
    LIB_INSTALL_RPATH in a first context but used that value in a second
    context as well.  And the conditions of that second context differed
    sometimes (e.g., if only a single device was enabled) from that first
    context leaving LIB_INSTALL_RPATH undefined for that second context.
    I fixed this bug by determining and immediately using
    LIB_INSTALL_RPATH independently for the second context.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by running scripts/comprehensive_test.sh for
    a single device (svg) without issues.  Details of this and other
    tests I ran will be given for the next commit.

M	bindings/python/CMakeLists.txt

commit e36a423fe0927987119bb94459750039737b47f3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Sep 26 01:49:27 2018 -0700

    Remove unused data/.dummy file
    
    git log --follow -- data/.dummy
    
    shows this empty file was originally committed in 1992 with a comment
    that it was a placeholder, but nothing has been done with it since
    other than to change its directory location.  Therefore, the current
    removal is long overdue.

D	data/.dummy

commit 2682d15f9ffd6b53e630e6c9b35200680dea2ed3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Sep 26 00:48:00 2018 -0700

    Fix external URL references for the website
    
    I completely checked every external URL reference for
    our website and found only the HomeBrew reference on the
    Downloads page and the libgd reference on the Credits
    page were dead/invalid.  This commit updates those
    references to valid sites again.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster> by following the (recently updated) instructions in
    README.Release_Manager_Cookbook to regenerate the local website,
    and then I checked that website to make sure the above two references
    linked to the desired sites.

M	www/credits.php
M	www/downloads.php

commit cf236a23c28c17dbf9e53667a9c7488d4ac357c9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Sep 26 00:25:20 2018 -0700

    Update scripts and instructions for generating local version of website
    
    The scripts to help generate the website were updated with commentary
    tweaks and an update to all make commands to use the
    PARALLEL_BUILD_OPTION bash variable which was set to "-j10" at the
    start of each script.  This value is suitable for my new hardware with
    8 cores but could easily be modified by someone else with different
    hardware whenever I step down as release manager.
    
    I updated the instructions for the apache install and configuration
    and instructions for the website generation for the release manager in
    README.Release_Manager_Cookbook.  That file was also updated with all
    references to "raven" (my old computer) replaced by "merlin" (my new
    computer) and all references to Debian Jessie (the Debian version on
    my old computer) replaced by Debian Buster (the Debian version on my
    new computer).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by following the above apache install and
    configuration instructions and the above website generation
    instructions.  I did not do any of the detailed error checking that is
    recommended for a release, but the result appeared to be a valid local
    website that I could easily browse with the konqueror and firefox
    browsers.

M	README.Release_Manager_Cookbook
M	scripts/generate_website.sh
M	scripts/htdocs-gen_plot-examples.sh

commit 8fdfe5cabd5320e9787583fcd2e984cb4bb14dbf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Sep 23 23:57:27 2018 -0700

    Report PostScript difference results in alphabetical order of languages
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by building the test_diff_psc target and confirming
    the (perfect) PostScript difference report is now alphabetized by language.

M	plplot_test/test_diff.sh.in

commit d6a76270499d393452df5cf36255bed2693891b3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Sep 23 22:59:55 2018 -0700

    Build system: for Mac OS X drop user overide that imposes the dated -single_module linking option
    
    Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring PLplot with cmake with no errors due to
    this change.  However, that is just a minimal test (since this removed
    override was a no-op on Linux) so the definitive test of this change
    is requested on Mac OS X platforms.

M	CMakeLists.txt
D	cmake/UserOverride.cmake

commit d2d9461a3ce3516c98611852879467e5cf0b8265
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Sep 22 16:40:32 2018 -0700

    Build system: allow consistent use of a build of Lua that is installed in a non-standard location
    
    I also made the cmake messages emitted by the Lua part of the configuration more informative.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring PLplot using
    
    env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 "/home/software/cmake/install-3.7.2/bin/cmake" ...
    
    where /home/software/lua/install-5.3.5 is the install prefix of a local build of Lua-5.3.5
    
    The result was consistent non-system versions of the lua library and executable were found.  Furthermore,
    I tested that result using
    
    make -j10 test_diff_psc >& test_diff_psc.out
    
    with no build or run-time errors and a perfect PostScript difference report
    (for all components including lua).

M	cmake/modules/lua.cmake

commit 4a5f94a70ac259d696dfaa8117cead7ad89b13f3
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Sat Sep 22 11:57:05 2018 +0100

    Changed order of some wxwidgets headers to avoid compilation bug
    
    Compile errors of wxwidgets_dev.cpp were reported on vs2017 by
    Laurent Berger, with many errors looking like
    
    1>c:\program files (x86)\windows
    kits\10\include\10.0.16299.0\shared\ws2def.h(235): error C2011:
    'sockaddr': 'struct' type redefinition
    1>c:\program files (x86)\windows
    kits\10\include\10.0.16299.0\um\winsock.h(1007): note: see declaration
    of 'sockaddr'
    1>c:\program files (x86)\windows
    kits\10\include\10.0.16299.0\shared\ws2def.h(437): error C2059: syntax
    error: 'constant'
    1>c:\program files (x86)\windows
    kits\10\include\10.0.16299.0\shared\ws2def.h(437): error C3805:
    'constant': unexpected token, expected either '}' or a ','
    
    You can find the discussion on the plplot-devel mailing list with title
    cannot compile plplot using vs 2017.
    
    The suspicion is a wierd interaction with the wx headers and the
    windows.h header included in our wxwidgets_comm.h file. It seems
    that ensuring wx/wx.h is included before windows.h avoids the
    problem.

M	drivers/wxwidgets.h

commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Sep 20 22:36:48 2018 -0700

    Build system: Improve logic for finding Lua
    
    There are two improvements:
    
    * Instead of blacklisting Lua5.3 (due to what turns out to be a
      run-time issue for that version of Lua that occurs on Debian Buster
      but not Fedora) do the following:
    
      If the user has specified REQUIRED_LUA_VERSION on the command line
      (e.g.  -DREQUIRED_LUA_VERSION=5.2 to avoid 5.3), then search
      specifically for that version of Lua.  Otherwise, do a search for
      Lua without specifying a version which means CMake will find the
      latest version of Lua that is installed.
    
    * If possible find the lua executable using the versioned name, e.g.,
      "lua5.2" that is consistent with the Lua version found, but if that
      versioned name is not found, then find the unversioned name "lua" of
      the executable as a last resort.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by running cmake with various values (or none) of
    -DREQUIRED_LUA_VERSION to make sure a consistent version of Lua is
    found in all cases (or no version is found if the REQUIRED_LUA_VERSION
    string does not correspond to an installed version of Lua).

M	cmake/modules/lua.cmake

commit a9d9500c732d4eae47ed7fca687e02ec8a48d02c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Sep 19 16:38:53 2018 -0700

    Build system: Future-proof use of FindPkgConfig by replacing call to _pkg_check_modules_internal with pkg_check_modules
    
    The previous use of _pkg_check_modules_internal was "an accident
    waiting to happen" since such logic obviously depends on an internal
    implementation detail of CMake's FindPkgConfig module while
    pkg-check_modules is for public use and therefore more stable.  And
    although CMake-3.12.2 was fine in this regard, that accident did
    happen for the git version of CMake that will turn into version
    3.13.0, and this commit solves this "future" issue.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster on my AMD Ryzen 7 1700 box) by running
    
    time (nice -19 env PATH="/home/software/cmake/Dashboards/Scripts/My Tests/CMake-build/Tests/CMakeInstall/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "ctest -j10")
    
    The combination of running the script from a source tree with blanks
    in the prefix (see above invocation) and the above --prefix option
    containing a blank tests that the current build system continues
    support for blanks in source-, build-, and install-tree prefixes; and
    the "-DUSE_INCRTCL_VERSION_4=ON" cmake option is appropriate for the
    software versions of Tcl/Tk/Itcl/Itk/Iwidgets that I have installed
    from Debian Buster.  Furthermore, I only have Qt5 development packages
    installed so only the Qt5 version of the qt device driver is tested
    here.
    
    The above setting of PATH accesses the git (CMake commit ddb33b)
    version of CMake and CTest that was tested successfully by hand using
    the PLplot contract build test earlier today.  However, the above test
    does a lot more than that simple PLplot build and install test so it
    is much more "comprehensive" test both of PLplot and CMake.
    
    The above script ran both interactive and noninteractive tests for
    direct use of my graphics card (i.e., not for an X-terminal) and
    completed (in 46 minutes) without running into any hangs or non-zero
    return codes, and the accompanying test results were evaluated as
    follows:
    
    # Check for all errors where that last pipeline stanza is to ignore
    # normal "ldd" references to the gpg-error library and normal "make
    # clean" references to test.error:
    
    grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'libgpg-error.so|test.error'
    
    # Check for regressions in configuration warnings:
    
    grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
    
    # Check for regressions in the distinct run-time warning labelled by
    'PLPLOT WARNING':
    
    grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
    
    # Check for build or run-time warnings where the trailing stanza is to
    # remove the "PLPLOT WARNING" and cmake.out warnings investigated
    # above, and spurious gfortran warnings:
    
    find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0 grep -i warning |grep -vE 'PLPLOT WARNING|cmake.out|PRIVATE|argv_dynamic'
    
    # Check for any ldd issues for the shared and nondynamic cases:
    
    grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
    
    # Check for any PostScript or Text differences between all non-C
    # languages and the corresponding C results:
    
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
    
    In sum, these checks of the above comprehensive test results showed no
    configure, build, run-time, or PostScript difference issues for the
    "future" version of CMake that was tested.

M	cmake/modules/cairo.cmake
M	cmake/modules/pkg-config.cmake

commit a730ebe34b9edd44124e0d217672e678ddd06eca
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Sep 15 02:38:42 2018 -0700

    Build system: fix OCaml build warnings for installed examples
    
    Previously there were warning messages emitted by Debian Buster (but
    not Debian Jessie) ocamlopt when linking the installed OCaml examples.
    These warnings took the following form:
    
    Warning 58: no cmx file was found in path for module Plplot, and its interface was not compiled with -opaque
    
    This commit solves this issue by installing plplot.cmx (as implied by
    the above warning message).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster on my AMD Ryzen 7 1700 box) in exactly the same way as
    my previous commit with only one change in the evaluation of the
    comprehensive test results, namely the above warning messages no
    longer occur.  Therefore, as far as I know, this commit removes the last "modern
    software" issue caused by building and testing PLplot in a Debian
    Buster = Testing environment rather than Debian Jessie = Oldstable
    environment that I was using for testing before.

M	bindings/ocaml/CMakeLists.txt

commit b10135855e7c2ae322a4fb4079398ff84eef80db
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Sep 14 15:18:06 2018 -0700

    Build system: fix regression in linking of libplplotqt
    
    This commit once again links libplplotqt with the plplot and math
    libraries for the Qt5 case to fix a regression introduced by my recent
    work on prefixing all the installed targets.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster on my AMD Ryzen 7 1700 box) by running
    
    time (nice -19 "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/home/software/cmake/install-3.7.2/bin/cmake" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "/home/software/cmake/install-3.7.2/bin/ctest -j10" --do_test_interactive no)
    
    The combination of running the script from a source tree with blanks
    in the prefix and the above --prefix option containing a blank tests
    the current build system continues support for blanks in source-,
    build-, and install-tree prefixes; and the
    "-DUSE_INCRTCL_VERSION_4=ON" cmake option is appropriate for the
    software versions of Tcl/Tk/Itcl/Itk/Iwidgets that I have installed
    from Debian Buster.  Furthermore, I only have Qt5 development packages
    installed so only the Qt5 version of the qt device driver is tested
    here.
    
    The above script completed (in 19 minutes) without running into any
    hangs or non-zero return codes, and the accompanying test results were
    evaluated as follows:
    
    # Check for all errors where that last pipeline stanza is to ignore
    # normal "ldd" references to the gpg-error library and normal "make clean"
    # references to test.error.
    
    grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'libgpg-error.so|test.error'
    
    # Check for regressions in configuration warnings:
    grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
    
    # Check for regressions in the distinct run-time warning labelled by 'PLPLOT WARNING':
    grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
    
    # Check for build or run-time warnings where the trailing stanza is to
    # remove the "PLPLOT WARNING" and cmake.out warnings investigated above,
    # and spurious gfortran warnings:
    
    find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0  grep -i warning |grep -vE 'PLPLOT WARNING|cmake.out|PRIVATE|argv_dynamic'
    
    This test revealed the following warning message regression which was a number of different instances
    of the following message:
    
    Warning 58: no cmx file was found in path for module Plplot, and its interface was not compiled with -opaque
    
    This warning which I attribute to a new version of OCaml for Debian
    Buster appears to not have any practical consequences (e.g., the clean
    PostScript differences reported below).  Nevertheless, I plan to
    investigate this warning at a later time.
    
    # Check for any ldd issues for the shared and nondynamic cases.
    grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
    
    No issues were found, i.e., this commit solves the regression in this
    regard found by the last several comprehensive tests.
    
    # Check for any PostScript or Text differences between all non-C languages and the corresponding
    # C results:
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
    
    In sum, these checks of the above comprehensive test results showed no
    configure, build, run-time, or PostScript difference issues other than
    the noted regression in non-consequential OCaml warnings which I will
    investigate later.

M	bindings/qt_gui/CMakeLists.txt

commit 0583fe8feb335c147f7951fe1bb4eb5e93a56317
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Sep 9 14:15:35 2018 -0700

    Build system: fix a bug in the use of the <TARGET_FILE:PLPLOT::pltcl> and $<TARGET_FILE:PLPLOT::plserver> generator expressions
    
    The fix was to use these generator expressions only when ENABLE_tkX was true
    since the shell script being configured only uses these locations for that
    case.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by setting the DISPLAY environment variable to nothing
    before configuring PLplot.  (An incorrect setting of DISPLAY in a
    crontab task to submit a PLplot contract dashboard for CMake first
    exposed these bugs).  For incorrect DISPLAY the Tk configuration of
    PLplot fails (softly) with the result that ENABLE_tkX is false, which
    means with this fix in place that the <TARGET_FILE:PLPLOT::pltcl> and
    $<TARGET_FILE:PLPLOT::plserver> generator expressions are not used
    which avoids the build-system error that occurred before this fix.

M	plplot_test/CMakeLists.txt

commit 7ec926fae5e17cbfc9ebb4c83144a8c7ef177cbb
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Sep 9 03:42:06 2018 -0700

    D examples: adjust so they compile for gcd-8
    
    These adjustments for the 21st example were to replace isnan by isNaN,
    and for the 31st example were to drop importation of std.cstream
    (because cstream no longer exists in libphobos for gdc-8) and to
    replace derr.writefln by stdderr.writefln everywhere.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by installing the gdc-8 and gnat-8 packages (to
    be consistent with the gcc-8 version being used) and running
    
    time (nice -19 "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/home/software/cmake/install-$CMAKE_VERSION/bin/cmake" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10" --do_test_interactive no)
    
    with CMAKE_VERSION = 3.7.2, 3.11.0, or 3.12.2 for a total of 3 script invocations.
    
    The combination of the above three invocations of the script from a
    software tree with blanks in the prefix and the above --prefix option
    containing a blank tests the current build system continues to test
    support for blanks in source, build, and install tree prefixes; the
    three versions of CMake correspond to the minimum version for the
    Linux platform, the minimum version for non-Linux platforms, and the
    latest current version of CMake; and the "-DUSE_INCRTCL_VERSION_4=ON"
    cmake option is appropriate for the software versions of
    Tcl/Tk/Itcl/Itk/Iwidgets that I have installed from Debian Buster.
    
    All three test script invocations completed without running into any hangs
    or non-zero return codes, and the accompanying test results were
    evaluated in each of the 3 cases as follows:
    
    # Check for all errors:
    grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'libG|libgpg-error.so'
    
    where that last pipeline stanza is to ignore routine libGL error messages
    issued by my X-terminal box and to ignore normal ldd references to the gpg-error library.
    
    # Check for regressions in configuration warnings:
    grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
    
    # Find each distinct run-time warning labelled by 'PLPLOT WARNING':
    grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
    
    # Check for build or run-time warnings:
    find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0  grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic|cmake.out|opaque'
    
    where the trailing stanza is to remove "PLPLOT WARNING" issues,
    spurious gfortran warnings, cmake.out warnings, and a number of instances
    of
    
    Warning 58: no cmx file was found in path for module Plplot, and its interface was not compiled with -opaque
    
    which appears, see below, to not have any consequences for the OCaml case.  Nevertheless,
    I plan to investigate this warning further.
    
    # Check for any ldd issues for the shared and nondynamic cases.
    grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
    
    I found a number of these for modern (Debian Buster) software which I plan to investigate later.
    
    # Check for any PostScript or Text differences between all non-C languages and the corresponding
    # C results:
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
    
    These checks of the above comprehensive test results showed no
    configure, build, run-time, or PostScript difference issues.  Thus,
    the install of gnat-8 seems to have solved all gnatmake parallel build
    issues I encountered before, and the install of gdc-8 (along with the
    above adjustments of the D examples) also appears to have worked
    perfectly.

M	examples/d/x21d.d
M	examples/d/x31d.d

commit 15d5829b94d79afbcddce3bd168dded0bcf85fa4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Sep 9 01:56:03 2018 -0700

    PLplot build system: bump minimum CMake version from 3.6.2 for all platforms to 3.7.2 for the Linux platform and 3.11.0 for non-Linux platforms
    
    The motivation for these changes is to reduce build-system bugs by
    forcing our users to use modern CMake (especially on non-Linux platforms where
    older versions of CMake can be problematic).
    
    With one exception, these minimum version choices mean that PLplot
    users on modern Linux platforms and the major modern non-Linux
    platforms should be able to rely on the official versions of CMake for
    those platforms.  The exception to this PLplot user convenience is
    Cygwin where the CMake packaging effort there has become moribund
    (i.e., stuck on CMake 3.6.2 for much too long a time for what is
    supposed to be a rolling release that keeps up with the latest free
    software versions).  Because of this packaging problem for CMake on
    Cygwin, this PLplot change means our Cygwin users will need to build
    their own CMake with version = 3.11.0 or greater before they build
    PLplot.
    
    See also the commentary in the top-level CMakeLists.txt file for
    details of the web sites checked for the CMake version that is
    officially installed for various platforms.
    
    I also took this opportunity to bump the minimum CMake version for
    other minor projects within the PLplot source tree to 3.7.2 or 3.11.0
    depending on whether for those projects I wanted to follow the
    minimum version adopted for PLplot for either the Linux platform
    or non-Linux platforms.

M	CMakeLists.txt
M	cmake/modules/language_support.cmake
M	cmake/modules/language_support/cmake/CMakeTestAdaCompiler.cmake
M	cmake/test_ada/CMakeLists.txt
M	cmake/test_ada/cmake/Modules/CMakeTestAdaCompiler.cmake
M	cmake/test_ada/installed_CMakeLists.txt
M	cmake/test_automoc/CMakeLists.txt
M	cmake/test_fortran/CMakeLists.txt
M	cmake/test_fortran/installed_CMakeLists.txt
M	cmake/test_linux_ipc/CMakeLists.txt
M	examples/CMakeLists.txt

commit d4ac55ea76fc7f5b514bc6e454b4c599dc048fde
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Sep 8 22:18:40 2018 -0700

    Build system: Blacklist Lua 5.3
    
    At least for Debian Buster, Lua 5.3 has a severe bug (see
    <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238>).  We
    previously worked around this upstream Lua-5.3 bug by dropping Lua
    example 23 (the only example that exposes this bug) from our tests,
    but for this commit we restore Lua example 23 for our tests, and
    simply blacklist Lua 5.3 instead.  As a result of this change we now
    support only Lua 5.1 and 5.2 (preferred if both 5.1 and 5.2 are
    available).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by installing Lua 5.2 and building the test_diff_psc
    target in the build tree (for the default shared library and dynamic
    devices case) for CMake versions 3.7.2, 3.11.0, and 3.12.2 where the
    first two versions are of future importance to our build system
    (respectively the planned minimum versions of CMake for Linux and
    non-Linux systems) and the third version is the current latest CMake
    version.  All results from these test_diff_psc builds showed no
    obvious configure, build, or run-time issues, and the PostScript
    difference results were perfect again because of restoration of Lua
    example 23 to our tests and the use of Lua 5.2 for both our Lua
    binding build and tests of our Lua examples.

M	cmake/modules/lua.cmake
M	plplot_test/test_lua.sh.in

commit 5c31678babaf99da755f48ef103aefe05c39a38c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Sep 8 19:10:23 2018 -0700

    Build system bug fix: set correct source file property on lib/csa/csa.c
    
    Previously when gcc was the C compiler, I set the source file property
    COMPILE_OPTIONS for lib/csa/csa.c to -fno-inline-functions to work
    around what appears to be an issue with gcc version 7.3.0-21 and now
    also 8.2.0 (where both versions tested were from Debian Buster) where
    the explicit (or implicit via -O3) use of the -finline-functions gcc
    option caused segfaults in the libcsirocsa library.  And this
    workaround was well-tested for CMake-3.11.x from Debian Buster.
    However, it turns out that COMPILE_OPTIONS is not recognized as a
    source file property for CMake-3.10.x and earlier so the workaround
    failed for those versions of CMake.
    
    This commit fixes this issue by setting the COMPILE_FLAGS rather than
    COMPILE_OPTIONS source file property to specify the
    -fno-inline-functions gcc option.  This should work for all CMake 3.x
    versions (although COMPILE_FLAGS is deprecated from CMake-3.11.x on).
    Because of that deprecation, the plan is to switch all mentions of
    COMPILE_FLAGS to COMPILE_OPTIONS once our minimum version of CMake on
    all platforms is 3.11.0 or higher.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by building the test_diff_psc target in the build tree
    (for the default shared library and dynamic devices case) for CMake
    versions 3.7.2, 3.11.0, and 3.12.2 where the first two versions are of
    future importance to our build system (respectively the planned
    minimum versions of CMake for Linux and non-Linux systems) and the
    third version is the current latest CMake version.  All results from
    these test_diff_psc builds showed no obvious configure, build, or
    run-time issues, and there were no regressions in the PostScript
    difference results.

M	lib/csa/CMakeLists.txt

commit e298aa70a1f5e30c55cbfd26488432ca17b1b75f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Aug 26 12:32:49 2018 -0700

    Build system: Implement NAMESPACE PLPLOT:: prefix for all installed targets
    
    This commit is the culmination of my previous work on core build
    prefixes (ALIASed PLPLOT:: prefix for read-only targets and the
    normally empty except when -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON
    ${WRITEABLE_TARGET} prefix for writeable installed targets) for all
    targets that will be installed.  Because of that previous work, and
    especially the core build tests that succeeded
    with-DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON proving all installed
    targets (*for CMake code that was exercised in those tests*) were
    prefixed, this commit ideally should have just contained one change
    (to use the NAMESPACE PLPLOT:: signature for the "install(EXPORT
    export_plplot ...)" CMake command.  However, the previous work
    (notably commit 0df4e30e6b on 2018-04-06) that implemented the core
    build change to use the PLPLOT:: prefix when referring to read-only
    targets meant that the installed version of PLplot could not be tested
    from then until now.  So this commit includes the following bug fixes
    for the installed version of PLplot:
    
    Prefix-related fixes:
    
    Change Tcl tests for CMake-based build system for installed examples
    from source tree to build tree.  This fix was needed because all the
    examples/c/x?? scripts became configured as part of the prefix
    changes.  At the same time the Tcl tests for the traditional build
    system for the installed examples are still for the case where source
    and build trees are the same so the core build system must configure
    examples/c/x?? script for this additional case as well.
    
    Fix blank-in-path quoting issues introduced by using configured target
    locations in plplot_test/plplot-test-interactive.sh(.in).
    
    Debian Buster versus Jessie fixes:
    
    The Debian Buster version of Qt5 demands that all executables
    (i.e. qt_example) that specifically links to the Qt5 libraries must be
    built with a special option (e.g., -fPIC on Linux systems).  This
    happens automatically for targets configured by CMake, but I had to
    change pc_qt_COMPILE_FLAGS to accomodate this need for our traditional
    (make and pkg-config) build system for the installed examples.
    
    Other fixes and improvements:
    
    Fixed bug for corner case where ENABLE_tkX was true and xwin_targets was false.
    
    Fixed bug where needed DROP_GTK_PLUS_2_BUILDS was not propagated to the CMake-based
    build system for the installed examples.
    
    Replaced EXAMPLES_DIR and SRC_EXAMPLES_DIR environment variable
    misnomers (and corresponding --examples-dir and --src-examples-dir
    script option misnomers) throughout our build system and test scripts by
    EXAMPLES_PREFIX and SRC_EXAMPLES_PREFIX (and corresponding
    --examples-prefix and --src-examples-prefix script options).
    
    Wrote plplot_test/README.developers to document test scripts.
    This documentation includes a much-needed explanation of
    how EXAMPLES_PREFIX and SRC_EXAMPLES_PREFIX are used.
    
    Added maintenance section to drivers/README.drivers to show how
    to make certain that the driver id numbers are unique and driver
    information is consistent.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by running
    
    "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/usr/bin/cmake" --cmake_added_options "-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10"
    
    where the combination of the above launch of the script from a
    software tree with blanks in the prefix and the above --prefix option
    containing a blank tests the current build system continues to
    test support for blanks in source, build, and install tree prefixes; the
    /usr/bin versions of cmake and ctest are the Debian Buster versions
    with version number of 3.11.2; and the "-DENABLE_ada=OFF
    -DUSE_INCRTCL_VERSION_4=ON" cmake options are appropriate for the
    software versions of (buggy) gnatmake and Tcl/Tk/Itcl/Itk/Iwidgets
    that I have installed from Debian Buster.
    
    The first invocation of the above command failed for the CMake-based
    interactive tests of the installed examples tree.  The failure message
    stated that a test was run using -dev plmeta (which, of course, should
    not work since that device is disabled by default and I double checked
    that was the case for this particular invocation of the comprehensive
    test script.  This error is an intermittent one (three attempts to
    replicate it afterwards including a second invocation of exactly the
    same command failed to show the error).  Furthermore, the error
    message is inexplicable since the confirmed disablement of the device
    should mean the device was not used for testing for anything, and the
    fact that it is a noninteractive device means it should not have been
    used for interactive testing in any case!  So this is indeed a nasty
    puzzle, but I plan to wait until the bug triggers again to investigate
    it further.
    
    This (second) test script invocation completed without running into any hangs
    or non-zero return codes, and the accompanying test results were
    evaluated as follows:
    
    # Check for all errors:
    grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'libG|libgpg-error.so'
    
    where that last pipeline stanza is to ignore routine libGL error messages
    issued by my X-terminal box and to ignore normal ldd references to the gpg-error library.
    
    # Check for regressions in configuration warnings:
    grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
    
    # Find each distinct run-time warning labelled by 'PLPLOT WARNING':
    grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
    
    # Check for build or run-time warnings:
    find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0  grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic|cmake.out'
    
    where the trailing stanza is to remove "PLPLOT WARNING" issues,
    spurious gfortran warnings and cmake.out warnings.
    
    This yielded a number of instances of the following warning
    
    Warning 58: no cmx file was found in path for module Plplot, and its interface was not compiled with -opaque
    
    which appears, see below, to not have any consequences for the OCaml case.  Nevertheless,
    I plan to investigate this warning further.
    
    # Check for any ldd issues for the shared and nondynamic cases.
    grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
    
    I found a number of these for modern (Debian Buster) software which I plan to investigate later.
    
    # Check for any PostScript or Text differences between all non-C languages and the corresponding
    # C results:
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
    
    There is a well-known upstream issue with lua5.3 software that is
    exposed by lua example 23 which we have worked around by dropping that
    example from the PostScript comparison test, but otherwise these
    checks of the above comprehensive test results showed no configure,
    build, run-time, or PostScript difference issues.

M	cmake/modules/plplot_functions.cmake
M	cmake/modules/qt.cmake
M	doc/docbook/README.developers
M	drivers/README.drivers
M	drivers/wingdi.driver_info.in
M	examples/CMakeLists.txt
M	examples/plplot_configure.cmake_installed_examples.in
M	examples/tcl/CMakeLists.txt
M	examples/tk/CMakeLists.txt
M	plplot_test/CMakeLists.txt
A	plplot_test/README.developers
M	plplot_test/plplot-test-interactive.sh.in
M	plplot_test/plplot-test.sh.in
M	src/CMakeLists.txt

commit beba481633e7ce148fc33386464b6a1b23f2b59b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Aug 3 23:32:11 2018 -0700

    Style previous commit

M	plplot_config.h.in

commit dd9699e5628309d4ee4a264d989c0868f5ef3dcd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Aug 3 23:17:03 2018 -0700

    Comprehensive test script: fix blank in fullpath bug
    
    The dirname logic used to obtain SCRIPT_PATH needed to be modified
    (using quotes) when the script was invoked using
    a fullpath to the script that included a blank, e.g.,
    
    "../plplot blank .git"/scripts/comprehensive_test.sh" ....
    
    used to invoke the script in the test of the last commit.
    
    Tested by: Alan. W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) with the script invocation described above.

M	scripts/comprehensive_test.sh

commit 94b5cf188d92b11920ad1998eda910e6e91992ae
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Aug 3 23:10:41 2018 -0700

    Build system: Finish the topic concerning special target prefixes for the build tree
    
    The add_executable and add_library targets that are built in the build
    tree and installed (as opposed to built) in the install-tree are
    special targets where special build-system rules are needed.  Best
    CMake practice is to install such special targets in name-spaced form
    (i.e., with a target prefix of PLPLOT::).  Because common CMake files
    are used by both the build-tree and installed-examples build systems,
    this also means that ALIASed targets with prefix PLPLOT:: must be
    defined in the build-tree build system for common targets for the two
    build systems.  Those common targets are read-only so for uniformity I
    have defined ALIASed targets to be used for all build-tree, read-only,
    special target cases.  And to make sure no unprefixed read-only
    special targets are left, I have also for the build-tree case used the
    ${WRITEABLE_TARGET} prefix for all special targets which are not
    read-only.  The side effect of this is all the associated executable
    and libraries files also have the same ${WRITEABLE_TARGET} prefix
    appear in their core name. Of course, you do not normally want that
    side effect so WRITEABLE_TARGET is undefined for the (default) case
    where -DUSE_WRITEABLE_TARGET_TEST_PREFIX=OFF.  However, if the
    build-tree build system user specifies
    -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON, then all unprefixed special
    targets *that are used in executed CMake code* (which is an important
    caveat) will generate a cmake error which will identify most but not
    necessarily all (because of that caveat) unprefixed special targets
    that still need to be addressed.
    
    A previous commit implemented such special target logic for all
    libraries, modules, and swig modules while this commit completes that
    work by dropping the hershey library (which does not qualify since it
    is not installed) from that list, and implementing such special target
    logic for the executables that qualify, i.e., just plserver, pltcl,
    plrender, pltek, and wxPLViewer.  In addition this commit changed many
    build system names committed as part of the previous prefix work that became
    obvious misnomers for this present case where special targets refer to
    both add_executable and add_library targets that qualify.  Because of
    these name changes, this commit is quite intrusive.
    
    N.B. This commit completes the topic of special target prefixes for
    the build-tree case.  And the test below (which uses
    -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON) applies to just the build-tree
    case alone.  I haven't considered it yet in detail, but, it is
    possible the installed results of the
    -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON case (where all the core names
    of relevant libraries and executables are prefixed) might be usable
    with some additional modifications.  If so; I might implement such
    modifications so that the -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON case
    works for all of build-tree, installed examples tree, and traditional
    installed examples tree cases; but only if the benefits justify the
    work involved.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by running
    
    "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/usr/bin/cmake" --cmake_added_options "-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10" --do_test_install_tree no --do_test_traditional_install_tree no --do_submit_dashboard no)
    
    where the combination of the above launch of the script from a
    software tree with blanks in the prefix and the above --prefix option
    containing a blank tests the current build system continues to
    support blanks in source, build, and install tree prefixes; the
    /usr/bin versions of cmake and ctest are the Debian Buster versions
    with version number of 3.11.2; the "-DENABLE_ada=OFF
    -DUSE_INCRTCL_VERSION_4=ON" cmake options are appropriate for the
    software versions of (buggy) gnatmake and Tcl/Tk/Itcl/Itk/Iwidgets
    that I have installed from Debian Buster;
    -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON tests special executable library
    and target names as I have explained above; and although (by default)
    both interactive and noninteractive comprehensive tests were done, I
    dropped all but build-tree tests for the reasons explained above.
    
    This test script invocation completed without running into any hangs
    or non-zero return codes, and the accompanying test results were
    evaluated as follows:
    
    # Check for all errors:
    grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -v libGL
    
    where that last pipeline stanza is to ignore libGL error messages
    issued by my X-terminal box.
    
    # Check for regressions in configuration warnings:
    grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
    
    # Find each distinct run-time warning labelled by 'PLPLOT WARNING':
    grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
    
    # Check for build or run-time warnings:
    find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0  grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic|cmake.out'
    
    where the trailing stanza is to remove "PLPLOT WARNING" issues,
    spurious gfortran warnings and cmake.out warnings.
    
    # Check for any ldd issues for the shared and nondynamic cases.
    # N.B. commented out this time because the above comprehensive_test.sh options
    # (--do_test_install_tree no --do_test_traditional_install_tree no)
    # preclude checking for ldd issues so there are no *.ldd.out files to
    # check.
    #grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
    
    # Check for any PostScript or Text differences between all non-C languages and the corresponding
    # C results:
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
    
    There is a well-known upstream issue with lua5.3 software that is
    exposed by lua example 23 which we have worked around by dropping that
    example from the PostScript comparison test, but otherwise these
    checks of the above comprehensive test results showed no configure,
    build, run-time, or PostScript difference issues.
    
    Because this test was a success with the above
    -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON cmake option, it appears there
    continues to be no special executable or library target references
    without prefixes (PLPLOT:: for read-only special targets and
    ${WRITEABLE_TARGET} for writeable special targets) for the CMake logic
    exercised by the above tests.

M	CMakeLists.txt
M	bindings/ada/CMakeLists.txt
M	bindings/c++/CMakeLists.txt
M	bindings/d/CMakeLists.txt
M	bindings/fortran/CMakeLists.txt
M	bindings/lua/CMakeLists.txt
M	bindings/lua/lua_namespace.i.in
M	bindings/ocaml/CMakeLists.txt
M	bindings/ocaml/plcairo/CMakeLists.txt
M	bindings/octave/CMakeLists.txt
M	bindings/octave/plplot_stub.m.in
M	bindings/python/CMakeLists.txt
M	bindings/qt_gui/CMakeLists.txt
M	bindings/qt_gui/pyqt4/CMakeLists.txt
M	bindings/qt_gui/pyqt5/CMakeLists.txt
M	bindings/qt_gui/smoke/plplotqt.pro.in
M	bindings/tcl/CMakeLists.txt
M	bindings/tk/CMakeLists.txt
M	bindings/wxwidgets/CMakeLists.txt
M	cmake/modules/drivers-finish.cmake
M	cmake/modules/plplot_functions.cmake
M	drivers/CMakeLists.txt
M	drivers/tk.c
M	drivers/wxwidgets_dev.cpp
M	examples/CMakeLists.txt
M	examples/fortran/CMakeLists.txt
M	examples/lua/plplot_examples.lua.in
M	examples/tcl/CMakeLists.txt
R051	examples/tcl/x00	examples/tcl/x00.in
R056	examples/tcl/x01	examples/tcl/x01.in
R051	examples/tcl/x02	examples/tcl/x02.in
R052	examples/tcl/x03	examples/tcl/x03.in
R051	examples/tcl/x04	examples/tcl/x04.in
R051	examples/tcl/x05	examples/tcl/x05.in
R051	examples/tcl/x06	examples/tcl/x06.in
R051	examples/tcl/x07	examples/tcl/x07.in
R051	examples/tcl/x08	examples/tcl/x08.in
R051	examples/tcl/x09	examples/tcl/x09.in
R051	examples/tcl/x10	examples/tcl/x10.in
R051	examples/tcl/x11	examples/tcl/x11.in
R051	examples/tcl/x12	examples/tcl/x12.in
R051	examples/tcl/x13	examples/tcl/x13.in
R057	examples/tcl/x14	examples/tcl/x14.in
R051	examples/tcl/x15	examples/tcl/x15.in
R062	examples/tcl/x16	examples/tcl/x16.in
R051	examples/tcl/x17	examples/tcl/x17.in
R069	examples/tcl/x18	examples/tcl/x18.in
R051	examples/tcl/x19	examples/tcl/x19.in
R051	examples/tcl/x20	examples/tcl/x20.in
R051	examples/tcl/x21	examples/tcl/x21.in
R051	examples/tcl/x22	examples/tcl/x22.in
R051	examples/tcl/x23	examples/tcl/x23.in
R069	examples/tcl/x24	examples/tcl/x24.in
R051	examples/tcl/x25	examples/tcl/x25.in
R069	examples/tcl/x26	examples/tcl/x26.in
R051	examples/tcl/x27	examples/tcl/x27.in
R051	examples/tcl/x28	examples/tcl/x28.in
R051	examples/tcl/x29	examples/tcl/x29.in
R051	examples/tcl/x30	examples/tcl/x30.in
R054	examples/tcl/x31	examples/tcl/x31.in
R069	examples/tcl/x33	examples/tcl/x33.in
M	examples/tk/CMakeLists.txt
M	fonts/CMakeLists.txt
M	include/plDevs.h.in
M	include/pldll.h.in
M	lib/csa/CMakeLists.txt
M	lib/csa/csadll.h.in
M	lib/nistcd/CMakeLists.txt
M	lib/nistcd/cddll.h.in
M	lib/nn/CMakeLists.txt
M	lib/nn/nndll.h.in
M	lib/qsastime/CMakeLists.txt
M	lib/qsastime/qsastimedll.h.in
M	plplot_config.h.in
M	plplot_test/CMakeLists.txt
M	plplot_test/plplot-test-interactive.sh.in
M	plplot_test/test_plrender.sh.in
M	plplot_test/test_tcl.sh.in
M	src/CMakeLists.txt
M	utils/CMakeLists.txt

commit 391ec0ad0a45b4e65e631d57218bbac1be5bf54c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Aug 1 12:46:40 2018 -0700

    Octave binding and examples: permanently fix issue with non-cell arrays of character strings
    
    After the previous cellstr workaround for this issue was committed, I
    discovered through further hex_print experiments that the issue with
    conversion of non-cell arrays of character strings to C strings had
    nothing to do with UTF-8, but instead any string (ascii or more
    general UTF-8) shorter than 15 bytes always worked and any such string
    longer than 15 bytes always failed (i.e., generated short C strings
    that were either 0 length or filled with non-valid UTF-8 characters).
    And when I reported that issue at <https://savannah.gnu.org/bugs/index.php?54415>,
    I got the following extremely useful response from Markus Mützel:
    
    <quote>
    Recently, gcc seems to have changed the lifetime of temporary strings
    that are not assigned to a variable. It looks like the C++ string
    returned by "row_as_string" is destroyed immediately after is is
    created. Thus, the reference to the C string array returned by "c_str"
    gets invalid. The memory at that location is no longer protected from
    being overwritten. The results of dereferencing that pointer is
    undefined.  You might be able to fix your code by explicitly assigning
    the C++ string returned by "row_as_string" to a variable for which you
    can control the scope.
    </quote>
    
    Accordingly I changed
    
    tmp_cstring = (char *) temp_matrix.row_as_string( i ).c_str();
    
    (where the tmp_cstring declaration was properly scoped)
    
    to
    
    str         = temp_matrix.row_as_string( i );
    tmp_cstring = (char *) str.c_str();
    
    (where both the str and tmp_cstring declarations were properly scoped)
    
    in our swig-generated interface and that solved all the non-cell
    long-string issues!  (By the way, the above new style has always been
    used by our equivalent interface to transform cell arrays of character
    strings to C strings which explains why the cell array version
    and the previous cellstr workaround both worked.)
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring PLplot using the normal
    (-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON) cmake options required
    by Debian Buster and by building the test_noninteractive target
    without obvious configure, build, or run-time errors and without
    PostScript difference report regressions (including on-going perfect
    results for octave despite the current commit reverting all the
    cellstr workarounds in examples octave that were applied in a previous
    commit).
    

M	bindings/octave/plplot_octave.i
M	examples/octave/x26c.m
M	examples/octave/x33c.m

commit 95f823ec0b3ca1ed54e8a664ab9a89c8fc5c872e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jul 31 20:40:13 2018 -0700

    Build system: bump minimum octave version we support from 3.2.0 to 3.8.0
    
    The reason for this bump is we have no way of testing early octave
    versions such as 3.2.  Actually, the same is likely true of 3.8.0, but
    I did have perfect PostScript difference reports for octave 3.8.x on
    my (now retired) Debian Jessie platform so on that basis I feel we can
    say we support 3.8.0 and above for the time being.
    
    In addition because octave-4 is now producing a perfect PostScript
    difference report, drop the TRY_OCTAVE4 option and the associated
    warnings when the user specified -DTRY_OCTAVE4=ON and simply quietly accept
    octave-4 if it is found.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring PLplot using the normal
    (-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON) cmake options required
    by Debian Buster and by building the test_noninteractive target
    without obvious configure, build, or run-time errors and without
    PostScript difference report regressions (including on-going perfect
    results for octave).

M	cmake/modules/octave.cmake

commit d7310aa9864ce1676177f39323c9daf593ae0765
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jul 31 13:13:11 2018 -0700

    Improved workaround for Octave-4 issue with non-cell arrays of character strings
    
    Our current swig-generated octave interface uses the following method call
    to help determine each element of an array of pointers to C strings
    from an octave non-cell array of strings:
    
    tmp_cstring = (char *) temp_matrix.row_as_string( i ).c_str();
    
    In turn this array of pointers to C strings are used as arguments to
    e.g., pllegend and plcolorbar.  This interfacing method worked fine
    for octave-3, and for octave-4 it also works for most UTF-8 character
    strings provided by our examples, but there are some exceptions
    (invalid UTF-8 character strings) turned up by our examples 26 and 33
    which I previously worked around before by dropping those octave
    examples from our test targets.
    
    Our octave binding of PLplot also provides the possibility of converting
    cell arrays of strings to pointers to C strings, and it turns out
    that method (using the cellstr function to convert from non-cell to
    cell array) makes examples 26 and 33 work again with octave-4.  In one
    case, the problematic non-cell array of strings in example 26 was
    
    ["Амплитуда"; "Фазовый сдвиг"]
    
    I have managed to replicate that issue with the simple self-contained "hex_print" project
    (completely independent of PLplot).  However, the issue appears to be quite specific
    to this array of strings since other arrays caused no problems for the hex_print project.
    These results will be the basis of an octave-4 bug report.
    
    But in another case for page 4 of example 33, the text was
    
    ["Box Line Width 1"; "Box Line Width 2"; "Box Line Width 3"; "Box Line Width 4"; "Box Line Width 5"]
    
    , i.e., all ascii.  I plan to investigate this issue further with the hex_print project, but meanwhile
    in this commit converting that array to cell
    in our example 33 avoided the invalid UTF-8 string issue.
    
    Many other cases of invalid UTF-8 string issues occurred for the plcolorbar pages (i.e.,
    page 5 and following) of example 33.  In all cases for this commit I
    avoided the problem by using cellstr to convert both the label and
    axis_opts arguments of plcolorbar to cell arrays.
    
    This commit allowed me to also add back examples 26 and 33 to our octave test case with
    a clean PostScript difference report for octave as a result, i.e.,
    
    octave
      Missing examples            :
      Differing graphical output  :
      Missing stdout              :
      Differing stdout            :
    
    I also took this opportunity not only to add back examples 26 and 33
    to our list of example pages that is maintained in
    cmake/modules/plplot_functions.cmake but also do further maintenance
    to that list, i.e., change the number of pages for example 22 from 4
    to the correct number (5), and change the number of pages for example
    33 from 4 (!) to the correct number (100).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring PLplot using the normal
    (-DENABLE_ada=OFF -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON) cmake
    options required by Debian Buster and by building the all,
    test_noninteractive, and test_interactive targets without obvious
    configure, build, or run-time errors and with the PostScript
    difference report improvement noted above which reduces the PostScript
    difference issues down to just one which is
    
    lua
      Missing examples            :  23
      Differing graphical output  :
      Missing stdout              :
      Differing stdout            :
    
    which is caused by my workaround (dropping example 23) for
    an upstream issue with lua5.3.
    
    A further test I did was to build the test_c_svg target twice followed
    by building the clean target.  The second build of test_c_svg did not
    execute anything showing that the list of examples pages maintained in
    cmake/modules/plplot_functions.cmake did not include too much.  The
    further build of the clean target removed all results from
    examples/test_examples_output_dir (except those from example 23 which
    necessarily must be there because example 23 is temporarily excluded
    from the list until the upstream Lua-5.3 issue is fixed).  This result
    confirms the maintained list of example pages did not include too
    little.

M	bindings/octave/plplot_octave.i
M	cmake/modules/plplot_functions.cmake
M	examples/octave/x26c.m
M	examples/octave/x33c.m
M	plplot_test/test_octave.sh.in

commit 94e2e5b01c3b844415244756c41e1286f9bb8935
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jul 30 23:23:35 2018 -0700

    Fix issues introduced by Phil's last two commits
    
    These issues range from the trivial (removing trailing blanks
    introduced into api.xml and restore correct plscmap1l as opposed to
    plscmap1la function name for relevant plabort calls) to important (fix
    introduced build errors for Tk-related source code caused by the
    backwards-incompatible changes [h,l,s ==> c1,c2,c3 changed member names])
    to the PLControlPt struct that were introduced by Phil's commit).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring PLplot using the normal
    (-DENABLE_ada=OFF -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON) cmake
    options required by Debian Buster and by building the all,
    test_noninteractive, and test_interactive targets without obvious
    configure, build, or run-time errors and without PostScript difference
    report regressions.

M	bindings/tk-x-plat/plplotter.c
M	bindings/tk/plframe.c
M	bindings/tk/plr.c
M	doc/docbook/src/api.xml
M	drivers/tk.c
M	src/plctrl.c

commit eac0c40f5bdb8c8e574357b1d9512269ed2b9cbe
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Thu Jul 26 14:02:35 2018 +0100

    Changes to documentation for plscmap1l
    
    These just update things and make the behaviour abslutely clear after
    the changes in the previous commit which not perform interpolation
    in the colorspace the user provides the coordinates in.

M	doc/docbook/src/api.xml

commit 7ab9c0abf4bf398568c0c39aa59cabce534d17f6
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Thu Jul 26 13:39:09 2018 +0100

    Changed color interpolation for plscmap1l and plscmap1la
    
    Previously scmap1l and plscmap1la took control points for interpolating
    a new colour map, but even if RGB coordinates were passed in, they were
    converted to HLS coordinates and interpolated in HLS space. The new
    behaviour is to interpolate in whichever space the coordinates are
    passed in with.

M	include/plplot.h
M	include/plstrm.h
M	src/plctrl.c

commit 1b800ff474c2035e325471adfa1b73ecaa8e4ce9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jul 17 11:53:20 2018 -0700

    Prefix the nistcd target
    
    The nistcd library is only built if -DPLD_cgm=ON.  That option is OFF
    by default so this unprefixed library target was missed by our
    previous tests until we tried the recent prefix test with
    -DPLD_cgm=ON.
    
    Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring PLplot with
    -DPLD_cgm=ON -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON included
    with the usual cmake options and building the test_cgm_dyndriver
    target specifically and the install target in general.
    There were no obvious configuration, build, or install issues.

M	lib/nistcd/CMakeLists.txt

commit 1282b2f257bd332e8f3ef21b8e40d5e66cb48c24
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jul 16 12:06:31 2018 -0700

    Change ALIAS target names of swig-generated shared objects for the Python case
    
    This commit changes the ALIAS target names from PLPLOT::plplotc and PLPLOT::Pltk_init
    to PLPLOT::_plplotc and PLPLOT::_Pltk_init to retain the underscore in the
    alias name.  This result is consistent with the swig-generated names of shared objects for
    the Python case.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by running
    
    time (nice -19 scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/usr/bin/cmake" --cmake_added_options "-DENABLE_ada=OFF -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10" --do_test_interactive no --do_test_install_tree no --do_test_traditional_install_tree no --do_submit_dashboard no)
    
    where the combination of launching the script from a software tree
    with blank in the prefix and the above --prefix option insure blanks
    in source, build, and install tree prefixes are tested, the /usr/bin
    versions of cmake and ctest are the Debian Buster versions with
    version number of 3.11.2; the "-DENABLE_ada=OFF -DTRY_OCTAVE4=ON
    -DUSE_INCRTCL_VERSION_4=ON" are appropriate software versions of
    octave, Tcl/Tk/Itcl/Itk/Iwidgets, and (buggy) gnatmake that I have
    installed from Debian Buster;
    -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON tests library target
    names, and I have dropped the interactive tests for convenience and
    the install-tree components of the comprehensive tests because those
    don't currently work due to namespace PLPLOT:: not being implemented
    yet for PLplot installs.
    
    This test script completed without running into any hangs or non-zero
    return codes, and the accompanying test results were evaluated as
    follows:
    
    # Check for all errors:
    grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -v libGL
    
    where that last pipeline stanza is to ignore libGL error messages
    issued by my X-terminal box.
    
    # Check for regressions in configuration warnings:
    grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
    
    # Find each distinct run-time warning labelled by 'PLPLOT WARNING':
    grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
    
    # Check for build or run-time warnings:
    find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0  grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic|cmake.out'
    
    where the trailing stanza is to remove "PLPLOT WARNING" issues, spurious gfortran warnings
    and cmake.out warnings.
    
    # Check for any ldd issues for the shared and nondynamic cases.
    # N.B. commented out this time because the above comprehensive_test.sh options
    # (--do_test_install_tree no --do_test_traditional_install_tree no)
    # preclude checking for ldd issues so there are no *.ldd.out files to
    # check.
    #grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
    
    # Check for any PostScript or Text differences between all non-C languages and the corresponding
    # C results:
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
    
    There are the well-known upstream issues with octave-4 and lua5.3
    software that are exposed by octave examples 26 and 33, and lua
    example 23 which we have worked around by dropping those examples from
    the PostScript comparison test, but otherwise these checks of the
    above comprehensive test results showed no configure, build, run-time,
    or PostScript difference issues.
    
    Because this test was a success with the above
    -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON cmake option, it
    appears there continues to be no library target references without
    prefixes (PLPLOT:: for read-only targets and ${LIBRARY_TARGET_PREFIX} for
    writeable targets) for the CMake logic exercised by the above tests.

M	CMakeLists.txt
M	cmake/modules/plplot_functions.cmake
M	examples/CMakeLists.txt
M	examples/python/CMakeLists.txt

commit 4d17d8f25cfb3df4d7e840a2ac61906ad473c5c2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Jul 15 11:25:20 2018 -0700

    Update installation of nistcd, csa, and nn headers
    
    In the nistcd case, I added the configured cddll.h header to the list
    of headers to be installed.
    
    In the csa and nn cases, I implemented header installation for the
    first time.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring the PLplot build using the cmake
    options -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON (consistent with
    modern software versions available from Debian Buster) and
    -DPLD_cgm=ON (needed to build and install the nistcd library), and
    building the install target.  There were no configure, build, or
    install issues other than the usual gfortran "PRIVATE" and "argv_dynamic"
    false alarm warnings.

M	lib/csa/CMakeLists.txt
M	lib/nistcd/CMakeLists.txt
M	lib/nn/CMakeLists.txt

commit 185b5fdcf0c0d5ad5c489b1ad7d8ede0f7b3f55f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Jul 15 10:54:25 2018 -0700

    Fix install error for configured qsastimedll.h
    
    In previous commit which introduced configuring this file, forgot
    to specify the ${CMAKE_CURRENT_BINARY_DIR} location of this
    configured file for the install command.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by building the install target without errors.

M	lib/qsastime/CMakeLists.txt

commit f9142a615a427eb66fa39708a84c7ea03c45d5e9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Jul 11 10:03:43 2018 -0700

    Remove sip v4.19 deprecation warning
    
    According to
    <http://pyqt.sourceforge.net/Docs/sip4/directives.html#directive-%25Module>
    the version option for the %Module directive is deprecated and ignored
    for v4.19 but apparently used for prior versions of sip to help keep
    track of shared object API changes for other modules that might depend
    on our pyqt5 module.  As a result prior to this commit the following
    deprecation warning was emitted by (Debian Buster) sip v4.19:
    
    sip: Deprecation warning: /home/software/plplot/HEAD/plplot.git/bindings/qt_gui/pyqt5/plplot_pyqt5.sip:25: %Module version numbers are deprecated and ignored
    
    Since it is unlikely we will ever have other modules depending on this
    one, and, in any case, this functionality is now missing from modern
    sip, I addressed this deprecation issue by removing the version option
    of our %Module directive.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by building the test_pyqt5_example target.  The
    deprecation warning is now gone, and there were no obvious configure,
    build, or run-time issues associated with this test target.

M	bindings/qt_gui/pyqt5/plplot_pyqt5.sip

commit dc217017dd2d276acd2a4b8cba5c74f652ec1803
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jul 10 15:48:45 2018 -0700

    Test system: Adjust what is tested by the test_interactive and test_tk targets
    
    Two steps forward, one step back....
    
    With the Debian Buster version (5.10.1) of the Qt5 suite of libraries
    valgrind reports *no" memory management issues for -dev qtwidget or
    qt_example which is in sharp contrast with my previous results for
    earlier Qt5 versions.  (I do see thousands of such issues when running
    pyqt5_example with python3 with valgrind, but python is notorious for
    false positives for valgrind so I discount these.)  Those earlier
    issues were reported at <https://sourceforge.net/p/plplot/bugs/158/>
    so this new result is a promising indication that bug should be
    closed, but I am going to wait to do that until there is more of a
    track record for good memory management experience with Qt5 5.10.1 and
    above.  To help gain that experience, I now allow both the
    test_qt_example and test_pyqt5_example targets to be dependencies of
    the test_interactive target for the -DPLPLOT_USE_QT5=ON case.  So this
    change constitutes the two steps forward.
    
    I have recently discovered that the pytkdemo example intermittently
    hangs on exit (at least with Debian Buster Tcl/Tk versions).  Therefore,
    I have dropped the test_pytkdemo target from the list of dependencies
    for both the test_interactive and test_tk targets.  So this change constitutes
    the one step back.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by running
    
    time (nice -19 scripts/comprehensive_test.sh --cmake_command "/usr/bin/cmake" --cmake_added_options "-DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10" --do_test_install_tree no --do_test_traditional_install_tree no)
    
    Where the /usr/bin versions of cmake and ctest are the Debian Buster
    versions with version number of 3.11.2; the "-DTRY_OCTAVE4=ON
    -DUSE_INCRTCL_VERSION_4=ON" are appropriate for the Debian Buster
    software versions of octave and Tcl/Tk/Itcl/Itk/Iwidgets that I have
    installed; and I have dropped the install-tree components of the
    comprehensive tests because those don't currently work due to
    namespace PLPLOT:: not being implemented yet for PLplot installs.  As
    a result of the above changes, this test built both the
    test_qt_example and test_pyqt5_example test targets but dropped the
    test_pytkdemo target.
    
    This test script completed without running into any hangs or non-zero
    return codes, and the accompanying test results were evaluated as
    follows:
    
    # Check for errors or any regressions in the warnings in the cmake output.
    grep -i error ../comprehensive_test_disposeable/*/*/output_tree/cmake.out
    grep -i warning ../comprehensive_test_disposeable/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target |requires shared libraries' |less
    
    # Find number of distinct run-time warnings labelled by 'PLPLOT WARNING':
    grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
    
    # Check for build or run-time warnings:
    ls ../comprehensive_test_disposeable/*/*/output_tree/* |grep -v cmake.out |xargs grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic'
    
    where I have ignored the previously covered 'PLPLOT WARNING' issues and ignored the spurious gfortran warnings.
    
    # Check for all errors:
    grep -i error ../comprehensive_test_disposeable/*/*/output_tree/*.out |grep -v libGL
    
    where that last pipeline stanza is to ignore libGL error messages issued by my X-terminal box.
    
    # Check for any ldd issues for the shared and nondynamic cases.
    # N.B. commented out because the above comprehensive_test.sh options
    # (--do_test_install_tree no --do_test_traditional_install_tree no)
    # preclude checking for ldd issues so there are no *.ldd.out files to
    # check.
    grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable/*/*/output_tree/*ldd.out
    
    # Check for any PostScript or Text differences between all non-C languages and the corresponding
    # C results.
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable/*/*/output_tree/*.out |less
    
    There were run-time deprecation warnings for pyqt5 found with the
    above checks which I will investigate later, and there are the
    well-known upstream issues with octave-4 and lua5.3 software that are
    exposed by octave examples 26 and 33, and lua example 23 which we have
    worked around by dropping those examples from the PostScript
    comparison test, but otherwise these checks of the above comprehensive
    test results showed no configure, build, run-time, or PostScript
    difference issues.

M	examples/CMakeLists.txt

commit 6e36da7fb40f8d867d11dd78fde5fa2b104c1c8d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jul 9 15:35:39 2018 -0700

    Reduce warning messages for the test_noninteractive target
    
    The changes were as follows:
    
    * For the Fortran binding, drop declarations of some unused variables.
    
    * For the Fortran examples, don't define an unused function.
    
    * For the OCaml examples, drop some unneeded calculations.
    
    * For the higher-level Octave binding that is implemented with Octave
      functions, replace calls to the deprecated (in Octave 4.4) toascii
      function with calls to the recommended replacement (the double
      function).  I assume this replacement is backwards compatible since
      I have discovered with web searchs that the double function has been
      documented back to octave-2.9 and likely even earlier.  However, I
      have no means to test octave versions less than 4.4.
    
      I speculate that toascii was deprecated in Octave 4.4 because its
      name was a horrible misnomer describing the reverse of what occurs
      which is conversion of each character in a string to the
      corresponding integer, but by default integers are internally stored
      in octave as double-precision floating point numbers so the actual
      conversion was from each character in the string to double (which I
      assume is why double is the recommended replacement).
    
    As a result of these changes the only warning messages left that are
    emitted by the test_noninteractive target are run-time "PLPLOT WARNING" messages
    that have been present for a long time, and the following spurious warnings
    emitted by gfortran:
    
    1. argv_dynamic warning message.
    /home/software/plplot/HEAD/plplot.git/examples/fortran/x01f.f90:51:0:
    
         character(len=:), dimension(:), allocatable :: argv_dynamic
    
    Warning: ‘.argv_dynamic’ is used uninitialized in this function [-Wuninitialized]
    
    I am not sure where the "." part of ".argv_dynamic" comes from in that
    warning message.  In any case, I am virtually positive this warning is
    spurious since argv_dynamic is an output argument of the routine
    plget_arguments(argv_dynamic) which is the first mention of
    argv_dynamic in an executable statement in this routine.
    
    2. Spurious "PRIVATE" warning messages.
    There are 56 of these due to a long-standing gfortran
    bug (see
    <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111> and
    <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861>).  A typical
    example is
    
    /home/software/plplot/HEAD/plplot.git/bindings/fortran/plplot_small_modules.f90:108:8:
    
             function interface_strlen(s) bind(c, name='strlen')
            1
    Warning: Symbol ‘interface_strlen’ at (1) is marked PRIVATE but has been given the binding label ‘strlen’
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring PLplot with the cmake options
    -DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON and
    building the test_noninteractive target with octave 4.4.  All but the
    "PLPLOT WARNING" and spurious fortran warning messages mentioned above
    are now gone.  This overall test showed no obvious configure, build,
    run-time, or PostScript difference report regressions as a result of
    this commit.

M	bindings/fortran/plplot_small_modules.f90
M	bindings/octave/PLplot/ginput.m
M	bindings/octave/PLplot/support/__pl_matstr.m
M	examples/fortran/x15f.f90
M	examples/ocaml/x19.ml

commit a4bada0048d93cc79900807b576a52e1503695a0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jul 9 11:26:00 2018 -0700

    Testing system: Fix long-standing name clash between various "test.error" files output by test scripts
    
    My thanks to Nils Gladitz for going above and beyond by investigating
    this PLplot bug and drawing my attention to the test.error files in
    response to my question on the CMake mailing list.
    
    These name clashes create obvious race conditions for parallel builds
    of test targets.  For example, after the fix was applied here is the list
    of the various "*test.error" files generated by
    the test_noninteractive target:
    
    software@merlin> find . -name "*test.error"
    ./examples/octave_psc_test.error
    ./examples/c_pngcairo_test.error
    ./examples/c_pdfqt_test.error
    ./examples/c_jpgqt_test.error
    ./examples/c_svgcairo_test.error
    ./examples/c_svg_test.error
    ./examples/tcl/tcl_psc_test.error
    ./examples/c_pscairo_test.error
    ./examples/c_psttf_test.error
    ./examples/c_ps_test.error
    ./examples/c_pngqt_test.error
    ./examples/c_svgqt_test.error
    ./examples/lua/lua_psc_test.error
    ./examples/cxx_psc_test.error
    ./examples/ada_psc_test.error
    ./examples/d_psc_test.error
    ./examples/c_tiffqt_test.error
    ./examples/ocaml_psc_test.error
    ./examples/c_psttfc_test.error
    ./examples/c_epscairo_test.error
    ./examples/c_ppmqt_test.error
    ./examples/c_pdfcairo_test.error
    ./examples/fortran_psc_test.error
    ./examples/python_psc_test.error
    ./examples/c_bmpqt_test.error
    ./examples/c_psc_test.error
    ./examples/c_xfig_test.error
    ./examples/java_psc_test.error
    
    Those versions of the files that are located in the examples directory
    obviously could have interfered with each other before the name clash
    was resolved.
    
    I don't understand the exact mechanism, but it turns out those races
    caused a long-standing problem of groups of extra ascii nul characters
    ('\0') to appear in the output of parallel builds, and I am pleased
    that race condition symptom is now gone as a result of this commit.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by building the test_noninteractive target using
    
    make -j16 test_noninteractive >& test_noninteractive.out
    
    The command
    
    od -c test_noninteractive.out |grep '\\0'
    
    showed those results were free of embedded '\0' (ascii nul) characters
    that were there for parallel builds before the current commit.  This
    overall test showed no obvious configure, build, run-time, or
    PostScript difference report regressions as a result of this commit.

M	plplot_test/plplot-test-interactive.sh.in
M	plplot_test/test_ada.sh.in
M	plplot_test/test_c.sh.in
M	plplot_test/test_c_interactive.sh.in
M	plplot_test/test_cxx.sh.in
M	plplot_test/test_d.sh.in
M	plplot_test/test_fortran.sh.in
M	plplot_test/test_java.sh.in
M	plplot_test/test_lua.sh.in
M	plplot_test/test_ocaml.sh.in
M	plplot_test/test_octave.sh.in
M	plplot_test/test_octave_interactive.sh.in
M	plplot_test/test_plrender.sh.in
M	plplot_test/test_python.sh.in
M	plplot_test/test_tcl.sh.in

commit 179809cb9eecb3e75997ca7aa39d6e1cb39d8708
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Jul 7 23:53:17 2018 -0700

    Octave binding: remove last build warning
    
    The build warning was caused by the following code fragment propagated
    to the C++ code generated by swig to implement the octave binding:
    
    // Check if version >= 3.4.0
    #if OCTAVE_API_VERSION_NUMBER < 45
        retval( 0 ) = octave_value( local_charMatrix, true );
    #else
        retval( 0 ) = octave_value( local_charMatrix );
    #endif
    
    This is an attempt to use the first (ancient) octave_value form if the
    user has a very old version of octave, but this is inconsistent with
    other parts of the code which uses the modern (second) form of
    octave_value without attempting to support ancient octave.
    Furthermore, even this attempt at backwards incompatibility with
    ancient octave is not implemented correctly since
    OCTAVE_API_VERSION_NUMBER is not #defined for modern octave so the C++
    preprocessor assumes its value is 0, and the first (ancient) form of
    the octave_value call is (incorrectly) used with accompanying build
    warnings.  I have absolutely no idea how that ancient form still
    worked for octave-4.4 prior to this commit, but in any case the
    warning issue is solved by this commit by only using the second modern
    form of the octave_value call consistent with other code in
    plplot_octave.i.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring PLplot with the cmake options
    -DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON and
    building the test_noninteractive target with octave 4.4.  All
    remaining deprecation build warnings for octave are now gone, and this
    test showed no obvious configure, build, or run-time regressions as a
    result of this commit.

M	bindings/octave/plplot_octave.i

commit b940cde452cbb8bea541087f66696137c4f6bbee
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Jul 7 14:34:17 2018 -0700

    Update styling script to handle swig %# preprocessor directives
    
    Some swig configuration files (e.g., bindings/octave/plplot_octave.i)
    use the swig "%#" preprocessor directive which tells swig to pass that
    directive through to the C or C++ preprocessor rather than using the
    swig preprocessor to process that directive.  Thus, from a style
    perspective, swig "%#" preprocessor directives should be treated the
    same way by uncrustify as the normal C or C++ "#" preprocessor
    directive.  So this commit implements that by the appropriate sed
    magic to replace "%#" by "#" before uncrustify processes the file and
    then replace "#" by "%#" (for appropriately commented lines) after
    uncrustify processes the file to restore back to appropriate swig
    configuration script form.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by running the new version of scripts/style_source.sh
    that is committed in this commit.  This version of the style script
    was used to style bindings/octave/plplot_octave.i with good
    indentation before that file was committed in the last commit, and
    running this version of the style script now shows (as expected) no
    further style changes to bindings/octave/plplot_octave.i (or any other
    file) are necessary.

M	scripts/style_source.sh

commit 76f486baadf33014ec97d03772bc591d22ae2231
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Jul 7 14:29:00 2018 -0700

    Octave binding: For octave-4.4 and above to avoid deprecations warnings replace calls to the is_empty and is_cell methods by calls to the preferred octave-4.4 names for those methods which are isempty and iscell
    
    As of version 4.4, the preferred names for the is_empty and is_cell methods have been changed
    to isempty and iscell to make them consistent with the corresponding octave function names.
    
    The current commit uses conditional compilation to use isempty and
    iscell for octave-4.4 (to avoid the 4.4 is_empty and is_cell
    deprecation warnings), but otherwise it continues to use the old
    names.  Therefore, this commit should not introduce issues for
    octave-4 versions below 4.4 and likely also octave-3, but I am not in
    a position to test those older octave versions.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring PLplot with the cmake options
    -DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON and
    building the test_noninteractive target with octave 4.4.  All the
    previous is_empty and is_cell deprecation build warnings are now gone,
    and this test showed no obvious configure, build, or run-time
    regressions as a result of this commit.

M	bindings/octave/plplot_octave.i

commit d96ac4b469f2e5028ff2fa773fce53ccf2d5d1a7
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Jul 6 14:48:17 2018 -0700

    Octave binding: For octave-4.4 and above replace calls to feval by calls to octave::feval to avoid a deprecation warning
    
    As of version 4.4, feval is deprecated in favour of octave::feval.
    
    The current commit uses conditional compilation to use octave::feval
    for octave-4.4 (to avoid the 4.4 feval deprecation warning), but
    otherwise it continues to use feval.  Therefore, this commit should
    not introduce issues for octave-4 versions below 4.4 and likely also
    octave-3, but I am not in a position to test those older octave
    versions.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring PLplot with the cmake options
    -DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON and
    building the test_noninteractive target with octave 4.4.  All the
    previous feval-related deprecation build warnings were gone, and this
    test showed no obvious configure, build, or run-time regressions as a
    result of this commit.

M	bindings/octave/plplot_octave.i

commit 844e7f3454b272ad3b4b83413e36e4c7ede6a68a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Jul 6 11:29:19 2018 -0700

    Solve dereferencing bug for pltcl application
    
    This bug was introduced by commit c1d5dba8d1 which made (in 2010) the following change
    to pltcl.c
    
    diff --git a/utils/pltcl.c b/utils/pltcl.c
    index 72a0055b4..1b15f5f93 100644
    --- a/utils/pltcl.c
    +++ b/utils/pltcl.c
    @@ -68,10 +68,13 @@ main( int argc, const char **argv )
     static int
     plExitCmd( ClientData clientData, Tcl_Interp *interp, int argc, char **argv )
     {
    +    char *tmp;
    +
     // Print error message if one given
    
    -    if ( interp->result != NULL && interp->result[0] != '\0' )
    -        fprintf( stderr, "%s\n", interp->result );
    +    tmp=Tcl_GetStringResult(interp);
    +    if ( tmp != NULL && tmp != '\0' )
    +        fprintf( stderr, "%s\n", Tcl_GetStringResult(interp));
    
         plspause( 0 );
         plend();
    
    The problem with that change was the second use of tmp in the if
    statement was not derefenced (to check that the size of the error
    message string was non-zero).  This issue was discovered by gcc 7.3.0
    which emitted the following warning message before this fix:
    
    bindings/tcl/pltcl.c:74:29: warning: comparison between pointer and zero character constant [-Wpointer-compare]
         if ( tmp != NULL && tmp != '\0' )
    
                             ^
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by building the test_pltcl_standard_examples target.
    The current fix removed the above build warning, and there were
    no obvious run-time issues with the results of this test.

M	bindings/tcl/pltcl.c

commit 5eced65fc75113200adb273f868bcd0d4fdb54c8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Jul 4 16:30:19 2018 -0700

    Build system: Fix OCTAVE_PREFIX (and derived OCTAVE_M_DIR) configuration bug for the octave-4.4 case
    
    For octave-4.4 __octave_config_info__("prefix") has stopped working,
    and the similar
    
    octave-config --print PREFIX
    
    command generates an empty string.  Experimentally, I have discovered
    that although __octave_config_info__("octave_home") does not work
    
    octave-config --print OCTAVE_HOME
    
    does generate the appropriate "/usr" string representing the install
    prefix for octave.
    
    Therefore, I have replaced all instances of using the
    __octave_config_info__ octave function with the equivalent
    octave-config command, and solved the OCTAVE_PREFIX issue for
    octave-4.4 by searching first for PREFIX, and if that generates an
    empty string, search for OCTAVE_HOME instead.  This fix also solved
    the (derived) OCTAVE_M_DIR issue where that variable had the wrong
    install prefix.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring PLplot with cmake and demonstrating via
    those results that OCTAVE_PREFIX and the derived OCTAVE_M_DIR are now
    defined properly again for octave-4.4.  As far as I know, this fix has
    been made in a backwards-compatible way, i.e., it should work for
    octave-3, but I am not in position to test that.

M	cmake/modules/octave.cmake

commit 4e36c1d0e2e6f31af678a3d7fc27cf0f0b0ce793
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Jul 4 13:19:28 2018 -0700

    Build system: Fix lua and octave rebuild bugs
    
    A maintenance quirk for the PLplot build system is that when examples
    are (temporarily) dropped (as in previous lua and octave commits to
    avoid exposing lua and octave upstream bugs, GRR) it is necessary to
    drop those examples from the list_example_files function in
    cmake/modules/plplot_functions.cmake to avoid rebuild bugs such as the
    ones fixed by this current commit.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by building the test_diff_psc target twice and
    demonstrating for the second of those that there are no unnecessary
    rebuilds such as occurred for lua and octave examples prior to this
    commit.

M	cmake/modules/plplot_functions.cmake

commit ade600099f51564eef1a80acebac94dd90623069
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Jul 4 11:41:40 2018 -0700

    Style previous commits

M	bindings/octave/plplot_octave.i
M	lib/csa/csa.c

commit 7bc62a898d483b92c4a122bb057649ad1bdf6b32
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Jul 4 11:09:15 2018 -0700

    Build system: fix "cmake -E copy_if_different" re-copy bugs
    
    The problem with using "cmake -E copy_if_different" within custom
    commands and targets is the date does not get updated when the file is
    the same (e.g., when the source file for the copy is touched
    explicitly or implicitly via git workflow).  This means the "cmake -E
    copy_if_different" command and *all* target dependencies of that command get
    incorrectly re-run until you start fresh from an empty build tree.
    
    This commit solves these bugs by replacing "cmake -E
    copy_if_different" for all cases where it occurs in a custom command
    or target with "cmake -E copy" since the latter command always updates
    the timestamp of the destination file which effectively eliminates
    further re-copies.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by rebuilding the octave_examples and lua_examples
    targets for a case where certain of the octave and lua examples had
    been touched by git workflow).  The result was the touched source
    files were updated in the build tree once, and then after that the
    timestamps on those updated files kept the command from incorrectly
    being re-run.
    
    N.B. there are other lua and octave incorrect re-run issues exposed by
    running the test_diff_psc target twice.  Those issues still require
    further investigation, but this commit, at least, eliminates the
    re-copy issue that was obfuscating the test_diff_psc target issue.

M	bindings/ada/CMakeLists.txt
M	bindings/ocaml/CMakeLists.txt
M	bindings/ocaml/plcairo/CMakeLists.txt
M	bindings/tcl/CMakeLists.txt
M	examples/lua/CMakeLists.txt
M	examples/ocaml/CMakeLists.txt
M	examples/python/CMakeLists.txt
M	examples/tcl/CMakeLists.txt
M	examples/tk/CMakeLists.txt
M	plplot_test/CMakeLists.txt
M	www/announce/CMakeLists.txt

commit 014bbe28f756c55f02b8152b0e7d10c185da489f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jul 3 16:17:09 2018 -0700

    octave binding and examples; adjust for octave-4 changed interpretation of strings
    
    The octave-4 difference we are adjusting for is that NULL's embedded
    in strings no longer terminate output of printf, etc.  Instead, the
    entire string is output with embedded NULL's ignored.
    
    To adjust for this change, the octave binding of plplot stores the
    results from plgver, plgdev, and plgfnam (all the PLplot API with
    output character string arguments) in an ordinary C string, and
    inserts the NULL-terminated substring of those results into an octave
    charMatrix which is then returned to the octave environment as an
    octave string of the correct (NULL-terminated) length.
    
    N.B. Backwards-incompatible change to plgver, plgdev, and plgfnam.
    
    The results for these functions are backwards incompatible because the
    result returned to the octave environment is a string rather than the
    transpose of a string which was the previous (badly designed)
    historical result.  Also note because of bad historical choices there
    are many other data returned by the current octave binding for PLplot
    where the transpose must be taken and the long-term plan is to
    introduce more backwards-incompatible changes by getting rid of all
    these unnecessary transposes.  So this commit is the first step toward
    that goal.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring PLplot with cmake 3.11.2 using the
    options -DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON
    and building the test_diff_psc target.  The configuration, build, and
    run time results had no obvious errors, and the present commit solved
    stdout differences for the octave part of the PostScript difference
    report.  Therefore, the exceptions to a perfect PostScript difference
    report are now reduced to
    
    octave
      Missing examples            :  26 33
      Differing graphical output  :
      Missing stdout              :
      Differing stdout            :
    lua
      Missing examples            :  23
      Differing graphical output  :
      Missing stdout              :
      Differing stdout            :
    
    where those missing examples are a temporary workaround to avoid
    exposing upstream bugs in octave 4 (likely 8-bit clean issues with
    octave-4 UTF-8 handling of strings) and lua5.3 (see
    <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for details
    of this severe bug).

M	bindings/octave/INSTALL
M	bindings/octave/PLplot/figure.m
M	bindings/octave/plplot_octave.i
M	examples/octave/x01c.m
M	examples/octave/x14c.m

commit 0b14d2a56623e88a4cf5431d36b0c1ac187628a2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Jun 23 14:56:10 2018 -0700

    Adjust Lua examples so they give correct results for Lua5.3
    
    All these issues are caused by Lua5.3 implementing default formatting of the
    conversion of numbers to strings that is different than prior
    versions.  So in each case the example correction was to replace
    default formatting with definite formatting when converting numbers to
    strings.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by building the test_diff_psc target.  The previous
    lua component of the report was
    
    lua
      Missing examples            :
      Differing graphical output  :  14a 19 23
      Missing stdout              :
      Differing stdout            :  31
    
    This and the prior commit substantially improved this result to
    
    lua
      Missing examples            :  23
      Differing graphical output  :
      Missing stdout              :
      Differing stdout            :
    
    where the remaining issue (example 23 missing from lua testing) is by
    design to avoid exposing an upstream bug with lua5.3.  (See the
    previous commit message for more details about this issue.)

M	examples/lua/x14.lua
M	examples/lua/x19.lua
M	examples/lua/x31.lua

commit 61be11becdc4577a01ffe3c1dde207530deed92e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Jun 23 14:50:45 2018 -0700

    Drop lua example 23 from tests to avoid upstream lua5.3 bug
    The upstream bug is a severe one, see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238>
    for details.  Therefore, all we can do on the PLplot side of things is to avoid exposing
    this bug by not running lua example 23 in our tests.

M	plplot_test/test_lua.sh.in

commit 9893349d1408545275d4f4187d4b7ba745a3c3db
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Jun 20 14:36:36 2018 -0700

    Build system: Force DROP_GTK_PLUS_2_BUILDS to be ON
    
    The fundamental purpose of this change is to make sure all our GTK+
    dependencies are version 3 rather than version 2 since version 3 has
    long been the standard version of GTK+ and a combination of versions 2
    and 3 will likely not work in any case.
    
    The practical implication of this change is
    examples/c/extXdrawable_demo.c is never built since that app consists
    of calls to GTK+ API that was already deprecated in GTK+ version 2 and
    completely removed in GTK+ version 3.  In addition, this change means
    the PLplot ocaml "cairo" API cannot be used, but that API has already
    been disabled due to lack of maintenance.

M	cmake/modules/plplot.cmake

commit 99472347145a5faa94411ed81f10ed028f2411cf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Jun 9 13:09:40 2018 -0700

    First collection of changes to make PLplot support modern versions (as available from Debian Buster) of free software
    
    These changes are as follows:
    
    * Support Lua version 5.3 (and likely versions back to 5.2).  Along
      with updates to cmake/modules/lua.cmake, this change required
      updating the cmake/modules/FindLua.cmake to be consistent with the
      CMake version 3.8.0 official version of this find module. The
      following minor change was required to make this find module work as
      part of the PLplot build system:
    ______________________________
    
    software@merlin> diff -au Modules/FindLua.cmake ~/plplot/HEAD/plplot.git/cmake/modules/
    --- Modules/FindLua.cmake       2018-06-09 10:41:24.374851079 -0700
    +++ /home/software/plplot/HEAD/plplot.git/cmake/modules/FindLua.cmake   2018-05-20 14:51:32.760113838 -0700
    @@ -187,7 +187,8 @@
         endif ()
     endif ()
    
    -include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
    +#include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
    +include(FindPackageHandleStandardArgs)
     # handle the QUIETLY and REQUIRED arguments and set LUA_FOUND to TRUE if
     # all listed variables are TRUE
     FIND_PACKAGE_HANDLE_STANDARD_ARGS(Lua
    ______________________________
    
    The plan is to drop this find module from PLplot and use the official
    version from then on once our minimum version of CMake is 3.8.0 or
    higher.
    
    * Support gdc version 7 (and likely version 6 and possibly 5).  The
      principal change here is to adjust for a rename of libgphobos2
      (required by gdc version 4) ==> libgphobos.  The libgphobos2 name was
      used for Debian Jessie gdc 4.9.2 and was changed to the libgphobos
      name somewhere between that version and gdc version 6.  Note this
      entire set of gdc-related changes was so simple it is likely we do
      support gdc-6 and we might even support gdc-5 if that version uses
      the new libgphobos name, but I am not in position to test either
      gdc-6 or gdc-5.
    
    * Support octave version 4.2.2 (and likely prior 4.x versions as well
      as octave 3.8.2 that was so well-tested on Debian Jessie).  The
      principal change here is to use __octave_config_info__ if available
      with a fallback to octave_config_info (deprecated for 4.2.2 in
      favour of __octave_config_info__) to quiet deprecation messages.  In
      addition, I temporarily dropped octave standard examples 26 and 33
      (two of our 4 UTF-8 examples) because they appear to expose
      eight-bit clean issues for octave 4.2.2 that mess up UTF-8 strings
      in PLplot arguments some of the time.  This issue needs further
      study, but will likely need to be addressed upstream by the octave
      developers.
    
    * Work around what appears to be an issue with gcc version 7.3.0-21
      from Debian Buster where the explicit (or implicit via -O3) use of
      the -finline-functions gcc option causes segfaults in the
      libcsirocsa library.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Buster) by configuring the PLplot build using the cmake
    (version 3.11.2 from Buster) options -DBUILD_TEST=ON -DTRY_OCTAVE4=ON
    -DUSE_INCRTCL_VERSION_4=ON, and within the build tree for the shared
    library case, building the test_noninteractive and all targets, and
    running ctest.
    
    There was one minor configuration regression compared to Debian Jessie
    results, i.e.,
    -- Determine compile and link flags for extXdrawable_demo
    -- Checking for module 'gtk+-x11-2.0'
    --   No package 'gtk+-x11-2.0' found
    -- WARNING: gtk+-x11-2.0 not found.  extXdrawable_demo not built.
    
    The solution is to update extXdrawable_demo so it works with GTK+ version 3.
    
    There was also no obvious build or run-time errors for these tests.
    However, the following PostScript regressions were introduced compared
    to the Jessie results:
    
    [...]
    octave
      Missing examples            :  26 33
      Differing graphical output  :
      Missing stdout              :
      Differing stdout            :  01 14
    [...]
    lua
      Missing examples            :
      Differing graphical output  :  14a 19 23
      Missing stdout              :
      Differing stdout            :  31
    
    The missing octave examples were necessary because of the (likely)
    upstream octave 4.x regressions with 8-bit clean handling of UTF-8
    strings compared to octave-3.8.2.  The remaining PostScript
    regressions relative to Debian Jessie need further study but will
    likely be solved by adjusting the relevant examples so they work
    properly on octave-4 and Lua-5.3.

M	cmake/modules/FindLua.cmake
M	cmake/modules/language_support/cmake/CMakeDInformation.cmake
M	cmake/modules/language_support/cmake/CMakeDetermineDCompiler.cmake
M	cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake
M	cmake/modules/lua.cmake
M	cmake/modules/octave.cmake
M	lib/csa/CMakeLists.txt
M	lib/csa/csa.c
M	plplot_test/test_octave.sh.in

commit f580dd5c22f070d44362a777ddb2256f8857f27d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Apr 15 13:25:40 2018 -0700

    Build system: Fix -DTEST_DYNDRIVERS=ON case when -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON
    
    My previous tests of -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON found issues
    with (the default) -DTEST_DYNDRIVERS=ON case which are fixed in this commit.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running
    
    time (nice -19 scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON" --build_command "make -j4 -k" --do_test_install_tree no --do_test_traditional_install_tree no --do_submit_dashboard no)
    
    (Note because this command was run from a "spaced" source tree and the above
    "spaced" --prefix, this test has a space in the prefixes of the source, build,
    and install trees.)
    
    Check the results:
    
    # Check for any regressions in the warnings in the cmake output.
    less ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out
    
    # Check for some non-standard warnings:
    grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'cmake.out|ctest.out' |grep -vEi 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout|unused|uninitialized'
    
    # Check for all errors:
    grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out
    
    # Check for any ldd issues for the shared and nondynamic cases.
    # N.B. commented out because the above comprehensive_test.sh options preclude
    # checking for ldd issues so there are no *.ldd.out files to check.
    #grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
    
    # Check for any PostScript or Text differences between all non-C languages and the corresponding
    # C results.
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
    
    These checks showed no configure, build, run-time, or PostScript
    difference issues with the above comprehensive test (limited to just
    the build-tree case because of the
    -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON side effect that would
    cause errors for the install-tree case).
    
    I additionally checked the
    -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=OFF case by building from
    a fresh start the test_diff_psc target for both the (default)
    -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=OFF case as well as the
    -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON case that is redundant
    with one part of the above comprehensive test.  All was well for the
    OFF case, but I got Ada build errors for the ON case that disappeared
    again when I ran that test for the second time (from an identical
    clean start in both cases).  So I am still encountering intermittent
    Ada build errors (in this case for the first
    -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON case above, but not for
    any of the other cases) even though my extensive testing of my
    hardware indicates no issues.  Currently, I think the most likely
    explanation of these intermittent errors is and Ada build tool bug
    <https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=65451>
    whose fix is not present in the ancient (4.9.2) version of Ada build
    tools I have access to at the moment.  (See further discussion on the
    PLplot devel list).
    
    Therefore, from these good comprehensive and test_diff_psc target
    results (if you exclude the case where intermittent Ada build issues
    showed up for the test_diff_psc target) it appears all non-prefixed
    writeable library target references in our build system have been
    eliminated (at least for the CMake logic exercised by the above
    tests).

M	drivers/CMakeLists.txt
M	drivers/test-drv-info.c

commit 0df4e30e6b469edac0ae6cea8c32250201f8341f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Apr 6 14:58:02 2018 -0700

    Build system: Implement TEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS experimental option
    
    This new option defaults to OFF (which unsets the CMake variable
    LIBRARY_TARGET_PREFIX), but when this option is ON the CMake variable
    LIBRARY_TARGET_PREFIX is set to "temporary_target_".  This commit also
    changes all writeable library targets in the build system (and also as
    an unwanted side effect [see below] that limits what we can test when
    -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON the corresponding dll
    or library filename) to have a prefix of ${LIBRARY_TARGET_PREFIX}.  So
    as a result of this commit and a prior commit that prefixed all
    read-only library targets with "PLPLOT:::, all library targets in our
    core build system that we use for the build tree should have a prefix
    of either ${LIBRARY_TARGET_PREFIX} or "PLPLOT::".  Therefore when
    -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON any exercised CMake
    code that refers to an unprefixed library target such as "plplot" will
    error out with an unknown target message at cmake time or some other
    error message at run time.
    
    Of course, CMake code paths not followed can still refer to unprefixed
    library targets so it is useful to use
    -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON for as wide variety of
    configuration, build, and test conditions as provided by
    scripts/comprehensive_test.sh to test as much of CMake logic in the
    build-tree build system as possible.  However, note that such tests
    must be limited just to build-tree tests since the side effects
    mentioned above completely screw up both the CMake-based and
    traditional install-tree build systems.  Furthermore, I have not yet
    figured out how to make this all work for the (default)
    -DTEST_DYNDRIVERS=ON case so my tests below used
    -DTEST_DYNDRIVERS=OFF.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running (from a source tree with a space in the
    prefix)
    
    time (nice -19 scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DTEST_DYNDRIVERS=OFF -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON" --build_command "make -j4 -k" --do_test_install_tree no --do_test_traditional_install_tree no)
    
    (Note because of the choice of a "spaced" source tree and the above
    --prefix, this test has a space in the prefixes of the source, build,
    and install trees.)
    
    Check the results:
    
    # Check for any regressions in the warnings in the cmake output.
    less ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out
    
    # Check for some non-standard warnings:
    grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout'
    
    # Check for all errors:
    grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out
    
    # Check for any ldd issues for the shared and nondynamic cases.
    grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
    
    # Check for any PostScript or Text differences between all non-C languages and the corresponding
    # C results.
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
    
    These checks showed intermittent failures for certain parts
    (xtraditional28a, xtraditional33a) of the Ada part of the build with
    two separate complaints about various files written by the gnat
    compiler.  At this stage I cannot figure out the source of this issue
    since it comes and goes and is hard to reproduce.  But at one point I
    got through the entire test above without Ada failures, and found an
    obvious issue with the static OCaml binding library which I fixed and
    which has absolutely nothing to do with Ada.  I then tried the test
    above again, which failed for the nondynamic case for the build of one
    of the Ada examples.  I then followed up by a specific static build of
    the ocaml binding library that exercised the fixed build-system CMake
    code for that case, and all was well.  Therefore, I think from these
    piecemeal results that all is well with the current commit, but
    further testing needs to be done as above once I figure out the source
    of the intermittent Ada build errors.
    
    N.B. I have run
    
    git fsck --strict --no-dangling
    
    before this commit.  That result showed the git filesystem had no
    inconsistencies.  Normally (from past experience with a slowly failing
    disk), there are such inconsistencies whenever the disk is
    experiencing some bad block issues.  So the good result for this
    command is encouraging with regard to the health of my computer
    hardware.  But "just in case", I plan to run the same git fsck command just
    before the push of this commit and will only do that push if
    the fsck is again a success.

M	CMakeLists.txt
M	bindings/ada/CMakeLists.txt
M	bindings/c++/CMakeLists.txt
M	bindings/d/CMakeLists.txt
M	bindings/fortran/CMakeLists.txt
M	bindings/java/CMakeLists.txt
M	bindings/lua/CMakeLists.txt
A	bindings/lua/lua_namespace.i.in
M	bindings/lua/plplotluac.i
M	bindings/ocaml/CMakeLists.txt
M	bindings/ocaml/plcairo/CMakeLists.txt
M	bindings/octave/CMakeLists.txt
R075	bindings/octave/plplot_stub_hand_crafted.m	bindings/octave/plplot_stub.m.in
M	bindings/python/CMakeLists.txt
M	bindings/qt_gui/CMakeLists.txt
M	bindings/qt_gui/pyqt4/CMakeLists.txt
M	bindings/qt_gui/pyqt5/CMakeLists.txt
M	bindings/qt_gui/smoke/CMakeLists.txt
M	bindings/qt_gui/smoke/plplotqt.pro.in
M	bindings/tcl/CMakeLists.txt
M	bindings/tk-x-plat/CMakeLists.txt
M	bindings/tk/CMakeLists.txt
M	bindings/wxwidgets/CMakeLists.txt
M	cmake/modules/cgm.cmake
M	cmake/modules/drivers-finish.cmake
M	cmake/modules/plplot_functions.cmake
M	cmake/modules/qt.cmake
M	cmake/modules/tk.cmake
M	doc/docbook/src/CMakeLists.txt
M	drivers/CMakeLists.txt
M	examples/CMakeLists.txt
M	examples/ada/CMakeLists.txt
M	examples/c++/CMakeLists.txt
M	examples/c/CMakeLists.txt
M	examples/d/CMakeLists.txt
M	examples/fortran/CMakeLists.txt
M	examples/lua/CMakeLists.txt
M	examples/lua/plplot_examples.lua.in
M	examples/octave/CMakeLists.txt
M	examples/python/CMakeLists.txt
M	examples/python/pyqt4_example.py
M	examples/python/pyqt5_example.py
M	examples/tcl/CMakeLists.txt
M	examples/tk/CMakeLists.txt
M	fonts/CMakeLists.txt
M	include/pldll.h.in
M	lib/csa/CMakeLists.txt
R096	lib/csa/csadll.h	lib/csa/csadll.h.in
M	lib/nistcd/CMakeLists.txt
R096	lib/nistcd/cddll.h	lib/nistcd/cddll.h.in
M	lib/nn/CMakeLists.txt
R096	lib/nn/nndll.h	lib/nn/nndll.h.in
M	lib/qsastime/CMakeLists.txt
R096	lib/qsastime/qsastimedll.h	lib/qsastime/qsastimedll.h.in
M	src/CMakeLists.txt
M	utils/CMakeLists.txt

commit 9cc1d067ee7fd7213d17ac1d737515828cad4d19
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Mar 23 17:15:46 2018 -0700

    Build system: configure a more uniform build of modules, swig-generated modules, static libraries and shared libraries
    
    I implemented this change using the new configure_library_build
    function that replaces the previously used (and misnamed)
    build_library function.  This new CMake function has a different set
    of arguments then the removed build_library function.  This new
    function allows not only the configuration of new explicit STATIC and
    SHARED builds or the old implied (via BUILD_SHARED_LIBS) STATIC or
    SHARED builds, but also the explicit new configuration of MODULE (dll)
    and swig-generated MODULE builds.  The type of library (i.e., "" [if
    decided by BUILD_SHARED_LIBS], "MODULE", "STATIC", "SHARED", or a
    language such as "python" [if a swig-generated module]) is now
    specified as the second argument.  In addition the old trailing
    namespace argument is dropped in favour of an external variable
    LIBRARY_NAMESPACE that should be set (with a trailing "::") globally
    once for a given project, e.g.,
    
    set(LIBRARY_NAMESPACE "PLPLOT::")
    
    for the PLplot project.
    
    As a result of this current commit, the "add_library" string only appears in the
    following files in the PLplot source tree:
    
    software@raven> find . -type f |grep -v .git |xargs grep -il 'add_library'
    ./ChangeLog.release
    ./cmake/test_ada/src_lib/CMakeLists.txt
    ./cmake/modules/UseSWIG.cmake
    ./cmake/modules/plplot_functions.cmake
    ./cmake/epa_build/libagg/libagg_CMakeLists.txt
    ./cmake/epa_build/libqhull/src/CMakeLists.txt
    ./cmake/epa_build/libharu/cmake.patch
    ./cmake/epa_build/shapelib/shapelib_CMakeLists.txt
    ./cmake/test_fortran/src_lib/CMakeLists.txt
    
    That is, if you look just at the PLplot project (i.e., you exclude
    historical mentions [ChangeLog.release] and various epa_build and test
    mini-projects), the actual use of the add_library command is reduced
    to the UseSWIG.cmake module copied from the CMake project and the
    configure_library_build function in plplot_functions.cmake.  In other
    words the configuration of the builds of shared objects now proceeds
    in a uniform manner for PLplot that is controlled by the logic in the
    configure_library_build function, and any idiosyncratic target
    property adjustments that might be done after the call to
    configure_library_build for each CMake "library" (actually a library
    or a dll) built by PLplot.
    
    Additional cleanups and changes:
    
    * For the swig-generated MODULE's, I now use
      ${SWIG_MODULE_${swig_target_name}_wrap_REAL_NAME}, e.g.,
      ${SWIG_MODULE_plplotc_wrap_REAL_NAME} to refer to the real target
      name after configure_build_library is called.  This automatically
      takes care of issues such as the "_" prefix used for the actual
      _plplotc target that is used when configuring swig-generated Python
      builds.
    
    * For the swig-generated MODULE's, I now have dropped all PREFIX and
      SUFFIX overwrites on the module properties.  Instead, I now rely on
      UseSWIG.cmake to set these properties correctly for each given Swig
      language.  And it appears that is currently done consistent with our
      previous overwrites.  However, if there is some PREFIX or SUFFIX
      screwup in UseSWIG.cmake for any Swig language or platform, I will
      adjust that file accordingly and report the issue to CMake as a
      CMake bug.
    
    * Had to set smokeplplotqt_SOVERSION and smokeplplotqt_VERSION in
      cmake/modules/plplot_versions.cmake so the smokeplplotqt library
      build could be configured in the standard way using configure_library_build.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by configuring PLplot with the -DENABLE_smoke=ON
    -DBUILD_HERSHEY_FONTS=ON options (to allow testing the build of the
    smokeplplotqt and hershey libraries) and by building the following
    targets:
    
    * smokeplplotqt
      There were no configure or build issues and ldd -r showed no
      run-time loader or symbol issues with this library (currently only
      used externally by one of Hazen Babcock's projects, but it would be
      good to implement at least a simple run-time test of this library as
      part of PLplot).
    
    * generate_stndfonts and generate_xtndfonts
      These targets build executables which link to the static hershey library,
      and I tested these executables as follows:
    
      ldd -r fonts/generate_stndfonts
      ldd -r fonts/generate_xtndfonts
      fonts/generate_stndfonts
      diff plstnd5.fnt ../plplot.git/data/
      fonts/generate_xtndfonts
      diff plxtnd5.fnt ../plplot.git/data/
    
      The diffs showed no changes compared to the source-tree versions
      of these generated Hershey font files.
    
    * test_noninteractive
    
      There were no configuration, build, run-time, or
      Postscript differences with this target.
    
    * test_interactive
    
      There were no configuration, build, or run-time
      issues with this target.
    
    N.B. the above good test_noninteractive and test_interactive tests are
    not comprehensive.  For example, the present changes have just been
    tested in the build tree and just for the shared libraries/dynamic
    devices case to save time.  So planned future comprehensive tests that
    do test many more configuration possibilities for both build-tree and
    install-tree may turn up additional issues for the present intrusive
    commit.

M	CMakeLists.txt
M	bindings/ada/CMakeLists.txt
M	bindings/c++/CMakeLists.txt
M	bindings/d/CMakeLists.txt
M	bindings/fortran/CMakeLists.txt
M	bindings/java/CMakeLists.txt
M	bindings/lua/CMakeLists.txt
M	bindings/ocaml/CMakeLists.txt
M	bindings/ocaml/plcairo/CMakeLists.txt
M	bindings/octave/CMakeLists.txt
M	bindings/python/CMakeLists.txt
M	bindings/qt_gui/CMakeLists.txt
M	bindings/qt_gui/pyqt4/CMakeLists.txt
M	bindings/qt_gui/pyqt5/CMakeLists.txt
M	bindings/qt_gui/smoke/CMakeLists.txt
M	bindings/tcl/CMakeLists.txt
M	bindings/wxwidgets/CMakeLists.txt
M	cmake/modules/plplot_functions.cmake
M	cmake/modules/plplot_version.cmake
M	drivers/CMakeLists.txt
M	examples/fortran/CMakeLists.txt
M	fonts/CMakeLists.txt
M	lib/csa/CMakeLists.txt
M	lib/nistcd/CMakeLists.txt
M	lib/nn/CMakeLists.txt
M	lib/qsastime/CMakeLists.txt
M	src/CMakeLists.txt

commit f4d7e1a30ec3a8e071574865d7780fce8d411fbd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Mar 16 19:21:05 2018 -0700

    Python binding: Improve UTF-8 fixup
    
    Our swig documentation strings (which include some UTF-8 glyphs such as
    "≥") are propagated directly to the swig-generated bindings/python/plplotc.py
    Python script.  So years ago when our bindings were strictly Python2 we
    had to implement a sed fixup to modify that file to append " It uses coding: utf-8"
    to the first line of that file to signal (according to PEP 263) that the encoding
    of that file is UTF-8.
    
    This commit improves the implementation of this fixup as follows:
    
    * Changed the implementation from using an additional
      add_custom_command/add_custom_target pair to the much simpler
      add_custom_command(TARGET _plplotc POST_BUILD ...) signature.
      The result is the same; the sed fixup occurs *AFTER*
      whenever swig (re-)generates bindings/python/plplotc.py.
    
    * It turns out that this fixup is not needed for Python3 because
      for that version of Python the default encoding is UTF-8.  Therefore,
      only implement the fixup for the Python2 case.
    
    * Because of the new implementation, the _plplotc_fixed target no
      longer exists.  So replace that target with the  _plplotc target
      wherever it occurs in our build system.
    
    * Change the comments in README.Release_Manager_Cookbook accordingly.
    
    As a result of this commit "_plplotc_fixed"
    no longer exists in our source tree except for the historical
    ChangeLog.release file.
    
    N.B. Note this remaining small Python2 fixup is actually a workaround
    for either a Python2 issue (for defaulting to ascii encoding rather
    than UTF-8) or else swig issue for not working around this Python2
    issue. But I have decided not to report this issue because of the
    uncertainty of where to report it and because it is undoubtedly an
    uncommon issue that is getting rarer (because Python2's share of the
    Python market keeps dropping).  In fact Python3 is working so well for
    PLplot, I plan to deprecate and eventually remove our Python2 support
    (including the current fixup) in the intermediate term (i.e., within a
    year or two).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by freshly configuring PLplot with either
    the set of CMake options
    
    # The python2 case
    -DBUILD_TEST=ON --DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON -DFORCE_PYTHON2=ON
    
    or
    
    # The (default) python3 case
    -DBUILD_TEST=ON --DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON
    
    For both cases, building the test_diff_psc target showed no configuration, build,
    run-time, or PostScript difference issues.

M	README.Release_Manager_Cookbook
M	bindings/python/CMakeLists.txt
M	doc/CMakeLists.txt
M	examples/CMakeLists.txt
M	examples/python/CMakeLists.txt

commit 593c07fcea6402b03c6b9c47842b09284bf2a1b2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Mar 14 16:22:44 2018 -0700

    PLplot build system: configure library builds in a more uniform manner
    
    I replaced calls to add_library, target_link_libraries, and the
    set_library_properties function with a call to the build_library
    function which for standard libraries can either be static or shared
    (but not STATIC only and not MODULE). This function calls add_library,
    creates a namespaced ALIAS library corresponding to that library,
    calls target_link_libraries in a standard way, and sets standard
    library properties.  Thus, this change significantly reduces
    the CMake code used to build our libraries and makes sure such
    building is done in a more uniform way.
    
    These new ALIAS libraries will be required in the future (so that the
    installed libraries can have namespaced targets associated with them
    so that common code between build tree and install tree can use
    namespaced library targets).  But the future plan is not to confine
    the use of namespaced targets just to the common code but also use
    them everywhere in the build tree where a library target is used in a
    read-only way as a matter of style (and safety for the
    target_link_libraries item case).  So for this commit I used ALIAS
    library targets in a small way to test them in
    that context.
    
    I also deleted the set_library_properties function since it is no
    longer used.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_noninteractive and
    test_interactive targets for shared libraries in the build tree
    without any configure, build, run-time, or PostScript difference
    issues.

M	bindings/ada/CMakeLists.txt
M	bindings/c++/CMakeLists.txt
M	bindings/d/CMakeLists.txt
M	bindings/fortran/CMakeLists.txt
M	bindings/qt_gui/CMakeLists.txt
M	bindings/tcl/CMakeLists.txt
M	bindings/wxwidgets/CMakeLists.txt
M	cmake/modules/plplot_functions.cmake
M	cmake/modules/plplot_version.cmake
M	fonts/CMakeLists.txt
M	lib/csa/CMakeLists.txt
M	lib/nistcd/CMakeLists.txt
M	lib/nn/CMakeLists.txt
M	lib/qsastime/CMakeLists.txt
M	src/CMakeLists.txt

commit ce4c2129fbcbb196a9e9276d1f38fb0c2b25d6a6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Mar 14 16:21:55 2018 -0700

    PLplot build system: update some copyright years

M	bindings/java/CMakeLists.txt
M	bindings/lua/CMakeLists.txt
M	bindings/ocaml/plcairo/CMakeLists.txt
M	bindings/octave/CMakeLists.txt
M	bindings/python/CMakeLists.txt
M	bindings/qt_gui/pyqt4/CMakeLists.txt
M	bindings/qt_gui/pyqt5/CMakeLists.txt
M	bindings/qt_gui/smoke/CMakeLists.txt
M	drivers/CMakeLists.txt
M	examples/fortran/CMakeLists.txt

commit d705381c6cdf99a390bdec22d859e45b5ef13e60
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Mar 13 13:58:27 2018 -0700

    PLplot library: Fix bug in command-line parsing for the PL_PARSE_NODELETE case
    
    This long-standing bug (which has been revealed by the recent x01c.c
    change which calls plparseopts with the PL_PARSE_NODELETE option) is
    the number of command-line options after command-line processing
    (stored in *p_argc) was being updated when the PL_PARSE_NODELETE
    option was specified.  The result was calls to plparseopts after the
    first call to that routine in x01c did not have the correct number of
    command-line options.  This commit fixes this bug.
    
    I also took this opportunity to improve the documentation of the
    -pl_parse_skip example option for x01c to make clear that this option
    must precede any non-PLplot options if the user is to avoid
    command-line parsing errors for this example.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running
    
    examples/c/x01c
    
    (which uses the PL_PARSE_NODELETE option in the first call to
    plparseopts) with all sorts of different option patterns both
    with and without the example -pl_parse_skip option.
    
    In all cases with -pl_parse_skip I obtained the expected results.  If
    this option preceded zero or more non-PLplot options, the number of options
    printed out by that option were correct both before and after the call
    to plparseopts with the PL_PARSE_SKIP option.  However, if non-PLplot
    options preceded -pl_parse_skip, gdb showed the first call to
    plparseopts with the PL_PARSE_NODELETE option silently failed with the
    pl_parse_skip_mode variable not set with the subsequent plparseopts
    call with PL_PARSE_FULL failing (as expected) because of those
    non-PLplot options.
    
    In all cases without -pl_parse_skip I also obtained the expected
    results (i.e., no command-line option processing errors unless
    non-PLplot options were used, and the expected interactive or
    noninteractive plot results.)

M	examples/c/x01c.c
M	src/plargs.c

commit 734aba7a3e08e7908ae4f2aefa88c64bd94acaab
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Sat Feb 3 21:02:26 2018 +0000

    Fixed possible uninitialised variable bug in wxPLplotwindow class
    
    There were execution paths where the wxDC pointer would not get
    initialised before it was passed into the stream in the
    setUseGraphicsContext method. This is now fixed. Thanks David Bergman
    for the bug report on the email list.

M	bindings/wxwidgets/wxPLplotwindow.h

commit d2a1a6d61ca0deb9025c019ed9d8d27577beb964
Author: Arjen Markus <arjen.markus@deltares.nl>
Date:   Sun Jan 7 12:05:39 2018 +0100

    Add new routines to the list of exported routines
    
    To build the library and the examples with the new routines to parse the command-line arguments we need to export these routines for Intel Fortran.
    
    Tested by: Arjen Markus <arjenmarkus@users.sourceforge.net> on bare Windows with the Intel Fortran compiler

M	bindings/fortran/plplotfortran_ifort.def

commit 70ec495533cb117016933f29239e7d2201f6fd9c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Jan 5 17:51:26 2018 -0800

    Fortran binding: Fix dropped specification of the defined region of cstring_address_arg_inout in plparsopts_dynamic
    
    This commit fixes a dropped (1:size_local) slice which specifies where
    cstring_address_arg_inout is defined for the
    max_cstring_length call.  My hope is this change will fix
    memory management issues encountered by Arjen when he tested
    plget_arguments_dynamic and plparseopts_dynamic with modern
    gfortran and ifort.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie with gfortran-4.9.2) by building the plplotfortran
    binding library without issues.  This change could not be tested
    at run-time because of allocatable length/size character
    array issues with (the ancient) gfortran-4.9.2.
    
    N.B. testing requested for modern gfortran and ifort.

M	bindings/fortran/plplot.f90

commit 3ee657ef568dc4f16eb0d5ad3d653ce4a10d9ebf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jan 2 12:59:15 2018 -0800

    Fortran binding: Tweak severe warning messages for parsing API

M	bindings/fortran/plplot.f90

commit 9fcc4d642ac3d65df16d08098f20dc7179a22570
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jan 2 12:13:25 2018 -0800

    Fortran standard example 01: restore default pl_parse_dynamic = .false.
    
    This is to correct my inadvertent commit of a local test case where I
    set pl_parse_dynamic = .true.

M	examples/fortran/x01f.f90

commit 6f2f4e4f43f755dcfee28c590e61039cf017de86
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jan 1 15:31:23 2018 -0800

    Fortran binding: implement dynamic length and size and static length and dynamic size variants of plget_arguments and plparseopts
    
    These new variants of plget_arguments and plparseopts were added to the
    existing static length and size variants.  In addition, examples/x01f.f90 was
    updated to test all variants of plget_arguments and plparseopts.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie with gfortran-4.9.2).  With this version of gfortran,
    the dynamic length and size variant of the API did not work at run
    time, but both the static length and dynamic size and static length
    and size variants did work.  For further details about how to run
    these tests and the results obtained, see README.release.
    Additional testing using more modern gfortran versions and other
    Fortran compilers is requested.

M	README.release
M	bindings/fortran/plplot.f90
M	bindings/fortran/plplot_small_modules.f90
M	examples/fortran/x01f.f90

commit dee0caa5225688b7bcfb6571c12da9db4fbaba69
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Dec 26 16:03:30 2017 -0800

    Fortran binding: Fix off-by-one error in plplot_private_utilities::c_to_character_array
    
    This routine blanks the tail end of output character array results, and the issue
    that was fixed was this blanking started one character too soon.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the x01f and ps targets (with the x01f
    source code locally modified to set pl_parse_skip_mode to .true.) and
    running
    
    software@raven> examples/fortran/x01f xxx -dev psc yyy -o testf.psc zzz
    argv before call to plparseopts(..., PL_PARSE_SKIP)
    i =   0, argument = examples/fortran/x01f
    i =   1, argument = xxx
    i =   2, argument = -dev
    i =   3, argument = psc
    i =   4, argument = yyy
    i =   5, argument = -o
    i =   6, argument = testf.psc
    i =   7, argument = zzz
    argv after call to plparseopts(..., PL_PARSE_SKIP)
    i =   0, argument = examples/fortran/x01f
    i =   1, argument = xxx
    i =   2, argument = yyy
    i =   3, argument = zzz
    PLplot library version: 5.13.0
    
    Before this fix all the trailing
    
    i =   [0-3] ....
    
    results were incorrectly truncated by one letter.

M	bindings/fortran/plplot_small_modules.f90

commit 71944dbd48f1c29c99252b862e5105b842ca478c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Dec 25 22:55:51 2017 -0800

    C example 01 and Fortran binding and example 01: improvements in command-line parsing
    
    The C example improvement was to implement the -pl_parse_skip option
    for examples/c/x01c.c that demonstrated the existing PL_PARSE_SKIP
    mode of the C version of plparseopts.  The Fortran binding improvement
    was to make similar PL_PARSE_SKIP mode functionality available for
    that binding via and added variant of the plparseopts API and a new
    Fortran function called plget_arguments.  The
    examples/fortran/x01f.f90 improvement was to implement a demonstration
    of that capability that gave the same results as the corresponding C
    results.  For further details see the write-up concerning these
    changes in README.release.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie with gfortran-4.9.2) by building the x01c, x01f, and ps
    targets, and running valgrind in the way described in README.release
    with perfect results.

M	README.release
M	bindings/fortran/included_plplot_real_interfaces.f90
M	bindings/fortran/plplot.f90
M	bindings/fortran/plplot_small_modules.f90
M	examples/fortran/x01f.f90

commit b224a834e4ff3b59a83f97a6e185658e5ed9b768
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Dec 24 15:18:11 2017 -0800

    plplot library: fix memory leak in plparseopts if that function is called more than once
    
    Each call of plparseopts allocates memory to store plsc->program, and
    that memory is normally deleted later in plend1.  However, if plparseopts
    is called multiple times with no plend1 call in between ==> memory leak.
    This commit addresses that issue by freeing non-NULL plsc->program in
    plparseopts before plsc->program is allocated.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the x01c and ps targets and running
    
    valgrind examples/c/x01c.c -dev psc -o testc.psc
    
    with perfect results (0 errors, no leaks are possible).
    
    Note that example/c/x01c.c is a good test case because it calls
    plparseopts twice (the first time with PL_PARSE_NODELETE, the second
    time with PL_PARSE_SKIP or PLPARSE_FULL depending on the results from
    the first call).  Before this fix, the valgrind report showed a memory
    leak for this example.

M	src/plargs.c

commit 1b0b78f8f158abce519c655a2be3f6ac37115036
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Dec 23 13:51:19 2017 -0800

    C standard example 01: implement -pl_parse_skip option for the example
    
    Note, the -pl_parse_skip command-line option demonstrates the
    PL_PARSE_SKIP mode for plparseopts, which parses just the
    PLplot-relevant options leaving the non-PLplot options for further
    parsing.  Thus, this option demonstrates the first part of how you
    would parse a mixture of PLplot and non-PLplot command-line options
    from C, and the long-term intention is to propagate this example
    option to standard example 01 for fortran first, and then the rest of
    our supported languages to demonstrate parsing a mixture of PLplot and
    non-PLplot command-line options is possible for those languages as
    well.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the x01c and ps targets and running
    
    software@raven> examples/c/x01c -pl_parse_skip xxx -dev psc yyy -o test1.psc zzz
    argv prior to call of plparseopts(..., PL_PARSE_SKIP)
    i =   0, argument = examples/c/x01c
    i =   1, argument = -pl_parse_skip
    i =   2, argument = xxx
    i =   3, argument = -dev
    i =   4, argument = psc
    i =   5, argument = yyy
    i =   6, argument = -o
    i =   7, argument = test1.psc
    i =   8, argument = zzz
    argv after call to plparseopts(..., PL_PARSE_SKIP)
    i =   0, argument = examples/c/x01c
    i =   1, argument = xxx
    i =   2, argument = yyy
    i =   3, argument = zzz
    PLplot library version: 5.13.0

M	examples/c/x01c.c

commit ef2bf58848be56992f47bb83fbf7ce662d3e612b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Dec 23 12:02:13 2017 -0800

    Style previous commit

M	bindings/d/plplot.d

commit 8aeee637ed0f0d766ca00e1cb25cee4dcb8650b0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Dec 18 13:13:57 2017 -0800

    Build system: fix sanity check logic for set_library_properties function
    
    if(NOT(${library}_SOVERSION OR ${library}_VERSION OR LIB_DIR))
    
    ==>
    
    if(NOT(DEFINED ${library}_SOVERSION AND DEFINED ${library}_VERSION AND DEFINED LIB_DIR))
    
    As is obvious above the prior version of the logic that has now been fixed
    was completely bogus (i.e,  used OR rather than the correct AND, and used true/false (which
    failed when ${library}_SOVERSION was 0) rather than doing the correct check that the
    variable had been DEFINED).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by configuring PLplot with cmake.  The result was
    there were no CMake errors due to the above revision in the sanity
    checking logic.

M	cmake/modules/plplot_functions.cmake

commit 5c628406e9a1c941dbe34d3db056f985e1ec8b08
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Dec 13 11:06:34 2017 -0800

    Build system: Drop the gcc -mieee-fp option on i*86 hardware for the Nan awareness compiler test
    
    Orion Poplawski discovered for i686 hardware and the latest gcc and
    glibc that (a) the gcc -mieee-fp option no longer compiles (apparently
    because glibc is dropping libieee.a) and (b) the gcc -mieee-fp option
    is no longer needed for the C NaN awareness test, i.e., when double x
    = NaN; then x != x is true.  Therefore, in this commit I have dropped
    the -mieee-fp option for the combination of i*86 hardware and gcc.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by configuring PLplot as usual with cmake to confirm
    that the change introduces no CMake logic errors (and that no special gcc option
    continues to work for testing C compiler NaN awareness on x86_64 hardware).
    
    when double x=NaN, then x != x.

M	cmake/modules/csiro.cmake

commit a7be76715300e829523be309c64d99b1b28c1bcc
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Dec 11 01:43:54 2017 -0800

    OCaml examples: fix standard example 33 to solve its inconsistencies with other languages
    
    The issue with examples/ocaml/x33.ml was simply that all pages demonstrating
    plcolobar results (page 5 and beyond) had not been implemented yet, and
    this commit fixes that issue.
    
    N.B. This resolves the last of the long-standing ocaml PostScript
    differences, and as a result we have gotten a clean PostScript difference
    report for the first time since 2010!
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running the test_diff_psc target.  The result was
    perfect PostScript differences (for all our standard examples
    including the Ocaml ones), e.g.,
    
    ocaml
      Missing examples            :
      Differing graphical output  :
      Missing stdout              :
      Differing stdout            :
    
    and similarly for all the computer languages we support.
    
    I also ran
    
    valgrind examples/ocaml/x33ocaml -dev psc -o test.psc
    
    and the resulting report showed memory leaks (as do all other
    OCaml examples) but "0 errors from 0 contexts".

M	README.release
M	examples/ocaml/x33.ml

commit b16d96713747fe027e7b08452c7716aa50fb0fc1
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Dec 11 00:40:10 2017 -0800

    Styled previous commit

M	examples/c/x33c.c

commit aa40de75266ae9fc1e24a5be10094b55b867c1a3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Dec 11 00:36:18 2017 -0800

    Core library and bindings: define PL_POSITION_NULL, PL_LEGEND_NULL, and PL_COLORBAR_NULL
    
    These option bits are all defined to be zero (0x in some languages, 0
    in others) to provide a way to specify no option bits for option
    arguments to pllegend and plcolorbar.  This allows users the
    (preferred) style choice of always using named option bits rather than
    numerical constants such as 0x or 0.  Furthermore, for certain
    languages (e.g., OCaml at least) the option bits are stored as part of
    an enum so until this change it was impossible to use an option bit of
    zero for any position, legend, or colorbar option.
    
    I propagated this update of #defined constants in plplot.h to the bindings by
    configuring PLplot with -DADD_SPECIAL_CONSISTENCY_CHECKING=ON and by
    using the following methods (which should be used every time there is
    such a #defined update of constants):
    
    * Run the check_plplotcapi_defines target and copy the generated file
      back to the appropriate part of bindings/swig-support/plplotcapi.i
    
    * Run the check_fortran_parameters target and copy the generated file
      back to bindings/fortran/included_plplot_parameters.f90
    
    * Run the check_fortran_parameters target and copy the generated file
      back to bindings/fortran/included_plplot_parameters.f90
    
    * Run the check_tcl_parameters target and copy the generated file
      back to bindings/tcl/plplot_parameters.h
    
    * Used the sed command and remaining instructions documented in
      bindings/python/Plframe.py to update the constants in that file
      consistently with bindings/swig-support/plplotcapi.i
    
    * Used the sed command and remaining instructions documented in
      bindings/d/plplot.d to update the constants in that file
      consistently with bindings/swig-support/plplotcapi.i
    
      Note I took this opportunity to collect all the previously
      hand-crafted constants in one place in plplot.d and work out the sed
      command (that is documented in the file) to generate those constants
      automatically.
    
    * Appropriate hand-crafted changes to bindings/ocaml files.
      After those, run the check_plplot_h.inc target and copy
      the generated file back to bindings/ocaml/plplot_h.inc if
      different.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by configuring PLplot using the CMake option
    -DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the
    check_all, test_noninteractive, and test_interactive targets
    with no obvious configure, build, or run-time errors and
    no PostScript difference regressions.

M	bindings/d/plplot.d
M	bindings/fortran/included_plplot_parameters.f90
M	bindings/ocaml/plplot.mli
M	bindings/ocaml/plplot_core.idl
M	bindings/ocaml/plplot_h
M	bindings/ocaml/plplot_impl.c
M	bindings/python/Plframe.py
M	bindings/swig-support/plplotcapi.i
M	bindings/tcl/plplot_parameters.h
M	include/plplot.h

commit ab6649299ba1802f992a92afe4b907d3b703c433
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Dec 10 16:16:11 2017 -0800

    Documentation: Update swig documentation to be consistent with recent DocBook documentation update
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by configuring PLplot with
    -DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the
    check_swig_documentation target without issues.

M	bindings/swig-support/swig_documentation.i

commit 244a526f97bd5d02719394a9121f63e43ec0650c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Dec 9 12:37:38 2017 -0800

    C examples: change -colorbar option to -nocolorbar option for example 33

M	examples/c/x33c.c

commit 35eafc15523b75616ec37fcb5cacd2b8fcfe470f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Dec 9 11:01:45 2017 -0800

    OCaml examples: Fix inconsistencies with other languages for standard example 16
    
    The cause of this long-standing inconsistency was the use of the
    high-level OCaml colorbar API for all the color bars in this example.
    That API is fundamentally inconsistent with the OCaml plcolorbar API
    because colorbar sets a default color before calling plcolorbar and
    then restores the original color after that call.  And those extra
    color settings were causing inconsistencies with the results for
    standard example 16 for other languages.  This commit replaced all
    calls to colorbar by calls to plcolorbar, and that change completely
    solved the inconsistency.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_diff_psc target.  The resulting
    error report for ocaml has all the long-standing example 16
    differences removed as a result of this commit, i.e.,
    
    ocaml
      Missing examples            :
      Differing graphical output  :  33
      Missing stdout              :
      Differing stdout            :
    
    (Those remaining 33 differences are long-standing as well and are
    caused by that OCaml example being partially implemented, i.e., all
    the color bar parts of that OCaml example are missing.
    However, now that the example 16 color bar discrepancies have finally
    been solved, that future fix should be straightforward.)
    
    I also ran
    
    valgrind examples/ocaml/x16ocaml -dev psc -o test.psc
    
    and the resulting report showed memory leaks (as do all other
    OCaml examples) but "0 errors from 0 contexts".

M	bindings/ocaml/plplot_h
M	examples/ocaml/x16.ml

commit e4105d1d1063292c8f33f34cdcc734137f2a59ed
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Dec 9 10:32:27 2017 -0800

    Ocaml binding: change indentation and tweak wording of binding description

M	bindings/ocaml/README

commit 601650e3bc4c2cedd9c786dcb6536e7012b3d8a9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Dec 8 19:01:04 2017 -0800

    DocBook documentation: Update pllegend documentation
    
    I just noticed the previous nrow and ncolumn argument documentation was
    completely wrong (obviously copied from another argument entry
    as a "temporary" place holder), nlegend documentation was
    outdated, etc.  These issues were all fixed by copying
    wording from the corresponding doxygen documentation of pllegend.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by configuring PLplot with the -DBUILD_DOC=ON
    cmake parameter, building the html version of the documentation
    using "make html", and viewing that with a browser.

M	doc/docbook/src/api.xml

commit 0da2c1403fd3a67474065207e3847e7b4f2826f7
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Dec 1 15:03:39 2017 -0800

    Add remove_trailing_whitespace.sh to the files that are excluded by that script from being processed by that script
    
    The reason why remove_trailing_whitespace.sh should not act on itself
    is that changes to shell (bash) scripts done while they are executing
    can potentially mess up their results.

M	scripts/remove_trailing_whitespace.sh

commit 2435390c773fb86584d3b5e761685e3afd3bce3e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Dec 1 14:17:51 2017 -0800

    Website: Update colour scheme
    
    The css colour scheme for the PLplot website was developed a bit
    further for the timeephem project to make the dark text colour
    absolutely black for best visibility.
    
    Adopt this colour change also for the PLplot website.

M	www/css/CMakeLists.txt
M	www/css/style.css.in

commit d93676de7a9b1481fb463234e93781a32900f8da
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Oct 31 23:28:48 2017 -0700

    OCaml bindings and examples: add and use plmap* API
    
    The added OCaml API is for plmapline, plmapstring, plmaptex, and
    plmapfill.  I added an "Exmoor" page to the 19th standard OCaml
    example using this new API to make results from that example
    consistent with the corresponding C example.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_diff_psc target.  The resulting
    error report for ocaml has all the long-standing example 19
    differences removed as a result of this commit, i.e.,
    
    ocaml
      Missing examples            :
      Differing graphical output  :  16 33
      Missing stdout              :
      Differing stdout            :
    
    (Those example 16 and 33 differences are long-standing as well.)
    
    I also ran
    
    valgrind examples/ocaml/x19ocaml -dev psc -o test.psc
    
    and the resulting report showed memory leaks (as do all other
    OCaml examples) but "0 errors from 0 contexts".

M	bindings/ocaml/CMakeLists.txt
M	bindings/ocaml/README
M	bindings/ocaml/plplot.mli
M	bindings/ocaml/plplot_core.idl
M	bindings/ocaml/plplot_impl.c
M	examples/ocaml/x19.ml

commit 76697707c81d7c094a57ab6737d7cf98c0bd5d55
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Oct 31 15:17:17 2017 -0700

    OCaml binding: remove gratuitous inconsistencies between plplot_h and plplot.h
    
    I recreated plplot_h from the common API declarations in plplot.h with
    argument types #defined appropriately and using #if 0....#endif
    preprocessor commands to ignore the parts of the common API (e.g., API
    with callback arguments) that cannot be processed with touchup.ml.
    These changes minimize the differences between plplot_h declarations
    and those in plplot.h, and the results typically have different
    argument types and argument names and some reordering of the API
    compared to the previous results.  The touchup.ml file had to be
    changed to be consistent with the a -> alpha argument name change for
    some of the color map functions.  The results of touchup.ml were
    generated using the cmake option -DADD_SPECIAL_CONSISTENCY_CHECKING=ON,
    building the check_plplot_h.inc target, and copying back
    bindings/ocaml/generated_plplot_h.inc in the build tree
    to bindings/ocaml/plplot_h.inc in the source tree.  The resulting
    plplot_h.inc differences consist solely of argument name changes, one void
    argument rather than an empty argument, and some reordering of the API.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by configuring PLplot with the cmake option
    -DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the
    check_plplot_h.inc target without issues and building the
    test_diff_psc target without obvious configure, build, or run-time
    issues or PostScript difference regressions.

M	bindings/ocaml/plplot_h
M	bindings/ocaml/plplot_h.inc
M	bindings/ocaml/touchup.ml

commit 14d838fc3587cbfe260cccf4106707dd837dfb29
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Oct 31 15:10:33 2017 -0700

    Core plplot code: improve alphabetization of common API
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by configuring PLplot with the cmake option
    -DADD_SPECIAL_CONSISTENCY_CHECKING=ON, and building both the check_all
    and test_diff_psc targets.  The consistency checks run by check_all passed
    without issues, and there were no configure, build, or obvious run-time
    issues with the test_diff_psc target and no PostScript difference
    regressions.

M	include/plplot.h

commit 4e338285ee632e4909de969168ff6d8044748b99
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Oct 31 14:41:56 2017 -0700

    Documentation: make API documentation for swig-generated bindings consistent with DocBook API documentation
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the check_swig_documentation target.

M	bindings/swig-support/swig_documentation.i

commit 69067983c65013058cfbe4cf047f0817f1933d37
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Oct 12 19:25:07 2017 -0700

    Drop example 17 from -dev wxwidgets tests
    
    This was done in the interest of testing convenience because this
    example takes a considerable length of time to complete for -dev
    wxwidgets, and this change follows what we have already done for the
    same reason for -dev qtwidget and -dev xcairo (which are quite slow
    for this particular example, but still faster than -dev wxwidgets).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie).  Note this test was way over the top for this simple
    change, but I took this opportunity to do complete testing because it
    was time to do this in any case as a test of previous commits, and
    also it gave me the opportunity to test a version of CMake that I
    built myself from the CMake 3.10.0-rc2 source code using the bootstrap
    method.  This test was performed by running (from a source tree with a
    space in the prefix)
    
    time (nice -19 scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command ~/cmake/install-3.10.0-rc2/bin/cmake --do_submit_dashboard yes)
    
    (Note because of the choice of a "spaced" source tree and the above
    --prefix, this test has a space in the prefixes of the source, build,
    and install trees.)
    
    Check the results:
    
    # Check for any regressions in the warnings in the cmake output.
    less ../comprehensive_test_disposeable\ blank/shared/noninteractive/output_tree/cmake.out
    
    # Check for some non-standard warnings:
    grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout'
    
    # Check for all errors:
    grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out
    
    # Check for any ldd issues for the shared and nondynamic cases.
    grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
    
    # Check for any PostScript or Text differences between all non-C languages and the corresponding
    # C results.
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
    
    These checks showed no configure, build, or run-time issues.
    Furthermore, the last check showed there were no PostScript difference
    regressions (i.e., the only PostScript difference issues revealed by
    that check were the long-standing ones for OCaml).  In addition, 3
    dashboards (for the shared, nondynamic, and static cases) were
    correctly posted to <http://my.cdash.org/index.php?project=PLplot_git>
    although with long-standing spurious warning counts for the cmake step
    which I have been unable to figure out, yet.

M	plplot_test/test_c_interactive.sh.in

commit 14ecc4bd943caa40a830e0da066ff7a220b9d5e8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Oct 10 19:07:02 2017 -0700

    C and C++ source code: replace all use of the WIN32 and __WIN32__ macros with the _WIN32 macro
    
    This change fixes bug 189 <https://sourceforge.net/p/plplot/bugs/189/>
    (which essentially found a Windows compiler that did not set WIN32 but
    which did set _WIN32).  This change is also consistent with a recent
    list recommendation from Jim Dishaw, and also the (dated) "Windows,
    Cygwin (non-POSIX), and MinGW" section of
    <https://web.archive.org/web/20140625123925/http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system>.
    
    This fairly intrusive change was done mostly using sed commands for
    convenience, but because of the possibility of screwing up such
    commands, this change was reviewed to make sure it did not change too
    much be reviewing "git diff" results in detail.  It was also reviewed to make
    sure it changed enough by checking our entire source code tree for all
    instances of WIN32 that had not been converted to _WIN32 to insure all
    such remaining instances were legitimate ones.  Our entire source tree
    was also checked for remaining occurrences of __WIN32__, and there are
    none.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the "all" and "test_noninteractive"
    targets.  There were no warning regressions; no obvious configuration,
    build, or run-time errors; and no PostScript difference regressions.
    
    The above tests are just due diligence that none of these Windows-related
    changes affect Linux results, and fundamental testing of these changes
    still needs to be done on all the many different Windows platforms we support.

M	README.release
M	bindings/tcl/tclAPI.c
M	bindings/tk-x-plat/plplotter.c
M	bindings/tk/plframe.c
M	bindings/tk/pltkd.h
M	bindings/tk/tcpip.c
M	bindings/tk/tkMain.c
M	cmake/epa_build/libharu/cmake.patch
M	cmake/epa_build/libqhull/src/libqhull.h
M	drivers/deprecated_wxwidgets_agg.cpp
M	drivers/pdf.c
M	drivers/tkwin.c
M	drivers/wxwidgets_comms.cpp
M	drivers/wxwidgets_comms.h
M	drivers/wxwidgets_dev.cpp
M	examples/c/x22c.c
M	include/pldll.h.in
M	lib/csa/csadll.h
M	lib/csa/nan.h
M	lib/nistcd/cddll.h
M	lib/nn/nan.h
M	lib/nn/nndll.h
M	lib/qsastime/qsastimedll.h
M	src/plctrl.c
M	src/plfreetype.c
M	src/plstdio.c

commit e0d5fdf5df1b619b3f3b3dfe5c082b6fe488e340
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Oct 10 17:59:33 2017 -0700

    Fix recently introduced PostScript difference regressions for example 19
    
    These regressions were recently introduced by the plmapfill-> plmapline
    changes to the C and C++ versions of example 19, and were fixed by
    propagating these changes to all our supported computer languages
    other than OCaml (which already has long-standing propagation issues for example 19).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_diff_psc target.  As a result
    the only non-empty PostScript difference summary was
    
    ocaml
      Missing examples            :
      Differing graphical output  :  16 19 33
      Missing stdout              :
      Differing stdout            :
    
    These differences are long-standing ones, i.e., we are back to a situation
    where there are no PostScript difference regressions (compared to
    e.g., plplot-5.13.0).

M	examples/ada/xstandard19a.adb
M	examples/ada/xtraditional19a.adb
M	examples/d/x19d.d
M	examples/fortran/x19f.f90
M	examples/java/x19.java
M	examples/lua/x19.lua
M	examples/octave/x19c.m
M	examples/python/x19.py
M	examples/tcl/x19.tcl

commit 3fe27f0ecadb14d94a1d5ed9125b35ec82ef67d3
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Fri Oct 6 23:04:36 2017 +0100

    WxWidget bug fix for wxWidgets during initialisation
    
    The wxPLViewer uses the size of the previously rendered bitmap to test
    whether or not it needs to rerender on a resize event. However it can
    receive a resize event before initialising te bitmap and on some
    platforms that causes a crash/assert fail/exception. Added a check for
    bitmap initialisation before getting the size of the bitmap.

M	bindings/wxwidgets/wxPLplotwindow.h

commit 3379c4eaa7c4cdebfcc3238bbfe023fb3732e0f9
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Fri Oct 6 00:15:31 2017 +0100

    Fixed compile bug in wxPLViewer for gcc
    
    GCC is clearly a bit stricter or less clever (depending upon your
    perspective I guess) than Visual Studio on the format of
    calling methods of templated classes. Updated the code to fix the
    compile error given by GCC.

M	bindings/wxwidgets/wxPLplotwindow.h

commit 476ce7392ad45624b41cd761bf1ebd51204fb957
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Oct 5 12:31:32 2017 -0700

    Build systems: output additional information
    
    The added information is the following:
    
    * Full pathname of the cmake executable
    * Name of generator
    * CMAKE_INCLUDE_PATH (both cache variable and environment variable forms)
    * CMAKE_LIBRARY_PATH (both cache variable and environment variable forms)
    * CMAKE_PLATFORM_INFO_DIR (the location where configured language support files live)
    
    I have consistently added this output both for the core build system
    as well as the CMake-based version of the installed examples build system.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running cmake in the build tree and observing the
    output.  The install-tree version has not been tested this way, but
    the identical CMake logic has been copied in that case so it should be
    fine.

M	CMakeLists.txt
M	examples/CMakeLists.txt

commit cd8f69d7abe4bc304cfac595fd67af097783dcb1
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Wed Oct 4 23:37:31 2017 +0100

    Removed a few lines of code used for debugging that should never have
    been commited.

M	utils/wxplframe.cpp

commit bb938c8baf3c19b1bff94cc27c073ee9c8bd62bb
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Wed Oct 4 23:36:45 2017 +0100

    Style only commit

M	utils/wxplframe.cpp

commit 20069523d621dd6f3a37a6a5b18d344a8ac52c75
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Wed Oct 4 23:32:33 2017 +0100

    Fixed recently introduced error that stopped wxPLViewer realizing
    plotting was complete
    
    A recent change accidentally adjusted the logic for a set of if/else
    statements, meaning that the timer that checks for new data got
    restarted. The result was a hang with IPC3 comms while the blocking
    getData function waited for data that never arrived. For non-IPC3 comms
    the repeated checks had no specific bad effects other than wasted cpu
    cycles I guess.

M	utils/wxplframe.cpp

commit e4fb932fe67ac431e3ae3205289f58ff1b074a64
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Wed Oct 4 23:24:30 2017 +0100

    Set the option of a render delay after resizes on wxPLplotwindows
    
    When rendering complex plot resizes can become jerky, unresposive and in
    some cases impossible because the window is continually trying to
    rerender the plot.
    
    Now set this up so that a delay to the render can be set and after
    resize the render only happens once the size has remained constant for
    that delay time. For wxPLviewer that delay time has been set to 1000 ms
    (1 s). This fixes bug #170 https://sourceforge.net/p/plplot/bugs/170/.

M	bindings/wxwidgets/wxPLplotwindow.h
M	utils/wxplframe.cpp

commit ff29053fe279e0424cc94c5f4d31a9291d8362a4
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Wed Oct 4 11:30:18 2017 +0100

    Attempted workaround for wxPLViewer IPC3 hangs
    
    When pllocate is called the core code then requests data from
    wxPLViewer in a blocking manner. Meanwhile wxPLViewer received the
    locate instruction, but carried on requesting further plot commands from
    the core code in a blocking manner while waiting for the user to click
    the mouse. This caused deadlock.
    
    Modified the wxPLViewer code so that it no longer requests data from the
    core code while waiting for locate data.
    
    This sortof works and sometimes allows execution beyond the use of
    locate in example 20, but then we seem to hit deadlock later. Not sure
    why.

M	utils/wxplframe.cpp

commit f5974813621b88f7d9e912dc86dde0809b390803
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Tue Oct 3 22:12:09 2017 +0100

    Towards correct locate state variable assignment in wxPLViewer
    
    I found that the locate state variable should represent the mouse
    buttons that were down immediately before the mouse event in question.
    I.e any other buttons held down at the same time or if the event in
    question was a release, then the button that was released.
    
    In theory the logic now in wxPLViewer is correct, but the frame is not
    capturing button release events so these events are not generating any
    locate information. This may require use of a wxPanel which I have been
    meanuing to do anyway as it is best practice. This commit is still an
    improvement on the incorrect locate information that was being provided
    though so I thought it was worth commiting now.

M	utils/wxplframe.cpp

commit 5232aaca74724e69e5ad61c12de63d31b44c0151
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Tue Oct 3 15:15:01 2017 +0100

    Added support for xor rendering and fixed a locate bug in wxWidgets.
    
    Example 20 didn't do the locate part because wxWidgets driver did not
    support xor mode. added a flag to say this is supported, but actually
    support isn't really there fully. Support is there when a wxDC is passed
    into the driver, however when using the wxPLViewer there is an issue -
    when xor mode is set the draw commands are no longer saved to the buffer,
    so they never get passed to the viewer. Changing this behaviour will be
    discussed on the email list.
    
    A locate bug was then shown up by this example. When locate occurred on
    a page other than the first, the PLViewer may have still been on an
    earlier page. We now record the page on which the locate occurred and do
    not action it until the user has moved to that page.
    
    The three sem comms suffers from a further locate bug which needs
    further work and is caused by both the core and the viewer code
    getting stuck sitting and waiting for the other to transmit data. But
    this commit means that the older comms method deals with locates
    absolutely correctly.

M	drivers/wxwidgets.cpp
M	drivers/wxwidgets.h
M	drivers/wxwidgets_dev.cpp
M	utils/wxplframe.cpp
M	utils/wxplframe.h

commit 124a0c3a2745fe6e3060bc61a6ef817e0e41e013
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Mon Oct 2 15:32:16 2017 +0100

    Set all clip limit changes I could find to use plP_sclp and hence get
    recorded in the buffer
    
    Clip limits need to be recorded in the buffer in order to be correctly
    set during a replot. An example of this problem was x33 where legends
    would not get rendered properly as seen by the wxPLViewer and reported
    as bug #176 https://sourceforge.net/p/plplot/bugs/176/.
    
    I've searched the code for raw assignments of the clip limits and
    replaced them all with plP_sclp calls in order to make sure that they
    are recorded in the buffer. I guess the joy of C (vs C++ whee these
    variables could have been hidden) is that there is nothing stopping
    people adding new raw assignments.
    
    One raw assignment that I left was in plmetafile.c. I couldn't work out
    why a driver would be modifying the clip limits, so I just left them
    alone. I will email Jim Dishaw and ask his advice.
    
    Tested by running x33c with the wcPLViewer to check all legends are
    correctly rendered.

M	src/plcore.c
M	src/plvpor.c

commit 0f71a774d13a1ab67887c291646e0a83360b3fcd
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Mon Oct 2 14:47:54 2017 +0100

    Added clipping to the wxWidgets FillPolygon function

M	drivers/wxwidgets_dev.cpp

commit 5b336deacd9de4a16471f1f4a98d12c75d2e5090
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Mon Oct 2 00:08:50 2017 +0100

    Fixed crashes associated with -eofill
    
    The test to make sure that the PLStream was ready to accept a plP_state
    call was incorrect. It was testing plsc->initialized !=0, when it should
    have been checking plsc->level > 0.

M	src/plargs.c

commit 81fafd26e60d3ff4483f4d5bf4c8a666ee758f52
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Sun Oct 1 23:57:22 2017 +0100

    Fixed failure to flush with wxViewer
    
    This was simply a loop that required exiting to allow rendering when a
    flush command was received.
    
    This fixes bug #169 https://sourceforge.net/p/plplot/bugs/169/
    
    Tested by running example 17

M	utils/wxplframe.cpp

commit 90692d8fdcfe801a5d4439caa915c4df976e56bb
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Sun Oct 1 23:24:00 2017 +0100

    Fixed background clear for wxWidgets driver
    
    The unit conversion for getting the region to clear was missing in
    wxPLDevice::ClearBackground. This has been added.
    
    This fixes bug #171 https://sourceforge.net/p/plplot/bugs/171/
    
    Tested by ammending x21 so that each subplot has a different colout
    background on page 2.

M	drivers/wxwidgets_dev.cpp

commit 315481fa073820302e9c4fb4ffed3c78c60800b3
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Sun Oct 1 12:51:46 2017 +0100

    Fixed plreplot and wxPLViewer bugs regarding begining of pages
    
    This addressed the bug report at
    https://sourceforge.net/p/plplot/bugs/168/
    
    There were two issues to address. The first was that if plreplot is
    called but the PLStream happens to be at the beginning of the page then
    the new beginning of page (which generally involves clearing the
    background to the bgcolour set from the buffer) was ignored. Now the
    status is set to end of page before the buffer read begins.
    
    The second issue was that during initialisation wxPLViewer added a
    beginning of page event to the buffer. It then received the buffer to
    plot, which included a second beginning of page even and appended this
    to the existing buffer. This gave two consecutive beginning of page
    entries in the buffer and the second one (which is the one we actually
    want) was ignored. This was fixed by checking if the data
    received was the first data, and if so then overwrite rather than append
    to the buffer.
    
    Tested by running x16 and checking we get correct background colours for
    all plots.

M	include/plplotP.h
M	src/plbuf.c
M	src/plcore.c
M	utils/wxplframe.cpp

commit b603fd228b29d75f0f3fd2b4b6518e3cf806afe3
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Sun Oct 1 00:38:58 2017 +0100

    Fixed wxWidgets even odd winding bug when using viewer
    
    This was really a buffer bug or at least the modifications here fix a
    buffer bug.
    Basically the dev_eofill variable was not being recorded in the buffer
    anywhere so it was never passed to the viewer. It is now recorded as
    part of the the state at beginning of page and plP_state is now called
    if opt_eofill is called after initialization which causes the state
    change to be recorded. A new state #define has been added to facilitate
    this.
    
    Tested by Phil Rosenberg by running example 27 with and without the
    -eofill command argument, however, only up to the point of checking in a
    debugger that wxPLViewer receives the value and calls the fill function
    with the correct fill option. I'm not actually sure what the difference
    in output should be - both looked the same to me, but maybe I'm missing
    something subtle.

M	include/plplotP.h
M	src/plargs.c
M	src/plbuf.c

commit e60fba878d5429592d9c084e18b29f834099189e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Sep 29 12:26:48 2017 -0700

    Fix style and trailing blank issues in a recent commit

M	doc/docbook/src/api.xml
M	src/plmap.c

commit e3c595819cf8f7596d09be6d4ac0c2beb7e642c3
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Fri Sep 29 12:32:04 2017 +0100

    Fixed error in map example 19
    
    The rivers were accidentally plotted with plmapfill not plmapline. This
    was masked by the fact that before recent fixes the shapefile's render
    type was always used.

M	examples/c++/x19.cc
M	examples/c/x19c.c

commit 6fbdc3353d7031278cd803792c226a1d8adf0ae6
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Fri Sep 29 11:49:57 2017 +0100

    Fix plmapline
    
    plmapline is supposed to override the render type of drawmap, passing in
    SHPT_ARC as the type to draw, but SHPT_NULL was passed instead causing
    the type to be derived from the file.
    
    Bug spotted and patch sent by Mark de Wever. Thanks for the
    contribution.

M	src/plmap.c

commit 124674358b7ffe41057d956351e298ddd12a82a9
Author: Arjen Markus <arjen.markus@deltares.nl>
Date:   Fri Sep 29 11:01:21 2017 +0200

    Add scripts and lists of required/recommended packages for Cygwin (64bits) and MinGW/-w64/MSYS2
    
    These scripts are examples of how to run CMake/make and the comprehensive tests
    for these two platforms. While they have been derived from scripts I have been
    using for a long time now, I have not tested these cleaned versions thoroughly
    yet. There may still be some quirks left in or inadvertently left out. The
    clean-up itself will be useful for me too - lots of stuff had accumulated over
    time not making it easy to determine what is really needed.
    
    Tested but not thoroughly by Arjen Markus (arjen.markus@users.sourceforge.net)

A	scripts/cygwin/interactive_launch_comprehensive_test.sh
A	scripts/cygwin/noninteractive_launch_comprehensive_test.sh
A	scripts/cygwin/package_list.txt
A	scripts/cygwin/run_cmake.sh
A	scripts/msys2/interactive_launch_comprehensive_test.sh
A	scripts/msys2/noninteractive_launch_comprehensive_test.sh
A	scripts/msys2/package_list.txt
A	scripts/msys2/run_cmake.sh

commit a4d9897f24ef150f8f037d09ff1cac80cd67ce63
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Thu Sep 28 21:19:55 2017 +0100

    Fixed the overrides for render type for the maps.
    
    The render type passed into drawmap() are now respected. Passing
    in a SHPT_NULL type causes the type from the file to be used.

M	doc/docbook/src/api.xml
M	src/plmap.c

commit aadbb28ec27a725eb8475dc67fcf28a23ec7d50a
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Thu Sep 28 20:51:59 2017 +0100

    Restyle only commit

M	include/plplot.h
M	src/plmap.c

commit 57e50d8bfdc4c3e687ec8347de1257cb257ed967
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Thu Sep 28 20:41:43 2017 +0100

    Edited plmap documentation
    
    This now reflects the changes made in the previous two commits and the
    fact that shapelib is required for maps.

M	doc/docbook/src/api.xml

commit 0b7dc2d42f29eed1780c01d1814ee5ddd9901dd8
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Thu Sep 28 20:01:49 2017 +0100

    Cleared out some unused functions from plmap.c

M	src/plmap.c

commit 7e7acff15a6eb8aff3b13d94740622b571f0ad77
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Thu Sep 28 19:50:41 2017 +0100

    Fixed PLFLT issue in plmap and issue with polygons wrapping the globe
    
    There was a problem with array types if PLFLT was not a double. this got
    introduced because shapelib always deals in doubles and in the last
    commit the conversion got removed. It has been added back in a more
    useful place.
    
    Also dealt with plmap rendering of polygons that wrap the whole globe,
    e.g. Antarctica. We should also effectively deal with the case where
    such a polgon gets turned inside out, like when doing a polor plot with
    the north pole in the centre.

M	src/plmap.c

commit 47222ff73c8410dc717ed4886e2ea88e06f5649e
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Thu Sep 28 18:21:37 2017 +0100

    Massively simplified the map code to fix a rendering bug and added
    PLFLT_HUGE_VAL to plplot.h
    
    A rendering bug was reported - see email to the list to the plplot-devel
    list entitled Plmap omits lines at the left hand side of the map dated
    18th Nov 2016. The bug was as described, lines on a lat/lon map that
    touched the left edge of the plot dissapeared.
    
    I have removed the code that tried to be clever and wrap cut sections
    of lines that weren't supposed to be plotted and attempted to wrap them
    round the globe if needed. Instead I now draw objects multiple times if
    needed to cover the wraparound. Note we also now support doing a plot
    which loops round the globe multiple times, so for example you could do
    lon -180 to +540 and you would get two full renderings of the globe.
    
    I added PLFLT_HUGE_VAL as I wanted to ensure that if someone threw one
    of the floating point limiting values in as the limit for the map plot
    then I wouldn't get stuck in a near infinite loop.

M	include/plplot.h
M	src/plmap.c

commit 0f3dcb2acf1df511a9a4299079234853043458c3
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Thu Sep 28 15:29:51 2017 +0100

    Comments and minor tidy in plmap.c
    
    Just added and edited some comments. Also removed reading the max/min
    values from the shapefile as we don't use these values anywhere.

M	src/plmap.c

commit a52aa2ff0dd371bc86784c58a4b1538eaa4ac2c6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Sep 25 12:52:54 2017 -0700

    Update our source tree from plplot.sourceforge.net (or plplot.sf.net) to plplot.org
    
    As a result of this change the command
    
    find . -type f |grep -v .git |xargs grep -El 'plplot.sf.net|plplot.sourceforge.net'
    
    yields only the following list of historical files
    
    ./rpm/plplot_mandrake9.2.spec
    ./rpm/plplot_redhat7.3.spec
    ./rpm/plplot_mandrake8.1.spec
    ./rpm/plplot_mandrake8.0.spec
    ./rpm/plplot_redhat6.2.spec
    ./rpm/plplot_redhat7.2.spec
    ./rpm/plplot_redhat7.1.spec
    ./README.release
    ./README.cumulated_release
    ./www/announce/announce-plplot-5.2.1.html
    ./www/announce/announce-plplot-5.1.0.html
    ./www/announce/announce-plplot-5.3.0.xml
    ./www/announce/announce-plplot-5.3.1.xml
    ./www/announce/ChangeLog-5.3.0-5.3.1
    
    Tested by: Alan W. Irwin <airwin@users.soureforge.net> on Linux
    by running
    
    echo irwin$'\n'irwin$'\n'raven$'\n'/home/irwin/public_html/plplot$'\n'yes |scripts/generate_website.sh
    
    and confirming there are no warning regressions or errors using
    
    find /tmp/plplotdoc -name '*.out' |xargs grep -i warning |less
    find /tmp/plplotdoc -name '*.out' |xargs grep -i error |grep -vE 'unable to read file loc from'
    
    (That grep -vE stanza is to remove output lines from doxygen that tend to
    include some case variants of "error" in the string because the
    referred to function name contains that substring.)
    
    I also very superficially checked the locally generated website to, e.g.,
    confirm the internal references are to plplot.org and not plplot.sf.net.
    However, that check also showed obsolete/deprecated functions had been changed due to
    all the recent cruft removal.  So because of these post-5.13.0
    cruft-removal changes, I have decided not to upload the locally generated website
    to SourceForge so that site will still contain internal references to
    plplot.sf.net and plplot.sourceforge.net until the next release
    when the regenerated website will automatically be uploaded
    as part of the usual release process.
    
    N.B. www/README.domain still needs to be created to explain in detail what we
    need to do in the future to maintain plplot.org and www.plplot.org.

M	NEWS
M	README
M	README.Release_Manager_Cookbook
M	README.release
M	bindings/ocaml/README
M	bindings/tk/about.tcl
M	cmake/modules/docbook.cmake
M	doc/docbook/README.developers
M	doc/docbook/src/intro.xml
M	doc/pstex2eps.1
M	drivers/README.wxwidgets
M	www/announce/CMakeLists.txt

commit c275d59fe6059899fbf49587a20db9ce57e6235c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Sep 10 17:39:08 2017 -0700

    Substantially update the history of our DocBook documentation project

M	doc/docbook/README

commit f997464d2e173137e3cb33d3d99f03a7bfdaa428
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Sep 25 11:45:07 2017 -0700

    Fix @param Doxygen bug

M	src/plmem.c

commit 53b33bdd81580e8a09aa1ae9c7dc8752d0c4b4e6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Sep 21 08:43:58 2017 -0700

    Official deprecation of C++ cruft
    
    Thirteen C++ methods (see README.release for the full list) have been
    unoffically deprecated (via comments in the code and lack of use in
    our C++ examples) for a long time.  One of these is the unofficially
    deprecated (AND incorrect) historical name "col" for the col1 method,
    and the rest are unofficially deprecated versions of methods which use
    PLINT instead of bool for logical arguments.
    
    With this commit, these unofficially deprecated methods have now been
    officially deprecated, i.e., they will only be accessible if a user
    sets -DPL_DEPRECATED=ON.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie).  The following tests were all done in the build tree for
    the shared libraries case:
    
    * Built the "all" target for -DPL_DEPRECATED=ON
    
    * Built the "all" target for -DPL_DEPRECATED=OFF
    
    * Built the "test_noninteractive" target for -DPL_DEPRECATED=OFF
    
    * Built the "test_interactive" target for -DPL_DEPRECATED=OFF
    
    In all cases there were no configure-, build-, or run-time errors and
    no warning regressions.  For the "test_noninteractive" case, there
    were no PostScript difference regressions.

M	README.release
M	bindings/c++/plstream.cc
M	bindings/c++/plstream.h

commit 6ce0494ec5542cb4f8fd89e22c7ce9ead8332d2a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Sep 20 21:53:14 2017 -0700

    Remove trailing whitespace from recent commit

M	doc/docbook/src/api-c.xml

commit 079cbf1f283cf82fc62eaf936423d65614fe584a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Sep 20 11:08:52 2017 -0700

    C and C++ API: Implement plStatic2dGrid and deprecate plshade1
    
    The 2D matrix arguments of plshade, plshades, plcont, plimage, plvect,
    etc., for our C API and corresponding C++ API must currently be
    organized as Iliffe column vectors (see
    <https://en.wikipedia.org/wiki/Iliffe_vector>) containing pointers to
    PLFLT row vectors.  And these matrices are normally in the C case
    dynamically allocated with plAlloc2dGrid and freed with plFree2dGrid,
    and in the C++ case the same thing is done with C++ wrappers for
    plAlloc2dGrid and plFree2dGrid.  However, that dynamically allocated
    approach has not allowed our C and C++ users to call plshade, etc.,
    with statically allocated 2D data.
    
    Historically we have partially addressed that issue by implementing a
    plshade1 variant of plshade that could be called with a statically
    allocated 2D matrix.  Expanding that approach with plshades1, plcont1,
    etc., variants is possible, but does considerably clutter our C and
    C++ API.  So instead for this release we have implemented the
    plStatic2dGrid C function and associated C++ wrapper which allows C
    and C++ users to determine the Iliffe column vector corresponding to a
    2D statically allocated array. The standard C and C++ examples
    (specifically examples/c/x15c.c and examples/c++/x15.cc) demonstrate
    how to use this new approach to call plshade using 2D data that have
    been statically allocated, and although none of our examples
    illustrate these additional possibilities, this same approach could
    also be used to call plshades, etc., with 2D data that have been
    statically allocated.
    
    I have added DocBook documentation of plStatic2dGrid and also
    significantly updated our DocBook documentation of the 2D matrix
    API for C consistent with this new C (and C++) functionality.
    
    Since this new approach completely supersedes plshade1, we have
    officially deprecated that function and its C++ wrapper.  (Note this
    is a backwards-incompatible change to our C and C++ API's.  Such
    official deprecation means that plshade1 and its C++ wrapper are only
    available to users if they specify the -DPL_DEPRECATED=ON cmake
    option. And our DocBook documentation for plshade1 has been moved to
    the obsolete/deprecated section of that documention.  This deprecation
    means that all other references to plshade1 (except for historical
    data such as change logs and release notes) to plshade1 have been
    eliminated from our source tree with this commit.  In particular,
    plshade1 had (in error) been previously propagated to the Ada
    traditional binding as plshade1 and Ada standard binding as
    Shade_Region_1, and used in the Ada standard and traditional examples
    so plshade1 and Shade_Region_1 have been dropped from the Ada bindings
    (note, this is a backwards-incompatible change for those bindings) and
    replaced in the Ada examples with the corresponding calls to plshade
    and Shade_Region.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie).  These tests consisted of the following steps:
    
    * I checked that the goal of elimination of references in our source
      tree to shade1 had been achieved (except for the C and C++
      deprecated API, the obsolete/deprecated DocBook documentation, and
      historical data) using
    
    find . -type f |grep -v .git |xargs grep shade1 |less
    
      and
    
    find . -type f |grep -v .git |xargs grep Shade_Region_1 |less
    
    * Using the cmake option -DBUILD_DOC=ON, I built the "html" target and
      checked that build of the html form of our documentation worked
      without validation issues and produced good results for the
      documentation of plStatic2dGrid, our general 2D matrix documentation
      for our C API, and the deprecated plshade1 documentation.
    
    * For both the -DPL_DEPRECATED=OFF and ON cases, I built the
      test_diff_psc target without configure, build, or run-time issues,
      and without any regressions in PostScript difference results.
    
    * I ran
    
    valgrind examples/c/x15c -dev psc -o test.psc
    
      and
    
    valgrind examples/c++/x15 -dev psc -o test.psc
    
      The resulting valgrind reports were perfect (i.e.,
      "All heap blocks were freed -- no leaks are possible"
    
      and
    
      "ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)"
    
      ) which demonstrates that the new plStatic2dGrid C functionality and
      its C++ wrapper that are used in these examples introduce no memory
      management issues.

M	README.Release_Manager_Cookbook
M	bindings/ada/plplot_standard.adb
M	bindings/ada/plplot_standard.ads
M	bindings/ada/plplot_thin.ads
M	bindings/ada/plplot_traditional.adb
M	bindings/ada/plplot_traditional.ads
M	bindings/c++/plstream.cc
M	bindings/c++/plstream.h
M	bindings/ocaml/plplot_impl.c
M	bindings/python/plplotc.i
M	bindings/swig-support/plplotcapi.i
M	doc/docbook/src/api-c.xml
M	doc/docbook/src/api-obsolete.xml
M	doc/docbook/src/api.xml
M	doc/docbook/src/c.xml
M	doc/docbook/src/plplotdoc.xml.in
M	examples/ada/xstandard15a.adb
M	examples/ada/xtraditional15a.adb
M	examples/c++/x15.cc
M	examples/c/x15c.c
M	include/plplot.h
M	src/plmem.c
M	src/plshade.c

commit 22a3bad9d3aaf6921e8099b7ee87460e4b038c24
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Sep 20 11:05:07 2017 -0700

    Update release notes for next release
    
    Describe new pyqt[45] configuration scheme and soon-to-be committed
    implementation of plStatic2dGrid and corresponding deprecation of plshade1.

M	README.release

commit 5f7e54119679d79c111bf37128ef441b56914d2e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Sep 18 19:17:39 2017 -0700

    Simplify plapi.tpl by dropping all commented-out parts of the file
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_diff_psc target in the build tree
    for the shared library case with no PostScript difference regressions.

M	bindings/tcl/plapi.tpl

commit 5d2c57322f9bb78ef5d055e9439cf2efa012da64
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Sep 18 15:20:32 2017 -0700

    Simplify plplot_h by dropping all commented-out parts of the file
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by configuring PLplot with the
    DADD_SPECIAL_CONSISTENCY_CHECKING=ON option and building the
    check_plplot_h.inc target which checks that
    bindings/ocaml/plplot_h.inc is consistent with what should be same
    file generated with bindings/ocaml/touchup.ml from
    bindings/ocaml/bindings/ocaml/plplot_h where all three mentioned files
    are in the source tree.

M	bindings/ocaml/plplot_h

commit 7c53539e300ac99c0db436c228fccf6b4d63338d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Sep 12 16:53:19 2017 -0700

    Fix bug in check_api_completeness.sh
    
    This script previously failed because it referred to
    files associated with the old fortran binding that has now been
    removed, and the fix was to gather similar Fortran API information
    from the new fortran binding.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running
    
    scripts/check_api_completeness.sh all |less
    
    in the source tree.  The script now finishes without errors although
    it currently reveals some possible API inconsistencies which might be
    real or which might be artifacts of how the various API results have
    been parsed.  So those possible API inconsistencies need to be
    investigated further.

M	scripts/check_api_completeness.sh

commit 696e56be6bb027d602de30120b6a12aa90d06c6f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Sep 12 16:49:33 2017 -0700

    Remove all officially deprecated functions
    
    I removed plParseInternalOpts, plSetInternalOpt, plclr, plpage, plcol,
    plcontf, plP_gvpd, plP_gvpw, plotsh3d, plSetOpt, plrgb, plrgb1, plhls,
    and plwid.  These functions were officially deprecated (i.e., only
    accessible if the user specifed the -DPL_DEPRECATED=ON cmake option)
    as of the PLplot-5.9.10 release (and in some cases even before that
    release) so it is long past the time to remove them.  I also edited
    the source tree files to remove all mentions of these functions (as well
    as plParseOpts, plHLS_RGB, plRGB_HLS, and plarrows that had
    been previously removed).  As a result
    
    find . -type f |grep -v .git |xargs grep -E 'plParseInternalOpts|plSetInternalOpt|plclr|plpage|plcol|plcontf|plP_gvpd|plP_gvpw|plotsh3d|plSetOpt|plrgb|plrgb1|plhls|plwid' |grep -vE 'plcol0|plcol1|plcolorbar' |less
    
    and
    
    find . -type f |grep -v .git |xargs grep -E 'plParseOpts|plHLS_RGB|plRGB_HLS|plarrows' |less
    
    now only find non-relevant hits or else hits for historical references
    (e.g., change logs and release notes) to these functions.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) for the build-tree shared-library case by configuring
    the PLplot build using the -DADD_SPECIAL_CONSISTENCY_CHECKING=ON cmake
    option, and building the validate and check_all targets with no
    issues.  I built the check_api_xml_consistency target which generated
    the same c_plshade1 and plGetCursor inconsistencies as previously
    (i.e., this target revealed no regressions from previous results due
    to the present changes).  Finally, I built the test_interactive and
    test_noninteractive targets and checked those results as follows:
    
    # Check for any regressions in the warnings in the cmake output.
    less cmake.out
    
    # Check for some non-standard warnings:
    grep -i warning *.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout'
    
    # Check for all errors:
    grep -i error *.out
    
    # Check for any PostScript or Text differences between all non-C languages and the corresponding
    # C results.
    grep -B1 -A3 "Missing examples" test_noninteractive.out |less
    
    These checks showed no issues other than long-standing PostScript
    differences for ocaml (i.e., there were no PostScript difference
    regressions).

M	FAQ
M	README.release
M	bindings/ada/plplot_standard.adb
M	bindings/ada/plplot_standard.ads
M	bindings/ada/plplot_thin.ads
M	bindings/ada/plplot_traditional.adb
M	bindings/ada/plplot_traditional.ads
M	bindings/c++/plstream.cc
M	bindings/c++/plstream.h
M	bindings/d/plplot.d
M	bindings/java/PLStream.java
M	bindings/lua/plplotluac.i
M	bindings/ocaml/plplot_h
M	bindings/octave/PLplot/arrows.m
M	bindings/octave/PLplot/figure.m
M	bindings/octave/PLplot/shade.m
M	bindings/octave/PLplot/support/__pl_contour.m
M	bindings/octave/PLplot/support/__pl_plotit.m
M	bindings/python/Plframe.py
M	bindings/swig-support/CMakeLists.txt
M	bindings/swig-support/plplotcapi.i
M	bindings/tcl/plapi.tpl
M	doc/docbook/src/api-obsolete.xml
M	include/plplot.h
M	scripts/check_api_completeness.sh
M	src/plargs.c
M	src/plcont.c
M	src/pldeprecated.c
M	src/plmem.c

commit ddd516cc9d8ab817da1625cad318dc65a7d33f0a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Sep 12 13:52:40 2017 -0700

    Remove the rest of the sys subdirectory tree
    
    The "sys" subdirectory tree was originally used in the pre-CMake days
    to implement various build systems for various platforms.  Most of
    this subdirectory tree was removed in commit 69abf21 (2009-09-23)
    followed by the removal of sys/dos/djgpp in commit aaf7332
    (2010-01-25).  This left just sys/win-tk.  However, that directory has
    not been developed for a decade or more, and my scan through the files
    there showed there was nothing left of value there so I have removed
    this last of the "sys" subdirectories in this commit.

M	CMakeLists.txt
D	sys/win-tk/Readme.txt
D	sys/win-tk/makePlplotStarkit.tcl
D	sys/win-tk/makefile.vc
D	sys/win-tk/pkgIndex.tcl
D	sys/win-tk/plConfig.h
D	sys/win-tk/plDevs.h
D	sys/win-tk/tclIndex
D	sys/win-tk/tclgen.c
D	sys/win-tk/tclgen.h
D	sys/win-tk/tclgen_s.h
D	sys/win-tk/testPlplot.tcl

commit 90723a2fa7e02899501497f461e29ba836db330d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Sep 12 12:14:47 2017 -0700

    Remove unused global-in-scripts file in octave binding

D	bindings/octave/globals-in-scripts

commit 8d13579ae3042b26b8746563b8b7752181737639
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Sep 7 15:35:53 2017 -0700

    Perl/PDL examples removal
    
    By historical accident and for just a limited time we actively
    developed a set of standard examples written in Perl/PDL to help test
    Doug Hunt's external PDL::Graphics::PLplot project.  But we have now
    removed those examples from our project since we have long since
    stopped testing PDL::Graphics::PLplot with those examples, and, in any
    case, such examples should be part of PDL::Graphics::PLplot rather
    than PLplot.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_noninteractive, validate, and
    install targets in the build tree for the shared library case.  There
    were no obvious configuration or run-time issues, and no PostScript
    difference regressions.

M	ABOUT
M	README.release
M	README.testing
M	bindings/swig-support/swig_documentation.i
M	bindings/tk/about.tcl
D	cmake/modules/pdl.cmake
M	cmake/modules/plplot.cmake
M	cmake/modules/summary.cmake
M	doc/docbook/src/CMakeLists.txt
M	doc/docbook/src/api.xml
D	doc/docbook/src/perl.xml
M	doc/docbook/src/plplotdoc.xml.in
M	doc/docbook/src/schemas.xml
M	examples/CMakeLists.txt
M	examples/Makefile.examples.in
D	examples/perl/CMakeLists.txt
D	examples/perl/README.perldemos
D	examples/perl/check-sync.pl
D	examples/perl/x01.pl
D	examples/perl/x02.pl
D	examples/perl/x03.pl
D	examples/perl/x04.pl
D	examples/perl/x05.pl
D	examples/perl/x06.pl
D	examples/perl/x07.pl
D	examples/perl/x08.pl
D	examples/perl/x09.pl
D	examples/perl/x10.pl
D	examples/perl/x11.pl
D	examples/perl/x12.pl
D	examples/perl/x13.pl
D	examples/perl/x14.pl
D	examples/perl/x15.pl
D	examples/perl/x16.pl
D	examples/perl/x17.pl
D	examples/perl/x18.pl
D	examples/perl/x19.pl
D	examples/perl/x20.pl
D	examples/perl/x21.pl
D	examples/perl/x22.pl
D	examples/perl/x23.pl
D	examples/perl/x24.pl
D	examples/perl/x25.pl
D	examples/perl/x26.pl
D	examples/perl/x27.pl
D	examples/perl/x28.pl
D	examples/perl/x29.pl
D	examples/perl/x30.pl
D	examples/perl/x31.pl
D	examples/perl/x33.pl
M	examples/plplot_configure.cmake_installed_examples.in
M	plplot_test/CMakeLists.txt
M	plplot_test/plplot-test.sh.in
M	plplot_test/test_diff.sh.in
D	plplot_test/test_pdl.sh.in

commit ce9f7bb6e9d605cb4302c409ae06e9e46f879abe
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Sep 6 11:29:09 2017 -0700

    Remove trailing whitespace from a previous commit

M	cmake/modules/qt.cmake

commit 51415db8b5d88657215a02b54694d5102c36e4e2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Sep 6 11:21:49 2017 -0700

    Build system: remove remaining references to *.map files in our source tree
    
    These *.map files were all removed in a prior commit so
    they no longer have to be specifically identified as binary data
    (.gitattributes) or excluded from consideration
    (scripts/parity_bit_check.exclude AND
    scripts/remove_trailing_whitespace.sh).
    
    All other references to '\.map' in our source tree that were found
    using
    
    find . -type f |grep -v .git |xargs grep '\.map' |less
    
    turned out not to be references to *.map files.

M	.gitattributes
M	scripts/parity_bit_check.exclude
M	scripts/remove_trailing_whitespace.sh

commit 2ac4b7b530ed023b037c390b6dff1a57a30d2981
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Sep 6 10:56:18 2017 -0700

    plmap cruft removal
    
    As of PLplot-5.9.10, a new version of plmap was implemented that used
    shapefile format (accessed via shapelib) for maps.  In addition other
    powerful map API (see the last page of standard example 19) that
    depended on shapelib map data was implemented as well.  However, we
    still made the old plmap implemention that depended on the
    (undocumented) binary format of our *.map files available when the
    user specified -DPL_DEPRECATED=ON, and this arrangement continued
    through PLplot-5.13.0.  However, it appears our users are generally
    satisfied with the new shapefile-based plmap functionality and we no
    longer want to maintain or test that old plmap functionality based on
    the *.map format.  So for this commit that old plmap functionality
    and associated *.map files have been completely removed from our
    source tree.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_diff_psc and install targets
    in the build tree for the shared library case.
    
    I did the above test twice (once as per normal and once with a
    temporary local variation of cmake/modules/FindShapelib.cmake that
    disabled finding of shapelib).  In both cases there were no obvious
    configuration or run-time issues, and the PostScript difference
    results had no regressions.  And (as expected) when shapelib finding was
    disabled, example 19 generated plot results with no map information
    other than meridians (from the calls in that example to plmeridians)
    and labels, and the core plplot library (as expected) emitted "PLPLOT
    WARNING" messages with the following messages:
    
    plmap is a no-op because shapelib is not available.
    plmapfill is a no-op because shapelib is not available.
    plmapline is a no-op because shapelib is not available.
    plmaptex is a no-op because shapelib is not available.

M	README.release
M	data/CMakeLists.txt
D	data/cglobe.map
D	data/globe.map
D	data/usa.map
D	data/usaglobe.map
M	src/CMakeLists.txt
D	src/deprecated_plmap.c

commit e3e0f15134128e76ec37e99285eae13a56b3dff0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Sep 6 01:36:50 2017 -0700

    Build system: Update NAMES used to find PYQT_SIP_DIR
    
    This update is based on the following results from Arjen's run of the
    "pkgfile -v QtCoremod.sip" command on his MinGW-w64/MSYS2 platform:
    mingw32/mingw-w64-i686-python2-pyqt4 4.11.4-2 /mingw32/share/sip/Py2-Qt4/QtCore/QtCoremod.sip
    mingw32/mingw-w64-i686-python2-pyqt5 5.8-1 /mingw32/share/sip/Py2-Qt5/QtCore/QtCoremod.sip
    mingw32/mingw-w64-i686-python3-pyqt4 4.11.4-2 /mingw32/share/sip/PyQt4/QtCore/QtCoremod.sip
    mingw32/mingw-w64-i686-python3-pyqt5 5.8-1 /mingw32/share/sip/PyQt5/QtCore/QtCoremod.sip
    mingw64/mingw-w64-x86_64-python2-pyqt4 4.11.4-2 /mingw64/share/sip/Py2-Qt4/QtCore/QtCoremod.sip
    mingw64/mingw-w64-x86_64-python2-pyqt5 5.8-1 /mingw64/share/sip/Py2-Qt5/QtCore/QtCoremod.sip
    mingw64/mingw-w64-x86_64-python3-pyqt4 4.11.4-2 /mingw64/share/sip/PyQt4/QtCore/QtCoremod.sip
    mingw64/mingw-w64-x86_64-python3-pyqt5 5.8-1 /mingw64/share/sip/PyQt5/QtCore/QtCoremod.sip
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by using all 4 combinations of
    -DFORCE_PYTHON2=OFF (or ON) -DPLPLOT_USE_QT5=OFF (or ON) and
    verifying the correct PYQT_SIP_DIR was found in each case.

M	cmake/modules/qt.cmake

commit b96ced11d61185d7621abc4412332e51093e23f8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Sep 4 11:22:18 2017 -0700

    Tcl/Tk cruft removal
    
    As of PLplot-5.12.0, a new Tcl binding was implemented that used the
    "redacted" PLplot API where all dimension arguments for arrays are
    dropped from argument lists since those data are redundant (already
    supplied by the arrays themselves).  As a result of this change, Tcl
    calls to the PLplot API in the old binding such as
    
    $w cmd plline $nsize x y
    
    now have to be replaced in the new binding by
    
    $w cmd plline x y
    
    and similarly for all other Tcl calls to the PLplot API that involve
    array (tclmatrix) arguments.  The advantages of this new binding are
    it is cleaner, it is safer (i.e., automatically self-consistent with
    regard to array dimensions), and it makes our Tcl binding compatible
    with the rest of our bindings.  (The only exception to this is our C++
    binding which currently still uses simple C-style arrays and therefore
    must use the non-redacted form of the PLplot API, but that may also
    change in the future.)  However, the disadvantage of this change is
    our new binding is obviously backwards-incompatible with the old
    binding.  Therefore, for PLplot-5.12.0 we implemented the CMake option
    -DUSE_NON_REDACTED_TCL_TK=ON to provide temporary deprecated access to
    the old Tcl binding, and that form of backwards compatibility
    continued to be provided for the PLplot-5.13.0 release.  However, it
    appears our users are generally satisfied with the new binding, and we
    no longer want to maintain or test that old binding.  So for this
    commit the old Tcl binding (and old versions of the Tcl standard
    examples and Tk source code that depended on it) have been completely
    removed from our source tree.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building (for the shared library case) the
    test_noninteractive and test_interactive targets in the build tree as
    follows:
    
    cmake .... <defaults for everything>  >& cmake.out
    make -j4 test_noninteractive >& test_noninteractive.out
    make -j4 test_interactive >& test_interactive.out
    
    These results were checked as follows:
    
    # Check for any regressions in the warnings in the cmake output.
    less cmake.out
    
    # N.B. the --binary-files=text option below is required because some binary data
    # (a group of NULL characters) got into test_noninteractive.out. (This is a long-standing
    # bug which I plan to investigate later.)
    
    # Check for some non-standard warnings:
    grep --binary-files=text -i warning *.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout'
    
    # Check for all errors:
    grep --binary-files=text -i error *.out
    
    # Check for any PostScript or Text differences between all non-C languages and the corresponding
    # C results.
    grep --binary-files=text -B1 -A3 "Missing examples" test_noninteractive.out |less
    
    These checks showed no issues other than long-standing PostScript
    differences for ocaml (i.e., there were no PostScript difference
    regressions).

M	README.release
M	bindings/CMakeLists.txt
D	bindings/non_redacted_tcl/CMakeLists.txt
D	bindings/non_redacted_tcl/README.tclAPI
D	bindings/non_redacted_tcl/global_defines.sed
D	bindings/non_redacted_tcl/matrixInit.c
D	bindings/non_redacted_tcl/pkgIndex.tcl.in
D	bindings/non_redacted_tcl/plapi.tpl
D	bindings/non_redacted_tcl/plitclgen
D	bindings/non_redacted_tcl/plitclgen.tcl
D	bindings/non_redacted_tcl/plplot_parameters.h
D	bindings/non_redacted_tcl/pltcl.c
D	bindings/non_redacted_tcl/pltcl.h
D	bindings/non_redacted_tcl/pltclgen
D	bindings/non_redacted_tcl/pltclgen.tcl
D	bindings/non_redacted_tcl/tclAPI.c
D	bindings/non_redacted_tcl/tclMain.c
D	bindings/non_redacted_tcl/tclMatrix.c
D	bindings/non_redacted_tcl/tclMatrix.h
D	bindings/non_redacted_tcl/tclcmd.tpl
D	bindings/non_redacted_tk-x-plat/CMakeLists.txt
D	bindings/non_redacted_tk-x-plat/Memberscope.tcl
D	bindings/non_redacted_tk-x-plat/Plplotter_Init.c
D	bindings/non_redacted_tk-x-plat/Plplotwin.tcl
D	bindings/non_redacted_tk-x-plat/Plwindow.tcl
D	bindings/non_redacted_tk-x-plat/pkgIndex.tcl.in
D	bindings/non_redacted_tk-x-plat/plbarchart.tcl
D	bindings/non_redacted_tk-x-plat/plplotter.c
D	bindings/non_redacted_tk-x-plat/pltimeseries.tcl
D	bindings/non_redacted_tk-x-plat/pltkwd.h
D	bindings/non_redacted_tk-x-plat/plwidget2.tcl
D	bindings/non_redacted_tk-x-plat/tclIndex
D	bindings/non_redacted_tk/CMakeLists.txt
D	bindings/non_redacted_tk/FileSelector.tcl
D	bindings/non_redacted_tk/PLWin.itk
D	bindings/non_redacted_tk/PLXWin.itk
D	bindings/non_redacted_tk/Pltk_Init.c
D	bindings/non_redacted_tk/Pltkwin.tcl
D	bindings/non_redacted_tk/about.tcl
D	bindings/non_redacted_tk/app-defaults/PLplot.large.ad
D	bindings/non_redacted_tk/app-defaults/PLplot.medium.ad
D	bindings/non_redacted_tk/app-defaults/PLplot.small.ad
D	bindings/non_redacted_tk/app-defaults/README
D	bindings/non_redacted_tk/cmap0a.pal
D	bindings/non_redacted_tk/cmap1a.pal
D	bindings/non_redacted_tk/cmap1a1.pal
D	bindings/non_redacted_tk/cmap1b.pal
D	bindings/non_redacted_tk/cmap1c.pal
D	bindings/non_redacted_tk/cmap1d.pal
D	bindings/non_redacted_tk/help_gui.tcl
D	bindings/non_redacted_tk/help_keys.tcl
D	bindings/non_redacted_tk/help_tcltk.tcl
D	bindings/non_redacted_tk/pkgIndex.tcl.in
D	bindings/non_redacted_tk/plclient.tcl
D	bindings/non_redacted_tk/plcolor.tcl
D	bindings/non_redacted_tk/plconfig.tcl
D	bindings/non_redacted_tk/pldefaults.tcl
D	bindings/non_redacted_tk/plframe.c
D	bindings/non_redacted_tk/plplot.tcl
D	bindings/non_redacted_tk/plr.c
D	bindings/non_redacted_tk/plserver.c
D	bindings/non_redacted_tk/plserver.h
D	bindings/non_redacted_tk/plserver.tcl
D	bindings/non_redacted_tk/pltk.h
D	bindings/non_redacted_tk/pltkd.h
D	bindings/non_redacted_tk/pltools.tcl
D	bindings/non_redacted_tk/plwidget.tcl
D	bindings/non_redacted_tk/stupidtk.c
D	bindings/non_redacted_tk/tcpip.c
D	bindings/non_redacted_tk/tcpip.h
D	bindings/non_redacted_tk/tkMain.c
D	bindings/non_redacted_tk/tkshell.c
M	cmake/modules/tcl-related.cmake
M	cmake/modules/tk.cmake
M	doc/Doxyfile.in
M	examples/CMakeLists.txt
D	examples/non_redacted_tcl/CMakeLists.txt
D	examples/non_redacted_tcl/README.tcldemos
D	examples/non_redacted_tcl/plgrid.tcl
D	examples/non_redacted_tcl/plot.dat
D	examples/non_redacted_tcl/plot.tcl
D	examples/non_redacted_tcl/pltcl_standard_examples.in
D	examples/non_redacted_tcl/r.dat
D	examples/non_redacted_tcl/stats.log
D	examples/non_redacted_tcl/tcldemos.tcl
D	examples/non_redacted_tcl/tclsh_standard_examples.in
D	examples/non_redacted_tcl/x00
D	examples/non_redacted_tcl/x00.tcl
D	examples/non_redacted_tcl/x01
D	examples/non_redacted_tcl/x01.tcl
D	examples/non_redacted_tcl/x02
D	examples/non_redacted_tcl/x02.tcl
D	examples/non_redacted_tcl/x03
D	examples/non_redacted_tcl/x03.tcl
D	examples/non_redacted_tcl/x04
D	examples/non_redacted_tcl/x04.tcl
D	examples/non_redacted_tcl/x05
D	examples/non_redacted_tcl/x05.tcl
D	examples/non_redacted_tcl/x06
D	examples/non_redacted_tcl/x06.tcl
D	examples/non_redacted_tcl/x07
D	examples/non_redacted_tcl/x07.tcl
D	examples/non_redacted_tcl/x08
D	examples/non_redacted_tcl/x08.tcl
D	examples/non_redacted_tcl/x09
D	examples/non_redacted_tcl/x09.tcl
D	examples/non_redacted_tcl/x10
D	examples/non_redacted_tcl/x10.tcl
D	examples/non_redacted_tcl/x11
D	examples/non_redacted_tcl/x11.tcl
D	examples/non_redacted_tcl/x12
D	examples/non_redacted_tcl/x12.tcl
D	examples/non_redacted_tcl/x13
D	examples/non_redacted_tcl/x13.tcl
D	examples/non_redacted_tcl/x14
D	examples/non_redacted_tcl/x14.tcl
D	examples/non_redacted_tcl/x15
D	examples/non_redacted_tcl/x15.tcl
D	examples/non_redacted_tcl/x16
D	examples/non_redacted_tcl/x16.tcl
D	examples/non_redacted_tcl/x17
D	examples/non_redacted_tcl/x17.tcl
D	examples/non_redacted_tcl/x18
D	examples/non_redacted_tcl/x18.tcl
D	examples/non_redacted_tcl/x19
D	examples/non_redacted_tcl/x19.tcl
D	examples/non_redacted_tcl/x20
D	examples/non_redacted_tcl/x20.tcl
D	examples/non_redacted_tcl/x21
D	examples/non_redacted_tcl/x21.tcl
D	examples/non_redacted_tcl/x22
D	examples/non_redacted_tcl/x22.tcl
D	examples/non_redacted_tcl/x23
D	examples/non_redacted_tcl/x23.tcl
D	examples/non_redacted_tcl/x24
D	examples/non_redacted_tcl/x24.tcl
D	examples/non_redacted_tcl/x25
D	examples/non_redacted_tcl/x25.tcl
D	examples/non_redacted_tcl/x26
D	examples/non_redacted_tcl/x26.tcl
D	examples/non_redacted_tcl/x27
D	examples/non_redacted_tcl/x27.tcl
D	examples/non_redacted_tcl/x28
D	examples/non_redacted_tcl/x28.tcl
D	examples/non_redacted_tcl/x29
D	examples/non_redacted_tcl/x29.tcl
D	examples/non_redacted_tcl/x30
D	examples/non_redacted_tcl/x30.tcl
D	examples/non_redacted_tcl/x31
D	examples/non_redacted_tcl/x31.tcl
D	examples/non_redacted_tcl/x33
D	examples/non_redacted_tcl/x33.tcl
D	examples/non_redacted_tk/CMakeLists.txt
D	examples/non_redacted_tk/Makefile.examples.in
D	examples/non_redacted_tk/README.tkdemos
D	examples/non_redacted_tk/plgrid.in
D	examples/non_redacted_tk/plserver_runAllDemos.in
D	examples/non_redacted_tk/plserver_standard_examples.in
D	examples/non_redacted_tk/runAllDemos.tcl
D	examples/non_redacted_tk/runExtendedDemos.tcl
D	examples/non_redacted_tk/tk01.in
D	examples/non_redacted_tk/tk02.in
D	examples/non_redacted_tk/tk03.in
D	examples/non_redacted_tk/tk04.in
D	examples/non_redacted_tk/tkdemos.tcl
D	examples/non_redacted_tk/wish_runAllDemos.in
D	examples/non_redacted_tk/wish_standard_examples.in
D	examples/non_redacted_tk/xtk01.c
D	examples/non_redacted_tk/xtk02.c
D	examples/non_redacted_tk/xtk04.c
M	plplot_test/CMakeLists.txt
M	plplot_test/plplot-test-interactive.sh.in
M	plplot_test/plplot-test.sh.in
M	src/CMakeLists.txt

commit bc7df37f6881260bef4f4391862d343181a5d066
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Sep 3 15:16:09 2017 -0700

    Fortran cruft removal
    
    As of PLplot-5.12.0, a new Fortran binding was implemented using the
    powerful capabilities of the Fortran 2003 iso_c_binding module which
    was the replacement for the old binding that was implemented using a
    combination of Fortran and C code.  The new binding is much simpler,
    more consistent, and more standards-compliant than the old binding and
    has some powerful new features (e.g., both single and double
    precisions Fortran floating-point arguments are accepted).  Therefore,
    the new binding is necessarily backwards incompatible with the old
    binding.  For PLplot-5.12.0 we implemented the CMake option
    -DPL_DEPRECATED_fortran=ON to provide temporary deprecated access to
    the old Fortran binding, and that form of backwards compatibility
    continued to be provided for the PLplot-5.13.0 release.  However, it
    appears our users are generally satisfied with the new binding, and we
    no longer want to maintain or test that old binding.  So for this
    commit the old binding has been completely removed from our source
    tree.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_diff_psc target.

M	README.release
M	bindings/CMakeLists.txt
D	bindings/old_fortran/CMakeLists.txt
D	bindings/old_fortran/global_defines.sed
D	bindings/old_fortran/plparseopts.f90
D	bindings/old_fortran/plplot_parameters.inc
D	bindings/old_fortran/plplot_types.f90.in
D	bindings/old_fortran/plplotfortran.def
D	bindings/old_fortran/plplotfortran_ifort.def
D	bindings/old_fortran/plplotfortran_mingw.def
D	bindings/old_fortran/plstubs.h
D	bindings/old_fortran/readme_f95.txt
D	bindings/old_fortran/sc3d.c
D	bindings/old_fortran/sccont.c
D	bindings/old_fortran/scstubs.c
D	bindings/old_fortran/sfstubs.inc
D	bindings/old_fortran/sfstubsfortran.f90
D	bindings/old_fortran/strutil.f90
M	cmake/modules/fortran.cmake
M	cmake/modules/plplot_version.cmake
M	doc/Doxyfile.in
M	examples/CMakeLists.txt
D	examples/old_fortran/CMakeLists.txt
D	examples/old_fortran/Makefile.examples.in
D	examples/old_fortran/plfortrandemolib.f90
D	examples/old_fortran/plfortrandemos.inc.in
D	examples/old_fortran/test_plfortrandemolib.f90
D	examples/old_fortran/x00f.f90
D	examples/old_fortran/x01f.f90
D	examples/old_fortran/x02f.f90
D	examples/old_fortran/x03f.f90
D	examples/old_fortran/x04f.f90
D	examples/old_fortran/x05f.f90
D	examples/old_fortran/x06f.f90
D	examples/old_fortran/x07f.f90
D	examples/old_fortran/x08f.f90
D	examples/old_fortran/x09f.f90
D	examples/old_fortran/x10f.f90
D	examples/old_fortran/x11f.f90
D	examples/old_fortran/x12f.f90
D	examples/old_fortran/x13f.f90
D	examples/old_fortran/x14f.f90
D	examples/old_fortran/x15f.f90
D	examples/old_fortran/x16af.f90
D	examples/old_fortran/x16f.f90
D	examples/old_fortran/x17f.f90
D	examples/old_fortran/x18f.f90
D	examples/old_fortran/x19f.f90
D	examples/old_fortran/x20f.f90
D	examples/old_fortran/x21f.f90
D	examples/old_fortran/x22f.f90
D	examples/old_fortran/x23f.f90
D	examples/old_fortran/x24f.f90
D	examples/old_fortran/x25f.f90
D	examples/old_fortran/x26f.f90
D	examples/old_fortran/x27f.f90
D	examples/old_fortran/x28f.f90
D	examples/old_fortran/x29f.f90
D	examples/old_fortran/x30f.f90
D	examples/old_fortran/x31f.f90
D	examples/old_fortran/x33f.f90
M	plplot_test/CMakeLists.txt
M	plplot_test/plplot-test.sh.in
M	scripts/style_source.sh

commit 259a7d4a90d63a39c0f7fd95a37ef9f163e73be6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Sep 2 19:09:57 2017 -0700

    Update script to remove trailing whitespace
    
    Files in the debian directory are no longer ignored (since this
    directory does not exist any more), and all *.pyc files are now
    ignored.
    
    This change was motivated by an attempt to remove trailing whitespace
    from bindings/python/Plframe.pyc.

M	scripts/remove_trailing_whitespace.sh

commit b3ef719f9ee5a763baa4705104a97c95c178afd3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Sep 2 19:00:29 2017 -0700

    Build system: rewrite logic for determining PYQT_SIP_DIR and PYQT_SIP_FLAGS
    
    For pyqt4 the pyqtconfig module useful for determining PYQT_SIP_DIR
    and PYQT_SIP_FLAGS has been deprecated and has therefore already
    completely disappeared from some software platforms (e.g.,
    MinGW-w64/MSYS2).  Therefore, in this commit we have replaced that
    approach with an approach very similar to what we currently use for
    pyqt5 (where the pyqtconfig module has never been available).
    PYQT_SIP_FLAGS is easy to determine without the pyqtconfig module, but
    determination of PYQT_SIP_DIR, the location where the PyQT sip files
    are located is not completely straightforward.  For the Debian-based
    Linux platforms and rpm-based Linux platforms accessible with
    rpm.pbone, Cygwin, and MinGW-w64/MSYS2, we feel we have the correct
    HINTS in place to find this directory.  But for other platforms where
    this might be an issue, the user is invited to install a system
    package with the needed pyqt-related sip files, but if those have
    already been installed, then they are invited to work around the
    problem by specifying the correct PYQT_SIP_DIR to find those files,
    and communicating with us to update our HINTS appropriately for their
    platform.
    
    Since the pyqt[45] logic is now so similar, we have reorganized the
    CMake code to treat those two cases as much as possible with the same
    code.
    
    We have also taken the opportunity to style this CMake code using
    emacs cmake mode.  That styling included replacing all tabbed
    indentation by spaced indentation.  (I have just discovered with that
    emacs mode that you can do such replacement by replacing all tabs with
    large numbers of spaces, then the correct spaced indentation will be
    used if you subsequently style all lines by selecting all lines of the
    file and hitting ctrl-alt-backslash.)
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) using the 4 combinations of the cmake options
    DFORCE_PYTHON2=OFF/ON -DPLPLOT_USE_QT5=OFF/ON.  In all cases, the PyQt
    sip directory (and sip flags) were found without issues, and building
    the appropriate test_pyqt[45]_example target for each case proceeded
    without issues other than pyqt5_example sometimes segfaulted at the
    end (a known, long-standing issue with Qt5).
    
    Additional testing of this new logic is requested on all accessible platforms.

M	cmake/modules/qt.cmake

commit 1b93965d437f3c63517cb0ac712482bcda8bf012
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Aug 27 18:04:41 2017 -0700

    pytkdemo: import and reload improvements
    
    * For both pytkdemo and its Plframe.py dependency, I replaced all
      non-namespaced imports of PLplot modules with the namespaced
      version.  This change removes the double import (one namespaced and
      one not) for Plframe so likely solves the corruption of
      bindings/python/Plframe.pyc by a Python race condition that
      according to a Python developer had been solved for Python3 (which
      my results confirm since I never got corruption in that case), but
      likely not for Python2 (as my on-going corruption results before the
      present release for this Python version also confirm).
    
    * I improved the pytkdemo logic to work around the different ways to
      access the reload function in Python for the three cases
      if version < 3.0.0:, elif version < 3.4.0:, else:
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    Debian Jessie by building the test_pytkdemo target (both with and
    without -DFORCE_PYTHON2=ON) and clicking on all examples as well as
    the "clear", "clone", "reload", and "dismiss" buttons without issues.

M	bindings/python/Plframe.py
M	examples/python/pytkdemo

commit 9cc0e68cd8a629e25cbbdb7629499874cf29e2b6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Aug 27 15:00:21 2017 -0700

    Remove trailing whitespace from ChangeLog.release

M	ChangeLog.release

commit e3202104b66994c7dc7693c06b5ac125e55eaa0a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Aug 27 14:36:11 2017 -0700

    Build system: Improve user control of Python version
    
    The build system now takes the following steps to search for a suitable
    Python version.
    
    * The build system searches for the PLPLOT_PYTHON_EXACT_VERSION version
      of Python where PLPLOT_PYTHON_EXACT_VERSION is specified by the
      user.  If this string is not specified by the user it defaults to
      "", and this exact search therefore always fails in this case.
    
    * If that first exact search is a failure and the option FORCE_PYTHON2
      is not ON, the build system searches for PYTHON 3.
    
    * If neither of the above two searches is a success, then the build
      system searches for Python 2.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by repeated fresh configurations of PLplot with
    -DPLPLOT_PYTHON_EXACT_VERSION=<Version> strings
    or -DFORCE_PYTHON2=ON specified.
    
    <Version> strings such as "", "whatever", and "1.0.0" found nothing
    so Python version 3.4.2 was found according to the above logic.
    
    <Version> strings such as "2.0.0" found unsuitable 2.7.9 so that
    exact match failed.  However, those find values were cached so the
    subsequent logic above found 2.7.9.
    
    <Version> strings such as "3.9.9" found unsuitable 3.4.3 so that
    exact match failed.  However, those find values were cached so the
    subsequent logic above found 3.4.3.
    
    The <Version> string "2.7.9" immediately found suitable 2.7.9.
    
    The <Version> string "3.4.3" immediately found suitable 3.4.3.
    
    -DFORCE_PYTHON2=ON immediately found 2.7.9.
    
    All of these Python version finding results are as expected.

M	README.release
M	cmake/modules/python.cmake

commit cf7faa2c13a0478487ad95c9eac021279a04021a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Aug 27 00:10:41 2017 -0700

    Build system: Improve version check for wxwidgets
    
    I replaced our brute-force version check (which did not deal well with
    the situation where multiple versions of wxwidgets were available)
    with the native version check capability of the find module for
    wxWidgets.  A byproduct of this change is the wxwidgets version that
    is found is automatically printed out.

M	cmake/modules/wxwidgets.cmake

commit 790a0c66f9bbc805dbabeda05bb3d933e7ce57e8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Aug 26 15:46:51 2017 -0700

    Correct the URL (https: protocol rather than http:) for Testing reports

M	README.release

commit dde43575033e646015c2bf083f54c8972593031b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Aug 26 14:59:18 2017 -0700

    Create new (preliminary) version of release notes for the next release

M	README.release

commit d3f8530c912e3c03fea786aed978448e4e8356b0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Aug 26 14:49:03 2017 -0700

    Tweak README.Release_Manager_Cookbook
    
    These tweaks concern improved instructions/fixes that occurred in
    the last stages of the 5.13.0 release.

M	README.Release_Manager_Cookbook