commit aa8e3ddcaf2b554058ee279a3cd6abc05df64f54
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Aug 25 19:29:44 2017 -0700

    Prepend 5.13.0 release notes to accumlated release notes

M	README.cumulated_release

commit 9971c887e9a652b8c33d0c8f1f1295356fef2a00
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Aug 25 17:52:43 2017 -0700

    Update notes for the release manager
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie).
    
    Do the following comprehensive test (and check of that test) twice,
    once for CMake version 3.6.1 (done on 2017-08-15) and once for CMake
    version 3.9.1 (done on 2017-08-25) to check our build system works
    fine for this range of CMake versions consistent with the remarks in
    README.release.  (Note is is assumed here that the cmake version was
    determined by manipulating the PATH, but you can also specify the
    cmake version explicitly by using the "--cmake_command" option for the
    comprehensive test script.)
    
    Run (from a source tree with a space in the prefix)
    
    scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --do_submit_dashboard yes)
    
    (Note because of the choice of a "spaced" source tree and --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 issues other than long-standing PostScript
    differences for ocaml (and therefore no PostScript difference
    regressions) in the ctest results.  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	README.Release_Manager_Cookbook

commit a9eb1e5c34a73f37cfbe4a8043b929ea53d9b1e2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Aug 25 17:04:28 2017 -0700

    DocBook documentation: Update test directions for a documentation build

M	doc/docbook/README.developers

commit ef033fa7b37fd0e9231a58d2fdc404389295aa9b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Aug 25 17:03:36 2017 -0700

    Final update of version numbers (and release date) in preparation for PLplot-5.13.0

M	cmake/modules/plplot_version.cmake
M	doc/docbook/src/CMakeLists.txt
M	www/examples.php

commit b7ab0f1c180b7d0ce0a7974fac88956d9ebfb40e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Aug 20 13:32:46 2017 -0700

    Final update of release notes in preparation for PLplot-5.13.0

M	README.release

commit ac3473f2e30b1d0b67f7b478694a59af7ce461c7
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Aug 16 14:16:43 2017 -0700

    ctest: Change default timeout from 1500 to 15000 seconds
    
    This change should accommodate our users who happen to have
    extraordinarily slow computers (such as the Raspberry Pi) or our users
    with anomalous platform issues where a few tests are extraordinarily
    slow (such as test_c_epsqt and test_c_pdfqt for the static library
    build on MinGW-w64/MSYS2 [as of 2017-08]).

M	CMakeLists.txt

commit ac753c6639e941ae00e8234ef90cb7aef9409215
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Aug 14 23:37:40 2017 -0700

    wxwidgets device driver: superscript/subscript logic improvement
    
    The logic improvements were as follows:
    
    * yScale, the value of the Y scaling parameter used in DrawTextSection
      is now returned as an argument of that routine since identical Y
      scaling (instead of the empirical factor of 60 that was used before) has
      to be done to calculate scaledOffset in DrawTextLine (the only
      routine that calls DrawTextSection).
    
    * When calculating textHeight and textDepth inside DrawTextLine, use
      properly Y-scaled and initialized scaledOffset value rather than uninitialized (on first
      loop) Offset value that is not Y-scaled.
    
    * The empirical Y offset is now implemented inside DrawTextSection so
      that it can be expressed in Y-scaled coordinates.  The value (which
      is quite small, i.e., 50 times smaller than a character height) is
    
    empiricalYOffset = -0.020 * scaledFontSize * m_yScale;
    
      was recalibrated so that the utf8 "heavy multiplication x", "number
      sign", "four teardrop-spoked asterisk", and "8-spoked asterisk" (all
      of which appear to be centred symbols for my particular system
      fonts) have correct vertical alignment when running
    
    python3 examples/python/test_circle.py -dev wxwidgets
    
    * The empirical factor of 1.2 which is used to enforce symmetry in
      vertical alignment between superscript and corresponding subscript
      levels is now expressed as the "empiricalSymmetricFactor"
      variable.
    
    I also took this opportunity to update examples/python/test_superscript_subscript.py
    to make that example a much more exacting test of superscript/subscript/linebreak logic.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the x01c, wxwidgets, and wxPLViewer
    targets and running
    
    valgrind examples/c/x01c -dev wxwidgets with
    
    which showed long-standing memory leak issues, but no memory management errors, e.g.,
    
    ==1032== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
    
    I also built all prerequisite targets for python examples
    (_plplotc_fixed and python_examples) and ran both
    
    python3 examples/python/test_circle.py -dev wxwidgets
    
    and
    
    python3 examples/python/test_superscript_subscript.py -dev wxwidgets
    
    That first Python example allows extremely precise checking of the vertical
    alignment for the above 4 centred utf8 symbols and showed no discernible
    misalignment with the above value of empiricalYOffset.
    
    That second Python example shows good relative and absolute vertical
    alignment of characters such as "p", "o", and "b" with a descender,
    with no ascender or descender, and with an ascender.  However, there
    are still the following vertical alignment and linebreak issues.
    
    * A string with just superscripts and the corresponding string with
      identical subscripts show inconsistent vertical alignment relative
      to each other (the superscript string is rendered too high, and the
      subscript string is rendered too low by the same amount compared to
      the absolute vertical position where these two string should be
      rendered).
    
    * Two strings that have a symmetrical range of both superscripts and
      subscripts but in different orders have consistent vertical
      alignment with each other which is nevertheless incorrect when
      compared to the correct absolute vertical positioning of simple
      strings such as "p", "o", and "b".
    
    * linebreak vertical spacing does not appear to be correct since
      superscripts on the lower line are currently superimposed on
      subscripts from the upper line.
    
    * The current logic reinitializes superscript/subscript state after
      each linebreak and eventually should be changed so that
      superscript/subscript level state is properly maintained through
      linebreaks (i.e., independent of linebreaks).
    
    I don't view any of these issues as release showstoppers so my plan is
    to deal with these issues in the indefinite long-term as a low
    priority.

M	drivers/wxwidgets.h
M	drivers/wxwidgets_dev.cpp
M	examples/python/test_superscript_subscript.py

commit 4c0fc780b05464de943687a26c94b62cf1217f47
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Aug 8 15:32:19 2017 -0700

    Build system: Actually fix Java issue for CMake versions > 3.7.2
    
    This commit replaces a workaround for a CMake bug with the actual
    CMake fix for this CMake bug.  See thread on the cmake-developer list
    started on 2017-07-21 with the subject line "Java language support
    regression (compared with 3.7.x and 3.8.x) for 3.9.0" for more details
    concerning this CMake bug.  The upshot some time later
    was Brad King committed the definitive fix for UseSWIG.cmake for this
    issue in the release branch after 3.9.0 (i.e., it will likely go into
    3.9.1) and this current PLplot commit insures the cmake/modules version of that file
    is identical.  The plan going forward (assuming the CMake 3.9.1 release
    includes this bug fix) is as soon as our minimum CMake version is 3.9.1
    or higher, to remove the cmake/modules version of UseSWIG.cmake
    so our users can just use the official version(s) of that file
    that come with their CMake installation instead.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_diff_psc target which had no
    build or run errors and no PostScript difference regressions (i.e.,
    perfect results for all languages including Java except for the
    long-standing Ocaml differences).  I performed this test for both
    CMake-3.6.2 (our minimum version) and CMake-3.9.0 with the
    same good results for both versions.

M	cmake/modules/UseSWIG.cmake

commit a5a0d252c245d3380edcdbe292d4b7ee0344214d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Aug 6 17:21:35 2017 -0700

    Traditional build system for the installed examples: Fix some rpath issues
    
    Namely the following:
    
    * Do not use rpath at all for WIN32_OR_CYGWIN platforms.  This should
      fix the gcc "Bad address" bug on the MinGW-w64/MSYS2 that has been
      reported by Arjen.  There is some possibility I could address that
      issue by replacing the colon-separated rpath that I am virtually
      certain is the cause of this issue by a semicolon-separated rpath,
      but I decided to drop rpath altogether to follow what our
      CMake-based build system for the installed examples does and because
      our WIN32_OR_CYGWIN platform users are already used to the
      alternative which is to set PATH appropriately to find PLplot
      libraries (and device drivers when those exist separately).
    
    * Consolidate Fortran RPATHCMD logic in examples/CMakeLists.txt. I also
      took this opportunity to fix some potential quoting bugs.
    
    * Consolidate ocaml RPATHCMD logic in examples/CMakeLists.txt.  My preliminary
      tests showed -ccopt and blank escape bugs in this case, and I have
      no idea how the previous logic in examples/ocaml/CMakeLists.txt passed
      my previous tests.  But the new logic is rock-solid and consistent
      with how we treat -copt options for the ocaml bindings.
    
    Tested by: Alan W. Irwin <airwin@user.sourceforge.net> on Linux
    (Debian Jessie) by running (from a source tree with space in the prefix)
    
    scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --do_submit_dashboard yes --do_test_interactive no --do_test_noninteractive no --do_test_install_tree no --do_test_traditional_install_tree no
    
    (note this test has a space in the prefixes of the source, build, and install tree)
    
    The results were checked as follows:
    
    # Check for any warning regressions 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 issues other than long-standing PostScript
    differences for ocaml (and therefore no PostScript difference
    regressions) in the ctest results.  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	examples/CMakeLists.txt
M	examples/fortran/CMakeLists.txt
M	examples/ocaml/Makefile.examples.in

commit 38ac92317173701b1f85b778f7f399e67590a5fb
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jul 31 23:53:17 2017 -0700

    Attempt to quiet compile warning on Cygwin
    
    That warning (reported by Arjen Markus) was
    
    bindings/tk/Pltk_Init.c:40:12:
    warning: ‘Matrix_Init’ redeclared without dllimport attribute:
    previous dllimport ignored [-Wattributes]
     extern int Matrix_Init( Tcl_Interp* interp );
                ^
    
    However, Matrix_Init is already correctly declared in
    bindings/tcl/tclMatrix.h, and the chain of includes starting at
    bindings/tk/Pltk_Init.c does include that file. So the above line
    should be completely unnecessary (as implied by the Cygwin compile
    warning), and I have therefore removed it in this commit.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) for the following compile flags:
    
    CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized
    CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
    FFLAGS=-O3 -Wuninitialized -Wunused
    
    and for the build tree in the shared libraries case.
    
    The results were checked by
    
    grep -i warning test_noninteractive.out |grep -vE 'PRIVATE|Wdeprecated|PLPLOT WARNING|Resource leak:|2 problems \(2 warnings\)|Some graphical or stdout results were different'
    grep -i error test_noninteractive.out
    grep -B1 -A3 "Missing examples" test_noninteractive.out |less
    
    The first two showed no serious build or run-time issues, and the last
    one showed no regressions in the PostScript differences, i.e., this
    test was a complete success on Debian Jessie.
    
    However, additional testing of this commit on all Windows platforms is
    requested to confirm no additional issues were introduced for those
    platforms by this change and also to confirm the above compile
    warning is removed by this change.

M	bindings/tk/Pltk_Init.c

commit bbf4e4d8b348ea74b0563dfdc5106e8e3152cb52
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Jul 27 15:15:20 2017 -0700

    Build system: Update documentation of how we build our Python extensions

M	bindings/python/README.pythonbuild

