commit aa8e3ddcaf2b554058ee279a3cd6abc05df64f54 Author: Alan W. Irwin 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 Date: Fri Aug 25 17:52:43 2017 -0700 Update notes for the release manager Tested by: Alan W. Irwin 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 . M scripts/comprehensive_test.sh commit b0cdaa9853c5f067a70114bf504bbd7b5ce297a6 Author: Alan W. Irwin 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 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 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 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 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 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 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 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 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 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 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 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 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 (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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 and links from that page). Tested by: Alan W. Irwin 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 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 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 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 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 , 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 _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 _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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Date: Sat Apr 29 15:17:25 2017 -0700 Build system: Output sip version Tested by: Alan W. Irwin on Linux (Debian Jessie) by looking at cmake output. M cmake/modules/qt.cmake commit 7653e24e49eba1742faf26604f55ffea68da9082 Author: Alan W. Irwin 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 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 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 ). 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 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 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 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 M bindings/python/CMakeLists.txt commit daa4b034eddded698041fc8257b204b6cca344cf Author: Alan W. Irwin 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 M examples/plplot_configure.cmake_installed_examples.in commit f25008fa5a8e72c946970e8c7b4889bfb6e34b47 Author: Alan W. Irwin 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 .) 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 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 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 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 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 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 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 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 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 (incorrectly classified as previously fixed), and Change 4 constitutes a workaround for . Tested by: Alan W. Irwin 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 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 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 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 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 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 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 Date: Sun Mar 12 18:11:05 2017 -0700 Style previous commit M drivers/wingdi.c commit 0479258002ec8cb468b00d29265353b068df5262 Author: Alan W. Irwin 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 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 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 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 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 , 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 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 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 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 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 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 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 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 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 Date: Mon Feb 27 16:35:04 2017 -0800 Style previous commit M drivers/wxwidgets_comms.cpp commit c39f93d87b8f3cefd03ca89384c8dcd76871ae97 Author: Alan W. Irwin 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 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 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 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 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 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 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 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 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 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 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::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 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 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 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 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 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 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 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 Date: Sun Feb 19 23:13:49 2017 -0500 Removed extraneous characters left when doing rebase Signed-off-by: Jim Dishaw M include/drivers.h M include/plDevs.h.in commit de5f710897faa7977d0e14923e9115af4d77d696 Author: Jim Dishaw Date: Tue Jul 28 22:09:02 2015 -0400 Incremental improvement to wingdi Signed-off-by: Jim Dishaw M drivers/wingdi.c commit 6eeb3db79479242492f82ff19af37d0445b513fd Author: Jim Dishaw Date: Thu Jun 18 21:59:49 2015 -0400 Added the wait for input function Signed-off-by: Jim Dishaw M drivers/wingdi.c commit 26a690409deb33944f1a3df4e72c2be53f75fa9b Author: Jim Dishaw Date: Sun Jun 14 21:33:26 2015 -0400 Minor corrections to the status bar layout Signed-off-by: Jim Dishaw M drivers/wingdi.c commit bc32f5c15d1a89404db35e8a03538009062fc3ee Author: Jim Dishaw 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 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 M cmake/modules/wingdi.cmake M drivers/wingdi.c M drivers/wingdi.driver_info.in commit 43b687a311634ad1396b251c2dc5c2779b9cb277 Author: Jim Dishaw 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 M drivers/wingdi.c commit 213cb14abb06edb3704f7fb73686471633bcd7a4 Author: Jim Dishaw 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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