PLplot Release 5.14.0
This is a release of the PLplot plotting package. It represents the
ongoing best efforts (roughly 150 commits since the last release) of
the PLplot development community to improve this package, and it is
the only version of PLplot that we attempt to support. Releases in
the 5.x.y series should be available roughly two times per year.
Note that PLplot has been continuously developed since 1986 so it has
accumulated a lot of cruft since that time. Therefore, we are now
slowing removing that cruft to improve the lot of both new users and
new members of the development team. As a result virtually every
PLplot release has some backwards incompatibilities introduced to help
clean it up so please pay careful attention to the OFFICIAL NOTICES
FOR USERS below (and also in the various sections of
README.cumulated_release if you need backward incompatibility
information for several recent releases) where we document such
incompatibilities to make life easier for those who have prior
experience with older PLplot releases.
If you encounter a problem with this release that is not already
documented on our bug tracker, then please send bug reports to PLplot
developers via our mailing lists (preferred for initial discussion of
issues) at <http://sourceforge.net/p/plplot/mailman/>. If it turns out
no quick resolution is possible via mailing-list discussion, then the
issue should be placed on our bug tracker at
<http://sourceforge.net/p/plplot/bugs/>.
This software is primarily distributed under the LGPL. See the
Copyright file for all licensing details.
________________________________________________________________
CONTENTS
1. OFFICIAL NOTICES FOR USERS
1.1 CMake version compatibility
1.2 Remove Fortran cruft
1.3 Remove Tcl/Tk cruft
1.4 Remove plmap cruft
1.5 Remove Perl/PDL examples
1.6 Remove all previously deprecated functions
1.7 Official deprecation of plshade1
1.8 Official deprecation of C++ cruft
1.9 plplot.org and www.plplot.org are now our official domains
1.10 We have removed the "sys" subdirectory from our source tree
1.11 Imported PLplot targets now must use the "PLPLOT::" prefix for the target name
1.12 Drop -single_module linking option that was previously forced for Mac OS X
1.13 Changed color interpolation for plscmap1l and plscmap1la
2. Improvements relative to the previous release
2.1 Bug fixes
2.2 Update control of Python version
2.3 Rewrite the build-system logic for determining PYQT_SIP_DIR and PYQT_SIP_FLAGS
2.4 Implement plStatic2dGrid
2.5 Replace use of the deprecated WIN32 and __WIN32__ macros by the _WIN32 macro
2.6 Difference report default device changed from psc to svg
2.7 Resolve the remaining difference report issues
2.8 Improve command-line parsing
2.9 Cleanup of plmap
2.10 wxwidgets development status
2.11 First step toward using best CMake-3 practices for our build system
2.12 Update PLplot to be consistent with modern free software
2.13 Rewrite documentation of PLplot testing
2.14 Configure the ps and psttf device drivers just like all other device drivers
3. PLplot testing
________________________________________________________________
1. OFFICIAL NOTICES FOR USERS
1.1 CMake version compatibility
Our build system is implemented using CMake. The minimum version of
CMake we allow is 3.7.2 on all platforms.
This particular PLplot release has been comprehensively tested for
CMake versions 3.7.2 through 3.13.1 on a variety of platforms (see
<http://sourceforge.net/p/plplot/wiki/Testing_Reports> for details
of recent tests on all platforms).
Therefore, if your CMake version is <= 3.13.1 and satisfies the above minimum
CMake version requirement there is an excellent chance that our build
system will work well. Furthermore, if you try later CMake versions
as they are released during the life of this PLplot release, our build
system will likely continue to work well because CMake has an excellent
reputation for preserving backwards compatibility. But if you get
build-system trouble for versions of CMake greater than 3.13.1, the
first thing you should try is CMake-3.13.1 which has been well-tested
by us.
1.2 Remove Fortran cruft
As of PLplot-5.12.0, a new Fortran binding was implemented using the
powerful capabilities of the Fortran 2003 iso_c_binding module which
was the replacement for the old binding that was implemented using a
combination of Fortran and C code. The new binding is much simpler,
more consistent, and more standards-compliant than the old binding and
has some powerful new features (e.g., both single and double
precision Fortran floating-point arguments are accepted). Therefore,
the new binding is necessarily backwards incompatible with the old
binding. For PLplot-5.12.0 we implemented the CMake option
-DPL_DEPRECATED_fortran=ON to provide temporary deprecated access to
the old Fortran binding, and that form of backwards compatibility
continued to be provided for the PLplot-5.13.0 release. However, it
appears our users are generally satisfied with the new binding, and we
no longer want to maintain or test that old binding. So for this
release the old Fortran binding (and an old set of Fortran standard
examples that depended on it) has been completely removed from our
source tree.
1.3 Remove Tcl/Tk cruft
As of PLplot-5.12.0, a new Tcl binding was implemented that used the
"redacted" PLplot API where all dimension arguments for arrays are
dropped from argument lists since those data are redundant (already
supplied by the arrays themselves). As a result of this change, Tcl
calls to the PLplot API in the old binding such as
$w cmd plline $nsize x y
now have to be replaced in the new binding by
$w cmd plline x y
and similarly for all other Tcl calls to the PLplot API that involve
array (tclmatrix) arguments. The advantages of this new binding are
it is cleaner, it is safer (i.e., automatically self-consistent with
regard to array dimensions), and it makes our Tcl binding compatible
with the rest of our bindings. (The only exception to this is our C++
binding which currently still uses simple C-style arrays and therefore
must use the non-redacted form of the PLplot API, but that may also
change in the future.) However, the disadvantage of this change is
our new binding is obviously backwards-incompatible with the old
binding. Therefore, for PLplot-5.12.0 we implemented the CMake option
-DUSE_NON_REDACTED_TCL_TK=ON to provide temporary deprecated access to
the old Tcl binding, and that form of backwards compatibility
continued to be provided for the PLplot-5.13.0 release. However, it
appears our users are generally satisfied with the new binding, and we
no longer want to maintain or test that old binding. So for this
release the old Tcl binding (and old versions of the Tcl standard
examples and Tk source code that depended on it) have been completely
removed from our source tree.
1.4 Remove plmap cruft
As of PLplot-5.9.10, a new version of plmap was implemented that used
shapefile format (accessed via shapelib) for maps. In addition other
powerful map API (see the last page of standard example 19) that
depended on shapelib map data was implemented as well. However, we
still made the old plmap implementation that depended on the
(undocumented) binary format of our *.map files available when the
user specified -DPL_DEPRECATED=ON, and this arrangement continued
through PLplot-5.13.0. However, it appears our users are generally
satisfied with the new shapefile-based plmap functionality and we no
longer want to maintain or test that old plmap functionality based on
the *.map format. So for this release that old plmap functionality
and associated *.map files have been completely removed from our
source tree.
1.5 Remove Perl/PDL examples
By historical accident and for just a limited time we actively
developed a set of standard examples written in Perl/PDL to help test
Doug Hunt's external PDL::Graphics::PLplot project. But we have now
removed those examples from our project since we have long since
stopped testing PDL::Graphics::PLplot with those examples, and, in any
case, such examples should be part of the PDL::Graphics::PLplot package rather
than PLplot.
1.6 Remove all previously deprecated functions
We removed plParseInternalOpts, plSetInternalOpt, plclr, plpage, plcol,
plcontf, plP_gvpd, plP_gvpw, plotsh3d, plSetOpt, plrgb, plrgb1, plhls,
and plwid. These functions were officially deprecated (i.e., only
accessible if the user specified the -DPL_DEPRECATED=ON cmake option)
as of the PLplot-5.9.10 release (and in some cases even before that
release) so it is long past the time to remove them. We edited
the source tree files to remove all mentions of these functions (as well
as plParseOpts, plHLS_RGB, plRGB_HLS, and plarrows that had
been previously removed). As a result
find . -type f |grep -v .git |xargs grep -E 'plParseInternalOpts|plSetInternalOpt|plclr|plpage|plcol|plcontf|plP_gvpd|plP_gvpw|plotsh3d|plSetOpt|plrgb|plrgb1|plhls|plwid' |grep -vE 'plcol0|plcol1|plcolorbar' |less
and
find . -type f |grep -v .git |xargs grep -E 'plParseOpts|plHLS_RGB|plRGB_HLS|plarrows' |less
now only find non-relevant hits or else hits for historical references
(e.g., change logs and release notes) to these functions.
1.7 Official deprecation of plshade1
The implementation of plStatic2dGrid (see 2.4) has made
the C routine plshade1 and its C++ wrapper pls->shade1 redundant.
Therefore, plshade1 and its C++ wrapper have now been officially
deprecated, i.e., only available if the CMake option -DPL_DEPRECATED=ON
is used.
1.8 Official deprecation of C++ cruft
The following C++ methods have been unofficially deprecated (via comments in the
code and lack of use in our C++ examples) for a long time:
// Previous function was inadvertently named plcol in old versions of
// plplot - this is maintained for backwards compatibility, but is best
// avoided in new code. Use col1 method instead.
void col( PLFLT c );
// Deprecated versions of methods which use PLINT instead of bool for logical arguments.
void svect( const PLFLT *arrow_x, const PLFLT *arrow_y, PLINT npts, PLINT fill );
void cpstrm( plstream &pls, PLINT flags );
void plot3d( const PLFLT *x, const PLFLT *y, const PLFLT * const *z,
PLINT nx, PLINT ny, PLINT opt, PLINT side );
void poly3( PLINT n, const PLFLT *x, const PLFLT *y, const PLFLT *z, const PLINT *draw, PLINT ifcc );
void scmap1l( PLINT itype, PLINT npts, const PLFLT *intensity,
const PLFLT *coord1, const PLFLT *coord2, const PLFLT *coord3, const PLINT *alt_hue_path );
void shade( const PLFLT * const *a, PLINT nx, PLINT ny,
PLDEFINED_callback defined,
PLFLT left, PLFLT right, PLFLT bottom, PLFLT top,
PLFLT shade_min, PLFLT shade_max,
PLINT sh_cmap, PLFLT sh_color, PLFLT sh_width,
PLINT min_color, PLFLT min_width,
PLINT max_color, PLFLT max_width,
PLFILL_callback fill, PLINT rectangular,
PLTRANSFORM_callback pltr, PLPointer pltr_data );
void shades( const PLFLT * const *a, PLINT nx, PLINT ny, PLDEFINED_callback defined,
PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax,
const PLFLT * clevel, PLINT nlevel, PLFLT fill_width,
PLINT cont_color, PLFLT cont_width,
PLFILL_callback fill, PLINT rectangular,
PLTRANSFORM_callback pltr, PLPointer pltr_data );
void shade( Contourable_Data& d, PLFLT xmin, PLFLT xmax,
PLFLT ymin, PLFLT ymax, PLFLT shade_min, PLFLT shade_max,
PLINT sh_cmap, PLFLT sh_color, PLFLT sh_width,
PLINT min_color, PLFLT min_width,
PLINT max_color, PLFLT max_width,
PLINT rectangular,
Coord_Xformer *pcxf );
void fshade( PLFLT ( *f2eval )( PLINT, PLINT, PLPointer ),
PLPointer f2eval_data,
PLFLT ( *c2eval )( PLINT, PLINT, PLPointer ),
PLPointer c2eval_data,
PLINT nx, PLINT ny,
PLFLT left, PLFLT right, PLFLT bottom, PLFLT top,
PLFLT shade_min, PLFLT shade_max,
PLINT sh_cmap, PLFLT sh_color, PLFLT sh_width,
PLINT min_color, PLFLT min_width,
PLINT max_color, PLFLT max_width,
PLFILL_callback fill, PLINT rectangular,
PLTRANSFORM_callback pltr, PLPointer pltr_data );
void spause( PLINT pause );
void stripc( PLINT *id, const char *xspec, const char *yspec,
PLFLT xmin, PLFLT xmax, PLFLT xjump, PLFLT ymin, PLFLT ymax,
PLFLT xlpos, PLFLT ylpos,
PLINT y_ascl, PLINT acc,
PLINT colbox, PLINT collab,
const PLINT colline[], const PLINT styline[], const char *legline[],
const char *labx, const char *laby, const char *labtop );
void xormod( PLINT mode, PLINT *status );
The above methods have now been officially deprecated, i.e., they will only
be accessible if a user sets -DPL_DEPRECATED=ON.
1.9 plplot.org and www.plplot.org are now our official domains
We have gone through the 3 steps in
<https://sourceforge.net/p/forge/documentation/Custom%20VHOSTs/> so that
plplot.org and www.plplot.org are now our official domains.
We have also gone through our source tree and replaced all instances
of plplot.sf.net and plplot.sourceforge.net with plplot.org. As a
result the website that is generated and uploaded by this release will
use the official plplot.org domain for all internal references. And
we have changed our official domain at sf.net/projects/plplot to
plplot.org as well. We encourage all PLplot users to use that
official PLplot domain as well.
1.10 We have removed the "sys" subdirectory from our source tree
This used to contain special build systems for special ports of PLplot
to various platforms, but over the years our CMake-based build system
turned out to be a better build system than these specials or else for
the given platform the special build system had been unmaintained for
many years and was therefore essentially worthless. The result has
been subdirectory after subdirectory has been removed from sys over
the years, and for this release the last such subdirectory (for the
so-called win-tk platform whose build system had not been maintained
for more than a decade) was removed from sys which allowed us to
remove sys as well.
1.11 Imported PLplot targets now must use the "PLPLOT::" prefix for the target name
This change is to conform to best CMake-3 practice. See further details
in 2.11 below.
1.12 Drop -single_module linking option that was previously forced for Mac OS X
We imposed this Mac OS X linking option to address a linking issue
that occurred for CMake on that platform 12 (!) years ago. We are
virtually positive from our google searches this linking issue no
longer exists so we have removed this option so that from now on
PLplot libraries and executables will be linked in a more standard way
on this platform.
1.13 Changed color interpolation for plscmap1l and plscmap1la
Previously these routines took control points for interpolating a new
colour map, but even if RGB coordinates were passed in, they were
converted to HLS coordinates and interpolated in HLS space. The new
behaviour of these routines is to interpolate in whichever space the
coordinates are passed in with. In addition to this change in
semantics, there was a backwards-incompatible change in the
names of the members of the PLControlPt C struct in plplot.h.
So those users whose code refers to this C struct will need
to modify their code appropriately.
________________________________________________________________
2. Improvements relative to the previous release
2.1 Bug fixes
The bug fixes in this release are noted in the roughly 150 commit messages
collected in ChangeLog.release.
2.2 Update control of Python version
The build system now takes the following steps to search for a suitable
Python version.
* The build system searches for the PLPLOT_PYTHON_EXACT_VERSION version
of Python where PLPLOT_PYTHON_EXACT_VERSION is specified by the
user. If this string is not specified by the user it defaults to
"", and this exact search therefore always fails in this case.
* If that first exact search is a failure and the option FORCE_PYTHON2
is not ON, the build system searches for PYTHON 3.
* If neither of the above two searches is a success, then the build
system searches for Python 2.
2.3 Rewrite the build-system logic for determining PYQT_SIP_DIR and PYQT_SIP_FLAGS
For pyqt4 the pyqtconfig module useful for determining PYQT_SIP_DIR
and PYQT_SIP_FLAGS has been deprecated and has therefore already
completely disappeared from some software platforms (e.g.,
MinGW-w64/MSYS2). Therefore, in this release we have replaced that
approach with an approach very similar to what we currently use for
pyqt5 (where the pyqtconfig module has never been available).
For both the pyqt4 and pyqt5 cases, PYQT_SIP_FLAGS is straightforward
to determine but determination of PYQT_SIP_DIR, the location where the
PyQT sip files are located, is not completely straightforward. For
Linux, Cygwin, and MinGW-w64/MSYS2, we feel we have the correct HINTS
in place to find this directory for either the pyqt4 or pyqt5 cases,
but for other platforms users can specify the correct PYQT_SIP_DIR
directly and are invited to communicate that information to us so we
can update our HINTS appropriately.
2.4 Implement plStatic2dGrid
The 2D matrix arguments of plshade, plshades, plcont, plimage, plvect,
etc., for our C API and corresponding C++ API must currently be
organized as Iliffe column vectors (see
<https://en.wikipedia.org/wiki/Iliffe_vector>) containing pointers to
PLFLT row vectors. And these matrices are normally in the C case
dynamically allocated with plAlloc2dGrid and freed with plFree2dGrid,
and in the C++ case the same thing is done with C++ wrappers for
plAlloc2dGrid and plFree2dGrid. However, that dynamically allocated
approach does not allow our C and C++ users to call plshade, etc.,
with statically allocated 2D matrices.
Historically we have partially addressed that issue by implementing a
plshade1 variant of plshade that could be called with a statically
allocated 2D matrix. Expanding that approach with plshades1, plcont1,
etc., variants is possible, but does considerably clutter our C and
C++ API. So instead for this release we have implemented the
plStatic2dGrid C function and associated C++ wrapper which allows C
and C++ users to determine the Iliffe column vector corresponding to a
2D statically allocated array. The examples/c/x15c.c and
examples/c++/x15.cc standard examples demonstrate how to use this new
approach to call plshade using 2D data that have been statically
allocated, and although none of our examples illustrate these
additional possibilities, this same approach could also be used to
call plshades, etc., with 2D data that have been statically allocated.
And since this new approach completely supersedes plshade1, we have
officially deprecated that function and its C++ wrapper, see 1.7.
2.5 Replace use of the deprecated WIN32 and __WIN32__ macros by the _WIN32 macro
In our C and C++ source code we now detect non-Cygwin Windows platforms
using the recommended _WIN32 macro (supported by all modern versions
of compilers that work on Windows platforms) rather than the deprecated
WIN32 and __WIN32__ macros.
2.6 Difference report default device changed from psc to svg
We have made extensive changes to our three (CMake-based, CTest-based,
and legacy) test systems (see
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot> for extensive
documentation of those test systems) to provide the user the freedom
(if they specify -DPLPLOT_TEST_DEVICE=<some test device name> to
choose any suitable PLplot device they like for the difference report
that is used to compare standard example results written for each
computer language that is supported by our bindings with the
corresponding C results. Of course, many such devices are not
suitable for such difference tests because of a number of factors, but
in the past we used -dev psc for this purpose, but recently we also
found -dev svg was suitable.
Of course, both the svg and psc devices share the advantage of having
no external library dependencies and thus they are available
on all platforms. However, the svg device has two notable advantages
over the psc device for the purposes of difference reports.
* The SVG XML format of the plot file output by the svg device file is
fundamentally easier for humans to learn than PostScript (at least
in this author's opinion) which makes it easier to debug rendering
errors.
* The svg device is a modern PLplot device that implements
alpha-channel transparency and gradients and which gives access to
virtually all (unicode-accessible) glyphs installed on a platform
while the psc device is an ancient PLplot device that because of the
limitations of PostScript is missing the alpha-channel and gradient
capabilities and which only gives access to an extremely limited
number of glyphs. Thus, when the svg device is used for
comparisons, test_diff.sh compares one *good* plot file (with the
exception of example 3 which is consistently missing some of its
graphical elements for some reason which we will investigate later)
result with another for all examples. However, when the psc device
is used for comparisons the difference test compares one garbage
plot file with missing or incorrect elements with another for many
of our standard examples. This means the svg choice supplies a much
stronger constraint on our language PLplot API consistency than the
psc choice.
For these reasons we have adopted -DPLPLOT_TEST_DEVICE=svg as the default value, and it
turns out for that much more powerful test of PLplot we are currently getting perfect
difference report results (see 2.7).
2.7 Resolve the remaining difference report issues
For PLplot-5.13.0 the difference report (for the psc comparison device
used for that report) was perfect except for the following
long-standing OCaml issues:
ocaml
Missing examples :
Differing graphical output : 16 19 33
Missing stdout :
Differing stdout
Those OCaml inconsistencies with the other languages have now been
fixed by the following steps:
* Implement the plmap* API for our OCaml binding and implement the
"Exmoor" page for examples/ocaml/x19.ml using that new API to
achieve consistency for this example.
* In examples/ocaml/x16.xml replace use of the high-level colorbar
function (which set and restored color which interfered with
consistency with the other languages) with plcolorbar to achieve
consistency for this example.
* In examples/ocaml/x33.ml implement all pages concerning
demonstrating the plcolorbar capability (page 5 onward) to achieve
consistency for this example.
This change removed all differences for the -dev psc test device but
since this change we have also moved from that device to -dev svg and
we find we get a clean difference report in that more powerful test
case as well.
In sum, because of the OCaml binding and examples improvements we
obtained a perfect PostScript difference report for the first time in
7 years, i.e.,
ocaml
Missing examples :
Differing graphical output :
Missing stdout :
Differing stdout
and similarly for all the other computer languages we support. And
these perfect results have now been also demonstrated for the much
stronger test when using the svg device for the comparison. Long may
this perfection continue!
2.8 Improve command-line parsing
2.8.1 Implement C demonstration of PL_PARSE_SKIP mode
The PL_PARSE_SKIP mode of plparsopts has been implemented for a long
time now in our core C library. What this mode does is parse the
PLplot-relevant command-line options, skip those which it does not
recognize and return a revised argument list containing the skipped
command-line options that is suitable for further specialized
(non-PLplot) parsing.
To demonstrate this capability we have implemented a -pl_parse_skip
example option for examples/c/x01c.c such that we get the following
result illustrating the PL_PARSE_SKIP capability:
software@raven> examples/c/x01c -pl_parse_skip xxx -dev psc yyy -o testc.psc zzz
argv prior to call of plparseopts(..., PL_PARSE_SKIP)
i = 0, argument = examples/c/x01c
i = 1, argument = -pl_parse_skip
i = 2, argument = xxx
i = 3, argument = -dev
i = 4, argument = psc
i = 5, argument = yyy
i = 6, argument = -o
i = 7, argument = testc.psc
i = 8, argument = zzz
argv after call to plparseopts(..., PL_PARSE_SKIP)
i = 0, argument = examples/c/x01c
i = 1, argument = xxx
i = 2, argument = yyy
i = 3, argument = zzz
PLplot library version: 5.13.0
Note that the valgrind results for the above command and also a more typical
execution of this example,
software@raven> examples/c/x01c -dev psc -o test1c.psc
PLplot library version: 5.13.0
are perfect (i.e., 0 errors, no leaks are possible) with no
PostScript differences between the above two commands other
than the date stamp.
2.8.2 Fortran improvement in parsing the command line
Previously the Fortran parsing API consisted of just
function plparseopts(mode)
integer :: plparseopts_brief !function type
integer, intent(in) :: mode
....
end function plparseopts
which allowed parsing of just PLplot-related command-line options with
no direct access to the command-line options.
We have now added the following experimental parsing API to the above:
* dynamic length and size
function plget_arguments( argv )
integer :: plget_arguments
character(len=:), dimension(:), allocatable, intent(out) :: argv
....
end function plget_arguments
function plparseopts(argv, mode)
integer :: plparseopts
character(len=:), intent(inout), dimension(:), allocatable :: argv
integer, intent(in) :: mode
....
end function plparseopts
* static length and dynamic size
function plget_arguments( argv, disambiguate )
integer :: plget_arguments
character(len=*), dimension(:), allocatable, intent(out) :: argv
integer :: disambiguate
....
end function plget_arguments
function plparseopts(argv, mode, disambiguate)
integer :: plparseopts_full !function type
character(len=*), dimension(:), allocatable, intent(inout) :: argv
integer, intent(in) :: mode
integer :: disambiguate
....
end function plparseopts
* static length and size
function plget_arguments( nargv, argv )
integer :: plget_arguments_impl !function type
integer, intent(out) :: nargv
character(len=*), dimension(0:), intent(out) :: argv
....
end function plget_arguments
function plparseopts(nargv, argv, mode)
integer :: plparseopts_full !function type
integer, intent(out) :: nargv
character(len=*), dimension(0:), intent(inout) :: argv
integer, intent(in) :: mode
....
end function plparseopts
The disambiguate variable of the static length and dynamic size
variants is required to distinguish between those variants and the
corresponding dynamic length and size variants. The static length and
dynamic size and static length and size variants are deprecated, but
we include them for now because certain Fortran compilers (see below)
might have trouble with the dynamic length and size variant of the API
even though that is part of the Fortran 2003 (!) standard.
plget_arguments is a convenience function that exercises the rather
complex Fortran API for determining command-line arguments and returns
all the the command-line components in argv. The three new variants
of plparseopts operate in a similar way to the C version of
plparseopts returning a modified form of argv that depends on which
mode is specified.
We tested these additions to the Fortran parsing API with
examples/x01f.f90, and Debian Testing gfortran version "Debian 8.2.0-9"
* If that source code is locally modified to change the
pl_parse_dynamic parameter from .false. to .true., and the x01f target
rebuilt then the following good results are obtained:
software@merlin> examples/fortran/x01f xxx -dev svg yyy -o testf.svg zzz
pl_parse_dynamic = T
argv before call to plparseopts(..., PL_PARSE_SKIP)
i = 0, argument = examples/fortran/x01f
i = 1, argument = xxx
i = 2, argument = -dev
i = 3, argument = svg
i = 4, argument = yyy
i = 5, argument = -o
i = 6, argument = testf.svg
i = 7, argument = zzz
argv after call to plparseopts(..., PL_PARSE_SKIP)
i = 0, argument = examples/fortran/x01f
i = 1, argument = xxx
i = 2, argument = yyy
i = 3, argument = zzz
PLplot library version: 5.13.0
* If that source code is locally modified to drop the above change and set the
pl_parse_static_length parameter from .false. to .true., and the x01f target
rebuilt then the following good results are obtained:
software@raven> examples/fortran/x01f xxx -dev svg yyy -o testf.svg zzz
pl_parse_static_length = T
argv before call to plparseopts(..., PL_PARSE_SKIP)
i = 0, argument = examples/fortran/x01f
i = 1, argument = xxx
i = 2, argument = -dev
i = 3, argument = psc
i = 4, argument = yyy
i = 5, argument = -o
i = 6, argument = testf.psc
i = 7, argument = zzz
argv after call to plparseopts(..., PL_PARSE_SKIP)
i = 0, argument = examples/fortran/x01f
i = 1, argument = xxx
i = 2, argument = yyy
i = 3, argument = zzz
PLplot library version: 5.13.0
* If that source code is locally modified to drop the previous local
change and change the pl_parse_static parameter from .false. to
.true., and the x01f target rebuilt then the good results above
(except for the difference
pl_parse_static_length = T ==> pl_parse_static = T
) continue to be obtained.
In all three test cases above, valgrind showed perfect results (0 errors with no leaks possible).
Note that when I tried these tests before with Debian Jessie (with gfortran-4.9.2) the first
test errored out with
"Fortran runtime error: Integer overflow when calculating the amount of memory to allocate"
We ascribe this error to a bug in gfortran-4.9.2 for the case of
character arrays that have both the length and size allocated. So we
recommend that old version of gfortran should be avoided, and it
appears more modern gfortran, e.g., gfortran 8.2.0 tested above, will
not have issues if we drop the deprecated forms of plget_arguments and
plparseopts in favour of the first method where an array of character
strings of both dynamic length and size is allocated. And that would
clear the way for following up by moving to uniform fortran arrays of
character strings that are dynamic in both length and size for our
entire Fortran API. That follow up would be terrific since it moves
our Fortran API and corresponding examples out of the Fortran
character array dark ages. However, there are other fortran compilers
(e.g., ifort, nagfor, absoft) we urgently need to test in the same way
with example 1 before we can go ahead and drop the above deprecated
functionality and do the suggested follow up.
2.9 Cleanup of plmap
We have removed old plmap functionality (see description of this
change in "1.4 Remove plmap cruft" above). In addition as part of
fixing a wrap bug we substantially simplified the code. And some
unused functions were also removed.
2.10 wxwidgets development status
This is a status report as of the release of PLplot-5.14.0 for the
"new" wxwidgets components (e.g., -dev wxwidgets, wxPLViewer
application, the wxwidgets binding, and wxPLplotDemo example
application that links to that binding) of PLplot.
Many bugs in the "new" wxwidgets components for this release (see the
ChangeLog for details) have been fixed. However, despite this
excellent development progress at least two serious issues for -dev
wxwidgets still remain.
* wxPLViewer only displays the end result of each page plotted.
Instead, it should immediately render that plot buffer as it is
actively filled with PLplot commands. That important change will
supply the required interactivity for example 17 (rather than just
plotting the end results for that one-page example) and make the -np
(no pause) option work correctly (where you can see all plot pages
as they are being plotted rather than just having a blank screen
99.99% of the time followed by a "flash" of the final page result at
the end of each page that is so short it is rarely visible). Note,
example 17 (without the -np option) and all examples including 17
with the -np option do render correctly for the interactive xwin,
tk, xcairo, and qtwidget devices so there should be no fundamental
reason for this functionality to work incorrectly for -dev
wxwidgets.
* AWI (Alan W. Irwin) and PR (Phil Rosenberg) have not yet decided on which of the
-DPL_WXWIDGETS_IPC3=OFF or ON methods should be used to handle
IPC (interprocess communication) between -dev wxwidgets and the
wxPLViewer application.
The -DPL_WXWIDGETS_IPC3=OFF case (developed by PR right when he
started developing the "new" wxwidgets code) uses a relatively large
circular buffer located in shared memory to efficiently transfer
data from one process to the other with transfer progress checked
periodically by a timed wait. The majority of this code is a subset
of code in an event-handling routine on the wxPLViewer side of
transfers so it is not (yet) organized as a dedicated set of two
routines (one to send one to receive) you call to transfer data as
in the -DPL_WXWIDGETS_IPC3=ON case discussed below. This method
works well for all noninteractive examples for both Linux and
Windows. And in older tests (before the above fixes) for -locate
mode of example 1 (that mode turns that normally noninteractive
example into an interactive example) PR found this method succeeded
on Windows while AWI found this method failed on Linux.
AWI has recently found for the latest version of the "new" wxwidgets
code (i.e., after all the above fixes were done) that interactive
example still has problems, i.e., the display did not come on
immediately so he had to mouse click on a particular part of the
blank screen (over one of the hidden viewports) for a while to get
the example to display properly on Linux for the
-DPL_WXWIDGETS_IPC3=OFF case.
The -DPL_WXWIDGETS_IPC3=ON case (developed by AWI long after PR had
initiated the work on his "new" wxwidgets code) uses a 3-semaphore
approach to transfer an arbitrarily large block bytes in an
efficient way from one process to the other using a relatively small
shared memory buffer with no timed waits. This complete transfer is
handled by just two function calls (transmitBytes on the
transmitting side and receiveBytes on the receiving side). Those
two routines use two semaphores to control the transfer in the way
described by the "Unnamed Semaphores Example" on page 73 and
following of
<http://man7.org/conf/lca2013/IPC_Overview-LCA-2013-printable.pdf>.
In addition, transmitBytes acquires a third semaphore before this
flow process starts and releases it after all bytes have been
transmitted to make sure that if other threads call transmitBytes,
they will just wait to acquire that third semaphore before
proceeding with its data transfer. So ordinarily there is absolutely no
interference between data transfers that occur in different threads.
However, there is at least one case (one thread transmitting bytes,
a second thread waiting to transmit bytes, but with
the first thread unable to regain process control for some reason (e.g.,
some screw up in handling wxwidgets events) where the first thread
will be unable to complete
its transfer ==> deadlock.
For -DPL_WXWIDGETS_IPC3=ON no such deadlocks have been observed on
any platform for noninteractive examples, but PR discovered such
deadlocks occurred on Windows when attempting to run the -locate
mode of example 1, and AWI also had trouble for this case on Linux.
But both these tests were done before all the recent wxwidgets fixes
(which apparently had nothing to do with IPC), and AWI has recently
discovered that interactive example now works well for the first
time ever! So an additional -DPL_WXWIDGETS_IPC3=ON test on Windows
platforms for this interactive case should be done to see if
whatever fixed -DPL_WXWIDGETS_IPC3=ON for the Linux case also fixes
the Windows case.
In sum, for noninteractive examples we should be fine on all
platforms with either -DPL_WXWIDGETS_IPC3=ON or OFF. And for the
latest version of "new" wxwidgets we are also fine on Linux with
-DPL_WXWIDGETS_IPC3=ON and the -locate mode of example 1. But that
interactive examples fails to work properly on Linux for
-DPL_WXWIDGETS_IPC3=OFF. And as far as I (AWI) am aware
-DPL_WXWIDGETS_IPC3=OFF and ON have not been tested for the latest
version of "new" wxwidgets on Windows. Given this uncertain testing
situation for the latest "new" wxwidgets code on Windows platform, I (AWI)
have adopted -DPL_WXWIDGETS_IPC3=ON as the default on the assumption
that the good noninteractive and interactive
results in the Linux case for -DPL_WXWIDGETS_IPC3=ON will carry over
to the Windows case when the latest version of the code is tested
on that platform. However, if a user runs into any trouble with this
default choice on any platform, please also try -DPL_WXWIDGETS_IPC3=OFF
and report back those two results to the plplot-general mailing list
so we have a chance to replicate the issue and fix it.
Furthermore if either of these serious issues with "new" wxwidgets
affect you in a way you cannot work around, you should also try
-DOLD_WXWIDGETS=ON to see if that gives a better result (although that
old wxwidgets code is in deep maintenance mode so we are unlikely to
change any part of it going forward in case issues with it are
discovered).
By the way, we have tried -DOLD_WXWIDGETS=ON, on Linux (Debian
Testing), and the following good results were obtained: (i) The -np
option does work properly (all example plots seen as they are plotted
out rather than just the final page result) if you test it by building
the test_c_wxwidgets target, (ii) example 17 does plot "interactively"
(rather than plotting final results at the end of the page) if you try
"examples/c/x17c -dev wxwidgets", and (iii) "examples/c/x01c -locate
-dev wxwidgets" works properly, i.e., the display and cursor position
show *before* you make a choice of where to click the mouse button.
However, for these ultra-modern (version 3.0.4) Debian Testing
wxWidgets libraries (this -DOLD_WXWIDGETS=ON problem did not
show up for the old wxWidgets libraries I tested for Debian Jessie =
Oldstable) you have to randomly move the mouse to get long plots such
as "examples/c/x08c -dev wxwidgets" and "examples/c/x17c -dev
wxwidgets" results completely plotted. So it appears that our "old"
code has exposed a bug in the Debian Testing wxwidgets libraries, but
that bug may not appear for other distributions so -DOLD_WXWIDGETS=ON
is certainly worth trying as a stop gap if there is some aspect of the
"new" wxwidgets PLplot code that is failing.
2.11 First step toward using best CMake-3 practices for our build system
Our CMake-based build system was originally designed more than a
decade ago for CMake-2 by a number of different PLplot developers, and
since then while maintaining this system I have taken full advantage
of CMake-3 backwards compatibility with CMake-2. The result works
well for cmake-3.7.2 (our minimum allowed cmake version) through
cmake-3.13.1 (the latest version of CMake that has been released).
However, our build system does not follow best CMake-3 practices as
outlined in [this inspiring
article](https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/).
Motivated by that article as well as by comments on the CMake mailing
list, I have now taken the first step toward such best practices which
is to always use prefixed target names (with a prefix of "PLPLOT::")
for read-only use of targets that are installed by the core build
and which are correspondingly imported by the build of the installed examples.
Of course, those imported targets are not available to the core build (since it
builds these special targets before installing/exporting
them) so the only way to implement the same "PLPLOT::" prefix
for these special targets in the core build is to implement ALIASed
versions of all these targets in the core build whose names all
have the "PLPLOT::" prefix. Both imported targets and ALIASed targets
can only be used by CMake commands which only read information about the target.
So for the sake of consistency, I changed
all read-only references to these special targets in the core build
by always using the "PLPLOT::" prefix for that case. In addition
for CMake commands which write information to targets
I used the prefix ${WRITEABLE_TARGET} for the target name.
As a result of these changes all special targets for both build systems
had a prefixed target name where the prefix was "PLPLOT::" in the
read-only case and ${WRITEABLE_TARGET} otherwise.
For normal use ${WRITEABLE_TARGET} must be empty since otherwise it
changes the actual installed library and executable names which
completely messes up any non-trivial use of the installed PLplot such
as the installed examples build system.
However, the configure_library_build and configure_executable_build
functions (the functions that are used in the core build to uniformly
configure builds of all special targets) have also been updated so
that a non-empty ${WRITEABLE_TARGET} changes the special library and
executable names while the original PLPLOT::<original target name>
remains the same and is aliased to refer to those changed writeable
targets and corresponding changed names for executables and libraries.
Thus, the net result is the core build and corresponding tests of that
build work when ${WRITEABLE_TARGET} is non-empty.
Normally nobody would be particularly interested in prefixing the name
of all special PLplot libraries and executables in a way that only
works in the build tree. However, there is one special case where
this capability is quite useful for developers, and that is when they
do a comprehensive test constrained just to the core-build
configurations with -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON (which is
the only case where a non-empty ${WRITEABLE_TARGET} is created). If
that comprehensive test is a success (which proved to be the case in
this release cycle after a fair number of iterations), then the
developer knows that there are no unprefixed special targets left in
our build system (since they would refer to library or executable
names that don't exist) with the caveat that only CMake code that is
actually exercised by the above comprehensive test is checked this way
by this test.
N.B. The second and third big steps toward best CMake-3 practices are
in the initial planning stages. Those steps which with luck will be
ready for the next release are the following:
* Replace all use of the completely unfocused include_directories
command (that effects builds of all targets in that directory and
below) with the the target_include_directories command which allows
us to define *and export* header file locations for one focused
target.
* Replace a grab-bag of ways to specify compile flags (some compiler options
some specific -D definitions) and another grab bag of ways to specify
compile definitions by calls
to target_compile_options and target_compile_definitions that not only
make these data available for the core target build but also the subset
of these data that are typically needed for building against the corresponding
imported targets.
In sum, we have made a good start toward updating our build system to
best CMake-3 practice for this release, and we plan to update it much
further in that regard for the next release. The net result of all
these intrusive changes should be that our build system will be
subject to fewer subtle bugs. And it should also be much easier to
maintain (e.g., during the coming expected advent of CMake-4 where several
deprecated CMake-2 commands such as the include_directories command
that we use now are likely to be dropped).
2.12 Update PLplot to be consistent with modern free software
This important series of changes occurred because the primary testing
platform for PLplot was changed from Debian Jessie (Debian 8) which
was more than 3 years out of date), to Debian Testing (currently
Debian Buster = Debian 10) which is a rolling release that keeps up to date
with modern free software development.
As a result of these changes, the PLplot core libraries, bindings, and device drivers
have now proven [via comprehensive tests](<https://sourceforge.net/p/plplot/wiki/Testing_Reports)
to be compatible with the following modern versions of free software packages:
* CMake-3.13.1 (core, bindings, and device drivers)
* gcc 8.2.0 (core)
* qhull 2015.2 (optional core interpolation functionality)
* shapelib 1.4.1 (optional core map functionality)
* swig 3.0.12 (java, lua, octave, and python bindings)
* gnatmake/gdc/gfortran 8.2.0 (ada, d, and fortran bindings)
* g++ 8.2.0 (c++ binding and psttf and wxwidgets device drivers)
* pango 1.42.3, cairo 1.16.0 (cairo device driver)
* openjdk 11.0.1 (java binding)
* lua 5.3.5 (lua binding)
* camlidl 1.05, ocaml 4.05 (ocaml binding)
* octave 4.4.1 (octave binding)
* python 3.6.7 (python binding)
* Qt 5.11.2 (qt binding and qt device driver)
* Tcl/Tk 8.6.8 (tcl/tk binding and tk device driver)
* libx11 2:1.6.7 (tk and xwin device drivers)
* wxWidgets 3.0.4 (wxwidgets binding and device driver)
Notes for this table:
* The Debian Testing package for swig 3.0.12 contains a swig fix that should be
generally released for swig-4 that allows PLplot to build an Octave-4.4 binding.
If your swig-3 version does not have this fix, you should use Octave-4.2
until swig-4 is released.
* The Debian Testing package for lua 5.3.3 currently perpetuates
[a serious bug](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238)
for that particular upstream version. The above good results for lua
5.3.5 were generated with a locally built version of upstream 5.3.5.
2.13 Rewrite documentation of PLplot testing
We have completely rewritten <https://sourceforge.net/p/plplot/wiki/Testing_Reports> which
documents how PLplot is tested.
2.14 Configure the ps and psttf device drivers just like all other device drivers
Previous to this change our build system configured the devices (i.e.,
the ps and psc devices) of the ps device driver together (i.e., the
CMake option DPLD_ps controlled both devices) but now it does that
individually (where DPLD_ps and DPLD_psc control the ps and psc
devices separately). And similarly for the psttf and psttfc devices
of the psttf device driver. Previous to this change, all other device
drivers configured their devices individually and now that the ps and
psttf device drivers are no longer anomalous in that regard, it has
allowed us to simplify our build system logic substantially for
anything having to do with the ps or psttf device drivers.
________________________________________________________________
3. PLplot testing
Comprehensive tests of this release are documented in
<https://sourceforge.net/p/plplot/wiki/Testing_Reports>.
In addition, developers and users who have used the git master tip
version for all their plotting needs during this release cycle have
provided additional important testing of this release of PLplot.
________________________________________________________________
DETAILED CHANGELOG FOR THIS RELEASE
commit 9e618c0b187ffe2a274a93b55287b46b9f43ffa7
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 11 17:56:32 2018 -0800
Prep for 5.14.0: Update instructions followed by the release manager for this release
M README.Release_Manager_Cookbook
commit 8a75fe2bfec38935e83a9f096e5179ff9cd0c96f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 11 17:28:30 2018 -0800
Prep for 5.14.0: Update the release tarball generating script
These changes were to change to the JOBS paradigm used for
other scripts to deal with parallel make processing, and
changing the way the make verbosity level is controlled
(using VERBOSE=1 make option rather than the -DCMAKE_VERBOSE_MAKEFILE=ON
cmake option).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by running the script and testing its results as
documented in README.Release_Manager_Cookbook.
M scripts/make_tarball.sh
commit eb440dda1de4ae74919d3778dadca383445c302d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 11 14:58:53 2018 -0800
Prep for 5.14.0: RELEASE_DATE=2018-12-12 and adjust for new version of plplot-doc-check
This update of RELEASE_DATE is consistent with the expected UTC date of the 5.14.0 release
and affects only the generated website documentation.
The new version (thanks to Hal Wang for this) of castxml-ready
plplot-doc-check code was required because the old version of that
code used the gccxml app which is not available for Debian Testing
because it has been completely superseded by castxml. So this change
is part of the overall project to make PLplot consistent with the
modern versions of free software.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by building a local version of the website using
time (echo irwin$'\n'irwin$'\n'merlin$'\n'/home/irwin/public_html/plplot$'\n'yes |scripts/generate_website.sh)
and checking that the generated documentation had the correct release date.
In addition, PLplot was configured with the cmake option
-DADD_SPECIAL_CONSISTENCY_CHECKING=ON which configures the
check_api_xml_consistency target. Building that target runs
the castxml-ready plplot-doc-check appropriately. Building
that target with an artificially introduced local api.xml
inconsistency quickly identified that inconsistency. So
this golang app seems to be a good one for finding such inconsistencies.
Finally, building that target without an introduced inconsistency
showed api.xml is consistent with plplot.h which is a good thing
to establish since it means our DocBook-generated documentation
concerning our API is consistent with our actual API!
M doc/docbook/src/CMakeLists.txt
commit c1871353a12195f7b0df10d5875623f27375dc6b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 11 11:20:00 2018 -0800
Prep for 5.14.0: Fix release critical bug introduced by commit plplot-5.13.0-47-g124a0c3a2
This bug was initially exposed by example 3 where all graphical elements were lost
in the results leaving only text that was plotted regardless of device. But later I discovered any
use of a non-zero -ori option for any of the rest of the examples also triggered this
same loss of all graphical elements in plotted results regardless of device. I used
make -j16 x01c ; make -j16 cairo
examples/c/x01c -dev xcairo -ori 0.001
as a test case and discovered via git bisect that
commit plplot-5.13.0-47-g124a0c3a2 was the first
to show the bad behaviour. One component of that
commit was bogus since it changed from calculating
plsc->diclpxmi, plsc->diclpxma, plsc->diclpymi, and
plsc->diclyma to (incorrectly) calculating those same
values for the incorrect plsc elements,
plsc->clpxmi, plsc->clpxma, plsc->clpymi, and
plsc->clyma. Assuming the original code was correct,
for this commit, I have reversed that part of commit plplot-5.13.0-47-g124a0c3a2
and discovered that solves the above "-ori 0.001" issue (i.e., all graphical
elements were restored) and also solves the same issue with
examples/c/x03c -dev xcairo
Furthermore, commit plplot-5.13.0-47-g124a0c3a2 fixed a
different rendering issue (missing graphical elements) in
examples/c/x33c -dev wxwidgets
that did not occur for any other device. But it turns out the present
commit preserves the good rendering for the above example as well as
for -dev xwin, -dev xcairo, and -dev qtwidget. And I also tried
examples/c/x01c -locate -dev wxwidgets -ori 0.1
and
examples/c/x33c -dev wxwidgets -ori 0.1
with perfect interaction for example 1, and perfect resizing and rendering for both
examples.
So I think I have found the fix for this bug with no deep
understanding of why this fix works except that not updating
plsc->diclpxmi, plsc->diclpxma, plsc->diclpymi, and plsc->diclyma
exactly like before commit plplot-5.13.0-47-g124a0c3a2 inside
calc_didev screws up all rendering when that routine is called (e.g.,
by the chain of calls plsdiori => pldi_ini => calc_diori =>
calc_didev).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by doing the rendering tests described above for example 1, example 3
and example 33 and by running
COMPREHENSIVE_TEST_PREFIX="/home/software/plplot/HEAD/comprehensive_test_disposeable blank"
time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.13.1/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "$COMPREHENSIVE_TEST_PREFIX" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON -DPLD_extqt=OFF" --build_command "make -j16" --ctest_command "ctest -j16" --do_submit_dashboard yes)
where -DUSE_INCRTCL_VERSION_4=ON is needed on this Debian Testing
platform to find Tcl/Tk, and -DPLD_extqt=OFF is needed to skip
comprehensive tests of qt_example and pyqt5 which sometimes segfault
in ways that will be investigated post-release.
The above command was followed by the evaluation procedure of
comprehensive test results documented in
doc/wiki_source/Testing_PLplot. That evaluation showed there were no
configure, build, or obvious run-time errors (i.e., no non-zero return
codes for any of the steps in this comprehensive test), and the
difference test results were perfect.
I also regenerated the local version of the website using
time (echo irwin$'\n'irwin$'\n'merlin$'\n'/home/irwin/public_html/plplot$'\n'yes |scripts/generate_website.sh)
and that local website passed all tests documented in
README.Release_Manager_Cookbook including that the example 3
screenshot had its graphical elements rendered correctly (where
the lack of those was the first symptom to set off this bug hunt).
M src/plcore.c
commit b5108131ff70561d843296945493595f116f8752
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 10 23:51:30 2018 -0800
Prep for 5.14.0: update handling of parallel build option in scripts used for website update
Previous to this change, we used in these scripts
an undocumented
PARALLEL_BUILD_OPTION=-j10
or for htdocs-gen_plot-examples.sh we used the incorrect (so I
have no idea how it worked before without the hyphen)
PARALLEL_BUILD_OPTION=j10
and later in these two scripts we used the style
make $PARALLEL_BUILD_OPTION <targetname>
to handle parallel builds. But now we use a different style in these
two scripts which is setting a well-documented value of
JOBS=16
and later in these two scripts we used the style
make -j$JOBS <targetname>
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by testing local website generation (which uses these
two scripts) as documented in README.Release_Manager_Cookbook.
N.B. That local website testing found a release-critical bug in
anything to do with reorientation of plots in the PLplot core library
which was exposed by example 3 losing all graphical elements so only
text was left in the plot. That bug will be addressed next.
M scripts/generate_website.sh
M scripts/htdocs-gen_plot-examples.sh
commit c8f41d3197941be632df054674e970e7b17e9cdd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 10 13:47:46 2018 -0800
Prep for 5.14.0 release: Update swig documentation to be consistent with DocBook documentation
I implemented this change by configuring PLplot with
-DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the
check_swig_documentation target. I checked differences between the
build-tree version of swig_documentation.i that is generated by that
target and the older source-tree version. That diff looked good so I
copied the build-tree version on top of the source-tree version.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by configuring PLplot with
-DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the
check_swig_documentation target without issues (after the above copy).
I used "git diff" to evaluate the changes to the source-tree version
of swig_documentation.i, and I also ran the python and octave
documentation tests decribed in doc/docbook/README.developers to
confirm the changes seemed appropriate.
N.B. The Python test showed a (likely long-standing) indentation issue
in the Python documentation that is associated with the <parameter>
DocBook tag. This issue will need further investigation after the
5.14.0 release.
M bindings/swig-support/swig_documentation.i
commit 2ac040345edbd84ab004359cbc4cb0397c75f2af
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 10 13:02:17 2018 -0800
In preparation for the 5.14.0 release, make check_plplot_h.inc target build without deprecation warnings
This commit is also part of the overall upgrade of PLplot to be
consistent with the modern free software stack (Debian Testing in this
case). In this case to stop the deprecation warnings by modern OCaml
software we adjusted the OCaml logic in touchup.ml to replace the
deprecated String.lowercase with String.lowercase_ascii. We made sure
that this is the only place where we used this deprecated function
using
software@merlin> find . -type f |grep -v .git |xargs grep String.lowercase
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by building the check_plplot_h.inc target without
any warnings or errors.
M bindings/ocaml/touchup.ml
commit ee1583dece821e68a46be0b4d9114c9a376d2b82
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 10 12:55:04 2018 -0800
In preparation for the 5.14.0 release, update the instructions for testing our DocBook documentation
This commit is also part of the overall upgrade of PLplot to be consistent with
the modern free software stack (Debian Testing in this case).
M doc/docbook/README.developers
commit c89b873fd89f87a8648669f5799321750a63690d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 9 17:08:22 2018 -0800
Tweak wording: two option ==> two options
M doc/docbook/src/api.xml
commit 8c92f45af92112d70ec7063f6e2abf61d86e4d3d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 9 14:27:32 2018 -0800
Update from doxygen 1.8.8 to 1.8.13 in preparation for the release of 5.14.0
This commit is also part of the overall upgrade of our free software
dependencies to Debian Testing (currently the same as Debian Buster)
which is a rolling release whose free software versions are typically
close to the latest upstream releases. (For example,
<http://www.doxygen.nl/download.html> states the latest doxygen
release right now is 1.8.14 so doxygen 1.8.13 that is packaged by
Debian Testing is behind that upstream version but not by very much.)
To upgrade our doxygen configuration to 1.8.13, I followed
the directions in (the updated) doc/README.doxygen and executed
doxygen -u Doxyfile.in
I also updated the testing directions in doc/README.doxygen.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Testing) by inspecting the Doxyfile.in change generated above
with "git diff" and following the additional test directions in the
updated doc/README.doxygen file.
M doc/Doxyfile.in
M doc/README.doxygen
commit 5cac57603d7137d16a2a76240be1c075ea940726
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 9 01:26:11 2018 -0800
Update version information in preparation for the 5.14.0 release
In particular with regard to library version numbers I looked
carefully at directory-selected git log and git diff results for this
release cycle, e.g.,
git log --name-status plplot-${old_plplot_version}..master bindings/fortran
git diff --ignore-all-space plplot-${old_plplot_version}..master bindings/fortran
to help decide whether one of our libraries was unchanged, had bug
fixes with no API changes, had API additions, or had
backwards-incompatible changes in the API, and then updated the
library versions according to the
[semantic versioning rules](https://semver.org/).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by using "git diff" to check for typographical
errors in this change and also by running
COMPREHENSIVE_TEST_PREFIX="/home/software/plplot/HEAD/comprehensive_test_disposeable blank"
time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.13.1/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "$COMPREHENSIVE_TEST_PREFIX" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON -DPLD_extqt=OFF" --build_command "make -j16" --ctest_command "ctest -j16" --do_submit_dashboard yes --do_test_interactive no)
followed by the evaluation procedure documented in doc/wiki_source/Testing_PLplot
That evaluation showed there were no configure, build, or obvious
run-time errors (i.e., non-zero return codes for any of the steps in this
comprehensive test), and the difference test results were perfect.
M cmake/modules/plplot_version.cmake
M www/examples.php
commit 472f35dc84a0cabc666889ef7b56250fd52231b8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 8 21:20:59 2018 -0800
Finalize the release notes for release 5.14.0
These notes were finalized based on a preliminary version of our ChangeLog for
this release.
The above finalized release notes are stored in README.release. I have
also updated our cumulated release notes as follows:
cat README.release README.cumulated_release > README.cumulated_release_new
mv README.cumulated_release_new README.cumulated_release
M README.cumulated_release
M README.release
commit 6e7b51cae6609bb22a94074eb720b1b16e960970
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Dec 6 01:04:49 2018 -0800
Interim update of README.release as part of the on-going release process for 5.14.0
In preparation for the 5.14.0 release I added a number of sections to this document, and spell-checked everything. However, there are likely four more sections to add corresponding to important
changes made during this release cycle before this document is ready for the release of 5.14.0.
M README.release
commit 39a15ae66c1429e9358bba3de9b5c5be5427891d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 3 15:01:05 2018 -0800
Add summaries of Alan's comprehensive tests for Debian Buster to our wiki Testing_Reports page
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by following the directions in README.developers to
propagate all the markdown format file changes to our SF wiki and test
them there.
M doc/wiki_source/Testing_Reports
commit 920d3983bfaa1fd7157f5f9574305171ee30db86
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 2 13:37:33 2018 -0800
Fix some remaining wiki_source issues
The command
software@merlin> find . -name "*.png"
./doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_labels.png
./doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_bare.png
./doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Non_antialized.png
./doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Antialized.png
shows that the recent wiki_source commits introduce *.png files for
the first time into our git repository.
This introduced two issues that were fixed in this commit.
* I had to change .gitattributes to be consistent with the binary nature of those files.
With the updated .gitattributes I got the following results
doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Antialized.png: text: unset
doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Non_antialized.png: text: unset
doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_bare.png: text: unset
doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_labels.png: text: unset
Previous to that change the results were "auto" instead, and I was
therefore concerned that those binary files had been corrupted when
they were committed since the documentation of "auto" says that
means git will change line endings (and therefore corrupt these
binary files). However, no such corruption occurred (see test
below) so I was probably saved (before the .gitattributes change) by
Linux native line endings = internal git repo line endings.
* I had to change scripts/remove_trailing_whitespace.sh to ignore *.png files.
This commit also solves three additional issues in doc/wiki_source
* I updated README.wiki to refer to the definitive directions in README.developers for
propagating markdown format changes in doc/wiki_source to our SF wiki.
* The updated scripts/remove_trailing_whitespace.sh indicated there
were trailing white space issues in some of the markdown format
files. Therefore, I instructed the script to remove the trailing
white space in all of those.
* I also discovered that the last few lines in some markdown format files were
inconsistent with the others, e.g., no trailing 'nl' or two of those. This
commit removes all those inconsistencies.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by downloading the *.png files again from the SF wiki
and showing there were no differences compared to those same files in
our git working directory, i.e., no corruption in the latter. I
also followed the directions in README.developers to upload all
the markdown format file changes to SF.
M .gitattributes
M doc/wiki_source/Building_PLplot
M doc/wiki_source/Configure_PLplot_for_cygwin
M doc/wiki_source/Configure_PLplot_for_msys2
M doc/wiki_source/Configure_PLplot_for_the_Visual_Studio_IDE
M doc/wiki_source/Home
M doc/wiki_source/Mac_OSX_Status
M doc/wiki_source/MinGW-w64-MSYS2
M doc/wiki_source/Overview_of_the_status_on_Windows
M doc/wiki_source/README.wiki
M doc/wiki_source/Testing_PLplot
M scripts/remove_trailing_whitespace.sh
commit 46fb96f5f69ba594867356df652960bc6155b3e2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 1 22:35:37 2018 -0800
Build system bug fix: drop install of recently removed README.testing
(A much newer version of this file is now named
doc/wiki_source/Testing_Plplot, and along with the other files in that
directory is not installed but instead used as the source of our SF
wiki following the directions in README.developers.)
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by building the install target without errors.
M CMakeLists.txt
commit 0d50e2a2aeb17b5408f55bae701a702f636b0c1a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 1 18:31:10 2018 -0800
Add summaries of Arjen's comprehensive tests for Cygwin and MinGW-w64/MSYS2 to our wiki Testing_Reports page
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by cutting and pasting the change to the SF edit GUI
for our Testing_Reports wiki page; saving the results there; and
testing them by making sure these two table entries were rendered
correctly, looking at exact differences with the previous version
using the SF history GUI for Home, etc.
M doc/wiki_source/Testing_Reports
commit 4537147b35769bc749b8acabf2983b2185f87762
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 30 13:50:49 2018 -0800
Update our directions for developers
Add a new section on how to update our wiki pages. Also remove a redundant paragraph
and tweak the writing.
M README.developers
commit 38f41b6bf5e04977ba66a77d5a934954a1c96908
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 30 11:32:46 2018 -0800
Add references to Testing_PLplot and Testing_Reports to our wiki Home page
Thanks, Arjen, for this good suggestion.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by cutting and pasting the change to the SF edit GUI for
our Home wiki page, saving the results there, and testing them by making
sure the new links from our home page were working, looking at exact differences
with previous version using the SF history GUI for Home, etc.
M doc/wiki_source/Home
commit fbf51065de293fb7c888fa3737864c64cf67fc0d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Nov 27 18:56:00 2018 -0800
Tweak MinGW-w64-MSYS2 wiki page
These tweaks consisted of spelling changes suggested by the
ispell-buffer emacs command and updating the Test_Reports wiki item
(the only wiki URL reference to that new wiki page), MYS2 wiki, and
OpenWalnut wiki URL references.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by cutting and pasting the revised MinGW-w64-MSYS2
file to the appropriate edit session of the corresponding wiki page at
SF, and looking at the wiki results and history diff results generated
from that edit session for any issues caused by these tweaks.
M doc/wiki_source/MinGW-w64-MSYS2
commit f7bedc70ad0cab21d36208fa434e540576898ccf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Nov 26 22:47:18 2018 -0800
Extensive further tweaking of the recently rewritten Testing_PLplot wiki page
Fixed misspellings revealed by the emacs ispell-buffer command.
Reviewed all URL's (which yielded tweaks for the CDash and our CDash
server references which were in a wrong form). To avoid rendering
issues caused by markdown sensitivity to "*", "<", and ">" had to
escape those characters as "\*", "<", and ">" when in ordinary
text. I also removed many "`" escapes that I previously used in text
since those created an unwanted different rendering (dark background)
of what was escaped that way.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by cutting and pasting the revised Testing_PLplot file
to the appropriate edit session of the corresponding wiki page at SF,
and looking at the wiki results generated from that edit session for
any URL or rendering issues.
M doc/wiki_source/Testing_PLplot
commit ee50dba3489bf15aa9c2626c22680061f16214f0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Nov 26 20:58:35 2018 -0800
Complete rewrite of our Testing_PLplot wiki page
This long-overdue rewrite included separating off the Testing reports into their own wiki page, Testing_Reports.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by cutting and pasting the (greatly) revised
Testing_PLplot file and the added Testing_Reports file to appropriate
edit sessions of our wiki pages at SF, and looking at the wiki results
generated from those edit sessions for any obvious rendering issues
caused, e.g., by "*" (rather than "\*") or "_$" (rather than "\_$") in
text where the former form apparently has some markdown significance
that needs to be escaped to get properly rendered results.
M doc/wiki_source/Testing_PLplot
A doc/wiki_source/Testing_Reports
commit 501ad3dcc22991d39fd92a49e63e6c0dcfc294fd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Nov 24 12:57:40 2018 -0800
Move definitive source of the markdown version of our wiki pages from our SF wiki editing sessions to git control
This change provides automatic backup and (git) version
control of our wiki markdown source files, and it allows our developers to
use the editor of their choice to edit these files.
This change was implemented by inserting the following boilerplate header
-----------------8<-------------------
<!---
N.B. The definitive Markdown source of this file is located in the
doc/wiki_source subdirectory of the PLplot source tree. So only use
the ctrl-v and delete capabilities of the GUI file editor at
SourceForge to make changes to the SourceForge version of this file,
where ctrl-v is used to complete a cut and paste from the definitive
version of this file in the PLplot source tree that is being edited
with your favorite file editor, and delete used to remove extraneous
unmodified text whose changed form has been copied with the cut and
paste.
-->
-----------------8<-------------------
at the start of each of the SF markdown sources of our wiki pages
(accessible by editing each of our wiki pages at SourceForge) then
using that SF editor to select all text and use the legacy ctrl-c cut command for that
edit session to start a cut and paste to the equivalent file in the
doc/wiki_source subdirectory of our source tree.
Note that README.testing was an older version of Testing_PLplot
created in the same way. So by copying the modern version of that
file to doc/wiki_source/Testing_PLplot by the above procedure and by
deleting README.testing we have effectively moved README.testing to
doc/wiki_source/Testing_PLplot and updated it to the latest SF
version.
D README.testing
A doc/wiki_source/Additional_notes_for_ifort_users
A doc/wiki_source/Apply_a_patch
A doc/wiki_source/Aquaterm
A doc/wiki_source/Building_PLplot
A doc/wiki_source/Building_PLplot_with_a_cross-compiler
A doc/wiki_source/CMake_options_for_PLplot
A doc/wiki_source/Cairo_pango
A doc/wiki_source/Configuration_of_wxWidgets_driver
A doc/wiki_source/Configure_PLplot_for_Borland_CXX_5.5_(free_command_line_tools)
A doc/wiki_source/Configure_PLplot_for_Borland_Turbo_C++_Explorer_Edition_(free_IDE_and_compiler)
A doc/wiki_source/Configure_PLplot_for_MinGW_CLI
A doc/wiki_source/Configure_PLplot_for_Visual_CXX_CLI
A doc/wiki_source/Configure_PLplot_for_cygwin
A doc/wiki_source/Configure_PLplot_for_msys2
A doc/wiki_source/Configure_PLplot_for_the_Visual_Studio_IDE
A doc/wiki_source/Debugging_code
A doc/wiki_source/Documenting_the_undocumented
A doc/wiki_source/Freetype
A doc/wiki_source/Frequently_Asked_Questions
A doc/wiki_source/General_CMake_documentation_links
A doc/wiki_source/Git_miscellanea
A doc/wiki_source/Home
A doc/wiki_source/Install_3rd_party_libraries
A doc/wiki_source/Install_Lua
A doc/wiki_source/Install_MinGW_MSYS
A doc/wiki_source/Install_Octave
A doc/wiki_source/Install_Python
A doc/wiki_source/Install_SWIG
A doc/wiki_source/Install_Tcl
A doc/wiki_source/Libgd
A doc/wiki_source/Linux
A doc/wiki_source/List_of_Debian_Ubuntu_packages
A doc/wiki_source/Lua
A doc/wiki_source/Mac_OSX
A doc/wiki_source/Mac_OSX_Status
A doc/wiki_source/MinGW-w64-MSYS2
A doc/wiki_source/OCaml_tutorial
A doc/wiki_source/Overview_of_the_status_on_Windows
A doc/wiki_source/Qhull
A doc/wiki_source/Qt
A doc/wiki_source/README.wiki
A doc/wiki_source/Setup_Visual_Studio_Express
A doc/wiki_source/Setup_cygwin
A doc/wiki_source/Setup_mingw
A doc/wiki_source/Setup_visualc
A doc/wiki_source/Setup_watcom
A doc/wiki_source/Specifics_for_various_platforms
A doc/wiki_source/Submit_a_patch
A doc/wiki_source/Swig
A doc/wiki_source/Testing_PLplot
A doc/wiki_source/Third-party_libraries
A doc/wiki_source/Todo_List
A doc/wiki_source/Using_PLplot
A doc/wiki_source/WxWidgets
A doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Antialized.png
A doc/wiki_source/attachments/Configuration_of_wxWidgets_driver/Non_antialized.png
A doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_bare.png
A doc/wiki_source/attachments/OCaml_tutorial/Quick_plot_labels.png
commit 48a56ee63d25d24eeb44f392025953a6e9cc6b3f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Oct 19 13:45:01 2018 -0700
Fix octave test script and example familied file bugs exposed by -DPLPLOT_TEST_DEVICE=svg and -DPLPLOT_TEST_DEVICE=svgcairo
The symptom of these bugs was that octave examples 14a and 31 were
missing from the PLplot test device diff report for both
-DPLPLOT_TEST_DEVICE=svg (the default) and
-DPLPLOT_TEST_DEVICE=svgcairo. The "14a" fix was to use the correct
file2 name in the test script for example 14, and to use "plSetOpt(
"fflen", "2" );" in the 14th example to follow what is done for the
corresponding C example. The "31" fix was to change the 31st example
to drop "Test setting / getting familying parameters across plinit "
and "Test setting / getting page parameters across plinit" tests which
had long since been dropped from the standard 31st example for all
other languages. (That first test interfered with familying so that
the plot file output by octave example 31 was misnamed).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by building the test_diff_device target for
either -DPLPLOT_TEST_DEVICE=svg (the default) or -DPLPLOT_TEST_DEVICE=svgcairo.
The difference report results showed the warnings about missing 14a
and 31 for octave were removed. As a result, the svg difference
report results are now perfect, and the svgcairo difference report
results are now reduced to
java
Missing examples :
Differing graphical output : 24
Missing stdout :
Differing stdout :
octave
Missing examples :
Differing graphical output : 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 14a 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 33
Missing stdout :
Differing stdout :
python
Missing examples :
Differing graphical output : 09 24
Missing stdout :
Differing stdout :
tcl
Missing examples :
Differing graphical output : 03 14a 24
Missing stdout :
Differing stdout :
Most of the octave graphical differences for svgcairo are due to trivial renaming of
surface id's, e.g.,
software@merlin> diff examples/test_examples_output_dir/x00[co]01.svgcairo
109c109
< <g id="surface1">
---
> <g id="surface66">
I attribute these octave id issues to the octave examples being run from one octave session
rather than separate octave sessions.
Also, at least some of the non-octave differences are due to trivial
glyph id changes, i.e., when I looked at the java differences for
example 24 two glyphs had the same contents as the corresponding C
result, but different names, and when the name differences were
accounted for, the order of the glyph definitions in the header of the
svg file was different between java and C. (Are these glyph changes
perhaps due to different threads taking longer/shorter for each
different language?)
In sum, I think the svgcairo test device is telling us a lot about
pango/cairo library idiosyncrasies but nothing useful about PLplot
issues so I intend to ignore svgcairo from now on and instead stick
with the default svg test device choice since that does give a perfect
difference report.
M examples/octave/x14c.m
M examples/octave/x31c.m
M plplot_test/test_octave.sh.in
commit 9f53302538879a7113b11de822dd917fda38ac2d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Oct 8 01:24:29 2018 -0700
Build system upgrade: Generalize how test_diff.sh is implemented and used in our test frameworks
The test_diff.sh(.in) configured script has long been implemented to
allow comparing results for our standard set of 33 examples
implemented in any of our language bindings with corresponding C
results as a test of the PLplot API consistency for each of our
language bindings. Up to now that script was configured to allow
either psc or svg as the device used for the comparison of plot file
results with rather specific implementation details for the familied
(separate files for separate pages of examples) svg device. The svg
alternative was only usable for our CTest-based test framework
(through the user specifying -DPLPLOT_TEST_DEVICE=psc or
-DPLPLOT_TEST_DEVICE=svg) with our CMake-based and traditional (based
on Makefiles + pkg-config) test frameworks completely ignoring this
potential choice and always using psc for the comparisons instead.
With this commit all these limitations concerning test_diff.sh have
been removed. If the user makes an error so that the specified
PLPLOT_TEST_DEVICE does not correspond to a enabled file device then
the build-system response to this error is that test_diff.sh will be
unused by our three test frameworks. But if PLPLOT_TEST_DEVICE
corresponds to an enabled file device, then whether this device is
familied is automatically detected by the build system, and the device
and familied information passed on to the updated test_diff.sh via the
--device and (new) --familied_device options. The updated
test_diff.sh implementation automatically accounts for all device and
familied details depending on the values of those two options. And
test_diff.sh is run in the same way for all our three (CMake-based,
CTest-based, and traditional) test frameworks. In sum, users should
be able to specify (via PLPLOT_TEST_DEVICE) any enabled file device,
and all our standard examples in all supported languages should be run
for that device with results compared by test_diff.sh for any or all
of our three test frameworks.
N.B. An important change for this commit is to use "svg" rather than
"psc" as the default value of PLPLOT_TEST_DEVICE. These two devices
share the advantage of having no dependencies and thus being
immediately available on all platforms. The SVG XML format of the
plot file output by the svg device file constitutes a small advantage
over the PostScript format of the plot file output of the psc device
because (at least in this author's opinion) SVG XML is fundamentally
easier for humans to learn than PostScript. But an even stronger
advantage of the svg device is it is a modern PLplot device that
implements alpha-channel transparency and gradients and which gives
access to virtually all (unicode-accessible) glyphs installed on a
platform while the psc device is an ancient PLplot device that because
of the limitations of PostScript is missing the alpha-channel and
gradient capabilities and which only gives access to an extremely
limited number of glyphs. Thus, when the svg device is used for
comparisons, test_diff.sh compares one good plot file result with
another for essentially all examples (see below for the one
exception), but when the psc device is used for comparisons
test_diff.sh compares one garbage plot file with missing or incorrect
elements with another for many of our standard examples. This means
the svg default choice we have adopted supplies a much stronger
constraint on our language PLplot API consistency than the old psc
default.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by running
time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.7.2/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "ctest -j10" --do_test_interactive no --do_submit_dashboard yes)
once to test the default case of the complete set of Linux devices with the default PLPLOT_TEST_DEVICE=svg and
time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.7.2/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON -DDEFAULT_NO_DEVICES=ON -DPLD_<device_name>=ON -DPLPLOT_TEST_DEVICE=<device name>" --build_command "make -j10" --ctest_command "ctest -j10" --do_test_interactive no)
7 different times with <device_name> set to ps, psc, psttf, psttfc, svg, svgqt, or svgcairo to test
the case when the indicated devices were enabled individually.
I also ran this test again for the svgqt case and -DENABLE_octave=OFF.
The first of these comprehensive tests yielded three good dashboard
results (corresponding to the ctest execution in the core build tree
for our 3 major configurations) at
<https://my.cdash.org/index.php?project=PLplot_git> on 2018-10-07.
I took a look in detail at the svg results and the results for all
examples other than example 3 rendered correctly when viewed with the
eog SVG browser. So as referred to above, svg is much better in this
regard than psc which has badly rendered results for quite a large
number of our examples because of the limitations of PostScript.
The svg issue with example 3 is that certain graphical elements are
missing consistently for all our supported languages. They are also
missing if that example is viewed with other SVG browsers such as the
konqueror and firefox browsers and the "display" application available
from the ImageMagick software suite (which by the way only works
correctly for SVG if inkscape is installed as well.)
Those elements for example 3 are also missing for the svgqt and
svgcairo devices so it is certainly possible that our fundamental C
API implementation that is exercised directly by C standard example 3
(and also indirectly by our other language bindings and example 3
implementations in those languages) is attempting to draw the missing
graphical elements of this example in a way that is not compatible
with the SVG standard. But a lot more investigation and a
much-simplified test example will likely be required to figure that
out.
The total of the 9 different comprehensive tests above were evaluated
in the usual manner (see previous commit messages for details and also
a future commit for README.testing which will document the usual
evaluation procedure for comprehensive test results).
In all but two cases there were no configuration or run-time issues
with these comprehensive tests. Those two exceptions were the following:
1. Intermittent javac segfault. This only happened one time, and I
could never replicate it afterwards. However, a valgrind run (with
the recommended for java --smc-check=all option to allow valgrind to
follow all self-modifying code changes that apparently are common for
java) for exactly the same (openjdk) javac command that segfaulted
when compiling x27.java into byte code showed 10 million memory
management issues before valgrind reached its limits and quit checking
any further. So it appears the openjdk javac command is potentially a
rich source of segfaults, and the only surprise is how little it
happens! In any case, I don't think this is our problem so if I ever
run into this issue again, I will simply repeat the test with a good
chance it will succeed.
2. Repeatible errors with the combination of svgqt and octave
On Debian Buster at least, octave examples and the svgqt device (or any
other qt device) are a toxic combination with consistent error
messages typically like:
(process:17721): GLib-CRITICAL **: 13:36:35.133: g_main_context_pop_thread_default: assertion 'g_queue_peek_head (stack) == context' failed
double free or corruption (out)
fatal: caught signal Aborted -- stopping myself...
From <https://bugs.launchpad.net/calibre/+bug/1022019> it appears
similar errors for the calibre software project were generated by glib
library inconsistencies. However, from ldd -r on
bindings/octave/plplot_octave.oct and other evidence it appears that
octave does not depend on libglib so perhaps there is something about
the octave examples that exposes a bug in libqt or else a bug in the
qt device driver. Anyhow, I plan to investigate this issue further
by attempting to determine which octave example generates the above
message.
There were a large variety of plot different reports for the additional
wide range of test device possibilities enabled by this commit.
For PLPLOT_TEST_DEVICE=psc or ps, the difference report was perfect
(i.e., this commit has not introduced any regressions into the psc
result used before, and ps follows that perfect result.)
For PLPLOT_TEST_DEVICE=psttfc or psttf the difference report was
octave
Missing examples :
Differing graphical output : 07 24
Missing stdout :
Differing stdout :
For PLPLOT_TEST_DEVICE=svg the difference report was
octave
Missing examples : 14a 31
Differing graphical output :
Missing stdout :
Differing stdout :
For PLPLOT_TEST_DEVICE=svgcairo the difference report was
java
Missing examples :
Differing graphical output : 24
Missing stdout :
Differing stdout :
octave
Missing examples : 14a 31
Differing graphical output : 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 33
Missing stdout :
Differing stdout :
python
Missing examples :
Differing graphical output : 09 24
Missing stdout :
Differing stdout :
tcl
Missing examples :
Differing graphical output : 03 14a 24
Missing stdout :
Differing stdout :
For PLPLOT_TEST_DEVICE=svgqt with -DENABLE_octave=OFF the difference report was
ocaml
Missing examples :
Differing graphical output : 28
Missing stdout :
Differing stdout :
In sum, the generalization of the test_diff.sh testing provided by
this commit provides a powerful new tool to expose issues with our
bindings and or standard examples for each of our supported languages.
The above difference report results show no regressions with the
previous psc results and constitute the best new difference reports we
can generate at the present time and are a benchmark for future
changes for all the new diff report test devices that are enabled by
this commit. Of course, it is also obvious from these results there
is clearly a lot of of work to do (especially for the octave binding
and examples) to reach an important new goal motivated by this commit
which is difference-free results for all languages for all these
different test devices.
M cmake/modules/drivers-finish.cmake
M cmake/modules/plplot.cmake
A cmake/modules/test_diff.cmake
M examples/CMakeLists.txt
M examples/Makefile.examples.in
M examples/plplot_configure.cmake_installed_examples.in
M plplot_test/CMakeLists.txt
M plplot_test/test_diff.sh.in
M plplot_test/test_octave.sh.in
commit 115cedd8378bf7627263f0f2c2d7831a0714566a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Oct 5 16:40:51 2018 -0700
Configure both the ps and psttf device drivers like all other device drivers
Previous to this commit the ps device driver configured its devices
(i.e., the ps and psc devices) together rather than individually and
the same for the psttf device driver and the corresponding psttf and
psttfc devices. All other device drivers configured their devices
individually and this anomalous ps and psttf situation generated a lot
of extra build-system complexity. We inherited this bad situation
from our previous autotools-based build system and never addressed
this issue until this commit which configures both the ps and psttf
device drivers to implement individual devices just like all the rest of
our device drivers.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by running
time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.7.2/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "ctest -j10" --do_test_interactive no)
once to test the default case of the complete set of Linux devices and
time (nice -19 env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 PATH="/home/software/cmake/install-3.7.2/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON -DDEFAULT_NO_DEVICES=ON -DPLD_<device_name>=ON" --build_command "make -j10" --ctest_command "ctest -j10" --do_test_interactive no)
5 different times with <device_name> set to ps, psc, psttf, psttfc, and svg to test
the case when the invidual devices for the ps and psttf device drivers were enabled
and when none of the devices for the ps and psttf device drivers were enabled.
These 6 different comprehensive tests were evaluated in the usual
manner (see previous commit messages for details and also a future
commit for README.testing which will document the usual evaluation
procedure for comprehensive test results). In all cases there were no
configuration, run-time, or PostScript difference (when the psc device
was implemented) issues detected so I feel confident that the current
set of rather intrusive changes has introduced no regressions.
M cmake/modules/drivers-init.cmake
M cmake/modules/pstex.cmake
M cmake/modules/psttf.cmake
M drivers/ps.c
M drivers/ps.driver_info.in
M drivers/pstex.c
M drivers/psttf.cc
M drivers/psttf.driver_info.in
M examples/CMakeLists.txt
M examples/Makefile.examples.in
M include/drivers.h
M include/plDevs.h.in
M include/plcore.h
M include/ps.h
M plplot_test/CMakeLists.txt
M plplot_test/plplot-test.sh.in
commit 58df034d4ea4682d911b419e296819aa5a8ba242
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Oct 5 16:03:28 2018 -0700
Build system: Fix undefined LIB_INSTALL_RPATH bug for the Python binding
In bindings/python/CMakeLists.txt we determined and immediately used
LIB_INSTALL_RPATH in a first context but used that value in a second
context as well. And the conditions of that second context differed
sometimes (e.g., if only a single device was enabled) from that first
context leaving LIB_INSTALL_RPATH undefined for that second context.
I fixed this bug by determining and immediately using
LIB_INSTALL_RPATH independently for the second context.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by running scripts/comprehensive_test.sh for
a single device (svg) without issues. Details of this and other
tests I ran will be given for the next commit.
M bindings/python/CMakeLists.txt
commit e36a423fe0927987119bb94459750039737b47f3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 26 01:49:27 2018 -0700
Remove unused data/.dummy file
git log --follow -- data/.dummy
shows this empty file was originally committed in 1992 with a comment
that it was a placeholder, but nothing has been done with it since
other than to change its directory location. Therefore, the current
removal is long overdue.
D data/.dummy
commit 2682d15f9ffd6b53e630e6c9b35200680dea2ed3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 26 00:48:00 2018 -0700
Fix external URL references for the website
I completely checked every external URL reference for
our website and found only the HomeBrew reference on the
Downloads page and the libgd reference on the Credits
page were dead/invalid. This commit updates those
references to valid sites again.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster> by following the (recently updated) instructions in
README.Release_Manager_Cookbook to regenerate the local website,
and then I checked that website to make sure the above two references
linked to the desired sites.
M www/credits.php
M www/downloads.php
commit cf236a23c28c17dbf9e53667a9c7488d4ac357c9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 26 00:25:20 2018 -0700
Update scripts and instructions for generating local version of website
The scripts to help generate the website were updated with commentary
tweaks and an update to all make commands to use the
PARALLEL_BUILD_OPTION bash variable which was set to "-j10" at the
start of each script. This value is suitable for my new hardware with
8 cores but could easily be modified by someone else with different
hardware whenever I step down as release manager.
I updated the instructions for the apache install and configuration
and instructions for the website generation for the release manager in
README.Release_Manager_Cookbook. That file was also updated with all
references to "raven" (my old computer) replaced by "merlin" (my new
computer) and all references to Debian Jessie (the Debian version on
my old computer) replaced by Debian Buster (the Debian version on my
new computer).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by following the above apache install and
configuration instructions and the above website generation
instructions. I did not do any of the detailed error checking that is
recommended for a release, but the result appeared to be a valid local
website that I could easily browse with the konqueror and firefox
browsers.
M README.Release_Manager_Cookbook
M scripts/generate_website.sh
M scripts/htdocs-gen_plot-examples.sh
commit 8fdfe5cabd5320e9787583fcd2e984cb4bb14dbf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Sep 23 23:57:27 2018 -0700
Report PostScript difference results in alphabetical order of languages
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by building the test_diff_psc target and confirming
the (perfect) PostScript difference report is now alphabetized by language.
M plplot_test/test_diff.sh.in
commit d6a76270499d393452df5cf36255bed2693891b3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Sep 23 22:59:55 2018 -0700
Build system: for Mac OS X drop user overide that imposes the dated -single_module linking option
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring PLplot with cmake with no errors due to
this change. However, that is just a minimal test (since this removed
override was a no-op on Linux) so the definitive test of this change
is requested on Mac OS X platforms.
M CMakeLists.txt
D cmake/UserOverride.cmake
commit d2d9461a3ce3516c98611852879467e5cf0b8265
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Sep 22 16:40:32 2018 -0700
Build system: allow consistent use of a build of Lua that is installed in a non-standard location
I also made the cmake messages emitted by the Lua part of the configuration more informative.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring PLplot using
env CMAKE_PREFIX_PATH=/home/software/lua/install-5.3.5 "/home/software/cmake/install-3.7.2/bin/cmake" ...
where /home/software/lua/install-5.3.5 is the install prefix of a local build of Lua-5.3.5
The result was consistent non-system versions of the lua library and executable were found. Furthermore,
I tested that result using
make -j10 test_diff_psc >& test_diff_psc.out
with no build or run-time errors and a perfect PostScript difference report
(for all components including lua).
M cmake/modules/lua.cmake
commit 4a5f94a70ac259d696dfaa8117cead7ad89b13f3
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Sat Sep 22 11:57:05 2018 +0100
Changed order of some wxwidgets headers to avoid compilation bug
Compile errors of wxwidgets_dev.cpp were reported on vs2017 by
Laurent Berger, with many errors looking like
1>c:\program files (x86)\windows
kits\10\include\10.0.16299.0\shared\ws2def.h(235): error C2011:
'sockaddr': 'struct' type redefinition
1>c:\program files (x86)\windows
kits\10\include\10.0.16299.0\um\winsock.h(1007): note: see declaration
of 'sockaddr'
1>c:\program files (x86)\windows
kits\10\include\10.0.16299.0\shared\ws2def.h(437): error C2059: syntax
error: 'constant'
1>c:\program files (x86)\windows
kits\10\include\10.0.16299.0\shared\ws2def.h(437): error C3805:
'constant': unexpected token, expected either '}' or a ','
You can find the discussion on the plplot-devel mailing list with title
cannot compile plplot using vs 2017.
The suspicion is a wierd interaction with the wx headers and the
windows.h header included in our wxwidgets_comm.h file. It seems
that ensuring wx/wx.h is included before windows.h avoids the
problem.
M drivers/wxwidgets.h
commit caf4801dfef32207b74f5374eff52bf2a4c24e3d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Sep 20 22:36:48 2018 -0700
Build system: Improve logic for finding Lua
There are two improvements:
* Instead of blacklisting Lua5.3 (due to what turns out to be a
run-time issue for that version of Lua that occurs on Debian Buster
but not Fedora) do the following:
If the user has specified REQUIRED_LUA_VERSION on the command line
(e.g. -DREQUIRED_LUA_VERSION=5.2 to avoid 5.3), then search
specifically for that version of Lua. Otherwise, do a search for
Lua without specifying a version which means CMake will find the
latest version of Lua that is installed.
* If possible find the lua executable using the versioned name, e.g.,
"lua5.2" that is consistent with the Lua version found, but if that
versioned name is not found, then find the unversioned name "lua" of
the executable as a last resort.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by running cmake with various values (or none) of
-DREQUIRED_LUA_VERSION to make sure a consistent version of Lua is
found in all cases (or no version is found if the REQUIRED_LUA_VERSION
string does not correspond to an installed version of Lua).
M cmake/modules/lua.cmake
commit a9d9500c732d4eae47ed7fca687e02ec8a48d02c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 19 16:38:53 2018 -0700
Build system: Future-proof use of FindPkgConfig by replacing call to _pkg_check_modules_internal with pkg_check_modules
The previous use of _pkg_check_modules_internal was "an accident
waiting to happen" since such logic obviously depends on an internal
implementation detail of CMake's FindPkgConfig module while
pkg-check_modules is for public use and therefore more stable. And
although CMake-3.12.2 was fine in this regard, that accident did
happen for the git version of CMake that will turn into version
3.13.0, and this commit solves this "future" issue.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster on my AMD Ryzen 7 1700 box) by running
time (nice -19 env PATH="/home/software/cmake/Dashboards/Scripts/My Tests/CMake-build/Tests/CMakeInstall/bin:$PATH" "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "ctest -j10")
The combination of running the script from a source tree with blanks
in the prefix (see above invocation) and the above --prefix option
containing a blank tests that the current build system continues
support for blanks in source-, build-, and install-tree prefixes; and
the "-DUSE_INCRTCL_VERSION_4=ON" cmake option is appropriate for the
software versions of Tcl/Tk/Itcl/Itk/Iwidgets that I have installed
from Debian Buster. Furthermore, I only have Qt5 development packages
installed so only the Qt5 version of the qt device driver is tested
here.
The above setting of PATH accesses the git (CMake commit ddb33b)
version of CMake and CTest that was tested successfully by hand using
the PLplot contract build test earlier today. However, the above test
does a lot more than that simple PLplot build and install test so it
is much more "comprehensive" test both of PLplot and CMake.
The above script ran both interactive and noninteractive tests for
direct use of my graphics card (i.e., not for an X-terminal) and
completed (in 46 minutes) without running into any hangs or non-zero
return codes, and the accompanying test results were evaluated as
follows:
# Check for all errors where that last pipeline stanza is to ignore
# normal "ldd" references to the gpg-error library and normal "make
# clean" references to test.error:
grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'libgpg-error.so|test.error'
# Check for regressions in configuration warnings:
grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
# Check for regressions in the distinct run-time warning labelled by
'PLPLOT WARNING':
grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
# Check for build or run-time warnings where the trailing stanza is to
# remove the "PLPLOT WARNING" and cmake.out warnings investigated
# above, and spurious gfortran warnings:
find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0 grep -i warning |grep -vE 'PLPLOT WARNING|cmake.out|PRIVATE|argv_dynamic'
# Check for any ldd issues for the shared and nondynamic cases:
grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
# Check for any PostScript or Text differences between all non-C
# languages and the corresponding C results:
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
In sum, these checks of the above comprehensive test results showed no
configure, build, run-time, or PostScript difference issues for the
"future" version of CMake that was tested.
M cmake/modules/cairo.cmake
M cmake/modules/pkg-config.cmake
commit a730ebe34b9edd44124e0d217672e678ddd06eca
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Sep 15 02:38:42 2018 -0700
Build system: fix OCaml build warnings for installed examples
Previously there were warning messages emitted by Debian Buster (but
not Debian Jessie) ocamlopt when linking the installed OCaml examples.
These warnings took the following form:
Warning 58: no cmx file was found in path for module Plplot, and its interface was not compiled with -opaque
This commit solves this issue by installing plplot.cmx (as implied by
the above warning message).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster on my AMD Ryzen 7 1700 box) in exactly the same way as
my previous commit with only one change in the evaluation of the
comprehensive test results, namely the above warning messages no
longer occur. Therefore, as far as I know, this commit removes the last "modern
software" issue caused by building and testing PLplot in a Debian
Buster = Testing environment rather than Debian Jessie = Oldstable
environment that I was using for testing before.
M bindings/ocaml/CMakeLists.txt
commit b10135855e7c2ae322a4fb4079398ff84eef80db
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Sep 14 15:18:06 2018 -0700
Build system: fix regression in linking of libplplotqt
This commit once again links libplplotqt with the plplot and math
libraries for the Qt5 case to fix a regression introduced by my recent
work on prefixing all the installed targets.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster on my AMD Ryzen 7 1700 box) by running
time (nice -19 "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/home/software/cmake/install-3.7.2/bin/cmake" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "/home/software/cmake/install-3.7.2/bin/ctest -j10" --do_test_interactive no)
The combination of running the script from a source tree with blanks
in the prefix and the above --prefix option containing a blank tests
the current build system continues support for blanks in source-,
build-, and install-tree prefixes; and the
"-DUSE_INCRTCL_VERSION_4=ON" cmake option is appropriate for the
software versions of Tcl/Tk/Itcl/Itk/Iwidgets that I have installed
from Debian Buster. Furthermore, I only have Qt5 development packages
installed so only the Qt5 version of the qt device driver is tested
here.
The above script completed (in 19 minutes) without running into any
hangs or non-zero return codes, and the accompanying test results were
evaluated as follows:
# Check for all errors where that last pipeline stanza is to ignore
# normal "ldd" references to the gpg-error library and normal "make clean"
# references to test.error.
grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'libgpg-error.so|test.error'
# Check for regressions in configuration warnings:
grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
# Check for regressions in the distinct run-time warning labelled by 'PLPLOT WARNING':
grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
# Check for build or run-time warnings where the trailing stanza is to
# remove the "PLPLOT WARNING" and cmake.out warnings investigated above,
# and spurious gfortran warnings:
find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0 grep -i warning |grep -vE 'PLPLOT WARNING|cmake.out|PRIVATE|argv_dynamic'
This test revealed the following warning message regression which was a number of different instances
of the following message:
Warning 58: no cmx file was found in path for module Plplot, and its interface was not compiled with -opaque
This warning which I attribute to a new version of OCaml for Debian
Buster appears to not have any practical consequences (e.g., the clean
PostScript differences reported below). Nevertheless, I plan to
investigate this warning at a later time.
# Check for any ldd issues for the shared and nondynamic cases.
grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
No issues were found, i.e., this commit solves the regression in this
regard found by the last several comprehensive tests.
# Check for any PostScript or Text differences between all non-C languages and the corresponding
# C results:
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
In sum, these checks of the above comprehensive test results showed no
configure, build, run-time, or PostScript difference issues other than
the noted regression in non-consequential OCaml warnings which I will
investigate later.
M bindings/qt_gui/CMakeLists.txt
commit 0583fe8feb335c147f7951fe1bb4eb5e93a56317
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Sep 9 14:15:35 2018 -0700
Build system: fix a bug in the use of the <TARGET_FILE:PLPLOT::pltcl> and $<TARGET_FILE:PLPLOT::plserver> generator expressions
The fix was to use these generator expressions only when ENABLE_tkX was true
since the shell script being configured only uses these locations for that
case.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by setting the DISPLAY environment variable to nothing
before configuring PLplot. (An incorrect setting of DISPLAY in a
crontab task to submit a PLplot contract dashboard for CMake first
exposed these bugs). For incorrect DISPLAY the Tk configuration of
PLplot fails (softly) with the result that ENABLE_tkX is false, which
means with this fix in place that the <TARGET_FILE:PLPLOT::pltcl> and
$<TARGET_FILE:PLPLOT::plserver> generator expressions are not used
which avoids the build-system error that occurred before this fix.
M plplot_test/CMakeLists.txt
commit 7ec926fae5e17cbfc9ebb4c83144a8c7ef177cbb
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Sep 9 03:42:06 2018 -0700
D examples: adjust so they compile for gcd-8
These adjustments for the 21st example were to replace isnan by isNaN,
and for the 31st example were to drop importation of std.cstream
(because cstream no longer exists in libphobos for gdc-8) and to
replace derr.writefln by stdderr.writefln everywhere.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by installing the gdc-8 and gnat-8 packages (to
be consistent with the gcc-8 version being used) and running
time (nice -19 "../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/home/software/cmake/install-$CMAKE_VERSION/bin/cmake" --cmake_added_options "-DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10" --do_test_interactive no)
with CMAKE_VERSION = 3.7.2, 3.11.0, or 3.12.2 for a total of 3 script invocations.
The combination of the above three invocations of the script from a
software tree with blanks in the prefix and the above --prefix option
containing a blank tests the current build system continues to test
support for blanks in source, build, and install tree prefixes; the
three versions of CMake correspond to the minimum version for the
Linux platform, the minimum version for non-Linux platforms, and the
latest current version of CMake; and the "-DUSE_INCRTCL_VERSION_4=ON"
cmake option is appropriate for the software versions of
Tcl/Tk/Itcl/Itk/Iwidgets that I have installed from Debian Buster.
All three test script invocations completed without running into any hangs
or non-zero return codes, and the accompanying test results were
evaluated in each of the 3 cases as follows:
# Check for all errors:
grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'libG|libgpg-error.so'
where that last pipeline stanza is to ignore routine libGL error messages
issued by my X-terminal box and to ignore normal ldd references to the gpg-error library.
# Check for regressions in configuration warnings:
grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
# Find each distinct run-time warning labelled by 'PLPLOT WARNING':
grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
# Check for build or run-time warnings:
find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0 grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic|cmake.out|opaque'
where the trailing stanza is to remove "PLPLOT WARNING" issues,
spurious gfortran warnings, cmake.out warnings, and a number of instances
of
Warning 58: no cmx file was found in path for module Plplot, and its interface was not compiled with -opaque
which appears, see below, to not have any consequences for the OCaml case. Nevertheless,
I plan to investigate this warning further.
# Check for any ldd issues for the shared and nondynamic cases.
grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
I found a number of these for modern (Debian Buster) software which I plan to investigate later.
# Check for any PostScript or Text differences between all non-C languages and the corresponding
# C results:
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
These checks of the above comprehensive test results showed no
configure, build, run-time, or PostScript difference issues. Thus,
the install of gnat-8 seems to have solved all gnatmake parallel build
issues I encountered before, and the install of gdc-8 (along with the
above adjustments of the D examples) also appears to have worked
perfectly.
M examples/d/x21d.d
M examples/d/x31d.d
commit 15d5829b94d79afbcddce3bd168dded0bcf85fa4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Sep 9 01:56:03 2018 -0700
PLplot build system: bump minimum CMake version from 3.6.2 for all platforms to 3.7.2 for the Linux platform and 3.11.0 for non-Linux platforms
The motivation for these changes is to reduce build-system bugs by
forcing our users to use modern CMake (especially on non-Linux platforms where
older versions of CMake can be problematic).
With one exception, these minimum version choices mean that PLplot
users on modern Linux platforms and the major modern non-Linux
platforms should be able to rely on the official versions of CMake for
those platforms. The exception to this PLplot user convenience is
Cygwin where the CMake packaging effort there has become moribund
(i.e., stuck on CMake 3.6.2 for much too long a time for what is
supposed to be a rolling release that keeps up with the latest free
software versions). Because of this packaging problem for CMake on
Cygwin, this PLplot change means our Cygwin users will need to build
their own CMake with version = 3.11.0 or greater before they build
PLplot.
See also the commentary in the top-level CMakeLists.txt file for
details of the web sites checked for the CMake version that is
officially installed for various platforms.
I also took this opportunity to bump the minimum CMake version for
other minor projects within the PLplot source tree to 3.7.2 or 3.11.0
depending on whether for those projects I wanted to follow the
minimum version adopted for PLplot for either the Linux platform
or non-Linux platforms.
M CMakeLists.txt
M cmake/modules/language_support.cmake
M cmake/modules/language_support/cmake/CMakeTestAdaCompiler.cmake
M cmake/test_ada/CMakeLists.txt
M cmake/test_ada/cmake/Modules/CMakeTestAdaCompiler.cmake
M cmake/test_ada/installed_CMakeLists.txt
M cmake/test_automoc/CMakeLists.txt
M cmake/test_fortran/CMakeLists.txt
M cmake/test_fortran/installed_CMakeLists.txt
M cmake/test_linux_ipc/CMakeLists.txt
M examples/CMakeLists.txt
commit d4ac55ea76fc7f5b514bc6e454b4c599dc048fde
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Sep 8 22:18:40 2018 -0700
Build system: Blacklist Lua 5.3
At least for Debian Buster, Lua 5.3 has a severe bug (see
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238>). We
previously worked around this upstream Lua-5.3 bug by dropping Lua
example 23 (the only example that exposes this bug) from our tests,
but for this commit we restore Lua example 23 for our tests, and
simply blacklist Lua 5.3 instead. As a result of this change we now
support only Lua 5.1 and 5.2 (preferred if both 5.1 and 5.2 are
available).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by installing Lua 5.2 and building the test_diff_psc
target in the build tree (for the default shared library and dynamic
devices case) for CMake versions 3.7.2, 3.11.0, and 3.12.2 where the
first two versions are of future importance to our build system
(respectively the planned minimum versions of CMake for Linux and
non-Linux systems) and the third version is the current latest CMake
version. All results from these test_diff_psc builds showed no
obvious configure, build, or run-time issues, and the PostScript
difference results were perfect again because of restoration of Lua
example 23 to our tests and the use of Lua 5.2 for both our Lua
binding build and tests of our Lua examples.
M cmake/modules/lua.cmake
M plplot_test/test_lua.sh.in
commit 5c31678babaf99da755f48ef103aefe05c39a38c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Sep 8 19:10:23 2018 -0700
Build system bug fix: set correct source file property on lib/csa/csa.c
Previously when gcc was the C compiler, I set the source file property
COMPILE_OPTIONS for lib/csa/csa.c to -fno-inline-functions to work
around what appears to be an issue with gcc version 7.3.0-21 and now
also 8.2.0 (where both versions tested were from Debian Buster) where
the explicit (or implicit via -O3) use of the -finline-functions gcc
option caused segfaults in the libcsirocsa library. And this
workaround was well-tested for CMake-3.11.x from Debian Buster.
However, it turns out that COMPILE_OPTIONS is not recognized as a
source file property for CMake-3.10.x and earlier so the workaround
failed for those versions of CMake.
This commit fixes this issue by setting the COMPILE_FLAGS rather than
COMPILE_OPTIONS source file property to specify the
-fno-inline-functions gcc option. This should work for all CMake 3.x
versions (although COMPILE_FLAGS is deprecated from CMake-3.11.x on).
Because of that deprecation, the plan is to switch all mentions of
COMPILE_FLAGS to COMPILE_OPTIONS once our minimum version of CMake on
all platforms is 3.11.0 or higher.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by building the test_diff_psc target in the build tree
(for the default shared library and dynamic devices case) for CMake
versions 3.7.2, 3.11.0, and 3.12.2 where the first two versions are of
future importance to our build system (respectively the planned
minimum versions of CMake for Linux and non-Linux systems) and the
third version is the current latest CMake version. All results from
these test_diff_psc builds showed no obvious configure, build, or
run-time issues, and there were no regressions in the PostScript
difference results.
M lib/csa/CMakeLists.txt
commit e298aa70a1f5e30c55cbfd26488432ca17b1b75f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Aug 26 12:32:49 2018 -0700
Build system: Implement NAMESPACE PLPLOT:: prefix for all installed targets
This commit is the culmination of my previous work on core build
prefixes (ALIASed PLPLOT:: prefix for read-only targets and the
normally empty except when -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON
${WRITEABLE_TARGET} prefix for writeable installed targets) for all
targets that will be installed. Because of that previous work, and
especially the core build tests that succeeded
with-DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON proving all installed
targets (*for CMake code that was exercised in those tests*) were
prefixed, this commit ideally should have just contained one change
(to use the NAMESPACE PLPLOT:: signature for the "install(EXPORT
export_plplot ...)" CMake command. However, the previous work
(notably commit 0df4e30e6b on 2018-04-06) that implemented the core
build change to use the PLPLOT:: prefix when referring to read-only
targets meant that the installed version of PLplot could not be tested
from then until now. So this commit includes the following bug fixes
for the installed version of PLplot:
Prefix-related fixes:
Change Tcl tests for CMake-based build system for installed examples
from source tree to build tree. This fix was needed because all the
examples/c/x?? scripts became configured as part of the prefix
changes. At the same time the Tcl tests for the traditional build
system for the installed examples are still for the case where source
and build trees are the same so the core build system must configure
examples/c/x?? script for this additional case as well.
Fix blank-in-path quoting issues introduced by using configured target
locations in plplot_test/plplot-test-interactive.sh(.in).
Debian Buster versus Jessie fixes:
The Debian Buster version of Qt5 demands that all executables
(i.e. qt_example) that specifically links to the Qt5 libraries must be
built with a special option (e.g., -fPIC on Linux systems). This
happens automatically for targets configured by CMake, but I had to
change pc_qt_COMPILE_FLAGS to accomodate this need for our traditional
(make and pkg-config) build system for the installed examples.
Other fixes and improvements:
Fixed bug for corner case where ENABLE_tkX was true and xwin_targets was false.
Fixed bug where needed DROP_GTK_PLUS_2_BUILDS was not propagated to the CMake-based
build system for the installed examples.
Replaced EXAMPLES_DIR and SRC_EXAMPLES_DIR environment variable
misnomers (and corresponding --examples-dir and --src-examples-dir
script option misnomers) throughout our build system and test scripts by
EXAMPLES_PREFIX and SRC_EXAMPLES_PREFIX (and corresponding
--examples-prefix and --src-examples-prefix script options).
Wrote plplot_test/README.developers to document test scripts.
This documentation includes a much-needed explanation of
how EXAMPLES_PREFIX and SRC_EXAMPLES_PREFIX are used.
Added maintenance section to drivers/README.drivers to show how
to make certain that the driver id numbers are unique and driver
information is consistent.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by running
"../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/usr/bin/cmake" --cmake_added_options "-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10"
where the combination of the above launch of the script from a
software tree with blanks in the prefix and the above --prefix option
containing a blank tests the current build system continues to
test support for blanks in source, build, and install tree prefixes; the
/usr/bin versions of cmake and ctest are the Debian Buster versions
with version number of 3.11.2; and the "-DENABLE_ada=OFF
-DUSE_INCRTCL_VERSION_4=ON" cmake options are appropriate for the
software versions of (buggy) gnatmake and Tcl/Tk/Itcl/Itk/Iwidgets
that I have installed from Debian Buster.
The first invocation of the above command failed for the CMake-based
interactive tests of the installed examples tree. The failure message
stated that a test was run using -dev plmeta (which, of course, should
not work since that device is disabled by default and I double checked
that was the case for this particular invocation of the comprehensive
test script. This error is an intermittent one (three attempts to
replicate it afterwards including a second invocation of exactly the
same command failed to show the error). Furthermore, the error
message is inexplicable since the confirmed disablement of the device
should mean the device was not used for testing for anything, and the
fact that it is a noninteractive device means it should not have been
used for interactive testing in any case! So this is indeed a nasty
puzzle, but I plan to wait until the bug triggers again to investigate
it further.
This (second) test script invocation completed without running into any hangs
or non-zero return codes, and the accompanying test results were
evaluated as follows:
# Check for all errors:
grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'libG|libgpg-error.so'
where that last pipeline stanza is to ignore routine libGL error messages
issued by my X-terminal box and to ignore normal ldd references to the gpg-error library.
# Check for regressions in configuration warnings:
grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
# Find each distinct run-time warning labelled by 'PLPLOT WARNING':
grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
# Check for build or run-time warnings:
find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0 grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic|cmake.out'
where the trailing stanza is to remove "PLPLOT WARNING" issues,
spurious gfortran warnings and cmake.out warnings.
This yielded a number of instances of the following warning
Warning 58: no cmx file was found in path for module Plplot, and its interface was not compiled with -opaque
which appears, see below, to not have any consequences for the OCaml case. Nevertheless,
I plan to investigate this warning further.
# Check for any ldd issues for the shared and nondynamic cases.
grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
I found a number of these for modern (Debian Buster) software which I plan to investigate later.
# Check for any PostScript or Text differences between all non-C languages and the corresponding
# C results:
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
There is a well-known upstream issue with lua5.3 software that is
exposed by lua example 23 which we have worked around by dropping that
example from the PostScript comparison test, but otherwise these
checks of the above comprehensive test results showed no configure,
build, run-time, or PostScript difference issues.
M cmake/modules/plplot_functions.cmake
M cmake/modules/qt.cmake
M doc/docbook/README.developers
M drivers/README.drivers
M drivers/wingdi.driver_info.in
M examples/CMakeLists.txt
M examples/plplot_configure.cmake_installed_examples.in
M examples/tcl/CMakeLists.txt
M examples/tk/CMakeLists.txt
M plplot_test/CMakeLists.txt
A plplot_test/README.developers
M plplot_test/plplot-test-interactive.sh.in
M plplot_test/plplot-test.sh.in
M src/CMakeLists.txt
commit beba481633e7ce148fc33386464b6a1b23f2b59b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Aug 3 23:32:11 2018 -0700
Style previous commit
M plplot_config.h.in
commit dd9699e5628309d4ee4a264d989c0868f5ef3dcd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Aug 3 23:17:03 2018 -0700
Comprehensive test script: fix blank in fullpath bug
The dirname logic used to obtain SCRIPT_PATH needed to be modified
(using quotes) when the script was invoked using
a fullpath to the script that included a blank, e.g.,
"../plplot blank .git"/scripts/comprehensive_test.sh" ....
used to invoke the script in the test of the last commit.
Tested by: Alan. W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) with the script invocation described above.
M scripts/comprehensive_test.sh
commit 94b5cf188d92b11920ad1998eda910e6e91992ae
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Aug 3 23:10:41 2018 -0700
Build system: Finish the topic concerning special target prefixes for the build tree
The add_executable and add_library targets that are built in the build
tree and installed (as opposed to built) in the install-tree are
special targets where special build-system rules are needed. Best
CMake practice is to install such special targets in name-spaced form
(i.e., with a target prefix of PLPLOT::). Because common CMake files
are used by both the build-tree and installed-examples build systems,
this also means that ALIASed targets with prefix PLPLOT:: must be
defined in the build-tree build system for common targets for the two
build systems. Those common targets are read-only so for uniformity I
have defined ALIASed targets to be used for all build-tree, read-only,
special target cases. And to make sure no unprefixed read-only
special targets are left, I have also for the build-tree case used the
${WRITEABLE_TARGET} prefix for all special targets which are not
read-only. The side effect of this is all the associated executable
and libraries files also have the same ${WRITEABLE_TARGET} prefix
appear in their core name. Of course, you do not normally want that
side effect so WRITEABLE_TARGET is undefined for the (default) case
where -DUSE_WRITEABLE_TARGET_TEST_PREFIX=OFF. However, if the
build-tree build system user specifies
-DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON, then all unprefixed special
targets *that are used in executed CMake code* (which is an important
caveat) will generate a cmake error which will identify most but not
necessarily all (because of that caveat) unprefixed special targets
that still need to be addressed.
A previous commit implemented such special target logic for all
libraries, modules, and swig modules while this commit completes that
work by dropping the hershey library (which does not qualify since it
is not installed) from that list, and implementing such special target
logic for the executables that qualify, i.e., just plserver, pltcl,
plrender, pltek, and wxPLViewer. In addition this commit changed many
build system names committed as part of the previous prefix work that became
obvious misnomers for this present case where special targets refer to
both add_executable and add_library targets that qualify. Because of
these name changes, this commit is quite intrusive.
N.B. This commit completes the topic of special target prefixes for
the build-tree case. And the test below (which uses
-DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON) applies to just the build-tree
case alone. I haven't considered it yet in detail, but, it is
possible the installed results of the
-DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON case (where all the core names
of relevant libraries and executables are prefixed) might be usable
with some additional modifications. If so; I might implement such
modifications so that the -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON case
works for all of build-tree, installed examples tree, and traditional
installed examples tree cases; but only if the benefits justify the
work involved.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by running
"../plplot blank .git"/scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/usr/bin/cmake" --cmake_added_options "-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON -DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10" --do_test_install_tree no --do_test_traditional_install_tree no --do_submit_dashboard no)
where the combination of the above launch of the script from a
software tree with blanks in the prefix and the above --prefix option
containing a blank tests the current build system continues to
support blanks in source, build, and install tree prefixes; the
/usr/bin versions of cmake and ctest are the Debian Buster versions
with version number of 3.11.2; the "-DENABLE_ada=OFF
-DUSE_INCRTCL_VERSION_4=ON" cmake options are appropriate for the
software versions of (buggy) gnatmake and Tcl/Tk/Itcl/Itk/Iwidgets
that I have installed from Debian Buster;
-DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON tests special executable library
and target names as I have explained above; and although (by default)
both interactive and noninteractive comprehensive tests were done, I
dropped all but build-tree tests for the reasons explained above.
This test script invocation completed without running into any hangs
or non-zero return codes, and the accompanying test results were
evaluated as follows:
# Check for all errors:
grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -v libGL
where that last pipeline stanza is to ignore libGL error messages
issued by my X-terminal box.
# Check for regressions in configuration warnings:
grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
# Find each distinct run-time warning labelled by 'PLPLOT WARNING':
grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
# Check for build or run-time warnings:
find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0 grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic|cmake.out'
where the trailing stanza is to remove "PLPLOT WARNING" issues,
spurious gfortran warnings and cmake.out warnings.
# Check for any ldd issues for the shared and nondynamic cases.
# N.B. commented out this time because the above comprehensive_test.sh options
# (--do_test_install_tree no --do_test_traditional_install_tree no)
# preclude checking for ldd issues so there are no *.ldd.out files to
# check.
#grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
# Check for any PostScript or Text differences between all non-C languages and the corresponding
# C results:
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
There is a well-known upstream issue with lua5.3 software that is
exposed by lua example 23 which we have worked around by dropping that
example from the PostScript comparison test, but otherwise these
checks of the above comprehensive test results showed no configure,
build, run-time, or PostScript difference issues.
Because this test was a success with the above
-DUSE_WRITEABLE_TARGET_TEST_PREFIX=ON cmake option, it appears there
continues to be no special executable or library target references
without prefixes (PLPLOT:: for read-only special targets and
${WRITEABLE_TARGET} for writeable special targets) for the CMake logic
exercised by the above tests.
M CMakeLists.txt
M bindings/ada/CMakeLists.txt
M bindings/c++/CMakeLists.txt
M bindings/d/CMakeLists.txt
M bindings/fortran/CMakeLists.txt
M bindings/lua/CMakeLists.txt
M bindings/lua/lua_namespace.i.in
M bindings/ocaml/CMakeLists.txt
M bindings/ocaml/plcairo/CMakeLists.txt
M bindings/octave/CMakeLists.txt
M bindings/octave/plplot_stub.m.in
M bindings/python/CMakeLists.txt
M bindings/qt_gui/CMakeLists.txt
M bindings/qt_gui/pyqt4/CMakeLists.txt
M bindings/qt_gui/pyqt5/CMakeLists.txt
M bindings/qt_gui/smoke/plplotqt.pro.in
M bindings/tcl/CMakeLists.txt
M bindings/tk/CMakeLists.txt
M bindings/wxwidgets/CMakeLists.txt
M cmake/modules/drivers-finish.cmake
M cmake/modules/plplot_functions.cmake
M drivers/CMakeLists.txt
M drivers/tk.c
M drivers/wxwidgets_dev.cpp
M examples/CMakeLists.txt
M examples/fortran/CMakeLists.txt
M examples/lua/plplot_examples.lua.in
M examples/tcl/CMakeLists.txt
R051 examples/tcl/x00 examples/tcl/x00.in
R056 examples/tcl/x01 examples/tcl/x01.in
R051 examples/tcl/x02 examples/tcl/x02.in
R052 examples/tcl/x03 examples/tcl/x03.in
R051 examples/tcl/x04 examples/tcl/x04.in
R051 examples/tcl/x05 examples/tcl/x05.in
R051 examples/tcl/x06 examples/tcl/x06.in
R051 examples/tcl/x07 examples/tcl/x07.in
R051 examples/tcl/x08 examples/tcl/x08.in
R051 examples/tcl/x09 examples/tcl/x09.in
R051 examples/tcl/x10 examples/tcl/x10.in
R051 examples/tcl/x11 examples/tcl/x11.in
R051 examples/tcl/x12 examples/tcl/x12.in
R051 examples/tcl/x13 examples/tcl/x13.in
R057 examples/tcl/x14 examples/tcl/x14.in
R051 examples/tcl/x15 examples/tcl/x15.in
R062 examples/tcl/x16 examples/tcl/x16.in
R051 examples/tcl/x17 examples/tcl/x17.in
R069 examples/tcl/x18 examples/tcl/x18.in
R051 examples/tcl/x19 examples/tcl/x19.in
R051 examples/tcl/x20 examples/tcl/x20.in
R051 examples/tcl/x21 examples/tcl/x21.in
R051 examples/tcl/x22 examples/tcl/x22.in
R051 examples/tcl/x23 examples/tcl/x23.in
R069 examples/tcl/x24 examples/tcl/x24.in
R051 examples/tcl/x25 examples/tcl/x25.in
R069 examples/tcl/x26 examples/tcl/x26.in
R051 examples/tcl/x27 examples/tcl/x27.in
R051 examples/tcl/x28 examples/tcl/x28.in
R051 examples/tcl/x29 examples/tcl/x29.in
R051 examples/tcl/x30 examples/tcl/x30.in
R054 examples/tcl/x31 examples/tcl/x31.in
R069 examples/tcl/x33 examples/tcl/x33.in
M examples/tk/CMakeLists.txt
M fonts/CMakeLists.txt
M include/plDevs.h.in
M include/pldll.h.in
M lib/csa/CMakeLists.txt
M lib/csa/csadll.h.in
M lib/nistcd/CMakeLists.txt
M lib/nistcd/cddll.h.in
M lib/nn/CMakeLists.txt
M lib/nn/nndll.h.in
M lib/qsastime/CMakeLists.txt
M lib/qsastime/qsastimedll.h.in
M plplot_config.h.in
M plplot_test/CMakeLists.txt
M plplot_test/plplot-test-interactive.sh.in
M plplot_test/test_plrender.sh.in
M plplot_test/test_tcl.sh.in
M src/CMakeLists.txt
M utils/CMakeLists.txt
commit 391ec0ad0a45b4e65e631d57218bbac1be5bf54c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Aug 1 12:46:40 2018 -0700
Octave binding and examples: permanently fix issue with non-cell arrays of character strings
After the previous cellstr workaround for this issue was committed, I
discovered through further hex_print experiments that the issue with
conversion of non-cell arrays of character strings to C strings had
nothing to do with UTF-8, but instead any string (ascii or more
general UTF-8) shorter than 15 bytes always worked and any such string
longer than 15 bytes always failed (i.e., generated short C strings
that were either 0 length or filled with non-valid UTF-8 characters).
And when I reported that issue at <https://savannah.gnu.org/bugs/index.php?54415>,
I got the following extremely useful response from Markus Mützel:
<quote>
Recently, gcc seems to have changed the lifetime of temporary strings
that are not assigned to a variable. It looks like the C++ string
returned by "row_as_string" is destroyed immediately after is is
created. Thus, the reference to the C string array returned by "c_str"
gets invalid. The memory at that location is no longer protected from
being overwritten. The results of dereferencing that pointer is
undefined. You might be able to fix your code by explicitly assigning
the C++ string returned by "row_as_string" to a variable for which you
can control the scope.
</quote>
Accordingly I changed
tmp_cstring = (char *) temp_matrix.row_as_string( i ).c_str();
(where the tmp_cstring declaration was properly scoped)
to
str = temp_matrix.row_as_string( i );
tmp_cstring = (char *) str.c_str();
(where both the str and tmp_cstring declarations were properly scoped)
in our swig-generated interface and that solved all the non-cell
long-string issues! (By the way, the above new style has always been
used by our equivalent interface to transform cell arrays of character
strings to C strings which explains why the cell array version
and the previous cellstr workaround both worked.)
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring PLplot using the normal
(-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON) cmake options required
by Debian Buster and by building the test_noninteractive target
without obvious configure, build, or run-time errors and without
PostScript difference report regressions (including on-going perfect
results for octave despite the current commit reverting all the
cellstr workarounds in examples octave that were applied in a previous
commit).