commit 79ed7a885c38b5ae7ff01b492cb5ed5966a62c89
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Jul 27 10:22:55 2017 -0700

    Build system: Work around Java issue for CMake versions > 3.7.2
    
    See thread on the cmake-developer list started on 2017-07-21 with
    the subject line "Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0"
    for more details.  The upshot is the following line was inserted into the official UseSWIG.cmake
    after version 3.7.2
    
    set(SWIG_JAVA_EXTRA_FILE_EXTENSIONS ".java" "JNI.java")
    
    which generates the following CMake error not only for PLplot but a simple test project.
    
    CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
    Missing variable is:
    CMAKE_Java_CREATE_SHARED_MODULE
    
    There is a deeper Java language support issue here which I assume the
    CMake developers will eventually fix, but for now a workaround is
    simply to comment out the above line.  To make sure our users have
    access to that workaround, I have copied the official UseSWIG.cmake
    from CMake-3.9.0 to cmake/modules and commented out the above line, and
    the official plan for this file is to simply delete it again (so our users
    use the official UseSWIG.cmake) once the version of CMake with the
    proper fix for the Java issue becomes our minimum version.
    
    A by-product of the above change is that the swig_add_module commands we have
    been using in all our swig-generated bindings generated deprecation warning
    messages so to quiet those I also changed all instances of swig_add_module to
    the equivalent swig_add_library command which is now defined in this
    latest version of UseSWIG.cmake.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_diff_psc target which
    had no build or run errors and no PostScript difference regressions (i.e.,
    perfect results for all languages including Java except for the long-standing
    Ocaml differences).  I performed that test for both CMake-3.6.2 (our minimum
    version) and CMake-3.6.2.  In addition (to thoroughly test CMake-3.9.0 for the
    first time) I ran
    
    scripts/comprehensive_test.sh --cmake_command ~/cmake/install-3.9.0/bin/cmake --do_submit_dashboard yes
    
    (By accident I forgot to set up this test to use a space in source,
    build, and install tree prefixes, but that extra test step was done
    for the other recent unconstrained comprehensive test so this
    limitation of the present test is noted here but does not justify
    redoing this test.)
    
    These comprehensive test results were perfect (except for the
    long-standing OCaml PostScript differences) as measured by the
    following commands:
    
    # Check for any warning regressions in the cmake output.
    less ../comprehensive_test_disposeable/shared/noninteractive/output_tree/cmake.out
    
    # Check for some non-standard warnings:
    grep -i warning ../comprehensive_test_disposeable/*/*/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/*/*/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/*/*/output_tree/*.out |less
    
    The ctest part of these tests were also successfully published at
    <http://my.cdash.org/index.php?project=PLplot_git> because of the
    above --do_submit_dashboard yes option.

M	bindings/java/CMakeLists.txt
M	bindings/lua/CMakeLists.txt
M	bindings/octave/CMakeLists.txt
M	bindings/python/CMakeLists.txt
A	cmake/modules/UseSWIG.cmake

commit 6819eb37975a45ca39000a120396affee993bd7d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jul 24 14:00:59 2017 -0700

    Build system: Fix duplicate bugs 182 and 163 for pkg-config.cmake
    
    The last argument of string(REGEX REPLACE...) must be quoted (in case
    it is empty).  I thought I had gotten all of these non-quoted issues
    before in pkg-config.cmake, but there was one instance still remaining
    (only relevant on Mac OS X) which I have now fixed.

M	cmake/modules/pkg-config.cmake

commit 5fc910877896271147aecb584a18ed5c424eb147
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Jul 23 22:34:45 2017 -0700

    Spelling changes throughout source tree
    
    Fix bad variants of the spelling of "continuous" and "argument" that were kindly
    reported by Ole Streicher from his Debian packaging lint results.
    
    These changes were implemented automatically as follows:
    
    sed -i -e 's?Continous?Continuous?g' $(find . -type f|grep -v .git |xargs grep -l Continous)
    sed -i -e 's?continous?continuous?g' $(find . -type f|grep -v .git |xargs grep -l continous)
    sed -i -e 's?argment?argument?g' $(find . -type f|grep -v .git |xargs grep -l argment)
    
    Afterwards
    
    find . -type f|grep -v .git |xargs grep -lE 'argment|continous'
    
    found no files (as expected).  Furthermore, git diff showed these
    changes in the 22 files that were updated with the sed
    commands above were for either documentation files, or
    for comments and error messages in non-documentation files.
    
    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 by building the check_all
    target with success (which runs a number of tests for consistency
    between documentation files and code files).  The
    check_api_xml_consistency target is not triggered by that overall
    target because it errors out so I ran that by hand, and the two
    inconsistencies are the usual ones, i.e., no regressions in the
    consistency between our DocBook documentation of our API, and our
    actual API in include/plplot.h have been introduced by these spelling
    changes.
    
    The final two tests I ran of this commit were
    
    scripts/remove_trailing_whitespace.sh
    
    and
    
    scripts/style_source.sh
    
    which demonstrated no style or trailing whitespace issues have
    been introduced by this commit.

M	OLDER-NEWS
M	README.developers
M	bindings/ada/plplot_standard.adb
M	bindings/ada/plplot_standard.ads
M	bindings/ada/plplot_thin.adb
M	bindings/ada/plplot_thin.ads
M	bindings/ada/plplot_traditional.adb
M	bindings/ada/plplot_traditional.ads
M	bindings/d/plplot.d
M	bindings/fortran/included_plplot_parameters.f90
M	bindings/non_redacted_tcl/plplot_parameters.h
M	bindings/old_fortran/plplot_parameters.inc
M	bindings/python/Plframe.py
M	bindings/python/plplotc.i
M	bindings/swig-support/plplotcapi.i
M	bindings/swig-support/swig_documentation.i
M	bindings/tcl/plplot_parameters.h
M	doc/docbook/src/api.xml
M	drivers/xwin.c
M	include/plplot.h
M	src/plargs.c
M	www/announce/ChangeLog-5.2.1-5.3.0

commit 4c90970e0db2ee1394979cd1bcf948e1002f7767
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Jul 22 00:06:45 2017 -0700

    Build system: Quiet cmake developer warning
    
    The change I made was to replace the fifth argument of the CMake
    string (REPLACE ...) signature command as follows:
    
    -  "${_octave_m_dir}"/PLplot
    +  "${_octave_m_dir}/PLplot"
    
    That first form generated
    
    CMake Warning (dev) at cmake/modules/octave.cmake:258:
      Syntax Warning in cmake code at column 21
    
      Argument not separated from preceding token by whitespace.
    Call Stack (most recent call first):
      cmake/modules/plplot.cmake:491 (include)
      CMakeLists.txt:129 (include)
    This warning is for project developers.  Use -Wno-dev to suppress it.
    
    The second unambiguous form (with everything inside quotes) suppressed
    that warning, but appending that "/PLplot" is necessary for getting
    all Octave components installed in the correct place, and a check of
    the recent full comprehensive test results without this fix showed
    that was happening properly even for the first ambiguous form.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by configuring PLplot with cmake and showing
    the developer warning is now gone from those cmake results.

M	cmake/modules/octave.cmake

commit 60d51d034646333236f368da9bea95ff78f372c2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Jul 21 23:31:59 2017 -0700

    Comprehensive test script: Fix ctest options when submitting a dashboard
    
    For the --do_submit_dashboard yes script option, this bug was screwing up the ctest command-line options
    (by jamming the -extra-verbose and -D Experimental options together without a space separator).
    I fixed this issue by changing the bash variable dashboard_option to be an empty string
    when a dashboard is not submitted, and leaving it as "-D Experimental " (note the trailing space)
    when a dashboard is submitted, and then prepending a space to all uses of $dashboard_option and leaving
    no space afterward.  The result is that
    
    echo_tee "$ctest_command --extra-verbose ${dashboard_option}in the build tree"
    $ctest_command --extra-verbose ${dashboard_option}>& "$output"
    
    is correctly translated to
    
    echo_tee "$ctest_command --extra-verbose in the build tree"
    $ctest_command --extra-verbose >& "$output"
    
    when there is no dashboard submitted and
    
    echo_tee "$ctest_command --extra-verbose -D Experimental in the build tree"
    $ctest_command --extra-verbose -D Experimental >& "$output"
    
    when there is a dashboard submitted.
    
    Tested by: Alan W. Irwin <airwin@user.sourceforge.net> on Linux
    (Debian Jessie) by repeating the previous comprehensive test
    except for limiting it to ctest only (and build tree only), i.e.,
    by running (from a source tree with space in the prefix)
    
    scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --do_submit_dashboard yes --do_test_interactive no --do_test_noninteractive no --do_test_install_tree no --do_test_traditional_install_tree no
    
    (note this test has a space in the prefixes of the source, build, and install tree)
    
    The results were checked as follows:
    
    # 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 issues other than long-standing PostScript
    differences for ocaml (and therefore no PostScript difference
    regressions) in the ctest results.  In addition, 3 dashboards (for the
    shared, nondynamic, and static cases) were correctly posted to
    <http://my.cdash.org/index.php?project=PLplot_git>.

M	scripts/comprehensive_test.sh

commit b0cdaa9853c5f067a70114bf504bbd7b5ce297a6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Jul 21 22:11:21 2017 -0700

    Remove trailing whitespace introduced in an earlier commit

M	bindings/qt_gui/pyqt4/CMakeLists.txt
M	bindings/qt_gui/pyqt5/CMakeLists.txt

commit 62e07d48f85c95851dd9084115c75385b17c71ba
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Jul 21 22:09:26 2017 -0700

    Build system updates concerning install locations
    
    The big change here is all install locations are now cached
    so that any of them can be controlled by the user by
    setting the appropriate -D cmake option.  These
    install location variables have been found using
    
    find . -type f|grep -v .git |grep -v epa_build |xargs grep -h DESTINATION |sed -e 's?  *? ?g' -e 's?^ ??'|sort -u |less
    
    to find all instances of DESTINATION (the CMake install command option which
    determines install locations).
    
    I also took this opportunity to make the following related changes:
    
    * I automated checking that all install locations had a common prefix
      as part of summarizing all install locations in summary.cmake.
    
    * I added many optional install location variables (e.g.,
      FORTRAN_MOD_DIR determined in cmake/modules/fortran.cmake when
      ENABLE_fortran is ON) to the list of such variables being processed by
      summary.cmake for the case when such variables are defined.
    
    * I converted mandatory install locations to optional where
      appropriate, e.g., I moved the determination of ADA_INCLUDE_DIR and
      ADA_LIB_DIR from cmake/modules/instdirs.cmake to
      cmake/modules/ada.cmake, and only when ENABLE_ada was ON.
    
    * I reserved JAVAWRAPPER_HARDDIR for configured files (where
      hard-coded install locations are needed) and replaced it with
      JAVAWRAPPER_DIR for other use cases that were subject to the DESTDIR
      staging area mechanism.
    
    * I replaced SHLIB_DIR everywhere with LIB_DIR.
    
    * I replaced ${OCTAVE_M_DIR}/PLplot everywhere with ${OCTAVE_M_DIR}
      (and appended "/PLplot" to the definition of OCTAVE_M_DIR).
    
    * I renamed JAVADATA_HARDDIR by JAR_HARDIR since that is the "hard"
      version of JAR_DIR to be used to configure files with hard-coded
      Java install locations.
    
    * I removed an unneeded determination of what is now named
      JAR_HARDIR from examples/java/CMakeLists.txt
    
    I also took this opportunity to change summary.cmake to display either
    ENABLE_pyqt5 or ENABLE_pyqt4 (but not both) depending on the value of
    PLPLOT_USE_QT5.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running
    
    scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --do_submit_dashboard yes
    
    from a source tree with a space in its prefix.  Because of the lack of
    any limiting options above this comprehensively tested all interactive
    and noninteractive components of PLplot that are available by default
    on a fully loaded Linux system.
    
    I chose to make the test that extensive because of the intrusive
    nature of the above changes.  Furthermore, because of that choice of
    source tree and the above --prefix option this test checked there
    continue to be no issues concerning spaces in the prefixes of source,
    build, or install trees.  (The above test repeated the success I had
    with an identical (except for --do_submit_dashboard yes option) test
    just after commit 58bc02e in early July.)
    
    These test results were perfect as measured by the following commands:
    
    # 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
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/build_tree/Testing/Temporary/LastTest.log |less
    
    (That last grep command was necessary because of a minor bug in the script which
    meant the actual ctest commands executed  was
    
    ctest -j4 --extra-verbose-D Experimental <message>
    
    rather than the correct command with the space between the
    --extra-verbose and -D options.  The net effect was no verbose results
    in the ctest.out files and no dashboards submitted, but, otherwise
    ctest ran properly [as determined by that last grep command above],
    and I hope to fix that minor script bug shortly.)

M	bindings/java/CMakeLists.txt
M	bindings/ocaml/META.in
M	bindings/octave/PLplot/CMakeLists.txt
M	cmake/modules/ada.cmake
M	cmake/modules/fortran.cmake
M	cmake/modules/instdirs.cmake
M	cmake/modules/java.cmake
M	cmake/modules/lua.cmake
M	cmake/modules/ocaml.cmake
M	cmake/modules/octave.cmake
M	cmake/modules/pkg-config.cmake
M	cmake/modules/python.cmake
M	cmake/modules/summary.cmake
M	cmake/modules/tcl-related.cmake
M	examples/CMakeLists.txt
M	examples/java/CMakeLists.txt
M	examples/java/Makefile.examples.in
M	pkgcfg/plplot-template.pc.in
M	plplot_test/plplot-test.sh.in
M	plplot_test/test_java.sh.in

commit c8739dd0a08a12fee6fa7bc3955e4287ed41dc5a
Author: Arjen Markus <arjen.markus@deltares.nl>
Date:   Sun Jul 16 14:38:18 2017 +0200

    Revert the earlier change which added two possible paths for finding the wxWidgets libraries. These paths are in fact already covered by the _WX_ARCH_ macro being set to an empty string if the build architecture is "32-bits" instead of "64-bits". The alternatives made it possible to find libraries for the wrong "bitness", leading to link problems that are awkward to diagnose.
    
    The bottom line is: get the wxWidgets installation for the right platform and architecture - and be careful about it.
    
    Tested by Arjen Markus (arjenmarkus@users.sourceforge.net) on Windows with MSVC

M	cmake/modules/FindwxWidgets.cmake

commit edd093972f8b3b9805cdbe94218828dae141e732
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Jul 13 01:15:14 2017 -0700

    Adjust for the new "plplot-doc-check" name of Hǎiliàng Wang's API consistency checker for PLplot
    
    That golang programme checks for consistency between our DocBook documentation of our API
    in doc/docbook/src/api.xml and the include/plplot.h header that defines our C API.
    Hǎiliàng upgraded that programme today to correctly handle callback function
    arguments, and he took the opportunity to change the name of the programme from "check"
    (which I had symlinked to a unique name because that name was too generic) to
    "plplot-doc-check" (which is sufficiently unique that it doesn't require a symlink).
    
    This commit adjusts for that new name, and I also took this opportunity to document
    how the new plplot-doc-check should be built in the comments in this CMakeLists.txt file.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building plplot-doc-check and putting it on the
    PATH, configuring the PLplot
    build with the cmake option -DADD_SPECIAL_CONSISTENCY_CHECKING=ON
    and checking for consistency between DocBook and C versions of
    our API by building the check_api_xml_consistency target.  The
    result was _almost_ a succes with two inconsistencies found which
    are as follows:
    
    c_plshade1 is not documented.
    para 0 of func plGetCursor TYPE mismatch doc[ PLGraphicsIn * ] vs. header[ struct PLGraphicsIn * ]
    
    The first corresponds to a real inconsistency which will be fixed when plshade1 is deprecated
    (the documentation is ahead of the C code in that regard).  The second is a spurious warning
    which I have brought to the attention of Hǎiliàng Wang.

M	doc/docbook/src/CMakeLists.txt

commit ff76ebd4bf9eee03ff5dd1dbdb9a69b466d07c19
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Jul 12 21:53:04 2017 -0700

    Work around plplot_pyqt4.so and plplot_pyqt5.so symbol visibility issues for GNU C++ compiler
    
    The combination of python3 (at least for version 3.4) and sip creates
    a useless shared object with no externally accessible symbols when the
    GNU version of the C++ compiler (i.e., g++ or the ccache version of
    it) with the -fvisibility=hidden option is used to compile either the
    plplot_pyqt4.so or plplot_pyqt5.so modules. As a result, python3
    cannot load either of these modules.  For this commit I work around
    this issue by appending -fvisibility=default to the compiler options
    for this target for all python 3 cases.  This visibility issue does
    not exist for Python 2.  It is possible it has been or will be fixed
    for some version of Python 3 greater than 3.6.4 so the necessity of
    this workaround should be tested periodically for later versions of
    Python (and sip).  But google searches have so far found no
    bug reports concerning this visibility issue.
    
    Since this fix makes it possible to reliably build the test_pyqt4_example
    target, make that target a dependency of the test_interactive generic
    target.  I have not made a similar change for the test_pyqt5_example
    target (despite its visibility issue being solved by this commit)
    because there is past evidence of segfaults for that target.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running the following commands:
    
    scripts/comprehensive_test.sh --cmake_command /home/software/cmake/install-3.6.2/bin/cmake --cmake_added_options "-DPLPLOT_USE_QT5=OFF -DFORCE_PYTHON2=OFF -DDEFAULT_NO_DEVICES=ON -DPLD_extqt=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON -DENABLE_qt=ON -DENABLE_pyqt4=ON" --do_test_noninteractive no --do_ctest no
    
    scripts/comprehensive_test.sh --cmake_command /home/software/cmake/install-3.6.2/bin/cmake --cmake_added_options "-DPLPLOT_USE_QT5=ON -DFORCE_PYTHON2=OFF -DDEFAULT_NO_DEVICES=ON -DPLD_extqt=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON -DENABLE_qt=ON -DENABLE_pyqt5=ON" --do_test_noninteractive no --do_ctest no
    
    (The last of these commands was run with a local change to
    examples/CMakeLists.txt to temporarily make the test_pyqt5_example
    target a dependency of the test_interactive target.)
    
    For the shared and nondynamic overall configurations and for the build
    tree and installed examples tree with CMake-based build system, I
    obtained the expected good interactive test_pyqt4_example example
    results for the first command above and the expected good interactive
    test_pyqt5_example example results for the second command.  In that
    latter case, there was no sign of segfaults so it is possible the past
    issue with those has been cured but more investigation will be
    required to come to a definitive conclusion about that issue.
    
    The results of both the first and second commands above also showed
    the expected results for the following checks:
    
    # 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
    
    N.B. The above GNU C++ compiler workaround has only been tested on a
    Linux platform (with the ccache version of g++) so far so similar
    tests are requested on other platforms which use GNU C++ compilers
    (e.g., Cygwin, MinGW-w64/MSYS2, Mac OS X, and Linux without ccache).
    
    N.B. The above workaround has no effect on any platform (e.g., MSVC)
    which does not use GNU compilers, and such platforms also need to be
    tested with Python 3 to see if a similar visibility issue needs to
    be worked around for them.

M	bindings/qt_gui/pyqt4/CMakeLists.txt
M	bindings/qt_gui/pyqt5/CMakeLists.txt
M	examples/CMakeLists.txt

commit 68e499b4ca830d20b0e7bca999ce756b6c744c67
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Jul 12 14:14:30 2017 -0700

    Replace out-dated Debian packaging files with documentation of where to find the latest Debian packaging information
    
    As a result of this change, the debian subdirectory is removed.
    Therefore, I have dropped the redundant build-system constraint
    that the debian subdirectory is not included in our source release
    tarballs.  In addition, I have documented where to find the
    latest Debian packaging information in
    the new file debian_packaging/README.

M	CMakeLists.txt
D	debian/NEWS
D	debian/README.Debian
D	debian/README.source
D	debian/Release
D	debian/TODO
D	debian/changelog
D	debian/compat
D	debian/control
D	debian/control.in
D	debian/copyright
D	debian/get-upstream-version.pl
D	debian/index.html.in
D	debian/install-www.sh
D	debian/libcsiro0.files
D	debian/libplplot-ada1-dev.files
D	debian/libplplot-ada1.files
D	debian/libplplot-ada1.lintian-overrides
D	debian/libplplot-c++11.files
D	debian/libplplot-d.files
D	debian/libplplot-dev.files
D	debian/libplplot-fortran10.files
D	debian/libplplot-fortran10.lintian-overrides
D	debian/libplplot-java.files
D	debian/libplplot-lua.files
D	debian/libplplot-ocaml.files
D	debian/libplplot-ocaml.lintian-overrides
D	debian/libplplot12.files
D	debian/libqsastime-dev.files
D	debian/libqsastime0.files
D	debian/make-cvs-release.sh
D	debian/octave-plplot.files
D	debian/patches/02_unset-python-path.diff
D	debian/patches/04_use-mkoctfile.diff
D	debian/patches/add-tcl-multiarch.diff
D	debian/patches/dont-check-for-hdf5_h
D	debian/patches/fix-lua-includes.diff
D	debian/patches/fix-wxwidgets-linkage.diff
D	debian/patches/fix_config_h_clash
D	debian/patches/octave_3.8_support.diff
D	debian/patches/proper-path-handling.diff
D	debian/patches/remove_nondfsg_dirs
D	debian/patches/series
D	debian/patches/set_cmake_policy
D	debian/patches/support-javac-options.diff
D	debian/plplot-doc.doc-base
D	debian/plplot-doc.files
D	debian/plplot-tcl-bin.files
D	debian/plplot-tcl-dev.files
D	debian/plplot-tcl-dev.lintian-overrides
D	debian/plplot-tcl.files
D	debian/plplot12-driver-cairo.files
D	debian/plplot12-driver-qt.files
D	debian/plplot12-driver-wxwidgets.files
D	debian/plplot12-driver-xwin.files
D	debian/python-plplot-qt.files
D	debian/python-plplot.files
D	debian/repack
D	debian/rules
D	debian/source/format
D	debian/upload-debs.pl
D	debian/watch
A	debian_packaging/README

commit 1e1224cbc6e816f155b50d669991edc0b0df38a1
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Jul 12 13:52:03 2017 -0700

    Build system: bug fix: do not attempt to install non-existent README.1st files
    
    These README.1st files in the lib/csa and lib/nn subdirectories
    were removed in the last commit, and this commit fixes the
    install error caused by attempting to install those files
    which no longer exist.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the install target with success.

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

commit 60bf759220062c19f8c74fba7eebecc5013b879b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jul 11 23:06:55 2017 -0700

    Update the license for the PLplot version of the csa and nn libraries
    
    These libraries are substantially modified versions of the 2003
    versons of Pavel Sakov's csa and nn libraries that are used to help
    provide our plgriddata API for our core plplot library.  The license
    update we have done with this commit for the PLplot versions of these
    libraries was to adopt the licensing text now used by Pavel Sakov for
    his latest versions of the csa and nn libraries (with the add-on note
    concerning the non-free triangle library specifically excluded from
    the latter licensing text since our changes to nn make the triangle
    library irrelevant to our version of nn.)  This latest licensing text
    is a simplification of the 3-clause BSD license, and it is the opinion
    of Ole Streicher, that this license is free and compliant with the
    DFSG (Debian Free Software Guidelines) which should allow him to close
    a critical bug for his Debian package of PLplot.
    
    Since those 2003 libraries were copyright Pavel Sakov we needed his permission to do
    this licensing update which he kindly gave us with the following e-mail text:
    
    Date: Wed, 12 Jul 2017 14:08:28 +1000
    Subject: Re: Request to update the licensing for our stripped down and substantially modified 2003 versions of nn and csa to your modern licenses for nn and csa
    ----------------------------------------
    
    Hi Alan,
    
    I agree with the changes in the libraries nn and csa used in PLplot as
    proposed in your message and quote below the first paragraph from your
    message as you requested to confirm my agreement.
    
    "On behalf of the PLplot developers I request your agreement for
    updating the licensing of our stripped-down and substantially modified
    versions of your 2003 version of the csa and nn libraries to be
    respectfully the same as your modern license for csa given at <
    https://github.com/sakov/csa-c/blob/master/csa/LICENSE> and your modern
    license for nn given at
    <https://github.com/sakov/nn-c/blob/master/nn/LICENSE> (with the last two
    note lines concerning triangle dropped because we use the free qhull
    library rather than non-free triangle software <
    http://www.cs.cmu.edu/~quake/triangle.html>)."
    
    Best regards,
    Pavel Sakov

A	lib/csa/LICENSE
M	lib/csa/README
D	lib/csa/README.1st
A	lib/nn/LICENSE
M	lib/nn/README
D	lib/nn/README.1st

commit b3e1452c7fbcf09db0edf4ac7d8906f8779d1f49
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jul 11 01:26:59 2017 -0700

    Documentation: get rid of tabs in the generated file bindings/swig-support/swig_documentation.i
    
    I noticed a number of tabs randomly sprinkled through the
    perl-generated file bindings/swig-support/swig_documentation.i so
    following the Linux man pages for Text::Tabs and Text::Wrap it
    appeared that perhaps the problem was caused by the low-level
    Text::Tabs interfering with the high-level Text::Wrap.  So in the perl
    script doc/docbook/bin/api2swigdoc.pl that is used to generate
    bindings/swig-support/swig_documentation.i (indirectly through the
    target check_swig_documentation) I dropped using the Text::Tabs module
    and used $Text::Wrap::unexpand = 0 to avoid tabs in output as
    documented in the Text::Wrap man page.  The (good) result is better
    space indentation for arguments and no tabs in the output.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the check_swig_documentation target,
    looking at the result
    bindings/swig-support/swig_documentation.i_compare in the build tree
    and copying that result back to
    bindings/swig-support/swig_documentation.i in the source tree.

M	bindings/swig-support/swig_documentation.i
M	doc/docbook/bin/api2swigdoc.pl

commit aca2d8db142b14c1a20aabef0e083739ec7199ad
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jul 11 01:17:21 2017 -0700

    Use PLPointer for our single recommended generic pointer type
    
    The plan (first announced in the release notes for 5.12.0) for
    introducing two new types of generic pointers (one with the const
    attribute and one not) has now been dropped.  However, as a side
    effect of this dropped plan, we now currently have three generic
    pointers, PLPointer, PL_GENERIC_POINTER, and PL_NC_GENERIC_POINTER
    typedef'd where the first one is recommended, the last two (introduced
    in 5.12.0) are now deprecated and scheduled for removal in the first
    release after 5.13.0, and all three continue to be typedef'd as void *.
    
    Consistent with that deprecation, this commit replaces all references
    to PL_GENERIC_POINTER and PL_NC_GENERIC_POINTER in our source tree by
    PLPointer except for cases (i.e., include/plplot.h and README.release
    as well as historical log files and cumulated release notes) where
    PL_GENERIC_POINTER and PL_NC_GENERIC_POINTER must necessarily be
    mentioned.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) fairly extensively (since this is an intrusive
    commit) by setting the environment variables
    
    CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized
    CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
    FFLAGS=-O3 -Wuninitialized -Wunused
    
    before configuration using the -DBUILD_DOC=ON
    -DADD_SPECIAL_CONSISTENCY_CHECKING=ON cmake options.  This was
    followed by
    
    * Building the test_interactive and test_noninteractive targets in the
      build tree for the default shared library case without build or
      run-time errors and without regressions in warning messages or
      PostScript difference results.
    
    * Building the build_docbook_documentation target (made available
      because of the above -DBUILD_DOC=ON cmake option) and checking those
      results (paying special attention to use of PLPointer) by using a
      browser to browse the resulting doc/docbook/src/plplot-5.12.0.pdf in
      the build tree.
    
    * Building the check_api_xml_consistency target (made available
      because of the above -DADD_SPECIAL_CONSISTENCY_CHECKING=ON cmake
      option).  That revealed ~30 API inconsistencies between
      doc/docbook/src/api.xml and include/plplot.h, but all but one of
      those were spurious.  I have written Hǎiliàng Wáng to see whether he
      will be able to fix his API consistency checking code (which he
      wrote in Go and which I am using for this check) to get rid of these
      spurious API inconsistency warnings.  (The warning generated by his
      code which was not spurious should be fixed by the planned deprecation
      of plshade1, but I am putting off that deprecation until later.)

M	README.release
M	doc/docbook/src/api-c.xml
M	doc/docbook/src/api.xml
M	doc/docbook/src/c.xml
M	doc/docbook/src/plplotdoc.xml.in
M	doc/docbook/src/tcl.xml
M	include/plplot.h

commit 2315367b3f5aeaef2a62b0131456a1c0e7c38041
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jul 10 12:17:18 2017 -0700

    Increase sophistication of script for trailing whitespace removal
    
    The user is now presented with a list of files that have trailing
    whitespace, and is given the option of removing that whitespace
    for all those files.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running the script with and without files with
    trailing whitespace and for the "with" case optionally removing that whitespace.

M	scripts/remove_trailing_whitespace.sh

commit 175eb9431060ed4091740fdec4f5e6bb06b184d7
Author: Arjen Markus <arjen.markus@deltares.nl>
Date:   Fri Jul 7 08:06:19 2017 +0200

    Add two plausible forms for the installation directories of wxWidgets under Windows/MSVC. The base form was observed in an "official" installation of wxWidgets for MSVC. So to be able to find these libraries I added these two forms (for DLLS and for static libraries).
    
    Note: This change only affects the Windows style of searching for the libraries.
    
    Tested by Arjen Markus (arjenmarkus@users.sourceforge.net) using MSVC 2012.

M	cmake/modules/FindwxWidgets.cmake

commit b05d501783e0917f109bf307536627a77b849e44
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Jul 5 14:19:28 2017 -0700

    Test system: Temporarily ignore example 14 for wxwidgets tests
    
    For example 14 on Windows, Arjen's run of
    
    examples/c/x14c -dev wxwidgets
    
    hung for -DPL_WXWIDGETS_IPC3=ON.
    
    On Linux that same command does not hang, but it does show
    (regardless of whether -DPL_WXWIDGETS_IPC3=ON or OFF) a
    bug where the slave GUI shows briefly than disappears.
    
    Because of these bugs and in the interest of allowing
    Arjen to complete his comprehensive tests of wxwidgets on Windows,
    The current commit temporarily ignores example 14 for wxwidgets tests.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_c_xwin, test_c_xcairo, test_c_qtwidget,
    and test_c_wxwidgets targets and showing all of them other
    than test_c_wxwidgets run example 14.

M	plplot_test/test_c_interactive.sh.in

commit cf589b7628a02dee4d0d9e9b862b88b428becc59
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jul 3 04:48:54 2017 -0700

    Update release notes
    
    These changes include the following:
    
    * Update the "CMake version compatibility" section
    
    * Update the "The Python binding and examples now work for both Python 2 and 3"
      section
    
    * Introduce a new section entitled 'Fixed many "space in prefix" issues'
    
    N.B. these release notes are known to still be incomplete.

M	README.release

commit 58bc02e78e374d69e1b52cc9b1995f56b7f8d07d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jul 3 01:34:44 2017 -0700

    Tcl/Tk build system, bindings, and examples: Fix space issues in prefixes of source, build, or install trees
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_wish_runAllDemos,
    test_plserver_runAllDemos, and test_wish_standard_examples targets in
    the shared build tree, and verifying that in each case the COMMAND
    that was being tested started executing.  (These targets are available
    for individual tests, but are not run as part of comprehensive testing
    because of certain errors for these targets.)  In addition I ran
    the piecemeal equivalent of a (successful) run of
    
    scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_xwin=ON -DPLD_tk=ON -DPLD_ntk=ON -DPLD_tkwin=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_tcl=ON -DENABLE_tk=ON -DENABLE_itcl=ON -DENABLE_itk=ON -DENABLE_python=ON"  --do_test_noninteractive no --do_ctest no
    
    (note the space in the prefix option) from a source tree with a space
    in its prefix.  As a result, this test checked there were no issues
    concerning spaces in the prefixes of source, build, or install trees
    for all Tcl/Tk related components of PLplot.  The actual test was done
    in 3 parts with the first two parts for the shared case build tree and
    the shared case install tree (with the latter configured both with the
    traditional and CMake-based build system), and the third part all but
    the shared tree part of the above test.  In all parts of this test the
    script output indicated there were no run-time errors captured by the
    tests.  In addition the third test (comprising 2/3rds of the above
    overall test) was evaluated using
    
    # 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

M	bindings/tk/tkMain.c
M	examples/CMakeLists.txt
M	examples/plplot_configure.cmake_installed_examples.in
M	examples/tcl/tclsh_standard_examples.in
M	examples/tk/CMakeLists.txt
M	examples/tk/plgrid.in
M	examples/tk/runAllDemos.tcl
M	examples/tk/runExtendedDemos.tcl
M	examples/tk/tk03.in
M	examples/tk/wish_runAllDemos.in
M	examples/tk/wish_standard_examples.in
M	plplot_test/plplot-test-interactive.sh.in

commit fa8c0bf783a3db4e3da02d2bde9ee64dba0d18a8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jul 3 01:00:12 2017 -0700

    Fix space in source tree prefix issues for remove_trailing_whitespace.sh

M	scripts/remove_trailing_whitespace.sh

commit b779495b4d85324ea509fdc011ca1d5f09fc1597
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Jul 1 13:07:19 2017 -0700

    wxwidgets IPC3: Replace Windows mutexes by named Windows semaphores
    
    The three-semaphores approach really does need to use the semantics of
    two-state semaphores so the previous attempt to use Windows mutexes
    for this purpose (which have slightly different semantics than
    two-state semaphores) were invalid and were likely the cause of the
    "wxPLViewer failed to signal it has found the shared memory" error
    that has been recently found when Arjen tested the Windows variant of
    the three-semaphores approach on MinGW-w64/MSYS2.  This bug in the
    Windows variant of the three-semaphores approach was fixed by
    replacing all Windows mutex API calls by the equivalent Windows named
    semaphores API calls (following the documentation in
    <https://msdn.microsoft.com/en-us/library/windows/desktop/ms686946(v=vs.85).aspx>
    and links from that page).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_c_wxwidgets and test_wxPLplotDemo
    targets and running
    
    examples/c/x00c -dev wxwidgets
    
    N.B. These tests simply confirm that wxwidgets-related PLplot components
    continue to work on Linux, but the above changes are not even build-tested
    by these tests so further tests on MinGW-w64/MSYS2 are required to see
    if the above fix works for the Windows variant of the 3-semaphores approach.

M	drivers/wxwidgets_comms.cpp
M	drivers/wxwidgets_comms.h

commit 77bbcaab23e276792671e619fed4c1a3726cd58d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Jul 1 13:06:51 2017 -0700

    Style previous commits.

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

commit bbfa0774c670a22a25ec8fcbe7ae0993a19178c0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Jul 1 13:05:46 2017 -0700

    Remove trailing whitespace from previous commits

M	cmake/modules/wxwidgets.cmake

commit 76f6a7862641caf3e12029f579e00a9432d2d5b0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jun 26 22:40:53 2017 -0700

    Build system: Fix various wxwidgets find and build issues on Wine/MinGW/MSYS
    
    The find issue on this platform was that find_file(... PATHS
    ${wxWidgets_INCLUDE_DIRS}) did not work correctly when
    ${wxWidgets_INCLUDE_DIRS} was in POSIX drive letter form (e.g.,
    /z/...) and had to be converted to the colon drive letter form (e.g.,
    z:/).  And similarly there were build issues concerning
    wxWidgets_INCLUDE_DIRS such as the the wxwidgets version >= 3.0.0
    check.  The cure was to convert wxWidgets_INCLUDE_DIRS to the colon
    form and append that converted list to the original, i.e., both forms
    are in the list where it is assumed one or the other will work on all
    platforms.
    
    Another independent build issue concerned "cannot convert" LPCTSTR
    LPCWSTR issues.  This happened because the CMake logic line
    
    list(APPEND wxWidgets_DEFINITIONS UNICODE _UNICODE)
    
    in cmake/modules/FindwxWidgets.cmake was buried so deep in Boolean
    logic that it was not executed for this platform (at least for the
    "MSYS Makefiles" case).
    
    I cured that issue by inserting (in cmake/modules/wxwidgets.cmake)
    if(WIN32)
      list(APPEND wxWidgets_DEFINITIONS UNICODE _UNICODE)
    endif(WIN32)
    
    where the Boolean logic is much simpler/clearer.  But we may need
    to review this fix later.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Wine/MinGW/MSYS
    where  the Wine version was Wine Staging 2.10, the MinGW/MSYS
    version was a still-working 4.7.2 snapshot from years ago, and
    the wxwidgets-3.0.2 libraries were epa_built (without issues)
    on this platform.  The test was to run
    
    bash.exe-3.1$ pushd /z/home/software/plplot/HEAD/plplot.git/cmake/epa_build/setup; source setup_msys_makefiles ; popd
    
    to set up all necessary environment variables for this platform.  Then run
    
    bash.exe-3.1$ ${EPA_BUILD_SOURCE_PATH}/../../scripts/comprehensive_test.sh --prefix comprehensive_test_disposable --generator_string "MSYS Makefiles" --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -DENABLE_cxx=ON -DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON" --build_command make --ctest_command ctest --do_nondynamic no --do_static no --do_test_noninteractive no --do_ctest no --do_test_install_tree no --do_test_traditional_install_tree no
    
    These script options mean the results are limited to the wxwidgets components
    of PLplot, and to speed the test (for now) just interactive testing is
    done for just the shared libraries case and just the build tree.
    
    The test_interactive target failed in the build tree, and
    comprehensive_test_disposable/shared/interactive/output_tree/make_interactive.out
    showed there were no more "cannot convert" LPCTSTR
    LPCWSTR issues, but also showed the following issue:
    
    z:/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp: In constructor 'Rand::Rand()':
    z:/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp:640:25: error: 'rand_s' was not declared in this scope
    
    I followed up by attempting to build the simple rand_s example given at
    <https://msdn.microsoft.com/en-us/library/sxtz2fa8.aspx>, but that failed
    with similar errors.  The above line was actually in code that worked for
    Phil Rosenberg on the MSVC platform just before the PLplot-5.12.0 release,
    and I suspect it still works for that platform, but perhaps g++ is much more
    stringent about scoping issues?  Anyhow, we may need some C++ scoping expertise
    (which I don't have) to sort out this issue.
    
    N.B. Further tests on MSVC and MinGW-w64/MSYS2 are requested, and I currently
    predict the former will work, and the latter will run into the above scoping
    issue detected by g++.

M	cmake/modules/FindwxWidgets.cmake
M	cmake/modules/wxwidgets.cmake

commit 256026d08eed2433e97c5299578627ff58193927
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Jun 25 22:45:25 2017 -0700

    epa_build: Update so that it works with my latest combination of Wine/MinGW/MSYS, python, and cmake.
    
    The Wine version is Wine Staging 2.10 from the winehq alternative Debian Jessie repository
    (via installing the winehq-staging and wine-staging-dev packages).
    
    The MinGW/MSYS version is my ancient (4.7.2) snapshot of MinGW/MSYS that was pretty
    reliable three years ago.  (I currently use this version because my preferred free software
    distribution for Windows, MinGW-w64/MSYS2, does not work on Wine.)
    
    Python is version 3.5 (since 3.6 has the issue <https://bugs.python.org/issue30186> which
    causes issues for Windows systems that are not Windows 8 or later [such as Wine]).
    
    CMake is version 3.8.2 for Windows downloaded from Kitware.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Windows
    (Wine Staging 2.10) by a successful epa_build of wxwidgets.

M	cmake/epa_build/CMakeLists.txt
M	cmake/epa_build/README
M	cmake/epa_build/setup/setup_mingw_msys_wine_toolchain
M	cmake/epa_build/setup/setup_msys_makefiles

commit 74ff386910b854e81d46e8a43caa477ce3a70133
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Jun 25 22:24:42 2017 -0700

    epa_build: Update ExternalProject.cmake to official 3.8.2 version
    
    This means those using anywhere from 3.6.2 and upward will be using
    the 3.8.2 version for their epa_build.  This solves the substantial
    number of cmake-3.8.2 developer warnings that were obtained for the
    previous adopted version of ExternalProject.cmake.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Windows
    (Wine Staging 2.10 from the winehq-staging and wine-staging-dev
    packages available for Debian Jessie from the winehq.org Debian
    repository) by a successful epa_build of wxwidgets.

M	cmake/epa_build/ExternalProject.cmake

commit 18869733fd32d00ed9ab3ac5bad997c4594b8be9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Jun 22 19:32:48 2017 -0700

    Update minimum CMake version to 3.6.2 everywhere in source tree (other than epa_build projects)
    
    This version of 3.6.2 was chosen to be consistent with the overall PLplot minimum cmake version.
    
    The source tree locations that needed changing were found as follows:
    
    find . -type f |grep -v .git |xargs grep -i cmake_minimum_required |grep -v 3.6.2 |grep -v epa_build |grep -v CMAKE_VERSION
    
    i.e., find all source tree locations (other than epa_build ones) where cmake_minimum_required is used, but where 3.6.2 or CMAKE_VERSION are not used.  After this change, the above command yielded no results.

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

commit abe9028d4b93e92a4787f885058a0bd74bb5b87e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Jun 22 19:11:31 2017 -0700

    Build system: Ada: Fix multiple issues when a space is in the source, build, or install tree prefixes
    
    These issues included appropriately quoting fullpaths in
    CMAKE_MODULE_PATH, the fundamental CMake language support files for
    Ada, and Ada link flags.
    
    Also, the minimum CMake version was bumped from 3.0.2 to 3.6.2 in the
    language support files to be consistent with the minimum CMake version
    adopted for the PLplot project.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running
    
    scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ada=ON" --do_test_interactive no --prefix "../comprehensive_test_disposeable blank"
    
    (note the space in the build and install-tree prefixes) from a source
    tree (e.g., /home/software/plplot/HEAD/plplot\ blank\ .git/cmake/test_ada)
    with a space in the prefix.
    
    The (good) results of this script run were checked as follows:
    
    # 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

M	CMakeLists.txt
M	cmake/modules/language_support.cmake
M	cmake/modules/language_support/cmake/CMakeDetermineAdaCompiler.cmake
M	cmake/modules/language_support/cmake/CMakeTestAdaCompiler.cmake
M	examples/CMakeLists.txt
M	examples/ada/CMakeLists.txt
M	examples/ada/Makefile.examples.in

commit 96ff2990d06029dd59198e433e99388c48199efe
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Jun 22 18:51:30 2017 -0700

    test_ada project: Fix multiple issues when a space is in the source, build, or install tree prefixes
    
    These "space" issue fixes are for the Ada language support files, the
    build system, and the comprehensive test script for the test_ada project.
    Equivalent fixes for the PLplot project are the next order of business.
    
    Also bump minimum CMake version for the test_ada project from 3.0.2 to 3.6.2
    to be consistent with the PLplot project.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running
    
    scripts/comprehensive_test.sh --prefix "/home/software/plplot/HEAD/plplot blank .git/cmake/test_ada/../../../comprehensive_test_ada_disposeable blank"
    
    (note the space in the build and install-tree prefixes).
    
    from a source tree (e.g., /home/software/plplot/HEAD/plplot blank .git/cmake/test_ada)
    with a space in the prefix.  The command
    
    grep -i error ../../../comprehensive_test_ada_disposeable\ blank/*/*/output_tree/*.out
    
    showed no issues.  Also, the files comprehensive_test.sh.out,
    comprehensive_test_env.out, comprehensive_test.tar.gz,
    comprehensive_test_listing.out, shared/noninteractive/build_tree/install_manifest.txt ,
    and static/noninteractive/build_tree/install_manifest.txt in
    ../../../comprehensive_test_ada_disposeable\ blank all appeared to be
    populated correctly.

M	cmake/test_ada/CMakeLists.txt
M	cmake/test_ada/cmake/Modules/CMakeDetermineAdaCompiler.cmake
M	cmake/test_ada/cmake/Modules/CMakeTestAdaCompiler.cmake
M	cmake/test_ada/installed_CMakeLists.txt
M	cmake/test_ada/scripts/comprehensive_test.sh
M	cmake/test_ada/src_executable/CMakeLists.txt

commit 2bc0626f42423bad565d92858147dccad1c8d9e9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jun 20 17:00:28 2017 -0700

    IPC for wxwidgets: Reenable the PL_WXWIDGETS_IPC3 option
    
    Previously this build system option had been disabled by forcing
    PL_WXWIDGETS_IPC3 to ON with no associated code changes.  So
    reenabling this option requires only a minor build system change.
    This change should temporarily allow users to compare the new 3
    semaphores IPC approach (using -DPL_WXWIDGETS_IPC3=ON which is also
    the default case and which was the forced case for the last few
    months) with the previous one semaphore IPC + circular buffer approach
    (using -DPL_WXWIDGETS_IPC3=OFF).  However, once those tests are
    completed successfully on all platforms the intention is to purge the
    one semaphore IPC + circular buffer approach completely.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by setting the -DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON
    cmake option and setting either the -DPL_WXWIDGETS_IPC3=ON or
    -DPL_WXWIDGETS_IPC3=OFF cmake option and for each of those two cases
    building the test_c_wxwidgets target.
    
    N.B. platforms that use a native Windows approach such as MSVC or MinGW-w64/MSYS2
    also should be tested with both -DPL_WXWIDGETS_IPC3=ON and
    -DPL_WXWIDGETS_IPC3=OFF

M	cmake/modules/wxwidgets.cmake

commit e07d5e5c315c389e16063b4969fcf55572364406
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jun 20 16:57:58 2017 -0700

    IPC for wxwidgets: Purge PL_HAVE_UNNAMED_POSIX_SEMAPHORES
    
    This change purges all references to PL_HAVE_UNNAMED_POSIX_SEMAPHORES
    and associated code stanzas in the source tree in an effort to help
    simplify that tree.  However, this change should have no practical
    effect on users and developers who are following the git version of
    PLplot since the PL_HAVE_UNNAMED_POSIX_SEMAPHORES option has been
    permanently disabled for some time now.
    
    The motivation for that disablement (and purge now) is because
    although the unnamed semaphores version of the PL_WXWIDGETS_IPC3
    version of our code worked on Linux, not all POSIX systems provide
    access to unnamed semaphores and the corresponding named semaphores
    approach works with the PL_WXWIDGETS_IPC3 version of our code on all
    POSIX systems including Linux.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by setting the -DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON
    cmake option and building the test_c_wxwidgets target.

M	cmake/modules/wxwidgets.cmake
M	drivers/wxwidgets_comms.cpp
M	drivers/wxwidgets_comms.h
M	drivers/wxwidgets_dev.cpp
M	plplot_config.h.in
M	utils/wxplframe.cpp

commit 2faff23b180ba73b362ebe72e1b57b3eb1cea981
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jun 20 16:00:39 2017 -0700

    IPC for wxwidgets: Fix use of WIN32 and PL_WXWIDGETS_IPC3 preprocessor macros
    
    Fix an obvious issue concerning one instance of how WIN32 and
    PL_WXWIDGETS_IPC3 preprocessor code stanzas are nested together.  This
    should likely cure a build bug for IPC that was discovered by Arjen
    Markus for the MinGW-w64/MSYS2 platform.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by setting the -DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON
    cmake option and building the test_c_wxwidgets target.
    
    N.B. This procedure merely tests that this IPC code fix does not
    interfere with the previously good -dev wxwidgets results on Linux,
    and further testing is obviously required for native Windows platforms
    such as MSVC and MinGW-w64/MSYS2.

M	drivers/wxwidgets_comms.h

commit 8fd52f8709c103fd1950509288756583f21010a9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Jun 20 13:48:36 2017 -0700

    Build System: Implement the PAUSE_CERTAIN_INTERACTIVE_DEVICES option
    
    This experimental option defaults to OFF, but if the user specifies
    -DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON, then for the wingcc and
    wxwidgets devices the -np option is not used for test targets, e.g.,
    test_c_wingcc and test_c_wxwidgets.  The reason these two devices are
    singled out for this experimental treatment is that they have an issue
    of only plotting a blank screen when -np is specified.  So until that
    issue for these devices is fixed (i.e., they plot the actual plot
    rather than a blank screen when -np is specified), this experimental
    -DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON CMake option has been
    implemented to drop the -np option for tests of these devices.  The
    result is the plots are rendered properly for tests of these devices
    at the expense of much additional user interaction (e.g., hitting the
    enter key to get through the plot pages for each example that is run).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by specifying the CMake option
    -DPAUSE_CERTAIN_INTERACTIVE_DEVICES=ON and building the
    test_c_wxwidgets target (which as expected displayed all plots
    properly without the -np option at the expense of much more
    interaction to get through the plots) and test_c_xcairo target (which
    as expected displayed all plots properly with the -np option so no
    interaction was required to get through the plots).

M	cmake/modules/plplot.cmake
M	plplot_test/test_c_interactive.sh.in

commit 59344dc51a25c51009b13e92c6ba0514b4ef95b8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Jun 15 14:57:24 2017 -0700

    Update FindwxWidgets.cmake to version v3.9.0-rc3
    
    This change means all our CMake users regardless of the cmake version
    they are using will effectively be using the official CMake version of
    this find module from CMake-3.9.0-rc3.
    
    Note this is exactly the official version except for the following
    change (which is necessary for local versions of find modules)
    
    software@raven> diff -au ~/cmake/cmake.git/Modules/FindwxWidgets.cmake cmake/modules/FindwxWidgets.cmake
    --- /home/software/cmake/cmake.git/Modules/FindwxWidgets.cmake  2017-06-15 14:48:31.338368008 -0700
    +++ cmake/modules/FindwxWidgets.cmake   2017-06-15 14:53:49.233142629 -0700
    @@ -948,7 +948,7 @@
     #=====================================================================
     #=====================================================================
    
    -include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
    +include(FindPackageHandleStandardArgs)
    
     find_package_handle_standard_args(wxWidgets
       REQUIRED_VARS wxWidgets_LIBRARIES wxWidgets_INCLUDE_DIRS

M	cmake/modules/FindwxWidgets.cmake

commit 45fdd538c32e2dc2cf0119873a585e5bee65c57a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed May 24 17:22:13 2017 -0700

    Update OCaml binding and examples to eliminate example 8 inconsistencies with C version
    
    This change was implemented as follows:
    
    * Edit plplot_h and touchup.ml to add plsurf3dl (and plot3dcl) to
      the OCaml API.
    
    * Generate plplot_h.inc in the way described in the README file.
    
    * Edit plplot.mli to add descriptions of the OCaml module interface definitions
     of plsurf3dl (and plot3dcl).
    
    * Update CMakeLists.txt to fix a dependency bug so that a change of
      an example regenerates the build of that example.
    
    * Update x08.ml to make OCaml results for this example equivalent to
      the corresponding C results.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_diff_psc target whose
    summary of PostScript differences is now reduced to
    
    ocaml
      Missing examples            :
      Differing graphical output  :  16 19 33
      Missing stdout              :
      Differing stdout
    
    i.e., the long-standing example 8 differences have now been
    fixed!

M	bindings/ocaml/README
M	bindings/ocaml/plplot.mli
M	bindings/ocaml/plplot_h
M	bindings/ocaml/plplot_h.inc
M	bindings/ocaml/touchup.ml
M	examples/ocaml/CMakeLists.txt
M	examples/ocaml/x08.ml

commit 58c4ed30414460d6956c294769b595a6a8d1add8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon May 22 16:41:31 2017 -0700

    ocaml binding: drop special handling of plhist array argument
    
    The generic rules in touchup.ml appear to work well for plline (which
    has similar array arguments as plhist) so I tried using those generic rules for
    touching up the plhist arguments, and the result is different, i.e.,
    
    -[mlname(plhist)] void c_plhist ( int n, [in, size_is(n), size_is(n)] double * data, double datmin, double datmax, int nbin, plplot_hist_style opt );
    +[mlname(plhist)] void c_plhist ( int n, [in, size_is(n)] double * data, double datmin, double datmax, int nbin, plplot_hist_style opt );
    
    with the extra size_is(n) removed, but I think that is likely a good
    thing.  (In fact, I don't understand how the interface to plhist
    worked before.)  So this simplifying commit is a small step in the direction
    of understanding what is needed to generate the ocaml binding.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by using the DGENERATE_PLPLOT_H_INC=ON option, building
    the check_plplot_h.inc target to check that plplot_h.inc is consistent
    with touchup.ml, and building
    the test_diff_psc target which generated
    the (long-standing) PostScript difference result:
    
    ocaml
      Missing examples            :
      Differing graphical output  :  08 16 19 33
      Missing stdout              :
      Differing stdout            :
    
    That is, this change to plhist introduced no differences in example 5
    (the only example that uses plhist).

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

commit e2ac60c1354d0203a732eca5b674b671a6d6d58b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun May 21 17:40:02 2017 -0700

    Build system: Fix "space in full pathname" and other bugs for the static OCaml binding and examples
    
    The fundamental issues I solved for the static library case were as
    follows:
    
    * Specify the properly quoted and escaped build-tree locations and
      install-tree locations for respectively the build-tree and
      install-tree ocaml bindings.
    
    * Specify the plplot library, other internal libraries, and external
      libraries in exactly that order for the OCaml linking flags (because
      order matters for static linking).
    
    * Use the same set of (build-tree or install-tree as appropriate)
      OCaml link flags for all ocaml build commands (ocamlmklib, ocamlc
      -a, and ocamlopt -a) that use those flags.
    
    Some minor issues I solved were as follows:
    
    * The previously used <libname>_LIB_DEPENDS variables have been
      replaced by the corresponding INTERFACE_LINK_LIBRARIES target
      property for each relevant internal library.  This is a substantial
      improvement in approach because the <libname>_LIB_DEPENDS variables
      are now strongly deprecated.
    
    * The target name for the plplot library is plplot and no longer
      plplotd (!)
    
    * Added C++ libraries that are typically used by C++ compilers to the
      OCaml link flags.
    
    * Properly handled Qt5 (and Qt4 as before) libraries.
    
    * Our build system now necessarily generates both dllplplot_stubs.so
      (to be used in the build tree) and dllinstalled_plplot_stubs.so
      (installed in renamed form in the install tree and used there); both
      these shared objects have insoluble rpath issues (see
      bindings/ocaml/CMakeLists.txt commentary about this issue), so
      scripts/comprehensive_test.sh had to be adjusted to ignore both of
      these files when looking for ldd issues.
    
    * The value of the qt_gui_true CMake variable (which controls whether
      the qt_example application is built or not in the traditional build
      of the installed examples) is set depending on the correct PLD_extqt
      variable rather than the incorrect ENABLE_qt variable.
    
    * Many minor dependency fixups.
    
    As a result of these changes the combination of static PLplot and
    ocaml bindings appears to work well on Linux for all of our major
    configurations (see test results below) so the former
    ENABLE_ocaml_static experimental option has now been dropped.  The
    result is the ocaml binding and examples are now always built for the
    static case.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_diff_psc target for the static
    libraries case and with all default bindings and device drivers
    enabled, and with all 4 possible combinations of FORCE_OCAMLC and PLPLOT_USE_QT
    option values.  For this case, the internal and especially external library
    dependencies of libplplot are at their most complex, and therefore
    tests our processing of those libraries into the ocaml_LIBRARIES_FLAGS
    list of OCaml build tool options to a
    substantial degree.  These tests
    were a complete success for all 4 cases showing our processing of the libraries
    for the ocaml case has no known issues for this complex case.
    For the record the usual ocaml PostScript difference results, e.g.,
    
    ocaml
      Missing examples            :
      Differing graphical output  :  08 16 19 33
      Missing stdout              :
      Differing stdout            :
    
    were obtained for all 4 cases.  These OCaml issues are long-standing
    ones for the shared and nondynamic cases so do not represent a
    regression from those results for the static case.
    
    I also tested all our major configurations for a limited external libraries case by running
    
    scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DPLD_svgqt=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ocaml=ON -DFORCE_OCAMLC=OFF -DPLPLOT_USE_QT5=OFF" --do_test_interactive no --prefix "../comprehensive_test_disposeable blank"
    
    scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DPLD_svgqt=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ocaml=ON -DFORCE_OCAMLC=ON -DPLPLOT_USE_QT5=OFF" --do_test_interactive no --prefix "../comprehensive_test_disposeable blank"
    
    scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DPLD_svgqt=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ocaml=ON -DFORCE_OCAMLC=OFF -DPLPLOT_USE_QT5=ON" --do_test_interactive no --prefix "../comprehensive_test_disposeable blank"
    
    scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DPLD_svgqt=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ocaml=ON -DFORCE_OCAMLC=ON -DPLPLOT_USE_QT5=ON" --do_test_interactive no --prefix "../comprehensive_test_disposeable blank"
    
    from a source tree with a space in the prefix.  That condition plus
    the above --prefix option insures these four tests were carried out
    with source, build, and install tree having a space in their prefixes.
    
    These four script runs were a success as measured by the following commands:
    
    # 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
    
    In the latter case the result (12 times now since the 4 tests for the
    static case are now added to the previous 8 tests that worked) for the
    PostScript differences was the same as above.  These OCaml issues are
    long-standing ones so these results do not represent a regression for
    any of our previous shared or nondynamic OCaml results,
    and also show the new static configuration results agree
    with the previous shared and nondynamic results.

M	bindings/ocaml/CMakeLists.txt
M	cmake/modules/ocaml.cmake
M	cmake/modules/qt.cmake
M	scripts/comprehensive_test.sh

commit 16bff2a70b57df37c031afa8ed58536530a935f3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue May 9 15:07:45 2017 -0700

    Build system: Fix "space in full pathname" bug for the check_plplot_h.inc target
    
    This target checks the consistency of the OCaml source code files.
    For the previous release 5.12.0, I thought I had discovered a bug in
    this target so I dropped the dependency of the check_all target on
    this target.  However, that "no space" bug was a false alarm which
    could be solved by installing the libpcre-ocaml-dev Debian package.
    Therefore, in this commit I reinstated that dependency.  However, that
    still left a bug for the case where either/both the source tree or
    build tree prefix contains a space.  This commit fixes that issue by
    copying touchup.ml (the file that is executed by the ocaml
    application) from the source to build tree so a relative pathname can
    be used in the build tree, and by using a relative pathname for the
    result file.  However, it turned out that the plplot_h input file for
    the touchup.ml Ocaml application could be accessed with full source
    tree path in quoted and escaped form so that is what I did.  But why
    these inconsistencies in what is allowed for "spaced" pathnames or
    not?
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by configuring PLplot from a source tree with
    spaces in its prefix using a build tree with
    spaces in its prefix as follows:
    
    cmake "-DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake blank" -DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ocaml=ON -DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DGENERATE_PLPLOT_H_INC=ON "../plplot blank .git" >& cmake.out
    
    (the GENERATE_PLPLOT_H_INC option allows the check_plplot_h.inc target to be built.)
    That was followed by a successful build of the check_plplot_h.inc target
    
    This target checks the consistency of the OCaml source code files.
    For the previous release 5.12.0, I thought I had discovered a bug in
    this target so I dropped the dependency of the check_all target on
    this target.  However, that "no space" bug was a false alarm which
    could be solved by installing the libpcre-ocaml-dev Debian package.
    Therefore, in this commit I reinstated that dependency.  However, that
    still left a bug for the case where either/both the source tree or
    build tree prefix contains a space.  This commit fixes that issue by
    copying touchup.ml (the file that is executed by the ocaml
    application) from the source to build tree so a relative pathname can
    be used in the build tree, and by using a relative pathname for the
    result file.  However, it turned out that the plplot_h input file for
    the touchup.ml Ocaml application could be accessed with full source
    tree path in quoted and escaped form so that is what I did.  But why
    these inconsistencies in what is allowed for "spaced" pathnames or
    not?
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by configuring PLplot from a source tree with
    
    cmake "-DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake blank" -DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ocaml=ON -DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DGENERATE_PLPLOT_H_INC=ON "../plplot blank .git" >& cmake.out
    
    That configuration of the PLplot build was followed by a successful build of the
    check_plplot_h.inc target, i.e.,
    
    make check_plplot_h.inc
    
    Note the prefixes of the source and build trees (and also the install
    tree but that is irrelevant for this particular test) contained spaces
    for this successful test.

M	bindings/ocaml/CMakeLists.txt

commit a3bf0e64e00cf0ef6a534687564cce481be06ffd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon May 8 20:08:29 2017 -0700

    Build system: Fix "space in full pathname" bugs for the OCaml binding and examples
    
    These fixes consisted of quoting some strings with embedded blanks and
    quoting other strings with embedded escaped blanks.  (Some OCaml build tool
    options demanded the one form, others the other form.)
    
    I also fixed some minor dependency and "clean" build-system issues for the
    OCaml binding and examples.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running
    
    scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ocaml=ON" --do_test_interactive no --prefix "../comprehensive_test_disposeable blank"
    
    and
    
    scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ocaml=ON -DFORCE_OCAMLC=ON" --do_test_interactive no --prefix "../comprehensive_test_disposeable blank"
    
    from a source tree with a space in the prefix.  That condition plus
    the above --prefix option insures these two tests (one with
    FORCE_OCAMLC false and one with that value true) were carried out with
    source, build, and install tree having a space in their prefixes.
    
    These script runs were a success as measured by the following commands:
    
    # 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
    
    In the latter case the result (8 times with ocaml automatically skipped for the static case) was
    
    ocaml
      Missing examples            :
      Differing graphical output  :  08 16 19 33
      Missing stdout              :
      Differing stdout            :
    
    but those OCaml issues are long-standing ones so these results do
    not represent a regression when there is a space in all of the
    above prefixes.

M	bindings/ocaml/CMakeLists.txt
M	examples/ocaml/CMakeLists.txt
M	examples/ocaml/Makefile.examples.in

commit 8476003851d017cf08e18333ecc575435da61cc6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu May 4 22:47:52 2017 -0700

    Build system: simplify/eliminate messages generated by long-term disablement of PLplot OCaml Cairo support
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by examining warning messages generated by cmake that
    are associated with the disabled OCaml Cairo component of PLplot.

M	cmake/modules/ocaml.cmake

commit 4295d9bfda1be124979941e4e05b8956f0fa86a3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu May 4 17:08:02 2017 -0700

    Build system: Fix Java-related "space in full pathname" bugs
    
    These Java related issues that were fixed showed up when testing of
    source, build, and install trees which all contained spaces in their
    full pathnames.
    
    Most of these fixes involved simply quoting variables appropriately,
    but one necessary fix was rather curious which was to supply the
    PLPLOT_JAVA_WRAP_DIR variable (the location of the dll wrapper
    generated by swig that interfaces between the Java language and
    PLplot) for the installed case.  With no spaces in the install tree
    full pathname (the mode always tested before) this setting was not required for the
    installed case at all.  So I presume this explicit setting is required
    to work around a Java bug where it cannot find its shared object
    wrapper as normal if the location of that object is in a directory
    with spaces in the fullpath name.
    
    N.B. This change has not been tested on any Windows platform yet, and
    since dll locations are different on such platforms, I am virtually
    positive that all of plplot_test/test_java.sh.in,
    plplot_test/CMakeLists.txt, examples/Makefile.examples.in, and
    examples/CMakeLists.txt files (the only files where some mention of
    PLPLOT_JAVA_WRAP_DIR occurs now in our source tree) should be looked
    at to see what changes need to be made for the various Windows
    platforms.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running
    
    scripts/comprehensive_test.sh --cmake_added_options "-DENABLE_ada=OFF -DENABLE_d=OFF -DENABLE_ocaml=OFF" --do_test_interactive no --prefix "../comprehensive_test_disposeable blank"
    
    from a symlink to my local PLplot git repository that has at least one
    space in all full pathnames.  So because of the --prefix option above
    with a space in the prefix, this is a comprehensive test on a fully
    loaded Linux platform of cases (1), (2), and (3) where all files of
    respectively the source, build, and install trees have a space in the
    full pathname.
    
    Caveats for this comprehensive test:
    
    * Cases (1), (2), and (3) are only comprehensively tested for the
      noninteractive components of PLplot and for only the components that
      occur for a fully-loaded Linux system.  So to insure safety for
      these cases the above noninteractive test for these combined cases
      needs to be repeated on Mac OS X, and the various Windows platforms.
      And a follow up using an interactive comprehensive test for these
      combined cases needs to be done on all platforms.
    
    * Case (4) is defined as the case where a blank occurs in the full
      pathname of _all_ external libraries [e.g., the QT5 suite of
      libraries], and executables [e.g., pkg-config] required by PLplot.
      This case is not tested yet!
    
      (One could do this test pretty straightforwardly on either Cygwin or
      MinGW-w64/MSYS2 platforms by installing the whole platform (which
      contains virtually all the external libraries and executables used
      by PLplot) in a prefix area with a space in the name.  I would
      recommend testing this case this way on both the mentioned platforms
      because they are so different with Cygwin being fundamentally POSIX
      compatible and MinGW-w64/MSYS2 being fundamentally compatible
      instead with native Windows.)  Because of those fundamental differences
      tests on these two platforms complement each other.
    
    * Case (5) (which is where a blank occurs in the full pathname of
      fundamental system libraries such as the C library) is difficult to
      test on Linux, but is likely not an issue since this case surely has
      already occurred on some Windows platforms.
    
    * Ada, D, and OCaml were dropped from the above test because of known
      "space in full pathname" issues with PLplot's implementation of
      CMake support for these three languages.  Sorting out these issues
      is difficult (because sorting out bugs in language support is
      difficult) but is on my future agenda.
    
    The following commands were used to determine the above comprehensive test
    was a complete success:
    
    # 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

M	examples/CMakeLists.txt
M	examples/Makefile.examples.in
M	examples/java/Makefile.examples.in
M	examples/plplot_configure.cmake_installed_examples.in
M	plplot_test/CMakeLists.txt
M	plplot_test/test_java.sh.in

commit 03fd013563d8ee87d8007d0a3ba259bd282b164e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu May 4 15:40:08 2017 -0700

    Comprehensive test script: Fix additional whitespace bugs and allow the --prefix option to be relative
    
    The bug fixes were to put quotes around all references to the $PATH
    variable (since that environment variable can have whitespace in it
    which is rare on Linux but fairly common on Windows) and also put
    quotes around all use of the pwd command output.
    
    The --prefix option change was to allow the user to specify either an
    absolute prefix or a relative (to the directory where the script
    invocation occurs) prefix.  The trick is in all cases to convert the
    prefix variable (just as soon as it is completely determined by the
    script) to absolute form so the rest of the script can continue to use
    this prefix variable in an absolute form as previously.
    
    In addition, I quoted all directory locations that are echoed;
    collected additional Java, Ada, D, and PWD environment variables;
    systematically processed all environment variable collection using
    printenv output (to assure it was an environment variable being set
    rather than an ordinary variable); summarized which environment
    variables were collected in the environment variable log file,
    processed the further input to that file with sed so that everything
    to the right of the "=" sign is quoted (useful for display of all
    path-related information and compiler flags); and fixed a minor issue
    (a double space rather than single space to separate components of the
    command) with use of the dashboard_option variable.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) using a constrained comprehensive test.  Details of
    those constraints to follow in a subsequent commit message for the
    rest of the file changes that were tested.

M	scripts/comprehensive_test.sh

commit f432893418ff29abde8fa2dab8a8c1c4ec630620
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed May 3 16:34:56 2017 -0700

    Fix "spaces in full pathname" issues with the test_tcl_psc target
    
    The fundamental fix done here was to replace some complex bash
    logic to escape spaces in some (but not all) of the pathnames by
    simply quoting all relevant pathnames.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_tcl_psc target without
    run-time issues for a source tree and build tree which both
    had spaces in their full pathnames.
    
    N.B. Some of these logic changes are Windows only so need additional testing
    on _all_ Windows platforms.

M	plplot_test/test_tcl.sh.in

commit d9fffdda14d714de3f52d1d5db5bf24e0664a957
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed May 3 14:21:00 2017 -0700

    Comprehensive test script: Fix "Blank in pathname" bugs
    
    These fixes consisted almost entirely of quoting variables that
    contained full pathnames.  In addition, the ldd-relevant find ... xargs
    commands were changed to deal with possible blanks in path names.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running
    
    scripts/comprehensive_test.sh --cmake_added_options "-DENABLE_ada=OFF -DENABLE_d=OFF -DENABLE_ocaml=OFF" --do_test_interactive no --do_ctest no --do_test_build_tree no
    
    from the "plplot blank .git" directory symlink to the "plplot.git"
    working directory of my local git repository for PLplot.  So this only
    tested the case of running this script from a source tree with blanks
    in the full pathname.  I also (as a result of fixing the ldd-related
    issue that showed up after the first build-tree test for the shared
    case) dropped the build tree tests from these results.  But a later
    test I have planned with --prefix set to a pathname with blanks should
    eventually cover this part of the comprehensive tests as well as any
    remaining issues with build tree or install tree with blanks in the
    full pathname.
    
    Ada, D, and OCaml were dropped from this test because of known "blank in full pathname" issues for
    our CMake language support for those languages.  (I plan to address those issues later.)
    
    N.B. Even the planned test with prefix with blanks in the full
    pathname does not check for the case where system libraries needed by
    PLplot have blanks in their full pathname (a common issue for the Windows
    platform).  So that issue will have to be tested separately (for example,
    on a Cygwin, MinGW-w64/MSYS2, or Linux epa_build platform where the installation
    prefix for all external libraries used by PLplot is deliberately designed
    to have a blank in the full pathname).
    
    Keeping in mind all these limitations on the current test, nevertheless, the
    above test did produce a successful result as measured by
    
    grep -i warning ../comprehensive_test_disposeable/*/*/output_tree/*.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout'
    
    grep -i error ../comprehensive_test_disposeable/*/*/output_tree/*.out
    
    grep -iE 'found|symbol|undefined' $(find ../comprehensive_test_disposeable -name "build*ldd.out")
    
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable/*/*/output_tree/*.out |less

M	scripts/comprehensive_test.sh

commit 7f1f5ce1039b8d6ac06770c8c0b5198a4173556d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Apr 29 15:17:25 2017 -0700

    Build system: Output sip version
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by looking at cmake output.

M	cmake/modules/qt.cmake

commit 7653e24e49eba1742faf26604f55ffea68da9082
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Apr 29 13:55:59 2017 -0700

    Build system: Make Python 3 the default choice
    
    It makes general sense to me that Python developers far prefer to work
    on Python 3 rather than the legacy Python 2 so any Python-2 only bugs
    left in the latter are likely not going to be addressed.  That general
    sense was confirmed in a recent discussion I had with a Python
    developer concerning the intermittent corruption of the
    python-generated file, bindings/python/Plframe.pyc _in the source
    tree_ that I was experiencing with Python 2.  His strong advice was to
    attempt to replicate the problem with Python 3 since that is very
    likely the only version the Python developers would be willing to find
    a fix for.
    
    Also, Python 3 now generally works for us.  Accordingly I am making it
    the default choice when both Python 3 and Python 2 are available on
    the system with a fallback to Python 2 if that is the only version
    available on the system.  but I am allowing users to override that
    behaviour if they specify -DFORCE_PYTHON2=ON (which does what its name
    implies which is to only look for a Python 2 version).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie with both Python 2 and 3 installed) by running CMake
    with and without -DFORCE_PYTHON2=ON and observing the correct results
    on what Python version (and consistent Python library and numpy with
    that version) that were found.

M	cmake/modules/python.cmake

commit 4508ccb23de4dece957d533b1586d6a6c90553ab
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Apr 25 11:25:53 2017 -0700

    Build system: Use official CMake swig support rather than our own
    
    Our own swig support (the FindSWIG.cmake and UseSwig.cmake that have
    been removed by this commit) was extraordinarily dated (these files
    started life as individually recommended versions from the CMake bug
    tracker a decade ago).  And this dated support caused the recently
    discovered contamination of _plplotc rules by _Pltk_init that did
    not occur for the official versions.  So this commit avoids
    that issue by moving to official CMake support for swig.
    
    That move did cause a build issue for our Lua binding just for
    CMake-3.0.2 that did not occur for CMake-3.6.2 and above.  That issue
    was (indirectly) addressed by the previous commit to bump our minimum
    version of CMake from 3.0.2 to 3.6.2.
    
    That move also changed the naming convention for the resulting Java
    dll (which caused run-time errors because the differently named dll
    could not be found) so this commit also addresses that changed naming
    convention as well.
    
    Tested by: Alan W. Irwin (airwin@users.sourceforge.net) on Linux
    (Debian Jessie) by running a comprehensive test of all interactive
    and noninteractive components of PLplot that are available on this
    platform, i.e.,
    
    scripts/comprehensive_test.sh --cmake_command ~/cmake/install-3.6.2/bin/cmake --do_submit_dashboard yes)
    
    where ~/cmake/install-3.6.2/bin/cmake refers to a cmake-3.6.2 version
    that I built myself using my normal bootstrap method (to check that
    our newly adopted minimum version of CMake passes all comprehensive
    tests on this platform).  Also, --do_submit_dashboard yes does what it
    says.
    
    The dashboard results showed no error issues at all (see those good dashboard results at
    <http://my.cdash.org/index.php?project=PLplot_git&date=2017-04-24>).  Also the CMake warnings
    for that report simply reflect the number of times "warning" appears in our CMake output and
    does not truly reflect official CMake warnings except in one case concerning OCaml support
    for a badly maintained feature which we will likely take care of in future by removing
    that feature.
    
    The above comprehensive test was analyzed with the following commands:
    
    grep -i warning ../comprehensive_test_disposeable/*/*/output_tree/*.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout'
    
    grep -i error ../comprehensive_test_disposeable/*/*/output_tree/*.out
    
    grep -iE 'found|symbol|undefined' $(find ../comprehensive_test_disposeable -name "build*ldd.out")
    
    No issues were found other than the long-known OCaml PostScript
    differences found (again) by that last grep command.

M	bindings/java/CMakeLists.txt
D	cmake/modules/FindSWIG.cmake
D	cmake/modules/UseSWIG.cmake
M	cmake/modules/java.cmake

commit f0610cdf5879ce2d7727f8d865d4523ebc501c78
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Apr 25 11:24:01 2017 -0700

    Bump the minimum version of CMake from 3.0.2 to 3.6.2 for the Linux platform
    
    Normally I keep this minimum version consistent with the version of
    CMake provided by Debian stable, i.e., I only bump this minimum
    version whenever a new Debian stable is released in an effort to
    specify a minimum version of CMake that is provided by a binary
    package on most Linux software distributions.  However, in this case I
    am jumping the gun a bit. (Debian Stretch which currently provides
    CMake-3.7.2 will likely be released as Debian stable this year, but
    that has not happened yet).  Also, I have bumped to 3.6.2 rather than
    3.7.2 because the minimum version of Linux should not exceed the
    minimum version adopted for non-Linux platforms (currently 3.6.2).
    
    Note that Cygwin only provides CMake 3.6.2 at this time as a binary
    package (as opposed to MinGW-w64/MSYS2 that provides CMake-3.7.2).  I
    plan to review the CMake minimum versions we adopt for both Linux and
    non-Linux platforms again once Cygwin provides CMake-3.7.2 or beyond.
    
    Note, the reason why I am bumping the Linux version now is older
    CMake-3.x.y versions tend to have a lot of bugs compared to CMake-3.6
    and beyond.  The file generate permissions problem is one of those we
    worked around, and versions just after 3.0.2 provided even more bugs
    (in that case with find modules) so we warned users to avoid all CMake
    versions from 3.2 through 3.3.1.
    
    I recently discovered one more issue with CMake-3.0.2 (the official
    UseSWIG.cmake for that version of CMake caused a build error for our
    Lua bindings which kept us from adopting official UseSWIG.cmake
    versions).  That issue was the final straw that motivated this minimum
    version bump.  This bump means I have been able to remove some cruft
    from our build system concerning a work around for the file generate
    permissions problem bug.  (This bump also means I have been able to
    remove CMAKE_VERSION-dependent changes in our pkg-config support that
    depended on the internal details of CMake support for pkg-config that
    has changed with CMAKE_VERSION.)
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net>

M	CMakeLists.txt
M	bindings/tcl/CMakeLists.txt
M	cmake/modules/pkg-config.cmake
M	cmake/modules/plplot_functions.cmake
M	examples/CMakeLists.txt

commit f8cd3ba745975ef4c22ab1103bd43df6321f4057
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Apr 25 09:58:03 2017 -0700

    Build system: Bug fixes for installation of files related to _Pltk_init target
    
    * Fix install rpath.
    
    * Install swig-generated Pltk_init.py file.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net>

M	bindings/python/CMakeLists.txt

commit daa4b034eddded698041fc8257b204b6cca344cf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Apr 25 09:49:42 2017 -0700

    Installed examples build system:PYTHON_VERSION bug fix
    
    This fix provides PYTHON_VERSION (which is now needed to avoid CMake
    errors) for this CMake-based build system.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net>

M	examples/plplot_configure.cmake_installed_examples.in

commit f25008fa5a8e72c946970e8c7b4889bfb6e34b47
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Apr 23 17:12:28 2017 -0700

    Make all software associated with the test_pytkdemo target work properly for Python 3
    
    The changes in the bindings/python/Plframe.py and examples/python/pytkdemo Python source code
    included using parentheses for all Python print(...) statements, replacing all
    tabs with blanks (no mixed tab/blank indentation is allowed by Python 3), and replacing
    the apply command (which is deprecated in Python 2 and not present for Python 3) with
    the corresponding function call.
    
    The hand-crafted plplot_widget Python extension that was used to glue
    everything together in the pytkdemo example of using the PLplot Tcl/Tk
    code from python was unmaintable and did not work for Python 3.  I
    therefore replaced that by the swig-generated Python extension
    module Pltk_init that (because of swig) works fine for both Python 2
    and Python 3 and which provides a Python interface routine between the
    Python Pltk_init command and a ~5-line C routine that calls Pltk_Init
    from the plplottcltk library.
    
    Since plplot_widget had been replaced, I dropped all references
    to plplot_widget from our source tree (excluding historical
    files such as ChangeLogs and excluding for now some
    README files I am still working on).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_pytkdemo target with complete
    success for both the Python2 (CMake option DPython_ADDITIONAL_VERSIONS:STRING=2)
    and Python3 (CMake option DPython_ADDITIONAL_VERSIONS:STRING=3) cases.
    
    In all cases I hammered the GUI pretty hard by exercising all demos
    without issues.  There were no problems with that GUI hanging (either
    with Python 2 or Python3) on exit like occurred roughly half the time
    previously for the hand-crafted plplot_widget interface.  So this is a
    promising result which may indicate the new swig-generated interface
    provides more reliable results for Python 2 than the old hand-crafted
    interface.  But more experience will be required to validate that
    conclusion.  And, of course, the new interface and all the other
    Python 3-related changes allows the test_pytkdemo target to be built
    without errors for the very first time for Python 3.
    
    To be addressed later: One remaining issue is a peculiar contamination
    of plplotc Makefile rules by some of the _Pltk_init Makefile rules.
    The resulting run-time warning messages are
    
    bindings/python/CMakeFiles/_plplotc.dir/build.make:77: warning: overriding recipe for target 'bindings/python/Pltk_init.py'
    bindings/python/CMakeFiles/_plplotc.dir/build.make:67: warning: ignoring old recipe for target 'bindings/python/Pltk_init.py'
    bindings/python/CMakeFiles/_plplotc.dir/build.make:77: warning: overriding recipe for target 'bindings/python/Pltk_init.py'
    bindings/python/CMakeFiles/_plplotc.dir/build.make:67: warning: ignoring old recipe for target 'bindings/python/Pltk_init.py'
    
    I have proved these warnings are due to PLplot's use of special (but
    extraordinarily dated) versions of FindSWIG.cmake and UseSWIG.cmake,
    but (temporary) replacement of those with the official versions
    currently does get rid of the above warning messages but causes other
    major issues (the Lua and Java bindings don't build).  (See the
    on-going discussion of these issues in the cmake-developers mailing
    list with the subject line "On-going UseSWIG troubles with the
    official versions".

M	bindings/python/CMakeLists.txt
M	bindings/python/Plframe.py
A	bindings/python/Pltk_init.i
D	bindings/python/plplot_widget.c
M	examples/CMakeLists.txt
M	examples/python/CMakeLists.txt
M	examples/python/pytkdemo
M	include/pldll.h.in
M	scripts/style_source.sh

commit 616daf60486615bd7f37c46c272d77e16d98fad2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Apr 21 12:49:30 2017 -0700

    Build system: Temporarily remove the test_interactive target dependence on test_pyqt[45]_example targets for the Python 3 case
    
    For the Python 3 case the test_pyqt[45]_example targets currently
    don't work for unknown reasons.  So for the Python 3 case this measure
    is necessary to insure the test_interactive target continues to work.
    
    temporarily excluded from being a dependency of
    +   other more general interactive test targets

M	examples/CMakeLists.txt

commit ec484bf28711b9689a631de82837a7a39e8ae3f8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Apr 21 11:45:04 2017 -0700

    Remove trailing whitespace introduced in previous commits

M	README.release
M	bindings/python/plplot.py
M	cmake/modules/wxwidgets.cmake
M	examples/python/plplot_logo.py
M	examples/python/x22.py

commit 258db0737c5d36bf4f420c70a530158b20b962c2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Apr 21 11:17:55 2017 -0700

    Drop "module" from basenames for _plplotc and plplot_widget Python extension modules
    
    The "module" part of basenames for Python extension modules is
    optional so we removed it completely.  This change simplifies our
    build system from the previous mixed basename case where sometimes the
    basename included "module" and sometimes not depending on context.
    
    As a byproduct of this change I discovered a visibility bug for the
    plplot_widget extension module in include/pldll.h.in that would have
    had an effect in the Windows case.  This bug was fixed (along with
    dropping "module" and "MODULE) as follows:
    
    -#if defined ( plplot_widgetmodule_EXPORTS )
    -  #define PLDLLIMPEXP_PLPLOT_WIDGETMODULE    PLDLLEXPORT
    -  #define PLDLLIMPEXP_PLPLOT_MODULE_DATA( type )    PLDLLEXPORT type
    +#if defined ( plplot_widget_EXPORTS )
    +  #define PLDLLIMPEXP_PLPLOT_WIDGET    PLDLLEXPORT
    +  #define PLDLLIMPEXP_PLPLOT_WIDGET_DATA( type )    PLDLLEXPORT type
     #else
    -  #define PLDLLIMPEXP_PLPLOT_MODULE          PLDLLIMPORT
    -  #define PLDLLIMPEXP_PLPLOT_MODULE_DATA( type )    PLDLLIMPORT type
    +  #define PLDLLIMPEXP_PLPLOT_WIDGET    PLDLLIMPORT
    +  #define PLDLLIMPEXP_PLPLOT_WIDGET_DATA( type )    PLDLLIMPORT type
     #endif
    
    The (typographical) bug was the old code sometimes used MODULE when it
    should have consistently used WIDGET_MODULE.  The _DATA part of this
    bug was inconsequential because that construct was never used in the
    plplot_widget C code.  So the net effect was no visibility bug on
    Linux (since PLDLLIMPORT is not #defined on that platform), but there
    would have been an issue on Windows where PLDLLIMPORT _is_ #defined.
    But that bug was not detected because nobody has tested the pytkdemo
    application (which uses the plplot_widget extension module) on Windows
    (yet).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_pytkdemo target (which tests the
    plplot_widget extension module), the test_diff_psc target (which tests
    the _plplotc extension module), and the test_pyqt[45]_example targets
    (which tests the _plplotc extension module).  These tests were
    sucessful for Python 2, but for Python 3 the test_pytkdemo target
    failed (as expected since the current hand-crafted interface file,
    bindings/python/plplot_widget.c is not compatible with what is needed
    to create Python 3 extensions) as did the test_pyqt[45]_example
    targets. I cannot explain that latter result because sip is designed
    to generate interface files that are compatible with both Python 2 and
    Python 3 and inspection of those generated files confirms that.  So I
    have called for testing of the test_pyqt[45]_example targets on other
    platforms to help discover whether this is a general issue or
    something specific to the Debian Jessie platform.

M	bindings/python/CMakeLists.txt
A	bindings/python/plplot_widget.c
D	bindings/python/plplot_widgetmodule.c
A	bindings/python/plplotc.i
D	bindings/python/plplotcmodule.i
M	doc/CMakeLists.txt
M	examples/CMakeLists.txt
M	examples/python/CMakeLists.txt
M	include/pldll.h.in
M	scripts/style_source.sh

commit 578b028dc587e7ab1d109d273eed03de63b8a29c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Apr 21 00:04:05 2017 -0700

    Build system: Fix pyqt4 and pyqt5 configuration so it works properly for both Python 2 and 3
    
    This fix was simple.  Use parentheses around Python print arguments.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) for the Python 2 case by successfully building the
    test_pyqt4_example target for the (default) Qt4 case, and the
    test_pyqt5_example target for the Qt5 case (selected by specifying
    -DPLPLOT_USE_QT5=ON).
    
    Similarly tested for the Python 3 case (selected by using the cmake
    option -DPython_ADDITIONAL_VERSIONS:STRING=3) but with only partial
    success.  The build system worked properly to build the
    plplot_pyqt[45] extension modules using Python 3 headers and the
    sip-generated code, but at run time the plplot_pyqt[45] extension modules
    each generated a link error while being imported.  So even though I
    have the python3-sip package installed (and many more python3 packages)
    it appears the sip generation is not working quite correctly for the
    Python 3 case.  (This could be a problem with the sip version for
    Debian Jessie so testing on other platforms is requested).

M	cmake/modules/qt.cmake

commit 4c031e6fbc9d57c6cf382f2c2ad9736d332d2da6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Apr 20 23:41:45 2017 -0700

    Build and test system: Run all standalone Python scripts with ${PYTHON_EXECUTABLE}
    
    Because typically #!/usr/bin/env python (the "bang" line on our Python
    scripts) chooses python2, this change still allows the script to run
    when ${PYTHON_EXECUTABLE} refers to python3.  Alternative ways to fix
    this would have been to alias "python" to refer to the same Python
    version as ${PYTHON_EXECUTABLE} or to make all our Python scripts
    configurable so the bang line agrees with ${PYTHON_EXECUTABLE}, but
    these methods seem overkill to me since it is so straightforward (as in
    this commit) to change our test system so it always executes Python
    scripts using ${PYTHON_EXECUTABLE}.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) for the Python 2 case by successfully building the
    test_pyqt4_example target for the (default) Qt4 case, and the
    test_pyqt5_example target for the Qt5 case (selected by specifying
    -DPLPLOT_USE_QT5=ON).

M	examples/CMakeLists.txt
M	examples/plplot_configure.cmake_installed_examples.in

commit e233697cf2fad287dc1a97377093feb00fa3ed51
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Apr 19 14:25:55 2017 -0700

    Change virtually all references to Fortran 95 to Fortran
    
    These extensive changes include renaming any directory or file
    with "f95" embedded in the name to the "fortran" equivalent.  Renaming
    the CMake variable ENABLE_f95 to ENABLE_fortran, etc., etc.
    
    The reason for these changes (except for historical files such as
    ChangeLogs) is that all references to f95, F95, Fortran 95, etc.  are
    misnomers since our Fortran binding and examples are now Fortran 2003
    rather than Fortran 95.  And by generally using "[fF]ortran" rather
    than something more specific such as [fF]2003 this allows us to avoid
    source tree Fortran-related name changes if in the future we decide to
    change (e.g., to Fortran 2008) the Fortran standard which we support.
    Note, this commit is intrusive so substantial testing was done for
    it, see below.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) with the following tests:
    
    * Test PL_DEPRECATED_fortran option using
    
    scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_fortran=ON -DPL_DEPRECATED_fortran=ON" --do_test_interactive no
    
    Note I checked this and the other comprehensive test results below for
    warnings, errors, ldd issues, and PostScript difference results using
    
    grep -i warning ../comprehensive_test_disposeable/*/*/output_tree/*.out |grep -vE 'PLPLOT WARNING|\-\- WARNING|PRIVATE|octave|java|cmake.out' |less
    
    grep -i error ../comprehensive_test_disposeable/*/*/output_tree/*.out
    
    grep -iE 'found|symbol|undefined' $(find ../comprehensive_test_disposeable -name "build*ldd.out")
    
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable/*/*/output_tree/*.out |less
    
    There were some PostScript difference results for examples 20 and 29 that have crept in since
    that old deprecated Fortran binding and examples code that is used when -DPL_DEPRECATED_fortran=ON
    was frozen.  But otherwise this result was good.
    
    * Full comprehensive test of default PLplot
    
    scripts/comprehensive_test.sh
    
    I did this full test because of the possibility of some error
    introduced by the extensive "sed -i" automatic editing commands I used
    on lists of files found with the find and grep -l commands, but all
    was well, i.e., no obvious build or run-time errors, and no PostScript
    difference regressions (i.e., perfect PostScript difference results
    other than for the long-standing ocaml issues).
    
    * Successful repeat of the first (-DPL_DEPRECATED_fortran=ON) test as well as
    
    scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_fortran=ON" --do_test_interactive no
    
    to check minor old_fortran and fortran changes made after the above full comprehensive test
    was completed successfully.
    
    * Additional fortran-related target checks:
    
    I built the target check_fortran_parameters with complete success.  I also
    built the test_plfortrandemolib (which builds the executable of that name)
    and then ran examples/fortran/test_plfortrandemolib with complete success.

M	README
M	README.Release_Manager_Cookbook
M	README.developers
M	README.release
M	README.testing
M	bindings/CMakeLists.txt
D	bindings/f95/CMakeLists.txt
D	bindings/f95/README_array_sizes
D	bindings/f95/generate_ifort_deffile.sed
D	bindings/f95/global_defines.sed
D	bindings/f95/included_plplot_configured_types.f90.in
D	bindings/f95/included_plplot_parameters.f90
D	bindings/f95/included_plplot_real_interfaces.f90
D	bindings/f95/plplot.f90
D	bindings/f95/plplot_double.f90
D	bindings/f95/plplot_single.f90
D	bindings/f95/plplot_small_modules.f90
D	bindings/f95/plplotf95_ifort.def
A	bindings/fortran/CMakeLists.txt
A	bindings/fortran/README_array_sizes
A	bindings/fortran/generate_ifort_deffile.sed
A	bindings/fortran/global_defines.sed
A	bindings/fortran/included_plplot_configured_types.f90.in
A	bindings/fortran/included_plplot_parameters.f90
A	bindings/fortran/included_plplot_real_interfaces.f90
A	bindings/fortran/plplot.f90
A	bindings/fortran/plplot_double.f90
A	bindings/fortran/plplot_single.f90
A	bindings/fortran/plplot_small_modules.f90
A	bindings/fortran/plplotfortran_ifort.def
D	bindings/old_f95/CMakeLists.txt
D	bindings/old_f95/global_defines.sed
D	bindings/old_f95/plparseopts.f90
D	bindings/old_f95/plplot_parameters.inc
D	bindings/old_f95/plplot_types.f90.in
D	bindings/old_f95/plplotf95.def
D	bindings/old_f95/plplotf95_ifort.def
D	bindings/old_f95/plplotf95_mingw.def
D	bindings/old_f95/plstubs.h
D	bindings/old_f95/readme_f95.txt
D	bindings/old_f95/sc3d.c
D	bindings/old_f95/sccont.c
D	bindings/old_f95/scstubs.c
D	bindings/old_f95/sfstubs.inc
D	bindings/old_f95/sfstubsf95.f90
D	bindings/old_f95/strutil.f90
A	bindings/old_fortran/CMakeLists.txt
A	bindings/old_fortran/global_defines.sed
A	bindings/old_fortran/plparseopts.f90
A	bindings/old_fortran/plplot_parameters.inc
A	bindings/old_fortran/plplot_types.f90.in
A	bindings/old_fortran/plplotfortran.def
A	bindings/old_fortran/plplotfortran_ifort.def
A	bindings/old_fortran/plplotfortran_mingw.def
A	bindings/old_fortran/plstubs.h
A	bindings/old_fortran/readme_f95.txt
A	bindings/old_fortran/sc3d.c
A	bindings/old_fortran/sccont.c
A	bindings/old_fortran/scstubs.c
A	bindings/old_fortran/sfstubs.inc
A	bindings/old_fortran/sfstubsfortran.f90
A	bindings/old_fortran/strutil.f90
M	cmake/modules/fortran.cmake
M	cmake/modules/plplot_version.cmake
M	cmake/modules/summary.cmake
M	cmake/test_fortran/CMakeLists.txt
M	cmake/test_fortran/src_executable/CMakeLists.txt
M	cmake/test_fortran/src_lib/CMakeLists.txt
M	cmake/test_fortran/test_fortran_configure.cmake_installed_examples.in
M	doc/Doxyfile.in
M	doc/docbook/src/CMakeLists.txt
M	doc/docbook/src/api-c.xml
A	doc/docbook/src/api-fortran.xml
D	doc/docbook/src/api-fortran95.xml
M	doc/docbook/src/api.xml
A	doc/docbook/src/fortran.xml
D	doc/docbook/src/fortran95.xml
M	doc/docbook/src/intro.xml
M	doc/docbook/src/libraries.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/f95/CMakeLists.txt
D	examples/f95/Makefile.examples.in
D	examples/f95/README_precision
D	examples/f95/plf95demolib.f90
D	examples/f95/plf95demos.inc.in
D	examples/f95/test_plf95demolib.f90
D	examples/f95/x00f.f90
D	examples/f95/x01f.f90
D	examples/f95/x02f.f90
D	examples/f95/x03f.f90
D	examples/f95/x04f.f90
D	examples/f95/x05f.f90
D	examples/f95/x06f.f90
D	examples/f95/x07f.f90
D	examples/f95/x08f.f90
D	examples/f95/x09f.f90
D	examples/f95/x10f.f90
D	examples/f95/x11f.f90
D	examples/f95/x12f.f90
D	examples/f95/x13f.f90
D	examples/f95/x14f.f90
D	examples/f95/x15f.f90
D	examples/f95/x16af.f90
D	examples/f95/x16f.f90
D	examples/f95/x17f.f90
D	examples/f95/x18f.f90
D	examples/f95/x19f.f90
D	examples/f95/x20f.f90
D	examples/f95/x21f.f90
D	examples/f95/x22f.f90
D	examples/f95/x23f.f90
D	examples/f95/x24f.f90
D	examples/f95/x25f.f90
D	examples/f95/x26f.f90
D	examples/f95/x27f.f90
D	examples/f95/x28f.f90
D	examples/f95/x29f.f90
D	examples/f95/x30f.f90
D	examples/f95/x31f.f90
D	examples/f95/x33f.f90
A	examples/fortran/CMakeLists.txt
A	examples/fortran/Makefile.examples.in
A	examples/fortran/README_precision
A	examples/fortran/plfortrandemolib.f90
A	examples/fortran/plfortrandemos.inc.in
A	examples/fortran/test_plfortrandemolib.f90
A	examples/fortran/x00f.f90
A	examples/fortran/x01f.f90
A	examples/fortran/x02f.f90
A	examples/fortran/x03f.f90
A	examples/fortran/x04f.f90
A	examples/fortran/x05f.f90
A	examples/fortran/x06f.f90
A	examples/fortran/x07f.f90
A	examples/fortran/x08f.f90
A	examples/fortran/x09f.f90
A	examples/fortran/x10f.f90
A	examples/fortran/x11f.f90
A	examples/fortran/x12f.f90
A	examples/fortran/x13f.f90
A	examples/fortran/x14f.f90
A	examples/fortran/x15f.f90
A	examples/fortran/x16af.f90
A	examples/fortran/x16f.f90
A	examples/fortran/x17f.f90
A	examples/fortran/x18f.f90
A	examples/fortran/x19f.f90
A	examples/fortran/x20f.f90
A	examples/fortran/x21f.f90
A	examples/fortran/x22f.f90
A	examples/fortran/x23f.f90
A	examples/fortran/x24f.f90
A	examples/fortran/x25f.f90
A	examples/fortran/x26f.f90
A	examples/fortran/x27f.f90
A	examples/fortran/x28f.f90
A	examples/fortran/x29f.f90
A	examples/fortran/x30f.f90
A	examples/fortran/x31f.f90
A	examples/fortran/x33f.f90
D	examples/old_f95/CMakeLists.txt
D	examples/old_f95/Makefile.examples.in
D	examples/old_f95/plf95demolib.f90
D	examples/old_f95/plf95demos.inc.in
D	examples/old_f95/test_plf95demolib.f90
D	examples/old_f95/x00f.f90
D	examples/old_f95/x01f.f90
D	examples/old_f95/x02f.f90
D	examples/old_f95/x03f.f90
D	examples/old_f95/x04f.f90
D	examples/old_f95/x05f.f90
D	examples/old_f95/x06f.f90
D	examples/old_f95/x07f.f90
D	examples/old_f95/x08f.f90
D	examples/old_f95/x09f.f90
D	examples/old_f95/x10f.f90
D	examples/old_f95/x11f.f90
D	examples/old_f95/x12f.f90
D	examples/old_f95/x13f.f90
D	examples/old_f95/x14f.f90
D	examples/old_f95/x15f.f90
D	examples/old_f95/x16af.f90
D	examples/old_f95/x16f.f90
D	examples/old_f95/x17f.f90
D	examples/old_f95/x18f.f90
D	examples/old_f95/x19f.f90
D	examples/old_f95/x20f.f90
D	examples/old_f95/x21f.f90
D	examples/old_f95/x22f.f90
D	examples/old_f95/x23f.f90
D	examples/old_f95/x24f.f90
D	examples/old_f95/x25f.f90
D	examples/old_f95/x26f.f90
D	examples/old_f95/x27f.f90
D	examples/old_f95/x28f.f90
D	examples/old_f95/x29f.f90
D	examples/old_f95/x30f.f90
D	examples/old_f95/x31f.f90
D	examples/old_f95/x33f.f90
A	examples/old_fortran/CMakeLists.txt
A	examples/old_fortran/Makefile.examples.in
A	examples/old_fortran/plfortrandemolib.f90
A	examples/old_fortran/plfortrandemos.inc.in
A	examples/old_fortran/test_plfortrandemolib.f90
A	examples/old_fortran/x00f.f90
A	examples/old_fortran/x01f.f90
A	examples/old_fortran/x02f.f90
A	examples/old_fortran/x03f.f90
A	examples/old_fortran/x04f.f90
A	examples/old_fortran/x05f.f90
A	examples/old_fortran/x06f.f90
A	examples/old_fortran/x07f.f90
A	examples/old_fortran/x08f.f90
A	examples/old_fortran/x09f.f90
A	examples/old_fortran/x10f.f90
A	examples/old_fortran/x11f.f90
A	examples/old_fortran/x12f.f90
A	examples/old_fortran/x13f.f90
A	examples/old_fortran/x14f.f90
A	examples/old_fortran/x15f.f90
A	examples/old_fortran/x16af.f90
A	examples/old_fortran/x16f.f90
A	examples/old_fortran/x17f.f90
A	examples/old_fortran/x18f.f90
A	examples/old_fortran/x19f.f90
A	examples/old_fortran/x20f.f90
A	examples/old_fortran/x21f.f90
A	examples/old_fortran/x22f.f90
A	examples/old_fortran/x23f.f90
A	examples/old_fortran/x24f.f90
A	examples/old_fortran/x25f.f90
A	examples/old_fortran/x26f.f90
A	examples/old_fortran/x27f.f90
A	examples/old_fortran/x28f.f90
A	examples/old_fortran/x29f.f90
A	examples/old_fortran/x30f.f90
A	examples/old_fortran/x31f.f90
A	examples/old_fortran/x33f.f90
M	examples/plplot_configure.cmake_installed_examples.in
M	include/pldll.h.in
M	pkgcfg/README
M	plplot_test/CMakeLists.txt
M	plplot_test/plplot-test.sh.in
M	plplot_test/test_diff.sh.in
D	plplot_test/test_f95.sh.in
A	plplot_test/test_fortran.sh.in
M	scripts/MinGW_MSYS_comprehensive_test.sh
M	scripts/check_api_completeness.sh
M	scripts/htdocs-gen_plot-examples.sh
M	scripts/parity_bit_check.exclude
M	scripts/run_examples_windows.bat
M	scripts/style_source.sh
M	www/examples.php
M	www/index.php

commit 9574a435305b7a7211dc1b305bc1bb6b19a97939
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Apr 18 19:06:32 2017 -0700

    CMake-based build system for installed examples: Fix bug when ENABLE_CXX is OFF
    
    C++ is a special language case in that we enable that language in the
    CMake-build system used for the build tree if at all possible
    regardless of the value of ENABLE_cxx.  For ENABLE_cxx OFF, this
    enabling of the C++ language allows, e.g., libplplot to link properly
    with the C++ compiler when it contains C++ object modules (e.g., the
    compiled code for the psttf device driver when that is resident in the
    libplplot library).  However, previously our CMake-based build system
    for the installed examples did not follow this special C++ enabling
    logic so the result was linking errors for any example that linked to
    libplplot (when that library contained C++ code) when ENABLE_cxx was
    OFF.  This fix addresses that issue.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running
    
    scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_BINDINGS=ON -DENABLE_fortran=ON" --do_test_interactive no
    
    Before the fix, there were libLasi linking errors for the static case
    when building the installed examples with the CMake-based build system
    for those examples.  (I don't quite understand how I avoided the
    equivalent error for the nondynamic case, but perhaps linking is not
    checked so rigourously for that shared library case.)  After the fix,
    the above script run finished without issues.

M	examples/plplot_configure.cmake_installed_examples.in

commit 9185cced94e50d873e7e9b5038c2e9679066fa20
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Apr 17 22:57:05 2017 -0700

    Python examples: Use floor division for division of two integers to remove Python 2 versus Python 3 inconsistency
    
    For both Python 2 and 3 "//" stands for floor division (where the
    floor of the result is taken).  However, when two integers are being
    divided using the ordinary division sign "/", Python 2 uses floor
    division while python 3 uses ordinary division, i.e., the result is a
    floating-point number with non-zero fraction.  Therefore, in order to
    obtain numerical consistency between Python 2 results and Python 3
    results it is absolutely necessary to force floor division (using
    "//") whenever two integers are being divided.  (See discussion at
    <http://stackoverflow.com/questions/183853/in-python-2-what-is-the-difference-between-and-when-used-for-division>.)
    This fix for the first
    time gives complete numerical consistency between our standard example
    results for Python 2 and Python 3.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_diff_psc target for both
    Python 2 (default) and Python 3 (obtained with the cmake option
    -DPython_ADDITIONAL_VERSIONS:STRING=3).  In both cases, perfect
    PostScript difference results were obtained with the corresponding
    C examples, i.e.,
    
    python
      Missing examples            :
      Differing graphical output  :
      Missing stdout              :
      Differing stdout            :

M	README.release
M	examples/python/x02.py
M	examples/python/x09.py
M	examples/python/x11.py
M	examples/python/x14.py
M	examples/python/x15.py
M	examples/python/x16.py

commit 2bbdcb0aac9f016ebdeb5c363c0efad84191d631
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Apr 17 17:25:19 2017 -0700

    Fix recently introduced Python 2 PostScript difference regressions
    
    For Python 2, the recently introduced text issue with example 23 and
    PostScript difference issue with example 33 have now been fixed.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_python_psc target for both the
    (default) Python 2 and the Python 3 (obtained with the cmake option
    -DPython_ADDITIONAL_VERSIONS:STRING=3) cases.  We now have the
    following perfect PostScript difference report for Python 2.
    
    python
      Missing examples            :
      Differing graphical output  :
      Missing stdout              :
      Differing stdout            :
    
    while the (inconsistent) Python 3 result says the same, namely
    
    python
      Missing examples            :
      Differing graphical output  :  02 09 11 14a 15 16
      Missing stdout              :
      Differing stdout            :
    
    ToDo.  Fix the Python 2 to Python 3 conversion issues in these 6 different examples.

M	examples/python/x23.py
M	examples/python/x33.py

commit dd9d258f7a15fed1db3bf7c4abec9c0dbe07e229
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Apr 17 16:01:53 2017 -0700

    Python binding and examples: replace all remaining tab indentation with blank indentation
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_diff_psc target for both the
    (default) Python 2 and Python 3 (obtained using the cmake option
    DPython_ADDITIONAL_VERSIONS:STRING=3) cases.  No build or obvious run
    time errors occurred for either case, but there were the following
    PostScript differences for the two cases:
    
    python (2)
      Missing examples            :
      Differing graphical output  :  33
      Missing stdout              :
      Differing stdout            :  23
    
    python (3)
      Missing examples            :
      Differing graphical output  :  02 09 11 14a 15 16
      Missing stdout              :
      Differing stdout            :
    
    These results were identical to the same test used for Hazen's recent
    commit so the further tab to space changes in this commit do not
    introduce any additional regressions.  However, the above issues
    are a regression from the perfect Python (2) PostScript differences
    for PLplot-5.12.0 so obviously some more work has to be done to
    address these regressions.

M	bindings/python/Plframe.py
M	examples/python/plplot_logo.py
M	examples/python/pyqt4_example.py
M	examples/python/pyqt5_example.py
M	examples/python/pythondemos.py
M	examples/python/tutor.py
M	examples/python/x18.py
M	examples/python/x22.py
M	examples/python/x24.py

commit 2ac13f2cd44588b0f6701b87d70474054b9cacbe
Author: Hazen Babcock <hbabcock@mac.com>
Date:   Sun Apr 16 16:43:06 2017 -0400

    Support for Python3.
    
    Tested on linux (lubuntu 16.04) with Python 3.5 and Python 2.7 using
    'ctest' and 'make test_python_psc'.

M	bindings/python/CMakeLists.txt
M	bindings/python/plplot.py
M	bindings/python/plplotcmodule.i
M	cmake/modules/python.cmake
M	examples/python/x01
M	examples/python/x01.py
M	examples/python/x02.py
M	examples/python/x03.py
M	examples/python/x04.py
M	examples/python/x05.py
M	examples/python/x06.py
M	examples/python/x07.py
M	examples/python/x08.py
M	examples/python/x11.py
M	examples/python/x12.py
M	examples/python/x13.py
M	examples/python/x14.py
M	examples/python/x15.py
M	examples/python/x17.py
M	examples/python/x19.py
M	examples/python/x20.py
M	examples/python/x21.py
M	examples/python/x23.py
M	examples/python/x26.py
M	examples/python/x27.py
M	examples/python/x28.py
M	examples/python/x33.py

commit 58dc757dcf65f247141b9a0209eaebc79143cc01
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Apr 14 20:10:49 2017 -0700

    Developer documentation: rework recommended gcc/g++/gfortran compiler options
    
    The principal change is the prior suggestions for the gfortran case
    had to be changed to be consistent with our new Fortran binding.  In
    particular the -std=f???? -pedantic options had to be dropped because
    they created what I consider to be spurious build errors.  This means
    we cannot check for Fortran 2003 compliance with gfortran and must
    rely on a different Fortran compiler (NAG) to do that.

M	README.developers

commit 4936e4067123ad68ffc27e1e658e3d986952ef28
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Apr 13 14:09:29 2017 -0700

    -dev wxwidgets: work around character alignment issues that need a proper fix from Phil
    
    I discovered by running
    
    python examples/python/test_superscript_subscript.py -dev wxwidgets
    
    that the rendered superscript offset was too small and the rendered
    subscript offset was completely in the wrong direction (i.e., gave the
    same upward offset as the corresponding superscript level rather than
    the correct downward offset of the same absolutel magnitude as the
    corresponding superscript offset).  Further investigation of the code
    showed a number of issues that had to be addressed.
    
    1. "Old" arguments to plP_script_scale were incorrectly destroyed
    between calls to that routine.  One fix for that issue would have been
    to initialize all plP_script_scale and associated arguments such as
    offsetActual properly in drawText and have that routine call
    DrawTextLine with that same set of plP_script_scale and associated
    arguments, but instead I decided to change the semantics of
    DrawTextLine so that superscript/subscript level state was not
    preserved across linefeeds (which allowed me to remove the partial
    list of plP_script_scale arguments that had been implemented
    previously from the DrawTextLine arguments, and initialize
    plP_script_scale and all associated variables properly inside
    DrawTextLine).  Note if we decide to change back to the old semantics,
    then I have outlined above how that should be done which is obviously
    quite different than what was implemented previously for the old
    semantics.
    
    2. The offsetActual variable had no discernible effect on rendered
    superscript and subscript levels until it was multiplied by a
    substantial factor (which was later empirically determined to be near
    60).  Presumably this "fix" is a workaround to some gross scaling bug
    which I have not been able to find so I leave finding the true cause
    of this issue and fixing it properly to Phil.
    
    3. When offsetActual was zeroed (or effectively zeroed by bad
    underscaling as in the original test) DrawTextSection renders the
    identical upward offset for the same absolute magnitude of level.  So
    for this special case level = +/-1 gives the same rendered results,
    and similarly for other absolute magnitudes of levels.  This is
    clearly wrong for the negative level (subscript) case whose rendered
    offsets should be downward rather than upward.  When fix 2. is applied
    so that offsetActual has a discernible effect, the net result is
    superscripts have upward offsets that are rendered too large and
    subscripts have downward offsets that are rendered too small.  I
    worked around this issue by reducing superscript offsets and
    increasing subscript offsets by an empirical factor of 1.2.  I leave
    it to Phil to determine a proper fix for this issue.
    
    4. Apply an overall empirical vertical offset to all strings to give
    good vertical alignment results for the utf8 "heavy multiplication x",
    "number sign", "four teardrop-spoked asterisk", and "8-spoked
    asterisk" characters for a large range of character sizes when running
    
    python examples/python/test_circle.py -dev wxwidgets
    
    Changes 1 through 3 constitute a fix and two workarounds to deal
    with <https://sourceforge.net/p/plplot/bugs/165/> (incorrectly
    classified as previously fixed), and Change 4 constitutes a
    workaround for <https://sourceforge.net/p/plplot/bugs/185/>.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running (after building the test_c_wxwidgets
    and test_python_psc prerequisite targets)
    
    python examples/python/test_superscript_subscript.py -dev wxwidgets
    python examples/python/test_circle.py -dev wxwidgets
    
    with good alignment results for each case as stated above, and
    
    examples/c/x??c -dev wxwidgets
    
    (where ?? is 01, 02, 04, and 26) where all these results had
    noticeably improved vertical alignment of text.  So these empirical
    workarounds appear to be a success for at least all these particular
    tests on the given platform, but fundamental fixes would be much
    better in all cases.

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

commit 25d120e6e1a80ad2ca8f63fb1cd1c6125e056c3f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Mar 30 12:36:34 2017 -0700

    wxwidgets IPC: Force three named semaphores approach on all platforms
    
    This change insures everyone will be testing the same IPC method
    on all platforms from now on and is the first step in a planned
    IPC code cleanup where all variants of IPC other than the three named
    semaphores approach will be completely removed.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running
    
    scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -DENABLE_cxx=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON" --do_test_noninteractive no --do_ctest no
    
    There were no obvious build or run-time issues with this test which
    took only 15 minutes to complete.  However, this test uses the -np
    option when running examples which means (because of a -dev wxwidgets
    bug for that option) effectively no visible rendering of the result.
    Therefore, for an additional test without the -np option I built the
    wxwidgets, wxPLViewer, and x08c targets and ran
    
    examples/c/x08c -dev wxwidgets
    
    without any obvious build, run-time, or rendering issues.
    
    N.B. The three named semaphores approach should "just work" on all
    platforms, but so far it has only been tested on Linux so testing on
    the various Windows platforms (MSVC, Cygwin, and MinGW-w64/MSYS2) and
    Mac OS X is requested.

M	cmake/modules/wxwidgets.cmake

commit 41594bca2a9716a8da4d8e7dd910a6850ea824e9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Wed Mar 15 12:20:57 2017 -0700

    Spelling fixes for all wxwidgets source code
    
    I made these changes using
    
    for FILE in $(ls drivers/wx* utils/wx* bindings/wxwidgets/wx* |grep -v driver_info); do aspell check $FILE; done
    
    The aspell command automatically recognized C/C++ files and confines
    its spelling changes to comments and string constants.  However, it
    turned out that that none of the spelling changes I authorized were in
    string constants, i.e., all these changes were in commentary alone.  I
    also confirmed that result by searching for the regular expression
    "^[+-] *[^/ ]" (search for any changes not in a standalone comment
    line) in "git diff" output.

M	bindings/wxwidgets/wxPLplotwindow.h
M	drivers/wxwidgets.cpp
M	drivers/wxwidgets.h
M	drivers/wxwidgets_comms.cpp
M	drivers/wxwidgets_dev.cpp
M	utils/wxplframe.cpp
M	utils/wxplframe.h
M	utils/wxplviewer.cpp

commit 65d55d6e98f6e84a94639e62276c0b595d73aa04
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Mar 13 11:48:55 2017 -0700

    wxwidgets 3-semaphore IPC: tuned PL_SHARED_ARRAY_SIZE to 10*1024
    
    I measured the total IPC time (roughly 18 seconds on my system) taken
    to execute all our C standard examples (except for 17 and 20) with
    -dev wxwidgets as follows:
    
    * I locally modified utils/wxplframe.cpp to #define PLPLOT_WX_NOPLOT
      (to stop the rendering inefficiency of wxPLViewer from interfering
      with the timing test).
    
    * I built all prerequisites using the test_c_wxwidgets target at first
      (which builds the wxwidgets and wxPLViewer targets as well as all the
      C examples).  Later I just rebuilt the wxwidgets and wxPLViewer targets
      for each change in PL_SHARED_ARRAY_SIZE.
    
    * For each of those builds, I measured the total IPC time using
    
    time(for N in $(seq --format='%02.0f' 0 34|grep -vE '17|20'); do examples/c/x${N}c -dev wxwidgets >&/dev/null; killall -9 wxPLViewer; done)
    
    where the killall command was required to get rid of the empty wxPLViewer GUI left by running
    the standard example with PLPLOT_WX_NOPLOT #defined.
    
    By repeating the above test for the same value of
    PL_SHARED_ARRAY_SIZE, I discovered that the repeatibility of the total
    time results was typically within 2 per cent or less.  Comparison of
    PL_SHARED_ARRAY_SIZE of 128 versus 1024 showed a barely significant 4 per cent
    improvement in speed, but there was no significant improvement beyond
    that for any value of PL_SHARED_ARRAY_SIZE tried above 1024 including
    1024*1024.  Therefore, the final PL_SHARED_ARRAY_SIZE adopted for this
    commit which is 10*1024 is very likely gross overkill, but still it is
    one hundred times smaller than the 1024*1024 size of the circular
    buffer used for the -DPL_WXWIDGETS_IPC3=OFF case.
    
    Normally, this large reduction in the amount of shared memory size
    that is consumed by -dev wxwidgets and wxPLViewer IPC would not be a
    significant advantage on systems with substantial amounts of shared
    memory available and no shared memory leaks associated with the
    wxwidgets IPC.  However, it is better style to use only the amount of
    shared memory that is necessary because on some systems that is a
    rather limited resource.  Furthermore, for some unknown reason we
    still have a shared memory leak (i.e., when you ctrl-C out of an
    example, /dev/shm shows shared memory is "permanently" consumed until
    the user logs off the system or executes a rm -f /dev/shm/*plplot*
    command).  Therefore, so long as this shared memory leak persists with
    wxwidgets IPC the much smaller shared memory buffer that results from
    this commit could be an advantage if the user is in the habit of
    exiting from -dev wxwidgets in a way (e.g., such as ctrl-C) that
    triggers the shared memory leak.

M	drivers/wxwidgets_comms.h

commit 7b1285b8f66a5ed4e71c1ae82c99ae35067331c7
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Mar 13 09:15:01 2017 -0700

    Build system: make endif label consistent
    
    This fixes a developer warning.

M	cmake/modules/wxwidgets.cmake

commit 7cfd6cec87fba729b48052c73fcd238103987432
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Mar 12 18:15:29 2017 -0700

    wxPLViewer app: implement PLPLOT_WX_NOPLOT macro which if #defined suppresses rendering for timing purposes
    
    By default the #define for this macro is commented out, but if that
    between -dev wxwidgets and wxPLViewer can be measured much more
    accurately because the currently inefficient plot rendering done by
    wxPLViewer is not consuming system resources and therefore not
    interfering with the timing measurement for IPC nearly as much as when
    Plot rendering is done by wxPLViewer.

M	utils/wxplframe.cpp

commit 3bf7b608866dec8c275f2f2dfdf573f3ba9bc338
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Mar 12 18:11:05 2017 -0700

    Style previous commit

M	drivers/wingdi.c

commit 0479258002ec8cb468b00d29265353b068df5262
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sun Mar 12 18:10:21 2017 -0700

    Remove trailing white space from previous commit

M	cmake/modules/wxwidgets.cmake

commit 14e70d733ea4a82859246473fa22edd76edfbf0b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Mar 11 14:27:09 2017 -0800

    Build system: implement try_run test to determine PL_HAVE_UNNAMED_POSIX_SEMAPHORES
    
    On Windows platforms (i.e., those where the CMake variable WIN32 is
    true) the result of this test is the CMake variable
    PL_HAVE_UNNAMED_POSIX_SEMAPHORES is undefined and the equivalent C
    macro is accordingly not #defined).  On non-Windows platforms (i.e.,
    POSIX platforms), a try_run test is run to check for the build and
    run-time success of sem_init and sem_destroy with CMake variable
    PL_HAVE_UNNAMED_POSIX_SEMAPHORES and equivalent C macro set
    accordingly.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running cmake with the -DPL_WXWIDGETS_IPC3=ON option
    and looking at the (correct) results for PL_HAVE_UNNAMED_POSIX_SEMAPHORES.
    
    N.B. a platform concern is the -pthread linking option used for the
    try_run test.  Other linking options might have to be used on other
    platforms to obtain linking success for the sem_init and sem_destroy
    calls used in this test.  However, if this test fails on some
    platforms because of this issue, it is only a minor concern since the
    fallback of using named semaphores on such platforms should be a good
    alternative.

M	cmake/modules/wxwidgets.cmake

commit 287fbd8d61d9ce46fd4842258922405fd1ec13da
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Mar 11 14:26:36 2017 -0800

    Build system: improve style of try_run tests
    
    As a matter of style for all try_run tests from now on, implement a
    proper "FAILED_TO_RUN" test for (unlikely but still potentially
    possible) run-time errors during the test.  As it happens, there is
    currently only one try_run test used in our build system right now (in
    cmake/modules/csiro.cmake), but I am planning at least one more.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by trying local modifications of the test C code so
    that it failed to compile, produced a false (0) result, or failed to
    run.  The latter result was achieved by introducing a segfault using
    the method in <https://en.wikipedia.org/wiki/Segmentation_fault>,
    e.g.,
    
    char *s = "hello world";
    //Attempt to write to read-only memory
    *s = 'H';
    
    ).
    
    The resulting RUN_RESULT and COMPILE_RESULT variables for these local
    variations took on the expected values, i.e., this improved style for
    using try_run should work fine on all platforms for this csiro library
    case and should work fine for future cases (so long as the C code
    being tested with try_run returns 1 on success and 0 on failure).

M	cmake/modules/TestNaNAware.c
M	cmake/modules/csiro.cmake

commit 658796c7411cc68e0ef78c7809d48fadb2e04298
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Mar 10 10:03:58 2017 -0800

    README.developers: updated git availability and git command-line paragraphs
    
    With regard to git availability, I have now added Xcode and Fink as
    sources of git packages on Mac OS X and "Git for Windows", Cygwin, and
    MinGW-w64/MSYS2 as sources of git packages on Windows.  I have removed
    the msysGit project as a source for git packages on Windows since that
    project has now been superseded by "Git for Windows".
    
    With regard to the git command-line, I have improved the justification
    for using that rather than some non-standard git GUI, and I have added
    more information about how to obtain access to the git command line
    for both the Xcode and "Git for Windows" versions of git.

M	README.developers

commit d81217530db5af568cdaae65ffefb386b015eb2b
Author: Jim Dishaw <jim@dishaw.org>
Date:   Fri Mar 10 10:27:57 2017 -0500

    Fixed the bug that caused the application to crash when printing
      - The printer device was not zero initialized, which resulted in
        in a bogus values being passed to windows
    
    Removed dead code
      - There was code that was put in as a placeholder for selecting
        a print range, however, the PLplot library is not setup to
        handle such a request at this time.
    
    Changed some #defines to an enumerated data type as a transition to
    getting the compiler to check for invalid values

M	drivers/wingdi.c

commit 096527c5b99c3be9dcde96a2239f543efd12cac4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Mar 9 21:50:19 2017 -0800

    wxwidgets three-semaphore IPC: implement named POSIX and named Windows semaphore variants of the current unnamed semaphore implementation
    
    These variants were determined by copying how semaphores were
    initialized, posted, waited for, and destroyed for the
    -DPL_WXWIDGETS_IPC3=OFF case.
    
    I also took this opportunity to replace all mention of two semaphores with three semaphores.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building (for the three cases
    1. -DPL_WXWIDGETS_IPC3=ON -DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=ON
    2. -DPL_WXWIDGETS_IPC3=ON -DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=OFF
    3. -DPL_WXWIDGETS_IPC3=OFF
    ) test_c_wxwidgets and by running timing tests using
    
    export TIMEFORMAT=$'real\t%3R'
    
    to replace the default
    
    export TIMEFORMAT=$'\nreal\t%3lR\nuser\t%3lU\nsys\t%3lS'
    
    and commands similar to
    
    (for N in $(seq --format='%02.0f' 0 30 |grep -vE '08|17|20|25'); do echo $N; (time examples/c/x${N}c -dev wxwidgets  >&/dev/null); sleep 5; done) >| ../IPC3_timing_ON_OFF_alt5.txt 2>&1
    
    to measure timing (both with and without the -np option for the
    examples/c/x${N}c command) and to look at rendered results when the
    -np option was not used.  There were no obvious run-time errors such
    as segfaults with any of these tests, and the rendered results seemed
    consistent in all cases.  (The timing results, however, were
    inconclusive as discussed on list.)
    
    Build and run-time testing is requested for the
    -DPL_WXWIDGETS_IPC3=ON -DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=OFF
    case for Windows platforms (i.e., when the macro WIN32 is
    
    Bug fixing is requested (for both -DPL_WXWIDGETS_IPC3=ON
    and -DPL_WXWIDGETS_IPC3=OFF) for the
    
    examples/c/x01c -locate -dev wxwidgets
    
    case as discussed further on the plplot-devel list.

M	cmake/modules/wxwidgets.cmake
M	drivers/wxwidgets.h
M	drivers/wxwidgets_comms.cpp
M	drivers/wxwidgets_comms.h
M	drivers/wxwidgets_dev.cpp
M	plplot_config.h.in
M	utils/wxplframe.cpp
M	utils/wxplframe.h

commit 79987dfa1f6462844ef3940a629595b3ced6772e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Mar 4 11:17:48 2017 -0800

    wxwidgets three-semaphore IPC: first attempt at implementing interactivity
    
    Here is what should be happening as a result of this
    attempted implementation:
    
    * In example 1 using the -locate option after all normal PLplot calls
    to generate the plot have been called (which fills up plbuf with 24272
    bytes of information, see below), the locate mode loop generates a
    series of plGetCursor calls.
    
    * Each of those plGetCursor calls ends up (for -dev wxwidgets) as a call to
    wxPLDevice::Locate which has the following code:
    
    TransmitBuffer( pls, transmissionLocate );
    m_outputMemoryMap.receiveBytes( true, &m_header, sizeof ( MemoryMapHeader ) );
    *graphicsIn = m_header.graphicsIn;
    
    * TransmitBuffer calls transmitBytes to send header information
    (including transmissionLocate = 4 and  plbufAmountToTransmit = 24272
    bytes in plbuf to be received by wxPlFrame::ReadTransmission (which is called
    by wxPlFrame::OnCheckTimer on a timer event loop) using receiveBytes.
    
    The results are
    
    Before transmitBytes
    transmissionType = 4
    plbufAmountToTransmit = 24272
    viewerOpenFlag = 1
    locateModeFlag = 1
    completeFlag = 0
    After receiveBytes
    transmissionType = 4
    plbufAmountToTransmit = 24272
    viewerOpenFlag = 1
    locateModeFlag = 1
    completeFlag = 0
    Successful read of plbuf
    
    i.e., that transmission of the plbuf information and
    transmissionLocate to wxPlFrame::ReadTransmission was a complete success.
    
    * Because plbufAmountToTransmit is non-zero, wxPLViewer appends that
    plbuf information to the correct element of the m_pageBuffers array
    and conditionally (although the result is the condition is true
    because of the above 24272 says there is a lot more data to plot)
    calls SetPageAndUpdate as per normal which should update all the
    required plotbuf information and configure all the plotbuf data to be
    plotted using the Refresh method.
    
    * After plbuf is processed, then wxPlFrame::ReadTransmission
    for the transmissionLocate case calls
    SetPageAndUpdate one more time (which should have no effect because
    the new plbuf information has already been completely processed by the
    previous call to SetPageAndUpdate), then sets m_locateMode = true
    before exiting wxPlFrame::ReadTransmission and wxPlFrame::OnCheckTimer
    to complete processing of that timer event.
    
    * After that exit from wxPlFrame::OnCheckTimer the plot should be
    automatically plotted (because of the above call to the Refresh
    method), but for some reason (likely a bug) that does not happen.
    
    * Then once a mouse click causes another event, wxPlFrame::OnMouse
    collects information about that click into the m_header.graphicsIn
    struct, and then the whole header is sent back to -dev wxwidgets with
    transmit_Bytes (which because of the three-semaphore design will wait
    for the end of the previous transmit_Bytes before proceeding so I
    don't think we are up against any race condition here) where
    wxPLDevice::Locate receives it with receiveBytes (see line of code
    above), and passes it back to the example 1 locate loop which prints
    out values collected for a particular mouse click, then (unless there
    is an exit from locate mode by a mouse click off of a viewport keeps
    repeating the whole process indefinitely.
    
    The above is the theory, but in practice the plot never shows and everything
    just hangs.  So there is likely some small bug in the implementation, but
    I haven't found it yet.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building wxwidgets, wxPLViewer, and x01c for the
    -DPL_WXWIDGETS_IPC2=ON case and running
    
    examples/c/x01c -dev wxwidgets
    
    with complete success, but
    
    examples/c/x01c -dev wxwidgets -locate
    
    produces the above-mentioned hang with no plot being displayed yet
    also the above evidence that all the data was transmitted from -dev
    wxwidgets to wxPLViewer without issues (except possibly that
    plbufAmountToTransmit = 24272 rather than the value of 24270 that
    occurred for the above case without the -locate option).  So it
    currently appears that all you need to do to get this fixed is display
    the plot after wxPlFrame::OnCheckTimer so that any mouse click after
    that on that display will end up as a call to wxPlFrame::OnMouse.
    
    N.B. this issue of the plot not being displayed also occurs for
    the -DPL_WXWIDGETS_IPC2=OFF case.  So presumably the same fix
    with fix both the -DPL_WXWIDGETS_IPC2=ON and OFF cases.

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

commit 245815fc3b336c1df522a9103986e3d1f3eca2c4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Feb 28 10:43:42 2017 -0800

    wxwidgets three-semaphore IPC: three fixes
    
    1. I fixed the "Caught unhandled unknown exception; terminating" exception
    that was thrown only for examples 02 and 14 which was
    due to those examples ending by sending a transmissionEndOfPage
    with no added plbuf data (because they use plbop and pleop to advance
    through the pages rather than pladv).  The wxPlFrame::ReadTransmission
    method threw an unnecessary exception for this case, and the fix was
    to remove that throw, and trust SetPageAndUpdate to handle this case
    (which it did).
    
    2. Obviously the above error message was way too generic so I
    made the treatment of exceptions much more specific by
    also fixing a bug in some of the catch statements (char * message ==>
    const char * message), and also by using more try and catch stanzas.
    The resulting specific error message, "wxPlFrame::ReadTransmission:
    Received an end of page transmission after no draw instructions", was
    the key in finding the solution to 1.
    
    3. I fixed a subtle error which was introduced for the cerr commands
    when the type of transmissionType was changed from size_t to unsigned
    char.  It turns out cerr interprets unsigned char as an ascii control
    character to be sent to the screen so the fix was to cast
    transmissionType to unsigned int for all cerr statements that were
    outputting the transmissionType.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) for the -DPL_WXWIDGETS_IPC2=OFF case by building the
    test_c_wxwidgets target (to demonstrate the -DPL_WXWIDGETS_IPC2=ON
    changes did not affect the-DPL_WXWIDGETS_IPC2=OFF case).
    
    In addition the -DPL_WXWIDGETS_IPC2=ON case was extensively tested.
    
    I ran both
    
    examples/c/x02c -dev wxwidgets
    
    and wxPLViewer under valgrind control with no memory management errors
    being reported (i.e., "ERROR SUMMARY: 0 errors from 0 contexts
    (suppressed: 0 from 0)") for either case.
    
    I did the same experiment for example 14 with the same good valgrind reports.
    
    I ran
    
    examples/c/x02c -dev wxwidgets
    
    on its own (i.e., without valgrind) and the rendered results looked the
    same (small character size which might be correct, but also some character
    misalignment which is wrong) as for the -DPL_WXWIDGETS_IPC2=OFF case.
    
    I ran
    
    examples/c/x14c -dev wxwidgets
    
    on its own (i.e., without valgrind) and the rendered results looked
    the same as for the -DPL_WXWIDGETS_IPC2=OFF case, i.e., there is a
    wxwidgets bug exposed here where the wxPLViewer instance corresponding to the
    slave instance of -dev wxwidgets starts but quits again before it can
    render the expected slave GUI, but since this bug also occurs for the
    -DPL_WXWIDGETS_IPC2=OFF case, the fix for it obviously has nothing to
    do with the -DPL_WXWIDGETS_IPC2=ON code (and more likely has something
    to do with a PLplot stream safety issue for -dev wxwidgets).
    
    As a final check for the -DPL_WXWIDGETS_IPC2=ON case I built the
    test_c_wxwidgets target with no obvious build or run-time issues.

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

commit 44e05cefbab1670cb07ea00f677804082817baf5
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Feb 27 16:35:04 2017 -0800

    Style previous commit

M	drivers/wxwidgets_comms.cpp

commit c39f93d87b8f3cefd03ca89384c8dcd76871ae97
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Feb 27 15:08:16 2017 -0800

    wxwidgets three-semaphore IPC: Fix race when data flow reverses
    
    The previous two-semaphore approach had a race condition when the data
    flow between -dev wxwidgets and wxPLViewer was reversed which
    previously was worked around by inserting a 10 ms wait.  This commit
    reverts that workaround for the race, drops (the no longer needed)
    moveBytesWriterReversed and moveBytesReaderReversed PLMemoryMap
    methods, renames moveBytesWriter to transmitBytes, and renames
    moveBytesReader to receiveBytes where both transmitBytes and
    receiveBytes can be used by either of -dev wxwidgets or wxPLViewer.
    In addition this commit fixes the race condition completely by using a
    third semaphore to control repeat use of transmitBytes so previous use
    of that function by either -dev wxwidgets or wxPLViewer must complete
    before that function can be executed again (by either side) to make
    the previous race in that regard impossible.  N.B. everywhere in the
    code that used to refer to the two-semaphores approach now refers to
    the three-semaphores approach.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) for the -DPL_WXWIDGETS_IPC2=ON case by building the
    relevant x??c targets as well as the wxwidgets and wxPLViewer
    targets and then running
    
    examples/c/x??c -dev wxwidgets
    
    for standard examples 00, 08, 09, and 16 with complete success (i.e.,
    no exceptions were thrown, and the plotted results showed some known
    rendering bugs for the wxwidgets case (e.g., the first page of example
    16 had incorrect black rather than correct white background), but
    there were no obvious regressions in rendering.

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

commit 4e6932edb82a26513f6fc6194813aefde1041bd9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Feb 25 17:18:04 2017 -0800

    wxwidgets two-semaphore IPC: Attempt to avoid race when data flow reverses
    
    When data flow is all in the same direction (e.g., moveBytesWriter
    calls followed consecutively by additional such calls on the writer
    (-dev wxwidgets) side) each moveBytesWriter call sets up the next with
    no chance for races.  And the same is true of consecutive
    moveBytesReaderReversed calls on the reader (wxPLViewer) side.
    However, a call to moveBytesReaderReversed on the reader side followed
    by a call to moveBytesWriter on the writer side (i.e., where the
    direction of data flow is reversed) creates a race because there is no
    guarantee (although it should happen virtually all the time) the OS
    scheduler will allow moveBytesReaderReversed to finish before
    moveBytesWriter is started.  And similarly there is an equivalent race
    when a call to moveBytesWriter on the writer side is followed by a
    call to moveBytesReaderReversed on the reader side.
    
    This commit attempts to avoid those races by inserting (whenever there
    is a reverse in the flow of data) a 10 ms sleep.  This should not be
    an efficiency concern in the slightest because the sleep is only
    executed when the direction of data flow is reversed, and that only
    occurs for an initialization handshake now and interactive use of -dev
    wxwidgets (later when interactive capabilities are implemented for the
    -DPL_WXWIDGETS_IPC2=ON case).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by rebuilding for the -DPL_WXWIDGETS_IPC2=ON case
    the wxwidgets, wxPLViewer, and x09c targets and running
    
    examples/c/x09c -dev wxwidgets
    
    without issues.
    
    N.B. my current thinking is the above 10 ms sleep is way more than
    enough.  The score is currently that it has worked once in the above
    test, but only time will tell whether the
    "PLMemoryMap::moveBytesWriter: attempt to start transfer with
    semaphores not in correct blocked state (likely due to a race)."
    exception or equivalent exception for
    PLMemoryMap::moveBytesReaderReversed is ever thrown again.

M	drivers/wxwidgets_comms.cpp
M	drivers/wxwidgets_comms.h
M	utils/wxplframe.cpp

commit ad372eed62b29cc820e784b20c6c27ef7e99bbe2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Feb 25 13:44:30 2017 -0800

    wxwidgets two-semaphore IPC: quiet valgrind uninitialized false alarms
    
    When wxPLViewer was run under valgrind, there were many uninitialized
    variable false alarms due (apparently) to valgrind not realizing that
    m_header could be updated with properly initialized values from the
    -dev wxwidgets side.  This commit works around that issue by
    wxPLViewer initializing m_header with the result that I now get
    consistently clean ("ERROR SUMMARY: 0 errors from 0 contexts
    (suppressed: 0 from 0)") valgrind reports from wxPLViewer (as well as
    -dev wxwidgets).
    
    By the way, these clean valgrind results for both -dev wxwidgets and
    wxPLViewer completely shoot down my previous hypothesis concerning
    the "PLMemoryMap::moveBytesWriter: attempt to start transfer
    with semaphores not in correct blocked state." exception that
    was being thrown in a tiny minority of cases.  So Phil's suggestion
    to look for a race condition to explain this exception is what
    I am focussing on now.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by rebuilding for the -DPL_WXWIDGETS_IPC2=ON case
    the wxwidgets, wxPLViewer, and x09c targets and running
    
    examples/c/x09c -dev wxwidgets
    
    without issues.

M	utils/wxplframe.cpp

commit 39d1aa35d62953ca1995dbdeb72f355e5bcbe7c0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Feb 25 13:42:41 2017 -0800

    wxwidgets two-semaphore IPC: initialize semaphores only once per memory map creation.
    
    This semaphores initialization (implemented by calling
    m_outputMemoryMap.initializeSemaphoresToValid with a false 3rd
    argument) occurs in wxPLDevice::SetupMemoryMap.  Previously this call
    was done as part of a loop to establish the memory map.  This fix
    moves that call from the loop (where any repeat of the call would have
    been invalid) to just after the loop.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by rebuilding for the -DPL_WXWIDGETS_IPC2=ON case
    the wxwidgets, wxPLViewer, and x09c targets and running
    
    examples/c/x09c -dev wxwidgets
    
    without issues.

M	drivers/wxwidgets_dev.cpp

commit 199b276bf1c0603c1cf9ba38822b94668b3b2898
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Feb 25 13:20:37 2017 -0800

    wxwidgets two-semaphore IPC: use consistent transmission types
    
    Change the type of transmissionType in the MemoryMapHeader struct from
    size_t to unsigned char (and reorder the elements of that struct to
    reduce padding for this case) to be consistent with the unsigned char
    type of the possible transmission flags constants that are compared
    with transmissionType.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by rebuilding for the -DPL_WXWIDGETS_IPC2=ON case
    the wxwidgets, wxPLViewer, and x09c targets and running
    
    examples/c/x09c -dev wxwidgets
    
    without issues.

M	drivers/wxwidgets_comms.h

commit 7c3f62fef2b1f08ad82cee2b245dc87a0dd78592
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Feb 24 16:41:23 2017 -0800

    Solve uninitialized m_useGraphicsContext
    
    This memory management issue (which could lead to random initialization issues for
    drawDc in wxPLplotwindow<WXWINDOW>::setUseGraphicsContext) was turned
    up by a valgrind run on wxPLViewer.  As expected, this fix (which insures that
    m_useGraphicsContext and drawDc are properly initialized by the call
    to setUseGraphicsContext from the wxPLplotwindow constructor) stopped
    these particular memory management issues reported by valgrind.

M	bindings/wxwidgets/wxPLplotwindow.h

commit d1ea14ff868016dfef3e2ec5f75bba9908c4138a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Feb 24 16:33:25 2017 -0800

    wingdi device driver: minor style fixup
    
    For some reason, the previous styling of drivers/wingdi.c was not
    complete and there are a few minor additional changes that
    are made when scripts/style_source.sh is run again, and
    those final style changes are committed here.

M	drivers/wingdi.c

commit 635df69c5332155d18c6d4f84a1aec5d00b9f7d8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Feb 23 23:06:03 2017 -0800

    wxwidgets IPC: enable (with limitations) plots for the wxwidgets two-semaphore IPC approach
    
    For the case when -DPL_WXWIDGETS_IPC2=ON I tweaked -dev wxwidgets to
    use transmissionFlush (rather than transmissionComplete) for flushes
    and use transmissionComplete for the case when
    m_header.completeFlag = 1 needs to be transmitted to wxPLViewer,
    made the corresponding WxPLViewer changes, and updated wxPlViewer
    to actually plot the plbuf data that are being sent.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by specifying the -DPL_WXWIDGETS_IPC2=ON cmake option,
    building all the C examples, wxwidgets, and
    wxPLViewer and running
    
    examples/c/x??c -dev wxwidgets
    
    There were good plot results for one-page examples such as x00c, x01c,
    and x24c but unexpected bad results (an uncaught wxPLViewer exception
    which needs further investigation) for multiple-page examples such as
    x02c.

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

commit 01b6e3ce1f1f71579f3cf113eddfc7ade4332ab7
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Feb 23 17:46:54 2017 -0800

    wxwidgets IPC: implement a lot more of the wxwidgets two-semaphore IPC approach
    
    For the case when -DPL_WXWIDGETS_IPC2=ON the IPC is now implmeented as
    follows:
    
    * The PLTwoSemaphores class has been matured with the addition of a
      number of methods (such as initializeToValid, initializeToInvalid,
      areBothSemaphoresValid, and areBothSemaphoresBlocked) that have
      proved useful for IPC using the two-semaphores approach.
      Furthermore, The alternative constructor has been dropped, and the
      destructor has been simplified.
    
    * Add transmissionType and plbufAmountToTransmit fields to the
      MemoryMapHeader struct rather than having such header-type fields
      mixed with plbuf information in the data transmitted back and forth
      via IPC between writer (-dev wxwidgets) and reader (wxPLViewer).
    
    * Separate header data from plbuf data in the data that are
      transmitted between writer and reader.  This means that within the
      shmbuf struct that MemoryMapHeader header data are transmitted via
      the header field, and plbuf data are transmitted via the data field.
    
    * Separate header data (as a private MemoryMapHeader m_header variable
      within the wxPLDevice class) from shmbuf data (which is strictly
      used just to transmit the header data and not store it).  The same
      change has implemented for the wxPlFrame class.  The net result of
      these changes is a complete separation of instance header
      information from shmbuf header information.
    
    * Change all use of memmove to memcpy (since we now have complete
      separation of storage of header information (i.e., in the private
      instance m_header variables) from the staging area in shmbuf used to
      tranfer that header information.
    
    * For the PLMemoryMap class implement the moveBytesWriter,
      moveBytesReader, moveBytesReaderReversed, and
      moveBytesWriterReversed methods where the first two implement
      transmission from writer to reader and the second two implement
      transmission from reader to writer.
    
    For the case when -DPL_WXWIDGETS_IPC2=ON, the current status is this
    new IPC method is used in a mature way on the writer (-dev wxwidgets)
    side but so far is mostly just used to confirm the data transmissions
    completed successfully on the reader (wxPLViewer) side.  That is, at
    run time the new IPC method is used to transfer header data (including
    viewerOpenFlag = 1) from reader (wxPLViewer) to writer (-dev
    wxwidgets) at the start, use wxPLDevice::TransmitBuffer on the writer
    side as appropriate (including sending the header completeFlag = 1 at
    the end) to send a header and optional plbuf data to the reader, and
    on the reader side reading that information with
    wxPlFrame::ReadTransmission, dumping out some key header values (to
    show the data were received), but not acting on that data except to
    exit when header completeFlag = 1 is received at the end.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the wxwidgets and wxPLViewer targets for
    the case when -DPL_WXWIDGETS_IPC2=ON, and run-time testing the
    result using
    
    examples/c/x08c -dev wxwidget
    
    The result shows correct transmission of the header viewerOpenFlag = 1
    from reader to writer, correct transmission of BOP, plbuf data, and
    EOP trom writer to reader (once per page), and correct transmission of header
    completeFlag = 1 from writer to reader before the reader exits.  And
    all these plbuf data (roughly 2MBytes for the 10 pages of that
    example) are assembled and transferred in less than a second so it
    appears the transmission speed is already comparable with the
    -DPL_WXWIDGETS_IPC2=OFF case.
    
    For the -DPL_WXWIDGETS_IPC2=OFF case, the test_c_wxwidgets target built
    without issues and
    
    examples/c/x08c -dev wxwidgets
    
    (note no -np option) executed with no issues.
    
    So it appears the large code changes for the -DPL_WXWIDGETS_IPC2=ON
    case are not affecting the -DPL_WXWIDGETS_IPC2=OFF case.

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

commit e639c33b47132345077de6c7eac35b4b000d1f41
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Tue Feb 21 11:55:03 2017 -0800

    Remove trailing white space and style wingdi.c
    
    The recent flurry of commits that implemented the wingdi device driver
    left wingdi.c with some trailing whitespace and styling issues that
    this commit fixes.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running:
    
    scripts/comprehensive_test.sh
    grep -i warning ../comprehensive_test_disposeable/*/*/output_tree/*.out |grep -v cmake.out |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems'
    grep -i error ../comprehensive_test_disposeable/*/*/output_tree/*.out
    grep -iE 'found|symbol|undefined' $(find ../comprehensive_test_disposeable -name "build*ldd.out")
    grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable/*/*/output_tree/*.out |less
    
    (The subsequent commands after running the script check for unusual warnings, any errors, any
    ldd issues, and any PostScript difference issues.)  All of those checks showed no obvious
    build or run-time issues, and no regressions in PostScript difference issues except for
    a one-time *.pyc file corruption issue [when I first tried to
    run the script] that I have discussed recently on list.)
    
    N.B. This comprehensive testing was done with no constraints on the
    test to make sure that the changes to common files that all device
    drivers depend on that were made in this recent series of
    wingdi-related commits did not compromise the Linux build or execution
    of all other devices.  However, since wingdi is Windows only, this
    test obviously did not test wingdi itself.

M	drivers/wingdi.c

commit 5bb3b1e08fa1dd0053ce95080b4cbcafc3862dfb
Author: Jim Dishaw <jim@dishaw.org>
Date:   Sun Feb 19 23:13:49 2017 -0500

    Removed extraneous characters left when doing rebase
    
    Signed-off-by: Jim Dishaw <jim@dishaw.org>

M	include/drivers.h
M	include/plDevs.h.in

commit de5f710897faa7977d0e14923e9115af4d77d696
Author: Jim Dishaw <jim@dishaw.org>
Date:   Tue Jul 28 22:09:02 2015 -0400

    Incremental improvement to wingdi
    
    Signed-off-by: Jim Dishaw <jim@dishaw.org>

M	drivers/wingdi.c

commit 6eeb3db79479242492f82ff19af37d0445b513fd
Author: Jim Dishaw <jim@dishaw.org>
Date:   Thu Jun 18 21:59:49 2015 -0400

    Added the wait for input function
    
    Signed-off-by: Jim Dishaw <jim@dishaw.org>

M	drivers/wingdi.c

commit 26a690409deb33944f1a3df4e72c2be53f75fa9b
Author: Jim Dishaw <jim@dishaw.org>
Date:   Sun Jun 14 21:33:26 2015 -0400

    Minor corrections to the status bar layout
    
    Signed-off-by: Jim Dishaw <jim@dishaw.org>

M	drivers/wingdi.c

commit bc32f5c15d1a89404db35e8a03538009062fc3ee
Author: Jim Dishaw <jim@dishaw.org>
Date:   Mon Feb 20 00:01:19 2017 -0500

    Fixes the multiple keypress bug -- However this patch relies on a change in plbuf.c that is not in the plplot master branch. -- I am creating this patch without the plbuf.c changes to avoid making changes in plbuf.c because I'm not sure if they are needed given the other changes in plbuf.c -- The required changes are:
    
             remove "plbuf_tidy( pls );" in plbuf_bop()
    	 add "plP_eop();" in rdbuf_eop()

M	drivers/wingdi.c

commit facf4c294f397c79b8a15fd6c5237dccaf215415
Author: Jim Dishaw <jim@dishaw.org>
Date:   Fri Jun 12 10:22:41 2015 -0400

    Added status bar to wingdi and improvements to printing
    
    - Modified the window to a parent with two children (plot area & status bar)
    - Preserved aspect ratio when printing
    
    Signed-off-by: Jim Dishaw <jim@dishaw.org>

M	cmake/modules/wingdi.cmake
M	drivers/wingdi.c
M	drivers/wingdi.driver_info.in

commit 43b687a311634ad1396b251c2dc5c2779b9cb277
Author: Jim Dishaw <jim@dishaw.org>
Date:   Tue Jun 9 21:33:28 2015 -0400

    Revised version of the wingdi driver that uses Windows text rendering
    
    - Added text rendering to replace text rendered by the PLplot core
    - Fixed print output
    
    Signed-off-by: Jim Dishaw <jim@dishaw.org>

M	drivers/wingdi.c

commit 213cb14abb06edb3704f7fb73686471633bcd7a4
Author: Jim Dishaw <jim@dishaw.org>
Date:   Sat Jun 6 00:11:52 2015 -0400

    Implement a new Windows GDI (wingdi) driver
    
    - Based on the wingcc driver
    - Is a pure GDI driver and does not use Freetype
    - Fixes problems that the wingcc driver (e.g. resizes can get clipped)
    - Intermediate step to using the GDI+ or DirectDraw API
    
    Signed-off-by: Jim Dishaw <jim@dishaw.org>

M	cmake/modules/drivers-init.cmake
M	cmake/modules/drivers.cmake
A	cmake/modules/wingdi.cmake
A	drivers/wingdi.c
A	drivers/wingdi.driver_info.in
M	examples/plplot_configure.cmake_installed_examples.in
M	include/drivers.h
M	include/plDevs.h.in
M	include/plcore.h
M	include/pldll.h.in
M	plplot_test/plplot-test.sh.in

commit cd13d659fdd57aa693ef97dc0fd62521bf999b48
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Feb 11 12:57:59 2017 -0800

    wxwidgets IPC: Start implementation of two-semaphore approach
    
    For the -DPL_WXWIDGETS_IPC2=ON case, drop all references to mutexes,
    and implement (but don't yet use) the PLTwoSemaphores class.
    
    N.B. this is just the first step toward the goal of getting the
    two-semaphores wxwidgets IPC method implemented and working
    properly.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) in the -DPL_WXWIDGETS_IPC2=ON case by a simple build
    test (using the wxwidgets and wxPLViewer targets) and in the
    -DPL_WXWIDGETS_IPC2=OFF case (to assure these changes are not
    affecting that case) of building the test_c_wxwidgets target (without
    obvious build or run-time issues) and (afterwards so all prerequisties
    were built) by running
    
    valgrind examples/c/x24c -dev wxwidgets
    
    with a valgrind error summary of
    
    ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

M	cmake/modules/wxwidgets.cmake
M	drivers/wxwidgets.h
M	drivers/wxwidgets_comms.cpp
M	drivers/wxwidgets_comms.h
M	drivers/wxwidgets_dev.cpp
M	plplot_config.h.in
M	utils/wxplframe.cpp
M	utils/wxplframe.h

commit 85135ae7bc2fa8027b925e9ce5bddba9de045a93
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Thu Feb 9 14:41:48 2017 -0800

    wxwidgets IPC: Drop use of unnamed semaphores for the one-semaphore case
    
    Implementation of unnamed semaphores for the one-semaphore case was a
    useful proof of concept, but ultimately if the two-semaphores case
    works, all the one-semaphore code will be removed, and if the
    two-semaphores case does not work, then the one-semaphore code will stay,
    but there will be no particular advantage to using unnamed semaphores
    in that one-semaphore case.  So before embarking on the two-semaphore
    implementation simplify the one-semaphore case by dropping the
    unnamed semaphores alternative for it.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_c_wxwidgets target (without obvious
    build or run-time issues) and
    (afterwards so all prerequisties were built) by running
    
    valgrind examples/c/x24c -dev wxwidgets
    
    with a valgrind error summary of
    
    ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

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

commit c4be63e854164236ad1378d9df7c49ed5e7ab443
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Feb 6 14:42:06 2017 -0800

    Style a previous commit

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

commit fb9509467b6dba80128b3ba90215771ab310e1b9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Feb 6 14:26:34 2017 -0800

    wxwidgets IPC: Fix named semaphores shared memory leak
    
    Before this fix, here was a recent result for the shared memory
    location on my (Linux) system.
    
    software@raven> ls -lt /dev/shm/sem* |head
    -rwx------ 1 software software 32 Feb  6 13:34 /dev/shm/sem.plplotMemoryMapAFJTJFKNBFmut*
    -rwx------ 1 software software 32 Feb  6 13:34 /dev/shm/sem.plplotMemoryMapNXUTQOHHYYmut*
    -rwx------ 1 software software 32 Feb  6 12:52 /dev/shm/sem.plplotMemoryMapLGGQKHSSQXmut*
    -rwx------ 1 software software 32 Feb  6 12:51 /dev/shm/sem.plplotMemoryMapYSMGRTYXSXmut*
    -rwx------ 1 software software 32 Feb  6 12:51 /dev/shm/sem.plplotMemoryMapGVUGAQOFORmut*
    -rwx------ 1 software software 32 Feb  6 12:50 /dev/shm/sem.plplotMemoryMapBGRGBXRBHFmut*
    -rwx------ 1 software software 32 Feb  6 12:50 /dev/shm/sem.plplotMemoryMapDGHOQFIRQSmut*
    
    where each example run with -dev wxwidgets (using the default
    -DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=OFF) permanently created one of
    these.  Because of the small size of each of these shared memory areas
    this was a minor shared memory leak.  Nevertheless it was good to get
    this cleaned up by following the call to sem_close in the PLNamedMutex
    destructor with a call to sem_unlink.  According to the Linux man
    page for sem_overview
    
    "POSIX named semaphores have kernel persistence: if not removed by sem_unlink(3), a semaphore will exist until the system is shut down."
    
    After this change and as expected from the above man page remark about
    sem_unlink /dev/shm showed no additional persistent shared memory
    areas were being left behind by each example run with -dev wxwidgets,
    i.e., this fix solved the above shared memory leak.

M	drivers/wxwidgets_comms.cpp
M	drivers/wxwidgets_comms.h

commit e705f7a7619ce9a32116fa8dc8708aa760fc9001
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Feb 6 12:53:43 2017 -0800

    wxwidgets IPC: implement use of unnamed semaphores
    
    This commit completes case 1 that was discussed on list where for
    the present one-semaphore approach (which requires use of sleep and
    mutex API) an unnamed semaphore is used (if
    -DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=ON) instead of a named semaphore.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the target test_c_wxwidgets and
    subsequently running
    
    examples/c/x16c -dev wxwidgets
    
    For both the -DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=ON and
    -DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=OFF cases.  As expected (since the
    same fundamental single-semaphore approach is used in both cases) I
    could find no difference in results between those two options.  For
    example, for both cases the time when wxPLViewer GUI's were on the
    screen was 60 seconds for test_c_wxwidgets and 14 seconds for the
    example 16 test above (where the enter key was pressed a lot to keep
    the page display moving as fast as possible).

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

commit c1e5962b4ea209219f6f39200c31fc78ef23c782
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date:   Sun Feb 5 09:23:53 2017 +0000

    Initialised remaining member variables in PlDevice
    
    although Alan had good valgrind results. It looked to me like if someone
    happened to try to draw unicode character 0x0000 for their first
    string then the current check for the size of the previous character
    could succeed and return garbage. Plus it is good practiace to initilise
    memer variables to sensible initial values.
    
    All these variables are now initialised to 0. Which means if the first
    size requested is of a 0x0000 character with size 0 and FCI 0 then the
    check for an existing size will succeed and will return sizes of 0,
    which is consistent.

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

commit d2218b320bd01af876ef51885a518d8366cc562b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Feb 4 18:30:32 2017 -0800

    wxwidgets driver: Fix uninitialized variable issue reported by valgrind
    
    The variable m_prevSymbol was uninitialized for its first test in
    PlDevice::DrawTextLine (reported by valgrind but also obvious by
    inspection).  The solution was to initialize it (in the constructor
    thanks to a tip from Phil) to an invalid value (so the initial test
    fails as it should before further tests are done with valid values of
    m_prevSymbol determined later in PlDevice::DrawTextLine).
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building test_c_wxwidgets (to build all prerequisites)
    then executing
    
    valgrind examples/c/x00c -dev wxwidgets
    
    with a good (unlike before this fix) valgrind summary,
    
    ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

M	drivers/wxwidgets.h

commit 3da0c90048e2e7ebd578a1566d40a7050645f357
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Sat Feb 4 13:59:51 2017 -0800

    wxwidgets IPC: Use a struct for the shared memory area
    
    If the PL_HAVE_UNNAMED_POSIX_SEMAPHORES macro is #defined
    use a shmbuf struct for the shared memory buffer that contains
    a fixed-size character array buf and some other essential
    fields.
    
    This change potentially allows (a) (with the cnt element of the shmbuf
    struct) keeping track of how many bytes are used in the char array,
    and (b) (with the wsem and rsem elemenst of the shmbuf struct) use of
    two unnamed semaphores to control the IPC.  But for now cnt, wsem, and
    rsem remain unused.
    
    If the PL_HAVE_UNNAMED_POSIX_SEMAPHORES macro is #defined
    this change means that the getBuffer and getSize methods
    of the PLMemoryMap class respectively return the location
    and size of the character array buf within the shmbuf struct.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building test_c_wxwidgets (to build all prerequisites)
    and then running various C examples with -dev wxwidgets without
    any noticeable run-time issues.  Also, I took a look in /dev/shm
    to determine the size of the memory buffer which is now 72 + 1024*1024
    rather than 1024*1024 as before.  The three extra fields in shmbuf
    are of types sem_t, sem_t, and size_t with corresponding sizes of
    32 (according to /usr/include/x86_64-linux-gnu/bits/semaphore.h), 32, and 8
    which is exactly consistent with the 72 if there are no alignment bytes
    in the struct.

M	cmake/modules/wxwidgets.cmake
M	drivers/wxwidgets_comms.h
M	drivers/wxwidgets_dev.cpp
M	plplot_config.h.in

commit 7ed66632b9a65e351477de8c5072352645638c2b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Feb 3 11:59:32 2017 -0800

    cairo driver: implement eop-wait split for wincairo device
    
    As of commit 5867959 "Fix to the multiple keypress bug on page
    advance" (2015-06-15) by Jim Dishaw the former EOP state was split for
    interactive devices between EOP (used for all code that ran at EOP
    with pls->nopause true) and WAIT (used for all code that previously
    ran at EOP with pls->nopause false, i.e., code run at former EOP that
    needed user interaction such as pressing the enter key to advance the
    page).  If interactive drivers were not adjusted for this change, they
    would continue to work in legacy mode except that the new EOP call
    that was inserted into plbuf would incorrectly generate wait activity.
    
    This commit finally adjusts the wincairo device for this eop-wait
    split, i.e., it should no longer be a legacy mode device with regard
    to the eop-wait split.  The former plD_eop_wincairo function has now
    been split into two functions called (new) plD_eop_wincairo and
    plD_wait_wincairo with the former reserved for all former EOP activity
    for the pls->nopause true case (of which there was none so
    plD_eop_wincairo is now empty, and the latter reserved for all former
    EOP activity for the pls->nopause false case, i.e., all code that used
    to be in plD_eop_wincairo without the redundant check that
    pls->nopause was false.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the cairo device (to test that these code
    changes did not affect that build.  However, that build completely
    ignored all wincairo parts of the code because that is only enabled on
    Windows.  Therefore, this change to the source code for the Windows-only
    wincairo interactive device needs to be both build tested and run-time
    tested on Windows.

M	drivers/cairo.c

commit 8354e4615eac7d0882b10e3e4d2f627dce4af962
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Feb 3 10:27:35 2017 -0800

    tkwin driver: fix obvious bug in eop-wait split implementation
    
    The pls->nopause false part of the eop code was previously copied
    (rather than moved) from plD_eop_tkwin to plD_wait_tkwin.  Address
    this issue by removing the pls->nopause false code from plD_eop_tkwin.
    Also remove the redundant check for pls->nopause false from
    plD_wait_tkwin.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by building the test_wish_runAllDemos (to build
    all prerequisites) and then following the test procedure
    in examples/tk/README.tkdemos to run runAllDemos.tcl from wish.
    The "package require Plplotter" command dynamically loads
    the tkwin shared object according to ./../bindings/tk-x-plat/pkgIndex.tcl,
    and apparently that loading occurred without issues.  However, there
    is something wrong with the actual runAllDemos.tcl script for this
    wish case because all the x00, etc., commands are unrecognized.  If
    I add "." to auto_path, that issue seems to be addressed, but then
    the examples hang.  So this is not a good test result, but I
    also don't think this is a regression because this test has not worked
    properly for a long time.  So all that is claimed here is this change
    does not affect dynamic loading of the tkwin shared object and does
    not appear to introduce any regressions for an already bad test case.
    
    test_plserver_runAllDemos target
    (which uses
    The (not very good) GUI result seems to work as well as before.

M	drivers/tkwin.c

commit 0ba44e878b1cdf03c507efc4b026f95663c7a06a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Fri Feb 3 10:06:46 2017 -0800

    wxwidgets driver: implement eop-wait split
    
    As of commit 5867959 "Fix to the multiple keypress bug on page advance"
    (2015-06-15) by Jim Dishaw the former EOP state was split for interactive
    devices between EOP (used for all code that ran at EOP with pls->nopause
    true) and WAIT (used for all code that previously ran at EOP with pls->nopause
    false, i.e., code run at former EOP that needed user interaction such as pressing
    the enter key to advance the page).  If interactive drivers were not adjusted
    for this change, they would continue to work in legacy mode except that the
    new EOP call that was inserted into plbuf would incorrectly generate wait activity.
    
    This commit finally adjusts the wxwidgets driver for this eop-wait
    split, i.e., it should no longer be a legacy mode driver with regard
    to the eop-wait split.  The former plD_eop_wxwidgets function has now
    been split into two functions called (new) plD_eop_wxwidgets and
    plD_wait_wxwidgets with the former reserved for all former EOP
    activity for the pls->nopause true case, and the latter reserved for
    all former EOP activity for the pls->nopause false case.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by spot checking a number of different C examples with
    -dev wxwidgets with and without this commit, with and without the -np
    option, and trying interactive page resizing on a number of them.  In
    all cases I could see absolutely no difference in results with and
    without this commit.  In particular, known bugs that might possibly be
    affected by this change continue as they were.  For example, the
    inefficieny continues in exactly the same way (with and without -np)
    for example 8, page 1 of example 16 has an incorrect (black rather
    than white) background color, and on multipage examples, resizes work
    on the first page, but do not work correctly (they always resize to
    the previous mouse position rather than the current mouse position) if
    you advance the page by hitting the "enter" key or return to the first
    page by hitting the "PageUp" key (e.g., on example 4).

M	drivers/wxwidgets.cpp
M	drivers/wxwidgets.h

commit 5b527169dc5434403c36194ea408b65169deba13
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jan 30 23:14:07 2017 -0800

    The cairo device driver: fix bug in aStream->xdrawable_mode logic
    
    The test for aStream->xdrawable_mode had to be moved from
    plD_eop_xcairo (where it effectively did nothing) to
    the start of plD_wait_xcairo where it returns immediately
    if aStream->xdrawable_mode is true.
    
    aStream->xdrawable_mode is only true if external_drawable is true
    and that value is only set by the extXdrawable_demo application.
    So the net effect of this bug fix is essentially all of
    plD_wait_xcairo is skipped for the extXdrawable_demo application
    case which is consistent with all of that code being skipped
    in like case when it was part of plD_eop_xcairo.
    
    As a result of this change the run-time error for the
    test_extXdrawable has been addressed (see below) so
    I have reinstated test_extXdrawable as a dependency of generic
    test targets again.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian testing) by building the test_c_xcairo, test_extcairo, and
    test_extXdrawable targets.  The first two are unaffected
    by this change (i.e., they continue to work fine as expected), and in addition
    the run-time error when running extXdrawable_demo for the 3rd target has
    now been addressed (because the plD_wait_xcairo code is skipped as it should be for
    this case).

M	drivers/cairo.c
M	examples/CMakeLists.txt

commit 6589caa47511978073bd9b00a09944d5458598af
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jan 30 21:11:32 2017 -0800

    Reinstate "5867959 Fix to the multiple keypress bug on page advance" for cairo device driver
    
    This reinstated (and unchanged) fix adjusts the cairo device driver
    (specifically the xcairo device) for Jim Dishaw's plbuf change similar
    to all the other changes he made for the other interactive devices
    (other than wxwidgets where this issue has yet to be addressed).
    
    As before the result of this change is there are no issues for -dev
    xcairo or the ext-cairo-test application you can build and run by
    building the test_extcairo target.  However, the extXdrawable_demo
    application that you can build and run by building the
    test_extXdrawable target _does_ have a run-time error that was not
    there before the present change.  But since the present change seems
    to be necessary for best results using plbuf, I thought I should
    expose this bug early in the present release cycle to motivate fixing
    it rather than limping along with having an xcairo device that was
    fundamentally inconsistent in a subtle way with plbuf like we were
    doing before.
    
    The run-time error that needs to be addressed with extXdrawable_demo is as follows:
    
    The program 'extXdrawable_demo' received an X Window System error.
    This probably reflects a bug in the program.
    The error was 'BadWindow (invalid Window parameter)'.
      (Details: serial 183 error_code 3 request_code 2 minor_code 0)
      (Note to programmers: normally, X errors are reported asynchronously;
       that is, you will receive the error a while after causing it.
       To debug your program, run it with the --sync command line
       option to change this behavior. You can then get a meaningful
       backtrace from your debugger if you break on the gdk_x_error() function.)
    examples/CMakeFiles/test_extXdrawable.dir/build.make:57: recipe for target 'examples/CMakeFiles/test_extXdrawable' failed
    make[3]: *** [examples/CMakeFiles/test_extXdrawable] Error 1
    CMakeFiles/Makefile2:5428: recipe for target 'examples/CMakeFiles/test_extXdrawable.dir/all' failed
    make[2]: *** [examples/CMakeFiles/test_extXdrawable.dir/all] Error 2
    CMakeFiles/Makefile2:5435: recipe for target 'examples/CMakeFiles/test_extXdrawable.dir/rule' failed
    make[1]: *** [examples/CMakeFiles/test_extXdrawable.dir/rule] Error 2
    Makefile:1846: recipe for target 'test_extXdrawable' failed
    make: *** [test_extXdrawable] Error 2
    
    Note the test_extXdrawable target continues to exist, but
    because of this known run-time error with this target I have removed it
    from the dependency lists of other more generic test targets so
    they will not be affected by this error.

M	drivers/cairo.c
M	examples/CMakeLists.txt

commit 8101dcd40c404803f4bc78b828af1dc616715450
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jan 30 18:32:22 2017 -0800

    Remove trailing whitespace (blanks and tabs)
    
    The previous script to do this has been renamed
    scripts/remove_trailing_blanks.sh ->
    scripts/remove_trailing_whitespace.sh
    
    That script has been modified so that instead of removing just trailing
    blanks it now removes both trailing blanks AND tabs.
    
    Running this script corrected a substantial number of trailing
    whitespace (tabs in this case) issues, and those changed files are
    included in this commit.  An unconstrained comprehensive test was done
    below to confirm no issues were introduced by this intrusive commit.
    
    Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
    (Debian Jessie) by running
    
    scripts/comprehensive_test.sh --do_submit_dashboard yes
    
    This test showed no obvious configure, build, or run-time issues,
    no ldd -r issues, no PostScript difference regressions, and no
    dashboard issues, i.e., this test was a
    complete success.

M	ChangeLog.release
M	README.Release_Manager_Cookbook
M	bindings/non_redacted_tcl/pltclgen
M	bindings/non_redacted_tk-x-plat/Plplotwin.tcl
M	bindings/non_redacted_tk-x-plat/plwidget2.tcl
M	bindings/non_redacted_tk/FileSelector.tcl
M	bindings/non_redacted_tk/Pltkwin.tcl
M	bindings/non_redacted_tk/plcolor.tcl
M	bindings/non_redacted_tk/plserver.tcl
M	bindings/non_redacted_tk/plwidget.tcl
M	bindings/octave/PLplot/arrow.m
M	bindings/octave/PLplot/contour.m
M	bindings/octave/PLplot/figure.m
M	bindings/octave/PLplot/free_fig.m
M	bindings/octave/PLplot/ginput.m
M	bindings/octave/PLplot/pldef.m
M	bindings/octave/PLplot/plot3.m
M	bindings/octave/PLplot/save_fig.m
M	bindings/octave/PLplot/set_view.m
M	bindings/octave/PLplot/shade.m
M	bindings/octave/PLplot/support/__pl_contour.m
M	bindings/octave/PLplot/support/__pl_draw_legend.m
M	bindings/octave/PLplot/support/__pl_mesh.m
M	bindings/octave/PLplot/support/__pl_meshplotit.m
M	bindings/octave/PLplot/support/__pl_plenv.m
M	bindings/octave/PLplot/support/__pl_plot3.m
M	bindings/octave/PLplot/support/__pl_plotit.m
M	bindings/octave/PLplot/support/__pl_store.m
M	bindings/octave/USAGE
M	bindings/octave/misc/diffn.m
M	bindings/octave/misc/gradn.m
M	bindings/python/plplot.py
M	bindings/qt_gui/pyqt4/plplot_pyqt4.sip
M	bindings/qt_gui/pyqt5/plplot_pyqt5.sip
M	bindings/swig-support/swig_documentation.i
M	bindings/tcl/pltclgen
M	bindings/tk-x-plat/Plplotwin.tcl
M	bindings/tk-x-plat/plwidget2.tcl
M	bindings/tk/FileSelector.tcl
M	bindings/tk/Pltkwin.tcl
M	bindings/tk/plcolor.tcl
M	bindings/tk/plserver.tcl
M	bindings/tk/plwidget.tcl
M	cmake/FindPLplot.cmake
M	cmake/modules/FindLTDL.cmake
M	cmake/modules/FindShapelib.cmake
M	cmake/modules/FindVGA.cmake
M	cmake/modules/Findhpdf.cmake
M	cmake/modules/language_support/cmake/CMakeAdaInformation.cmake
M	cmake/modules/tk.cmake
M	cmake/test_ada/cmake/Modules/CMakeAdaInformation.cmake
M	cmake/test_ada/scripts/comprehensive_test.sh
M	cmake/test_fortran/scripts/comprehensive_test.sh
M	cmake/test_linux_ipc/pshm_read.c
M	cmake/test_linux_ipc/pshm_write.c
M	doc/docbook/README.developers
M	doc/docbook/src/advanced.xml
M	drivers/CMakeLists.txt
M	examples/CMakeLists.txt
M	examples/ada/Makefile.examples.in
M	examples/ada/xtraditional22a.adb
M	examples/c++/Makefile.examples.in
M	examples/lua/x09.lua
M	examples/lua/x15.lua
M	examples/lua/x16.lua
M	examples/lua/x17.lua
M	examples/lua/x18.lua
M	examples/lua/x19.lua
M	examples/lua/x22.lua
M	examples/non_redacted_tcl/tcldemos.tcl
M	examples/non_redacted_tcl/x03.tcl
M	examples/non_redacted_tcl/x08.tcl
M	examples/non_redacted_tcl/x14.tcl
M	examples/non_redacted_tcl/x23.tcl
M	examples/non_redacted_tcl/x29.tcl
M	examples/non_redacted_tk/tk04.in
M	examples/non_redacted_tk/tkdemos.tcl
M	examples/octave/p11.m
M	examples/octave/p19.m
M	examples/octave/x00c.m
M	examples/octave/x06c.m
M	examples/octave/x09c.m
M	examples/octave/x17c.m
M	examples/octave/x20c.m
M	examples/octave/x21c.m
M	examples/octave/x25c.m
M	examples/octave/x33c.m
M	examples/perl/x25.pl
M	examples/python/pyqt4_example.py
M	examples/python/pyqt5_example.py
M	examples/python/tutor.py
M	examples/python/x14.py
M	examples/python/x15.py
M	examples/python/x16.py
M	examples/python/x17.py
M	examples/python/x18.py
M	examples/python/xtkpy
M	examples/tcl/tcldemos.tcl
M	examples/tcl/x03.tcl
M	examples/tcl/x08.tcl
M	examples/tcl/x14.tcl
M	examples/tcl/x23.tcl
M	examples/tcl/x29.tcl
M	examples/tk/tk04.in
M	examples/tk/tkdemos.tcl
M	scripts/comprehensive_test.sh
D	scripts/remove_trailing_blanks.sh
A	scripts/remove_trailing_whitespace.sh
M	src/CMakeLists.txt
M	src/README.pages
M	www/announce/html.xsl
M	www/announce/print.xsl
M	www/corefunctions.php
M	www/development.php
M	www/examples.php
M	www/index.php

commit ea278557c39e3dece8ee854848611d3bbd0d3f71
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jan 30 14:34:49 2017 -0800

    Prepare near-empty template for the next set of release notes.

M	README.release

commit 7921e7e041cbc9729ca747291e23157934eb8a9a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date:   Mon Jan 30 14:24:08 2017 -0800

    Release process: change when cumulated release notes are stored.
    
    Those cumulated release notes were previously stored in
    OLD-README.release but now that file is renamed as
    README.cumulated_release, and the final README.release notes are
    prepended to that file as the last step before the release is tagged.
    Therefore, README.cumulated_release should be up to date for the
    release tag and also the release tarball.  I also added
    README.cumulated_release to the files that are installed.

M	CMakeLists.txt
D	OLD-README.release
M	README.Release_Manager_Cookbook
A	README.cumulated_release