M bindings/octave/plplot_octave.i
M examples/octave/x26c.m
M examples/octave/x33c.m
commit 95f823ec0b3ca1ed54e8a664ab9a89c8fc5c872e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Jul 31 20:40:13 2018 -0700
Build system: bump minimum octave version we support from 3.2.0 to 3.8.0
The reason for this bump is we have no way of testing early octave
versions such as 3.2. Actually, the same is likely true of 3.8.0, but
I did have perfect PostScript difference reports for octave 3.8.x on
my (now retired) Debian Jessie platform so on that basis I feel we can
say we support 3.8.0 and above for the time being.
In addition because octave-4 is now producing a perfect PostScript
difference report, drop the TRY_OCTAVE4 option and the associated
warnings when the user specified -DTRY_OCTAVE4=ON and simply quietly accept
octave-4 if it is found.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring PLplot using the normal
(-DENABLE_ada=OFF -DUSE_INCRTCL_VERSION_4=ON) cmake options required
by Debian Buster and by building the test_noninteractive target
without obvious configure, build, or run-time errors and without
PostScript difference report regressions (including on-going perfect
results for octave).
M cmake/modules/octave.cmake
commit d7310aa9864ce1676177f39323c9daf593ae0765
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Jul 31 13:13:11 2018 -0700
Improved workaround for Octave-4 issue with non-cell arrays of character strings
Our current swig-generated octave interface uses the following method call
to help determine each element of an array of pointers to C strings
from an octave non-cell array of strings:
tmp_cstring = (char *) temp_matrix.row_as_string( i ).c_str();
In turn this array of pointers to C strings are used as arguments to
e.g., pllegend and plcolorbar. This interfacing method worked fine
for octave-3, and for octave-4 it also works for most UTF-8 character
strings provided by our examples, but there are some exceptions
(invalid UTF-8 character strings) turned up by our examples 26 and 33
which I previously worked around before by dropping those octave
examples from our test targets.
Our octave binding of PLplot also provides the possibility of converting
cell arrays of strings to pointers to C strings, and it turns out
that method (using the cellstr function to convert from non-cell to
cell array) makes examples 26 and 33 work again with octave-4. In one
case, the problematic non-cell array of strings in example 26 was
["Амплитуда"; "Фазовый сдвиг"]
I have managed to replicate that issue with the simple self-contained "hex_print" project
(completely independent of PLplot). However, the issue appears to be quite specific
to this array of strings since other arrays caused no problems for the hex_print project.
These results will be the basis of an octave-4 bug report.
But in another case for page 4 of example 33, the text was
["Box Line Width 1"; "Box Line Width 2"; "Box Line Width 3"; "Box Line Width 4"; "Box Line Width 5"]
, i.e., all ascii. I plan to investigate this issue further with the hex_print project, but meanwhile
in this commit converting that array to cell
in our example 33 avoided the invalid UTF-8 string issue.
Many other cases of invalid UTF-8 string issues occurred for the plcolorbar pages (i.e.,
page 5 and following) of example 33. In all cases for this commit I
avoided the problem by using cellstr to convert both the label and
axis_opts arguments of plcolorbar to cell arrays.
This commit allowed me to also add back examples 26 and 33 to our octave test case with
a clean PostScript difference report for octave as a result, i.e.,
octave
Missing examples :
Differing graphical output :
Missing stdout :
Differing stdout :
I also took this opportunity not only to add back examples 26 and 33
to our list of example pages that is maintained in
cmake/modules/plplot_functions.cmake but also do further maintenance
to that list, i.e., change the number of pages for example 22 from 4
to the correct number (5), and change the number of pages for example
33 from 4 (!) to the correct number (100).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring PLplot using the normal
(-DENABLE_ada=OFF -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON) cmake
options required by Debian Buster and by building the all,
test_noninteractive, and test_interactive targets without obvious
configure, build, or run-time errors and with the PostScript
difference report improvement noted above which reduces the PostScript
difference issues down to just one which is
lua
Missing examples : 23
Differing graphical output :
Missing stdout :
Differing stdout :
which is caused by my workaround (dropping example 23) for
an upstream issue with lua5.3.
A further test I did was to build the test_c_svg target twice followed
by building the clean target. The second build of test_c_svg did not
execute anything showing that the list of examples pages maintained in
cmake/modules/plplot_functions.cmake did not include too much. The
further build of the clean target removed all results from
examples/test_examples_output_dir (except those from example 23 which
necessarily must be there because example 23 is temporarily excluded
from the list until the upstream Lua-5.3 issue is fixed). This result
confirms the maintained list of example pages did not include too
little.
M bindings/octave/plplot_octave.i
M cmake/modules/plplot_functions.cmake
M examples/octave/x26c.m
M examples/octave/x33c.m
M plplot_test/test_octave.sh.in
commit 94e2e5b01c3b844415244756c41e1286f9bb8935
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Jul 30 23:23:35 2018 -0700
Fix issues introduced by Phil's last two commits
These issues range from the trivial (removing trailing blanks
introduced into api.xml and restore correct plscmap1l as opposed to
plscmap1la function name for relevant plabort calls) to important (fix
introduced build errors for Tk-related source code caused by the
backwards-incompatible changes [h,l,s ==> c1,c2,c3 changed member names])
to the PLControlPt struct that were introduced by Phil's commit).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring PLplot using the normal
(-DENABLE_ada=OFF -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON) cmake
options required by Debian Buster and by building the all,
test_noninteractive, and test_interactive targets without obvious
configure, build, or run-time errors and without PostScript difference
report regressions.
M bindings/tk-x-plat/plplotter.c
M bindings/tk/plframe.c
M bindings/tk/plr.c
M doc/docbook/src/api.xml
M drivers/tk.c
M src/plctrl.c
commit eac0c40f5bdb8c8e574357b1d9512269ed2b9cbe
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Jul 26 14:02:35 2018 +0100
Changes to documentation for plscmap1l
These just update things and make the behaviour abslutely clear after
the changes in the previous commit which not perform interpolation
in the colorspace the user provides the coordinates in.
M doc/docbook/src/api.xml
commit 7ab9c0abf4bf398568c0c39aa59cabce534d17f6
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Jul 26 13:39:09 2018 +0100
Changed color interpolation for plscmap1l and plscmap1la
Previously scmap1l and plscmap1la took control points for interpolating
a new colour map, but even if RGB coordinates were passed in, they were
converted to HLS coordinates and interpolated in HLS space. The new
behaviour is to interpolate in whichever space the coordinates are
passed in with.
M include/plplot.h
M include/plstrm.h
M src/plctrl.c
commit 1b800ff474c2035e325471adfa1b73ecaa8e4ce9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Jul 17 11:53:20 2018 -0700
Prefix the nistcd target
The nistcd library is only built if -DPLD_cgm=ON. That option is OFF
by default so this unprefixed library target was missed by our
previous tests until we tried the recent prefix test with
-DPLD_cgm=ON.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring PLplot with
-DPLD_cgm=ON -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON included
with the usual cmake options and building the test_cgm_dyndriver
target specifically and the install target in general.
There were no obvious configuration, build, or install issues.
M lib/nistcd/CMakeLists.txt
commit 1282b2f257bd332e8f3ef21b8e40d5e66cb48c24
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Jul 16 12:06:31 2018 -0700
Change ALIAS target names of swig-generated shared objects for the Python case
This commit changes the ALIAS target names from PLPLOT::plplotc and PLPLOT::Pltk_init
to PLPLOT::_plplotc and PLPLOT::_Pltk_init to retain the underscore in the
alias name. This result is consistent with the swig-generated names of shared objects for
the Python case.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by running
time (nice -19 scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command "/usr/bin/cmake" --cmake_added_options "-DENABLE_ada=OFF -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10" --do_test_interactive no --do_test_install_tree no --do_test_traditional_install_tree no --do_submit_dashboard no)
where the combination of launching the script from a software tree
with blank in the prefix and the above --prefix option insure blanks
in source, build, and install tree prefixes are tested, the /usr/bin
versions of cmake and ctest are the Debian Buster versions with
version number of 3.11.2; the "-DENABLE_ada=OFF -DTRY_OCTAVE4=ON
-DUSE_INCRTCL_VERSION_4=ON" are appropriate software versions of
octave, Tcl/Tk/Itcl/Itk/Iwidgets, and (buggy) gnatmake that I have
installed from Debian Buster;
-DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON tests library target
names, and I have dropped the interactive tests for convenience and
the install-tree components of the comprehensive tests because those
don't currently work due to namespace PLPLOT:: not being implemented
yet for PLplot installs.
This test script completed without running into any hangs or non-zero
return codes, and the accompanying test results were evaluated as
follows:
# Check for all errors:
grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -v libGL
where that last pipeline stanza is to ignore libGL error messages
issued by my X-terminal box.
# Check for regressions in configuration warnings:
grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target|requires shared libraries'
# Find each distinct run-time warning labelled by 'PLPLOT WARNING':
grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
# Check for build or run-time warnings:
find ../comprehensive_test_disposeable\ blank/*/*/output_tree/* -type f -print0 |xargs -0 grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic|cmake.out'
where the trailing stanza is to remove "PLPLOT WARNING" issues, spurious gfortran warnings
and cmake.out warnings.
# Check for any ldd issues for the shared and nondynamic cases.
# N.B. commented out this time because the above comprehensive_test.sh options
# (--do_test_install_tree no --do_test_traditional_install_tree no)
# preclude checking for ldd issues so there are no *.ldd.out files to
# check.
#grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
# Check for any PostScript or Text differences between all non-C languages and the corresponding
# C results:
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
There are the well-known upstream issues with octave-4 and lua5.3
software that are exposed by octave examples 26 and 33, and lua
example 23 which we have worked around by dropping those examples from
the PostScript comparison test, but otherwise these checks of the
above comprehensive test results showed no configure, build, run-time,
or PostScript difference issues.
Because this test was a success with the above
-DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON cmake option, it
appears there continues to be no library target references without
prefixes (PLPLOT:: for read-only targets and ${LIBRARY_TARGET_PREFIX} for
writeable targets) for the CMake logic exercised by the above tests.
M CMakeLists.txt
M cmake/modules/plplot_functions.cmake
M examples/CMakeLists.txt
M examples/python/CMakeLists.txt
commit 4d17d8f25cfb3df4d7e840a2ac61906ad473c5c2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jul 15 11:25:20 2018 -0700
Update installation of nistcd, csa, and nn headers
In the nistcd case, I added the configured cddll.h header to the list
of headers to be installed.
In the csa and nn cases, I implemented header installation for the
first time.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring the PLplot build using the cmake
options -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON (consistent with
modern software versions available from Debian Buster) and
-DPLD_cgm=ON (needed to build and install the nistcd library), and
building the install target. There were no configure, build, or
install issues other than the usual gfortran "PRIVATE" and "argv_dynamic"
false alarm warnings.
M lib/csa/CMakeLists.txt
M lib/nistcd/CMakeLists.txt
M lib/nn/CMakeLists.txt
commit 185b5fdcf0c0d5ad5c489b1ad7d8ede0f7b3f55f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jul 15 10:54:25 2018 -0700
Fix install error for configured qsastimedll.h
In previous commit which introduced configuring this file, forgot
to specify the ${CMAKE_CURRENT_BINARY_DIR} location of this
configured file for the install command.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by building the install target without errors.
M lib/qsastime/CMakeLists.txt
commit f9142a615a427eb66fa39708a84c7ea03c45d5e9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jul 11 10:03:43 2018 -0700
Remove sip v4.19 deprecation warning
According to
<http://pyqt.sourceforge.net/Docs/sip4/directives.html#directive-%25Module>
the version option for the %Module directive is deprecated and ignored
for v4.19 but apparently used for prior versions of sip to help keep
track of shared object API changes for other modules that might depend
on our pyqt5 module. As a result prior to this commit the following
deprecation warning was emitted by (Debian Buster) sip v4.19:
sip: Deprecation warning: /home/software/plplot/HEAD/plplot.git/bindings/qt_gui/pyqt5/plplot_pyqt5.sip:25: %Module version numbers are deprecated and ignored
Since it is unlikely we will ever have other modules depending on this
one, and, in any case, this functionality is now missing from modern
sip, I addressed this deprecation issue by removing the version option
of our %Module directive.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by building the test_pyqt5_example target. The
deprecation warning is now gone, and there were no obvious configure,
build, or run-time issues associated with this test target.
M bindings/qt_gui/pyqt5/plplot_pyqt5.sip
commit dc217017dd2d276acd2a4b8cba5c74f652ec1803
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Jul 10 15:48:45 2018 -0700
Test system: Adjust what is tested by the test_interactive and test_tk targets
Two steps forward, one step back....
With the Debian Buster version (5.10.1) of the Qt5 suite of libraries
valgrind reports *no" memory management issues for -dev qtwidget or
qt_example which is in sharp contrast with my previous results for
earlier Qt5 versions. (I do see thousands of such issues when running
pyqt5_example with python3 with valgrind, but python is notorious for
false positives for valgrind so I discount these.) Those earlier
issues were reported at <https://sourceforge.net/p/plplot/bugs/158/>
so this new result is a promising indication that bug should be
closed, but I am going to wait to do that until there is more of a
track record for good memory management experience with Qt5 5.10.1 and
above. To help gain that experience, I now allow both the
test_qt_example and test_pyqt5_example targets to be dependencies of
the test_interactive target for the -DPLPLOT_USE_QT5=ON case. So this
change constitutes the two steps forward.
I have recently discovered that the pytkdemo example intermittently
hangs on exit (at least with Debian Buster Tcl/Tk versions). Therefore,
I have dropped the test_pytkdemo target from the list of dependencies
for both the test_interactive and test_tk targets. So this change constitutes
the one step back.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by running
time (nice -19 scripts/comprehensive_test.sh --cmake_command "/usr/bin/cmake" --cmake_added_options "-DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON" --build_command "make -j10" --ctest_command "/usr/bin/ctest -j10" --do_test_install_tree no --do_test_traditional_install_tree no)
Where the /usr/bin versions of cmake and ctest are the Debian Buster
versions with version number of 3.11.2; the "-DTRY_OCTAVE4=ON
-DUSE_INCRTCL_VERSION_4=ON" are appropriate for the Debian Buster
software versions of octave and Tcl/Tk/Itcl/Itk/Iwidgets that I have
installed; and I have dropped the install-tree components of the
comprehensive tests because those don't currently work due to
namespace PLPLOT:: not being implemented yet for PLplot installs. As
a result of the above changes, this test built both the
test_qt_example and test_pyqt5_example test targets but dropped the
test_pytkdemo target.
This test script completed without running into any hangs or non-zero
return codes, and the accompanying test results were evaluated as
follows:
# Check for errors or any regressions in the warnings in the cmake output.
grep -i error ../comprehensive_test_disposeable/*/*/output_tree/cmake.out
grep -i warning ../comprehensive_test_disposeable/*/*/output_tree/cmake.out |grep -Ev 'Octave-4|Suitable Qt4|PLPLOT_USE_QT5|PLD_pdf|PLplot OCaml|spurious|PRIVATE|gfortran Fortran compiler|It appears these warnings|The test_.*target |requires shared libraries' |less
# Find number of distinct run-time warnings labelled by 'PLPLOT WARNING':
grep -A1 --no-filename "PLPLOT WARNING" ../comprehensive_test_disposeable/*/*/output_tree/*.out |sed -e 's?^[0-9][0-9]*: ??' |sort -u
# Check for build or run-time warnings:
ls ../comprehensive_test_disposeable/*/*/output_tree/* |grep -v cmake.out |xargs grep -i warning |grep -vE 'PLPLOT WARNING|PRIVATE|argv_dynamic'
where I have ignored the previously covered 'PLPLOT WARNING' issues and ignored the spurious gfortran warnings.
# Check for all errors:
grep -i error ../comprehensive_test_disposeable/*/*/output_tree/*.out |grep -v libGL
where that last pipeline stanza is to ignore libGL error messages issued by my X-terminal box.
# Check for any ldd issues for the shared and nondynamic cases.
# N.B. commented out because the above comprehensive_test.sh options
# (--do_test_install_tree no --do_test_traditional_install_tree no)
# preclude checking for ldd issues so there are no *.ldd.out files to
# check.
grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable/*/*/output_tree/*ldd.out
# Check for any PostScript or Text differences between all non-C languages and the corresponding
# C results.
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable/*/*/output_tree/*.out |less
There were run-time deprecation warnings for pyqt5 found with the
above checks which I will investigate later, and there are the
well-known upstream issues with octave-4 and lua5.3 software that are
exposed by octave examples 26 and 33, and lua example 23 which we have
worked around by dropping those examples from the PostScript
comparison test, but otherwise these checks of the above comprehensive
test results showed no configure, build, run-time, or PostScript
difference issues.
M examples/CMakeLists.txt
commit 6e36da7fb40f8d867d11dd78fde5fa2b104c1c8d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Jul 9 15:35:39 2018 -0700
Reduce warning messages for the test_noninteractive target
The changes were as follows:
* For the Fortran binding, drop declarations of some unused variables.
* For the Fortran examples, don't define an unused function.
* For the OCaml examples, drop some unneeded calculations.
* For the higher-level Octave binding that is implemented with Octave
functions, replace calls to the deprecated (in Octave 4.4) toascii
function with calls to the recommended replacement (the double
function). I assume this replacement is backwards compatible since
I have discovered with web searchs that the double function has been
documented back to octave-2.9 and likely even earlier. However, I
have no means to test octave versions less than 4.4.
I speculate that toascii was deprecated in Octave 4.4 because its
name was a horrible misnomer describing the reverse of what occurs
which is conversion of each character in a string to the
corresponding integer, but by default integers are internally stored
in octave as double-precision floating point numbers so the actual
conversion was from each character in the string to double (which I
assume is why double is the recommended replacement).
As a result of these changes the only warning messages left that are
emitted by the test_noninteractive target are run-time "PLPLOT WARNING" messages
that have been present for a long time, and the following spurious warnings
emitted by gfortran:
1. argv_dynamic warning message.
/home/software/plplot/HEAD/plplot.git/examples/fortran/x01f.f90:51:0:
character(len=:), dimension(:), allocatable :: argv_dynamic
Warning: ‘.argv_dynamic’ is used uninitialized in this function [-Wuninitialized]
I am not sure where the "." part of ".argv_dynamic" comes from in that
warning message. In any case, I am virtually positive this warning is
spurious since argv_dynamic is an output argument of the routine
plget_arguments(argv_dynamic) which is the first mention of
argv_dynamic in an executable statement in this routine.
2. Spurious "PRIVATE" warning messages.
There are 56 of these due to a long-standing gfortran
bug (see
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111> and
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861>). A typical
example is
/home/software/plplot/HEAD/plplot.git/bindings/fortran/plplot_small_modules.f90:108:8:
function interface_strlen(s) bind(c, name='strlen')
1
Warning: Symbol ‘interface_strlen’ at (1) is marked PRIVATE but has been given the binding label ‘strlen’
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring PLplot with the cmake options
-DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON and
building the test_noninteractive target with octave 4.4. All but the
"PLPLOT WARNING" and spurious fortran warning messages mentioned above
are now gone. This overall test showed no obvious configure, build,
run-time, or PostScript difference report regressions as a result of
this commit.
M bindings/fortran/plplot_small_modules.f90
M bindings/octave/PLplot/ginput.m
M bindings/octave/PLplot/support/__pl_matstr.m
M examples/fortran/x15f.f90
M examples/ocaml/x19.ml
commit a4bada0048d93cc79900807b576a52e1503695a0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Jul 9 11:26:00 2018 -0700
Testing system: Fix long-standing name clash between various "test.error" files output by test scripts
My thanks to Nils Gladitz for going above and beyond by investigating
this PLplot bug and drawing my attention to the test.error files in
response to my question on the CMake mailing list.
These name clashes create obvious race conditions for parallel builds
of test targets. For example, after the fix was applied here is the list
of the various "*test.error" files generated by
the test_noninteractive target:
software@merlin> find . -name "*test.error"
./examples/octave_psc_test.error
./examples/c_pngcairo_test.error
./examples/c_pdfqt_test.error
./examples/c_jpgqt_test.error
./examples/c_svgcairo_test.error
./examples/c_svg_test.error
./examples/tcl/tcl_psc_test.error
./examples/c_pscairo_test.error
./examples/c_psttf_test.error
./examples/c_ps_test.error
./examples/c_pngqt_test.error
./examples/c_svgqt_test.error
./examples/lua/lua_psc_test.error
./examples/cxx_psc_test.error
./examples/ada_psc_test.error
./examples/d_psc_test.error
./examples/c_tiffqt_test.error
./examples/ocaml_psc_test.error
./examples/c_psttfc_test.error
./examples/c_epscairo_test.error
./examples/c_ppmqt_test.error
./examples/c_pdfcairo_test.error
./examples/fortran_psc_test.error
./examples/python_psc_test.error
./examples/c_bmpqt_test.error
./examples/c_psc_test.error
./examples/c_xfig_test.error
./examples/java_psc_test.error
Those versions of the files that are located in the examples directory
obviously could have interfered with each other before the name clash
was resolved.
I don't understand the exact mechanism, but it turns out those races
caused a long-standing problem of groups of extra ascii nul characters
('\0') to appear in the output of parallel builds, and I am pleased
that race condition symptom is now gone as a result of this commit.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by building the test_noninteractive target using
make -j16 test_noninteractive >& test_noninteractive.out
The command
od -c test_noninteractive.out |grep '\\0'
showed those results were free of embedded '\0' (ascii nul) characters
that were there for parallel builds before the current commit. This
overall test showed no obvious configure, build, run-time, or
PostScript difference report regressions as a result of this commit.
M plplot_test/plplot-test-interactive.sh.in
M plplot_test/test_ada.sh.in
M plplot_test/test_c.sh.in
M plplot_test/test_c_interactive.sh.in
M plplot_test/test_cxx.sh.in
M plplot_test/test_d.sh.in
M plplot_test/test_fortran.sh.in
M plplot_test/test_java.sh.in
M plplot_test/test_lua.sh.in
M plplot_test/test_ocaml.sh.in
M plplot_test/test_octave.sh.in
M plplot_test/test_octave_interactive.sh.in
M plplot_test/test_plrender.sh.in
M plplot_test/test_python.sh.in
M plplot_test/test_tcl.sh.in
commit 179809cb9eecb3e75997ca7aa39d6e1cb39d8708
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jul 7 23:53:17 2018 -0700
Octave binding: remove last build warning
The build warning was caused by the following code fragment propagated
to the C++ code generated by swig to implement the octave binding:
// Check if version >= 3.4.0
#if OCTAVE_API_VERSION_NUMBER < 45
retval( 0 ) = octave_value( local_charMatrix, true );
#else
retval( 0 ) = octave_value( local_charMatrix );
#endif
This is an attempt to use the first (ancient) octave_value form if the
user has a very old version of octave, but this is inconsistent with
other parts of the code which uses the modern (second) form of
octave_value without attempting to support ancient octave.
Furthermore, even this attempt at backwards incompatibility with
ancient octave is not implemented correctly since
OCTAVE_API_VERSION_NUMBER is not #defined for modern octave so the C++
preprocessor assumes its value is 0, and the first (ancient) form of
the octave_value call is (incorrectly) used with accompanying build
warnings. I have absolutely no idea how that ancient form still
worked for octave-4.4 prior to this commit, but in any case the
warning issue is solved by this commit by only using the second modern
form of the octave_value call consistent with other code in
plplot_octave.i.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring PLplot with the cmake options
-DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON and
building the test_noninteractive target with octave 4.4. All
remaining deprecation build warnings for octave are now gone, and this
test showed no obvious configure, build, or run-time regressions as a
result of this commit.
M bindings/octave/plplot_octave.i
commit b940cde452cbb8bea541087f66696137c4f6bbee
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jul 7 14:34:17 2018 -0700
Update styling script to handle swig %# preprocessor directives
Some swig configuration files (e.g., bindings/octave/plplot_octave.i)
use the swig "%#" preprocessor directive which tells swig to pass that
directive through to the C or C++ preprocessor rather than using the
swig preprocessor to process that directive. Thus, from a style
perspective, swig "%#" preprocessor directives should be treated the
same way by uncrustify as the normal C or C++ "#" preprocessor
directive. So this commit implements that by the appropriate sed
magic to replace "%#" by "#" before uncrustify processes the file and
then replace "#" by "%#" (for appropriately commented lines) after
uncrustify processes the file to restore back to appropriate swig
configuration script form.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by running the new version of scripts/style_source.sh
that is committed in this commit. This version of the style script
was used to style bindings/octave/plplot_octave.i with good
indentation before that file was committed in the last commit, and
running this version of the style script now shows (as expected) no
further style changes to bindings/octave/plplot_octave.i (or any other
file) are necessary.
M scripts/style_source.sh
commit 76f486baadf33014ec97d03772bc591d22ae2231
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jul 7 14:29:00 2018 -0700
Octave binding: For octave-4.4 and above to avoid deprecations warnings replace calls to the is_empty and is_cell methods by calls to the preferred octave-4.4 names for those methods which are isempty and iscell
As of version 4.4, the preferred names for the is_empty and is_cell methods have been changed
to isempty and iscell to make them consistent with the corresponding octave function names.
The current commit uses conditional compilation to use isempty and
iscell for octave-4.4 (to avoid the 4.4 is_empty and is_cell
deprecation warnings), but otherwise it continues to use the old
names. Therefore, this commit should not introduce issues for
octave-4 versions below 4.4 and likely also octave-3, but I am not in
a position to test those older octave versions.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring PLplot with the cmake options
-DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON and
building the test_noninteractive target with octave 4.4. All the
previous is_empty and is_cell deprecation build warnings are now gone,
and this test showed no obvious configure, build, or run-time
regressions as a result of this commit.
M bindings/octave/plplot_octave.i
commit d96ac4b469f2e5028ff2fa773fce53ccf2d5d1a7
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jul 6 14:48:17 2018 -0700
Octave binding: For octave-4.4 and above replace calls to feval by calls to octave::feval to avoid a deprecation warning
As of version 4.4, feval is deprecated in favour of octave::feval.
The current commit uses conditional compilation to use octave::feval
for octave-4.4 (to avoid the 4.4 feval deprecation warning), but
otherwise it continues to use feval. Therefore, this commit should
not introduce issues for octave-4 versions below 4.4 and likely also
octave-3, but I am not in a position to test those older octave
versions.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring PLplot with the cmake options
-DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON and
building the test_noninteractive target with octave 4.4. All the
previous feval-related deprecation build warnings were gone, and this
test showed no obvious configure, build, or run-time regressions as a
result of this commit.
M bindings/octave/plplot_octave.i
commit 844e7f3454b272ad3b4b83413e36e4c7ede6a68a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jul 6 11:29:19 2018 -0700
Solve dereferencing bug for pltcl application
This bug was introduced by commit c1d5dba8d1 which made (in 2010) the following change
to pltcl.c
diff --git a/utils/pltcl.c b/utils/pltcl.c
index 72a0055b4..1b15f5f93 100644
--- a/utils/pltcl.c
+++ b/utils/pltcl.c
@@ -68,10 +68,13 @@ main( int argc, const char **argv )
static int
plExitCmd( ClientData clientData, Tcl_Interp *interp, int argc, char **argv )
{
+ char *tmp;
+
// Print error message if one given
- if ( interp->result != NULL && interp->result[0] != '\0' )
- fprintf( stderr, "%s\n", interp->result );
+ tmp=Tcl_GetStringResult(interp);
+ if ( tmp != NULL && tmp != '\0' )
+ fprintf( stderr, "%s\n", Tcl_GetStringResult(interp));
plspause( 0 );
plend();
The problem with that change was the second use of tmp in the if
statement was not derefenced (to check that the size of the error
message string was non-zero). This issue was discovered by gcc 7.3.0
which emitted the following warning message before this fix:
bindings/tcl/pltcl.c:74:29: warning: comparison between pointer and zero character constant [-Wpointer-compare]
if ( tmp != NULL && tmp != '\0' )
^
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by building the test_pltcl_standard_examples target.
The current fix removed the above build warning, and there were
no obvious run-time issues with the results of this test.
M bindings/tcl/pltcl.c
commit 5eced65fc75113200adb273f868bcd0d4fdb54c8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jul 4 16:30:19 2018 -0700
Build system: Fix OCTAVE_PREFIX (and derived OCTAVE_M_DIR) configuration bug for the octave-4.4 case
For octave-4.4 __octave_config_info__("prefix") has stopped working,
and the similar
octave-config --print PREFIX
command generates an empty string. Experimentally, I have discovered
that although __octave_config_info__("octave_home") does not work
octave-config --print OCTAVE_HOME
does generate the appropriate "/usr" string representing the install
prefix for octave.
Therefore, I have replaced all instances of using the
__octave_config_info__ octave function with the equivalent
octave-config command, and solved the OCTAVE_PREFIX issue for
octave-4.4 by searching first for PREFIX, and if that generates an
empty string, search for OCTAVE_HOME instead. This fix also solved
the (derived) OCTAVE_M_DIR issue where that variable had the wrong
install prefix.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring PLplot with cmake and demonstrating via
those results that OCTAVE_PREFIX and the derived OCTAVE_M_DIR are now
defined properly again for octave-4.4. As far as I know, this fix has
been made in a backwards-compatible way, i.e., it should work for
octave-3, but I am not in position to test that.
M cmake/modules/octave.cmake
commit 4e36c1d0e2e6f31af678a3d7fc27cf0f0b0ce793
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jul 4 13:19:28 2018 -0700
Build system: Fix lua and octave rebuild bugs
A maintenance quirk for the PLplot build system is that when examples
are (temporarily) dropped (as in previous lua and octave commits to
avoid exposing lua and octave upstream bugs, GRR) it is necessary to
drop those examples from the list_example_files function in
cmake/modules/plplot_functions.cmake to avoid rebuild bugs such as the
ones fixed by this current commit.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by building the test_diff_psc target twice and
demonstrating for the second of those that there are no unnecessary
rebuilds such as occurred for lua and octave examples prior to this
commit.
M cmake/modules/plplot_functions.cmake
commit ade600099f51564eef1a80acebac94dd90623069
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jul 4 11:41:40 2018 -0700
Style previous commits
M bindings/octave/plplot_octave.i
M lib/csa/csa.c
commit 7bc62a898d483b92c4a122bb057649ad1bdf6b32
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jul 4 11:09:15 2018 -0700
Build system: fix "cmake -E copy_if_different" re-copy bugs
The problem with using "cmake -E copy_if_different" within custom
commands and targets is the date does not get updated when the file is
the same (e.g., when the source file for the copy is touched
explicitly or implicitly via git workflow). This means the "cmake -E
copy_if_different" command and *all* target dependencies of that command get
incorrectly re-run until you start fresh from an empty build tree.
This commit solves these bugs by replacing "cmake -E
copy_if_different" for all cases where it occurs in a custom command
or target with "cmake -E copy" since the latter command always updates
the timestamp of the destination file which effectively eliminates
further re-copies.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by rebuilding the octave_examples and lua_examples
targets for a case where certain of the octave and lua examples had
been touched by git workflow). The result was the touched source
files were updated in the build tree once, and then after that the
timestamps on those updated files kept the command from incorrectly
being re-run.
N.B. there are other lua and octave incorrect re-run issues exposed by
running the test_diff_psc target twice. Those issues still require
further investigation, but this commit, at least, eliminates the
re-copy issue that was obfuscating the test_diff_psc target issue.
M bindings/ada/CMakeLists.txt
M bindings/ocaml/CMakeLists.txt
M bindings/ocaml/plcairo/CMakeLists.txt
M bindings/tcl/CMakeLists.txt
M examples/lua/CMakeLists.txt
M examples/ocaml/CMakeLists.txt
M examples/python/CMakeLists.txt
M examples/tcl/CMakeLists.txt
M examples/tk/CMakeLists.txt
M plplot_test/CMakeLists.txt
M www/announce/CMakeLists.txt
commit 014bbe28f756c55f02b8152b0e7d10c185da489f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Jul 3 16:17:09 2018 -0700
octave binding and examples; adjust for octave-4 changed interpretation of strings
The octave-4 difference we are adjusting for is that NULL's embedded
in strings no longer terminate output of printf, etc. Instead, the
entire string is output with embedded NULL's ignored.
To adjust for this change, the octave binding of plplot stores the
results from plgver, plgdev, and plgfnam (all the PLplot API with
output character string arguments) in an ordinary C string, and
inserts the NULL-terminated substring of those results into an octave
charMatrix which is then returned to the octave environment as an
octave string of the correct (NULL-terminated) length.
N.B. Backwards-incompatible change to plgver, plgdev, and plgfnam.
The results for these functions are backwards incompatible because the
result returned to the octave environment is a string rather than the
transpose of a string which was the previous (badly designed)
historical result. Also note because of bad historical choices there
are many other data returned by the current octave binding for PLplot
where the transpose must be taken and the long-term plan is to
introduce more backwards-incompatible changes by getting rid of all
these unnecessary transposes. So this commit is the first step toward
that goal.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring PLplot with cmake 3.11.2 using the
options -DBUILD_TEST=ON -DTRY_OCTAVE4=ON -DUSE_INCRTCL_VERSION_4=ON
and building the test_diff_psc target. The configuration, build, and
run time results had no obvious errors, and the present commit solved
stdout differences for the octave part of the PostScript difference
report. Therefore, the exceptions to a perfect PostScript difference
report are now reduced to
octave
Missing examples : 26 33
Differing graphical output :
Missing stdout :
Differing stdout :
lua
Missing examples : 23
Differing graphical output :
Missing stdout :
Differing stdout :
where those missing examples are a temporary workaround to avoid
exposing upstream bugs in octave 4 (likely 8-bit clean issues with
octave-4 UTF-8 handling of strings) and lua5.3 (see
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for details
of this severe bug).
M bindings/octave/INSTALL
M bindings/octave/PLplot/figure.m
M bindings/octave/plplot_octave.i
M examples/octave/x01c.m
M examples/octave/x14c.m
commit 0b14d2a56623e88a4cf5431d36b0c1ac187628a2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jun 23 14:56:10 2018 -0700
Adjust Lua examples so they give correct results for Lua5.3
All these issues are caused by Lua5.3 implementing default formatting of the
conversion of numbers to strings that is different than prior
versions. So in each case the example correction was to replace
default formatting with definite formatting when converting numbers to
strings.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by building the test_diff_psc target. The previous
lua component of the report was
lua
Missing examples :
Differing graphical output : 14a 19 23
Missing stdout :
Differing stdout : 31
This and the prior commit substantially improved this result to
lua
Missing examples : 23
Differing graphical output :
Missing stdout :
Differing stdout :
where the remaining issue (example 23 missing from lua testing) is by
design to avoid exposing an upstream bug with lua5.3. (See the
previous commit message for more details about this issue.)
M examples/lua/x14.lua
M examples/lua/x19.lua
M examples/lua/x31.lua
commit 61be11becdc4577a01ffe3c1dde207530deed92e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jun 23 14:50:45 2018 -0700
Drop lua example 23 from tests to avoid upstream lua5.3 bug
The upstream bug is a severe one, see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238>
for details. Therefore, all we can do on the PLplot side of things is to avoid exposing
this bug by not running lua example 23 in our tests.
M plplot_test/test_lua.sh.in
commit 9893349d1408545275d4f4187d4b7ba745a3c3db
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jun 20 14:36:36 2018 -0700
Build system: Force DROP_GTK_PLUS_2_BUILDS to be ON
The fundamental purpose of this change is to make sure all our GTK+
dependencies are version 3 rather than version 2 since version 3 has
long been the standard version of GTK+ and a combination of versions 2
and 3 will likely not work in any case.
The practical implication of this change is
examples/c/extXdrawable_demo.c is never built since that app consists
of calls to GTK+ API that was already deprecated in GTK+ version 2 and
completely removed in GTK+ version 3. In addition, this change means
the PLplot ocaml "cairo" API cannot be used, but that API has already
been disabled due to lack of maintenance.
M cmake/modules/plplot.cmake
commit 99472347145a5faa94411ed81f10ed028f2411cf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jun 9 13:09:40 2018 -0700
First collection of changes to make PLplot support modern versions (as available from Debian Buster) of free software
These changes are as follows:
* Support Lua version 5.3 (and likely versions back to 5.2). Along
with updates to cmake/modules/lua.cmake, this change required
updating the cmake/modules/FindLua.cmake to be consistent with the
CMake version 3.8.0 official version of this find module. The
following minor change was required to make this find module work as
part of the PLplot build system:
______________________________
software@merlin> diff -au Modules/FindLua.cmake ~/plplot/HEAD/plplot.git/cmake/modules/
--- Modules/FindLua.cmake 2018-06-09 10:41:24.374851079 -0700
+++ /home/software/plplot/HEAD/plplot.git/cmake/modules/FindLua.cmake 2018-05-20 14:51:32.760113838 -0700
@@ -187,7 +187,8 @@
endif ()
endif ()
-include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
+#include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
+include(FindPackageHandleStandardArgs)
# handle the QUIETLY and REQUIRED arguments and set LUA_FOUND to TRUE if
# all listed variables are TRUE
FIND_PACKAGE_HANDLE_STANDARD_ARGS(Lua
______________________________
The plan is to drop this find module from PLplot and use the official
version from then on once our minimum version of CMake is 3.8.0 or
higher.
* Support gdc version 7 (and likely version 6 and possibly 5). The
principal change here is to adjust for a rename of libgphobos2
(required by gdc version 4) ==> libgphobos. The libgphobos2 name was
used for Debian Jessie gdc 4.9.2 and was changed to the libgphobos
name somewhere between that version and gdc version 6. Note this
entire set of gdc-related changes was so simple it is likely we do
support gdc-6 and we might even support gdc-5 if that version uses
the new libgphobos name, but I am not in position to test either
gdc-6 or gdc-5.
* Support octave version 4.2.2 (and likely prior 4.x versions as well
as octave 3.8.2 that was so well-tested on Debian Jessie). The
principal change here is to use __octave_config_info__ if available
with a fallback to octave_config_info (deprecated for 4.2.2 in
favour of __octave_config_info__) to quiet deprecation messages. In
addition, I temporarily dropped octave standard examples 26 and 33
(two of our 4 UTF-8 examples) because they appear to expose
eight-bit clean issues for octave 4.2.2 that mess up UTF-8 strings
in PLplot arguments some of the time. This issue needs further
study, but will likely need to be addressed upstream by the octave
developers.
* Work around what appears to be an issue with gcc version 7.3.0-21
from Debian Buster where the explicit (or implicit via -O3) use of
the -finline-functions gcc option causes segfaults in the
libcsirocsa library.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Buster) by configuring the PLplot build using the cmake
(version 3.11.2 from Buster) options -DBUILD_TEST=ON -DTRY_OCTAVE4=ON
-DUSE_INCRTCL_VERSION_4=ON, and within the build tree for the shared
library case, building the test_noninteractive and all targets, and
running ctest.
There was one minor configuration regression compared to Debian Jessie
results, i.e.,
-- Determine compile and link flags for extXdrawable_demo
-- Checking for module 'gtk+-x11-2.0'
-- No package 'gtk+-x11-2.0' found
-- WARNING: gtk+-x11-2.0 not found. extXdrawable_demo not built.
The solution is to update extXdrawable_demo so it works with GTK+ version 3.
There was also no obvious build or run-time errors for these tests.
However, the following PostScript regressions were introduced compared
to the Jessie results:
[...]
octave
Missing examples : 26 33
Differing graphical output :
Missing stdout :
Differing stdout : 01 14
[...]
lua
Missing examples :
Differing graphical output : 14a 19 23
Missing stdout :
Differing stdout : 31
The missing octave examples were necessary because of the (likely)
upstream octave 4.x regressions with 8-bit clean handling of UTF-8
strings compared to octave-3.8.2. The remaining PostScript
regressions relative to Debian Jessie need further study but will
likely be solved by adjusting the relevant examples so they work
properly on octave-4 and Lua-5.3.
M cmake/modules/FindLua.cmake
M cmake/modules/language_support/cmake/CMakeDInformation.cmake
M cmake/modules/language_support/cmake/CMakeDetermineDCompiler.cmake
M cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake
M cmake/modules/lua.cmake
M cmake/modules/octave.cmake
M lib/csa/CMakeLists.txt
M lib/csa/csa.c
M plplot_test/test_octave.sh.in
commit f580dd5c22f070d44362a777ddb2256f8857f27d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Apr 15 13:25:40 2018 -0700
Build system: Fix -DTEST_DYNDRIVERS=ON case when -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON
My previous tests of -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON found issues
with (the default) -DTEST_DYNDRIVERS=ON case which are fixed in this commit.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
time (nice -19 scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON" --build_command "make -j4 -k" --do_test_install_tree no --do_test_traditional_install_tree no --do_submit_dashboard no)
(Note because this command was run from a "spaced" source tree and the above
"spaced" --prefix, this test has a space in the prefixes of the source, build,
and install trees.)
Check the results:
# Check for any regressions in the warnings in the cmake output.
less ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out
# Check for some non-standard warnings:
grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'cmake.out|ctest.out' |grep -vEi 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout|unused|uninitialized'
# Check for all errors:
grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out
# Check for any ldd issues for the shared and nondynamic cases.
# N.B. commented out because the above comprehensive_test.sh options preclude
# checking for ldd issues so there are no *.ldd.out files to check.
#grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
# Check for any PostScript or Text differences between all non-C languages and the corresponding
# C results.
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
These checks showed no configure, build, run-time, or PostScript
difference issues with the above comprehensive test (limited to just
the build-tree case because of the
-DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON side effect that would
cause errors for the install-tree case).
I additionally checked the
-DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=OFF case by building from
a fresh start the test_diff_psc target for both the (default)
-DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=OFF case as well as the
-DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON case that is redundant
with one part of the above comprehensive test. All was well for the
OFF case, but I got Ada build errors for the ON case that disappeared
again when I ran that test for the second time (from an identical
clean start in both cases). So I am still encountering intermittent
Ada build errors (in this case for the first
-DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON case above, but not for
any of the other cases) even though my extensive testing of my
hardware indicates no issues. Currently, I think the most likely
explanation of these intermittent errors is and Ada build tool bug
<https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=65451>
whose fix is not present in the ancient (4.9.2) version of Ada build
tools I have access to at the moment. (See further discussion on the
PLplot devel list).
Therefore, from these good comprehensive and test_diff_psc target
results (if you exclude the case where intermittent Ada build issues
showed up for the test_diff_psc target) it appears all non-prefixed
writeable library target references in our build system have been
eliminated (at least for the CMake logic exercised by the above
tests).
M drivers/CMakeLists.txt
M drivers/test-drv-info.c
commit 0df4e30e6b469edac0ae6cea8c32250201f8341f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Apr 6 14:58:02 2018 -0700
Build system: Implement TEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS experimental option
This new option defaults to OFF (which unsets the CMake variable
LIBRARY_TARGET_PREFIX), but when this option is ON the CMake variable
LIBRARY_TARGET_PREFIX is set to "temporary_target_". This commit also
changes all writeable library targets in the build system (and also as
an unwanted side effect [see below] that limits what we can test when
-DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON the corresponding dll
or library filename) to have a prefix of ${LIBRARY_TARGET_PREFIX}. So
as a result of this commit and a prior commit that prefixed all
read-only library targets with "PLPLOT:::, all library targets in our
core build system that we use for the build tree should have a prefix
of either ${LIBRARY_TARGET_PREFIX} or "PLPLOT::". Therefore when
-DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON any exercised CMake
code that refers to an unprefixed library target such as "plplot" will
error out with an unknown target message at cmake time or some other
error message at run time.
Of course, CMake code paths not followed can still refer to unprefixed
library targets so it is useful to use
-DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON for as wide variety of
configuration, build, and test conditions as provided by
scripts/comprehensive_test.sh to test as much of CMake logic in the
build-tree build system as possible. However, note that such tests
must be limited just to build-tree tests since the side effects
mentioned above completely screw up both the CMake-based and
traditional install-tree build systems. Furthermore, I have not yet
figured out how to make this all work for the (default)
-DTEST_DYNDRIVERS=ON case so my tests below used
-DTEST_DYNDRIVERS=OFF.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running (from a source tree with a space in the
prefix)
time (nice -19 scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_added_options "-DTEST_DYNDRIVERS=OFF -DTEST_BUILD_TREE_WRITEABLE_LIBRARY_TARGETS=ON" --build_command "make -j4 -k" --do_test_install_tree no --do_test_traditional_install_tree no)
(Note because of the choice of a "spaced" source tree and the above
--prefix, this test has a space in the prefixes of the source, build,
and install trees.)
Check the results:
# Check for any regressions in the warnings in the cmake output.
less ../comprehensive_test_disposeable\ blank/*/*/output_tree/cmake.out
# Check for some non-standard warnings:
grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout'
# Check for all errors:
grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out
# Check for any ldd issues for the shared and nondynamic cases.
grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
# Check for any PostScript or Text differences between all non-C languages and the corresponding
# C results.
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
These checks showed intermittent failures for certain parts
(xtraditional28a, xtraditional33a) of the Ada part of the build with
two separate complaints about various files written by the gnat
compiler. At this stage I cannot figure out the source of this issue
since it comes and goes and is hard to reproduce. But at one point I
got through the entire test above without Ada failures, and found an
obvious issue with the static OCaml binding library which I fixed and
which has absolutely nothing to do with Ada. I then tried the test
above again, which failed for the nondynamic case for the build of one
of the Ada examples. I then followed up by a specific static build of
the ocaml binding library that exercised the fixed build-system CMake
code for that case, and all was well. Therefore, I think from these
piecemeal results that all is well with the current commit, but
further testing needs to be done as above once I figure out the source
of the intermittent Ada build errors.
N.B. I have run
git fsck --strict --no-dangling
before this commit. That result showed the git filesystem had no
inconsistencies. Normally (from past experience with a slowly failing
disk), there are such inconsistencies whenever the disk is
experiencing some bad block issues. So the good result for this
command is encouraging with regard to the health of my computer
hardware. But "just in case", I plan to run the same git fsck command just
before the push of this commit and will only do that push if
the fsck is again a success.
M CMakeLists.txt
M bindings/ada/CMakeLists.txt
M bindings/c++/CMakeLists.txt
M bindings/d/CMakeLists.txt
M bindings/fortran/CMakeLists.txt
M bindings/java/CMakeLists.txt
M bindings/lua/CMakeLists.txt
A bindings/lua/lua_namespace.i.in
M bindings/lua/plplotluac.i
M bindings/ocaml/CMakeLists.txt
M bindings/ocaml/plcairo/CMakeLists.txt
M bindings/octave/CMakeLists.txt
R075 bindings/octave/plplot_stub_hand_crafted.m bindings/octave/plplot_stub.m.in
M bindings/python/CMakeLists.txt
M bindings/qt_gui/CMakeLists.txt
M bindings/qt_gui/pyqt4/CMakeLists.txt
M bindings/qt_gui/pyqt5/CMakeLists.txt
M bindings/qt_gui/smoke/CMakeLists.txt
M bindings/qt_gui/smoke/plplotqt.pro.in
M bindings/tcl/CMakeLists.txt
M bindings/tk-x-plat/CMakeLists.txt
M bindings/tk/CMakeLists.txt
M bindings/wxwidgets/CMakeLists.txt
M cmake/modules/cgm.cmake
M cmake/modules/drivers-finish.cmake
M cmake/modules/plplot_functions.cmake
M cmake/modules/qt.cmake
M cmake/modules/tk.cmake
M doc/docbook/src/CMakeLists.txt
M drivers/CMakeLists.txt
M examples/CMakeLists.txt
M examples/ada/CMakeLists.txt
M examples/c++/CMakeLists.txt
M examples/c/CMakeLists.txt
M examples/d/CMakeLists.txt
M examples/fortran/CMakeLists.txt
M examples/lua/CMakeLists.txt
M examples/lua/plplot_examples.lua.in
M examples/octave/CMakeLists.txt
M examples/python/CMakeLists.txt
M examples/python/pyqt4_example.py
M examples/python/pyqt5_example.py
M examples/tcl/CMakeLists.txt
M examples/tk/CMakeLists.txt
M fonts/CMakeLists.txt
M include/pldll.h.in
M lib/csa/CMakeLists.txt
R096 lib/csa/csadll.h lib/csa/csadll.h.in
M lib/nistcd/CMakeLists.txt
R096 lib/nistcd/cddll.h lib/nistcd/cddll.h.in
M lib/nn/CMakeLists.txt
R096 lib/nn/nndll.h lib/nn/nndll.h.in
M lib/qsastime/CMakeLists.txt
R096 lib/qsastime/qsastimedll.h lib/qsastime/qsastimedll.h.in
M src/CMakeLists.txt
M utils/CMakeLists.txt
commit 9cc1d067ee7fd7213d17ac1d737515828cad4d19
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Mar 23 17:15:46 2018 -0700
Build system: configure a more uniform build of modules, swig-generated modules, static libraries and shared libraries
I implemented this change using the new configure_library_build
function that replaces the previously used (and misnamed)
build_library function. This new CMake function has a different set
of arguments then the removed build_library function. This new
function allows not only the configuration of new explicit STATIC and
SHARED builds or the old implied (via BUILD_SHARED_LIBS) STATIC or
SHARED builds, but also the explicit new configuration of MODULE (dll)
and swig-generated MODULE builds. The type of library (i.e., "" [if
decided by BUILD_SHARED_LIBS], "MODULE", "STATIC", "SHARED", or a
language such as "python" [if a swig-generated module]) is now
specified as the second argument. In addition the old trailing
namespace argument is dropped in favour of an external variable
LIBRARY_NAMESPACE that should be set (with a trailing "::") globally
once for a given project, e.g.,
set(LIBRARY_NAMESPACE "PLPLOT::")
for the PLplot project.
As a result of this current commit, the "add_library" string only appears in the
following files in the PLplot source tree:
software@raven> find . -type f |grep -v .git |xargs grep -il 'add_library'
./ChangeLog.release
./cmake/test_ada/src_lib/CMakeLists.txt
./cmake/modules/UseSWIG.cmake
./cmake/modules/plplot_functions.cmake
./cmake/epa_build/libagg/libagg_CMakeLists.txt
./cmake/epa_build/libqhull/src/CMakeLists.txt
./cmake/epa_build/libharu/cmake.patch
./cmake/epa_build/shapelib/shapelib_CMakeLists.txt
./cmake/test_fortran/src_lib/CMakeLists.txt
That is, if you look just at the PLplot project (i.e., you exclude
historical mentions [ChangeLog.release] and various epa_build and test
mini-projects), the actual use of the add_library command is reduced
to the UseSWIG.cmake module copied from the CMake project and the
configure_library_build function in plplot_functions.cmake. In other
words the configuration of the builds of shared objects now proceeds
in a uniform manner for PLplot that is controlled by the logic in the
configure_library_build function, and any idiosyncratic target
property adjustments that might be done after the call to
configure_library_build for each CMake "library" (actually a library
or a dll) built by PLplot.
Additional cleanups and changes:
* For the swig-generated MODULE's, I now use
${SWIG_MODULE_${swig_target_name}_wrap_REAL_NAME}, e.g.,
${SWIG_MODULE_plplotc_wrap_REAL_NAME} to refer to the real target
name after configure_build_library is called. This automatically
takes care of issues such as the "_" prefix used for the actual
_plplotc target that is used when configuring swig-generated Python
builds.
* For the swig-generated MODULE's, I now have dropped all PREFIX and
SUFFIX overwrites on the module properties. Instead, I now rely on
UseSWIG.cmake to set these properties correctly for each given Swig
language. And it appears that is currently done consistent with our
previous overwrites. However, if there is some PREFIX or SUFFIX
screwup in UseSWIG.cmake for any Swig language or platform, I will
adjust that file accordingly and report the issue to CMake as a
CMake bug.
* Had to set smokeplplotqt_SOVERSION and smokeplplotqt_VERSION in
cmake/modules/plplot_versions.cmake so the smokeplplotqt library
build could be configured in the standard way using configure_library_build.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by configuring PLplot with the -DENABLE_smoke=ON
-DBUILD_HERSHEY_FONTS=ON options (to allow testing the build of the
smokeplplotqt and hershey libraries) and by building the following
targets:
* smokeplplotqt
There were no configure or build issues and ldd -r showed no
run-time loader or symbol issues with this library (currently only
used externally by one of Hazen Babcock's projects, but it would be
good to implement at least a simple run-time test of this library as
part of PLplot).
* generate_stndfonts and generate_xtndfonts
These targets build executables which link to the static hershey library,
and I tested these executables as follows:
ldd -r fonts/generate_stndfonts
ldd -r fonts/generate_xtndfonts
fonts/generate_stndfonts
diff plstnd5.fnt ../plplot.git/data/
fonts/generate_xtndfonts
diff plxtnd5.fnt ../plplot.git/data/
The diffs showed no changes compared to the source-tree versions
of these generated Hershey font files.
* test_noninteractive
There were no configuration, build, run-time, or
Postscript differences with this target.
* test_interactive
There were no configuration, build, or run-time
issues with this target.
N.B. the above good test_noninteractive and test_interactive tests are
not comprehensive. For example, the present changes have just been
tested in the build tree and just for the shared libraries/dynamic
devices case to save time. So planned future comprehensive tests that
do test many more configuration possibilities for both build-tree and
install-tree may turn up additional issues for the present intrusive
commit.
M CMakeLists.txt
M bindings/ada/CMakeLists.txt
M bindings/c++/CMakeLists.txt
M bindings/d/CMakeLists.txt
M bindings/fortran/CMakeLists.txt
M bindings/java/CMakeLists.txt
M bindings/lua/CMakeLists.txt
M bindings/ocaml/CMakeLists.txt
M bindings/ocaml/plcairo/CMakeLists.txt
M bindings/octave/CMakeLists.txt
M bindings/python/CMakeLists.txt
M bindings/qt_gui/CMakeLists.txt
M bindings/qt_gui/pyqt4/CMakeLists.txt
M bindings/qt_gui/pyqt5/CMakeLists.txt
M bindings/qt_gui/smoke/CMakeLists.txt
M bindings/tcl/CMakeLists.txt
M bindings/wxwidgets/CMakeLists.txt
M cmake/modules/plplot_functions.cmake
M cmake/modules/plplot_version.cmake
M drivers/CMakeLists.txt
M examples/fortran/CMakeLists.txt
M fonts/CMakeLists.txt
M lib/csa/CMakeLists.txt
M lib/nistcd/CMakeLists.txt
M lib/nn/CMakeLists.txt
M lib/qsastime/CMakeLists.txt
M src/CMakeLists.txt
commit f4d7e1a30ec3a8e071574865d7780fce8d411fbd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Mar 16 19:21:05 2018 -0700
Python binding: Improve UTF-8 fixup
Our swig documentation strings (which include some UTF-8 glyphs such as
"≥") are propagated directly to the swig-generated bindings/python/plplotc.py
Python script. So years ago when our bindings were strictly Python2 we
had to implement a sed fixup to modify that file to append " It uses coding: utf-8"
to the first line of that file to signal (according to PEP 263) that the encoding
of that file is UTF-8.
This commit improves the implementation of this fixup as follows:
* Changed the implementation from using an additional
add_custom_command/add_custom_target pair to the much simpler
add_custom_command(TARGET _plplotc POST_BUILD ...) signature.
The result is the same; the sed fixup occurs *AFTER*
whenever swig (re-)generates bindings/python/plplotc.py.
* It turns out that this fixup is not needed for Python3 because
for that version of Python the default encoding is UTF-8. Therefore,
only implement the fixup for the Python2 case.
* Because of the new implementation, the _plplotc_fixed target no
longer exists. So replace that target with the _plplotc target
wherever it occurs in our build system.
* Change the comments in README.Release_Manager_Cookbook accordingly.
As a result of this commit "_plplotc_fixed"
no longer exists in our source tree except for the historical
ChangeLog.release file.
N.B. Note this remaining small Python2 fixup is actually a workaround
for either a Python2 issue (for defaulting to ascii encoding rather
than UTF-8) or else swig issue for not working around this Python2
issue. But I have decided not to report this issue because of the
uncertainty of where to report it and because it is undoubtedly an
uncommon issue that is getting rarer (because Python2's share of the
Python market keeps dropping). In fact Python3 is working so well for
PLplot, I plan to deprecate and eventually remove our Python2 support
(including the current fixup) in the intermediate term (i.e., within a
year or two).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by freshly configuring PLplot with either
the set of CMake options
# The python2 case
-DBUILD_TEST=ON --DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON -DFORCE_PYTHON2=ON
or
# The (default) python3 case
-DBUILD_TEST=ON --DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_python=ON
For both cases, building the test_diff_psc target showed no configuration, build,
run-time, or PostScript difference issues.
M README.Release_Manager_Cookbook
M bindings/python/CMakeLists.txt
M doc/CMakeLists.txt
M examples/CMakeLists.txt
M examples/python/CMakeLists.txt
commit 593c07fcea6402b03c6b9c47842b09284bf2a1b2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Mar 14 16:22:44 2018 -0700
PLplot build system: configure library builds in a more uniform manner
I replaced calls to add_library, target_link_libraries, and the
set_library_properties function with a call to the build_library
function which for standard libraries can either be static or shared
(but not STATIC only and not MODULE). This function calls add_library,
creates a namespaced ALIAS library corresponding to that library,
calls target_link_libraries in a standard way, and sets standard
library properties. Thus, this change significantly reduces
the CMake code used to build our libraries and makes sure such
building is done in a more uniform way.
These new ALIAS libraries will be required in the future (so that the
installed libraries can have namespaced targets associated with them
so that common code between build tree and install tree can use
namespaced library targets). But the future plan is not to confine
the use of namespaced targets just to the common code but also use
them everywhere in the build tree where a library target is used in a
read-only way as a matter of style (and safety for the
target_link_libraries item case). So for this commit I used ALIAS
library targets in a small way to test them in
that context.
I also deleted the set_library_properties function since it is no
longer used.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_noninteractive and
test_interactive targets for shared libraries in the build tree
without any configure, build, run-time, or PostScript difference
issues.
M bindings/ada/CMakeLists.txt
M bindings/c++/CMakeLists.txt
M bindings/d/CMakeLists.txt
M bindings/fortran/CMakeLists.txt
M bindings/qt_gui/CMakeLists.txt
M bindings/tcl/CMakeLists.txt
M bindings/wxwidgets/CMakeLists.txt
M cmake/modules/plplot_functions.cmake
M cmake/modules/plplot_version.cmake
M fonts/CMakeLists.txt
M lib/csa/CMakeLists.txt
M lib/nistcd/CMakeLists.txt
M lib/nn/CMakeLists.txt
M lib/qsastime/CMakeLists.txt
M src/CMakeLists.txt
commit ce4c2129fbcbb196a9e9276d1f38fb0c2b25d6a6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Mar 14 16:21:55 2018 -0700
PLplot build system: update some copyright years
M bindings/java/CMakeLists.txt
M bindings/lua/CMakeLists.txt
M bindings/ocaml/plcairo/CMakeLists.txt
M bindings/octave/CMakeLists.txt
M bindings/python/CMakeLists.txt
M bindings/qt_gui/pyqt4/CMakeLists.txt
M bindings/qt_gui/pyqt5/CMakeLists.txt
M bindings/qt_gui/smoke/CMakeLists.txt
M drivers/CMakeLists.txt
M examples/fortran/CMakeLists.txt
commit d705381c6cdf99a390bdec22d859e45b5ef13e60
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Mar 13 13:58:27 2018 -0700
PLplot library: Fix bug in command-line parsing for the PL_PARSE_NODELETE case
This long-standing bug (which has been revealed by the recent x01c.c
change which calls plparseopts with the PL_PARSE_NODELETE option) is
the number of command-line options after command-line processing
(stored in *p_argc) was being updated when the PL_PARSE_NODELETE
option was specified. The result was calls to plparseopts after the
first call to that routine in x01c did not have the correct number of
command-line options. This commit fixes this bug.
I also took this opportunity to improve the documentation of the
-pl_parse_skip example option for x01c to make clear that this option
must precede any non-PLplot options if the user is to avoid
command-line parsing errors for this example.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
examples/c/x01c
(which uses the PL_PARSE_NODELETE option in the first call to
plparseopts) with all sorts of different option patterns both
with and without the example -pl_parse_skip option.
In all cases with -pl_parse_skip I obtained the expected results. If
this option preceded zero or more non-PLplot options, the number of options
printed out by that option were correct both before and after the call
to plparseopts with the PL_PARSE_SKIP option. However, if non-PLplot
options preceded -pl_parse_skip, gdb showed the first call to
plparseopts with the PL_PARSE_NODELETE option silently failed with the
pl_parse_skip_mode variable not set with the subsequent plparseopts
call with PL_PARSE_FULL failing (as expected) because of those
non-PLplot options.
In all cases without -pl_parse_skip I also obtained the expected
results (i.e., no command-line option processing errors unless
non-PLplot options were used, and the expected interactive or
noninteractive plot results.)
M examples/c/x01c.c
M src/plargs.c
commit 734aba7a3e08e7908ae4f2aefa88c64bd94acaab
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Sat Feb 3 21:02:26 2018 +0000
Fixed possible uninitialised variable bug in wxPLplotwindow class
There were execution paths where the wxDC pointer would not get
initialised before it was passed into the stream in the
setUseGraphicsContext method. This is now fixed. Thanks David Bergman
for the bug report on the email list.
M bindings/wxwidgets/wxPLplotwindow.h
commit d2a1a6d61ca0deb9025c019ed9d8d27577beb964
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Sun Jan 7 12:05:39 2018 +0100
Add new routines to the list of exported routines
To build the library and the examples with the new routines to parse the command-line arguments we need to export these routines for Intel Fortran.
Tested by: Arjen Markus <arjenmarkus@users.sourceforge.net> on bare Windows with the Intel Fortran compiler
M bindings/fortran/plplotfortran_ifort.def
commit 70ec495533cb117016933f29239e7d2201f6fd9c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 5 17:51:26 2018 -0800
Fortran binding: Fix dropped specification of the defined region of cstring_address_arg_inout in plparsopts_dynamic
This commit fixes a dropped (1:size_local) slice which specifies where
cstring_address_arg_inout is defined for the
max_cstring_length call. My hope is this change will fix
memory management issues encountered by Arjen when he tested
plget_arguments_dynamic and plparseopts_dynamic with modern
gfortran and ifort.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie with gfortran-4.9.2) by building the plplotfortran
binding library without issues. This change could not be tested
at run-time because of allocatable length/size character
array issues with (the ancient) gfortran-4.9.2.
N.B. testing requested for modern gfortran and ifort.
M bindings/fortran/plplot.f90
commit 3ee657ef568dc4f16eb0d5ad3d653ce4a10d9ebf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Jan 2 12:59:15 2018 -0800
Fortran binding: Tweak severe warning messages for parsing API
M bindings/fortran/plplot.f90
commit 9fcc4d642ac3d65df16d08098f20dc7179a22570
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Jan 2 12:13:25 2018 -0800
Fortran standard example 01: restore default pl_parse_dynamic = .false.
This is to correct my inadvertent commit of a local test case where I
set pl_parse_dynamic = .true.
M examples/fortran/x01f.f90
commit 6f2f4e4f43f755dcfee28c590e61039cf017de86
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Jan 1 15:31:23 2018 -0800
Fortran binding: implement dynamic length and size and static length and dynamic size variants of plget_arguments and plparseopts
These new variants of plget_arguments and plparseopts were added to the
existing static length and size variants. In addition, examples/x01f.f90 was
updated to test all variants of plget_arguments and plparseopts.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie with gfortran-4.9.2). With this version of gfortran,
the dynamic length and size variant of the API did not work at run
time, but both the static length and dynamic size and static length
and size variants did work. For further details about how to run
these tests and the results obtained, see README.release.
Additional testing using more modern gfortran versions and other
Fortran compilers is requested.
M README.release
M bindings/fortran/plplot.f90
M bindings/fortran/plplot_small_modules.f90
M examples/fortran/x01f.f90
commit dee0caa5225688b7bcfb6571c12da9db4fbaba69
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 26 16:03:30 2017 -0800
Fortran binding: Fix off-by-one error in plplot_private_utilities::c_to_character_array
This routine blanks the tail end of output character array results, and the issue
that was fixed was this blanking started one character too soon.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the x01f and ps targets (with the x01f
source code locally modified to set pl_parse_skip_mode to .true.) and
running
software@raven> examples/fortran/x01f xxx -dev psc yyy -o testf.psc zzz
argv before call to plparseopts(..., PL_PARSE_SKIP)
i = 0, argument = examples/fortran/x01f
i = 1, argument = xxx
i = 2, argument = -dev
i = 3, argument = psc
i = 4, argument = yyy
i = 5, argument = -o
i = 6, argument = testf.psc
i = 7, argument = zzz
argv after call to plparseopts(..., PL_PARSE_SKIP)
i = 0, argument = examples/fortran/x01f
i = 1, argument = xxx
i = 2, argument = yyy
i = 3, argument = zzz
PLplot library version: 5.13.0
Before this fix all the trailing
i = [0-3] ....
results were incorrectly truncated by one letter.
M bindings/fortran/plplot_small_modules.f90
commit 71944dbd48f1c29c99252b862e5105b842ca478c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 25 22:55:51 2017 -0800
C example 01 and Fortran binding and example 01: improvements in command-line parsing
The C example improvement was to implement the -pl_parse_skip option
for examples/c/x01c.c that demonstrated the existing PL_PARSE_SKIP
mode of the C version of plparseopts. The Fortran binding improvement
was to make similar PL_PARSE_SKIP mode functionality available for
that binding via and added variant of the plparseopts API and a new
Fortran function called plget_arguments. The
examples/fortran/x01f.f90 improvement was to implement a demonstration
of that capability that gave the same results as the corresponding C
results. For further details see the write-up concerning these
changes in README.release.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie with gfortran-4.9.2) by building the x01c, x01f, and ps
targets, and running valgrind in the way described in README.release
with perfect results.
M README.release
M bindings/fortran/included_plplot_real_interfaces.f90
M bindings/fortran/plplot.f90
M bindings/fortran/plplot_small_modules.f90
M examples/fortran/x01f.f90
commit b224a834e4ff3b59a83f97a6e185658e5ed9b768
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 24 15:18:11 2017 -0800
plplot library: fix memory leak in plparseopts if that function is called more than once
Each call of plparseopts allocates memory to store plsc->program, and
that memory is normally deleted later in plend1. However, if plparseopts
is called multiple times with no plend1 call in between ==> memory leak.
This commit addresses that issue by freeing non-NULL plsc->program in
plparseopts before plsc->program is allocated.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the x01c and ps targets and running
valgrind examples/c/x01c.c -dev psc -o testc.psc
with perfect results (0 errors, no leaks are possible).
Note that example/c/x01c.c is a good test case because it calls
plparseopts twice (the first time with PL_PARSE_NODELETE, the second
time with PL_PARSE_SKIP or PLPARSE_FULL depending on the results from
the first call). Before this fix, the valgrind report showed a memory
leak for this example.
M src/plargs.c
commit 1b0b78f8f158abce519c655a2be3f6ac37115036
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 23 13:51:19 2017 -0800
C standard example 01: implement -pl_parse_skip option for the example
Note, the -pl_parse_skip command-line option demonstrates the
PL_PARSE_SKIP mode for plparseopts, which parses just the
PLplot-relevant options leaving the non-PLplot options for further
parsing. Thus, this option demonstrates the first part of how you
would parse a mixture of PLplot and non-PLplot command-line options
from C, and the long-term intention is to propagate this example
option to standard example 01 for fortran first, and then the rest of
our supported languages to demonstrate parsing a mixture of PLplot and
non-PLplot command-line options is possible for those languages as
well.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the x01c and ps targets and running
software@raven> examples/c/x01c -pl_parse_skip xxx -dev psc yyy -o test1.psc zzz
argv prior to call of plparseopts(..., PL_PARSE_SKIP)
i = 0, argument = examples/c/x01c
i = 1, argument = -pl_parse_skip
i = 2, argument = xxx
i = 3, argument = -dev
i = 4, argument = psc
i = 5, argument = yyy
i = 6, argument = -o
i = 7, argument = test1.psc
i = 8, argument = zzz
argv after call to plparseopts(..., PL_PARSE_SKIP)
i = 0, argument = examples/c/x01c
i = 1, argument = xxx
i = 2, argument = yyy
i = 3, argument = zzz
PLplot library version: 5.13.0
M examples/c/x01c.c
commit ef2bf58848be56992f47bb83fbf7ce662d3e612b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 23 12:02:13 2017 -0800
Style previous commit
M bindings/d/plplot.d
commit 8aeee637ed0f0d766ca00e1cb25cee4dcb8650b0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 18 13:13:57 2017 -0800
Build system: fix sanity check logic for set_library_properties function
if(NOT(${library}_SOVERSION OR ${library}_VERSION OR LIB_DIR))
==>
if(NOT(DEFINED ${library}_SOVERSION AND DEFINED ${library}_VERSION AND DEFINED LIB_DIR))
As is obvious above the prior version of the logic that has now been fixed
was completely bogus (i.e, used OR rather than the correct AND, and used true/false (which
failed when ${library}_SOVERSION was 0) rather than doing the correct check that the
variable had been DEFINED).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by configuring PLplot with cmake. The result was
there were no CMake errors due to the above revision in the sanity
checking logic.
M cmake/modules/plplot_functions.cmake
commit 5c628406e9a1c941dbe34d3db056f985e1ec8b08
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Dec 13 11:06:34 2017 -0800
Build system: Drop the gcc -mieee-fp option on i*86 hardware for the Nan awareness compiler test
Orion Poplawski discovered for i686 hardware and the latest gcc and
glibc that (a) the gcc -mieee-fp option no longer compiles (apparently
because glibc is dropping libieee.a) and (b) the gcc -mieee-fp option
is no longer needed for the C NaN awareness test, i.e., when double x
= NaN; then x != x is true. Therefore, in this commit I have dropped
the -mieee-fp option for the combination of i*86 hardware and gcc.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by configuring PLplot as usual with cmake to confirm
that the change introduces no CMake logic errors (and that no special gcc option
continues to work for testing C compiler NaN awareness on x86_64 hardware).
when double x=NaN, then x != x.
M cmake/modules/csiro.cmake
commit a7be76715300e829523be309c64d99b1b28c1bcc
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 11 01:43:54 2017 -0800
OCaml examples: fix standard example 33 to solve its inconsistencies with other languages
The issue with examples/ocaml/x33.ml was simply that all pages demonstrating
plcolobar results (page 5 and beyond) had not been implemented yet, and
this commit fixes that issue.
N.B. This resolves the last of the long-standing ocaml PostScript
differences, and as a result we have gotten a clean PostScript difference
report for the first time since 2010!
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running the test_diff_psc target. The result was
perfect PostScript differences (for all our standard examples
including the Ocaml ones), e.g.,
ocaml
Missing examples :
Differing graphical output :
Missing stdout :
Differing stdout :
and similarly for all the computer languages we support.
I also ran
valgrind examples/ocaml/x33ocaml -dev psc -o test.psc
and the resulting report showed memory leaks (as do all other
OCaml examples) but "0 errors from 0 contexts".
M README.release
M examples/ocaml/x33.ml
commit b16d96713747fe027e7b08452c7716aa50fb0fc1
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 11 00:40:10 2017 -0800
Styled previous commit
M examples/c/x33c.c
commit aa40de75266ae9fc1e24a5be10094b55b867c1a3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 11 00:36:18 2017 -0800
Core library and bindings: define PL_POSITION_NULL, PL_LEGEND_NULL, and PL_COLORBAR_NULL
These option bits are all defined to be zero (0x in some languages, 0
in others) to provide a way to specify no option bits for option
arguments to pllegend and plcolorbar. This allows users the
(preferred) style choice of always using named option bits rather than
numerical constants such as 0x or 0. Furthermore, for certain
languages (e.g., OCaml at least) the option bits are stored as part of
an enum so until this change it was impossible to use an option bit of
zero for any position, legend, or colorbar option.
I propagated this update of #defined constants in plplot.h to the bindings by
configuring PLplot with -DADD_SPECIAL_CONSISTENCY_CHECKING=ON and by
using the following methods (which should be used every time there is
such a #defined update of constants):
* Run the check_plplotcapi_defines target and copy the generated file
back to the appropriate part of bindings/swig-support/plplotcapi.i
* Run the check_fortran_parameters target and copy the generated file
back to bindings/fortran/included_plplot_parameters.f90
* Run the check_fortran_parameters target and copy the generated file
back to bindings/fortran/included_plplot_parameters.f90
* Run the check_tcl_parameters target and copy the generated file
back to bindings/tcl/plplot_parameters.h
* Used the sed command and remaining instructions documented in
bindings/python/Plframe.py to update the constants in that file
consistently with bindings/swig-support/plplotcapi.i
* Used the sed command and remaining instructions documented in
bindings/d/plplot.d to update the constants in that file
consistently with bindings/swig-support/plplotcapi.i
Note I took this opportunity to collect all the previously
hand-crafted constants in one place in plplot.d and work out the sed
command (that is documented in the file) to generate those constants
automatically.
* Appropriate hand-crafted changes to bindings/ocaml files.
After those, run the check_plplot_h.inc target and copy
the generated file back to bindings/ocaml/plplot_h.inc if
different.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by configuring PLplot using the CMake option
-DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the
check_all, test_noninteractive, and test_interactive targets
with no obvious configure, build, or run-time errors and
no PostScript difference regressions.
M bindings/d/plplot.d
M bindings/fortran/included_plplot_parameters.f90
M bindings/ocaml/plplot.mli
M bindings/ocaml/plplot_core.idl
M bindings/ocaml/plplot_h
M bindings/ocaml/plplot_impl.c
M bindings/python/Plframe.py
M bindings/swig-support/plplotcapi.i
M bindings/tcl/plplot_parameters.h
M include/plplot.h
commit ab6649299ba1802f992a92afe4b907d3b703c433
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 10 16:16:11 2017 -0800
Documentation: Update swig documentation to be consistent with recent DocBook documentation update
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by configuring PLplot with
-DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the
check_swig_documentation target without issues.
M bindings/swig-support/swig_documentation.i
commit 244a526f97bd5d02719394a9121f63e43ec0650c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 9 12:37:38 2017 -0800
C examples: change -colorbar option to -nocolorbar option for example 33
M examples/c/x33c.c
commit 35eafc15523b75616ec37fcb5cacd2b8fcfe470f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 9 11:01:45 2017 -0800
OCaml examples: Fix inconsistencies with other languages for standard example 16
The cause of this long-standing inconsistency was the use of the
high-level OCaml colorbar API for all the color bars in this example.
That API is fundamentally inconsistent with the OCaml plcolorbar API
because colorbar sets a default color before calling plcolorbar and
then restores the original color after that call. And those extra
color settings were causing inconsistencies with the results for
standard example 16 for other languages. This commit replaced all
calls to colorbar by calls to plcolorbar, and that change completely
solved the inconsistency.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_diff_psc target. The resulting
error report for ocaml has all the long-standing example 16
differences removed as a result of this commit, i.e.,
ocaml
Missing examples :
Differing graphical output : 33
Missing stdout :
Differing stdout :
(Those remaining 33 differences are long-standing as well and are
caused by that OCaml example being partially implemented, i.e., all
the color bar parts of that OCaml example are missing.
However, now that the example 16 color bar discrepancies have finally
been solved, that future fix should be straightforward.)
I also ran
valgrind examples/ocaml/x16ocaml -dev psc -o test.psc
and the resulting report showed memory leaks (as do all other
OCaml examples) but "0 errors from 0 contexts".
M bindings/ocaml/plplot_h
M examples/ocaml/x16.ml
commit e4105d1d1063292c8f33f34cdcc734137f2a59ed
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 9 10:32:27 2017 -0800
Ocaml binding: change indentation and tweak wording of binding description
M bindings/ocaml/README
commit 601650e3bc4c2cedd9c786dcb6536e7012b3d8a9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Dec 8 19:01:04 2017 -0800
DocBook documentation: Update pllegend documentation
I just noticed the previous nrow and ncolumn argument documentation was
completely wrong (obviously copied from another argument entry
as a "temporary" place holder), nlegend documentation was
outdated, etc. These issues were all fixed by copying
wording from the corresponding doxygen documentation of pllegend.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by configuring PLplot with the -DBUILD_DOC=ON
cmake parameter, building the html version of the documentation
using "make html", and viewing that with a browser.
M doc/docbook/src/api.xml
commit 0da2c1403fd3a67474065207e3847e7b4f2826f7
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Dec 1 15:03:39 2017 -0800
Add remove_trailing_whitespace.sh to the files that are excluded by that script from being processed by that script
The reason why remove_trailing_whitespace.sh should not act on itself
is that changes to shell (bash) scripts done while they are executing
can potentially mess up their results.
M scripts/remove_trailing_whitespace.sh
commit 2435390c773fb86584d3b5e761685e3afd3bce3e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Dec 1 14:17:51 2017 -0800
Website: Update colour scheme
The css colour scheme for the PLplot website was developed a bit
further for the timeephem project to make the dark text colour
absolutely black for best visibility.
Adopt this colour change also for the PLplot website.
M www/css/CMakeLists.txt
M www/css/style.css.in
commit d93676de7a9b1481fb463234e93781a32900f8da
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Oct 31 23:28:48 2017 -0700
OCaml bindings and examples: add and use plmap* API
The added OCaml API is for plmapline, plmapstring, plmaptex, and
plmapfill. I added an "Exmoor" page to the 19th standard OCaml
example using this new API to make results from that example
consistent with the corresponding C example.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_diff_psc target. The resulting
error report for ocaml has all the long-standing example 19
differences removed as a result of this commit, i.e.,
ocaml
Missing examples :
Differing graphical output : 16 33
Missing stdout :
Differing stdout :
(Those example 16 and 33 differences are long-standing as well.)
I also ran
valgrind examples/ocaml/x19ocaml -dev psc -o test.psc
and the resulting report showed memory leaks (as do all other
OCaml examples) but "0 errors from 0 contexts".
M bindings/ocaml/CMakeLists.txt
M bindings/ocaml/README
M bindings/ocaml/plplot.mli
M bindings/ocaml/plplot_core.idl
M bindings/ocaml/plplot_impl.c
M examples/ocaml/x19.ml
commit 76697707c81d7c094a57ab6737d7cf98c0bd5d55
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Oct 31 15:17:17 2017 -0700
OCaml binding: remove gratuitous inconsistencies between plplot_h and plplot.h
I recreated plplot_h from the common API declarations in plplot.h with
argument types #defined appropriately and using #if 0....#endif
preprocessor commands to ignore the parts of the common API (e.g., API
with callback arguments) that cannot be processed with touchup.ml.
These changes minimize the differences between plplot_h declarations
and those in plplot.h, and the results typically have different
argument types and argument names and some reordering of the API
compared to the previous results. The touchup.ml file had to be
changed to be consistent with the a -> alpha argument name change for
some of the color map functions. The results of touchup.ml were
generated using the cmake option -DADD_SPECIAL_CONSISTENCY_CHECKING=ON,
building the check_plplot_h.inc target, and copying back
bindings/ocaml/generated_plplot_h.inc in the build tree
to bindings/ocaml/plplot_h.inc in the source tree. The resulting
plplot_h.inc differences consist solely of argument name changes, one void
argument rather than an empty argument, and some reordering of the API.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by configuring PLplot with the cmake option
-DADD_SPECIAL_CONSISTENCY_CHECKING=ON and building the
check_plplot_h.inc target without issues and building the
test_diff_psc target without obvious configure, build, or run-time
issues or PostScript difference regressions.
M bindings/ocaml/plplot_h
M bindings/ocaml/plplot_h.inc
M bindings/ocaml/touchup.ml
commit 14d838fc3587cbfe260cccf4106707dd837dfb29
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Oct 31 15:10:33 2017 -0700
Core plplot code: improve alphabetization of common API
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by configuring PLplot with the cmake option
-DADD_SPECIAL_CONSISTENCY_CHECKING=ON, and building both the check_all
and test_diff_psc targets. The consistency checks run by check_all passed
without issues, and there were no configure, build, or obvious run-time
issues with the test_diff_psc target and no PostScript difference
regressions.
M include/plplot.h
commit 4e338285ee632e4909de969168ff6d8044748b99
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Oct 31 14:41:56 2017 -0700
Documentation: make API documentation for swig-generated bindings consistent with DocBook API documentation
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the check_swig_documentation target.
M bindings/swig-support/swig_documentation.i
commit 69067983c65013058cfbe4cf047f0817f1933d37
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Oct 12 19:25:07 2017 -0700
Drop example 17 from -dev wxwidgets tests
This was done in the interest of testing convenience because this
example takes a considerable length of time to complete for -dev
wxwidgets, and this change follows what we have already done for the
same reason for -dev qtwidget and -dev xcairo (which are quite slow
for this particular example, but still faster than -dev wxwidgets).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie). Note this test was way over the top for this simple
change, but I took this opportunity to do complete testing because it
was time to do this in any case as a test of previous commits, and
also it gave me the opportunity to test a version of CMake that I
built myself from the CMake 3.10.0-rc2 source code using the bootstrap
method. This test was performed by running (from a source tree with a
space in the prefix)
time (nice -19 scripts/comprehensive_test.sh --prefix "../comprehensive_test_disposeable blank" --cmake_command ~/cmake/install-3.10.0-rc2/bin/cmake --do_submit_dashboard yes)
(Note because of the choice of a "spaced" source tree and the above
--prefix, this test has a space in the prefixes of the source, build,
and install trees.)
Check the results:
# Check for any regressions in the warnings in the cmake output.
less ../comprehensive_test_disposeable\ blank/shared/noninteractive/output_tree/cmake.out
# Check for some non-standard warnings:
grep -i warning ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout'
# Check for all errors:
grep -i error ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out
# Check for any ldd issues for the shared and nondynamic cases.
grep -iE 'found|symbol|undefined' ../comprehensive_test_disposeable\ blank/*/*/output_tree/*ldd.out
# Check for any PostScript or Text differences between all non-C languages and the corresponding
# C results.
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable\ blank/*/*/output_tree/*.out |less
These checks showed no configure, build, or run-time issues.
Furthermore, the last check showed there were no PostScript difference
regressions (i.e., the only PostScript difference issues revealed by
that check were the long-standing ones for OCaml). In addition, 3
dashboards (for the shared, nondynamic, and static cases) were
correctly posted to <http://my.cdash.org/index.php?project=PLplot_git>
although with long-standing spurious warning counts for the cmake step
which I have been unable to figure out, yet.
M plplot_test/test_c_interactive.sh.in
commit 14ecc4bd943caa40a830e0da066ff7a220b9d5e8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Oct 10 19:07:02 2017 -0700
C and C++ source code: replace all use of the WIN32 and __WIN32__ macros with the _WIN32 macro
This change fixes bug 189 <https://sourceforge.net/p/plplot/bugs/189/>
(which essentially found a Windows compiler that did not set WIN32 but
which did set _WIN32). This change is also consistent with a recent
list recommendation from Jim Dishaw, and also the (dated) "Windows,
Cygwin (non-POSIX), and MinGW" section of
<https://web.archive.org/web/20140625123925/http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system>.
This fairly intrusive change was done mostly using sed commands for
convenience, but because of the possibility of screwing up such
commands, this change was reviewed to make sure it did not change too
much be reviewing "git diff" results in detail. It was also reviewed to make
sure it changed enough by checking our entire source code tree for all
instances of WIN32 that had not been converted to _WIN32 to insure all
such remaining instances were legitimate ones. Our entire source tree
was also checked for remaining occurrences of __WIN32__, and there are
none.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the "all" and "test_noninteractive"
targets. There were no warning regressions; no obvious configuration,
build, or run-time errors; and no PostScript difference regressions.
The above tests are just due diligence that none of these Windows-related
changes affect Linux results, and fundamental testing of these changes
still needs to be done on all the many different Windows platforms we support.
M README.release
M bindings/tcl/tclAPI.c
M bindings/tk-x-plat/plplotter.c
M bindings/tk/plframe.c
M bindings/tk/pltkd.h
M bindings/tk/tcpip.c
M bindings/tk/tkMain.c
M cmake/epa_build/libharu/cmake.patch
M cmake/epa_build/libqhull/src/libqhull.h
M drivers/deprecated_wxwidgets_agg.cpp
M drivers/pdf.c
M drivers/tkwin.c
M drivers/wxwidgets_comms.cpp
M drivers/wxwidgets_comms.h
M drivers/wxwidgets_dev.cpp
M examples/c/x22c.c
M include/pldll.h.in
M lib/csa/csadll.h
M lib/csa/nan.h
M lib/nistcd/cddll.h
M lib/nn/nan.h
M lib/nn/nndll.h
M lib/qsastime/qsastimedll.h
M src/plctrl.c
M src/plfreetype.c
M src/plstdio.c
commit e0d5fdf5df1b619b3f3b3dfe5c082b6fe488e340
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Oct 10 17:59:33 2017 -0700
Fix recently introduced PostScript difference regressions for example 19
These regressions were recently introduced by the plmapfill-> plmapline
changes to the C and C++ versions of example 19, and were fixed by
propagating these changes to all our supported computer languages
other than OCaml (which already has long-standing propagation issues for example 19).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_diff_psc target. As a result
the only non-empty PostScript difference summary was
ocaml
Missing examples :
Differing graphical output : 16 19 33
Missing stdout :
Differing stdout :
These differences are long-standing ones, i.e., we are back to a situation
where there are no PostScript difference regressions (compared to
e.g., plplot-5.13.0).
M examples/ada/xstandard19a.adb
M examples/ada/xtraditional19a.adb
M examples/d/x19d.d
M examples/fortran/x19f.f90
M examples/java/x19.java
M examples/lua/x19.lua
M examples/octave/x19c.m
M examples/python/x19.py
M examples/tcl/x19.tcl
commit 3fe27f0ecadb14d94a1d5ed9125b35ec82ef67d3
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Fri Oct 6 23:04:36 2017 +0100
WxWidget bug fix for wxWidgets during initialisation
The wxPLViewer uses the size of the previously rendered bitmap to test
whether or not it needs to rerender on a resize event. However it can
receive a resize event before initialising te bitmap and on some
platforms that causes a crash/assert fail/exception. Added a check for
bitmap initialisation before getting the size of the bitmap.
M bindings/wxwidgets/wxPLplotwindow.h
commit 3379c4eaa7c4cdebfcc3238bbfe023fb3732e0f9
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Fri Oct 6 00:15:31 2017 +0100
Fixed compile bug in wxPLViewer for gcc
GCC is clearly a bit stricter or less clever (depending upon your
perspective I guess) than Visual Studio on the format of
calling methods of templated classes. Updated the code to fix the
compile error given by GCC.
M bindings/wxwidgets/wxPLplotwindow.h
commit 476ce7392ad45624b41cd761bf1ebd51204fb957
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Oct 5 12:31:32 2017 -0700
Build systems: output additional information
The added information is the following:
* Full pathname of the cmake executable
* Name of generator
* CMAKE_INCLUDE_PATH (both cache variable and environment variable forms)
* CMAKE_LIBRARY_PATH (both cache variable and environment variable forms)
* CMAKE_PLATFORM_INFO_DIR (the location where configured language support files live)
I have consistently added this output both for the core build system
as well as the CMake-based version of the installed examples build system.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running cmake in the build tree and observing the
output. The install-tree version has not been tested this way, but
the identical CMake logic has been copied in that case so it should be
fine.
M CMakeLists.txt
M examples/CMakeLists.txt
commit cd8f69d7abe4bc304cfac595fd67af097783dcb1
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Oct 4 23:37:31 2017 +0100
Removed a few lines of code used for debugging that should never have
been commited.
M utils/wxplframe.cpp
commit bb938c8baf3c19b1bff94cc27c073ee9c8bd62bb
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Oct 4 23:36:45 2017 +0100
Style only commit
M utils/wxplframe.cpp
commit 20069523d621dd6f3a37a6a5b18d344a8ac52c75
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Oct 4 23:32:33 2017 +0100
Fixed recently introduced error that stopped wxPLViewer realizing
plotting was complete
A recent change accidentally adjusted the logic for a set of if/else
statements, meaning that the timer that checks for new data got
restarted. The result was a hang with IPC3 comms while the blocking
getData function waited for data that never arrived. For non-IPC3 comms
the repeated checks had no specific bad effects other than wasted cpu
cycles I guess.
M utils/wxplframe.cpp
commit e4fb932fe67ac431e3ae3205289f58ff1b074a64
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Oct 4 23:24:30 2017 +0100
Set the option of a render delay after resizes on wxPLplotwindows
When rendering complex plot resizes can become jerky, unresposive and in
some cases impossible because the window is continually trying to
rerender the plot.
Now set this up so that a delay to the render can be set and after
resize the render only happens once the size has remained constant for
that delay time. For wxPLviewer that delay time has been set to 1000 ms
(1 s). This fixes bug #170 https://sourceforge.net/p/plplot/bugs/170/.
M bindings/wxwidgets/wxPLplotwindow.h
M utils/wxplframe.cpp
commit ff29053fe279e0424cc94c5f4d31a9291d8362a4
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Oct 4 11:30:18 2017 +0100
Attempted workaround for wxPLViewer IPC3 hangs
When pllocate is called the core code then requests data from
wxPLViewer in a blocking manner. Meanwhile wxPLViewer received the
locate instruction, but carried on requesting further plot commands from
the core code in a blocking manner while waiting for the user to click
the mouse. This caused deadlock.
Modified the wxPLViewer code so that it no longer requests data from the
core code while waiting for locate data.
This sortof works and sometimes allows execution beyond the use of
locate in example 20, but then we seem to hit deadlock later. Not sure
why.
M utils/wxplframe.cpp
commit f5974813621b88f7d9e912dc86dde0809b390803
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Oct 3 22:12:09 2017 +0100
Towards correct locate state variable assignment in wxPLViewer
I found that the locate state variable should represent the mouse
buttons that were down immediately before the mouse event in question.
I.e any other buttons held down at the same time or if the event in
question was a release, then the button that was released.
In theory the logic now in wxPLViewer is correct, but the frame is not
capturing button release events so these events are not generating any
locate information. This may require use of a wxPanel which I have been
meanuing to do anyway as it is best practice. This commit is still an
improvement on the incorrect locate information that was being provided
though so I thought it was worth commiting now.
M utils/wxplframe.cpp
commit 5232aaca74724e69e5ad61c12de63d31b44c0151
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Oct 3 15:15:01 2017 +0100
Added support for xor rendering and fixed a locate bug in wxWidgets.
Example 20 didn't do the locate part because wxWidgets driver did not
support xor mode. added a flag to say this is supported, but actually
support isn't really there fully. Support is there when a wxDC is passed
into the driver, however when using the wxPLViewer there is an issue -
when xor mode is set the draw commands are no longer saved to the buffer,
so they never get passed to the viewer. Changing this behaviour will be
discussed on the email list.
A locate bug was then shown up by this example. When locate occurred on
a page other than the first, the PLViewer may have still been on an
earlier page. We now record the page on which the locate occurred and do
not action it until the user has moved to that page.
The three sem comms suffers from a further locate bug which needs
further work and is caused by both the core and the viewer code
getting stuck sitting and waiting for the other to transmit data. But
this commit means that the older comms method deals with locates
absolutely correctly.
M drivers/wxwidgets.cpp
M drivers/wxwidgets.h
M drivers/wxwidgets_dev.cpp
M utils/wxplframe.cpp
M utils/wxplframe.h
commit 124a0c3a2745fe6e3060bc61a6ef817e0e41e013
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Oct 2 15:32:16 2017 +0100
Set all clip limit changes I could find to use plP_sclp and hence get
recorded in the buffer
Clip limits need to be recorded in the buffer in order to be correctly
set during a replot. An example of this problem was x33 where legends
would not get rendered properly as seen by the wxPLViewer and reported
as bug #176 https://sourceforge.net/p/plplot/bugs/176/.
I've searched the code for raw assignments of the clip limits and
replaced them all with plP_sclp calls in order to make sure that they
are recorded in the buffer. I guess the joy of C (vs C++ whee these
variables could have been hidden) is that there is nothing stopping
people adding new raw assignments.
One raw assignment that I left was in plmetafile.c. I couldn't work out
why a driver would be modifying the clip limits, so I just left them
alone. I will email Jim Dishaw and ask his advice.
Tested by running x33c with the wcPLViewer to check all legends are
correctly rendered.
M src/plcore.c
M src/plvpor.c
commit 0f71a774d13a1ab67887c291646e0a83360b3fcd
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Oct 2 14:47:54 2017 +0100
Added clipping to the wxWidgets FillPolygon function
M drivers/wxwidgets_dev.cpp
commit 5b336deacd9de4a16471f1f4a98d12c75d2e5090
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Oct 2 00:08:50 2017 +0100
Fixed crashes associated with -eofill
The test to make sure that the PLStream was ready to accept a plP_state
call was incorrect. It was testing plsc->initialized !=0, when it should
have been checking plsc->level > 0.
M src/plargs.c
commit 81fafd26e60d3ff4483f4d5bf4c8a666ee758f52
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Sun Oct 1 23:57:22 2017 +0100
Fixed failure to flush with wxViewer
This was simply a loop that required exiting to allow rendering when a
flush command was received.
This fixes bug #169 https://sourceforge.net/p/plplot/bugs/169/
Tested by running example 17
M utils/wxplframe.cpp
commit 90692d8fdcfe801a5d4439caa915c4df976e56bb
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Sun Oct 1 23:24:00 2017 +0100
Fixed background clear for wxWidgets driver
The unit conversion for getting the region to clear was missing in
wxPLDevice::ClearBackground. This has been added.
This fixes bug #171 https://sourceforge.net/p/plplot/bugs/171/
Tested by ammending x21 so that each subplot has a different colout
background on page 2.
M drivers/wxwidgets_dev.cpp
commit 315481fa073820302e9c4fb4ffed3c78c60800b3
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Sun Oct 1 12:51:46 2017 +0100
Fixed plreplot and wxPLViewer bugs regarding begining of pages
This addressed the bug report at
https://sourceforge.net/p/plplot/bugs/168/
There were two issues to address. The first was that if plreplot is
called but the PLStream happens to be at the beginning of the page then
the new beginning of page (which generally involves clearing the
background to the bgcolour set from the buffer) was ignored. Now the
status is set to end of page before the buffer read begins.
The second issue was that during initialisation wxPLViewer added a
beginning of page event to the buffer. It then received the buffer to
plot, which included a second beginning of page even and appended this
to the existing buffer. This gave two consecutive beginning of page
entries in the buffer and the second one (which is the one we actually
want) was ignored. This was fixed by checking if the data
received was the first data, and if so then overwrite rather than append
to the buffer.
Tested by running x16 and checking we get correct background colours for
all plots.
M include/plplotP.h
M src/plbuf.c
M src/plcore.c
M utils/wxplframe.cpp
commit b603fd228b29d75f0f3fd2b4b6518e3cf806afe3
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Sun Oct 1 00:38:58 2017 +0100
Fixed wxWidgets even odd winding bug when using viewer
This was really a buffer bug or at least the modifications here fix a
buffer bug.
Basically the dev_eofill variable was not being recorded in the buffer
anywhere so it was never passed to the viewer. It is now recorded as
part of the the state at beginning of page and plP_state is now called
if opt_eofill is called after initialization which causes the state
change to be recorded. A new state #define has been added to facilitate
this.
Tested by Phil Rosenberg by running example 27 with and without the
-eofill command argument, however, only up to the point of checking in a
debugger that wxPLViewer receives the value and calls the fill function
with the correct fill option. I'm not actually sure what the difference
in output should be - both looked the same to me, but maybe I'm missing
something subtle.
M include/plplotP.h
M src/plargs.c
M src/plbuf.c
commit e60fba878d5429592d9c084e18b29f834099189e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Sep 29 12:26:48 2017 -0700
Fix style and trailing blank issues in a recent commit
M doc/docbook/src/api.xml
M src/plmap.c
commit e3c595819cf8f7596d09be6d4ac0c2beb7e642c3
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Fri Sep 29 12:32:04 2017 +0100
Fixed error in map example 19
The rivers were accidentally plotted with plmapfill not plmapline. This
was masked by the fact that before recent fixes the shapefile's render
type was always used.
M examples/c++/x19.cc
M examples/c/x19c.c
commit 6fbdc3353d7031278cd803792c226a1d8adf0ae6
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Fri Sep 29 11:49:57 2017 +0100
Fix plmapline
plmapline is supposed to override the render type of drawmap, passing in
SHPT_ARC as the type to draw, but SHPT_NULL was passed instead causing
the type to be derived from the file.
Bug spotted and patch sent by Mark de Wever. Thanks for the
contribution.
M src/plmap.c
commit 124674358b7ffe41057d956351e298ddd12a82a9
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Fri Sep 29 11:01:21 2017 +0200
Add scripts and lists of required/recommended packages for Cygwin (64bits) and MinGW/-w64/MSYS2
These scripts are examples of how to run CMake/make and the comprehensive tests
for these two platforms. While they have been derived from scripts I have been
using for a long time now, I have not tested these cleaned versions thoroughly
yet. There may still be some quirks left in or inadvertently left out. The
clean-up itself will be useful for me too - lots of stuff had accumulated over
time not making it easy to determine what is really needed.
Tested but not thoroughly by Arjen Markus (arjen.markus@users.sourceforge.net)
A scripts/cygwin/interactive_launch_comprehensive_test.sh
A scripts/cygwin/noninteractive_launch_comprehensive_test.sh
A scripts/cygwin/package_list.txt
A scripts/cygwin/run_cmake.sh
A scripts/msys2/interactive_launch_comprehensive_test.sh
A scripts/msys2/noninteractive_launch_comprehensive_test.sh
A scripts/msys2/package_list.txt
A scripts/msys2/run_cmake.sh
commit a4d9897f24ef150f8f037d09ff1cac80cd67ce63
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Sep 28 21:19:55 2017 +0100
Fixed the overrides for render type for the maps.
The render type passed into drawmap() are now respected. Passing
in a SHPT_NULL type causes the type from the file to be used.
M doc/docbook/src/api.xml
M src/plmap.c
commit aadbb28ec27a725eb8475dc67fcf28a23ec7d50a
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Sep 28 20:51:59 2017 +0100
Restyle only commit
M include/plplot.h
M src/plmap.c
commit 57e50d8bfdc4c3e687ec8347de1257cb257ed967
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Sep 28 20:41:43 2017 +0100
Edited plmap documentation
This now reflects the changes made in the previous two commits and the
fact that shapelib is required for maps.
M doc/docbook/src/api.xml
commit 0b7dc2d42f29eed1780c01d1814ee5ddd9901dd8
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Sep 28 20:01:49 2017 +0100
Cleared out some unused functions from plmap.c
M src/plmap.c
commit 7e7acff15a6eb8aff3b13d94740622b571f0ad77
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Sep 28 19:50:41 2017 +0100
Fixed PLFLT issue in plmap and issue with polygons wrapping the globe
There was a problem with array types if PLFLT was not a double. this got
introduced because shapelib always deals in doubles and in the last
commit the conversion got removed. It has been added back in a more
useful place.
Also dealt with plmap rendering of polygons that wrap the whole globe,
e.g. Antarctica. We should also effectively deal with the case where
such a polgon gets turned inside out, like when doing a polor plot with
the north pole in the centre.
M src/plmap.c
commit 47222ff73c8410dc717ed4886e2ea88e06f5649e
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Sep 28 18:21:37 2017 +0100
Massively simplified the map code to fix a rendering bug and added
PLFLT_HUGE_VAL to plplot.h
A rendering bug was reported - see email to the list to the plplot-devel
list entitled Plmap omits lines at the left hand side of the map dated
18th Nov 2016. The bug was as described, lines on a lat/lon map that
touched the left edge of the plot dissapeared.
I have removed the code that tried to be clever and wrap cut sections
of lines that weren't supposed to be plotted and attempted to wrap them
round the globe if needed. Instead I now draw objects multiple times if
needed to cover the wraparound. Note we also now support doing a plot
which loops round the globe multiple times, so for example you could do
lon -180 to +540 and you would get two full renderings of the globe.
I added PLFLT_HUGE_VAL as I wanted to ensure that if someone threw one
of the floating point limiting values in as the limit for the map plot
then I wouldn't get stuck in a near infinite loop.
M include/plplot.h
M src/plmap.c
commit 0f3dcb2acf1df511a9a4299079234853043458c3
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Sep 28 15:29:51 2017 +0100
Comments and minor tidy in plmap.c
Just added and edited some comments. Also removed reading the max/min
values from the shapefile as we don't use these values anywhere.
M src/plmap.c
commit a52aa2ff0dd371bc86784c58a4b1538eaa4ac2c6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Sep 25 12:52:54 2017 -0700
Update our source tree from plplot.sourceforge.net (or plplot.sf.net) to plplot.org
As a result of this change the command
find . -type f |grep -v .git |xargs grep -El 'plplot.sf.net|plplot.sourceforge.net'
yields only the following list of historical files
./rpm/plplot_mandrake9.2.spec
./rpm/plplot_redhat7.3.spec
./rpm/plplot_mandrake8.1.spec
./rpm/plplot_mandrake8.0.spec
./rpm/plplot_redhat6.2.spec
./rpm/plplot_redhat7.2.spec
./rpm/plplot_redhat7.1.spec
./README.release
./README.cumulated_release
./www/announce/announce-plplot-5.2.1.html
./www/announce/announce-plplot-5.1.0.html
./www/announce/announce-plplot-5.3.0.xml
./www/announce/announce-plplot-5.3.1.xml
./www/announce/ChangeLog-5.3.0-5.3.1
Tested by: Alan W. Irwin <airwin@users.soureforge.net> on Linux
by running
echo irwin$'\n'irwin$'\n'raven$'\n'/home/irwin/public_html/plplot$'\n'yes |scripts/generate_website.sh
and confirming there are no warning regressions or errors using
find /tmp/plplotdoc -name '*.out' |xargs grep -i warning |less
find /tmp/plplotdoc -name '*.out' |xargs grep -i error |grep -vE 'unable to read file loc from'
(That grep -vE stanza is to remove output lines from doxygen that tend to
include some case variants of "error" in the string because the
referred to function name contains that substring.)
I also very superficially checked the locally generated website to, e.g.,
confirm the internal references are to plplot.org and not plplot.sf.net.
However, that check also showed obsolete/deprecated functions had been changed due to
all the recent cruft removal. So because of these post-5.13.0
cruft-removal changes, I have decided not to upload the locally generated website
to SourceForge so that site will still contain internal references to
plplot.sf.net and plplot.sourceforge.net until the next release
when the regenerated website will automatically be uploaded
as part of the usual release process.
N.B. www/README.domain still needs to be created to explain in detail what we
need to do in the future to maintain plplot.org and www.plplot.org.
M NEWS
M README
M README.Release_Manager_Cookbook
M README.release
M bindings/ocaml/README
M bindings/tk/about.tcl
M cmake/modules/docbook.cmake
M doc/docbook/README.developers
M doc/docbook/src/intro.xml
M doc/pstex2eps.1
M drivers/README.wxwidgets
M www/announce/CMakeLists.txt
commit c275d59fe6059899fbf49587a20db9ce57e6235c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Sep 10 17:39:08 2017 -0700
Substantially update the history of our DocBook documentation project
M doc/docbook/README
commit f997464d2e173137e3cb33d3d99f03a7bfdaa428
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Sep 25 11:45:07 2017 -0700
Fix @param Doxygen bug
M src/plmem.c
commit 53b33bdd81580e8a09aa1ae9c7dc8752d0c4b4e6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Sep 21 08:43:58 2017 -0700
Official deprecation of C++ cruft
Thirteen C++ methods (see README.release for the full list) have been
unoffically deprecated (via comments in the code and lack of use in
our C++ examples) for a long time. One of these is the unofficially
deprecated (AND incorrect) historical name "col" for the col1 method,
and the rest are unofficially deprecated versions of methods which use
PLINT instead of bool for logical arguments.
With this commit, these unofficially deprecated methods have now been
officially deprecated, i.e., they will only be accessible if a user
sets -DPL_DEPRECATED=ON.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie). The following tests were all done in the build tree for
the shared libraries case:
* Built the "all" target for -DPL_DEPRECATED=ON
* Built the "all" target for -DPL_DEPRECATED=OFF
* Built the "test_noninteractive" target for -DPL_DEPRECATED=OFF
* Built the "test_interactive" target for -DPL_DEPRECATED=OFF
In all cases there were no configure-, build-, or run-time errors and
no warning regressions. For the "test_noninteractive" case, there
were no PostScript difference regressions.
M README.release
M bindings/c++/plstream.cc
M bindings/c++/plstream.h
commit 6ce0494ec5542cb4f8fd89e22c7ce9ead8332d2a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 20 21:53:14 2017 -0700
Remove trailing whitespace from recent commit
M doc/docbook/src/api-c.xml
commit 079cbf1f283cf82fc62eaf936423d65614fe584a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 20 11:08:52 2017 -0700
C and C++ API: Implement plStatic2dGrid and deprecate plshade1
The 2D matrix arguments of plshade, plshades, plcont, plimage, plvect,
etc., for our C API and corresponding C++ API must currently be
organized as Iliffe column vectors (see
<https://en.wikipedia.org/wiki/Iliffe_vector>) containing pointers to
PLFLT row vectors. And these matrices are normally in the C case
dynamically allocated with plAlloc2dGrid and freed with plFree2dGrid,
and in the C++ case the same thing is done with C++ wrappers for
plAlloc2dGrid and plFree2dGrid. However, that dynamically allocated
approach has not allowed our C and C++ users to call plshade, etc.,
with statically allocated 2D data.
Historically we have partially addressed that issue by implementing a
plshade1 variant of plshade that could be called with a statically
allocated 2D matrix. Expanding that approach with plshades1, plcont1,
etc., variants is possible, but does considerably clutter our C and
C++ API. So instead for this release we have implemented the
plStatic2dGrid C function and associated C++ wrapper which allows C
and C++ users to determine the Iliffe column vector corresponding to a
2D statically allocated array. The standard C and C++ examples
(specifically examples/c/x15c.c and examples/c++/x15.cc) demonstrate
how to use this new approach to call plshade using 2D data that have
been statically allocated, and although none of our examples
illustrate these additional possibilities, this same approach could
also be used to call plshades, etc., with 2D data that have been
statically allocated.
I have added DocBook documentation of plStatic2dGrid and also
significantly updated our DocBook documentation of the 2D matrix
API for C consistent with this new C (and C++) functionality.
Since this new approach completely supersedes plshade1, we have
officially deprecated that function and its C++ wrapper. (Note this
is a backwards-incompatible change to our C and C++ API's. Such
official deprecation means that plshade1 and its C++ wrapper are only
available to users if they specify the -DPL_DEPRECATED=ON cmake
option. And our DocBook documentation for plshade1 has been moved to
the obsolete/deprecated section of that documention. This deprecation
means that all other references to plshade1 (except for historical
data such as change logs and release notes) to plshade1 have been
eliminated from our source tree with this commit. In particular,
plshade1 had (in error) been previously propagated to the Ada
traditional binding as plshade1 and Ada standard binding as
Shade_Region_1, and used in the Ada standard and traditional examples
so plshade1 and Shade_Region_1 have been dropped from the Ada bindings
(note, this is a backwards-incompatible change for those bindings) and
replaced in the Ada examples with the corresponding calls to plshade
and Shade_Region.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie). These tests consisted of the following steps:
* I checked that the goal of elimination of references in our source
tree to shade1 had been achieved (except for the C and C++
deprecated API, the obsolete/deprecated DocBook documentation, and
historical data) using
find . -type f |grep -v .git |xargs grep shade1 |less
and
find . -type f |grep -v .git |xargs grep Shade_Region_1 |less
* Using the cmake option -DBUILD_DOC=ON, I built the "html" target and
checked that build of the html form of our documentation worked
without validation issues and produced good results for the
documentation of plStatic2dGrid, our general 2D matrix documentation
for our C API, and the deprecated plshade1 documentation.
* For both the -DPL_DEPRECATED=OFF and ON cases, I built the
test_diff_psc target without configure, build, or run-time issues,
and without any regressions in PostScript difference results.
* I ran
valgrind examples/c/x15c -dev psc -o test.psc
and
valgrind examples/c++/x15 -dev psc -o test.psc
The resulting valgrind reports were perfect (i.e.,
"All heap blocks were freed -- no leaks are possible"
and
"ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)"
) which demonstrates that the new plStatic2dGrid C functionality and
its C++ wrapper that are used in these examples introduce no memory
management issues.
M README.Release_Manager_Cookbook
M bindings/ada/plplot_standard.adb
M bindings/ada/plplot_standard.ads
M bindings/ada/plplot_thin.ads
M bindings/ada/plplot_traditional.adb
M bindings/ada/plplot_traditional.ads
M bindings/c++/plstream.cc
M bindings/c++/plstream.h
M bindings/ocaml/plplot_impl.c
M bindings/python/plplotc.i
M bindings/swig-support/plplotcapi.i
M doc/docbook/src/api-c.xml
M doc/docbook/src/api-obsolete.xml
M doc/docbook/src/api.xml
M doc/docbook/src/c.xml
M doc/docbook/src/plplotdoc.xml.in
M examples/ada/xstandard15a.adb
M examples/ada/xtraditional15a.adb
M examples/c++/x15.cc
M examples/c/x15c.c
M include/plplot.h
M src/plmem.c
M src/plshade.c
commit 22a3bad9d3aaf6921e8099b7ee87460e4b038c24
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 20 11:05:07 2017 -0700
Update release notes for next release
Describe new pyqt[45] configuration scheme and soon-to-be committed
implementation of plStatic2dGrid and corresponding deprecation of plshade1.
M README.release
commit 5f7e54119679d79c111bf37128ef441b56914d2e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Sep 18 19:17:39 2017 -0700
Simplify plapi.tpl by dropping all commented-out parts of the file
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_diff_psc target in the build tree
for the shared library case with no PostScript difference regressions.
M bindings/tcl/plapi.tpl
commit 5d2c57322f9bb78ef5d055e9439cf2efa012da64
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Sep 18 15:20:32 2017 -0700
Simplify plplot_h by dropping all commented-out parts of the file
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by configuring PLplot with the
DADD_SPECIAL_CONSISTENCY_CHECKING=ON option and building the
check_plplot_h.inc target which checks that
bindings/ocaml/plplot_h.inc is consistent with what should be same
file generated with bindings/ocaml/touchup.ml from
bindings/ocaml/bindings/ocaml/plplot_h where all three mentioned files
are in the source tree.
M bindings/ocaml/plplot_h
commit 7c53539e300ac99c0db436c228fccf6b4d63338d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Sep 12 16:53:19 2017 -0700
Fix bug in check_api_completeness.sh
This script previously failed because it referred to
files associated with the old fortran binding that has now been
removed, and the fix was to gather similar Fortran API information
from the new fortran binding.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
scripts/check_api_completeness.sh all |less
in the source tree. The script now finishes without errors although
it currently reveals some possible API inconsistencies which might be
real or which might be artifacts of how the various API results have
been parsed. So those possible API inconsistencies need to be
investigated further.
M scripts/check_api_completeness.sh
commit 696e56be6bb027d602de30120b6a12aa90d06c6f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Sep 12 16:49:33 2017 -0700
Remove all officially deprecated functions
I removed plParseInternalOpts, plSetInternalOpt, plclr, plpage, plcol,
plcontf, plP_gvpd, plP_gvpw, plotsh3d, plSetOpt, plrgb, plrgb1, plhls,
and plwid. These functions were officially deprecated (i.e., only
accessible if the user specifed the -DPL_DEPRECATED=ON cmake option)
as of the PLplot-5.9.10 release (and in some cases even before that
release) so it is long past the time to remove them. I also edited
the source tree files to remove all mentions of these functions (as well
as plParseOpts, plHLS_RGB, plRGB_HLS, and plarrows that had
been previously removed). As a result
find . -type f |grep -v .git |xargs grep -E 'plParseInternalOpts|plSetInternalOpt|plclr|plpage|plcol|plcontf|plP_gvpd|plP_gvpw|plotsh3d|plSetOpt|plrgb|plrgb1|plhls|plwid' |grep -vE 'plcol0|plcol1|plcolorbar' |less
and
find . -type f |grep -v .git |xargs grep -E 'plParseOpts|plHLS_RGB|plRGB_HLS|plarrows' |less
now only find non-relevant hits or else hits for historical references
(e.g., change logs and release notes) to these functions.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) for the build-tree shared-library case by configuring
the PLplot build using the -DADD_SPECIAL_CONSISTENCY_CHECKING=ON cmake
option, and building the validate and check_all targets with no
issues. I built the check_api_xml_consistency target which generated
the same c_plshade1 and plGetCursor inconsistencies as previously
(i.e., this target revealed no regressions from previous results due
to the present changes). Finally, I built the test_interactive and
test_noninteractive targets and checked those results as follows:
# Check for any regressions in the warnings in the cmake output.
less cmake.out
# Check for some non-standard warnings:
grep -i warning *.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout'
# Check for all errors:
grep -i error *.out
# Check for any PostScript or Text differences between all non-C languages and the corresponding
# C results.
grep -B1 -A3 "Missing examples" test_noninteractive.out |less
These checks showed no issues other than long-standing PostScript
differences for ocaml (i.e., there were no PostScript difference
regressions).
M FAQ
M README.release
M bindings/ada/plplot_standard.adb
M bindings/ada/plplot_standard.ads
M bindings/ada/plplot_thin.ads
M bindings/ada/plplot_traditional.adb
M bindings/ada/plplot_traditional.ads
M bindings/c++/plstream.cc
M bindings/c++/plstream.h
M bindings/d/plplot.d
M bindings/java/PLStream.java
M bindings/lua/plplotluac.i
M bindings/ocaml/plplot_h
M bindings/octave/PLplot/arrows.m
M bindings/octave/PLplot/figure.m
M bindings/octave/PLplot/shade.m
M bindings/octave/PLplot/support/__pl_contour.m
M bindings/octave/PLplot/support/__pl_plotit.m
M bindings/python/Plframe.py
M bindings/swig-support/CMakeLists.txt
M bindings/swig-support/plplotcapi.i
M bindings/tcl/plapi.tpl
M doc/docbook/src/api-obsolete.xml
M include/plplot.h
M scripts/check_api_completeness.sh
M src/plargs.c
M src/plcont.c
M src/pldeprecated.c
M src/plmem.c
commit ddd516cc9d8ab817da1625cad318dc65a7d33f0a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Sep 12 13:52:40 2017 -0700
Remove the rest of the sys subdirectory tree
The "sys" subdirectory tree was originally used in the pre-CMake days
to implement various build systems for various platforms. Most of
this subdirectory tree was removed in commit 69abf21 (2009-09-23)
followed by the removal of sys/dos/djgpp in commit aaf7332
(2010-01-25). This left just sys/win-tk. However, that directory has
not been developed for a decade or more, and my scan through the files
there showed there was nothing left of value there so I have removed
this last of the "sys" subdirectories in this commit.
M CMakeLists.txt
D sys/win-tk/Readme.txt
D sys/win-tk/makePlplotStarkit.tcl
D sys/win-tk/makefile.vc
D sys/win-tk/pkgIndex.tcl
D sys/win-tk/plConfig.h
D sys/win-tk/plDevs.h
D sys/win-tk/tclIndex
D sys/win-tk/tclgen.c
D sys/win-tk/tclgen.h
D sys/win-tk/tclgen_s.h
D sys/win-tk/testPlplot.tcl
commit 90723a2fa7e02899501497f461e29ba836db330d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Sep 12 12:14:47 2017 -0700
Remove unused global-in-scripts file in octave binding
D bindings/octave/globals-in-scripts
commit 8d13579ae3042b26b8746563b8b7752181737639
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Sep 7 15:35:53 2017 -0700
Perl/PDL examples removal
By historical accident and for just a limited time we actively
developed a set of standard examples written in Perl/PDL to help test
Doug Hunt's external PDL::Graphics::PLplot project. But we have now
removed those examples from our project since we have long since
stopped testing PDL::Graphics::PLplot with those examples, and, in any
case, such examples should be part of PDL::Graphics::PLplot rather
than PLplot.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_noninteractive, validate, and
install targets in the build tree for the shared library case. There
were no obvious configuration or run-time issues, and no PostScript
difference regressions.
M ABOUT
M README.release
M README.testing
M bindings/swig-support/swig_documentation.i
M bindings/tk/about.tcl
D cmake/modules/pdl.cmake
M cmake/modules/plplot.cmake
M cmake/modules/summary.cmake
M doc/docbook/src/CMakeLists.txt
M doc/docbook/src/api.xml
D doc/docbook/src/perl.xml
M doc/docbook/src/plplotdoc.xml.in
M doc/docbook/src/schemas.xml
M examples/CMakeLists.txt
M examples/Makefile.examples.in
D examples/perl/CMakeLists.txt
D examples/perl/README.perldemos
D examples/perl/check-sync.pl
D examples/perl/x01.pl
D examples/perl/x02.pl
D examples/perl/x03.pl
D examples/perl/x04.pl
D examples/perl/x05.pl
D examples/perl/x06.pl
D examples/perl/x07.pl
D examples/perl/x08.pl
D examples/perl/x09.pl
D examples/perl/x10.pl
D examples/perl/x11.pl
D examples/perl/x12.pl
D examples/perl/x13.pl
D examples/perl/x14.pl
D examples/perl/x15.pl
D examples/perl/x16.pl
D examples/perl/x17.pl
D examples/perl/x18.pl
D examples/perl/x19.pl
D examples/perl/x20.pl
D examples/perl/x21.pl
D examples/perl/x22.pl
D examples/perl/x23.pl
D examples/perl/x24.pl
D examples/perl/x25.pl
D examples/perl/x26.pl
D examples/perl/x27.pl
D examples/perl/x28.pl
D examples/perl/x29.pl
D examples/perl/x30.pl
D examples/perl/x31.pl
D examples/perl/x33.pl
M examples/plplot_configure.cmake_installed_examples.in
M plplot_test/CMakeLists.txt
M plplot_test/plplot-test.sh.in
M plplot_test/test_diff.sh.in
D plplot_test/test_pdl.sh.in
commit ce9f7bb6e9d605cb4302c409ae06e9e46f879abe
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 6 11:29:09 2017 -0700
Remove trailing whitespace from a previous commit
M cmake/modules/qt.cmake
commit 51415db8b5d88657215a02b54694d5102c36e4e2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 6 11:21:49 2017 -0700
Build system: remove remaining references to *.map files in our source tree
These *.map files were all removed in a prior commit so
they no longer have to be specifically identified as binary data
(.gitattributes) or excluded from consideration
(scripts/parity_bit_check.exclude AND
scripts/remove_trailing_whitespace.sh).
All other references to '\.map' in our source tree that were found
using
find . -type f |grep -v .git |xargs grep '\.map' |less
turned out not to be references to *.map files.
M .gitattributes
M scripts/parity_bit_check.exclude
M scripts/remove_trailing_whitespace.sh
commit 2ac4b7b530ed023b037c390b6dff1a57a30d2981
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 6 10:56:18 2017 -0700
plmap cruft removal
As of PLplot-5.9.10, a new version of plmap was implemented that used
shapefile format (accessed via shapelib) for maps. In addition other
powerful map API (see the last page of standard example 19) that
depended on shapelib map data was implemented as well. However, we
still made the old plmap implemention that depended on the
(undocumented) binary format of our *.map files available when the
user specified -DPL_DEPRECATED=ON, and this arrangement continued
through PLplot-5.13.0. However, it appears our users are generally
satisfied with the new shapefile-based plmap functionality and we no
longer want to maintain or test that old plmap functionality based on
the *.map format. So for this commit that old plmap functionality
and associated *.map files have been completely removed from our
source tree.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_diff_psc and install targets
in the build tree for the shared library case.
I did the above test twice (once as per normal and once with a
temporary local variation of cmake/modules/FindShapelib.cmake that
disabled finding of shapelib). In both cases there were no obvious
configuration or run-time issues, and the PostScript difference
results had no regressions. And (as expected) when shapelib finding was
disabled, example 19 generated plot results with no map information
other than meridians (from the calls in that example to plmeridians)
and labels, and the core plplot library (as expected) emitted "PLPLOT
WARNING" messages with the following messages:
plmap is a no-op because shapelib is not available.
plmapfill is a no-op because shapelib is not available.
plmapline is a no-op because shapelib is not available.
plmaptex is a no-op because shapelib is not available.
M README.release
M data/CMakeLists.txt
D data/cglobe.map
D data/globe.map
D data/usa.map
D data/usaglobe.map
M src/CMakeLists.txt
D src/deprecated_plmap.c
commit e3e0f15134128e76ec37e99285eae13a56b3dff0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 6 01:36:50 2017 -0700
Build system: Update NAMES used to find PYQT_SIP_DIR
This update is based on the following results from Arjen's run of the
"pkgfile -v QtCoremod.sip" command on his MinGW-w64/MSYS2 platform:
mingw32/mingw-w64-i686-python2-pyqt4 4.11.4-2 /mingw32/share/sip/Py2-Qt4/QtCore/QtCoremod.sip
mingw32/mingw-w64-i686-python2-pyqt5 5.8-1 /mingw32/share/sip/Py2-Qt5/QtCore/QtCoremod.sip
mingw32/mingw-w64-i686-python3-pyqt4 4.11.4-2 /mingw32/share/sip/PyQt4/QtCore/QtCoremod.sip
mingw32/mingw-w64-i686-python3-pyqt5 5.8-1 /mingw32/share/sip/PyQt5/QtCore/QtCoremod.sip
mingw64/mingw-w64-x86_64-python2-pyqt4 4.11.4-2 /mingw64/share/sip/Py2-Qt4/QtCore/QtCoremod.sip
mingw64/mingw-w64-x86_64-python2-pyqt5 5.8-1 /mingw64/share/sip/Py2-Qt5/QtCore/QtCoremod.sip
mingw64/mingw-w64-x86_64-python3-pyqt4 4.11.4-2 /mingw64/share/sip/PyQt4/QtCore/QtCoremod.sip
mingw64/mingw-w64-x86_64-python3-pyqt5 5.8-1 /mingw64/share/sip/PyQt5/QtCore/QtCoremod.sip
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by using all 4 combinations of
-DFORCE_PYTHON2=OFF (or ON) -DPLPLOT_USE_QT5=OFF (or ON) and
verifying the correct PYQT_SIP_DIR was found in each case.
M cmake/modules/qt.cmake
commit b96ced11d61185d7621abc4412332e51093e23f8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Sep 4 11:22:18 2017 -0700
Tcl/Tk cruft removal
As of PLplot-5.12.0, a new Tcl binding was implemented that used the
"redacted" PLplot API where all dimension arguments for arrays are
dropped from argument lists since those data are redundant (already
supplied by the arrays themselves). As a result of this change, Tcl
calls to the PLplot API in the old binding such as
$w cmd plline $nsize x y
now have to be replaced in the new binding by
$w cmd plline x y
and similarly for all other Tcl calls to the PLplot API that involve
array (tclmatrix) arguments. The advantages of this new binding are
it is cleaner, it is safer (i.e., automatically self-consistent with
regard to array dimensions), and it makes our Tcl binding compatible
with the rest of our bindings. (The only exception to this is our C++
binding which currently still uses simple C-style arrays and therefore
must use the non-redacted form of the PLplot API, but that may also
change in the future.) However, the disadvantage of this change is
our new binding is obviously backwards-incompatible with the old
binding. Therefore, for PLplot-5.12.0 we implemented the CMake option
-DUSE_NON_REDACTED_TCL_TK=ON to provide temporary deprecated access to
the old Tcl binding, and that form of backwards compatibility
continued to be provided for the PLplot-5.13.0 release. However, it
appears our users are generally satisfied with the new binding, and we
no longer want to maintain or test that old binding. So for this
commit the old Tcl binding (and old versions of the Tcl standard
examples and Tk source code that depended on it) have been completely
removed from our source tree.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building (for the shared library case) the
test_noninteractive and test_interactive targets in the build tree as
follows:
cmake .... <defaults for everything> >& cmake.out
make -j4 test_noninteractive >& test_noninteractive.out
make -j4 test_interactive >& test_interactive.out
These results were checked as follows:
# Check for any regressions in the warnings in the cmake output.
less cmake.out
# N.B. the --binary-files=text option below is required because some binary data
# (a group of NULL characters) got into test_noninteractive.out. (This is a long-standing
# bug which I plan to investigate later.)
# Check for some non-standard warnings:
grep --binary-files=text -i warning *.out |grep -vE 'cmake.out|ctest.out' |grep -vE 'PLPLOT WARNING|PRIVATE|deprecated|Resource leak|2 problems|Some graphical or stdout'
# Check for all errors:
grep --binary-files=text -i error *.out
# Check for any PostScript or Text differences between all non-C languages and the corresponding
# C results.
grep --binary-files=text -B1 -A3 "Missing examples" test_noninteractive.out |less
These checks showed no issues other than long-standing PostScript
differences for ocaml (i.e., there were no PostScript difference
regressions).
M README.release
M bindings/CMakeLists.txt
D bindings/non_redacted_tcl/CMakeLists.txt
D bindings/non_redacted_tcl/README.tclAPI
D bindings/non_redacted_tcl/global_defines.sed
D bindings/non_redacted_tcl/matrixInit.c
D bindings/non_redacted_tcl/pkgIndex.tcl.in
D bindings/non_redacted_tcl/plapi.tpl
D bindings/non_redacted_tcl/plitclgen
D bindings/non_redacted_tcl/plitclgen.tcl
D bindings/non_redacted_tcl/plplot_parameters.h
D bindings/non_redacted_tcl/pltcl.c
D bindings/non_redacted_tcl/pltcl.h
D bindings/non_redacted_tcl/pltclgen
D bindings/non_redacted_tcl/pltclgen.tcl
D bindings/non_redacted_tcl/tclAPI.c
D bindings/non_redacted_tcl/tclMain.c
D bindings/non_redacted_tcl/tclMatrix.c
D bindings/non_redacted_tcl/tclMatrix.h
D bindings/non_redacted_tcl/tclcmd.tpl
D bindings/non_redacted_tk-x-plat/CMakeLists.txt
D bindings/non_redacted_tk-x-plat/Memberscope.tcl
D bindings/non_redacted_tk-x-plat/Plplotter_Init.c
D bindings/non_redacted_tk-x-plat/Plplotwin.tcl
D bindings/non_redacted_tk-x-plat/Plwindow.tcl
D bindings/non_redacted_tk-x-plat/pkgIndex.tcl.in
D bindings/non_redacted_tk-x-plat/plbarchart.tcl
D bindings/non_redacted_tk-x-plat/plplotter.c
D bindings/non_redacted_tk-x-plat/pltimeseries.tcl
D bindings/non_redacted_tk-x-plat/pltkwd.h
D bindings/non_redacted_tk-x-plat/plwidget2.tcl
D bindings/non_redacted_tk-x-plat/tclIndex
D bindings/non_redacted_tk/CMakeLists.txt
D bindings/non_redacted_tk/FileSelector.tcl
D bindings/non_redacted_tk/PLWin.itk
D bindings/non_redacted_tk/PLXWin.itk
D bindings/non_redacted_tk/Pltk_Init.c
D bindings/non_redacted_tk/Pltkwin.tcl
D bindings/non_redacted_tk/about.tcl
D bindings/non_redacted_tk/app-defaults/PLplot.large.ad
D bindings/non_redacted_tk/app-defaults/PLplot.medium.ad
D bindings/non_redacted_tk/app-defaults/PLplot.small.ad
D bindings/non_redacted_tk/app-defaults/README
D bindings/non_redacted_tk/cmap0a.pal
D bindings/non_redacted_tk/cmap1a.pal
D bindings/non_redacted_tk/cmap1a1.pal
D bindings/non_redacted_tk/cmap1b.pal
D bindings/non_redacted_tk/cmap1c.pal
D bindings/non_redacted_tk/cmap1d.pal
D bindings/non_redacted_tk/help_gui.tcl
D bindings/non_redacted_tk/help_keys.tcl
D bindings/non_redacted_tk/help_tcltk.tcl
D bindings/non_redacted_tk/pkgIndex.tcl.in
D bindings/non_redacted_tk/plclient.tcl
D bindings/non_redacted_tk/plcolor.tcl
D bindings/non_redacted_tk/plconfig.tcl
D bindings/non_redacted_tk/pldefaults.tcl
D bindings/non_redacted_tk/plframe.c
D bindings/non_redacted_tk/plplot.tcl
D bindings/non_redacted_tk/plr.c
D bindings/non_redacted_tk/plserver.c
D bindings/non_redacted_tk/plserver.h
D bindings/non_redacted_tk/plserver.tcl
D bindings/non_redacted_tk/pltk.h
D bindings/non_redacted_tk/pltkd.h
D bindings/non_redacted_tk/pltools.tcl
D bindings/non_redacted_tk/plwidget.tcl
D bindings/non_redacted_tk/stupidtk.c
D bindings/non_redacted_tk/tcpip.c
D bindings/non_redacted_tk/tcpip.h
D bindings/non_redacted_tk/tkMain.c
D bindings/non_redacted_tk/tkshell.c
M cmake/modules/tcl-related.cmake
M cmake/modules/tk.cmake
M doc/Doxyfile.in
M examples/CMakeLists.txt
D examples/non_redacted_tcl/CMakeLists.txt
D examples/non_redacted_tcl/README.tcldemos
D examples/non_redacted_tcl/plgrid.tcl
D examples/non_redacted_tcl/plot.dat
D examples/non_redacted_tcl/plot.tcl
D examples/non_redacted_tcl/pltcl_standard_examples.in
D examples/non_redacted_tcl/r.dat
D examples/non_redacted_tcl/stats.log
D examples/non_redacted_tcl/tcldemos.tcl
D examples/non_redacted_tcl/tclsh_standard_examples.in
D examples/non_redacted_tcl/x00
D examples/non_redacted_tcl/x00.tcl
D examples/non_redacted_tcl/x01
D examples/non_redacted_tcl/x01.tcl
D examples/non_redacted_tcl/x02
D examples/non_redacted_tcl/x02.tcl
D examples/non_redacted_tcl/x03
D examples/non_redacted_tcl/x03.tcl
D examples/non_redacted_tcl/x04
D examples/non_redacted_tcl/x04.tcl
D examples/non_redacted_tcl/x05
D examples/non_redacted_tcl/x05.tcl
D examples/non_redacted_tcl/x06
D examples/non_redacted_tcl/x06.tcl
D examples/non_redacted_tcl/x07
D examples/non_redacted_tcl/x07.tcl
D examples/non_redacted_tcl/x08
D examples/non_redacted_tcl/x08.tcl
D examples/non_redacted_tcl/x09
D examples/non_redacted_tcl/x09.tcl
D examples/non_redacted_tcl/x10
D examples/non_redacted_tcl/x10.tcl
D examples/non_redacted_tcl/x11
D examples/non_redacted_tcl/x11.tcl
D examples/non_redacted_tcl/x12
D examples/non_redacted_tcl/x12.tcl
D examples/non_redacted_tcl/x13
D examples/non_redacted_tcl/x13.tcl
D examples/non_redacted_tcl/x14
D examples/non_redacted_tcl/x14.tcl
D examples/non_redacted_tcl/x15
D examples/non_redacted_tcl/x15.tcl
D examples/non_redacted_tcl/x16
D examples/non_redacted_tcl/x16.tcl
D examples/non_redacted_tcl/x17
D examples/non_redacted_tcl/x17.tcl
D examples/non_redacted_tcl/x18
D examples/non_redacted_tcl/x18.tcl
D examples/non_redacted_tcl/x19
D examples/non_redacted_tcl/x19.tcl
D examples/non_redacted_tcl/x20
D examples/non_redacted_tcl/x20.tcl
D examples/non_redacted_tcl/x21
D examples/non_redacted_tcl/x21.tcl
D examples/non_redacted_tcl/x22
D examples/non_redacted_tcl/x22.tcl
D examples/non_redacted_tcl/x23
D examples/non_redacted_tcl/x23.tcl
D examples/non_redacted_tcl/x24
D examples/non_redacted_tcl/x24.tcl
D examples/non_redacted_tcl/x25
D examples/non_redacted_tcl/x25.tcl
D examples/non_redacted_tcl/x26
D examples/non_redacted_tcl/x26.tcl
D examples/non_redacted_tcl/x27
D examples/non_redacted_tcl/x27.tcl
D examples/non_redacted_tcl/x28
D examples/non_redacted_tcl/x28.tcl
D examples/non_redacted_tcl/x29
D examples/non_redacted_tcl/x29.tcl
D examples/non_redacted_tcl/x30
D examples/non_redacted_tcl/x30.tcl
D examples/non_redacted_tcl/x31
D examples/non_redacted_tcl/x31.tcl
D examples/non_redacted_tcl/x33
D examples/non_redacted_tcl/x33.tcl
D examples/non_redacted_tk/CMakeLists.txt
D examples/non_redacted_tk/Makefile.examples.in
D examples/non_redacted_tk/README.tkdemos
D examples/non_redacted_tk/plgrid.in
D examples/non_redacted_tk/plserver_runAllDemos.in
D examples/non_redacted_tk/plserver_standard_examples.in
D examples/non_redacted_tk/runAllDemos.tcl
D examples/non_redacted_tk/runExtendedDemos.tcl
D examples/non_redacted_tk/tk01.in
D examples/non_redacted_tk/tk02.in
D examples/non_redacted_tk/tk03.in
D examples/non_redacted_tk/tk04.in
D examples/non_redacted_tk/tkdemos.tcl
D examples/non_redacted_tk/wish_runAllDemos.in
D examples/non_redacted_tk/wish_standard_examples.in
D examples/non_redacted_tk/xtk01.c
D examples/non_redacted_tk/xtk02.c
D examples/non_redacted_tk/xtk04.c
M plplot_test/CMakeLists.txt
M plplot_test/plplot-test-interactive.sh.in
M plplot_test/plplot-test.sh.in
M src/CMakeLists.txt
commit bc7df37f6881260bef4f4391862d343181a5d066
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Sep 3 15:16:09 2017 -0700
Fortran cruft removal
As of PLplot-5.12.0, a new Fortran binding was implemented using the
powerful capabilities of the Fortran 2003 iso_c_binding module which
was the replacement for the old binding that was implemented using a
combination of Fortran and C code. The new binding is much simpler,
more consistent, and more standards-compliant than the old binding and
has some powerful new features (e.g., both single and double
precisions Fortran floating-point arguments are accepted). Therefore,
the new binding is necessarily backwards incompatible with the old
binding. For PLplot-5.12.0 we implemented the CMake option
-DPL_DEPRECATED_fortran=ON to provide temporary deprecated access to
the old Fortran binding, and that form of backwards compatibility
continued to be provided for the PLplot-5.13.0 release. However, it
appears our users are generally satisfied with the new binding, and we
no longer want to maintain or test that old binding. So for this
commit the old binding has been completely removed from our source
tree.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_diff_psc target.
M README.release
M bindings/CMakeLists.txt
D bindings/old_fortran/CMakeLists.txt
D bindings/old_fortran/global_defines.sed
D bindings/old_fortran/plparseopts.f90
D bindings/old_fortran/plplot_parameters.inc
D bindings/old_fortran/plplot_types.f90.in
D bindings/old_fortran/plplotfortran.def
D bindings/old_fortran/plplotfortran_ifort.def
D bindings/old_fortran/plplotfortran_mingw.def
D bindings/old_fortran/plstubs.h
D bindings/old_fortran/readme_f95.txt
D bindings/old_fortran/sc3d.c
D bindings/old_fortran/sccont.c
D bindings/old_fortran/scstubs.c
D bindings/old_fortran/sfstubs.inc
D bindings/old_fortran/sfstubsfortran.f90
D bindings/old_fortran/strutil.f90
M cmake/modules/fortran.cmake
M cmake/modules/plplot_version.cmake
M doc/Doxyfile.in
M examples/CMakeLists.txt
D examples/old_fortran/CMakeLists.txt
D examples/old_fortran/Makefile.examples.in
D examples/old_fortran/plfortrandemolib.f90
D examples/old_fortran/plfortrandemos.inc.in
D examples/old_fortran/test_plfortrandemolib.f90
D examples/old_fortran/x00f.f90
D examples/old_fortran/x01f.f90
D examples/old_fortran/x02f.f90
D examples/old_fortran/x03f.f90
D examples/old_fortran/x04f.f90
D examples/old_fortran/x05f.f90
D examples/old_fortran/x06f.f90
D examples/old_fortran/x07f.f90
D examples/old_fortran/x08f.f90
D examples/old_fortran/x09f.f90
D examples/old_fortran/x10f.f90
D examples/old_fortran/x11f.f90
D examples/old_fortran/x12f.f90
D examples/old_fortran/x13f.f90
D examples/old_fortran/x14f.f90
D examples/old_fortran/x15f.f90
D examples/old_fortran/x16af.f90
D examples/old_fortran/x16f.f90
D examples/old_fortran/x17f.f90
D examples/old_fortran/x18f.f90
D examples/old_fortran/x19f.f90
D examples/old_fortran/x20f.f90
D examples/old_fortran/x21f.f90
D examples/old_fortran/x22f.f90
D examples/old_fortran/x23f.f90
D examples/old_fortran/x24f.f90
D examples/old_fortran/x25f.f90
D examples/old_fortran/x26f.f90
D examples/old_fortran/x27f.f90
D examples/old_fortran/x28f.f90
D examples/old_fortran/x29f.f90
D examples/old_fortran/x30f.f90
D examples/old_fortran/x31f.f90
D examples/old_fortran/x33f.f90
M plplot_test/CMakeLists.txt
M plplot_test/plplot-test.sh.in
M scripts/style_source.sh
commit 259a7d4a90d63a39c0f7fd95a37ef9f163e73be6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Sep 2 19:09:57 2017 -0700
Update script to remove trailing whitespace
Files in the debian directory are no longer ignored (since this
directory does not exist any more), and all *.pyc files are now
ignored.
This change was motivated by an attempt to remove trailing whitespace
from bindings/python/Plframe.pyc.
M scripts/remove_trailing_whitespace.sh
commit b3ef719f9ee5a763baa4705104a97c95c178afd3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Sep 2 19:00:29 2017 -0700
Build system: rewrite logic for determining PYQT_SIP_DIR and PYQT_SIP_FLAGS
For pyqt4 the pyqtconfig module useful for determining PYQT_SIP_DIR
and PYQT_SIP_FLAGS has been deprecated and has therefore already
completely disappeared from some software platforms (e.g.,
MinGW-w64/MSYS2). Therefore, in this commit we have replaced that
approach with an approach very similar to what we currently use for
pyqt5 (where the pyqtconfig module has never been available).
PYQT_SIP_FLAGS is easy to determine without the pyqtconfig module, but
determination of PYQT_SIP_DIR, the location where the PyQT sip files
are located is not completely straightforward. For the Debian-based
Linux platforms and rpm-based Linux platforms accessible with
rpm.pbone, Cygwin, and MinGW-w64/MSYS2, we feel we have the correct
HINTS in place to find this directory. But for other platforms where
this might be an issue, the user is invited to install a system
package with the needed pyqt-related sip files, but if those have
already been installed, then they are invited to work around the
problem by specifying the correct PYQT_SIP_DIR to find those files,
and communicating with us to update our HINTS appropriately for their
platform.
Since the pyqt[45] logic is now so similar, we have reorganized the
CMake code to treat those two cases as much as possible with the same
code.
We have also taken the opportunity to style this CMake code using
emacs cmake mode. That styling included replacing all tabbed
indentation by spaced indentation. (I have just discovered with that
emacs mode that you can do such replacement by replacing all tabs with
large numbers of spaces, then the correct spaced indentation will be
used if you subsequently style all lines by selecting all lines of the
file and hitting ctrl-alt-backslash.)
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) using the 4 combinations of the cmake options
DFORCE_PYTHON2=OFF/ON -DPLPLOT_USE_QT5=OFF/ON. In all cases, the PyQt
sip directory (and sip flags) were found without issues, and building
the appropriate test_pyqt[45]_example target for each case proceeded
without issues other than pyqt5_example sometimes segfaulted at the
end (a known, long-standing issue with Qt5).
Additional testing of this new logic is requested on all accessible platforms.
M cmake/modules/qt.cmake
commit 1b93965d437f3c63517cb0ac712482bcda8bf012
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Aug 27 18:04:41 2017 -0700
pytkdemo: import and reload improvements
* For both pytkdemo and its Plframe.py dependency, I replaced all
non-namespaced imports of PLplot modules with the namespaced
version. This change removes the double import (one namespaced and
one not) for Plframe so likely solves the corruption of
bindings/python/Plframe.pyc by a Python race condition that
according to a Python developer had been solved for Python3 (which
my results confirm since I never got corruption in that case), but
likely not for Python2 (as my on-going corruption results before the
present release for this Python version also confirm).
* I improved the pytkdemo logic to work around the different ways to
access the reload function in Python for the three cases
if version < 3.0.0:, elif version < 3.4.0:, else:
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
Debian Jessie by building the test_pytkdemo target (both with and
without -DFORCE_PYTHON2=ON) and clicking on all examples as well as
the "clear", "clone", "reload", and "dismiss" buttons without issues.
M bindings/python/Plframe.py
M examples/python/pytkdemo
commit 9cc0e68cd8a629e25cbbdb7629499874cf29e2b6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Aug 27 15:00:21 2017 -0700
Remove trailing whitespace from ChangeLog.release
M ChangeLog.release
commit e3202104b66994c7dc7693c06b5ac125e55eaa0a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Aug 27 14:36:11 2017 -0700
Build system: Improve user control of Python version
The build system now takes the following steps to search for a suitable
Python version.
* The build system searches for the PLPLOT_PYTHON_EXACT_VERSION version
of Python where PLPLOT_PYTHON_EXACT_VERSION is specified by the
user. If this string is not specified by the user it defaults to
"", and this exact search therefore always fails in this case.
* If that first exact search is a failure and the option FORCE_PYTHON2
is not ON, the build system searches for PYTHON 3.
* If neither of the above two searches is a success, then the build
system searches for Python 2.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by repeated fresh configurations of PLplot with
-DPLPLOT_PYTHON_EXACT_VERSION=<Version> strings
or -DFORCE_PYTHON2=ON specified.
<Version> strings such as "", "whatever", and "1.0.0" found nothing
so Python version 3.4.2 was found according to the above logic.
<Version> strings such as "2.0.0" found unsuitable 2.7.9 so that
exact match failed. However, those find values were cached so the
subsequent logic above found 2.7.9.
<Version> strings such as "3.9.9" found unsuitable 3.4.3 so that
exact match failed. However, those find values were cached so the
subsequent logic above found 3.4.3.
The <Version> string "2.7.9" immediately found suitable 2.7.9.
The <Version> string "3.4.3" immediately found suitable 3.4.3.
-DFORCE_PYTHON2=ON immediately found 2.7.9.
All of these Python version finding results are as expected.
M README.release
M cmake/modules/python.cmake
commit cf7faa2c13a0478487ad95c9eac021279a04021a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Aug 27 00:10:41 2017 -0700
Build system: Improve version check for wxwidgets
I replaced our brute-force version check (which did not deal well with
the situation where multiple versions of wxwidgets were available)
with the native version check capability of the find module for
wxWidgets. A byproduct of this change is the wxwidgets version that
is found is automatically printed out.
M cmake/modules/wxwidgets.cmake
commit 790a0c66f9bbc805dbabeda05bb3d933e7ce57e8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Aug 26 15:46:51 2017 -0700
Correct the URL (https: protocol rather than http:) for Testing reports
M README.release
commit dde43575033e646015c2bf083f54c8972593031b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Aug 26 14:59:18 2017 -0700
Create new (preliminary) version of release notes for the next release
M README.release
commit d3f8530c912e3c03fea786aed978448e4e8356b0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Aug 26 14:49:03 2017 -0700
Tweak README.Release_Manager_Cookbook
These tweaks concern improved instructions/fixes that occurred in
the last stages of the 5.13.0 release.
M README.Release_Manager_Cookbook
Download Latest Version
plplot-5.15.0.tar.gz (15.4 MB)
