PLplot Release 5.12.0
This is a release of the PLplot plotting package. It represents the
ongoing best efforts of the PLplot development community (roughly 400
commits since the last release) 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 several times per year.
Note that PLplot has been continuously developed since 1986 so it has
accumulated a lot of cruft since that time that we are now slowing
dealing with 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
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 the licensing details.
________________________________________________________________
CONTENTS
1. OFFICIAL NOTICES FOR USERS
1.1 CMake version compatibility
1.2 Backwards incompatibilities have been introduced for our C (and other) API
1.3 Backwards incompatibilities have been introduced for our Fortran binding
1.4 Backwards incompatibilities have been introduced for our Tcl/Tk bindings
1.5 Octal interpretation has been removed from numerical escape sequences in text
1.6 The rpath treatment has been changed for Mac OS X platforms
1.7 Notice of a backwards incompatibility for our C API that we plan for our next release
2. Improvements relative to the previous release
2.1 Bug fixes
2.2 Rewrite the CMake Ada language support
2.3 Rewrite the Fortran binding
2.4 Supply old Fortran binding and examples option
2.5 Backwards incompatibilities introduced by the new Fortran binding
2.6 Examples reworked for the -DPL_DOUBLE=OFF case
2.7 Changes to our Ada bindings and examples
2.8 Changes to our tclmatrix library
2.9 Backwards-incompatible changes to our Tcl/Tk bindings and examples
2.10 Substantial rewrite of the DocBook documentation
2.11 Default page size consistency
2.12 Updated D language support
2.13 Modernized build-system support for Qt4 and Qt5
2.14 Implemented support for pyqt5
2.15 Addressed -DPL_DOUBLE=OFF issues
2.16 Replaced "Lena" with "Chloe"
2.17 Removed trailing blanks on most text files in our source tree
2.18 Make our wxwidgets find module consistent with the official version for CMake-3.7.1
2.19 Introduction of two new generic pointer types to help protect against a planned future C API breakage
2.20 Introduction of additional self-describing names for the types of arguments used in our C API.
2.21 Implement submission of dashboards to the <my.cdash.org> cdash server
2.22 Substantial update and rename of the Python examples
2.23 Linux efficiency improvements for the wxwidgets device driver
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.0.2 on Linux and 3.6.2 on all other platforms.
(And it is likely we will bump those minimum versions to at least
3.7.0 for our next release.)
This particular PLplot release has been comprehensively tested for
CMake versions 3.0.2 through 3.7.0 on a variety of platforms (see
<http://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>).
So if your CMake version is <= 3.7.0 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 might 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.7.0, the
first thing you should try is the well-tested CMake-3.7.0.
1.2 Backwards incompatibilities have been introduced for our C (and other) API
We recently discovered that the second (argv) argument of plparseopts
was changed by that routine so accordingly we have dropped the
inappropriate "const" attribute from the type of that argument.
The return type has been change from int to PLINT (which is normally
defined by "typedef int32_t PLINT;" for plparseopts, plsetopt,
plMergeOpts, plFindName, plGetCursor, and plTranslateCursor.
All these changes have been propagated to our language bindings where
appropriate.
1.3 Backwards incompatibilities have been introduced for our Fortran binding
The new implementation of the Fortran binding has introduced a
significant number of backwards incompatibilities. See 2.5 below for
the details.
1.4 Backwards incompatibilities have been introduced for our Tcl/Tk bindings
Our Tcl/Tk bindings and examples now use only a redacted API, i.e.,
redundant array dimensions are removed from all argument lists.
See 2.9 for the details concerning this important Tcl/Tk change.
1.5 Octal interpretation has been removed from numerical escape sequences in text
The undocumented feature where leading 0's in numerical escape
sequences meant the whole number was interpreted as octal rather than
decimal has been removed, i.e., if the number string starts with 0x or
0X then the interpretation of the number is hexadecimal (as before),
but all other number strings starting with 0 are interpreted as
decimal rather than octal. Thus, the decimal interpretation of
"#(0123)" and "#(123)" is now identical, and there are no errors
introduced by leading-zero decimal escape sequences such as "#(0855)".
1.6 The linking method has been changed for the Mac OS X platform
For this platform our build system previously used the default CMake
rpath-based linking method in the build tree, but in the installed
examples tree used the INSTALL_NAME_DIR linking method instead of the
rpath-based method. For this release the build-tree linking method
uses the rpath-based linking method as before, but if USE_RPATH is ON
(the default) we also use the rpath-based linking method in the
installed examples tree. This change makes our linking treatment on
Mac OS X similar to that on Linux with the side benefit that
DYLD_LIBRARY_PATH no longer has to be set in order to use a
traditional (Make + pkg-config) build of software against a set of
PLplot libraries that are installed in a non-standard location.
However, those who install PLplot libraries in standard locations
(typically just the downstream Mac OS X free software distributors of
PLplot such as Fink, MacPorts, and Homebrew) may prefer not to use
rpath-based methods for installed libraries. Such users should
specify the old linking behaviour using -DUSE_RPATH=OFF.
1.7 Notice of a backwards incompatibility for our C API that we plan for our next release
In our next release as an aid toward achieving our goal of const
correctness for PLplot, we plan to distinguish between generic pointer
arguments to our C API that do and do not have the const attribute.
See 2.19 for a method of protecting yourself against that planned
future backwards incompatibility for our C API.
________________________________________________________________
2. Improvements relative to the previous release
2.1 Bug fixes
The bug fixes in this release are noted in the ~400 commit messages
collected in ChangeLog.release.
2.2 Rewrite the CMake Ada language support
The CMake-based Ada language support has been totally rewritten
based on the official CMake-3.4.0 language support that is used for
C++. This rewrite should make the Ada language support much easier to
understand since the diff results comparing Ada and CMake-3.4 C++
language support are quite small if some Ada to CXX translations are
done with sed. Also, it is considered to be a major advantage that
the new Ada language support is based on modern CMake language support
principles and infrastructure as opposed to whatever was available for
language support a decade ago when the old Ada language support was
implemented.
This new Ada language has been much more extensively tested than our
old Ada language support. On Linux it is essentially perfect for our
Ada library and executable needs in the build tree and install tree.
On Mac OS X, our one report shows no problems in the build tree, but
there is a linking issue in the install-tree version of PLplot Ada
libraries that we have been unable to figure out. Our one report for
Cygwin (the first time our old or new Ada language support has been
tested on any Windows platform) shows failure of our Ada
language support on that platform (fairly much as expected since we
don't understand what the Cygwin platform requires for CMake language
support) .
2.3 Rewrite the Fortran binding
The Fortran binding has been completely rewritten using the powerful
capabilities of the iso_c_binding module that is available for modern
Fortran. There are several advantages to this rewritten binding.
(i) It is implemented using much more compact code with none
of the interfacing done in C (i.e., the plplotf95c library has
now been removed completely).
(ii) It is much easier to understand and maintain than the previous
effort.
(iii) Linking issues are simplified. (nm --undefined-only shows that
the Fortran examples only need to be linked to libplplotf95 and not
libplplot)
(iv) Support for kind=plflt for those who just want to adopt in their
own code the same Fortran floating-point precision as in our C
libraries remains, but this is no longer necessary. Instead, users
are encouraged to use either kind(1.0) or kind(1.0d0) for the
floating-point arguments in calls to PLplot routines, and our new
Fortran binding automatically does the appropriate conversions to the
floating-point precision of our C libraries using modern Fortran's
overloading mechanism.
N.B. plflt is now replaced in our examples by pl_test_flt, and that
latter parameter is made available by the plplot module as a
convenience to our Fortran developers to test that either kind(1.0) or
kind(1.0d0) works well for our examples regardless of the
floating-point precision used in our C libraries. But users are
strongly discouraged from using this test parameter for their own code
because we make no guarantees concerning its value, and instead they
should make their own decision about whether to adopt kind(1.0) or
kind(1.0d0) for the floating-point arguments for a given call to a
PLplot routine. See further remarks in examples/f95/README_precision.
(v) Once support for bindings/old_f95 and examples/old_f95 (see 2.4
below) has been dropped, the "c_" prefixes on our C API that were
required to avoid name clashes with the Fortran versions are no
longer required for that reason. If it turns out no other
binding requires these prefixes then we potentially could
remove them which would be a welcome simplification.
We have achieved good test results (no build or run-time issues, no
PostScript differences between the Fortran and C results for our ~30
standard examples written in the two languages) for gfortran, ifort,
and nagfor with this new Fortran binding and examples. In particular,
we feel it is significant there are no warning messages at all
generated by nagfor when we build the new Fortran binding and examples
with that compiler. We had to make a significant number of changes to
achieve that goal to bring us into strict standards compliance consistent
with the claim made for that compiler that it is "valued by developers
all over the globe for its checking capabilities and detailed error
reporting" (see <https://www.nag.com/nag-compiler>).
One known gfortran downside of this new binding is it generates some ~50
"marked PRIVATE" warning messages when building the plplotf95 target
with the gfortran Fortran compiler. A typical example of such a
warning message is
Warning: Symbol 'interface_plcont' at (1) is marked PRIVATE but has been given the binding label 'c_plcont'
It appears these warnings (which do not occur if using the ifort or
nagfor Fortran compilers) are due to a gfortran bug (see
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111> and
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861>), i.e., they are
spurious warnings concerning completely valid use of the private
attribute for interface blocks describing C routines. There appear to
be no known negative consequences of this gfortran bug other than the
spurious warnings themselves. Until this gfortran bug is fixed, these
~50 "marked PRIVATE" warnings should just be ignored for those using
gfortran.
Another known gfortran downside of this new binding is it does not
build with gfortran 4.8.x or less, i.e., apparently the implementation
of the iso_c_binding module for those versions of gfortran is not good
enough to build our new Fortran binding. However, our tests show
gfortran 4.9.2 does implement the iso_c_binding module well enough to
produce good results (other than the above spurious warnings). So
4.9.2 is the minimum version of gfortran that we support with this new
binding, and if the user is temporarily stuck with an earlier version
of gfortran, see the next section.
2.4 Supply old Fortran binding and examples option
Because the new Fortran binding is not completely compatible with the
old one (see 2.5 below for the list of incompatibilities) and does not
build for gfortran versions less than 4.9.2, we have
supplied a -DPL_DEPRECATED_f95=ON CMake option (which defaults to
OFF) that uses a snapshot of the old Fortran binding and associated
Fortran examples rather than the new versions.
We have tested the new Fortran bindings and examples on several
different Fortran platforms accessible to us so it should normally
work well, but this option should be suitable for emergency conditions
where you just cannot get the new Fortran binding to work properly.
But in this case please let us know about those issues so we can fix
them. Also, this -DPL_DEPRECATED_f95=ON option should extend the
length of time that the old Fortran 95 binding is available for new
PLplot releases, but that old binding will not be available
indefinitely so at some point (after discussions on the plplot-general
list concerning how many users are still using this option) the
-DPL_DEPRECATED_f95=ON option will be removed and user choices will be
reduced to either using an old PLplot version or modifying their
software for the incompatibilities mentioned below for the new Fortran
binding. And if you start that modification process immediately, you
will likely get better help with it since we have just gone through
that process for the Fortran examples (which should be your first
guide concerning how to use the new Fortran binding).
2.5 Backwards incompatibilities introduced by the new Fortran binding
The rewritten Fortran binding does have a significant number of
backwards-incompatible API changes we have decided to introduce at
this time to improve consistency and simplicity as much as possible.
As always, the examples are your best documentation on how to
use this new Fortran API. But for those experienced with the
old API, here is the list of changes.
(i) The new Fortran binding only maps C routines that have return
values to Fortran functions and C routines with no return values to
Fortran subroutines. The strict application of this rule means that
plparseopts, plsetopt, and plGetCursor have been changed from
Fortran subroutines to Fortran functions. This requires changes to
users' code similar to the following:
call plparseopts(...)
changed to
integer :: plplarseopts_rc
[...]
plparseopts_rc = plparseopts(...)
which will now allow our Fortran users to respond to error conditions
for plparseopts, plsetopt, and plGetCursor.
(ii) Only the redacted form of API (with all redundant dimension
arguments removed) is supported. The following set of functions
has been affected by the strict application of this rule:
pllegend (drop redundant nlegend argument),
plpat (drop redundant nlin argument),
plsurf3dcl (drop redundant indexxmax argument),
plstyl (drop all overloaded versions other than the redacted one. N.B. use
zero-sized arrays to indicate that plstyl should restore the default continuous
line style.)
(iii) Multiple arrays in a redacted argument list should have
consistent sizes for dimensions that are designed for the same
purpose. This rule has been enforced for many years for most
languages where we provide bindings since if we take the size from an
array that is inconsistently smaller because of user error, then part
of the plot will be missing, and if we take the size from an array
that is inconsistently larger because of user error, then access
violations or memory management issues will be the result. To warn of
such potential issues for the Fortran case we now generate a warning
when inconsistent array sizes are encountered. For those cases which
generate such warnings because the calling routine provides static or
allocatable arrays which are larger than the subsets of the array
indices which have values assigned, it is straightforward to comply
with this consistency rule by taking the appropriate array slice in
the argument list, e.g., "text_colors(1:nlegend), text(1:nlegend)" in
the pllegend argument list.
The complete list of these adopted rules for consistently sized array
arguments for our Fortran binding are given at
bindings/f95/README_array_sizes.
(iv) Fortran logical arguments are strictly used for all cases where
the corresponding C argument is PLBOOL. In order to comply strictly
with this rule, the list of functions whose arguments have changed
from integer to logical or functions where an extra signature with
integer argument rather than correct logical argument has been removed
is the following:
plarc (last argument),
plspal1 (last argument), and
plconfigtime (fifth argument).
(v) For those rare cases where the actual floating-point precision
cannot be automatically specified by the user via the precision of the
floating-point arguments which are used for a call to a subroutine or
function, then the only choice we supply is the double precision
(kind(1.0d0)) one regardless of the underlying precision of the C
plplot library.
The instances of this issue are the floating-point return value of the
function plrandd, floating-point elements of the defined type
PLGraphicsIn, floating-point arguments of Fortran callback functions
that are used as arguments for plstransform and pllabelfunc, and the
pre-defined floating-point parameters PL_NOTSET, PL_PI, and PL_TWOPI.
To see how each of these cases should be handled by users please
consult examples/f95/README_precision and the Fortran examples
in that directory.
(vi) The experimental and far from uniform support for the kind=plint and
kind=plunicode Fortran integer types has now been removed. Instead,
ordinary default kind integers are used for the Fortran types
corresponding to the PLINT and PLUNICODE C types.
(vii) Support for a single integer argument for plstransform that is
unused is dropped because calling plstransform with no arguments
has exactly the same effect.
(viii) A rectangular logical argument for all variants of plshade and
plshades has been added to give the same control of this argument to
Fortran users that is currently available to C users.
(ix) The "defined" argument for all variants of plshade and plshades
that existed but was unused in the old Fortran binding has been
removed for the new binding.
(x) The old support for translating any "\n" characters in Fortran
character string arguments to "char(10)" has now been removed.
Instead, a user should use achar(10) (not char(10) which may not give
you the desired line feed character on certain platforms) to do this
job instead. So if the old character string argument was
"Heale\nDown"
that should be replaced by
"Heale"//achar(10)//"Down"
(Compare examples/old_f95/x19f.f90 with examples/f95/x19f.f90.) The
net result of the achar(10) method is that the Fortran character
string is reliably on all platforms translated at the C level to
"Heale\nDown" (where in this case "\n" has a special character meaning
of linefeed unlike the Fortran case. After that, how our device
drivers currently interpret that special C character for linefeed is
idiosyncratic to each of our device drivers.)
(xi) The index arguments (i.e., the last 3 arguments) of plot3dcl and
plsurf3dl have been changed from one-based indexing to zero-based
indexing to be consistent with C and also all our other bindings.
(xii) For the plimagefr signature without callback-related arguments
(i.e., no trailing xg, yg, tr, or callback arguments), we now use NULL
internally for the C callback following what is done (both in the old
and new binding) for the plshade and plshades signatures without
callback-related arguments. In all these different cases, the C
library interprets the NULL callback as a signal to map the x and y
index ranges to the world coordinates xmin, xmax, ymin, and ymax
(which also appear in the argument lists for plshade, plshades, and
plimagefr) without recourse to a callback. The old Fortran binding
used pltr0 rather than NULL for the plimagefr signature without
callback-related arguments. In retrospect we feel this was an error
(since it meant xmin, xmax, ymin, and ymax were always ignored for the
old Fortran plimagefr case). Note, this distinction does not matter
for our Fortran example 20 (the only place this particular signature
of plimagefr is used in our examples) since xmin, xmax, ymin, and ymax
correspond to the exact x and y ranges that pltr0 delivers. But it
does matter for other uses of this plimagefr signature which is
why we are documenting this backwards incompatibility here.
(xiii) For the plcont and plvect signatures without callback-related
arguments (i.e., no trailing xg, yg, tr, or callback arguments), we
now use pltr0 internally for the callback rather than pltr0f (which
applies an offset of 1 unit in the way that input arguments were
interpreted compared to pltr0). The idea behind pltr0f was
problematic since the index range being interpreted was always in the
C code and has nothing to do with Fortran indices. In any case, this
is likely a "for the record" backwards incompatibility since these
particular signatures for plcont and plvect were not documented, and
were not used in any of our examples.
2.6 Examples reworked for the -DPL_DOUBLE=OFF case
N.B. Many of our supported languages do not currently work for
-DPL_DOUBLE=OFF so the changes below for many of our examples cannot
be tested for that case. However, all these changes are worthwhile
style changes in their own right that have been thoroughly tested for
the (default) -DPL_DOUBLE=ON case.
* Example 29 has been changed for all our supported languages to be
much more careful of adopted epoch to maximize the
time-representation precision. This is a good illustration of how
to use epochs correctly for our users, and also allowed this example
to give good results (as opposed to errors) for the -DPL_DOUBLE=OFF
case.
* Example 31 has been changed for all our supported languages to use
variables rather than constants for arguments of most calls
(specifically all calls with floating-point arguments) to PLplot
routines. Use of variables rather than constants is generally
better form in any case (via the self-description associated with
well-chosen variable names), but this change also dealt with
-DPL_DOUBLE=OFF errors for this example in a natural way for C, C++,
and likely other languages as well.
* Example 33 has been changed for all our supported languages to
replace the former scaling factor of 1.e-200 by 1.e-20. This solved
an issue with the -DPL_DOUBLE=OFF case where the former scaling
factor underflowed, and those uniformly zeroed results in turn
caused PLplot run-time errors.
2.7 Changes to our Ada bindings and examples
Using PLplot "traditional" and PLplot "standard" to name our two thick
user-visible Ada bindings has long been documented in our DocBook
documentation for our Ada bindings. That is a good naming convention
since the names of these bindings nicely complement each other. Our
existing Ada thick "PLplot_Traditional" binding implementation already
follows this naming convention, and we have now changed to this same
naming convention for our other thick binding by renaming it from
"PLplot" to "PLplot_Standard". To keep backwards compatibility
(which has been tested by building and running our PLplot-5.11.1 Ada
examples against our latest Ada binding) we still provide
the deprecated "PLplot" name to be used in "with" and "use" statements
instead of the recommended "PLplot_Standard" name to access our
"standard" thick binding.
We have changed our Ada examples to be consistent with the above change. In
addition, we have renamed the x??a.adb examples which depend on what
is now called our thick PLplot_Traditional binding to xtraditional??a.adb
and our xthick??a.adb examples (a egregious misnomer) which depend
on what is now called our thick PLplot_Standard binding to xstandard??a.adb.
We have made changes to our Ada bindings and examples so they now provide
the following report of complete consistency with the corresponding C results:
adastandard
Missing examples :
Differing graphical output :
Missing stdout :
Differing stdout :
adatraditional
Missing examples :
Differing graphical output :
Missing stdout :
Differing stdout :
2.8 Changes to our tclmatrix library
Implement vastly improved index slicing following the index slicing
rules used for Python. Also implement vastly improved array
initialization and assignment for our tclmatrix library.
To see what is now possible, take a look at bindings/tcl/test_tclmatrix.tcl
and also the added instructions in examples/tcl/README.tcldemos for using
bindings/tcl/test_tclmatrix.tcl to test all these new tclmatrix capabilities.
2.9 Backwards-incompatible changes to our Tcl/Tk bindings and examples
Our Tcl/Tk bindings have been modified in a backwards-incompatible way
to use a redacted API. That is, redundant array dimension information
has now been removed from all calls to PLplot routines. So for
example, the call to plline from a Tcl/Tk environment has been changed
from
$w cmd plline $nsize x y
(where $nsize is the redundant size of the x and y arrays)
to
$w cmd plline x y
Note, this call returns TCL_ERROR if either x or y are of the wrong
type, or if x and y have inconsistent lengths. So this new API is typically
more robust than our old API. Of course, there are cases where users need to
collect information in x and y matrices of different sizes and only
plot a subset of that information. For this case you should use the new
tclmatrix index slicing, matrix initialization, and matrix assignment capabilities
to create the same-sized x and y matrices you want to plot.
For (a rather contrived) example that plots a slice of xoriginal and
yoriginal corresponding to the third hundred values of xoriginal and the
second hundred values of yoriginal do the following:
matrix xoriginal f 500
matrix yoriginal f 1000
# for loop to define the 500 values of xoriginal
[...]
# for loop to define the 1000 values of yoriginal
# Use new index slice and matrix initialization capability
# to select the third hundred xoriginal values to plot:
matrix x f 100 = [xoriginal 200:300]
# Use new index slice and matrix assignment capability
# to select the second hundred yoriginal values to plot:
matrix y f 100
y : = [yoriginal 100:200]
$w cmd plline x y
Note that many PLplot calls do involve arrays so this new redacted API is largely
incompatible with the old API. So for old applications we have
provided the -DUSE_NON_REDACTED_TCL_TK=ON cmake option to provide
access to a deprecated version of our Tcl/Tk bindings and examples
that is a snapshot of the relevant Tcl/Tk code before any of this
redacted API work had been done.
This -DUSE_NON_REDACTED_TCL_TK=ON option should extend the length of
time that the old non-redacted API is available with new PLplot
releases, but that deprecated API will not be available
indefinitely so at some point (after discussions on the plplot-general
list concerning how many users are still using this option) the
-DUSE_NON_REDACTED_TCL_TK=ON option will be removed and user choices
will be reduced to either using an old PLplot version or modifying
their Tcl/TK software for the incompatibilities mentioned above for
our new redacted API. And if you start that modification process
immediately, you will likely get better help with it since we have
just gone through that process for our Tcl/Tk examples (which should
be your first guide concerning how to use the new redacted API for
Tcl/Tk).
2.10 Substantial rewrite of the DocBook documentation
The fundamental principle used for this rewrite is to rely heavily on
cross-references. Most of these are internal to the DocBook
documentation, but some (such as references to our examples on our
website and platform-dependent build quirks documented in our wiki)
are external. The result is much less repeating of material (which
substantially reduces maintenance issues) and use of the best source
of documentation in all cases. For example, the simple and advanced
use of PLplot chapters previously contained large chunks of C code from the C
examples. All that C code is gone and instead references to our
standard examples on our website are used instead. The result is much
less C specific since the website user has ready access to the example
code in each of our supported languages. Furthermore, the website
gives the expected plot results for the example. Of course, the
downside of this new documentation approach is each section of the
DocBook documentation is much less self-contained. But the advantages
of the new "cross-reference" documentation approach far outweigh that.
Here are the parts of the DocBook documentation that have been rewritten
with the new approach.
* The introduction has been rewritten to be consistent with
modern PLplot. For example, modern CMake-based build generic build
instructions are given, and a reference to our wiki is given for
those users who encounter platform-dependent build quirks.
* The simple and advanced use of PLplot chapters have been rewritten
as referred to above.
* The chapters referring to drivers which implement file devices and
interactive devices have been rewritten to be consistent with modern
PLplot. For example, the list of devices that was egregiously
outdated has now been updated.
* The C chapter has been rewritten to be consistent with
modern PLplot. In particular, the new self-describing names for
PLplot C argument types (see 2.19 and 2.20) are documented.
* The Fortran chapter has been rewritten to be consistent
with modern PLplot, i.e., the new Fortran binding that has just been
implemented.
* The tclmatrix subchapter of the Tcl chapter has been rewritten
to be consistent with the recent tclmatrix changes (2.8).
* The previous chapter entitled "Notes for each Operating System that We Support"
has now been dropped since this material is already covered
in the introduction with reference to the wiki as appropriate
for platform details (see above discussion of the introduction).
Here are some additional significant updates to our documentation that
(unlike the changes above) did not constitute a complete rewrite.
* The Ada chapter has been updated to be consistent with the
recent Ada changes (2.7).
* The Tcl chapter as a whole has been updated to be
consistent with the recent redacted API change (2.9).
* A number of documentation improvements have been made to the common
API chapter. For example, the new self-describing names for PLplot
C argument types (see 2.19 and 2.20) are now used to document all
arguments which makes it much simpler to document those arguments.
Also, reference to those types now link to the appropriate part
of the C chapter which describes the PLplot types.
* An important short paragraph of text was inserted in the simple
usage, advanced usage, and common API chapters to clarify how the
API for all our supported languages corresponds with the
self-describing names for PLplot C argument types (see 2.19 and
2.20).
2.11 Default page sizes
We now provide two default page sizes for our device drivers. One for
drivers which have real world pages (e.g. the postscript driver) which
is specified in mm and one for drivers which use pixel pages (e.g. the
Cairo or the interactive drivers). The mm page size is A4 as this is
the most commonly used metric paper size used. The pixel size is
approximately A5 when scaled using the default 90 dpi. This was chosen
as it has the same aspect ratio as the mm size, but fits comfortably
on most computer screens. So far only the gd, cgm, and wxwidgets
device drivers use these defaults, but our eventual goal is that all
our device drivers will use these defaults for consistency between them.
2.12 Updated D language support
CMake-3.4.0 introduced a change in internal language support infrastructure.
Our D language support was changed so that it accommodated this change and
also still worked for older CMake versions.
2.13 Modernized build-system support for Qt4 and Qt5
The Qt4 support modernization consisted of moving from the old and rigid
QT4_WRAP_CPP method of applying moc to just qt.h and propagating those
results everywhere they were needed to the more flexible AUTOMOC approach
which allows us to choose (important!) what Qt header(s) to moc for each
library. This same approach is now also used for the Qt5 case.
The Qt4 CMake support is a responsibility of CMake developers, but the
Qt5 CMake support is the responsibility of Qt5 developers and is
entirely different (except for AUTOMOC) from Qt4 support. That
Qt5 CMake support is documented at <http://doc.qt.io/qt-5/cmake-manual.html>
and this PLplot release has moved from the deprecated qt5_use_modules method
to the latest method involving using aliased libraries called
Qt5::Svg, Qt5::Gui, and Qt5::PrintSupport in the appropriate
target_link_libraries command.
Our tests now show that as a result of these changes our build-system
support for Qt5 is now just as mature as for the Qt4 case. Our tests
also show the Qt5 library has matured (as of Qt5 version 5.3.2 from
Debian Jessie) somewhat in that the character alignment issues that
plagued us before are now gone. So there are no more ad hoc adjustments
of the character height to accommodate for the Qt5 character alignment bugs
so our qt device driver code now uses exactly the same code for Qt4
and Qt5.
Despite this encouraging recent alignment improvement, Qt5 is still
not nearly as mature as Qt4 according to our other tests. For our qt
device driver linked to Qt5 and according to the
-DVALGRIND_ALL_TESTS=ON cmake option, results for the test_pdfqt
target show severe memory management issues (invalid reads, etc.) for
all standard examples other than 0, 1, 3, 5, 10, 12, 13, 24, and 31.
(Presumably these inter-example differences in Qt5 memory management
issues are due to the different ways these examples use the Qt
libraries and thus find the memory management issues in those
libraries or not.) It is encouraging that there are no memory
management issues for some of our examples for qt linked to Qt5, but
when our qt device driver is linked to Qt4 instead (at least for the
Debian Jessie version 4.8.6) there are no memory management issues for
_any_ of the examples for the pdfqt device. We have not had time to
make similar comprehensive valgrind tests for all our examples for other
qt devices, but spot checks with valgrind indicate a consistent pattern
of severe memory management issues with Qt5 that just don't occur
for Qt4. Another memory-management issue that is likely related to Qt5
is we get a segfault when exiting from the pyqt5_example (which is
necessarily linked to Qt5) while we have no such issues with
pyqt4_example (that is necessarily linked to Qt4). A final issue
with Qt5 that we have noticed is our comprehensive test
of our qt device driver linked to Qt5 was twice (!) as slow as the
same test for our qt device driver linked to Qt4.
Because of these present Qt5 memory management and inefficiency
concerns, our build system currently prefers to use Qt4 if it can find
it, but automatically falls back to Qt5 otherwise. If for some reason
a user wants to avoid Qt4, then only Qt5 will be searched for and used
if they specify -DPLPLOT_USE_QT5=ON. (Note this important change in
the semantics of -DPLPLOT_USE_QT5=ON which in 5.11.1 was the only
(experimental) way users could link qt to Qt5.)
2.14 Implemented support for pyqt5
Because our build-system support for Qt5 has matured (although the Qt5
library has not matured yet in memory management and efficiency, see
comments above), we have also implemented support for pyqt5 when Qt5
is being used to link qt. Our tests using the test_pyqt5_example show
this support for pyqt5 has matured (other than the segfault issue at
exit from this GUI which we attribute to memory management issues in
Qt5). (Note our support for pyqt4 when Qt4 is being used to
link qt continues without known build or run-time issues.)
2.15 Addressed -DPL_DOUBLE=OFF issues
Our comprehensive tests of the single-precision version of the PLplot
libraries (built with -DPL_DOUBLE=OFF) demonstrated a substantial
number of issues that had accumulated since we last tested this
option. Those issues have now all been solved so that PLplot users
can be reasonably confident again about using the -DPL_DOUBLE=OFF
option if they so desire. However, it should be emphasized that the
-DPL_DOUBLE=ON case (which is the case users get by default) is the
case we test the most so that will almost always be the more reliable
option to use.
2.16 Replaced "Lena" with "Chloe"
The image we use to demonstrate and test our plimage capability has
been changed from "Lena" to "Chloe" because the licensing for the
former image (although used often as a test image by other software
projects) turns out to be not definite while the licensing for the
latter image is definite and gives us the freedom to modify and
redistribute that image. Also, I like that image of Chloe who is a
cute "Westie" (West Highland White Terrier) that reminds me of one of
my all-time favourite TV shows "Hamish Macbeth". :-)
2.17 Removed trailing blanks on most text files in our source tree
This was a massive and intrusive change to our source tree when we
first did this because years of neglect concerning this issue had left
trailing whitespace virtually everywhere which git constantly
complained about. From now on, our developers are encouraged to run
scripts/remove_trailing_blanks.sh to deal with this issue before each
of their commits. That script excludes all binary files following the
rules in .gitattributes concerning what constitutes a text file. In
addition some text files are excluded from trailing-blank removal
because they involve text that should be immutable (e.g., licensing
text, test text) that has trailing blanks. This script uses sed to do
the job so this script can only be run on systems that have sed
installed.
2.18 Make our wxwidgets find module consistent with the official version for CMake-3.7.1
That latest released version of the find module for wxwidgets is
actively maintained by the CMake developers so the latest version
available (from CMake-3.7.1) is likely to be the best version of this
find module. We therefore adopt that version (with one necessary line
change so we can use it for PLplot) for all our users regardless of
the CMake version they are using.
2.19 Introduction of two new generic pointer types to help protect against a planned future C API breakage
As a step toward our goal of achieving const correctness for PLplot we
have defined two new generic pointer types called PL_GENERIC_POINTER
and PL_NC_GENERIC_POINTER which are typedef'd and used in
include/plplot.h as the types for the generic pointers in our C API
with the former reserved for identifying generic pointer arguments
where the called routine guarantees to leave the object being pointed
to completely unchanged while the latter is used for those rare cases
when we cannot make that guarantee. (NC stands for "non const".) The
generic pointer type PLPointer is typedef'd in include/plplot.h for
those of our users who are still using it, but it is deprecated and
therefore unused in include/plplot.h.
The typedefs for these 3 generic pointers are currently the following:
typedef void * PL_NC_GENERIC_POINTER;
typedef void * PL_GENERIC_POINTER;
// Deprecated and only provided for backwards compatibility.
typedef PL_NC_GENERIC_POINTER PLPointer;
So all the above is backwards compatible with prior releases which
just typedef'd and used
typedef void * PLPointer;
However, for our next release we plan to change PL_GENERIC_POINTER as follows:
typedef const void * PL_GENERIC_POINTER;
which will help improve our const correctness but which will also
introduce a substantial backwards incompatibility into our C API.
To protect yourself against this planned future backwards incompatibility we recommend
you do the following:
Change the types of all your void * or PLPointer arguments for our C
API to PL_GENERIC_POINTER or PL_NC_GENERIC_POINTER as documented for
each of our functions in include/plplot.h and also at
<http://plplot.sourceforge.net/docbook-manual/plplot-html-5.12.0/API.html>.
This change means when we update the PL_GENERIC_POINTER typedef as above,
a recompilation of your code will be all that is required to deal with this issue.
We also recommend you drop use of the deprecated PLPointer type since
we plan to stop providing a typedef for that type sometime in the future.
2.20 Introduction of additional self-describing names for the types of arguments used in our C API.
These new self-describing type name are defined (in include/plplot.h) as follows:
// typedefs that are typically used for passing scalar, vector, and
// matrix arguments to functions. The NC attribute concerns pointers
// to mutable objects, where the objects are used for passing values
// that are either output only or both input and output. Pointers whose
// name does not contain the NC attribute point to immutable objects
// which are strictly input and guaranteed to be unchanged by the function.
//
// Pointers to mutable scalars:
typedef PLINT * PLINT_NC_SCALAR;
typedef PLBOOL * PLBOOL_NC_SCALAR;
typedef PLUNICODE * PLUNICODE_NC_SCALAR;
typedef char * PLCHAR_NC_SCALAR;
typedef PLFLT * PLFLT_NC_SCALAR;
// Pointers to mutable vectors:
typedef char * PLCHAR_NC_VECTOR;
typedef PLFLT * PLFLT_NC_VECTOR;
// Pointers to immutable vectors:
typedef const PLINT * PLINT_VECTOR;
typedef const PLBOOL * PLBOOL_VECTOR;
typedef const char * PLCHAR_VECTOR;
typedef const PLFLT * PLFLT_VECTOR;
// Pointers to mutable 2-dimensional matrices:
typedef char ** PLCHAR_NC_MATRIX;
typedef PLFLT ** PLFLT_NC_MATRIX;
// Pointers to immutable 2-dimensional matrices,
// (i.e., pointers to const pointers to const values):
typedef const char * const * PLCHAR_MATRIX;
typedef const PLFLT * const * PLFLT_MATRIX;
// Callback-related typedefs
typedef void ( *PLMAPFORM_callback )( PLINT n, PLFLT_NC_VECTOR x, PLFLT_NC_VECTOR y );
typedef void ( *PLTRANSFORM_callback )( PLFLT x, PLFLT y, PLFLT_NC_SCALAR xp, PLFLT_NC_SCALAR yp, PL_GENEIC_POINTER data );
typedef void ( *PLLABEL_FUNC_callback )( PLINT axis, PLFLT value, PLCHAR_NC_VECTOR label, PLINT length, P_GENERIC_POINTER data );
typedef PLFLT ( *PLF2EVAL_callback )( PLINT ix, PLINT iy, PL_GENERIC_POINTER data );
typedef void ( *PLFILL_callback )( PLINT n, PLFLT_VECTOR x, PLFLT_VECTOR y );
typedef PLINT ( *PLDEFINED_callback )( PLFLT x, PLFLT y );
For this release we have only partially propagated the use of these
self-describing names for PLplot C argument types to our core C
library, device drivers, our bindings implemented in C, our C++
binding, and the C and C++ examples, but we plan to address that
propagation issue in the next release. Meanwhile these type names are
extremely useful for helping to document our bindings and common API,
see 2.10.
2.21 Implement submission of dashboards to the <my.cdash.org> cdash server
CMake users who want to help with testing PLplot on Unix-like Windows
platforms such as Cygwin or MinGW-w64/MSYS2 or on the usual Unix
platforms such as Linux or Mac OS X can now submit dashboards (defined
as a collection of data associated with a given ctest run in a
standard form) to the <my.cdash.org> cdash server where it is publicly
displayed using a nice format at
<http://my.cdash.org/index.php?project=PLplot_git>.
Such dashboards should be submitted using, e.g.,
cmake -DBUILD_TEST=ON -DPLPLOT_BUILDNAME_SUFFIX:STRING="-shared library + dynamic devices" ....
#N.B. the all target must always be built before ctest is run
make -j4 all
ctest -j4 -D Experimental
The -DPLPLOT_BUILDNAME_SUFFIX:STRING option is not necessary, but the
string specified with that option is appended to the "Build Name"
field displayed by the cdash server so it helps PLplot users to
identify the broad configuration of the type of build that was used to
submit a dashboard.
If the user specifies the
--do_submit_dashboard yes
option for the bash script,
scripts/comprehensive_test.sh,
then the above tests to submit a dashboard will occur for each ctest
command (typically for (1) shared library + dynamic devices, (2)
shared library + nondynamic devices, and (3) static library +
nondynamic devices) that is run by that script and with
-DPLPLOT_BUILDNAME_SUFFIX:STRING automatically set appropriately for
each dashboard submission generated by the script.
2.22 Substantial update and rename of the Python examples
All python modules and scripts in example/python were converted to the
namespace form, e.g.,
from plplot import *
was replaced by
import plplot as <some namespace>
where "<some namespace>" is typically "w" for historical reasons.
This change removed the fundamental difference between the set of
well-maintained xw??.py standard examples and the original
badly-maintained and incomplete set of standard examples that were
called x??.py. So we removed all those badly maintained versions and
renamed xw??.py as the corresponding x??.py.
This rename, some work on examples/python/pytkdemo, and a large amount
of generic work on bindings/python/Plframe.py to add the necessary
PLplot API to run the revitalized x??.py examples means
examples/python/pytkdemo (previously crippled by using the old buggy
version of the x??.py examples) is working reliably for the first time
ever. In fact it is so reliable we routinely add the new
test_pytkdemo target to the dependencies of the generic
test_interactive target which is reserved for just running the
interactive test targets that are reliable.
2.23 Linux efficiency improvements for the wxwidgets device
The speed of the Linux wxwidgets device (N.B. note the
time required by wxPLViewer is not counted in any of these comparisons)
was not in a good state for PLplot-5.11.1; slowdowns of a factor of two
compared to the qtwidget and xcairo devices were typical while in some cases
the slowdown ranged up to two orders of magnitude! That latter problem
turned out to be due to our use of the blocking /dev/random device
to choose the seed for the random names chosen for the shared memory
areas used for IPC between -dev wxwidgets and wxPLViewer, and the simple fix
(discovered quite recently) was to preferentially use the non-blocking
/dev/urandom instead! In addition many other changes have been
made to both -dev wxwidgets and wxPLViewer to improve their joint
efficiency since the release of PLplot-5.11.1. A recent detailed experiment
showing real times required to complete examples showed
the following count results for which of the three devices was the fastest
for each of the 27 standard examples that were run for this test:
qtwidget 10
xcairo 08
wxwidgets 09
In none of these 27 standard examples is -dev wxwidgets slower than
the best of the other two by a factor of two or more. And -dev
wxwidgets is actually the best of the three devices for a 3rd of these
examples. So -dev wxwidgets is clearly comparable in speed to the
other two for most of our examples. However, the above 27 standard
examples did not include examples 8, 25, and 33 which all notoriously
have extremely large numbers of graphical elements. I just ran
comparisons for examples 8 and 25 (because 33 takes too long even when
it is efficient), and in those two cases the wxwidgets slowdown factor
compared to the best of the other two devices is respectively 16 and
8! So clearly there is still some large bottleneck in efficiency for the
combination of -dev wxwidgets and wxPLViewer that shows up
particularly strongly when there are large numbers of graphical
elements. We hope to deal with that issue for our next release, but
clearly for this release Linux -dev wxwidgets users are going to be
much better off in the efficiency department than they were for
PLplot-5.11.1.
________________________________________________________________
3. PLplot testing
Comprehensive tests of this release are documented in
<http://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
and
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Fortran%20Testing%20Reports>.
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 89873fe451838fc7661097d06d58a5880c05af7d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 28 17:37:45 2017 -0800
Add some minor additional information to the release manager's cookbook
M README.Release_Manager_Cookbook
commit 9f01349ab38d1520b63bf96cd8c83e08eb9c61c9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 28 17:11:14 2017 -0800
Build of doxygen-generated documentation: drop call/caller graphs
It turned out these graphs increased the release tarball size from
16MB to 567MB! Which is completely unacceptable. Also, it is far
from clear how useful these graphs are to developers because of their
huge complexity. So drop those graphs completely at least for now
(with the additional benefit that the doxygen documentation build time
is greatly reduced by this change).
M doc/Doxyfile.in
commit 816448262f47be3eb210eb1ee2a79399c8630746
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 28 12:32:13 2017 -0800
Build system: implement and use PREBUILT_DOX_DOC option
This option plays the same role for doxygen documentation as the
PREBUILT_DOC option plays for the DocBook documentation.
Those using a tarball with prebuilt doxygen documentation should use
this option to allow use of that documentation (e.g., installation of
it) just as if it was built as part of the build process. So, for
example, we use this option when testing installation of a release tarball
in the make_tarball.sh script.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
scripts/make_tarball.sh -c -i /tmp/plplot_install
and checking the doxygen build when creating the tarball
and checking the doxygen install from the prebuilt
doxygen documentation in that tarball.
M cmake/modules/doxygen.cmake
M doc/CMakeLists.txt
M scripts/make_tarball.sh
commit 255f468bc9337deec0b79f1ae606e6fe0b1305f5
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 28 12:02:16 2017 -0800
Build system: make build_doxygen target depend on plplotqt
This dependency is added so that doxygen can analyze the automoc-generated
files associated with the plplotqt library.
M doc/CMakeLists.txt
commit 7f88cd9a193daf3d387188dfeb13e5bb66417ba6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 28 00:29:31 2017 -0800
Update the release manager's cookbook
As far as I can tell, this cookbook is completely up to date now
for this forthcoming plplot-5.12.0 release including how to make a signed tagged release,
but if I run into any issues following the rest of this cookbook, I will likely
need to update this file again for the release.
M README.Release_Manager_Cookbook
commit 1486ce821e28140b04a4daf75648589635e44269
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 28 00:20:33 2017 -0800
Fix website generation script
The issue was no bindings or devices were allowed for the
documentation build, and this interfered with the bindings
dependencies for the doxygen build. When this issue was
addressed a warning about the Tcl bindings missing some generated files
for doxygen analysis was removed.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
echo irwin$'\n'irwin$'\n'raven$'\n'/home/irwin/public_html/plplot$'\n'yes |scripts/generate_website.sh
and looking carefully at all warnings and 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|Generating call.*graph for function'
M scripts/generate_website.sh
commit 227ffbc627447e28268277f107a3b2b724a75671
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 27 21:43:02 2017 -0800
Build system: corrected the python-related dependency of doxygen documentation build
Changed the build_doxygen target dependency from _plplotcmodule to _plplotcmodule_fixed.
M doc/CMakeLists.txt
commit f848347401cfce09e028cb8887d75bf520131b70
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 27 21:40:22 2017 -0800
doxygen documentation build: exclude non_redacted Tcl/Tk-related files
M doc/Doxyfile.in
commit 4eed3fc09d76410ea179b94240a08978dbc51469
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 27 16:38:09 2017 -0800
Update the release notes concerning the DocBook documentation rewrite that has been completed
M README.release
commit 3e8eb0ba2083dc4786baa0503a29929cdbfc5947
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 27 14:22:41 2017 -0800
Make api2man.pl.in template for perl utility script produce results without trailing blanks
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by using the cmake -DBUILD_DOC=ON option,
building the man target, and checking all results for trailing
blanks using
grep -l ' $' doc/docbook/src/*.3plplot
I also spot checked some of those generated man results using
nroff -man doc/docbook/src/<PLplot command name>.3plplot |less
All was well except for a long-standing problem with the pages
(plsurf3dl.3plplot, plot3dcl.3plplot) with UTF-8 characters where
nroff on Debian Jessie still has troubles rendering those UTF-8
glyphs. However, if you set up the appropriate symlinks, the
equivalent man command works fine for those pages, i.e., the bad
rendering of UTF-8 glyphs appears to be an nroff bug.
M doc/docbook/bin/api2man.pl.in
commit e174355d8cb95eec1cd1048dccf6d96a845a6aff
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 27 13:14:49 2017 -0800
swig-generated octave and python bindings: update documentation strings to be consistent with api.xml
I generated this change as follows: I built the
check_swig_documentation target which uses the recently updated
api2swigdoc.pl perl script to generate from api.xml a check file
bindings/swig-support/swig_documentation.i_compare (without trailing
blanks) in the build tree and then compares that result with
bindings/swig-support/swig_documentation.i in the source tree. That
comparison initially failed (i.e., swig_documentation.i was not
consistent with api.xml). I addressed that issue (after spot-checking
swig_documentation.i_compare) by copying swig_documentation.i_compare
in the build tree on top of swig_documentation.i in the source tree.
This change effectively updates the python and octave documentation
strings to be consistent with api.xml.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_diff_psc target and also
by following the test procedures for both python
and octave help strings given in doc/docbook/README.developers.
M bindings/swig-support/swig_documentation.i
M doc/docbook/README.developers
commit cde5d9bc416e4073c87b99f596b2ef8ffbef65a4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 27 13:09:11 2017 -0800
Make api2swigdoc.pl perl utility script produce results without trailing blanks
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the check_swig_documentation target and
checking the resulting check file,
bindings/swig-support/swig_documentation.i_compare has no trailing
blanks.
M doc/docbook/bin/api2swigdoc.pl
commit f00bb8e5eff3da51fe64d77004d12cebe4353fc5
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 27 00:37:52 2017 -0800
Build system: temporarily remove the check_all target dependency on check_api_xml_consistency
The issue is the check_api_xml_consistency target has run-time issues
when attempting to generate its check file (using the golang check
routine). I attribute this issue to the massive api.xml and plplot.h
changes that have occurred since plplot-5.11.1 (where the
check_api_xml_consistency worked), and some significant go language
changes to the externally developed golang check executable will have
to be made to get this to work again or else this whole consistency
checking between api.xml and plplot.h needs reimplementation using a
perl script. Until one of these possible fixes are made, remove the
check_all target dependency on check_api_xml_consistency so that
the check_all target will continue to work.
M doc/docbook/src/CMakeLists.txt
commit 759bee9c87e4040139d72bb276aab11d8b4efbd8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 27 00:33:09 2017 -0800
Build system: temporarily remove the check_all target dependency on check_plplot_h.inc
The issue is that check_plplot_h.inc now encounters run-time issues when attempting
to generate its check file using ocaml. This is likely due to a namespace
or installation issue with ocaml. Until this issue is fixed, remove the
check_all dependency on check_plplot_h.inc so that check_all will continue to work.
M bindings/ocaml/CMakeLists.txt
commit e98cb2b20abf1071040d1eb4385cc9cb0cf398be
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 27 00:23:34 2017 -0800
api2swigdoc.pl utility: update entity processing
I followed here the recently updated entity processing
in api2man.pl.in.
This change allowed the script to work again for
the modern form (with much more entity use) of api.xml.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by using the cmake option DADD_SPECIAL_CONSISTENCY_CHECKING=ON
and building (without run-time errors when generating the check file) the check_swig_documentation
target. The comparison check file was different from the original and
diff showed at least some of those differences were trailing blank issues
introduced by the script which will have to be taken care of in a subsequent commit.
M doc/docbook/bin/api2swigdoc.pl
commit 7710523a12356831ecb80aa4ed6a6da07a350b15
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 26 22:06:28 2017 -0800
DocBook documentation: tweak testing instructions for the documentation build
M doc/docbook/README.developers
commit 78e268691015bcf3a72321bdbca5edfb93bd9630
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 26 22:03:23 2017 -0800
DocBook documentation: update timestamp for the documentation to 2017-01-28
That date (two days from now) is the current ETA for the 5.12.0 release.
M doc/docbook/src/CMakeLists.txt
commit 6e4eedbf494a27cb01687c0b3bb497a8724d9472
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 26 19:09:06 2017 -0800
Doxygen-generated documentation: Tweak configuration to avoid doxygen error and reduce doxygen warnings
Excluded more files, i.e. the configured fortran included file that was causing an
error, all java files (which were generating lots of warnings), bindings/python/Plframe.py
that was causing a warning, and a deprecated
wxwidgets file that we wanted to exclude for consistency with the
exclusion of the other deprecated wxwidgets files although it didn't appear
to cause any trouble.) I also raised DOT_GRAPH_MAX_NODES from the default 50
to 1000 which removed a lot of warnings.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by using the cmake parameter -DBUILD_DOX_DOC=ON and
building the build_doxygen target. As a result of the above changes there
were no errors, and the warnings were reduced to
Warning: doxygen no longer ships with the FreeSans font.
/home/software/plplot/HEAD/plplot.git/bindings/d/plplot.d:18: warning: no matching class member found for
/home/software/plplot/HEAD/plplot.git/bindings/d/plplot.d:19: warning: no matching class member found for
AFAICT, that FreeSans warning is a false alarm from doxgyen since
presumably doxygen can use system fonts, and the Debian package
"fonts-freefont-ttf" has been installed which contains
/usr/share/fonts/truetype/freefont/FreeSans.ttf.
Furthermore, the last two D warnings are also apparently false alarms
caused by bad doxygen parsing of D aliases that makes the incorrect
assumption that two different D aliases cannot refer to the same
thing.
M doc/Doxyfile.in
commit 976b30798085f2d55639155b428728c95c51abab
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 26 17:49:52 2017 -0800
Update version information for the release of 5.12.0
I looked at the backwards-incompatibility comments in our release
notes as well as "git diff" results for various library source code
directly locations within our source tree in order to determine the
correct major=SOVERSION, minor, and patch subfields for our various
library versions according to the library versioning rules in
cmake/modules/plplot_version.cmake.
M README.Release_Manager_Cookbook
M cmake/modules/plplot_version.cmake
M www/examples.php
commit 9882da7bdda4955263d35b80c820abafeb4e4c70
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 26 16:03:45 2017 -0800
DocBook documentation: substantial update to advanced usage chapter
The summary of changes is as follows:
* All references to examples are now linkable and point to our
website examples (which give source code in all our supported
languages as well as results).
* Update the list of command-line options
* To make this chapter much less specific to C, replace all C code
fragments by references to the appropriate (linkable) examples.
* Explain why the (pl)freetype approach is deprecated and because of
that deprecation drop all the details concerning how that approach
is implemented.
* Rewrite/simplify the viewport, window, viewport annotation, and standard viewport sections
* Rewrite/simplify the color section
* Rewrite/simplify the 3D plotting section.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) using the cmake option -DBUILD_DOC=ON and by building
(without any obvious issues) the build_docbook_documentation target
(which builds the man, info, pdf, and html forms of the
DocBook-generated documentation).
M doc/docbook/src/advanced.xml
commit 2f38bbbf2f2ae669ff45fb9992dc7f9edbc83775
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 26 15:56:07 2017 -0800
DocBook documentation: Update simple use chapter
This update made references to the examples linkable. There
were some writing tweaks as well.
M doc/docbook/src/simple.xml
commit dd3474818f991908b024a1d93821e7d1597c8ebb
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 26 15:54:19 2017 -0800
DocBook documentation: improve descriptions of our API.
M doc/docbook/src/api-c.xml
M doc/docbook/src/api-obsolete.xml
M doc/docbook/src/api.xml
commit 8523bc4cb97dcaf842b4a5104cc58a3b5c35cd9d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 26 15:52:03 2017 -0800
DocBook documentation: Add some needed entities
M doc/docbook/src/plplotdoc.xml.in
commit 3070ae21fc5256af9f4b839d256f80d703728e8b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 26 14:29:56 2017 -0800
DocBook documentation; Ada chapter spelling tweaks
pre-installed ==> preinstalled
pre-built ==> prebuilt
M doc/docbook/src/ada.xml
commit ed5740b3cb040c6498a81090edfb82196e2a8c4a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 26 14:25:22 2017 -0800
Documentation build: man pages fix
Added "le" entity that is defined the same way as the existing
"leq" entity. This change allows us to use the "le" and "leq"
entities interchangeably in the documentation of our common API
(api.xml).
M doc/docbook/bin/api2man.pl.in
commit 946a9dcdb517879e7693de374994fa9f23ab2d55
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 12 15:39:04 2017 -0800
DocBook documentation: minor cleanups
Got rid of trailing whitespace issues for api.xml and tcl.xml
and fixed copyright date issues for intro.xml and tcl.xml.
M doc/docbook/src/api.xml
M doc/docbook/src/intro.xml
M doc/docbook/src/tcl.xml
commit bca95f6220558032bbd63a197f7fab11c8682486
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 12 14:11:00 2017 -0800
DocBook documentation: Remove detailed API discussions from the "Simple Use of PLplot" chapter
Detailed discussion of the API is the job of the "The Common API for
PLplot" chapter. So repeating this information in other chapters is
unnecessary and leads to maintenance issues. Instead, a simple
cross-reference to the appropriate API is the correct thing to do in
other chapters, and this commit implements that idea for the
"Simple Use of PLplot" chapter.
M doc/docbook/src/simple.xml
commit 9f402b73a676709c6abcf593f10faf87d5decc25
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 12 10:47:41 2017 -0800
DocBook documentation: update configuration of tables generated in html.
M doc/docbook/src/plplotdoc-html.xsl.in
commit da23200cec374d11e5be1b499e10d23de12dd98c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 12 10:05:09 2017 -0800
A substantial update to the DocBook documentation
* The list of C typedefs used by PLplot has been updated in the C chapter.
Also this chapter and the entities described in plplotdoc.xml have
been updated so that all PLplot C types are linkable now (see the
api*.xml changes below to take advantage of that capability).
* The Fortran chapter has had a small update.
* An important short paragraph of text was inserted in the simple,
advanced, and api chapters to clarify how all our supported
languages correspond with the C API, and corresponding C types that
are often used in those chapters.
* The "Drawing points" section of the simple chapter has been
rewritten to emphasize plstring and to drop discussion of the
detailed syntax (which is the job of the api chapter).
* The advanced chapter has been substantially updated.
+ Tables of the file and interactive devices have been completely updated.
+ Dropped emphasis on plmeta and plrender since those are deprecated until
Jim fixes them.
+ Substantial update of 3D plot descriptions.
* The file devices chapter has been substantially updated.
* The interactive devices chapter has been substantially updated.
* The PLplot Tcl Matrix Extension section of the Tcl chapter has been
rewritten to describe the new matrix slice, initialization, and
assignment capabilities.
* The "Common API for PLplot" chapter (api.xml) and "The Specialized
C/C++ API for PLplot" (api-c.xml) chapters have been substantially improved. In
particular, the new typedef'd arguments for our API (including C
callback function types) are now used to document all arguments.
This makes it much simpler to document those arguments in a way that
is much less C specific which in turn makes it easier for users to
infer the argument types to be used for the other languages we
support.
Further details of api.xml and api-c.xml changes:
+ sed converted everything with const attribute (which turned
out to be *_MATRIX and *_VECTOR arguments).
+ Followed up by looking at language following each *_MATRIX and
*_VECTOR argument and replace "pointer", "array" or "grid"
references by "character string", "vector of character strings",
"vector", or "matrix" as appropriate.
+ sed processed lists of examples to be in standard list form, e.g., a
blank after every comma, "and" before the last instance, and drop
the comma when there are only two examples in the list.
+ Systematically used the ascii or UTF-8 adjective as appropriate
when referring to character strings.
+ Updated the descriptions of PLTRANSFORM_callback arguments in a
uniform way for plcont, plimagefr, plshades, plshade, plshade1,
and plvect. Also, update the description of the
PLTRANSFORM_callback argument in plstransform.
+ Reviewed all use of void * and PLPointer and replace with
PL_GENERIC_POINTER (usually) or PL_NC_GENERIC_POINTER (rarely) as
appropriate.
+ PLFLT * -> PLFLT_NC_SCALAR and reviewed associated text.
+ PLINT * -> PLINT_NC_SCALAR and reviewed associated text.
+ PLBOOL * -> PLBOOL_NC_SCALAR and reviewed associated text.
+ PLUNICODE * -> PLBOOL_NC_SCALAR and reviewed associated text.
+ char * -> PLCHAR_NC_VECTOR and reviewed associated text.
+ C-specific plshade1 and plfsurf3d documentation moved from api.xml
to api-c.xml.
+ Cross-language plGetCursor documentation moved from api-c.xml to
api.xml.
+ Tracked down the remaining references to the indirection C
operator * and reduced those as much as possible using our
typedef'd types.
+ Tracked down the remaining references to the extended regexp
'[vV]ectored|[aA]rray|[pP]ointer|[Nn]ull-terminated' and reduced
those as much as possible.
+ Made C argument types linkable and linked to those types in
api*.xml for the specific case where the type of argument is
given.
M doc/docbook/src/advanced.xml
M doc/docbook/src/api-c.xml
M doc/docbook/src/api-fortran95.xml
M doc/docbook/src/api-obsolete.xml
M doc/docbook/src/api.xml
M doc/docbook/src/c.xml
M doc/docbook/src/drivers.xml
M doc/docbook/src/fortran95.xml
M doc/docbook/src/plplotdoc.xml.in
M doc/docbook/src/simple.xml
M doc/docbook/src/tcl.xml
commit 488a785ff645f33080801ae00e0c25c0a6c81738
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jan 8 12:36:05 2017 -0800
DocBook documentation: Update instructions for documentation developers
The section concerning test results was changed in recognition of the
fact that konsole (the KDE terminal emulator that uses client-side
system fonts where glyphs are selected by font-config) yields
essentially perfect UTF-8 test results for info pages. This is a huge
improvement compared to the missing Mandarin, Korean, and Devanagari
(Hindi script) glyphs and the glyph rendering in the wrong order for some
CTL languages that you get with xterm (the X terminal emulator that
uses server-side X fonts without the benefit of font-config).
M doc/docbook/README.developers
commit da56d5d180862b28a542b6e5e0cdd0ea832817b5
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jan 8 12:33:35 2017 -0800
DocBook documentation: update html configuration
Change html style so that first sections in a chapter are treated as other
sections in that chapter rather than being jammed in on the page
with the introductory paragraph(s) for the chapter.
M doc/docbook/src/plplotdoc-html.xsl.in
commit 4d8dad6cae746b23901618b2772ffff09009f84a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jan 8 12:31:40 2017 -0800
DocBook documentation: Update script for generating man pages
Add entities from MASTER = plplotdoc.xml that start with the letters "PL" in
anticipation that those entities will be needed in the future to
refer to PLplot types such as PLFLT when generating man pages
from api.xml.
M doc/docbook/bin/api2man.pl.in
commit d983e753b084b414d56cc801e24c06116e91ce37
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Fri Jan 6 11:42:54 2017 +0100
Minor textual and format changes to the text.
Tested (proof-read) by Arjen Markus (arjenmarkus@users.sourceforge.net)
I corrected a typo and simplified a sentence that I thought was confusing. Some limited reformatting of the text.
M README.release
commit a809aa8fea1273b623f5fb05362e6dbd6141c7e9
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Jan 5 14:40:34 2017 +0000
Fixed text transform issues in wxWidgets when not using
wxGraphicsContext transforms
The wxWidgets driver uses a number of systems to transform text. Some
wxDCs support transforms, if so these were used. Up until recently
wxGCDC did not support transforms, but the underlying wxGraphicsContext
does, so these were used where needed. If neither of these options was
possible then we just do simple translate and rotate transforms.
Unfortunately ony the wxGraphicsContext code was regularly checked as
wxGCDCs are used by wxPLViewer and much other display code.
In the very recent past (during wxWidgets 3.1 development) wxGCDC
started supporting wxDC transformations and the plplot driver logic was
arrange such that they were used. This exposed a bug in the use of those
transforms. Further investigation revealed a bug in the simple translate
rotate code, including a logic bug that meant this code was only used
pre wxWidgets 29.0.2 and a syntax error that meant this code actually
didn't compile pre wxWidgets 29.0.2!
This commit fixes the logic and compilation bugs that existed in the use
of the transformations.
It also reorders the if statements and the way that the code checks for
a wxGCDC. This makes it clearer that in the case where wxGCDCs now
support wxDC transformations it is these transformations that will be
used.
It should also be noted that at some point if we bump the minimum
wxWidgets version to 3.2 (once this version gets released) then we
should be able to ditch all wxGCDC specific code.
Code tested on Windows.
M drivers/wxwidgets_dev.cpp
commit 5f6bc7efe9c1dbb23f627d69900ff32818076260
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Jan 5 13:16:14 2017 +0000
Restyle only commit
M bindings/wxwidgets/wxPLplot_nanosec.cpp
M bindings/wxwidgets/wxPLplotwindow.h
M drivers/wxwidgets_dev.cpp
M examples/c++/wxPLplotDemo.cpp
M include/plplot.h
commit 4ce762b8a43346c709be2c7d13739df9973ea0ac
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Jan 5 12:39:55 2017 +0000
Edited second example frame in wxPLplotDemo
Just added a different curve and changed some colours, just to make the
second plot look different and show how to adjust the background colour.
M examples/c++/wxPLplotDemo.cpp
commit 16698e80df63aec49adbc15c8e5783cb4dff89c5
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Jan 4 13:51:12 2017 +0000
Fix infinite yield issue in wxPLplotDemo
It turns out that on Linux (I think all systems, not just with remote
X11 servers) the wxEVT_CREATE event is not triggered until after Show()
is called. This was causing an infinite loop while the code repeatedly
called Yield to wait for this event before calling Show().
Provided two separate windows in the example now showing two ways to do
this properly. One is using inheritence and having a class which catches
wxEVT_IDLE events, checks if the window is ready and then does the
plotting. The second does not use inheritance, but just has to make sure
that Show() is called, followed by some waiting and Yielding (probably
only needed for remote X11 servers) before we attempt to do any
plotting.
M examples/c++/wxPLplotDemo.cpp
commit 8879fcf3e5f96b7959292190a4a96530c5f45128
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Dec 29 17:08:47 2016 -0800
Core library: add to C types that are typedef'd
The new typedefs are
typedef PLFLT * PLFLT_NC_FE_POINTER;
typedef const PLFLT * PLFLT_FE_POINTER;
That is they are additional typedefs for "PLFLT *" and "const PLFLT *"
that are reserved for use in the special situation when those types
are used as pointers to the first element of contiguous potentially
multi-dimensional arrays.
Since these changes constitute just a relabelling for this particular
use case, there should be no effective code changes associated with this
commit. Nevertheless, I test it below for typographic errors.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_diff_psc target with no
obvious configure, build, or run-time errors and with no regressions in
the PostScript differences.
M include/plplot.h
commit c27eff0f834de62e2666c325c2841bd8c564392f
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Thu Dec 29 12:08:43 2016 +0100
Add convenience batch file for running the examples under bare Windows
Tested by: Arjen Markus (arjenmarkus@users.sourceforge.net)
Due to the lack of sufficiently popwerful tools in the Windows environment (the Windows powershell might provide the tools that are required, but I do not know enough about it for an implementation) the automated testing on this platform is limited. To help with this I have written a small batch file and a dedicated comparison program.
The idea is simple: run the examples for the various programming languages and compare the output files. It presumes that the examples have been built already, so it does not test anything else than the build that is present.
To compare the files I wrote a small dedicated C program - experiments with the diff command from MinGW-w64/MSYS2 failed, as it appears you cannot run such programs outside the MinGW-w64/MSYS2 shell (merely setting the path is not enough).
To use it: go to the top-most directory holding the built examples (that is, the directory with subdirectories like bindings, examples, dll, ...) and run the script "run_examples_windows.bat". That is it. Redirect the output for later inspection.
Note: it is a fairly simple script - it assumes that all executable programs whose name start with an "x" are PLplot examples with C equivalents. Some experimental programs are present, however, for instance x01cc.exe, so that the comparison program fails to compare the right files. Ignore the resulting false messages.
A scripts/compare.c
A scripts/run_examples_windows.bat
commit 26bc4bf13aa41dff0e19345e982eca00a0458578
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 24 14:32:48 2016 -0800
Apply spell checker to release notes
M README.release
commit dd178fd84c8e67e6c26c6248dc428d8302a0b744
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 24 14:04:09 2016 -0800
Update the release notes for 5.12.0
N.B. The ChangeLog consisting of all the commit messages for the ~400
commits that are included in this release has been reviewed to help
insure that these release notes mention all the major PLplot
developments that have occurred for this release. So virtually all
sections of these release notes should be ready for release. However,
my work on the large documentation update is still in progress so that
section of these release notes will likely require further revision.
M README.release
commit 995e75e6086caaf04d65c307612b6edaa49f96bc
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Dec 20 13:33:43 2016 +0000
Made some items clearer in the wxWigdets Demo
The checking for whether the create event has been processed has been moved to directly
after the Create() function call. Some extra comments have been added around that section of
code to explain what is happening.
M examples/c++/wxPLplotDemo.cpp
commit 65e7b3c99809aaa490b928679bd3f3ff2f0c51a9
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Dec 19 13:50:04 2016 +0000
Fix bug with plotting in wxPLplotDemo
On most systems it seems that when wxWindow::Create() is called that
triggers a create event, but within the Create() function the event loop
is checked and the create event is processed immediately and OnCreate()
is called setting up the wxPLplotstream. This means we can begin using
the wxPLplotstream immediately after the call to Create().
However on some systems the create event is not processed immediately.
This has been observed on some Linux systems but apparently
identical systems seem to have different behaviour. The cause of this is
not clear.
To deal with this we now check the wxPLplotwindow is ready and wait for
it if not, yielding to allow the create event to be processed. Another
option might be to catch idle events and each time check the window is
ready then do the plotting at this point. However this is a more complex
proceedure and it would partly obfuscate what should be a simple
example.
M examples/c++/wxPLplotDemo.cpp
commit 67ef7be48217c098ae49bb893df5e170c3eccc2c
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Dec 19 13:44:02 2016 +0000
Added a function to check if the window is ready to accept plot
commands.
This function calls GetStream() to get a pointer to the wxPLplotstream
and checks if this pointer is NULL as a method for checking if
everything is ready to accept plot commands. This method is then used
internally in a few locations to check if things are ready in OnMouse
and OnPaint. Performing these checks implies that it is possible for a
paint or mouse event to be generated before a create event. I'm not sure
if this is the case, but the wxWidgets docs are a bit vague so there is
no harm in using the checks.
M bindings/wxwidgets/wxPLplotwindow.h
commit bf79603f136e2e5799191e387044b927faa007f0
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Dec 19 11:14:54 2016 +0000
Revert "wxwidgets binding: workaround fix for delayed OnCreate event"
This reverts commit e5b7485290a3d5d65b0be1b8037e56441b71d891.
This fix works for the specific example, but we need something more
general.
M bindings/wxwidgets/wxPLplotwindow.h
commit c111bad6ed0fef26bdd2bc34b4b4be188e3bda1e
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Dec 19 11:13:36 2016 +0000
Revert "wxwidgets binding: modification of workaround fix for delayed OnCreate event"
This reverts commit 786ff045d1b28db848222e66e47b6349d4aabb52.
This workaround works in this specific case, but we need to do something
more general.
M bindings/wxwidgets/wxPLplotwindow.h
commit ca58e7cbe959504c59a22e0b482c3c7fc826f821
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Dec 20 00:27:27 2016 +0000
Use /dev/urandom in preference to /dev/random in wxWidgets driver.
The wxWidgets driver needs to create a random name for a memory map to
avoid name clashes with concurrent instances. The seed for the random
number generator was created from /dev/random, however this blocks and
caused up to a 1-15 second delay in some instances while waiting for
entropy. Swap to using /dev/urandom when possible which is not as
random, but suits our needs and does not block.
M drivers/wxwidgets_dev.cpp
commit 1ccbdcd1c376075da8ef474a4f88e6cc09516a89
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 19 16:00:42 2016 -0800
Build system: fix build bug for (default) -DPLPLOT_WX_DEBUG_OUTPUT=OFF and also fix install bug
For my recent fix for the combination case of (-DPLPLOT_WX_DEBUG_OUTPUT=ON
-DPLPLOT_WX_NANOSEC=OFF) I forgot to test the
-DPLPLOT_WX_DEBUG_OUTPUT=OFF case which also had some build-system errors.
Those errors are now fixed as well as another recently introduced
build-system error where the install target failed because the generated
header, bindings/wxwidgets/wxPLplot_nanosec.h in the build tree, was
incorrectly identified has being in the source tree.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running three different comprehensive tests
time (nice -19 scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -DENABLE_cxx=ON" --do_test_noninteractive no --do_ctest no)
time (nice -19 scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -DENABLE_cxx=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON" --do_test_noninteractive no --do_ctest no)
time (nice -19 scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -DENABLE_cxx=ON -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON" --do_test_noninteractive no --do_ctest no)
to test all combinations of PLPLOT_WX_DEBUG_OUTPUT and
PLPLOT_WX_NANOSEC for the wxwidgets device and binding. There were no
obvious, configuration, build, or run-time issues with any of these
tests.
M bindings/wxwidgets/CMakeLists.txt
M drivers/CMakeLists.txt
M src/CMakeLists.txt
commit 946b17fba9982e4c11cfa2d5dfeb0d1ff040ef5f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 19 11:59:10 2016 -0800
Build system: fix build bug for combination -DPLPLOT_WX_DEBUG_OUTPUT=ON and (default) -DPLPLOT_WX_NANOSEC=OFF
I needed to tweak the Boolean logic for setting the
INCLUDE_DIRECTORIES property for the wxwidgets target and
(when ENABLE_DYNDRIVERS OFF) the plplot target.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building (both for the cases when
ENABLE_DYNDRIVERS=ON and OFF) the x01c, wxwidgets (when
ENABLE_DYNDRIVERS=ON), and wxPLViewer and test_wxPLplotDemo targets and then running
time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c -dev wxwidgets -np;echo "done x01c"
Unfortunately, the pause issue is still there in all cases, and
mousing around (to increase entropy to test Phil's hypothesis for this
bug) does not appear to make any difference at all.
But at least the build bug reported by Pedro has been fixed!
M drivers/CMakeLists.txt
M src/CMakeLists.txt
commit af417651da9a130c050392a1cbdb362a4a609f82
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 19 03:25:16 2016 -0800
Implement wxwidgets device driver debug output using the PLPLOT_wxLogDebug macro
I used the same useful PLPLOT_wxLogDebug macro that was just implemented
to output wxwidgets debug information, but complications (since the wxwidgets device driver
does not link to the plplotwxwidgets library) were to conditionally
add the bindings/wxwidgets/wxPLplot_nanosec.cpp code to
the source code for the wxwidgets device driver (or the plplot library
if ENABLE_DYNDRIVERS is false) and #include the configured header
bindings/wxwidgets/wxPLplot_nanosec.h in the build tree.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by using the cmake options
-DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON
(the second one of those options is experimental and also optional) to
configure the debug output from the PLPLOT_wxLogDebug macro. I made a
number of tests by inserting PLPLOT_wxLogDebug(<some message>); statements
throughout the device driver code to see if I could pin down the cause
of the long pause.
I built and tested each of those results as follows:
make wxwidgets
time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c -dev wxwidgets -np;echo "done x01c"
Until for the last such test (where this commit includes all the uses
of PLPLOT_wxLogDebug) where I got an inexplicable result.
The partial output from the start of the execution of x01c for the
second time was as follows:
PLplot library version: 5.11.1
03:21:18: Debug: nanosecs since epoch = 1838153041939051: plD_init_wxwidgets(): enter
03:21:19: Debug: nanosecs since epoch = 1838153433478655: wxPLDevice(): enter
03:21:19: Debug: nanosecs since epoch = 1838153433667731: wxPLDevice(): gc done
03:21:19: Debug: nanosecs since epoch = 1838153517795969: wxPLDevice(): m_interactiveTextGcdc done
03:21:19: Debug: nanosecs since epoch = 1838153517870818: SetupMemoryMap(): enter
03:21:32: Debug: nanosecs since epoch = 1838166471100796: SetupMemoryMap(): mapName start
03:21:32: Debug: nanosecs since epoch = 1838166471176607: SetupMemoryMap(): mapName done
03:21:32: Debug: nanosecs since epoch = 1838166471205300: SetupMemoryMap(): m_outputMemoryMap.create call
03:21:32: Debug: nanosecs since epoch = 1838166471277077: SetupMemoryMap(): m_outputMemoryMap.create done
Clearly, there is a dramatic large 13 second pause between where
SetupMemoryMap() is entered and it starts to determine mapName. But
the inexplicable part is if you look at the source code there is
trivial executable code code between those two uses of the
PLPLOT_wxLogDebug macro, and there is nothing done between the two
that is related to wxwidgets at all! So fundamentally it looks like
something completely different code is freezing anything to do with
wxwidgets so either execution of the SetupMemoryMap routine itself is
suspended or else execution of wxLogDebug (which is called by the
PLPLOT_wxLogDebug macro) is suspended for 13 seconds. Why?
M cmake/modules/wxwidgets.cmake
M drivers/CMakeLists.txt
M drivers/wxwidgets.cpp
M drivers/wxwidgets_comms.h
M drivers/wxwidgets_dev.cpp
M src/CMakeLists.txt
commit 3c4e6be47c2b132bc632ea7773d912de95631243
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 18 20:44:22 2016 -0800
Upgrade debug output for wxwidgets using the PLPLOT_WX_DEBUG_OUTPUT and PLPLOT_WX_NANOSEC CMake options.
Implement the option PLPLOT_WX_DEBUG_OUTPUT which defaults to OFF.
However, when the user specifies ON, then
debug output is generated for wxwidgets device driver, binding, and example
wherever the developers have used the macro
PLPLOT_wxLogDebug(<some string>);
in the code.
N.B. When the default OFF option is used, that macro is #define'd but empty, and
therefore there is no code that is compiled from the above use of
the macro and therefore no wxwidgets debug output for this case.
Implement the option PLPLOT_WX_NANOSEC which is only meaningful if
PLPLOT_WX_DEBUG_OUTPUT is ON. If both these options are ON, then a
nanosec time stamp is applied to the debug message that is output.
However, PLPLOT_WX_NANOSEC defaults to OFF (so that nanosec time stamp
is not applied) because this option is completely experimental, i.e.,
it will introduce build errors if the user's system does not properly
support the clock_gettime function which is a POSIX option so
clock_gettime is mostly available only on Linux.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) for 3 configuration cases with the following cmake command-line
options:
(1) -DPLPLOT_WX_DEBUG_OUTPUT=ON -DPLPLOT_WX_NANOSEC=ON
(2) -DPLPLOT_WX_DEBUG_OUTPUT=ON
(3) neither of these options
The result for (1) when building the test_wxPLplotDemo target was
19:00:38: Debug: nanosecs since epoch = 1808113138508376: wxPLplotwindow::wxPLplotwindow
19:00:38: Debug: nanosecs since epoch = 1808113147285531: frame->Create
19:00:38: Debug: nanosecs since epoch = 1808113151908731: wxPLplotwindow::Show
19:00:38: Debug: nanosecs since epoch = 1808113151958780: wxPLplotwindow::CreateStream
19:00:38: Debug: nanosecs since epoch = 1808113172019557: wxPLplotwindow::OnCreate
19:00:38: Debug: nanosecs since epoch = 1808113172092596: wxPLplotwindow::CreateStream
19:00:38: Debug: nanosecs since epoch = 1808113181701454: Plot()
The result for (2) when building the test_wxPLplotDemo target was
20:38:39: Debug: wxPLplotwindow::wxPLplotwindow
20:38:39: Debug: frame->Create
20:38:39: Debug: wxPLplotwindow::Show
20:38:39: Debug: wxPLplotwindow::CreateStream
20:38:39: Debug: wxPLplotwindow::OnCreate
20:38:39: Debug: wxPLplotwindow::CreateStream
20:38:39: Debug: Plot()
And the result for (3) when building the test_wxPLplotDemo target was
no debug output at all.
I find these wxwidgets debug output results (i.e., no debug output at
all by default) completely satisfactory for the release, although I
will likely be deploying additional usage of
PLPLOT_wxLogDebug(<some string>);
to try and track down the long pause bug.
M bindings/wxwidgets/CMakeLists.txt
A bindings/wxwidgets/wxPLplot_nanosec.cpp
A bindings/wxwidgets/wxPLplot_nanosec.h.in
M bindings/wxwidgets/wxPLplotstream.h
M bindings/wxwidgets/wxPLplotwindow.h
M cmake/modules/wxwidgets.cmake
M examples/c++/wxPLplotDemo.cpp
M utils/CMakeLists.txt
commit 5a78bb68c509d1a3909c6f3158f22b57e442a7bf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 18 13:17:59 2016 -0800
-dev wxwidgets and wxPLViewer: remove debugging output from PLMemoryMap::create and PLMemoryMap::close
This debugging output in PLMemoryMap::create and PLMemoryMap::close
was useful for determining that (a) there were
no shared memory leaks being generated by this code, and (b) the long
pause issue was created elsewhere than these two methods.
However, this debugging output has served its purpose and was
implemented in a clumsy manner (which I can say because it was mine)
which created preprocessor directives all over the code making it
virtually unreadable. So as a matter of code cleanup and consistent
with the philosophy of removing all debug output from releases, I have
completely removed this debugging output implementation for these two
routines, and if I ever have to reinstate something similar, I will
likely implement it in another way altogether.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the targets x01c, wxwidgets, wxPLViewer and
running
time examples/c/x01c -dev wxwidgets -np; echo "done x01c"; time examples/c/x01c -dev wxwidgets -np;echo "done x01c"
with the PLMemoryMap::create and PLMemoryMap::close debug output gone
as expected. However, there is the usual result of this example where
there is a long pause (typically 5 to 10 seconds) some time in the
initial phases of the start of the second time x01c is run, but (from
previous evidence from the just-removed debug output) some time before
PLMemoryMap::create is called by -dev wxwidgets).
M drivers/wxwidgets_comms.cpp
M drivers/wxwidgets_comms.h
commit 786ff045d1b28db848222e66e47b6349d4aabb52
Author: Pedro Vicente <pvicente@users.sourceforge.net>
Date: Sat Dec 17 16:13:41 2016 -0500
wxwidgets binding: modification of workaround fix for delayed OnCreate event
Make bool wxPLplotwindow<WXWINDOW>::Show return a boolean value.
Failure to do so is an error in Visual Studio.
Tested by: Pedro Vicente <pvicente@users.sourceforge.net>
Tested in Visual Studio, change made/committed in Ubuntu 16.04 i386
where wxWidgets is installed with
sudo apt-get install libwxgtk3.0-dev
with the following results from building the test_wxPLplotDemo target:
15:33:46: Debug: wxPLplotwindow::wxPLplotwindow
15:33:46: Debug: frame->Create
15:33:46: Debug: wxPLplotwindow::Show
15:33:46: Debug: wxPLplotwindow::CreateStream
15:33:46: Debug: Plot()
15:33:46: Debug: wxPLplotwindow::OnCreate
15:33:46: Debug: wxPLplotwindow::CreateStream
Also similarly tested on linux (before and after fix):
1) Ubuntu 14.04 amd64 libwxgtk3.0-dev
2) CentOS 6.8 amd64 wxWidgets 3.1 built from source
3) Debian 8.0 running in VirtualBox amd64 libwxgtk3.0-dev
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_wxPLplotDemo target with
the following results:
22:45:01: Debug: wxPLplotwindow::wxPLplotwindow
22:45:01: Debug: frame->Create
22:45:01: Debug: wxPLplotwindow::Show
22:45:01: Debug: wxPLplotwindow::CreateStream
22:45:01: Debug: wxPLplotwindow::OnCreate
22:45:01: Debug: wxPLplotwindow::CreateStream
22:45:01: Debug: Plot()
M bindings/wxwidgets/wxPLplotwindow.h
commit b0db43554c671e1315d312d3cf3ac08340373b87
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 17 21:28:00 2016 -0800
Update release notes
These preliminary release notes have not been finalized yet because
the preliminary ChangeLog of commit messages for this release has only
been reviewed for topics to include in these release notes up to the
first NAGFOR-related commit. Also, the section on the documentation
changes is forward looking (i.e., stores on-going notes of a
work-in-progress, my documentation work on a private topic branch that
has not been pushed yet).
M README.release
commit e5b7485290a3d5d65b0be1b8037e56441b71d891
Author: Pedro Vicente <pedro.vicente@rhw9121.star1.nesdis.noaa.gov>
Date: Fri Dec 16 13:25:12 2016 -0500
wxwidgets binding: workaround fix for delayed OnCreate event
Add a workaround fix for cases where frame->Create does not trigger an
OnCreate() event before the Plot() in test_wxPLplotDemo. The solution
is to create the stream in a overidden Show() method, that is always
called on window creation.
Tested by: Pedro Vicente <pedro.vicente@rhw9121.star1.nesdis.noaa.gov>
on CentOS Linux with wxwidgets3.1 built from source with the following
results from building the test_wxPLplotDemo target:
13:16:18: Debug: wxPLplotwindow::wxPLplotwindow
13:16:18: Debug: frame->Create
13:16:18: Debug: wxPLplotwindow::Show
13:16:18: Debug: wxPLplotwindow::CreateStream
13:16:19: Debug: Plot()
13:16:19: Debug: wxPLplotwindow::OnCreate
13:16:19: Debug: wxPLplotwindow::CreateStream
The above debug sequence shows that the stream is
valid before the plot is made.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) with the system version of wxwidgets-3.0.2 with
the following results from building the test_wxPLplotDemo target:
23:41:12: Debug: wxPLplotwindow::wxPLplotwindow
23:41:12: Debug: frame->Create
23:41:12: Debug: wxPLplotwindow::Show
23:41:12: Debug: wxPLplotwindow::CreateStream
23:41:12: Debug: wxPLplotwindow::OnCreate
23:41:12: Debug: wxPLplotwindow::CreateStream
23:41:12: Debug: Plot()
In this case, Plot() occurs in a different order but the net effect is
the same as Pedro's case; an OnCreate() event occurs before Plot().
Furthermore, the plot result on this system looks the same as it
did before this fix (as expected from the above event sequence).
M bindings/wxwidgets/wxPLplotwindow.h
commit 3cccca6a49a572e7aa518a5b8a6bbecd9ef1f812
Author: Pedro Vicente <pedro.vicente@rhw9121.star1.nesdis.noaa.gov>
Date: Fri Dec 16 11:24:23 2016 -0500
wxwidgets binding: insert debug messages
Add debug messages that show sequence of events for a bug that happens
on some but not all Linux distributions with wxwidgets3.0/3.1. The
cause is that frame->Create does not always trigger an OnCreate()
event on time before the Plot() call.
Tested by: Pedro Vicente <pedro.vicente@rhw9121.star1.nesdis.noaa.gov>
on CentOS Linux with wxwidgets3.1 built from source with the following
results from building the test_wxPLplotDemo target:
11:09:13: Debug: wxPLplotwindow::wxPLplotwindow
11:09:13: Debug: frame->Create
11:09:13: Debug: pls NULL
11:09:13: Debug: wxPLplotwindow::OnCreate
Clearly this demonstrates the bug with the OnCreate() event happening
too late.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) with the system version of wxwidgets-3.0.2 with
the following results from building the test_wxPLplotDemo target:
23:09:34: Debug: wxPLplotwindow::wxPLplotwindow
23:09:34: Debug: frame->Create
23:09:34: Debug: wxPLplotwindow::OnCreate
23:09:34: Debug: Plot()
Clearly in this case the OnCreate() event happens on time in contrast
with Pedro's result. This demonstrates the bug is platform-dependent
where because timing might be involved, platform should be interpreted
as generally as possible including the hardware/OS version as well as
wxwidgets and gtk+ software. The above results were without
VirtualBox, but in addition all of Pedro's tests failed on a
VirtualBox setup he was using where host was a Windows OS and the
guests were various Linux distributions with system versions of
wxwidgets. Pedro also got a bad test for a non-VirtualBox Ubuntu
distro with wxwidgets was built from source while Phil got a good test
for a non-VirtualBox Ubuntu distro for system wxwidgets. So there are
no clear patterns here.
M bindings/wxwidgets/wxPLplotwindow.h
M examples/c++/wxPLplotDemo.cpp
commit ae4af16daee1ec5215fad84a004c25c86c47de87
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Dec 15 12:18:27 2016 -0800
Update instructions for developers
I split the instructions into more sections, and added
some information for those who are just getting started
as PLplot developers, i.e., always using a description paragraph (typically just one line)
at the start of each commit message, git identifying yourself, and using
git format-patch. I also added a description of the new script
scripts/remove_trailing_blanks.sh
M README.developers
commit e38681885ac2972e4029f55eb7fc79170f6abe38
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Dec 15 00:03:49 2016 -0800
Build system: Implement version check on libharu = libhpdf
Generally speaking, libharu versions < 2.3.0 have a bug (fixed in
2.3.0) where they do not support largish fonts such as occur in our
example 24. Therefore, our build system now implements a version
check for libharu version >= 2.3.0, and only if that check
is passed is PLD_pdf allowed to be ON.
Thanks to Hazen for suggesting this version check to deal with the
several recent dashboard results where test_c_pdf failed on example
24.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by attempting to configure against libharu version
2.2.1 (which was rejected as expected) and then libharu version
2.3.0 (which was accepted as expected). For the latter case,
I built the test_c_pdf target, and build and run went well while
spot checks using a pdf image viewer, e.g.
gv examples/test_examples_output_dir/x24c.pdf
showed the pdf device was slightly better quality in graphics than our
psc device and roughly the same quality in text (i.e., extremely
limited selection of glyphs available). This was the first time I had
checked this device linked against version 2.3.0 of libharu. (Previous
checks were linked against a patched version 2.2.1 of libharu.) All
seems well with this version of libharu so I feel comfortable with
forcing those interested in using the pdf device driver
to use this (latest) version of libharu.
M cmake/modules/pdf.cmake
commit ae52dc63634b3611a5d57d13623ff5feacdd18fe
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 13 23:34:37 2016 -0800
Build system: Fix test_python_psc dependency issue
Recent dashboards (e.g.,
<http://my.cdash.org/index.php?project=PLplot_git&date=2016-12-11>)
that did not enable Tk were showing CMake errors with the following
message:
CMake Error at examples/CMakeLists.txt:668 (add_dependencies):
The dependency target "plplot_widgetmodule" of target "test_python_psc"
does not exist.
I was also able to replicate this issue by enabling Python but not Tk.
The cause was some bad logic that indiscrimately added the
plplot_widgetmodule to the TARGETS_examples_python GLOBAL property
in examples/python/CMakeLists.txt even for cases where the
plplot_widgetmodule target was not built. This commit fixes
that logic.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running cmake with python enabled and either
tk enabled or disabled without CMake error. In the former case
I also built the test_pytkdemo target and was able to operate
the resulting pytkdemo GUI that was launched by that test without
issues.
M examples/python/CMakeLists.txt
commit 8566ee81aa75c18837cdac568f5748cccf45e3e9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 13 18:53:03 2016 -0800
Build system: Improve error message when pkg-config results are inconsistent with CMake library finding
The pkg-config CMake module typically delivers (along with other
information) a list of link flags including many libraries specified
in the -L... -lbasename form. We translate that format for libraries
into actual full pathnames for libraries using the find_library
command. This commit improves the error message when some subset of
the libraries cannot be found. We thank Laurent Berger for drawing
this issue to our attention.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by temporarily renaming the pango-1.0 libraries so
CMake cannot find them. Here is the resulting WARNING messages
which are substantially more informative to the user than
what was delivered for this case before:
-- Found pango, version 1.36.8
-- WARNING: Library inconsistency detected. Your pkg-config files claim certain libraries are present, but CMake cannot find them.
-- The unfound library basenames are as follows:
-- pango-1.0
-- Some library installation and/or adjustment of find-related environment variables or corresponding CMake variables will be required before CMake will be able to find these libraries.
-- cmake_link_flags WARNING: (original link flags) = -lpango-1.0;-lgobject-2.0;-lglib-2.0
-- cmake_link_flags WARNING: (corresponding link flags with found libraries = PANGO_LINK_FLAGS) = _library_pathname-NOTFOUND;/usr/lib/x86_64-linux-gnu/libgobject-2.0.so;/usr/lib/x86_64-linux-gnu/libglib-2.0.so
-- cmake_link_flags WARNING: PANGO_LINK_FLAGS is invalid so it is set to nothing to signal the failure of cmake_link_flags for the original link flags printed out above.
-- WARNING: pkg-config does not find pango.
M cmake/modules/pkg-config.cmake
commit 6170626bc359bbe7f773ef7646449fb359fd563a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 13 02:09:59 2016 -0800
Build system: Bump non-Linux minimum version from 3.3.2 to 3.6.2
At this time, Cygwin provides CMake-3.6.2, MinGW-w64/MSYS2 provides
CMake-3.7.0, Fink provides CMake-3.7.1, MacPorts provides CMake-3.7.1,
and HomeBrew provides CMake-3.7.1.
So adopting a minimum version of 3.6.2 should provide no hardships for any
users of the above non-Linux distributions.
I plan to bump the minimum version for Linux distributions to 3.7.x in
6 months or so, but for now it remains at 3.0.2 (the version provided
by Debian Jessie).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) using
time (nice -19 scripts/comprehensive_test.sh --do_submit_dashboard yes --cmake_command /usr/bin/cmake)
i.e., there were no constraints limiting this test other than
specifying the Debian Jessie system version of cmake which is 3.0.2.
There were no obvious configure, build, or run-time errors, and there
were no PostScript difference regressions.
In addition to this good result for 3.0.2, my recent good
comprehensive test results for PLplot on Linux were for CMake-3.7.0.
So these tests pretty much cover the entire range of CMake versions
that we can use on Linux. Of course, once Arjen finishes his (largely
unlimited) comprehensive test on Cygwin using cmake-3.6.2, and
similarly on MinGW-w64/MSYS2 using the latest cmake version there
(currently 3.7.0) these good conclusions about what versions of CMake
we support should be strengthened even more.
N.B. these tests did not include the recent commits concerning wxwidgets
changes. So those changes will have to be comprehensively tested later.
M CMakeLists.txt
M examples/CMakeLists.txt
commit c1f618a788f11d02cdd78427a42bf64afe11713c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 13 02:07:24 2016 -0800
Update Release manager's cookbook
Tweak procedure for creating preliminary ChangeLog
Add comments in Appendix devoted to gpg about how to
update/revive your expired public key (since mine recently expired).
M README.Release_Manager_Cookbook
commit 08935de7b0c9b6f7f6e2f8937f80da8df8ec4dca
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Dec 13 01:17:49 2016 +0000
Restyle commit
M drivers/wxwidgets_dev.cpp
commit 2643684b94001cd0c7d036fe906574f942a3292c
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Dec 13 00:24:59 2016 +0000
Fixed problem with rotated wxWidgets text
When text was rotated and there was a style change mid line the text was
rendered in the wrong position. Basically for a 90 degree rotatio the x
and y translations relative to the text origin were reversed.
A similar but more subtle issue was that text with newlines was also not
aligned properly as it was assumed that the scale for converting between
plplot units and pixels was the same which only occured when the device
context was square.
These problems were fixed by passing an origin through the function
calls and passing coordinates relative to that origin. This meant that
the relative positions got correctly rotated.
M drivers/wxwidgets.h
M drivers/wxwidgets_dev.cpp
commit 6f483685a5a4135323f17e13337c8a6c290ac92d
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Nov 3 14:13:57 2016 +0000
Fixed problem with newlines in wxWidgets Driver
the wxWidgets driver had stopped working in wxWidgets, this is because
we stopped calculating line height when drawing text as an optimisation.
This has been added back in.
M drivers/wxwidgets_dev.cpp
commit 35833c758dee122b73b130137ed1da9cf3a9343a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 12 14:26:59 2016 -0800
qt device driver: drop use of automoc
This was an example of automoc overkill. All the relevant
automoc-generated symbols are already available and exported from the
plplotqt library which the qt shared object links to. So it was
redundant to regenerate those symbols again with automoc for the qt
shared object, and although the result worked on Linux it appeared to
be associated with build problems on Cygwin. So my hope is that by
removing this redundancy (which also works fine on Linux, see below),
the Cygwin problems associated with the build of qt will disappear.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_c_qtwidget target with no
obvious configure-, build-, or run-time issues.
Furthermore,
ldd -r drivers/qt.so |& less ,
nm --defined-only --extern-only --demangle drivers/qt.so ,
and
nm --undefined-only --demangle drivers/qt.so |less
all gave the expected (good) results.
N.B. testing on Cygwin is requested to make sure this fix and a prior
similar fix for pyqt4 work well on that platform.
M drivers/CMakeLists.txt
commit 15869c314afcb5226c7e076498481b75e78885ee
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 11 21:42:54 2016 -0800
Script for removing trailing blanks: exclude test_tclmatrix.out
This file is used by the check_libtclmatrix_capabilities target for
an exact comparison with pltcl results that exercise the libtclmatrix
capabilities. These pltcl results do have some trailing blanks
so those must be preserved in test_tclmatrix.out as well.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running the modified
scripts/remove_trailing_blanks.sh
No files were changed as a result. In particular, test_tclmatrix.out
retained its trailing blanks (as expected after this change).
M scripts/remove_trailing_blanks.sh
commit aab044901aeb3602e4c4cb9f054892742993c769
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 11 21:29:19 2016 -0800
Style and remove trailing blanks from previous commits
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by runnning
scripts/comprehensive_test.sh
Note, there were no arguments ==> no limits on this comprehensive
test. The result was no configure, build, or run time issues and no
PostScript difference regressions proving the present intrusive change
and the prior intrusive change to include/plplot.h did not introduce
any new issues.
M CMakeLists.txt
M README.dashboard_submissions
M README.release
M bindings/python/CMakeLists.txt
M bindings/python/Plframe.py
M bindings/python/plplot_widgetmodule.c
M bindings/qt_gui/CMakeLists.txt
M cmake/modules/pkg-config.cmake
M cmake/modules/qt.cmake
M cmake/test_linux_ipc/pshm_read.c
M cmake/test_linux_ipc/pshm_unlink.c
M cmake/test_linux_ipc/pshm_write.c
M drivers/wxwidgets_comms.cpp
M drivers/wxwidgets_comms.h
M examples/CMakeLists.txt
M examples/c++/CMakeLists.txt
M examples/plplot_configure.cmake_installed_examples.in
M examples/python/x00.py
M examples/python/x22.py
M examples/python/x24.py
M examples/python/x29.py
M examples/python/x30.py
M examples/python/x33.py
M plplot_test/CMakeLists.txt
commit 6eac5bd11ae44c1fd9f6b7162c9b2780a5877aa2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 11 21:24:35 2016 -0800
tclmatrix library: make this library const correct
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the check_libtclmatrix_capabilities
target with
export CFLAGS="-O3 -std=gnu99 -pedantic -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs -Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings -fvisibility=hidden -Wuninitialized"
M bindings/tcl/tclMatrix.c
commit 627da35ca2336de18b77b0fa861164f352c06ee9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 11 15:11:14 2016 -0800
plplot library: Introduce some additional useful typedefs
These plplot.h header changes include defining the following new typedefs:
// Pointers to mutable scalars:
typedef PLINT * PLINT_NC_SCALAR;
typedef PLBOOL * PLBOOL_NC_SCALAR;
typedef PLUNICODE * PLUNICODE_NC_SCALAR;
typedef char * PLCHAR_NC_SCALAR;
typedef PLFLT * PLFLT_NC_SCALAR;
// Pointers to mutable vectors:
typedef char * PLCHAR_NC_VECTOR;
typedef PLFLT * PLFLT_NC_VECTOR;
// Pointers to mutable 2-dimensional matrices:
typedef char ** PLCHAR_NC_MATRIX;
typedef PLFLT ** PLFLT_NC_MATRIX;
These typedefs are used throughout plplot.h to self-document arguments
which previously had an ambiguous type (e.g., char *) that could be
interpreted either as an array or returned value.
Currently, these new types are not used anywhere else within PLplot but I plan to
use them for DocBook documentation purposes for this release and
post-release I plan to propagate them to other parts of the PLplot
code.
We drop the use of PL_GENERIC_POINTER outside of plplot.h (which
involved changing two lines of code in fonts/stndfont.c), and we
temporarily drop the const attribute from that typedef. That allows
us to replace PLPointer where appropriate with PL_GENERIC_POINTER
within include.h as a self-documenting argument type indicating that
generic pointer argument _should have_ a const attribute without
actually making that backwards-incompatible change, yet.
In sum, although these changes are intrusive code changes for
plplot.h, they are meant to be equivalent to no actual code changes,
i.e., they are designed for self-documentation purposes for now within
plplot.h, but the plan is to propagate the use of these typedefs throughout PLplot
after the release to spread that self documentation.
Since these changes were intrusive, they were heavily tested. See
two commits after this one for the details.
M fonts/stndfont.c
M include/plplot.h
commit 7756f60573ea44ee0eef57e4cae1a1782ec61646
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 10 13:49:29 2016 -0800
wxwidgets: insert more debugging output into code
This time we use
+#define PLMemoryMap_DEBUG
+//#undef PLMemoryMap_DEBUG
in drivers/wxwidgets_comms.h to keep all this debugging noise in the output until we solve this. But for the
release must remember to reverse the sense of the commenting out done
above.
Note this debug output shows what naively appears to me (because there may be an
easy explanation I just don't understand due to lack of C++ skills) to be
a deadloock of some kind which I will discuss on list.
M drivers/wxwidgets_comms.cpp
M drivers/wxwidgets_comms.h
commit 1627eeca9e2b8ff1c0c32166c6299f033eeada9a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 10 04:43:43 2016 -0800
wxwidgets device driver: #undef and use the PLMemoryMap_DEBUG macro
Because PLMemoryMap_DEBUG is #undef'd there is no debug output
for PLMemoryMap, but a future change to #define PLMemoryMap_DEBUG
will generate a lot of useful defbug output.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building and running tests for this commit and
also a local but uncommitted change where PLMemoryMap_DEBUG
was #defined. All results were as expected for the two cases.
M drivers/wxwidgets_comms.cpp
M drivers/wxwidgets_comms.h
commit dcae24e1ce7d15015e0483e71d534bec38aba26d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 10 04:20:08 2016 -0800
wxwidgets device driver: insert some useful debugging output
The resulting debugging output has been discussed recently on the plplot-devel
mailing list. It allowed significant narrowing down of the source of
the long idle wait times that occur for -dev wxwidgets, but that
narrowing down process is not finished yet.
M drivers/wxwidgets_comms.cpp
M drivers/wxwidgets_comms.h
commit 6b010001bf3ed1381b0c4afb7ec07ab8972a4907
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Dec 9 17:42:14 2016 -0800
Build system bug fix: Set USINGDLL macro for automoc-generated source code
The USINGDLL macro must be set in the shared libraries case in
order for visibility of symbols to be implemented correctly.
Our previous method of specifying this macro set the the source-code
property COMPILE_FLAGS (or at least one part of that space-separated
list) to "-DUSINGDLL". But that method fails on automoc-generated
source code (and possibly other generated source code). The answer is
to set the target property COMPILE_DEFINITIONS to USINGDLL (which
applies to all source code for the target whether generated or not).
This fix (and also cleanup in style) is an intrusive build-system
change where for libraries this logic is now all centralized with the
set_library_properties function. As a result of this fix, all
instances of "DUSINGDLL" are now gone from our build-system logic and
either replaced centrally or on-the-spot for modules and executables
by the above COMPILE_DEFINITIONS target property.
This fix allowed us to drop the previous automoc-related workarounds
for the plplot_pyqt4 and plplot_pyqt5 targets that had been applied
previously which was to regenerate automoc results for those targets.
Those workarounds worked on Linux but were causing undefined symbol
problems on Cygwin (and possibly other platforms). So it is
anticipated this fix will solve that Cygwin issue.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
scripts/comprehensive_test.sh
The above build system change was intrusive, and a lot of previous
commits were only partially tested. So note there are no constraining
options used for this script run, i.e., all PLplot components and all
major configurations were tested by it for both the interactive and
non-interactive cases. The result was near perfect with no obvious
configure-, build-, or run-time issues. The only exception to this is
noted and discussed below. Furthermore, there were no PostScript
regressions (i.e., the PostScript difference report was perfect other
than the long-standing ocaml issues) and no "ldd -r" issues.
The only issue for this test was
that at one point (after the test_c_ntk target started building, but
that is not necessarily the one causing the issue because of the -j4
jumbling of results) PLplot generated ~5
PLPLOT ERROR, ABORTING OPERATION
messages from a C (or C++) call to
plabort( "<command_name>: Please call plinit first" )
for several different command_names that were executed for the
interactive testing case and the static build. But without an actual
error exit, and a subsequent run of the appropriate test_interactive
target could not replicate the issue (perhaps because I hit GUI
buttons in a different order? As a result it is extremely difficult
to find the source of this issue.
The above "PLPLOT ERROR" string is looked for and a specific error
exit is taken for most of the results generated in plplot_test except
for
plplot_test/test_octave_interactive.sh.in
But none of those interactive octave examples are currently exercised.
So I conclude this issue occurred for a different type of interactive
test target that is not coverered by plplot_test. But since I could
not identify the source of the issue I am documenting it here (in case
I see it ever again) and moving on.
M bindings/c++/CMakeLists.txt
M bindings/d/CMakeLists.txt
M bindings/non_redacted_tcl/CMakeLists.txt
M bindings/non_redacted_tk/CMakeLists.txt
M bindings/old_f95/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/tk/CMakeLists.txt
M bindings/wxwidgets/CMakeLists.txt
M cmake/modules/plplot_functions.cmake
M drivers/CMakeLists.txt
M examples/c++/CMakeLists.txt
M examples/c/CMakeLists.txt
M examples/non_redacted_tk/CMakeLists.txt
M examples/tk/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
M utils/CMakeLists.txt
commit b9494e0c56186832e6ceafbc116eff177ecce90c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Dec 9 17:26:38 2016 -0800
Build system bug fix: Set installed rpath for the plplotf95 library
This bit of build-system logic for the USE_RPATH=ON case was
inadvertently dropped when creating the new Fortran bindings.
Reinstate it.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ocaml=ON -DENABLE_f95=ON" --do_test_interactive no
(This test also checks the recent fix to this script to drop
dllplplot_stubs.so from the ldd -r reports.)
There were no (bad) results from
grep 'undefined symbol' $(find ../comprehensive_test_disposeable -name "*ldd.out")
like there were before for (the now suppressed) dllplplot_stubs.so
case and the libplplotf95.so case.
In addition there were no obvious run-time or PostScript difference
issues from
grep -i "error" ../comprehensive_test_disposeable/*/*/output_tree/*.out
and
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable/*/*/output_tree/*.out |less
M bindings/f95/CMakeLists.txt
commit 3dea991e07e94faa6df30ca641561f2019058fd6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Dec 9 17:22:50 2016 -0800
Comprehensive test script: drop dllplplot_stubs.so from the ldd -r reports
We deliberately drop dllplplot_stubs.so from the ldd -r reports on
Linux because there is no known way to set the rpath for that
ocamlmklib-generated shared object at the moment. See plplot-devel
mailing discusion on 2016-12-09 with the subject line
"Setting rpath for dllplplot_stubs.so appears not to be possible".
M scripts/comprehensive_test.sh
commit b684ea289b013a9f94e9d1b3d7aa0d450b86b782
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 6 16:37:00 2016 -0800
Comprehensive test script: Improved collection of environment variables
Make the grep selection of environment variable from printenv more specific to avoid
collecting, say both
LD_LIBRARY_PATH=
and
MIC_LD_LIBRARY_PATH
(which actually was reported recently in a report tarball) when for
PLplot testing report purposes we only need to know the contents of LD_LIBRARY_PATH.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DDEFAULT_NO_BINDINGS=ON" --do_test_noninteractive no --do_ctest no --do_test_traditional_install_tree no --do_test_interactive no --do_test_build_tree no --do_test_install_tree no
i.e., a vacuous test other than collecting environment variables and a
listing of the files in ../comprehensive_test_disposable when this
test is completed. The collected environment variables were fine (and
for the record so was the listing file under these unprecedented test
conditions).
M scripts/comprehensive_test.sh
commit f5ba231a99da9ecc0811668381e04f79d97913cf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 4 20:38:59 2016 -0800
Python examples: Rename xw??.py modules to x??.py
This commit completes the topic consisting of namespacing the
maintained set of Python example modules (named xw??.py at that time)
so they work well both noninteractively and with pyqtdemo, dumping the
unmaintained set of Python example modules (named x??.py at that
time), and renaming the xw??.py set as x??.py.
After the renaming was completed I searched our entire source tree
as follows:
find . -type f |grep -v .git |xargs grep xw |grep -vE 'xwin|wxwidgets' |less
and checked through those results for anything relevant to the xw??.py
examples. As far as I know, the only references left are historical
documents, e.g., old changelogs, and the python chapter of our DocBook
documentation. However, that chapter is so out of date it needs to be
completely rewritten so I left the xw??.py references there to be
dealt with during that urgently needed rewrite.
I also searched our entire source tree as follows:
software@raven> find . -type f |grep -v .git |xargs grep 'from *plplot *import'
./bindings/python/Plframe.py:from plplot import *
./examples/python/pytkdemo:from plplot import *
to demonstrate that non-namespaced imports of plplot still exist.
However, I don't have time/energy to deal with these now so I leave
changing these last two instances to namespaced versions an exercise
for the (distant?) future.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running the following comprehensive tests
(which also test our recent build-system bug fixes):
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DPLD_extqt=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_qt=ON -DENABLE_cxx=ON -DENABLE_python=ON -DENABLE_pyqt4=ON -DENABLE_pyqt5=ON")
The above test showed good configure, build, and GUI manipulation for
qt_example and pyqt4_example interactive results (demonstrating the
previous external devices fix works) and good configure, build, and
PostScript differences for the noninteractive Python results
(demonstrating the current name change is working well for
noninteractive testing.)
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_xwin=ON -DPLD_tk=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_tcl=ON -DENABLE_tk=ON -DENABLE_itcl=ON -DENABLE_itk=ON -DENABLE_python=ON" --do_test_noninteractive no --do_ctest no --do_test_traditional_install_tree no
The above test showed good configure, build, and GUI manipulation
results for the Tcl examples (demonstrating the x02.tcl fix is working
well for all these different Tcl/Tk tests). They also showed good
configure, build, and GUI manipulation results for pytkdemo. For all
tests I randomly pushed the buttons for the various examples to
generate them in random order, and I did not notice any issue at all
with cross-talk between the examples showing the restore capabilities
we have created within the (newly renamed) x??.py modules are working
well. Note that no pytkdemo results are possible for the static
library case since Python and therefore this GUI are automatically
turned off for that case, but for what we could test (the build-tree
and installed-examples tree cases and for the remaining two major
configurations [shared libraries + dynamic device, shared libraries +
nondynamic devices]) all was well.
For the first comprehensive test I forgot to check the ldd -r results
but the the last comprehensive test, the following test showed
there were no missing symbols _in any_ of the shared objects that we
build.
grep -i "symbol not found" $(find ../comprehensive_test_disposeable -name "*ldd.out")
M examples/python/CMakeLists.txt
M examples/python/README.pythondemos
M examples/python/pythondemos.py
M examples/python/pytkdemo
M examples/python/x00
A examples/python/x00.py
M examples/python/x01
A examples/python/x01.py
M examples/python/x02
A examples/python/x02.py
M examples/python/x03
A examples/python/x03.py
M examples/python/x04
A examples/python/x04.py
M examples/python/x05
A examples/python/x05.py
M examples/python/x06
A examples/python/x06.py
M examples/python/x07
A examples/python/x07.py
M examples/python/x08
A examples/python/x08.py
M examples/python/x09
A examples/python/x09.py
M examples/python/x10
A examples/python/x10.py
M examples/python/x11
A examples/python/x11.py
M examples/python/x12
A examples/python/x12.py
M examples/python/x13
A examples/python/x13.py
M examples/python/x14
A examples/python/x14.py
M examples/python/x15
A examples/python/x15.py
M examples/python/x16
A examples/python/x16.py
M examples/python/x17
A examples/python/x17.py
M examples/python/x18
A examples/python/x18.py
M examples/python/x19
A examples/python/x19.py
M examples/python/x20
A examples/python/x20.py
M examples/python/x21
A examples/python/x21.py
M examples/python/x22
A examples/python/x22.py
M examples/python/x23
A examples/python/x23.py
M examples/python/x24
A examples/python/x24.py
M examples/python/x25
A examples/python/x25.py
M examples/python/x26
A examples/python/x26.py
M examples/python/x27
A examples/python/x27.py
M examples/python/x28
A examples/python/x28.py
M examples/python/x29
A examples/python/x29.py
M examples/python/x30
A examples/python/x30.py
M examples/python/x31
A examples/python/x31.py
M examples/python/x33
A examples/python/x33.py
D examples/python/xw00.py
D examples/python/xw01.py
D examples/python/xw02.py
D examples/python/xw03.py
D examples/python/xw04.py
D examples/python/xw05.py
D examples/python/xw06.py
D examples/python/xw07.py
D examples/python/xw08.py
D examples/python/xw09.py
D examples/python/xw10.py
D examples/python/xw11.py
D examples/python/xw12.py
D examples/python/xw13.py
D examples/python/xw14.py
D examples/python/xw15.py
D examples/python/xw16.py
D examples/python/xw17.py
D examples/python/xw18.py
D examples/python/xw19.py
D examples/python/xw20.py
D examples/python/xw21.py
D examples/python/xw22.py
D examples/python/xw23.py
D examples/python/xw24.py
D examples/python/xw25.py
D examples/python/xw26.py
D examples/python/xw27.py
D examples/python/xw28.py
D examples/python/xw29.py
D examples/python/xw30.py
D examples/python/xw31.py
D examples/python/xw33.py
M scripts/htdocs-gen_plot-examples.sh
M scripts/parity_bit_check.exclude
M www/examples.php
commit 165d3896fed9a0741a319562732dc7fc6c2f7a94
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 4 20:34:25 2016 -0800
Tcl examples: Solve long-standing restoration bug for example 2
For Tcl example 2 I followed the restoration model worked out for the
Python examples, and the result was the nasty interaction (images
superimposed) between Tcl example 2 and the following example 3 was
eliminated.
M examples/tcl/x02.tcl
commit 326967040f49400040bf155c3382c48fba0b7096
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 4 20:11:00 2016 -0800
Build system: Fix linking issues
For the plplot_widgetmodule shared object used by pytkdemo, the ENABLE_DYNDRIVERS
OFF linking case only works if -dev tk code is incorporated into libplplot.
So add some "AND (ENABLE_DYNDRIVERS OR PLD_tk)" Boolean logic to only
build the plplot_widgetmodule shared object and the test_pytkdemo target
that depends on it only for this (correct) case.
Add list of external devices to interactive devices to determine
<driver>_targets in test system targets that are enabled in the
examples subdirectory. This change makes sure that qt_targets and
cairo_targets are correctly calculated for the case where only the
extqt form and not the interactive form of the qt or cairo devices
is enabaled.
Also, I took this opportunity to allow test_tk and test_interactive
general interactive targets to depend on test_pytkdemo since that GUI
has become so reliable now.
M bindings/python/CMakeLists.txt
M examples/CMakeLists.txt
commit 9f90a72c9a8224f03a4c6498f47a084f2c96ef35
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 4 17:19:21 2016 -0800
Bug fix for TclSup.py: Allow the possibility that list of file devices is empty
This bug in TclSup.py was discovered for the case where the cmake options
-DDEFAULT_NO_DEVICES=ON -DPLD_xwin=ON -DDEFAULT_NO_BINDINGS=ON
-DENABLE_tcl=ON -DENABLE_tk=ON -DENABLE_itcl=ON -DENABLE_itk=ON
-DENABLE_python=ON
were used and the test_pytkdemo target was built. (The pytkdemo
GUI's operation depends on TclSup.py working properly, and before
this fix an empty list of file devices was causing python errors
during the GUI startup.)
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) using the above cmake options and
building test_pyqtdemo without any build issues or GUI running
issues (although I did not try the GUI button to
store results to a file device since there are none of those
for the above cmake options, so a graceful escape from that
situation will likely take more programming effort if somebody
is interested in further developing this GUI).
M bindings/python/TclSup.py
commit 8b19e884e155c1030776f869b5f77285bb9e8073
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 4 03:53:48 2016 -0800
Removed all the x[0-9][0-9].py versions of the standard Python example modules
These x[0-9][0-9].py versions (which were the historical basis of the
current well-maintained and expanded set of xw[0-9][0-9].py example
modules) were only kept around because the pytkdemo Python +
Plframe/Tcl/Tk used them, but pytkdemo has now been changed to use the
xw[0-9][0-9].py versions and nothing else in our source tree refers to
these x[0-9][0-9].py versions. Also these x[0-9][0-9].py versions are
not well-maintained. So there is no reason to keep these unmaintained
versions around any longer.
M examples/python/CMakeLists.txt
D examples/python/x01.py
D examples/python/x02.py
D examples/python/x03.py
D examples/python/x04.py
D examples/python/x05.py
D examples/python/x06.py
D examples/python/x07.py
D examples/python/x08.py
D examples/python/x09.py
D examples/python/x10.py
D examples/python/x11.py
D examples/python/x12.py
D examples/python/x13.py
D examples/python/x14.py
D examples/python/x15.py
D examples/python/x16.py
D examples/python/x17.py
D examples/python/x18.py
D examples/python/x19.py
commit b1c89bf7aea23aa7b1fc7c32567b75260310290a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 4 03:10:35 2016 -0800
Python + Plframe/Tk/Tcl GUI: large update
Changed pytkdemo (which demonstrates this GUI) to add examples 0, 9,
and 18 to the GUI and change the standard example modules that were
imported from the x??.py versions to the xw??.py versions. The x??.py
versions had historically served as the starting basis for the xw??.py
versions, but the latter had been greatly expanded, modernized, and
maintained while the former were essentially unmaintained. Thus, the
only reason to keep the x??.py versions around was because the xw??.py
versions had originally been changed to using no plplot namespace (a
historical error by yours truly because I didn't understand Python
very well way back when) so could not be called from pytkdemo. That
historical error has now been rectified allowing the present change to
pytkdemo so it now imports the xw??.py versions of the standard
example modules.
The modernized/expanded standard example modules required large
changes to Plframe.py to support the additional PLplot API used in
those examples including all the PLplot constants and a substantial
number of PLplot functions which had not been supported before.
N.B. pytkdemo currently does not display examples 14, 15, 17, and
19-33. If that demo was modified to add in some or all of those
missing examples more PLplot functions would have to be added to
Plframe.py.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_pytkdemo target and
clicking on each of the subset of examples that are enabled
in that GUI (examples 0 through 18 excluding 14, 15, and 17).
Those examples looked find with no observable cross-talk between them
except for one intermittent colour issue which is when I clicked on
example 0 through 3 in that exact order, example 3 turned up with the
wrong colours. But I could not reproduce the problem reliably so I
suspect these intermittent colour issues are the result of some subtle
memory management issue.
In sum, pytkdemo now has a new lease on life with very few issues
compared to what it had before with the x??.py version of the
standard example modules. And this commit prepares the way
for removing the x??.py version of the standard examples in
the next commit.
M bindings/python/Plframe.py
M examples/python/pytkdemo
commit 9a1626cc6b71b544c299d9e2eb50301ce5bd3f9f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 4 03:06:51 2016 -0800
Remove debugging printf statements from bindings/python/plplot_widgetmodule.c
M bindings/python/plplot_widgetmodule.c
commit 94f1dcb250c72c9ea3bbe4a75f5bb1066f57148a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 4 02:41:33 2016 -0800
Remove plplot_test/test_single_python.sh script
This bash script historically was used to run a single Python example. It
had fallen into disrepair (it would not work properly on standard
examples 14, 17 and 31, and also it needed a fixup to work with the
namespaced version of the xw?? modules we have now), and was located
in an awkward directory in the source tree from which it would have
had to be run from examples/python in the build tree. Also this
script has been completely superseded by the examples/python/x??
Python scripts and is referred to by no other script or file (except
for historical data) within our source tree. Therefore, deep-six this
script.
D plplot_test/test_single_python.sh
commit a222c2de5350f6382f8803c93c3c73427c22c752
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 4 01:59:44 2016 -0800
Python examples: Convert pythondemos.py to namespaced form
In this example replaced all instances of
from plplot import *
with
import plplot as <somenamespace>
where somenamespace is typically "w". Then edited this example
further to use the now required (because of the above form of import
statement) namespaced version (e.g., w.plparseopts rather than
plparseopts and w.PL_PARSE_FULL rather than PL_PARSE_FULL) to refer to
all plplot function calls and data.
I also took this opportunity to remove import of the
plplot_py_demos module and also removed the corresponding
file plplot_py_demos.py which contained only
from plplot import *
from numpy import *
This change avoids the non-namespaced form of import statement
for the plplot module. And with regard to numpy, I
now use "from numpy import *" where needed.
Within pythondemos.py I now import the restore module and call
restore.main(w) to do the required return to default of the chosen
cmap0 colour index between each of the examples. (By avoiding this
index change within the xw??.py modules, we avoid generating spurious
differences with the C standard examples.) At some point in the future
I may do other restoration to default via the restore module, but for
now, I leave that to individual xw??.py examples following the
restoration model used by the Tcl examples (to avoid
cross-contamination issues between them). Note, that preliminary runs
of pythondemos.py (and also pytkdemo while converting it over to use
of the xw??.py modules, see next commit) showed a lot of
cross-contamination issues that had to be dealt with by restoring to
default in each of the xw??.py modules where some command within the
example was changing PLplot to a non-default state.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building all the Python example prerequisite
targets (_plplotcmodule_fixed and python_examples), the Chloe_file
target (required by example 20), and some interactive device driver
target [I picked the cairo target so that the xcairo device would be
accessible]). Afterward, I changed directory to examples/python
(required by the location of Chloe.pgm) and ran
./pythondemons.py
with no obvious cross-contamination or any other issue.
M examples/python/CMakeLists.txt
D examples/python/plplot_py_demos.py
M examples/python/pythondemos.py
A examples/python/restore.py
commit b335634bb28c41eaad0b6e79f755d39c273b00df
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 4 01:46:03 2016 -0800
Python examples: Convert xMN + xwMN.py python scripts and modules to namespaced form
(The xMN form is always a script that imports the corresponding xwMN
module, but xwMN.py is also a script for MN = 14, 17, and 31).
In these script and module pairs corresponding to a standard example,
I replaced all instances of
from plplot import *
with
import plplot as <somenamespace>
where somenamespace is typically "w". Then edited these examples
further to use the now required (because of the above form of import
statement) namespaced version (e.g., w.plparseopts rather than
plparseopts and w.PL_PARSE_FULL rather than PL_PARSE_FULL) to refer to
all plplot function calls and data.
In anticipation of the next commit concerning the pythondemos.py
script to run all Python standard examples at once, I took this
opportunity to remove known sources of cross-contamination of one
example with another by restoring defaults (other than choice of
current cmap0 index which must be restored another way to avoid
creating spurious differences with the corresponding C results).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_noninteractive target.
No build, run-time, or PostScript difference issues were encountered.
M examples/python/x00
M examples/python/x01
M examples/python/x02
M examples/python/x03
M examples/python/x04
M examples/python/x05
M examples/python/x06
M examples/python/x07
M examples/python/x08
M examples/python/x09
M examples/python/x10
M examples/python/x11
M examples/python/x12
M examples/python/x13
M examples/python/x15
M examples/python/x16
M examples/python/x18
M examples/python/x19
M examples/python/x20
M examples/python/x21
M examples/python/x22
M examples/python/x23
M examples/python/x24
M examples/python/x25
M examples/python/x26
M examples/python/x27
M examples/python/x28
M examples/python/x29
M examples/python/x30
M examples/python/x33
M examples/python/xw00.py
M examples/python/xw01.py
M examples/python/xw02.py
M examples/python/xw03.py
M examples/python/xw04.py
M examples/python/xw05.py
M examples/python/xw06.py
M examples/python/xw07.py
M examples/python/xw08.py
M examples/python/xw09.py
M examples/python/xw10.py
M examples/python/xw11.py
M examples/python/xw12.py
M examples/python/xw13.py
M examples/python/xw14.py
M examples/python/xw15.py
M examples/python/xw16.py
M examples/python/xw17.py
M examples/python/xw18.py
M examples/python/xw19.py
M examples/python/xw20.py
M examples/python/xw21.py
M examples/python/xw22.py
M examples/python/xw23.py
M examples/python/xw24.py
M examples/python/xw25.py
M examples/python/xw26.py
M examples/python/xw27.py
M examples/python/xw28.py
M examples/python/xw29.py
M examples/python/xw30.py
M examples/python/xw31.py
M examples/python/xw33.py
commit 247282eb817cc22b65bf9f0c5cfc44fb608a427a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 3 19:07:06 2016 -0800
Python examples: Convert test*.py, test_plsmem.py.in, and plplot_logo.py examples to namespaced form
In these examples replaced all instances of
from plplot import *
to
import plplot as <somenamespace>
where somenamespace is typically "w". Then edited the examples
further to use the now required (because of the above form of import
statement) namespaced version (e.g., w.plparseopts rather than
plparseopts and w.PL_PARSE_FULL rather than PL_PARSE_FULL) to refer to
all plplot function calls and data.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building all the Python example prerequisite targets
(_plplotcmodule_fixed and python_examples) and some interactive
device driver target [I picked the cairo target so that the xcairo device
would be accessible]). Afterward, I ran all the 12 test*.py examples
from the top directory of the build tree using the xcairo device. For example:
examples/python/testh.py -dev xcairo
No build or run-time issues were encountered with any of these 14 tests.
M examples/python/plplot_logo.py
M examples/python/test_axis_precision.py
M examples/python/test_circle.py
M examples/python/test_fill.py
M examples/python/test_gradient.py
M examples/python/test_hebrew_diacritic.py
M examples/python/test_linebreak.py
M examples/python/test_plplot_encodings.py
M examples/python/test_plsmem.py.in
M examples/python/test_style.py
M examples/python/test_superscript_subscript.py
M examples/python/test_symbol_clip.py
M examples/python/test_type1.py
M examples/python/testh.py
commit cb2a2c6ab33ad750e0693c7866a030a846e7cbe8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Nov 30 21:49:33 2016 -0800
Tests: Added test_pytkdemo target
This target runs the pytkdemo example which exercises all the x??.py
forms of the Python examples using the Tcl/Tk plframe approach that is
briefly described in examples/python/README.pythondemos.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_pytkdemo target from scratch
(just after cmake was run in an empty build tree). Via the
dependencies of that target all prerequisites for running pytkdemo are
built, and then pytkdemo is run. That modified Tkinter GUI appears to
work well outside of some bugs in the x??.py examples which have
essentially gone unmaintained since ~2000 essentially because pytkdemo
is the only way to run these examples. (N.B. the xw??.py form of the
examples can be run with pure python independent of Tkinter and the
Tcl/Tk plframe approach, and are well maintained.)
M examples/CMakeLists.txt
M examples/python/pytkdemo
commit 8dfff8a6c822651df944b5306f2b3a26ddb7a491
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Nov 30 02:26:47 2016 -0800
Build system: Fix stale cached variable bug in determining correct HAS_LIBQHULL_INCLUDE value
If HAS_LIBQHULL_INCLUDE was ON as a result of the first cmake run, for any subsequent
run the cached variable QHULL_INCLUDE_DIR would be true and HAS_LIBQHULL_INCLUDE would
(incorrectly) be set to OFF as a result. The fix was to look for both
forms of header with one command and store the result in the cached
variable QHULL_INCLUDE_FILE, and then parse that cached result to see if
it was the libqhull form or not. Subsequent runs would skip the find
(because the cached value would show that had already been done) and
continue to parse that result the same way.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux by
running cmake twice and looking at the QHULL-related results for the
case when the libqhull form of header was present and also the case
when it was not. In all cases got the expected results for
HAS_LIBQHULL_INCLUDE which were consistent between cmake runs.
M cmake/modules/FindQHULL.cmake
M cmake/modules/csiro.cmake
commit 8cf972a0af24672529f1132ea69bb9cff7b78755
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Nov 29 01:48:29 2016 -0800
Document our dashboard submissions.
A README.dashboard_submissions
commit 7e987c4a4eb8a3390e54a26e5267ddcc9669f53d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Nov 29 01:01:49 2016 -0800
CTest: Implement PLPLOT_BUILDNAME_SUFFIX and use this capability to improve labelling of dashboards submitted by comprehensive_test.sh
The CTest module typically calculates the BUILDNAME as <os>-<compiler>,
e.g., Linux-c++. I have implemented an option to add a suffix to that name
to help users label the various kinds of PLplot builds in more detail. The logic
I use for this is
set(BUILDNAME ${BUILDNAME}${PLPLOT_BUILDNAME_SUFFIX})
So if the user specifies the cmake option
-DPLPLOT_BUILDNAME_SUFFIX:STRING="-(shared library + dynamic devices)"
then if the usual name string would have been "Linux-c++" then the
actual name string used to identify the build for a dashboard
will be "Linux-c++-(shared library + dynamic devices)"
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
scripts/comprehensive_test.sh --do_submit_dashboard yes --do_test_interactive no --do_test_noninteractive no --do_test_install_tree no --do_test_traditional_install_tree no
The resulting three dashboards at
<http://my.cdash.org/index.php?project=PLplot_git&date=2016-11-29> are
labelled appropriately for the three principal build configurations
tested by the above script options so this BUILDNAME suffix capability seems to be
working correctly.
M CMakeLists.txt
M scripts/comprehensive_test.sh
commit e187a6c733007c97e962d18aa6543ff81eb0e96a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Nov 28 17:01:26 2016 -0800
CTest: customize maximum length of successful tests from 1024 to 10240 bytes
That smaller limit was unnecessarily truncating the results from the
examples_compare test that were being submitted to our dashboard
server.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
scripts/comprehensive_test.sh --do_submit_dashboard yes --do_test_interactive no --do_test_noninteractive no --do_test_install_tree no --do_test_traditional_install_tree no --do_nondynamic no --do_static no
(i.e., run just ctest with dashboard submission enabled in the build
tree for just our shared library/dynamic devices configuration.) The
resulting dashboard at
<http://my.cdash.org/index.php?project=PLplot_git> no longer show the
annoying truncation of the examples_compare test results that occurred
before.
M CMakeLists.txt
A CTestCustom.ctest.in
commit 9adf35eabcd0aa4c0aa49f2ed410ccbf387a1294
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Nov 28 14:16:19 2016 -0800
Comprehensive test script: Implement the --do_submit_dashboard option
Because of privacy concerns, we make this option opt-in (i.e., the
default value is no). The reason for this is the dashboards collected
and published at <http://my.cdash.org/index.php?project=PLplot_git> by
this option contain essentially all details of each ctest run (e.g., how many
cpu's does your computer have). So some users may prefer not to use
this option for that reason. Note, if the user specifies yes for this
option they are also specifically warned of the publication of
complete details of their ctest results, and they have a chance to abort
the comprehensive test at that point if they so desire.
We also took this opportunity to make the order in which
the script options are documented, processed, and summarized
consistent throughout the script. We also made that order
more logical in a few cases.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
scripts/comprehensive_test.sh --do_submit_dashboard yes --do_test_interactive no --do_test_noninteractive no --do_test_install_tree no --do_test_traditional_install_tree no
(which because of the extra options, ends up running just "make -j4"
and "ctest -j4 -D Experimental" in the build tree for our 3 major
configurations). As expected 3 dashboards containing these ctest
results were submitted to and showed up at
<http://my.cdash.org/index.php?project=PLplot_git>. So it appears,
this script update is a complete success. However, for those
published dashboards, I noticed that the examples_compare test
exceeded the default limit of 1024 bytes for successfull tests so I
plan to raise that limit to 10240 bytes in a forthcoming commit.
M scripts/comprehensive_test.sh
commit d7192bb96ccacfd741b4d105940b5c69d099c28d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Nov 28 02:38:02 2016 -0800
Implement submission of dashboards to the my.cdash.org cdash server
The new CTestConfig.cmake file was provided by my.cdash.org to
facilitate submitting dashboards (defined to be essentially the complete
set of information associated with a particular ctest run) to the new
"PLplot_git" project I created at my.cdash.org. Note the "ctest -D
Experimental " command I used below to test this project, can be
executed by anybody to create a dashboard and send it to the
"PLplot_git" project. However, since this is a free service (provided
by Kitware) there is a limit of a total of 10 dashboard submissions
per day.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running the following commands:
cmake -DBUILD_TEST=ON ....
make -j4 all #N.B. the all target must always be built before ctest is run
ctest -j4 -D Experimental
(The -j4 option for makes builds the all target in parallel, and the
-j4 option for ctest runs the tests in parallel.)
That ctest command (which required ~5 minutes) executed 31 tests that
are enabled by the above cmake command; created a dashboard of those
results; and submitted that dashboard to the above project. That
dashboard (and one previous one I did) can be viewed at
<http://my.cdash.org/index.php?project=PLplot_git> and shows the whole
process was a complete success. Note that virtually every field in a
given dashboard is presented on the my.cdash.org cdash server as a
clickable link that gives more information about all aspects of the
dashboard in an extremely convenient format.
M CMakeLists.txt
A CTestConfig.cmake
commit 34db4b3730430a690326399597fd138522939025
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Nov 26 17:18:55 2016 -0800
Build system: Improve Qt (mostly Qt5) support
* Change the semantics of PLPLOT_USE_QT5. By default PLPLOT_USE_QT5
is OFF. In this case our build system searches first for Qt4, and
if no suitable development version of that can be found, then
searches second for Qt5 (and if no suitable development version of
that is found, disables our Qt-related code components). The reason
for favoring Qt4 over Qt5 this way is because at least on Debian
Jessie, Qt4 has no text alignment or memory management issues while
Qt5 still does have those issues. Also, our test times indicate our qt
devices (which only use a Qt API that is common to both Qt4 and Qt5)
are a factor of 2 (!) faster with Qt4 compared to Qt5. Because of
these advantages of Qt4, most users should use this default Qt
search method, However, note, if a user for some strange reason
absolutely does not want to look for or use the preferred Qt4
development support, they should set -DPLPLOT_USE_QT5=ON (in which
case the search for Qt4 is completely bypassed and only Qt5 is
tried).
* Update minimum Qt4 version from 4.8.2 to 4.8.6.
* Improve commentary in qt.cmake.
* Improve Qt-related variable names so the ones with the "pc_" prefix
only affect the configuration of our pkg-config files and nothing
else.
* Fix configuration of pkg-config files for the Qt5 case. This bug fix and the
next bug fix allowed qt_example to be traditionally built
in the installed examples tree for the Qt5 case.
* Fix examples/c++/Makefile.examples.in to properly configure the traditional
build of qt_examples in the Qt5 case.
* Rename set_qt_target_properties function to
set_qt4_target_properties to self-document that is to be used only
for the Qt4 case.
* This is not necessary for g++ and many other compilers, but for best
practice Add ${CMAKE_CURRENT_BINARY_DIR} to the included directories
when AUTOMOC is ON for a target.
* Work around insoluble visibility issues for the moc-generated code
in the plplotqt or plplot libraries by using AUTOMOC for both
the plplot_pyqt4 and plplot_pyqt5 shared objects.
* Drop unnecessary (from inspections of nm and ldd -r results) AUTOMOC of
qt.h for qt_example build. This makes sense since qt.h describes a
separate library (plplotqt or plplot depending on ENABLE_DYNDRIVERS)
which already includes moc-generated code for qt.h and qt_example
links to that separate library.
* Drop redundant link of the plplot_pyqt4 and plplot_pyqt5 shared
objects with the plplotqt library when ENABLE_DYNDRIVERS is false
(since in that case the plplot library provides all the needed
symbols).
* Force smokplplotqt build to be Qt4 only because smoke is not
available (for the forseeable future) for Qt5.
* Solve visibility issue with smokeplplotqt by running ${SMOKE_GEN_BIN}
directly on qt.h rather than plplotqt.h. The latter file only
#include'd qt.h, but somehow that compromised ${SMOKE_GEN_BIN}'s ability
to generate code with consistent visibilty. I only discovered this
solution by accident, but I will take it! This change also allows
plplotqt.h to be removed.
* Update ndp_UseQt4.cmake to be consistent with the CMake-3.7.0 version
of UseQt4.cmake.
This commit completes my planned Qt-related build system work because of
the unprecedented good Qt5 comprehensive test results below.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_bmpqt=ON -DPLD_epsqt=ON -DPLD_extqt=ON -DPLD_jpgqt=ON -DPLD_memqt=ON -DPLD_pdfqt=ON -DPLD_pngqt=ON -DPLD_ppmqt=ON -DPLD_qtwidget=ON -DPLD_svgqt=ON -DPLD_tiffqt=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_qt=ON -DENABLE_cxx=ON -DENABLE_python=ON -DENABLE_pyqt5=ON -DENABLE_pyqt4=ON -DPLPLOT_USE_QT5=OFF"
and
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_bmpqt=ON -DPLD_epsqt=ON -DPLD_extqt=ON -DPLD_jpgqt=ON -DPLD_memqt=ON -DPLD_pdfqt=ON -DPLD_pngqt=ON -DPLD_ppmqt=ON -DPLD_qtwidget=ON -DPLD_svgqt=ON -DPLD_tiffqt=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_qt=ON -DENABLE_cxx=ON -DENABLE_python=ON -DENABLE_pyqt5=ON -DENABLE_pyqt4=ON -DPLPLOT_USE_QT5=ON"
with no obvious issues. Note the above are truly comprehensive tests
other than limiting the tests to Qt-related PLplot software components
in the interest of speed. So these comprehensive tests were for our 3
major configurations, and our 3 different build trees (core build,
installed examples build, and traditional installed examples build)
for both interactive and noninteractive test results. Also note this
is the first time a fully comprehensive test of the Qt case has
completed without errors for -DPLPLOT_USE_QT5=ON.
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
D bindings/qt_gui/smoke/plplotqt.h
M cmake/modules/ndp_UseQt4.cmake
M cmake/modules/qt.cmake
M drivers/CMakeLists.txt
M examples/c++/CMakeLists.txt
M examples/c++/Makefile.examples.in
M src/CMakeLists.txt
commit 034aa0c47ec818b412c93784276ee961fc05e2c0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Nov 26 17:08:59 2016 -0800
Comprehensive test script: reuse code to roughly halve the logic to be maintained
Previously, the script had two large chunks of logic which were
the same as each other except in the second chunk every instance
of "noninteractive" was replaced with "interactive", and the ctest part
of the logic was dropped. It turned out I could generalize the first
chunk of logic using TEST_TYPE (which is either "noninteractive" or
"interactive") so that logic chunk handled both types allowing me to drop
the second chunk of logic completely. So this change lifts a
substantial maintenance burden and considerably shortens the script.
(What's not to like? :-) )
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DPLD_xwin=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON"
without any noticeable issues.
M scripts/comprehensive_test.sh
commit 4586463f540da126e71274d35291b307a1f67626
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Nov 26 14:17:47 2016 -0800
Comprehensive test script: add stanzas to collect ldd -r information on Linux
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DPLD_xwin=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON"
The revised script worked and the resulting *ldd.out files appeared in
the report tarball and also showed no missing symbols (for this
extremely limited test case).
M scripts/comprehensive_test.sh
commit e1e7be46a89707a6aa872e0ca97d14132dc514b2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 25 18:08:24 2016 -0800
test_automoc project: add ${CMAKE_CURRENT_BINARY_DIR} to include directories
Note that for these cases ${CMAKE_CURRENT_BUILD_DIR} is not required
for g++ and many other C++ compilers, but still adding this directory
to the include directories is still best practice for AUTOMOC just in
case there is a compiler out there that does not look in the source
directory for the quoted form of #included headers (this is allowed by
the lax C/C++ standards in this regard) in the automoc-generated
source code ${CMAKE_CURRENT_BINARY_DIR}/<targetname>_automoc.cpp that
is specifically added by automoc to the list of source files for the
target.
Also, it is not clear that the INCLUDE_DIRECTORIES property should be
set directly using set_target_properties because there is a question
in general (although it doesn't matter in this specific case) whether
that will destroy INCLUDE_DIRECTORIES inherited from the directory. So
I took this opportunity to change from setting that property directly
to using the target_include_directories command which specifically
appends the specified directories to the INCLUDE_DIRECTORIES property
of the target.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by creating a build directory, changing location to that
empty directory, and then running
cmake <location of test_automoc project>
make
nm --undefined-only --demangle $(ls helloworld_* |grep '\*$' | sed -e 's?\*??') |less
ldd -r $(ls helloworld_* |grep '\*$' | sed -e 's?\*??') |& less
The above four commands all had no noticable issues.
M cmake/test_automoc/CMakeLists.txt
commit 8e5529d7affff22ade059101d243319020a8986d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Nov 20 16:11:46 2016 -0800
The tclmatrix library: add instructions for testing that library by hand
M examples/tcl/README.tcldemos
commit db396b9fbdc9cd54fb8545ea655185ca73a2a07e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Nov 19 16:04:28 2016 -0800
Build system: Fix if argument dereferencing issue that occurs for CMake-3.7.0
My thanks to Tom Schoonjans for reporting this issue.
CMake-3.1 and beyond implements policy CMP0054. The OLD behaviour of
this policy (which we are forced to adopt because we currently support
CMake-3.0.2, ugh) is that quoted strings in if arguments are
dereferenced if there is a variable of the same name that has been
defined.
For example in the following if statement
if(BINDING STREQUAL "c")
CMake looks for a variable called c that has been defined and uses the
value of that variable (which is really a nasty bug in the older
versions of CMake such as 3.0.2 since it is a huge surprise that that
dereferencing occurs instead of just using the string as is for the
comparison). But we are stuck with that bug (because we support 3.0.2
which implies the OLD behaviour of CMP0054).
However, modern versions of CMake such as 3.1.x through 3.7.0 do warn
when this bug shows up. We got no such warning up to 3.6.x, but
evidentally for CMake-3.7.0, the c variable has been set somewhere in
the official CMake code (e.g., in the find modules) so for that versin
we got warnings for the above if statement each time our build system
code executes the function (pkg_config_file) that contains the above
statement, and the result was the above if statement failed when
BINDING derefenced to c, and the pkg-config files that are configured
by that function were screwed up as a result as noticed by Tom
Schoonjans.
I have worked around the problem by replacing the above logic with
if("X${BINDING}X" STREQUAL "XcX")
on the assumption that no CMake variable in our own build system logic
and also the CMake code provided by CMake itself is going to have the name
XcX, but I have also commented the result with "CMP0054" so it will
be easy to find and remove this commit once we no longer have to
support CMake-3.0.2 so that we can use the rational CMP0054 NEW behaviour
which is that quoted strings such as "c" are not dereferenced in "if"
statements!
Meanwhile, we rely on sharp-eyed users like Tom to tell us whenever
there is a message concerning CMP0054 for any CMake version of 3.1 or
higher since that is a signal that in virtually every case our CMake
logic will go wrong (as in this 4.7.0 case) do to this OLD CMP0054
behaviour.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by comparing pkg-config files we configure in
pkgcfg/*.pc with equivalent good *.pc results that were derived with a
previous version of CMake that did not define the "c" variable that
triggered this bug. In all cases for CMake-3.7.0, the file names and
contents of those files are now identical to the good past results.
Also, because of this fix all CMP0054 warnings now no longer occur
with cmake-3.7.0.
M cmake/modules/pkg-config.cmake
commit 6dd5069b8058cdc9bacb88932e80583b33319148
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Nov 19 12:47:12 2016 -0800
Build system: reduce loudness of warnings when a compiler is broken or missing
Also, for this case advertise (and implement) the
-DENABLE_compiler_diagnostics=ON option to give full CMake diagnostics
when a compiler is broken or missing. This option should be useful
to users where the broken/missing compiler is a surprise.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by deliberately breaking the gfortran compiler
by specifying
export FFLAGS=-whatever
and checking the messages that result from
-DENABLE_compiler_diagnostics=ON or (the default)
-DENABLE_compiler_diagnostics=OFF.
M cmake/modules/language_support.cmake
commit e166866e1012543eeebd4e737283a33642b9ee5b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 18 22:49:17 2016 -0800
test_linux_ipc: Finish this test project
I updated both the pshm_write and pshm_read applications to
the "Unnamed semaphores example" paradigm mentioned in the
README, and also implemented a pshm_unlink application to deal
with cleanup of the shared memory if psh_write (which creates
that memory) must be interrupted for some reason.
Tested by: Alan W. Irwin <airwin.users.sourceforge.net> on Linux
(Debian testing) following the directions in the README. The result
was a big efficiency success; a file copy using the combination of
pshm_write and pshm_read only required 0.3 seconds to complete for
a 25MB file.
M cmake/test_linux_ipc/CMakeLists.txt
A cmake/test_linux_ipc/README
M cmake/test_linux_ipc/pshm.h
M cmake/test_linux_ipc/pshm_read.c
A cmake/test_linux_ipc/pshm_unlink.c
M cmake/test_linux_ipc/pshm_write.c
commit 1bd16d4572c2177f9f7db5f5d514fdb6941eacd3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 18 15:58:23 2016 -0800
test_linux_ipc: make pshm_write and pshm_read buildable and implement build system for these two applications
To make these two applications buildable on their own, I replaced
their reliance on tlpi headers and error handling with local #includes
and local error handling (typically a call to fprintf(stderr,...)
followed by exit).
Note that although these two applications are now buildable more has
to be done to make them compatible with the "Unnamed semaphores example"
that is outlined starting at page 73 of
<http://man7.org/conf/lca2013/IPC_Overview-LCA-2013-printable.pdf>.
I have already started that process by adding pshm.h, but more is
necessary.
A cmake/test_linux_ipc/CMakeLists.txt
A cmake/test_linux_ipc/pshm.h
M cmake/test_linux_ipc/pshm_read.c
M cmake/test_linux_ipc/pshm_write.c
commit cfbc8f6d9d600d82e0f9f754e44c7836960c5555
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Nov 17 21:21:09 2016 -0800
test_linux_ipc: Initial commit
The point of this project is to familiarize PLplot developers with an
efficient Linux IPC example as an aid toward reaching the goal of
figuring out how to make the IPC between the wxwidgets device and the
wxPLViewer viewing application much more efficient on Linux.
(Currently there is plenty of room to reach that goal because that
combination of software is losing up to two orders of magnitude in
practical speed because of excessive idle times for the current way it
uses Linux shared memory IPC.)
Michael Kerrisk's book, "The Linux Programming Interface" includes
Linux IPC software that is licensed under GPL version 3, (see
<http://man7.org/tlpi/code/>.) We start this project with three files
from that distribution (one concerns the licensing text, one is source
code copied from tlpi-dist/pshm/pshm_write.c that implements an
application that writes to shared memory, and one is source code
copied from tlpi-dist/pshm/pshm_read.c that implements an application
that reads from shared memory.)
Our further goals are as follows:
1. Modify these source code files following the shared memory and
unnamed POSIX semaphores outline example given starting on page 71 of
Michael Kerrisk's talk (which came after his book) entitled "An
Introduction to Linux IPC" (see
<http://man7.org/conf/lca2013/IPC_Overview-LCA-2013-printable.pdf>.
2. Create a build system for these "pshm_write" and "pshm_read" applications.
3. Implement a test script to evaluate the communication efficiency of
these two applications by time comparisons between,
for example,
a. cat < input_file >| output_file
b. cat < input file |cat - >| output_file
c. pshm_write <input file && pshm_read >| output_file
where input file is a file that is sufficiently large so that the
shortest of these examples (which should be "a" for obvious reasons)
will take roughly one second to complete making all these examples
easy to time accurately.
A cmake/test_linux_ipc/COPYING.gpl-v3
A cmake/test_linux_ipc/pshm_read.c
A cmake/test_linux_ipc/pshm_write.c
commit 7bea18c1240929306662afa3082b703f5bdc6966
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Nov 17 01:03:37 2016 -0800
Build system: Move to automoc for both Qt4 and Qt5 cases
Via the test_automoc project and advice given on the cmake-devel list
I finally figured out how to make automoc work properly. Since
automoc is recommended now and does seem to be a bit smoother than the
qt4_wrap_cpp or qt5_wrap_cpp macro cases, have moved from those macros
to automoc for both Qt4 and Qt5 which also allowed a substantial
cleanup of the build system CMake code for the Qt case and also a
minor cleanup of the Qt-related C++ code.
Drop test_qt_example and test_pyqt5_example from general tests for the
qt5 case because bug <https://sourceforge.net/p/plplot/bugs/158/>
still persists (very likely because of bugs in the Qt5 library memory
management that have not been corrected yet) even with this new qt5
support method.
Note for the Qt5 case, we still do not support pkg-config correctly.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_bmpqt=ON -DPLD_epsqt=OFF -DPLD_extqt=ON -DPLD_jpgqt=ON -DPLD_memqt=ON -DPLD_pdfqt=ON -DPLD_pngqt=ON -DPLD_ppmqt=ON -DPLD_qtwidget=ON -DPLD_svgqt=ON -DPLD_tiffqt=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_qt=ON -DENABLE_cxx=ON -DENABLE_python=ON -DENABLE_pyqt5=ON -DENABLE_pyqt4=ON -DPLPLOT_USE_QT5=OFF" --do_test_traditional_install_tree yes
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_bmpqt=ON -DPLD_epsqt=OFF -DPLD_extqt=ON -DPLD_jpgqt=ON -DPLD_memqt=ON -DPLD_pdfqt=ON -DPLD_pngqt=ON -DPLD_ppmqt=ON -DPLD_qtwidget=ON -DPLD_svgqt=ON -DPLD_tiffqt=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_qt=ON -DENABLE_cxx=ON -DENABLE_python=ON -DENABLE_pyqt5=ON -DENABLE_pyqt4=ON -DPLPLOT_USE_QT5=ON" --do_test_traditional_install_tree no
(Note I dropped the traditional install tree from the Qt5 case for the
reason stated above.) Neither of these comprehensive tests showed any
build or run-time issues.
I also used the -DVALGRIND_ALL_TESTS=ON cmake option so that
make test_c_pngqt
tested each of standard examples with -dev pngqt using valgrind.
For the Qt4 case, there were no memory management errors (although
there were memory leak issues). So no segfaults due to a corrupted
memory heap are possible. For Qt5, 22 or the 33 examples did have
memory management issues (typically invalid reads). I attribute these
issues to bugs in the Qt5 library memory management that have not been
corrected yet because Qt4 gives such a clean valgrind result, and our
qt device driver generally uses Qt5 and Qt5 in exactly the same
manner.
M bindings/qt_gui/CMakeLists.txt
M bindings/qt_gui/plqt.cpp
M cmake/modules/qt.cmake
M drivers/CMakeLists.txt
M examples/CMakeLists.txt
M examples/c++/CMakeLists.txt
M examples/plplot_configure.cmake_installed_examples.in
M include/CMakeLists.txt
D include/moc_files.h.in
M plplot_test/CMakeLists.txt
M plplot_test/plplot-test-interactive.sh.in
M src/CMakeLists.txt
M src/plplotConfig.cmake
commit d71e484cb9177865981e913984a725752061342b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Nov 12 22:11:10 2016 -0800
test_automoc project: Add the helloworld_automoc_same_include2 target
This additional target is similar to both the
helloworld_automoc_same_include and helloworld_automoc_same_include1
targets. The implementation codes for the three targets are all
identical and contain both
(and at the bottom of the file)
The idea is for all three targets to generate name collisions for the
generated moc_test_q_object.cpp file in the same build tree
subdirectory to see whether CMake-3.7.0 diagnoses this issue. The
helloworld_automoc_same_include1 target uses the identical source code
in the same directory as the helloworld_automoc_same_include target,
while the helloworld_automoc_same_include2 target does the same thing
for source code that is copied from the directory used by the first
two targets to a different directory. I thought that directory
difference might force cmake-3.7.0 to generate the name collision
diagnostic that is mentioned in the documentation, but no such
diagnostic was generated for any of these cases.
M cmake/test_automoc/CMakeLists.txt
M cmake/test_automoc/README
A cmake/test_automoc/src_same_include_alt/helloworld.cpp
A cmake/test_automoc/src_same_include_alt/test_q_object.h
commit c8874bd90d672ef40f8fdd4daf9667a4abb3849f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Nov 12 18:12:52 2016 -0800
test_automoc: create this test project
The point of test_automoc is to demonstrate the various valid ways (most
using the AUTOMOC target property) to use moc with a Qt5 project.
A cmake/test_automoc/CMakeLists.txt
A cmake/test_automoc/README
A cmake/test_automoc/include/test_q_object.h
A cmake/test_automoc/src_noinclude/helloworld.cpp
A cmake/test_automoc/src_same_include/helloworld.cpp
A cmake/test_automoc/src_same_include/test_q_object.h
A cmake/test_automoc/src_same_noinclude/helloworld.cpp
A cmake/test_automoc/src_same_noinclude/helloworld.h
commit 24864eff46e904bcce1e58038cde8e002b2ff262
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Nov 10 13:24:08 2016 -0800
Build system: Fix minor misspellings
The change was
runAlldemos ==> runAllDemos
is this only affected commented out code or else cmake message commands.
M examples/CMakeLists.txt
commit 0b9182b93db6d6ade4456cb32e711a2f76a3fbaa
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Nov 10 11:54:31 2016 -0800
libplplottcltk, Tcl/Tk examples; Fix bugs and move to pure redacted argument lists
The bugs that were fixed are the following:
1. A redaction bug in plsurf3dlCmd in tclAPI.c (for the redacted argument case,
indexxmax was not redacted) was fixed. examples/tcl/x08.tcl had to be
changed to use this correct redaction for plsurf3dl.
2. Bad Boolean logic for the argc checking in tclcmd.tpl was fixed.
(Without this fix, the number of arguments was effectively never
wrong, so issuing PLplot commands with the wrong number of arguments
lead to segfaults and/or matrix errors.) An additional upgrade to
tclcmd.tpl was to identify the correct redacted call that should be
used whenever argc checking found an issue.
The additional changes that were made were the following:
1. libplplottcltk was changed to support only the redacted API for all
PLplot commands. (You can go back to supporting both the non-redacted
and redacted API's by changing the variable if_non_redacted from 0 to
1 in bindings/tcl/pltclgen.tcl, and by #define'ing
PLPLOTTCLTK_NON_REDACTED_API in bindings/tcl/tclAPI.c. But I
anticipate we will never actually want to do that.)
2. All Tcl/Tk examples that failed with the new pure redaction version
of libplplottcltk had their syntax updated to use the redacted API.
Other than documentation updates for Tcl/Tk, this commit should conclude
the effort to move to a pure redacted API for Tcl/Tk (unless further
testing finds bugs or identifies some platform issues).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the "test_noninteractive" and
test_interactive targets with no obvious build or run-time issues
and no PostScript differences.
N.B. similar testing on other platforms is requested.
M bindings/tcl/CMakeLists.txt
M bindings/tcl/pltclgen.tcl
M bindings/tcl/tclAPI.c
M bindings/tcl/tclcmd.tpl
M examples/tcl/plgrid.tcl
M examples/tcl/x08.tcl
M examples/tcl/x13.tcl
M examples/tcl/x24.tcl
M examples/tcl/x25.tcl
M examples/tcl/x26.tcl
M examples/tcl/x27.tcl
M examples/tcl/x29.tcl
M examples/tk/tk02.in
M examples/tk/tk03.in
commit 2491587cd6f242b4a6f42c7922b14e1681d440de
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Nov 10 11:29:15 2016 -0800
tclmatrix library: Fix recently introduced redim bug
When an array is redimensioned, must reallocate matPtr->indices.
examples/tcl/plot.tcl (which uses the redim matrix operator) segfaults
without this obvious fix.
I also took this opportunity to fix the redacted argument
issues with examples/tcl/plot.tcl.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running the test_noninteractive target (which
runs plot.tcl as part of that test). No segfaults occurred. I also
ran the following specific test of plot.tcl:
make test_noninteractive #to build the prerequisites if not done already
make xwin
cd examples/tcl
valgrind ../../bindings/tcl/pltcl -dev xwin -np
plinit
source plot.tcl
plot stats.log {1 4}
plot stats.log
plot r.dat
plot plot.dat
exit
No memory management errors were reported, i.e.,
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
M bindings/tcl/tclMatrix.c
M examples/tcl/plot.tcl
commit e9c917a896e2830d3b40426381c593c2d63fb43d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Nov 8 19:23:05 2016 -0800
plplottcltk library: comment, clean up, and reorganize Tcl code used to generate the interface
The added comments are by no means complete and were simply added as I
finally understood the purpose of various bits of the Tcl code. The
cleanup was to remove some set commands for variables which are not
used. The reorganization was to replace the "round" loop by one call
(if nredacted == 0) or two or three calls (if nredacted > 0) to a new
process_args procedure which does most of the work that formerly
resided in the "round" loop. This reorganization includes optional
logic for removing the generation of the non-redacted API for Tcl, but
that code has not been exercised yet (because if_non_redacted is set
to 1).
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the plplottcltk library and confirming
that the three source code files generated by the updated pltclgen.tcl
(tclgen.c, tclgen.h, and tclgen_s.h in bindings/tcl in the build tree)
are identical to what was produced by the previous version of
pltclgen.tcl.
M bindings/tcl/pltclgen.tcl
commit ad34b3ac85e0cac718c121e232561e9804593a38
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Nov 6 16:41:12 2016 -0800
libtclmatrix: fix bugs in matrix max/min and reimplement matrix initialization and assignment
The last libtclmatrix commit introduced bugs in the matrix max min
C logic (such that a default length always lead to an error). These
bugs have been fixed in this commit.
Note that for the previous matrix initialize code, there were severe
memory management issues if the RHS had more numerical items than fit
into a column of the LHS matrix, and for other kinds of shape
mismatches silent failures occurred. In other words, the only way the
old code worked was if the size and shape of the lists on the RHS was
exactly equivalent to the size and shape of the matrix on the LHS. So
that precluded, for example using a matrix slice on the RHS (which
gets interpreted as a shallow list) if the LHS matrix is smaller than
that RHS shallow list or if the LHS matrix is multi-dimensional.
Because of these issues, I reimplemented the matrix initialization so
there are no constraints on the shape or size of the matrix
initializer list that appears on the RHS of the "=". As the result of
this change, the following exotic matrix initialize example works:
pltcl> matrix a f 2 2 3 = {{{{1} {2}}}} 3 4 5 6 7 8 9 10 11 12 13 14
a
pltcl> a dump
1.0 2.0 3.0
4.0 5.0 6.0
7.0 8.0 9.0
10.0 11.0 12.0
Note a less exotic but more useful example demonstrating
resizing/reshaping capability is the following:
pltcl> matrix x f 2 7 = 0 1 2 3 4 5 6 7 8 9 10 11 12 13
x
pltcl> x dump
0.0 1.0 2.0 3.0 4.0 5.0 6.0
7.0 8.0 9.0 10.0 11.0 12.0 13.0
pltcl> matrix a f 2 2 3 = [x 0 :]
a
pltcl> a dump
0.0 1.0 2.0
3.0 4.0 5.0
6.0 0.0 0.0
0.0 0.0 0.0
Note that the array and lists are processed in the natural order (row
major order as in C for the array or array slice, and in the order of
the list items that are not lists themselves when the RHS is an
explicit list rather than a matrix slice. Furthermore, if too many
initializers are used on the RHS as in the first example, they are
quietly ignored; while if too few initializers are used on the RHS as
in the second example, then the corresponding LHS matrix elements
are left unchanged from their initial 0 (or 0.) values they are given
before further array initialization is attempted.
Note array assignment had substantial issues as well. (Only one
number used from the RHS of the "=" to initialize the entire
specified slice of the matrix on the LHS.) So I reimplemented
that as well so that all forms of the RHS of the "=" above can
also be used on the RHS of the "=" of an array slice assignment, e.g.,
pltcl> matrix x f 2 7 = 0 1 2 3 4 5 6 7 8 9 10 11 12 13
x
pltcl> matrix a f 2 2 3
a
pltcl> a : : : = [x 1 :]
pltcl> a dump
7.0 8.0 9.0
10.0 11.0 12.0
13.0 0.0 0.0
0.0 0.0 0.0
The new rule for matrix assignment is if the RHS is a pure single
number that is completely valid according to strtod (for the
floating-point matrix case) or strtol (for the integer matrix case),
then all matrix elements on the LHS are updated to that number, but
otherwise the same routine is called to assign values to the elements
of the LHS matrix slice as is used for matrix initialization with
elements outside the LHS slice unaffected. Furthermore, if too many
values are specified on the RHS, they are quietly ignored; while if
too few values are specified on the RHS then the corresponding LHS
matrix slice elements are left unchanged from their previous values.
As a test of this new matrix initialization and assignment code, I
have added some matrix initialization and assignment examples to the
already existing slice examples in bindings/tcl/test_tclmatrix.tcl.
This file is used as the source of all tclmatrix examples tested by
the check_libtclmatrix_capabilities target, and I have adjusted the
comparison output for that target, bindings/tcl/test_tclmatrix.out, to
be consistent with these additional test examples.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_interactive, test_noninteractive,
and check_libtclmatrix_capabilities targets with no obvious build or
run-time issues. (The test_interactive target originally found the
matrix max/min bug which has been fixed in this commit.) I also
sourced bindings/tcl/test_tclmatrix.tcl under bindings/tcl/tclsh when
run with valgrind, and there were no memory management issues reported
by valgrind. Finally, I have tried the examples specified above under
valgrind and obtained the stated results with no memory management
issues being reported by valgrind.
M bindings/tcl/tclMatrix.c
M bindings/tcl/tclMatrix.h
M bindings/tcl/test_tclmatrix.out
M bindings/tcl/test_tclmatrix.tcl
commit aab39943a215acb28d45d85ae27995d3bc17f8a3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 4 23:59:46 2016 -0700
libtclmatrix: Add extensive index slice capability
This implementation was inspired by the Python index slice capability
and closely follows that model. I have created the target
"check_libtclmatrix_capabilities" to extensively test this new
slice capability by running all the Tcl commands in
bindings/tcl/test_tclmatrix.tcl under pltcl and comparing those
output results with the prior version located at
bindings/tcl/test_tclmatrix.out.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running the "check_libtclmatrix_capabilities" target
with no issues.
M bindings/tcl/CMakeLists.txt
M bindings/tcl/tclMatrix.c
M bindings/tcl/tclMatrix.h
A bindings/tcl/test_tclmatrix.out
A bindings/tcl/test_tclmatrix.sh.in
A bindings/tcl/test_tclmatrix.tcl
commit 73b98de98796a63e55bbcdd6b91e459e10fed301
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Oct 29 03:27:25 2016 -0700
Build system: filter source tree and build tree -I flags from pkg-config files
Such -I flags do occur, e.g., for the tk device driver when it is
embedded in libplplot when -DENABLE_DYNDRIVERS=OFF, but I cannot
imagine any case where the resulting pkg-config file should be
generating such -I flags for applications and libraries which link to
the installed PLplot libraries. In other words, the install tree is
supposed to work when the source tree and build tree have been
completely removed, and the previous -I flags in the pkg-config files
that referred to source-tree and/or build-tree locations violated this
philosophy. Thus, our build system now filters these -I flags out
of the generated pkg-config files as a matter of principle.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> as part of the
successful comprehensive testing of the last commit which was limited
to just the Tcl/Tk components of PLplot. So the component testing was
limited, but did include running cmake to configure at least two *.pc
files without issues, and running and testing the traditional build of
the installed examples occurred without running into issues so the
conclusion is there is unlikely to be any typographical error in the
changes of this commit (which simply added the required filtering
commands to the CMake function used to configure the *.pc files).
Therefore, it is very likely this limited component testing is more
than enough for the reasons mentioned in the first paragraph, but
later on, as a matter of course, more complete component testing will
be done, and if any issues are found, this commit is separated from
other changes so should be easy to find with git bisect.
M cmake/modules/pkg-config.cmake
commit 89a2bcb12899a56f034feec2a94baa06b3d8bfa9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Oct 25 10:53:45 2016 -0700
Build system: Add non-redacted Tcl/Tk bindings and examples
In future we plan to drop all support for non-redacted Tcl arguments
so this commit preserves the status of the Tcl/Tk bindings and
examples just before commit dbc889263 (the first commit where Arjen
made changes concerning redaction of Tcl arguments). Changes to our
build system (the option USE_NON_REDACTED_TCL_TK) have also been made.
This option defaults to OFF, but if the user wants to use non_redacted
Tcl/Tk bindings he only needs to specify -DUSE_NON_REDACTED_TCL_TK=ON
to get access to the Tcl/Tk bindings and examples just prior to commit
dbc889263.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by renaming what should be unused Tcl/Tk bindings
and examples source directories when -DUSE_NON_REDACTED_TCL_TK=ON
to something else to make sure those directories that should be
unused really are and the non-redacted directories are used instead
and then running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ntk=ON -DPLD_tk=ON -DPLD_tkwin=ON -DPLD_xwin=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_tcl=ON -DENABLE_tk=ON -DENABLE_itcl=ON -DENABLE_itk=ON -DUSE_NON_REDACTED_TCL_TK=ON
The result had no obvious build or run-time errors. Furthermore, all
make results from the build tree only referred to the regex
plplot.git[^ ]*(tcl|tk) appropriately, and all make results from
the two different build and test systems for the installed examples
and all the generated *.pc files had no references to "non_redacted"
(as expected).
M bindings/CMakeLists.txt
A bindings/non_redacted_tcl/CMakeLists.txt
A bindings/non_redacted_tcl/README.tclAPI
A bindings/non_redacted_tcl/global_defines.sed
A bindings/non_redacted_tcl/matrixInit.c
A bindings/non_redacted_tcl/pkgIndex.tcl.in
A bindings/non_redacted_tcl/plapi.tpl
A bindings/non_redacted_tcl/plitclgen
A bindings/non_redacted_tcl/plitclgen.tcl
A bindings/non_redacted_tcl/plplot_parameters.h
A bindings/non_redacted_tcl/pltcl.c
A bindings/non_redacted_tcl/pltcl.h
A bindings/non_redacted_tcl/pltclgen
A bindings/non_redacted_tcl/pltclgen.tcl
A bindings/non_redacted_tcl/tclAPI.c
A bindings/non_redacted_tcl/tclMain.c
A bindings/non_redacted_tcl/tclMatrix.c
A bindings/non_redacted_tcl/tclMatrix.h
A bindings/non_redacted_tcl/tclcmd.tpl
A bindings/non_redacted_tk-x-plat/CMakeLists.txt
A bindings/non_redacted_tk-x-plat/Memberscope.tcl
A bindings/non_redacted_tk-x-plat/Plplotter_Init.c
A bindings/non_redacted_tk-x-plat/Plplotwin.tcl
A bindings/non_redacted_tk-x-plat/Plwindow.tcl
A bindings/non_redacted_tk-x-plat/pkgIndex.tcl.in
A bindings/non_redacted_tk-x-plat/plbarchart.tcl
A bindings/non_redacted_tk-x-plat/plplotter.c
A bindings/non_redacted_tk-x-plat/pltimeseries.tcl
A bindings/non_redacted_tk-x-plat/pltkwd.h
A bindings/non_redacted_tk-x-plat/plwidget2.tcl
A bindings/non_redacted_tk-x-plat/tclIndex
A bindings/non_redacted_tk/CMakeLists.txt
A bindings/non_redacted_tk/FileSelector.tcl
A bindings/non_redacted_tk/PLWin.itk
A bindings/non_redacted_tk/PLXWin.itk
A bindings/non_redacted_tk/Pltk_Init.c
A bindings/non_redacted_tk/Pltkwin.tcl
A bindings/non_redacted_tk/about.tcl
A bindings/non_redacted_tk/app-defaults/PLplot.large.ad
A bindings/non_redacted_tk/app-defaults/PLplot.medium.ad
A bindings/non_redacted_tk/app-defaults/PLplot.small.ad
A bindings/non_redacted_tk/app-defaults/README
A bindings/non_redacted_tk/cmap0a.pal
A bindings/non_redacted_tk/cmap1a.pal
A bindings/non_redacted_tk/cmap1a1.pal
A bindings/non_redacted_tk/cmap1b.pal
A bindings/non_redacted_tk/cmap1c.pal
A bindings/non_redacted_tk/cmap1d.pal
A bindings/non_redacted_tk/help_gui.tcl
A bindings/non_redacted_tk/help_keys.tcl
A bindings/non_redacted_tk/help_tcltk.tcl
A bindings/non_redacted_tk/pkgIndex.tcl.in
A bindings/non_redacted_tk/plclient.tcl
A bindings/non_redacted_tk/plcolor.tcl
A bindings/non_redacted_tk/plconfig.tcl
A bindings/non_redacted_tk/pldefaults.tcl
A bindings/non_redacted_tk/plframe.c
A bindings/non_redacted_tk/plplot.tcl
A bindings/non_redacted_tk/plr.c
A bindings/non_redacted_tk/plserver.c
A bindings/non_redacted_tk/plserver.h
A bindings/non_redacted_tk/plserver.tcl
A bindings/non_redacted_tk/pltk.h
A bindings/non_redacted_tk/pltkd.h
A bindings/non_redacted_tk/pltools.tcl
A bindings/non_redacted_tk/plwidget.tcl
A bindings/non_redacted_tk/stupidtk.c
A bindings/non_redacted_tk/tcpip.c
A bindings/non_redacted_tk/tcpip.h
A bindings/non_redacted_tk/tkMain.c
A bindings/non_redacted_tk/tkshell.c
M cmake/modules/tcl-related.cmake
M cmake/modules/tk.cmake
M examples/CMakeLists.txt
A examples/non_redacted_tcl/CMakeLists.txt
A examples/non_redacted_tcl/README.tcldemos
A examples/non_redacted_tcl/plgrid.tcl
A examples/non_redacted_tcl/plot.dat
A examples/non_redacted_tcl/plot.tcl
A examples/non_redacted_tcl/pltcl_standard_examples.in
A examples/non_redacted_tcl/r.dat
A examples/non_redacted_tcl/stats.log
A examples/non_redacted_tcl/tcldemos.tcl
A examples/non_redacted_tcl/tclsh_standard_examples.in
A examples/non_redacted_tcl/x00
A examples/non_redacted_tcl/x00.tcl
A examples/non_redacted_tcl/x01
A examples/non_redacted_tcl/x01.tcl
A examples/non_redacted_tcl/x02
A examples/non_redacted_tcl/x02.tcl
A examples/non_redacted_tcl/x03
A examples/non_redacted_tcl/x03.tcl
A examples/non_redacted_tcl/x04
A examples/non_redacted_tcl/x04.tcl
A examples/non_redacted_tcl/x05
A examples/non_redacted_tcl/x05.tcl
A examples/non_redacted_tcl/x06
A examples/non_redacted_tcl/x06.tcl
A examples/non_redacted_tcl/x07
A examples/non_redacted_tcl/x07.tcl
A examples/non_redacted_tcl/x08
A examples/non_redacted_tcl/x08.tcl
A examples/non_redacted_tcl/x09
A examples/non_redacted_tcl/x09.tcl
A examples/non_redacted_tcl/x10
A examples/non_redacted_tcl/x10.tcl
A examples/non_redacted_tcl/x11
A examples/non_redacted_tcl/x11.tcl
A examples/non_redacted_tcl/x12
A examples/non_redacted_tcl/x12.tcl
A examples/non_redacted_tcl/x13
A examples/non_redacted_tcl/x13.tcl
A examples/non_redacted_tcl/x14
A examples/non_redacted_tcl/x14.tcl
A examples/non_redacted_tcl/x15
A examples/non_redacted_tcl/x15.tcl
A examples/non_redacted_tcl/x16
A examples/non_redacted_tcl/x16.tcl
A examples/non_redacted_tcl/x17
A examples/non_redacted_tcl/x17.tcl
A examples/non_redacted_tcl/x18
A examples/non_redacted_tcl/x18.tcl
A examples/non_redacted_tcl/x19
A examples/non_redacted_tcl/x19.tcl
A examples/non_redacted_tcl/x20
A examples/non_redacted_tcl/x20.tcl
A examples/non_redacted_tcl/x21
A examples/non_redacted_tcl/x21.tcl
A examples/non_redacted_tcl/x22
A examples/non_redacted_tcl/x22.tcl
A examples/non_redacted_tcl/x23
A examples/non_redacted_tcl/x23.tcl
A examples/non_redacted_tcl/x24
A examples/non_redacted_tcl/x24.tcl
A examples/non_redacted_tcl/x25
A examples/non_redacted_tcl/x25.tcl
A examples/non_redacted_tcl/x26
A examples/non_redacted_tcl/x26.tcl
A examples/non_redacted_tcl/x27
A examples/non_redacted_tcl/x27.tcl
A examples/non_redacted_tcl/x28
A examples/non_redacted_tcl/x28.tcl
A examples/non_redacted_tcl/x29
A examples/non_redacted_tcl/x29.tcl
A examples/non_redacted_tcl/x30
A examples/non_redacted_tcl/x30.tcl
A examples/non_redacted_tcl/x31
A examples/non_redacted_tcl/x31.tcl
A examples/non_redacted_tcl/x33
A examples/non_redacted_tcl/x33.tcl
A examples/non_redacted_tk/CMakeLists.txt
A examples/non_redacted_tk/Makefile.examples.in
A examples/non_redacted_tk/README.tkdemos
A examples/non_redacted_tk/plgrid.in
A examples/non_redacted_tk/plserver_runAllDemos.in
A examples/non_redacted_tk/plserver_standard_examples.in
A examples/non_redacted_tk/runAllDemos.tcl
A examples/non_redacted_tk/runExtendedDemos.tcl
A examples/non_redacted_tk/tk01.in
A examples/non_redacted_tk/tk02.in
A examples/non_redacted_tk/tk03.in
A examples/non_redacted_tk/tk04.in
A examples/non_redacted_tk/tkdemos.tcl
A examples/non_redacted_tk/wish_runAllDemos.in
A examples/non_redacted_tk/wish_standard_examples.in
A examples/non_redacted_tk/xtk01.c
A examples/non_redacted_tk/xtk02.c
A 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 3ab6396f0da8e1b7109ea3323eeb0ef81d215a8a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Oct 19 17:32:52 2016 -0700
Update FindwxWidgets.cmake to version 3.7.0-rc2
This version fixes CMake bug #16366 concerning finding unversioned
VS-built directory prefixes. See the cmake git commit
<https://gitlab.kitware.com/cmake/cmake/commit/52e8fa2312c73338c7fac38e7c2b30f136f4d247>
for further details.
I also reduced our change to this file to just the following:
--- /home/software/cmake/cmake.git/Modules/FindwxWidgets.cmake 2016-10-19 17:40:45.066875781 -0700
+++ cmake/modules/FindwxWidgets.cmake 2016-10-19 17:51:09.924437386 -0700
@@ -924,7 +924,7 @@
#=====================================================================
#=====================================================================
-include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
+include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(wxWidgets
REQUIRED_VARS wxWidgets_LIBRARIES wxWidgets_INCLUDE_DIRS
This one-line change is necessary in order for this file to be used by
PLplot. This means our licensing text for this file is now identical
to the official CMake version (thanks to Kitware adopting much simpler
instructions for complying with their OSI-approved BSD 3-clause
license) which in turn allowed us to simplify the description of
licensing terms that we maintain in the Copyright file.
So aside from licensing details, the effective result of this commit
is the above bug fix is adopted and the invocation of
find_package_handle_standard_args has been changed from a home-brew we
had before to the invocation method used in the official CMake version
of FindwxWidgets.cmake.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by invoking both cmake-3.0.2 and cmake-3.5.2 to
configure PLplot. For both find_package_handle_standard_args cases
(versions 3.0.2 and 3.5.2), wxWidgets was successfully found using the
updated invocation of find_package_handle_standard_args. Further
testing of this updated wxWidgets find module (especially
on non-Linux platforms) is requested.
M Copyright
M cmake/modules/FindwxWidgets.cmake
commit 018ed7354db242e5dddf6e373d97a97e0c0045b2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Oct 18 00:28:36 2016 -0700
Build system: Update to the latest Qt5 support method
This latest Qt5 support method (documented in
<http://doc.qt.io/qt-5/cmake-manual.html>) essentially consists of
appending the targets Qt5::Svg Qt5::Gui Qt5::PrintSupport to the
Qt5-related target_link_libraries commands. The above URL also
recommends using automoc and effectively deprecates qt5_wrap_cpp by
classifying it as an old method. However, automoc turned out to be a complete dead
end because it could not handle header files (e.g., include/qt.h) in
different directores than the library or driver dll source). Also,
when I temporarily worked around that issue with symlinks, it turned
out the automoc results were identical (except for identifying the
header file as the symlink location rather than actual location) with
qt5_wrap_cpp results on the appropriate absolute header location. So
I stuck with using qt5_wrap_cpp since it worked on the actual location
of the header file and thus did not require symlinks.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie with appropriate Qt5 development packages installed)
by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_bmpqt=ON -DPLD_epsqt=OFF -DPLD_extqt=ON -DPLD_jpgqt=ON -DPLD_memqt=ON -DPLD_pdfqt=ON -DPLD_pngqt=ON -DPLD_ppmqt=ON -DPLD_qtwidget=ON -DPLD_svgqt=ON -DPLD_tiffqt=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_qt=ON -DENABLE_cxx=ON -DENABLE_python=ON -DENABLE_pyqt5=ON -DPLPLOT_USE_QT5=ON" --do_test_traditional_install_tree no
Note, we specifically do not test the traditional (Makefile +
pkg-config) install tree since more work needs to be done to configure
the pkg-config files properly with the appropriate link flags
determined with this new Qt5 support method. There were no errors in
the above test which implies this implementation of the new Qt5
support method is working well (so long as you avoid using pkg-config
for now).
M bindings/qt_gui/CMakeLists.txt
M bindings/qt_gui/pyqt5/CMakeLists.txt
M cmake/modules/qt.cmake
M drivers/CMakeLists.txt
M examples/CMakeLists.txt
M examples/c++/CMakeLists.txt
M include/CMakeLists.txt
M include/qt.h
M src/CMakeLists.txt
commit 10fe84bca28536f5b0ea3afd786dd97ede780d11
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Oct 15 15:24:43 2016 -0700
pyqt5 binding and example: implement test support for pyqt5
In particular, implement the test_pyqt5 target.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by installing the python-pyqt5 and pyqt5-dev packages,
configuring the PLplot build with the -DPLPLOT_USE_QT5=ON cmake option,
and building test_pyqt5. The result was no obvious build errors and
the run-time test of examples/python/pyqt5_example.py that is set up
and run by the test_pyqt5 target worked perfectly. In sum, pyqt5 is
looking good with PLplot!
M cmake/modules/summary.cmake
M examples/CMakeLists.txt
M examples/plplot_configure.cmake_installed_examples.in
M examples/python/CMakeLists.txt
commit 536f94b9f91f975fdc5debcb4a0a221cb386ea7a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Oct 15 13:47:10 2016 -0700
Qt5 bindings: Bump minimum acceptable Qt5 version from 5.2.0 to 5.3.1
N.B. Currently, MinGW-w64/MSYS2 packages Qt5 version 5.3.1, Cygwin
packages Qt5 version 5.5.1, and most Linux distributions package at
least Qt5 version 5.3.2 (e.g., Debian Jessie packages that version
despite that distro being fairly conservative about adopting new
versions of packages). So adopting a minimum acceptable version of
5.3.1 should satisfy the needs of MinGW-w64/MSYS2, Cygwin, and most
Linux distros. The obvious exception is likely the so-called
enterprise-class Linux distros, but we don't go out of our way to
support such distros since they typically package really old versions
of every library/software package that often are no longer
supported by modern PLplot.
M cmake/modules/qt.cmake
M src/plplotConfig.cmake
commit c58020c9f1a154eda25488148f133ee108930048
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Oct 15 09:19:36 2016 -0700
Qt5 bindings: Fix vertical alignment issues
As of Debian Jessie Qt5.3.2, the vertical alignment issue that was in
previous versions of Qt5 has been fixed. Therefore, have removed
compensating vertical offset in our own code that was required to
work around that Qt5 bug.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by installing the qtbase5-dev and libqt5svg5-dev
Debian packages, configuring the PLplot build using the cmake option
-DPLPLOT_USE_QT5=ON, building qt and _plplotcmodule_fixed (our Python
interface) and running the alignment test,
examples/python/test_circle.py -dev qtwidget
. The UTF8 "heavy multiplication x", "number sign", "four
teardrop-spoked asterisk", and "spoked asterisk" glyphs all appeared
to have perfect alignment. The "large circle + light diagonal cross"
and "heavy plus" glyphs had slightly bad vertical alignment, and the
rest of the glyphs tested had bad vertical alignment. I attribute both the
perfect and non-perfect results to how well the particular glyph was centred in
the glyph box for the particular default font being chosen. I also
checked that standard examples 00 and 02 had good vertical alignment
with -dev qtwidget.
I also performed similar checks for -dev pdfqt (which followed the
alignment for -dev qtwidget as expected) and -dev svgqt (which
unexpectedly had different vertical AND horizontal alignment than the
other qt devices which I attribute to alignment bugs in the
libqt5svg5-dev package for the 5.3.2 version of Qt5).
In sum, the alignment issues that plagued our qt devices for Qt5 prior
to 5.3.2 seem to be gone at least for -dev qtwidget and -dev pdfqt,
and presumably later versions of Qt5 have fixed/will fix the -dev
svgqt vertical and horizontal alignment issues I discovered.
M bindings/qt_gui/plqt.cpp
commit 4963a8deac0df7d2c3e064299e5bc5b4c633f07d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Oct 4 12:10:32 2016 -0700
Create script to remove trailing blanks from essentially all text files in our source tree
This script contains the mass 'sed' command that was recently used to
clean up trailing blank problems in our source tree. Thus, this
script should be available for periodic use in the future to remove
any trailing blanks that have crept into our source tree since the
recent cleanup. The sed command includes a regex to exclude certain
files (binary files, licensing text, etc.) from the cleanup, and that
regex may need additional review from time to time.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by temporarily adding a blank to the end of line for
one of our files, and running the script. As expected, the script
changed that file to remove the trailing blank, and made no other
changes to our source tree (since the trailing blank problem has
recently been cleaned up).
A scripts/remove_trailing_blanks.sh
commit 923a4f2aac7a19084fe4a2d17b6c5c22211b7215
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Oct 2 01:53:10 2016 -0700
Update the release notes consistent with the recent restoration of backwards compatibility for our Ada binding
M README.release
commit 4e9797dc494955d998c1e493b598ae9fa4bde838
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Oct 1 23:41:02 2016 -0700
Fix trailing space issues on most files
This fix was done piecemeal and sometimes with checks on the
find results that no binary files were affected rather than excluding
them from the start (based on the rules in .gitattributes). But
effectively the following command was used (and should be used for
future changes of this type):
sed -i -e 's? *$??' $(find . -type f |grep -E -v '\.git|\.pgm|\.gif|\.jpg|\.cgm|\.map|\.dbf|\.prj|\.shp|\.shx|\.fnt|debian/|rpm/|lib/|\.patch|libqhull/src/mem.h|COPYING.LIB' | xargs grep -l ' *$')
where the exclude pattern is designed to exclude from this change .git
directory files; all binary files according to the rules in
.gitattributes; debian, rpm, and lib directory and subdirectory files;
*.patch files; a particular epa_build file, and the LGPL licensing
text file from this change.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) using the command
scripts/comprehensive_test.sh
to comprehensively test _both_ the noninteractive and interactive
components of PLplot. The results showed no obvious configure, build,
or run-time errors, and PostScript differences only occurred for the
well-known and long-standing ocaml case.
N.B. This test is obviously not complete, but it is the most
comprehensive we have (other than daily use by large numbers of users
on all platforms) so at least it is a good indication that if some
error has been introduced by this extremely intrusive commit, it is
quite subtle and will likely be encountered by few users.
M ABOUT
M ChangeLog.release
M Copyright
M FAQ
M OLD-NEWS
M OLD-README.release
M OLDER-NEWS
M PROBLEMS
M README.Release_Manager_Cookbook
M README.developers
M README.emacs
M README.release
M README.testing
M ToDo
M bindings/ada/plplot.ads
M bindings/ada/plplot_auxiliary.adb
M bindings/ada/plplot_auxiliary.ads
M bindings/ada/plplot_standard.adb
M bindings/ada/plplot_standard.ads
M bindings/ada/plplot_thin.adb
M bindings/ada/plplot_thin.ads
M bindings/ada/plplot_traditional.adb
M bindings/ada/plplot_traditional.ads
M bindings/c++/CMakeLists.txt
M bindings/d/README.txt
M bindings/f95/CMakeLists.txt
M bindings/f95/generate_ifort_deffile.sed
M bindings/f95/plplot_small_modules.f90
M bindings/java/CMakeLists.txt
M bindings/java/README.javaAPI
M bindings/lua/CMakeLists.txt
M bindings/ocaml/plplot.ml
M bindings/ocaml/plplot.mli
M bindings/octave/BUGS
M bindings/octave/CMakeLists.txt
M bindings/octave/FGA
M bindings/octave/INSTALL
M bindings/octave/PLplot/CMakeLists.txt
M bindings/octave/PLplot/arrow.m
M bindings/octave/PLplot/arrows.m
M bindings/octave/PLplot/autostyle.m
M bindings/octave/PLplot/axis.m
M bindings/octave/PLplot/axis_set.m
M bindings/octave/PLplot/bgr.m
M bindings/octave/PLplot/bone.m
M bindings/octave/PLplot/bottom_title.m
M bindings/octave/PLplot/closeallfig.m
M bindings/octave/PLplot/closefig.m
M bindings/octave/PLplot/colormap.m
M bindings/octave/PLplot/comet.m
M bindings/octave/PLplot/contour.m
M bindings/octave/PLplot/cool.m
M bindings/octave/PLplot/copper.m
M bindings/octave/PLplot/drawnow.m
M bindings/octave/PLplot/fig.m
M bindings/octave/PLplot/fig_raise.m
M bindings/octave/PLplot/fig_state.m
M bindings/octave/PLplot/figure.m
M bindings/octave/PLplot/fill.m
M bindings/octave/PLplot/free_fig.m
M bindings/octave/PLplot/ginput.m
M bindings/octave/PLplot/grid.m
M bindings/octave/PLplot/griddata.m
M bindings/octave/PLplot/gtext.m
M bindings/octave/PLplot/hls2rgb.m
M bindings/octave/PLplot/hold.m
M bindings/octave/PLplot/hot.m
M bindings/octave/PLplot/ishold.m
M bindings/octave/PLplot/label_plot.m
M bindings/octave/PLplot/legend.m
M bindings/octave/PLplot/loglog.m
M bindings/octave/PLplot/lp_setup.m
M bindings/octave/PLplot/mesh.m
M bindings/octave/PLplot/meshc.m
M bindings/octave/PLplot/meshz.m
M bindings/octave/PLplot/mplot.m
M bindings/octave/PLplot/multiplot.m
M bindings/octave/PLplot/oneplot.m
M bindings/octave/PLplot/pink.m
M bindings/octave/PLplot/plclearplot.m
M bindings/octave/PLplot/plclg.m
M bindings/octave/PLplot/plcolormap.m
M bindings/octave/PLplot/pldef.m
M bindings/octave/PLplot/plimage.m
M bindings/octave/PLplot/plot3.m
M bindings/octave/PLplot/plot_border.m
M bindings/octave/PLplot/plot_margin.m
M bindings/octave/PLplot/plrb.m
M bindings/octave/PLplot/plsetopt.m
M bindings/octave/PLplot/polar.m
M bindings/octave/PLplot/prism.m
M bindings/octave/PLplot/rgb2hls.m
M bindings/octave/PLplot/rgbplot.m
M bindings/octave/PLplot/save_fig.m
M bindings/octave/PLplot/set_view.m
M bindings/octave/PLplot/shade.m
M bindings/octave/PLplot/shading.m
M bindings/octave/PLplot/stopdraw.m
M bindings/octave/PLplot/stripc.m
M bindings/octave/PLplot/stripc_add.m
M bindings/octave/PLplot/stripc_del.m
M bindings/octave/PLplot/struct_contains.m
M bindings/octave/PLplot/subplot.m
M bindings/octave/PLplot/subwindow.m
M bindings/octave/PLplot/support/__comet.m
M bindings/octave/PLplot/support/__pl_contour.m
M bindings/octave/PLplot/support/__pl_draw_legend.m
M bindings/octave/PLplot/support/__pl_fill.m
M bindings/octave/PLplot/support/__pl_init.m
M bindings/octave/PLplot/support/__pl_logplotit.m
M bindings/octave/PLplot/support/__pl_matstr.m
M bindings/octave/PLplot/support/__pl_mesh.m
M bindings/octave/PLplot/support/__pl_meshplotit.m
M bindings/octave/PLplot/support/__pl_opt.m
M bindings/octave/PLplot/support/__pl_plenv.m
M bindings/octave/PLplot/support/__pl_plot3.m
M bindings/octave/PLplot/support/__pl_plotit.m
M bindings/octave/PLplot/support/__pl_polargrid.m
M bindings/octave/PLplot/support/__pl_store.m
M bindings/octave/PLplot/support/__plt__.m
M bindings/octave/PLplot/surf.m
M bindings/octave/PLplot/surfc.m
M bindings/octave/PLplot/surfl.m
M bindings/octave/PLplot/text.m
M bindings/octave/PLplot/title.m
M bindings/octave/PLplot/top_title.m
M bindings/octave/PLplot/xlabel.m
M bindings/octave/PLplot/xticks.m
M bindings/octave/PLplot/ylabel.m
M bindings/octave/PLplot/yticks.m
M bindings/octave/PLplot/zlabel.m
M bindings/octave/PLplot/zoom.m
M bindings/octave/ToDo
M bindings/octave/USAGE
M bindings/octave/globals-in-scripts
M bindings/octave/misc/diffn.m
M bindings/octave/misc/gradn.m
M bindings/octave/misc/rosenbrock.m
M bindings/octave/octaverc.in
M bindings/old_f95/plplot_parameters.inc
M bindings/old_f95/plplot_types.f90.in
M bindings/python/CMakeLists.txt
M bindings/python/Plframe.py
M bindings/python/fragments.i
M bindings/python/makedocstrings.py
M bindings/python/plplot.py
M bindings/qt_gui/CMakeLists.txt
M bindings/qt_gui/pyqt4/CMakeLists.txt
M bindings/qt_gui/pyqt4/plplot_pyqt4.sip
M bindings/qt_gui/pyqt5/CMakeLists.txt
M bindings/qt_gui/pyqt5/plplot_pyqt5.sip
M bindings/qt_gui/smoke/CMakeLists.txt
M bindings/qt_gui/smoke/smokeconfig.xml
M bindings/swig-support/CMakeLists.txt
M bindings/swig-support/swig_documentation.i
M bindings/tcl/CMakeLists.txt
M bindings/tcl/pkgIndex.tcl.in
M bindings/tcl/plitclgen
M bindings/tcl/pltclgen
M bindings/tk-x-plat/Memberscope.tcl
M bindings/tk-x-plat/Plplotwin.tcl
M bindings/tk-x-plat/Plwindow.tcl
M bindings/tk-x-plat/pkgIndex.tcl.in
M bindings/tk-x-plat/plbarchart.tcl
M bindings/tk-x-plat/pltimeseries.tcl
M bindings/tk-x-plat/plwidget2.tcl
M bindings/tk/CMakeLists.txt
M bindings/tk/FileSelector.tcl
M bindings/tk/Pltkwin.tcl
M bindings/tk/about.tcl
M bindings/tk/app-defaults/PLplot.medium.ad
M bindings/tk/app-defaults/PLplot.small.ad
M bindings/tk/app-defaults/README
M bindings/tk/help_gui.tcl
M bindings/tk/help_keys.tcl
M bindings/tk/help_tcltk.tcl
M bindings/tk/pkgIndex.tcl.in
M bindings/tk/plclient.tcl
M bindings/tk/plcolor.tcl
M bindings/tk/plconfig.tcl
M bindings/tk/pldefaults.tcl
M bindings/tk/plplot.tcl
M bindings/tk/pltools.tcl
M bindings/wxwidgets/CMakeLists.txt
M cmake/FindPLplot.cmake
M cmake/epa_build/CMakeLists.txt
M cmake/epa_build/ExternalProject.cmake
M cmake/epa_build/README
M cmake/epa_build/README.developers
M cmake/epa_build/at-spi2-atk/CMakeLists.txt
M cmake/epa_build/at-spi2-core/CMakeLists.txt
M cmake/epa_build/atk/CMakeLists.txt
M cmake/epa_build/cairo/CMakeLists.txt
M cmake/epa_build/configure_epa.cmake
M cmake/epa_build/docbook-xml/CMakeLists.txt
M cmake/epa_build/docbook-xml/docbook-xml_CMakeLists.txt
M cmake/epa_build/docbook-xsl/docbook-xsl_CMakeLists.txt
M cmake/epa_build/epa_CMakeLists.txt.in
M cmake/epa_build/fontconfig/CMakeLists.txt
M cmake/epa_build/freetype/CMakeLists.txt
M cmake/epa_build/freetype_nohb/CMakeLists.txt
M cmake/epa_build/gdk-pixbuf/CMakeLists.txt
M cmake/epa_build/glib/CMakeLists.txt
M cmake/epa_build/gnome-common/CMakeLists.txt
M cmake/epa_build/gobject-introspection/CMakeLists.txt
M cmake/epa_build/gperf/CMakeLists.txt
M cmake/epa_build/gtk+/CMakeLists.txt
M cmake/epa_build/gtk-doc/CMakeLists.txt
M cmake/epa_build/gtk_transform.py
M cmake/epa_build/harfbuzz/CMakeLists.txt
M cmake/epa_build/intltool/CMakeLists.txt
M cmake/epa_build/itcl3/CMakeLists.txt
M cmake/epa_build/itk/CMakeLists.txt
M cmake/epa_build/itk3/CMakeLists.txt
M cmake/epa_build/itstool/CMakeLists.txt
M cmake/epa_build/iwidgets/CMakeLists.txt
M cmake/epa_build/iwidgets/iwidgets_CMakeLists.txt
M cmake/epa_build/iwidgets4.0/CMakeLists.txt
M cmake/epa_build/lapack_blas/CMakeLists.txt
M cmake/epa_build/libLASi/CMakeLists.txt
M cmake/epa_build/libagg/libagg_CMakeLists.txt
M cmake/epa_build/libffi/CMakeLists.txt
M cmake/epa_build/libharu/CMakeLists.txt
M cmake/epa_build/libpcre/CMakeLists.txt
M cmake/epa_build/libqhull/CMakeLists.txt
M cmake/epa_build/libqhull/src/CMakeLists.txt
M cmake/epa_build/libxkbcommon/CMakeLists.txt
M cmake/epa_build/libxml2/CMakeLists.txt
M cmake/epa_build/libxslt/CMakeLists.txt
M cmake/epa_build/ndiff/ndiff_CMakeLists.txt
M cmake/epa_build/octave_lite/CMakeLists.txt
M cmake/epa_build/pango/CMakeLists.txt
M cmake/epa_build/pixman/CMakeLists.txt
M cmake/epa_build/pkg-config/CMakeLists.txt
M cmake/epa_build/plplot/CMakeLists.txt
M cmake/epa_build/plplot_lite/CMakeLists.txt
M cmake/epa_build/qt4_lite/CMakeLists.txt
M cmake/epa_build/qt5_lite/CMakeLists.txt
M cmake/epa_build/ragel/CMakeLists.txt
M cmake/epa_build/setup/setup_linux_makefiles
M cmake/epa_build/setup/setup_mingw_makefiles
M cmake/epa_build/setup/setup_msys_makefiles
M cmake/epa_build/shapelib/shapelib_CMakeLists.txt
M cmake/epa_build/subversion/CMakeLists.txt
M cmake/epa_build/tcl/CMakeLists.txt
M cmake/epa_build/tk/CMakeLists.txt
M cmake/epa_build/uncrustify/config.h.cmake
M cmake/epa_build/valgrind/CMakeLists.txt
M cmake/epa_build/wxwidgets/CMakeLists.txt
M cmake/epa_build/xmlcatalog-wrapper/CMakeLists.txt
M cmake/epa_build/yelp-tools/CMakeLists.txt
M cmake/epa_build/yelp-xsl/CMakeLists.txt
M cmake/modules/CheckDIRSymbolExists.cmake
M cmake/modules/CheckDTD.cmake
M cmake/modules/FindAGG.cmake
M cmake/modules/FindGD.cmake
M cmake/modules/FindLTDL.cmake
M cmake/modules/FindLua.cmake
M cmake/modules/FindQHULL.cmake
M cmake/modules/FindShapelib.cmake
M cmake/modules/FindVGA.cmake
M cmake/modules/Findhpdf.cmake
M cmake/modules/FindwxWidgets.cmake
M cmake/modules/TestBrokenIsnanCXX.cmake
M cmake/modules/TestForHighBitCharacters.cmake
M cmake/modules/TestForNamespace.cmake
M cmake/modules/TestForStdintCXX.cmake
M cmake/modules/TestSignalType.cmake
M cmake/modules/UseSWIG.cmake
M cmake/modules/ada.cmake
M cmake/modules/agg.cmake
M cmake/modules/c++.cmake
M cmake/modules/d.cmake
M cmake/modules/docbook.cmake
M cmake/modules/double.cmake
M cmake/modules/drivers-finish.cmake
M cmake/modules/drivers-init.cmake
M cmake/modules/freetype.cmake
M cmake/modules/gd.cmake
M cmake/modules/java.cmake
M cmake/modules/language_support.cmake
M cmake/modules/language_support/cmake/CMakeAdaInformation.cmake
M cmake/modules/language_support/cmake/CMakeDCompiler.cmake.in
M cmake/modules/language_support/cmake/CMakeDInformation.cmake
M cmake/modules/language_support/cmake/CMakeD_Copyright.txt
M cmake/modules/language_support/cmake/CMakeDetermineDCompiler.cmake
M cmake/modules/language_support/cmake/CMakeTestAdaCompiler.cmake
M cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake
M cmake/modules/ndp_UseQt4.cmake
M cmake/modules/ocaml.cmake
M cmake/modules/octave.cmake
M cmake/modules/pango.cmake
M cmake/modules/pdf.cmake
M cmake/modules/pdl.cmake
M cmake/modules/pkg-config.cmake
M cmake/modules/plplot.cmake
M cmake/modules/plplot_functions.cmake
M cmake/modules/plplot_version.cmake
M cmake/modules/pstex.cmake
M cmake/modules/psttf.cmake
M cmake/modules/python.cmake
M cmake/modules/qt.cmake
M cmake/modules/shapelib.cmake
M cmake/modules/tk.cmake
M cmake/modules/wxwidgets.cmake
M cmake/modules/xwin.cmake
M cmake/test_ada/cmake/Modules/CMakeAdaInformation.cmake
M cmake/test_ada/cmake/Modules/CMakeTestAdaCompiler.cmake
M cmake/test_ada/scripts/comprehensive_test.sh
M cmake/test_ada/src_executable/CMakeLists.txt
M cmake/test_ada/src_lib/CMakeLists.txt
M cmake/test_fortran/scripts/comprehensive_test.sh
M cmake/test_fortran/src_executable/CMakeLists.txt
M cmake/test_fortran/src_lib/CMakeLists.txt
M data/README.shapefiles
M debian/README.Debian
M doc/CMakeLists.txt
M doc/Doxyfile.in
M doc/Xauthority
M doc/docbook/CMakeLists.txt
M doc/docbook/ChangeLog
M doc/docbook/README
M doc/docbook/README.developers
M doc/docbook/bin/ChangeLog
M doc/docbook/bin/get-library-structs.pl
M doc/docbook/bin/get-library-symbols.pl
M doc/docbook/bin/info-clean.pl
M doc/docbook/src/ada.xml
M doc/docbook/src/intro.xml
M doc/plm2gif.1
M doc/plpr.1
M doc/plrender.1
M doc/plserver.1
M doc/pltcl.1
M doc/pltek.1
M doc/pstex2eps.1
M drivers/CMakeLists.txt
M drivers/README.drivers
M drivers/README.wxwidgets
M drivers/deprecated_wxwidgets.h
M examples/CMakeLists.txt
M examples/Makefile.examples.in
M examples/ada/CMakeLists.txt
M examples/ada/Makefile.examples.in
M examples/ada/x00_easy_a.adb
M examples/ada/xstandard00a.adb
M examples/ada/xstandard01a.adb
M examples/ada/xstandard02a.adb
M examples/ada/xstandard03a.adb
M examples/ada/xstandard04a.adb
M examples/ada/xstandard05a.adb
M examples/ada/xstandard06a.adb
M examples/ada/xstandard07a.adb
M examples/ada/xstandard08a.adb
M examples/ada/xstandard09a.adb
M examples/ada/xstandard10a.adb
M examples/ada/xstandard11a.adb
M examples/ada/xstandard12a.adb
M examples/ada/xstandard13a.adb
M examples/ada/xstandard15a.adb
M examples/ada/xstandard16a.adb
M examples/ada/xstandard17a.adb
M examples/ada/xstandard18a.adb
M examples/ada/xstandard19a.adb
M examples/ada/xstandard20a.adb
M examples/ada/xstandard21a.adb
M examples/ada/xstandard22a.adb
M examples/ada/xstandard23a.adb
M examples/ada/xstandard25a.adb
M examples/ada/xstandard26a.adb
M examples/ada/xstandard28a.adb
M examples/ada/xstandard29a.adb
M examples/ada/xstandard30a.adb
M examples/ada/xstandard31a.adb
M examples/ada/xstandard33a.adb
M examples/ada/xtraditional00a.adb
M examples/ada/xtraditional01a.adb
M examples/ada/xtraditional02a.adb
M examples/ada/xtraditional03a.adb
M examples/ada/xtraditional04a.adb
M examples/ada/xtraditional05a.adb
M examples/ada/xtraditional06a.adb
M examples/ada/xtraditional07a.adb
M examples/ada/xtraditional08a.adb
M examples/ada/xtraditional09a.adb
M examples/ada/xtraditional10a.adb
M examples/ada/xtraditional11a.adb
M examples/ada/xtraditional12a.adb
M examples/ada/xtraditional13a.adb
M examples/ada/xtraditional15a.adb
M examples/ada/xtraditional16a.adb
M examples/ada/xtraditional17a.adb
M examples/ada/xtraditional18a.adb
M examples/ada/xtraditional19a.adb
M examples/ada/xtraditional20a.adb
M examples/ada/xtraditional21a.adb
M examples/ada/xtraditional22a.adb
M examples/ada/xtraditional23a.adb
M examples/ada/xtraditional25a.adb
M examples/ada/xtraditional26a.adb
M examples/ada/xtraditional28a.adb
M examples/ada/xtraditional29a.adb
M examples/ada/xtraditional30a.adb
M examples/ada/xtraditional31a.adb
M examples/ada/xtraditional33a.adb
M examples/c++/CMakeLists.txt
M examples/c++/Makefile.examples.in
M examples/c++/README.c++demos
M examples/c/CMakeLists.txt
M examples/d/CMakeLists.txt
M examples/f95/x09f.f90
M examples/f95/x20f.f90
M examples/java/CMakeLists.txt
M examples/java/README.javademos
M examples/lua/CMakeLists.txt
M examples/lua/x00.lua
M examples/lua/x01.lua
M examples/lua/x02.lua
M examples/lua/x03.lua
M examples/lua/x04.lua
M examples/lua/x05.lua
M examples/lua/x06.lua
M examples/lua/x07.lua
M examples/lua/x08.lua
M examples/lua/x09.lua
M examples/lua/x11.lua
M examples/lua/x12.lua
M examples/lua/x13.lua
M examples/lua/x14.lua
M examples/lua/x15.lua
M examples/lua/x16.lua
M examples/lua/x17.lua
M examples/lua/x18.lua
M examples/lua/x19.lua
M examples/lua/x20.lua
M examples/lua/x21.lua
M examples/lua/x22.lua
M examples/lua/x23.lua
M examples/lua/x24.lua
M examples/lua/x25.lua
M examples/lua/x26.lua
M examples/lua/x27.lua
M examples/lua/x28.lua
M examples/lua/x29.lua
M examples/lua/x30.lua
M examples/lua/x31.lua
M examples/lua/x33.lua
M examples/ocaml/Makefile.examples.in
M examples/ocaml/x00.ml
M examples/ocaml/x03.ml
M examples/ocaml/x13.ml
M examples/ocaml/x14.ml
M examples/ocaml/x15.ml
M examples/ocaml/x17.ml
M examples/ocaml/x22.ml
M examples/ocaml/x25.ml
M examples/ocaml/x26.ml
M examples/ocaml/x29.ml
M examples/ocaml/x30.ml
M examples/ocaml/x31.ml
M examples/octave/CMakeLists.txt
M examples/octave/p1.m
M examples/octave/p10.m
M examples/octave/p11.m
M examples/octave/p12.m
M examples/octave/p13.m
M examples/octave/p14.m
M examples/octave/p15.m
M examples/octave/p16.m
M examples/octave/p17.m
M examples/octave/p18.m
M examples/octave/p19.m
M examples/octave/p2.m
M examples/octave/p20.m
M examples/octave/p21.m
M examples/octave/p3.m
M examples/octave/p4.m
M examples/octave/p5.m
M examples/octave/p6.m
M examples/octave/p7.m
M examples/octave/p8.m
M examples/octave/p9.m
M examples/octave/plplot_octave_demo.m
M examples/octave/x00c.m
M examples/octave/x01c.m
M examples/octave/x02c.m
M examples/octave/x03c.m
M examples/octave/x04c.m
M examples/octave/x05c.m
M examples/octave/x06c.m
M examples/octave/x07c.m
M examples/octave/x08c.m
M examples/octave/x09c.m
M examples/octave/x10c.m
M examples/octave/x11c.m
M examples/octave/x12c.m
M examples/octave/x13c.m
M examples/octave/x14c.m
M examples/octave/x15c.m
M examples/octave/x16c.m
M examples/octave/x17c.m
M examples/octave/x18c.m
M examples/octave/x19c.m
M examples/octave/x20c.m
M examples/octave/x21c.m
M examples/octave/x22c.m
M examples/octave/x23c.m
M examples/octave/x24c.m
M examples/octave/x25c.m
M examples/octave/x26c.m
M examples/octave/x27c.m
M examples/octave/x28c.m
M examples/octave/x29c.m
M examples/octave/x30c.m
M examples/octave/x31c.m
M examples/octave/x33c.m
M examples/old_f95/x04f.f90
M examples/old_f95/x14f.f90
M examples/old_f95/x23f.f90
M examples/old_f95/x24f.f90
M examples/old_f95/x27f.f90
M examples/old_f95/x29f.f90
M examples/old_f95/x30f.f90
M examples/old_f95/x31f.f90
M examples/old_f95/x33f.f90
M examples/perl/CMakeLists.txt
M examples/perl/check-sync.pl
M examples/perl/x02.pl
M examples/perl/x04.pl
M examples/perl/x13.pl
M examples/perl/x15.pl
M examples/perl/x20.pl
M examples/perl/x21.pl
M examples/perl/x22.pl
M examples/perl/x23.pl
M examples/perl/x24.pl
M examples/perl/x25.pl
M examples/perl/x26.pl
M examples/perl/x27.pl
M examples/perl/x28.pl
M examples/perl/x29.pl
M examples/perl/x30.pl
M examples/perl/x31.pl
M examples/python/CMakeLists.txt
M examples/python/README.logo
M examples/python/plplot_logo.py
M examples/python/pyqt4_example.py
M examples/python/pyqt5_example.py
M examples/python/pythondemos.py
M examples/python/pytkdemo
M examples/python/test_circle.py
M examples/python/test_plsmem.py.in
M examples/python/test_style.py
M examples/python/test_type1.py
M examples/python/tutor.py
M examples/python/x01.py
M examples/python/x04.py
M examples/python/x16.py
M examples/python/xtkpy
M examples/python/xw01.py
M examples/python/xw02.py
M examples/python/xw03.py
M examples/python/xw04.py
M examples/python/xw06.py
M examples/python/xw09.py
M examples/python/xw10.py
M examples/python/xw11.py
M examples/python/xw13.py
M examples/python/xw14.py
M examples/python/xw15.py
M examples/python/xw16.py
M examples/python/xw17.py
M examples/python/xw18.py
M examples/python/xw19.py
M examples/python/xw20.py
M examples/python/xw21.py
M examples/python/xw22.py
M examples/python/xw23.py
M examples/python/xw24.py
M examples/python/xw25.py
M examples/python/xw26.py
M examples/python/xw27.py
M examples/python/xw28.py
M examples/python/xw29.py
M examples/python/xw30.py
M examples/python/xw31.py
M examples/tcl/README.tcldemos
M examples/tcl/plgrid.tcl
M examples/tcl/plot.tcl
M examples/tcl/stats.log
M examples/tcl/x14
M examples/tcl/x27.tcl
M examples/tk/CMakeLists.txt
M examples/tk/runExtendedDemos.tcl
M examples/tk/tk01.in
M examples/tk/tk03.in
M examples/tk/tk04.in
M fonts/CMakeLists.txt
M fonts/README
M git/README
M git/case-1/README
M git_hooks/README
M historical_repository_conversions/README_SourceForge_outage_restore
M historical_repository_conversions/README_svn2git_conversion
M historical_repository_conversions/diff_git_versus_svn_tree.sh
M historical_repository_conversions/plplot.rules
M include/CMakeLists.txt
M lib/csa/CMakeLists.txt
M lib/csa/README
M lib/nistcd/CMakeLists.txt
M lib/nn/README
M lib/qsastime/CMakeLists.txt
M lib/qsastime/README.deltaT.dat
M lib/qsastime/README.tai-utc
M pkgcfg/README
M plplot_test/CMakeLists.txt
M plplot_test/plplot-test-interactive.sh.in
M plplot_test/test_cxx.sh.in
M plplot_test/test_diff.sh.in
M plplot_test/test_java.sh.in
M plplot_test/test_octave.sh.in
M plplot_test/test_octave_interactive.sh.in
M plplot_test/test_python.sh.in
M plplot_test/test_tcl.sh.in
M scripts/check_api_completeness.sh
M scripts/check_backwards_incompatible_api.sh
M scripts/comprehensive_test.sh
M scripts/convert_comment.py
M scripts/generate_website.sh
M scripts/htdocs-gen_plot-examples.sh
M scripts/mklinks
M scripts/plm2gif
M scripts/plplot_miscdebris_wiki_backup.sh
M scripts/pstex2eps
M scripts/style_source.sh
M src/README.pages
M src/readme-mt.txt
M utils/CMakeLists.txt
M www/CMakeLists.txt
M www/README
M www/announce/CMakeLists.txt
M www/announce/README
M www/announce/announce-plplot-5.2.1.html
M www/announce/print.xsl
M www/corefunctions.php
M www/credits.php
M www/css/CMakeLists.txt
M www/css/style.css.in
M www/development.php
M www/downloads.php
commit 8f31e32db8d8bf36ded30e0a22f5cf09831fa069
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Oct 1 13:55:32 2016 -0700
Build system: Drop unneeded specification files from libplplotada build
I noticed that the new plplot.ads specification file did not have to
be included in the compilation of libplplotada so I removed all spec
files from that compilation so that only body files are compiled. That
updated compilation procedure is confirmed by my test below and also
by the rules in
<http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gnat_ugn_unw/Compiling-Programs.html>.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running the test_noninteractive target with no
Ada configure, build, run, or PostScript difference issues (see
remarks below about these good PostScript difference results.
In addition, the backwards compability of the new Ada binding was
tested by replacing examples/ada by the plplot-5.11.1 equivalent,
making the following temporary patch (to test those old versions of
the examples)
diff --git a/plplot_test/test_ada.sh.in b/plplot_test/test_ada.sh.in
index 8dc3b50..5df7d5e 100755
--- a/plplot_test/test_ada.sh.in
+++ b/plplot_test/test_ada.sh.in
@@ -28,7 +28,7 @@
# Do the standard non-interactive examples.
lang="a"
-for prefix in xstandard xtraditional ; do
+for prefix in xthick x ; do
for index in 00 01 02 03 04 05 06 07 08 09 10 11 12 13 15 16 18 19 20 21 22 23 24 25 26 27 28 30 31 33 ${critical_examples} ; do
example=${prefix}${index}
if [ "$verbose_test" ] ; then
diff --git a/plplot_test/test_diff.sh.in b/plplot_test/test_diff.sh.in
index 0c30cbe..86978ee 100755
--- a/plplot_test/test_diff.sh.in
+++ b/plplot_test/test_diff.sh.in
@@ -116,11 +116,11 @@ for lang in c++ f95 java octave python tcl perl adastandard adatraditional ocaml
suffix=pdl
;;
adastandard)
- xsuffix=standard
+ xsuffix=thick
suffix=a
;;
adatraditional)
- xsuffix=traditional
+ xsuffix=
suffix=a
;;
ocaml)
and running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ada=ON" --do_test_interactive no
There were no obvious configure, build, or run issues. There were some
PostScript difference issues, e.g.,
adastandard
Missing examples :
Differing graphical output : 08 19 20 29 33
Missing stdout :
Differing stdout : 20
adatraditional
Missing examples :
Differing graphical output : 08 19 20 29 33
Missing stdout :
Differing stdout : 20
N.B. the above PostScript difference issues do not occur when the
modern Ada example results are compared with the corresponding modern
C example results (see test_noninteractive results above) so I ascribe
all of the above PostScript difference issues to PLplot-5.11.1 Ada
examples that were inconsistent with the C examples in PLplot-5.11.1,
and further changes in the C examples since PLplot-5.11.1.
M bindings/ada/CMakeLists.txt
commit 511a6ac19a7ebc4f094478400bc57d6454ea6887
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Sep 17 11:21:14 2016 -0700
Build system: Update FindwxWidgets.cmake to be consistent with cmake master branch
The current (v3.6.2-1012-g4171b86) cmake master-branch version of
FindwxWidgets.cmake is being actively maintained and appears to be the
same or superior to our own version in all respects. So I have
changed our version to be the same as the cmake master-branch version
except for necessary licensing language changes and the different
method we use find_package_handle_standard_args which should work for
whatever cmake version >= 3.0.2 that is being used by the user.
So the net effect of this commit is users of older cmake versions such
as 3.0.2 will have access to the latest official cmake version of
FindwxWidgets.cmake which contains many bug fixes compared to the
3.0.2 version. And that desired result should continue if we are
careful to update our version of this find module to the latest
official cmake version whenever there is a significant change in that
version.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running cmake and building the wxwidgets device.
Testing on additional platforms is requested.
M cmake/modules/FindwxWidgets.cmake
commit 5b9dd303b50061c8ed3a9f149aea4b2a6817eece
Author: Jerry Bauck <jbauck@users.sourceforge.net>
Date: Tue Sep 13 02:51:31 2016 -0700
Restore backward compatiblity for Ada bindings
Restore backward compatibility for the "standard" Ada binding that was lost when it was renamed from PLplot to PLplot_Standard, with files plplot.adb and plplot.ads renamed to plplot_standard.ads and plplot_standard.adb.
A single new file was added, with the old name, plplot.ads. No .adb file is required. Users that have used the PLplot name need not change their code although a "deprecated" note is added herein.
A bindings/ada/plplot.ads
commit 5314c652809bd1abfc7f065b6bf32aa9748cf238
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Aug 6 12:30:57 2016 -0700
Build system: make rpath treatment on Mac OS X similar to the rpath treatment on Linux
This change has been implemented as follows:
1. USE_RPATH defaults to ON for Mac OS X.
2. DYLD_LIBRARY_PATH manipulations for Mac OS X have been dropped
from comprehensive test scripts since those should no longer be
necessary in order to get the traditional (make + pkg-config) build
of installed examples to work.
3. The use of the INSTALL_NAME_DIR property that is specific to Mac OS
X platforms has changed. This property normally takes precedence over
the INSTALL_RPATH property so the build system now specifies either
the INSTALL_RPATH property (if USE_RPATH is ON) or the
INSTALL_NAME_DIR property (if USE_RPATH is OFF), but not both.
These changes mean that downstream Mac OS X software distributors such
as Fink, MacPorts, and Homebrew who install PLplot in a standard
location will want to use the cmake -DUSE_RPATH=OFF option (following
the best practice of Linux distributions), but Mac OS X users who
typically install PLplot in non-standard Mac OS X locations will want
to use the default setting (USE_RPATH=ON) since that is more
convenient than, for example, setting DYLD_LIBRARY_PATH so the
run-time loader can find where the PLplot libraries are installed in their
non-standard locations for traditional builds of software that depends
on the PLplot libraries.
N.B. According to
<https://blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_mac>
Mac OS X only supported rpath as of 2007 with Mac OS X v10.5
"Leopard". So this change means new versions of PLplot will no longer
work on earlier Mac OS X versions unless the user specifically sets
-DUSE_RPATH=OFF and uses DYLD_LIBRARY_PATH instead, but that is a
necessary condition and may not be sufficient, i.e., it is likely that
modern PLplot will not work on ancient Mac OS X versions (Mac OS X
v10.4 "Tiger" and earlier) for many other reasons.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_noninteractive target with
no obvious configuration, build, or run-time issues and with no
PostScript difference regressions.
Tested by: Jerry Bauck <jbauck@users.sourceforge.net> on Mac OS X
for just the test_fortran project (using a patch that incorporated the
current set of changes for that project). The comprehensive test script for
that project executed without issues.
N.B. This commit still needs to be tested for the plplot project (as
opposed to the test_fortran project) on Mac OS X.
M README.release
M bindings/java/CMakeLists.txt
M bindings/lua/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 cmake/modules/plplot_functions.cmake
M cmake/modules/rpath.cmake
M cmake/test_ada/CMakeLists.txt
M cmake/test_ada/scripts/comprehensive_test.sh
M cmake/test_ada/src_lib/CMakeLists.txt
M cmake/test_fortran/CMakeLists.txt
M cmake/test_fortran/scripts/comprehensive_test.sh
M cmake/test_fortran/src_lib/CMakeLists.txt
M scripts/comprehensive_test.sh
commit 189724d0ad5a678408e08cf794d56bf58c82418d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Aug 19 11:17:00 2016 -0700
test_ada: remove EOL indicators from comparions of "hello, world"
phrases
Arjen's (test_fortran) experience on MinGW-w64/MSYS2 showed the files
being compared on that platform had EOL differences. So we had to
modify test_fortran to drop the EOL indicator "\nl" on the end of the
"hello, world" phrase, and this commit (implemented with lots of help
from Jerry) does the same thing for the test_ada case.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie with gnatmake) by running
cd cmake/test_ada
scripts/comprehensive_test.sh
with the result that there were perfect comparisons of the "hello,
world" phrases created without EOL indicators.
N.B. This test_ada commit keeps that project consistent with the
recent EOL change for the test_fortran project and prepares for the
day when Ada language support works properly on Windows. However,
that day is still a long way away.
M cmake/test_ada/src_executable/CMakeLists.txt
M cmake/test_ada/src_lib/hello_1.adb
M cmake/test_ada/src_lib/hello_1.ads
commit fbc85d48739ba391d491a85b9ab72cbe18e56c79
Author: Jerry Bauck <jbauck@users.sourceforge.net>
Date: Wed Aug 17 02:43:50 2016 -0700
Made backward compatibility for PLpointer in Ada
A recent change in the Ada bindings changed PLpointer to PL_Pointer, causing a backward incompatibility. See fdd31ce6. The present change restores that backward compatibility but marks the PLpointer spelling as deprecated.
Tested by temporarily changing all instances of PL_Pointer to PLpointer in both the traditional and standard versions of Example 14.
M bindings/ada/plplot_standard.ads
M bindings/ada/plplot_thin.ads
M bindings/ada/plplot_traditional.ads
commit db71a36044ff1b3512c080930d5be681e8b79853
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Aug 4 23:34:28 2016 -0700
test_fortran: remove EOL indicators from comparions of "hello, world" phrases
Arjen's test on MinGW-w64/MSYS2 showed the files being compared on
that platform had EOL differences. This fix should sort out that
issue by removing all EOL indicators from the "hello, world" phrase.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie with gfortran) by running
cd cmake/test_fortran
scripts/comprehensive_test.sh
with the result that there were perfect comparisons of the "hello, world" phrases
created without EOL indicators.
N.B. this test still needs to be done on Windows platforms.
M cmake/test_fortran/src_executable/CMakeLists.txt
M cmake/test_fortran/src_lib/hello_1.f90
commit cf4f843564dd9d47240a255af832362f9998e405
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Thu Aug 4 12:35:03 2016 +0200
Solve the remaining warnings about unused arguments and local variables
The NAG Fortran compiler is very strict wrt checking the code. Several warnings were left. This commit solves them.
Tested by Arjen Markus (arjenmarkus@users.sourceforge.net) on Linux with the NAG compiler
M bindings/f95/plplot.f90
M bindings/f95/plplot_single.f90
commit d9968a0fa50cfbae0828fe659cd92c1247961dc5
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Wed Aug 3 21:10:24 2016 +0200
Small correction - c_associated missing
M bindings/f95/plplot_single.f90
commit 4682cf166223a2215b74c68fd4fd3b51415e90b4
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Wed Aug 3 20:44:27 2016 +0200
Solve the last compiler warnings from NAG Fortran
The NAG Fortran compiler is very strict. To solve the warnings about unused arguments and local variables several extra changes were required.
Tested by Arjen Markus (arjenmarkus@users.sourceforge.net) on Linux/NAG
M bindings/f95/plplot.f90
M bindings/f95/plplot_single.f90
commit 91b751c9b6ba60e65b16f9f150c36c6261d69f9d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jul 29 12:05:10 2016 -0700
test_ada project: For Windows case properly support build-tree tests.
This is done by collecting build-tree dll's in the dll subdirectory of
the top-level build-tree directory, and it is the user's
responsibility to put that dll subdirectory on their PATH for the
build-tree case, but otherwise (install-tree case) ignore that
subdirectory. Note, such PATH manipulations have already been set up
in cmake/test_ada/scripts/comprehensive_test.sh so this fix should
"just work" when someone tests the test_ada project on Cygwin and/or
MinGW-w64/MSYS2 without any need for them to do PATH manipulations
(unless they run tests by hand).
Untested since this added logic has already been proved to not
interfere with the test_fortran Linux case, and actual test of
test_ada on Windows platforms (which will thoroughly test this logic)
isn't planned any time soon (since it is already known that Ada
language support does not work correctly for the Windows case and
debugging that case with test_ada on Cygwin and/or MinGW-w64/MSYS2 is
going to take a major effort).
M cmake/test_ada/CMakeLists.txt
commit 77efd8a2cd38554ec563adfad4c257b5e97598d8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jul 29 11:42:08 2016 -0700
test_fortran project: For Windows case properly support build-tree tests.
This is done by collecting build-tree dll's in the dll subdirectory
of the top-level build-tree directory, and it is the user's
responsibility to put that dll subdirectory on their PATH for
the build-tree case, but otherwise (install-tree case) ignore
that subdirectory. Note, such PATH manipulations have already
been set up in cmake/test_fortran/scripts/comprehensive_test.sh
so this fix should "just work" when Arjen tests this on Cygwin
and/or MinGW-w64/MSYS2 without any need for him to do PATH
manipulations (unless he runs tests by hand).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
cmake/test_fortran/scripts/comprehensive_test.sh
without issues. This test only proves that the extra Windows logic
does not interfere with the Linux case, and the real test of this
Windows bug fix must be done by Arjen.
M cmake/test_fortran/CMakeLists.txt
M cmake/test_fortran/README
commit 71c86fce7ebdce075a26b891a3b19abc49bf3a64
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jul 27 13:37:28 2016 -0700
Implement new test_fortran project to do what its name implies
This project was inspired by the existing test_ada project. Similarly
to that project but for Fortran rather than Ada it creates a library
with a routine that emits the "hello, world" phrase, and an executable
that calls that routine.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) with gfortran by following all the steps in
cmake/test_fortran/README.
A cmake/test_fortran/CMakeLists.txt
A cmake/test_fortran/README
A cmake/test_fortran/installed_CMakeLists.txt
A cmake/test_fortran/scripts/comprehensive_test.sh
A cmake/test_fortran/src_executable/CMakeLists.txt
A cmake/test_fortran/src_executable/hello.f90
A cmake/test_fortran/src_lib/CMakeLists.txt
A cmake/test_fortran/src_lib/hello_1.f90
A cmake/test_fortran/src_lib/test_fortranConfig.cmake
A cmake/test_fortran/test_fortran_configure.cmake_installed_examples.in
commit f449f0d2e0db9b976cd1181523cd7d31b9240add
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Tue Jul 26 19:06:59 2016 +0200
Remove a superfluous parameter
The NAG Fortran compiler issued a warning for one parameter in example x14f that was not used. This parameter (PI) could indeed be removed from the source code.
Tested by Arjen Markus (arjenmarkus@users.sourceforge.net) on Cygwin and Linux/NAG
M examples/f95/x14f.f90
commit 8730bd9f0ca38a32a16735de690aef537e9f5cdc
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Sun Jul 24 20:57:38 2016 +0200
Check the data argument for callbacks that do not use them
The purpose of checking the data argument for the two Fortran callback routines pltransformf2c and pllabelerf2c is twofold: make sure the binding can be compiled with as little warnings as possible and to make sure that the correct version of the routine is being used.
The most critical compiler, NAG Fortran, could not be used unfortunately (expired licence), but earlier experiments indicated this change makes the warnings go away.
Tested by Arjen Markus (arjenmarkus@users.sourceforge.net) on Windows+Cygwin
M bindings/f95/plplot_double.f90
commit 56f415ae9208681e5a52af6782d22b752e32be04
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jul 22 09:41:50 2016 -0700
Build system: ocaml binding: implement message concerning OCAML_HAS_CAIRO
Note that OCAML_HAS_CAIRO continues to be indefinitely disabled
because that component of PLplot needs substantial development to work
again, but this commit implements an AUTHOR_WARNING message concerning
this development situation that will be useful for packagers and
developers. However, ordinary users will be able to turn off by this
message by using the CMake -Wno-dev option.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by configuring PLplot by running cmake appropriately
and confirming this "developer-only" message is delivered correctly.
M cmake/modules/ocaml.cmake
commit fdd31ce68b219dbbde39e92fcd2be976c9c6c2c6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jul 20 00:23:10 2016 -0700
Ada bindings and examples: change name of pointer type
Following discussion with Jerry changed PLpointer and PLPointer (which
are equivalent in Ada) everywhere in Ada bindings and examples to
PL_Pointer so as not to confuse that Ada type with the C PLPointer
type (which in any case I plan to rename since I plan to generalize
to two different (non const and const) generic pointer types for C).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ada=ON" --do_test_interactive no
This test showed no regressions, i.e., no obvious build or run-time
errors and perfect PostScript differences.
M bindings/ada/plplot_standard.adb
M bindings/ada/plplot_standard.ads
M bindings/ada/plplot_thin.adb
M bindings/ada/plplot_thin.ads
M bindings/ada/plplot_traditional.adb
M bindings/ada/plplot_traditional.ads
M examples/ada/xstandard09a.adb
M examples/ada/xstandard14a.adb
M examples/ada/xstandard16a.adb
M examples/ada/xstandard19a.adb
M examples/ada/xstandard20a.adb
M examples/ada/xstandard22a.adb
M examples/ada/xtraditional09a.adb
M examples/ada/xtraditional14a.adb
M examples/ada/xtraditional16a.adb
M examples/ada/xtraditional19a.adb
M examples/ada/xtraditional20a.adb
M examples/ada/xtraditional22a.adb
commit 3f2b5f2bafc5b069a169feb19a7f1ee17d5cb735
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jul 17 19:20:29 2016 -0700
fonts: address compiler warnings for Hershey font generation code
The gcc options used to generate possible warnings were
CFLAGS=-O3 -std=gnu99 -pedantic -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs -Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings
I also addressed all unfreed memory issues.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by following the steps in fonts/README and also
by executing
valgrind ./generate_stndfonts
valgrind ./generate_xtndfonts
which generated perfect (no errors, no memory leaks possible) valgrind
reports.
M fonts/README
M fonts/stndfont.c
M fonts/xtndfont.c
M include/plplot.h
commit 11c496bebb2d23f86812c753e60e7a5b8bbfb0a0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jul 17 00:13:35 2016 -0700
Build system: fix else --> elseif bug in last commit for pkg-config.cmake
The above typographical error in the previous fix essentially made all
pkg-config-related CMake package finding that is done by our build
system fail to find packages. So the previous comprehensive test
results passed with flying colours, but with all components of PLplot
dropped that depended on pkg-config-related CMake package finding.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) using
scripts/comprehensive_test.sh --cmake_command ~/cmake/install-3.6.0/bin/cmake
where ~/cmake/install-3.6.0/bin/cmake is the location of a CMake-3.6.0
version of CMake that I built myself with the bootstrap method and
(Linux) system libraries.
There were no obvious build or run-time errors, the PostScript
difference results had no regressions (i.e., were perfect other
than the long-time ocaml issues), and all pkg-config-related CMake
package finding worked perfectly.
M cmake/modules/pkg-config.cmake
commit cac0198537a260fcb413f7d97301979c2dfaa31c
Author: Raphael Kubo da Costa <rakuco@FreeBSD.org>
Date: Sat Jul 16 10:45:25 2016 +0200
pkg-config: Adjust _pkg_check_modules_internal() for CMake 3.6.
CMake commit df97b97 ("FindPkgConfig: optionally create imported
target for the found libraries") has changed the function's signature
again, so add another check and update the call accordingly when using
CMake >= 3.6.0.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) using
scripts/comprehensive_test.sh
(i.e., a full noninteractive and interactive test for CMake-3.6.0
which is the version of CMake that I used for this test).
There were no obvious build or run-time errors, and the PostScript
difference results had no regressions (i.e., were perfect other
than the long-time ocaml issues).
M cmake/modules/pkg-config.cmake
commit 5010eddcfc3bdab366107a09d2b96ed496ec1a9a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Jul 12 17:08:06 2016 -0700
test_ada: Add comprehensive tests
This is a substantial update of the test_ada project to add
installation, installed examples tree CMake-based build system, build
tree and installed examples tree test_noninteractive test, and a
script to make it easy for users to comprehensively test the two
principal configurations (shared and static libraries) for both the
build tree and installed examples tree for the test_ada project.
M cmake/test_ada/CMakeLists.txt
M cmake/test_ada/README
A cmake/test_ada/installed_CMakeLists.txt
A cmake/test_ada/scripts/comprehensive_test.sh
M cmake/test_ada/src_executable/CMakeLists.txt
M cmake/test_ada/src_lib/CMakeLists.txt
A cmake/test_ada/src_lib/test_adaConfig.cmake
A cmake/test_ada/test_ada_configure.cmake_installed_examples.in
commit 796e8316f9f087f58508627005c5c2a8f76d5283
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Jul 11 12:41:18 2016 -0700
Build system: Ada examples: update build procedure
These updates consist of updating the clean rules to remove all
generated Ada-related files, simplifying the include_directories
command (which experimentation showed was possible), and updating the
commentary.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) using
scripts/comprehensive_test.sh --do_test_interactive no --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ada=ON"
There were no obvious build or run-time errors, and the PostScript
difference results were perfect.
M examples/ada/CMakeLists.txt
commit 8dc141f98c920c40089f9de0c4522296e665fcdd
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Tue Jul 5 21:14:51 2016 +0200
Make the Tcl examples use the redacted API as far as possible
The examples have been adapted to use the readacted API as far as possible. In some cases a smaller part of the vector of data is used, so that there the number of data points is specified explictly.
This change required a change in some C routines to actually take care of the reduced API. (We currently support a range of argument lists for some of these commands.)
Tested by Arjen Markus (arjenmarkus@users.sourceforge.net) on Cygwin
M bindings/tcl/tclAPI.c
M bindings/tcl/tclMatrix.c
M examples/tcl/x00.tcl
M examples/tcl/x01.tcl
M examples/tcl/x02.tcl
M examples/tcl/x03.tcl
M examples/tcl/x04.tcl
M examples/tcl/x05.tcl
M examples/tcl/x06.tcl
M examples/tcl/x07.tcl
M examples/tcl/x08.tcl
M examples/tcl/x09.tcl
M examples/tcl/x11.tcl
M examples/tcl/x12.tcl
M examples/tcl/x14.tcl
M examples/tcl/x15.tcl
M examples/tcl/x16.tcl
M examples/tcl/x18.tcl
M examples/tcl/x19.tcl
M examples/tcl/x20.tcl
M examples/tcl/x21.tcl
M examples/tcl/x22.tcl
M examples/tcl/x24.tcl
M examples/tcl/x26.tcl
M examples/tcl/x28.tcl
M examples/tcl/x29.tcl
M examples/tcl/x30.tcl
M examples/tcl/x31.tcl
commit fa1612b80cfbaec4aac2e84a7102ed42090170d1
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Sun Jul 3 21:39:00 2016 +0200
Adjust Fortran binding to remove unused arguments and variables
The NAG Fortran compiler produced a number of issues that were related to unused arguments and variables. One set of these messages concerned the argument "defined" for plshade and similar routines. This argument has been removed from the API. While this introduces a limited incompatibility it simplifies the interface, especially as the argument was dummy for all current specific interfaces. The examples have been adjusted to reflect this change.
Some other unused arguments exist because the routines are callbacks and therefore the API is defined at the C side.
The various examples turned out to have a small number of similar issues, nothing of any consequence though, but to make them as clean as possible, several changes were made.
Tested by: Arjen Markus (arjenmarkus@users.sourceforge.net) on Cygwin and MS Windows with the Intel Fortran compiler
M bindings/f95/included_plplot_real_interfaces.f90
M examples/f95/x14f.f90
M examples/f95/x15f.f90
M examples/f95/x16af.f90
M examples/f95/x16f.f90
M examples/f95/x17f.f90
M examples/f95/x21f.f90
M examples/f95/x22f.f90
commit ba34f1064a7950edff527a7809513b32e3eb0380
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jun 24 16:30:19 2016 -0700
Build system: Fortran binding: Implement WARNING concerning spurious warning messages emitted by the gfortran compiler
We have achieved good test results for gfortran, ifort, and nagfor
with this new Fortran binding. However, one known downside of this
new binding is it generates some ~50 "marked PRIVATE" warning messages
when building the plplotf95 target with the gfortran Fortran compiler.
A typical example of such a warning message is
Warning: Symbol 'interface_plcont' at (1) is marked PRIVATE but has been given the binding label 'c_plcont'
It appears these warnings (which do not occur if using the ifort or
nagfor Fortran compilers) are due to a gfortran bug (see
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111> and
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861>), i.e., they are
spurious warnings concerning completely valid use of the private
attribute for interface blocks describing C routines. There appear to
be no known negative consequences of this gfortran bug other than the
spurious warnings themselves. Until this gfortran bug is fixed, these
~50 "marked PRIVATE" warnings should just be ignored for those using
gfortran.
This commit copies the above information to our release notes and also
implements a WARNING message (only if the plplotf95 target is
configured and the user is using the gfortran compiler) for our build
system concerning this issue.
M README.release
M bindings/f95/CMakeLists.txt
commit 8e06e40d9f0f93b98bdff77f24f519195bb46fdd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jun 24 14:53:18 2016 -0700
Fortran binding: overall style change for multiply referenced interface blocks describing C routines
Normally interface blocks describing the C routines that are called by
the Fortran binding are embedded as part of module procedures, but
when more than one module procedure uses such interface blocks there
is a requirement (enforced at least by the nagfor compiler) that those
interface blocks must be consistent. We have previously complied with
that requirement by embedding such multiply referenced interface
blocks as part of module procedures using duplicated code, but that is
inefficient (in terms of the number of lines of code to be compiled)
and implies a maintenance issue (to keep that code duplicated whenever
there are changes on the C side or if we decide to make changes on the
Fortran side about how we describe the C routine). To deal with those
two potential issues this commit replaces all embedded copies of these
multiply referenced interface blocks by a common and private interface
block that is placed before the contains line.
N.B. All instances of such multiple use were determined using
variants of
grep -h -A1 '^ *interface$' bindings/f95/* |grep -E 'subroutine|function' |sort -b |less
where less was replaced by "wc -l" to count instances and the -u
option for sort was used or not to count total instances versus unique
instances. Ultimately the differences between those two numbers was
reduced to 10 corresponding to 10 duplicates of interface blocks that
were embedded inside _other_ interface blocks. (The three interface
blocks where this occurs are internal descriptions of the fill,
lookup, and transform callback arguments.) I do not know of any
Fortran method to use a common interface block to describe these C
callbacks so I have left them.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options
"-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON
-DENABLE_f95=ON" --do_test_interactive no
for the gfortran case. There were no obvious build or run-time errors
and there were perfect PostScript difference results.
N.B. this test merely proves these changes have introduced no
regressions for the Linux gfortran case, and follow-up comprehensive
testing with Linux nagfor is needed.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_double.f90
commit 291b7b61985c4b51004d59dca951198c2f3d21ab
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jun 24 14:40:15 2016 -0700
Style previous commits
M src/plimage.c
M src/plshade.c
M src/plvect.c
commit 220fa2dbec5970f6ffc4e9e862ebf4314bf7f6bf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jun 24 13:47:59 2016 -0700
Fortran binding: rework the interface blocks for the c_plsvect C routine
The nagfor compiler (rightly) requires that a given C routine is
always described with a consistent interface block, but it apparently
only applies that consistency test within a given module, and this
commit goes one step beyond by conforming to that consistency
requirement across modules for the C routine, c_plsvect (which is used
by module procedures in the plplot_double, plplot_single, and plplot
modules). The plplot module procedure for plsvect has just one
(optional) argument and maps to calling c_plsvect with first two
arguments NULL to change to the default arrow style. That is a very
different use case than the plplot_double and plplot_single modules
that requires a different interface block to describe c_plsvect. To
correct this inconsistency, I have implemented plsvect_null (with no
arguments) in src/plvect.c which simply calls c_plsvect with first two
arguments NULL and last two arguments 0 and then described and used
that unique plsvect_null wrapper in the plplot module.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) with gfortran by building the test_diff_psc target.
There were no obvious build or run errors, and the PostScript
difference results for Fortran were perfect. In addition, I
built the svg, x22c, and x22f95 targets and ran
valgrind examples/c/x22c -dev svg -fam -o testc.svg
valgrind examples/f95/x22f -dev svg -fam -o testf.svg.
All these valgrind runs produced perfect (no leaks possible and no
errors) valgrind results, there were no differences between the C
and Fortran SVG results, and the x22f valgrind run specifically tests
the normal call to plsvect as well as the variant with no arguments.
In sum, these are completely satisfactory test results for the
Linux gfortran case.
N.B. testing of these changes for the nagfor compiler will eventually
be needed, but that can be put off until my plans for additional
interface block and style changes are completed.
M bindings/f95/plplot.f90
M src/plvect.c
commit 0df6dd7799efa7b329b3e2e2e1151f32bca6bf72
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jun 22 17:07:13 2016 -0700
Fortran binding: rework the interface blocks for the plfvect and c_plvect C routines
The nagfor compiler (rightly) requires that a given C routine is
always described with a consistent interface block. Arjen previously
implemented this required consistency by removing an internal
interface block describing the transform callback (for the plfvect
case), and making other changes which gave consistent but not
identical code for the various descriptions of the plfvect interface
block. In addition, the original implementation of the c_plvect
interface block did not have an internal interfact block describing
the transform callback.
I have replaced those multiple descriptions of plfvect by implementing
(before the contains) one definition of the interface block for
plfvect which reinstates the internal interface block describing the
transform callback that was removed by Arjen's changes. I have also
moved the multiple descriptions of the c_plvect callback beyond the
contains to one description before the contains and for that one
description implemented an internal interface block describing the
transform callback.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) with gfortran by building the test_diff_psc target.
There were no obvious build or run errors, and the PostScript
difference results for Fortran were perfect. In addition, I
built the svg, x22c, and x22f95 targets and ran
valgrind examples/c/x22c -dev svg -fam -o testc.svg
valgrind examples/f95/x22f -dev svg -fam -o testf.svg.
The valgrind run on x22f was done 4 times with the following variants
of examples/f95/x22f.f90:
tr_callback .false., identity_callback .false., mypltr_callback .false.
tr_callback .true., identity_callback .false., mypltr_callback .false.
tr_callback .false., identity_callback .true., mypltr_callback .false.
tr_callback .false., identity_callback .false., mypltr_callback .true.
where the first one is the committed version of that code and the next
three are local variants. As a result of running
the x22f test with the 4 above variants to x22f.f90, all 6 signatures
of plvect (namely plvect_impl_0, plvect_impl_1, plvect_impl_2,
plvect_impl_tr, plvect_impl, and plvect_impl_data) were tested.
All these valgrind runs produced perfect (no leaks possible and no
errors) valgrind results, and there were no differences between the C
and Fortran SVG results for example 15 except in one case where the
first page of x22f SVG results corresponding to plvect_impl_0 and the
third variant of the code above differed from the corresponding C
results (slightly different scaling of the results + completely
different tick range) as expected.
In sum, these tests of the 6 possible plvect signatures showed the
expected results in all cases for the Linux gfortran compiler.
N.B. testing of these changes for the nagfor compiler will eventually
be needed, but that can be put off until my plans for additional
interface block and style changes are completed.
M bindings/f95/included_plplot_real_interfaces.f90
commit 1db54b1db3f8e177e8b1a9d7396a87273e50a3df
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jun 22 15:47:43 2016 -0700
Fortran binding: rework the interface block for the c_plshades C routine
The nagfor compiler (rightly) requires that a given C routine is always
described with a consistent interface block. Arjen previously
implemented this required consistency by removing an internal
interface block describing the transform callback, and making other
changes which gave consistent but not identical code for the various
descriptions of the c_plshades interface block.
I have replaced those multiple descriptions by implementing (before
the contains) one definition of the interface block for c_plshades
which reinstates the internal interface block describing the transform
callback that was removed by Arjen's changes. I have also implemented
the C routine plshades_null in src/plshade.c which is a wrapper for
plfshades that drops the formal transform callback and associated
data arguments and replaces those with NULL. I have described that
new routine with an interface block before the contains, and used that
interface block where it is required in the plshades_impl_0 signature
for plshades.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) with gfortran by building the test_diff_psc target.
There were no obvious build or run errors, and the PostScript
difference results for Fortran were perfect. In addition, I
built the svg, x16c, and x16f95 targets and ran
valgrind examples/c/x16c -dev svg -fam -o testc.svg
valgrind examples/f95/x16f -dev svg -fam -o testf.svg.
The valgrind run on x16f was done 4 times with the following variants
of examples/f95/x16f.f90:
no_callback .false., tr_callback .false., mypltr_callback .false.
no_callback .true., tr_callback .false., mypltr_callback .false.
no_callback .false., tr_callback .true., mypltr_callback .false.
no_callback .false., tr_callback .false., mypltr_callback .true.
where the first one is the committed version of that code and the next
three are local variants. As a result of running
the x16f test with the 4 above variants to x16f.f90, all 6 signatures
of plshades (namely plshades_impl_0, plshades_impl_1, plshades_impl_2,
plshades_impl_tr, plshades_impl, and plshades_impl_data) were tested.
All these valgrind runs produced perfect (no leaks possible and no
errors) valgrind results, and there were no differences between the C
and Fortran SVG results for example 15.
In sum, these tests of the 6 possible plshade signatures showed the
expected results in all cases for the Linux gfortran compiler.
N.B. testing of these changes for the nagfor compiler will eventually
be needed, but that can be put off until my plans for additional
interface block and style changes are completed.
M bindings/f95/included_plplot_real_interfaces.f90
M src/plshade.c
commit a788c26396409073877b780eec25718041d5e378
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jun 22 11:09:33 2016 -0700
Fortran binding: rework the interface block for the c_plshade C routine and implement a style change for the previous work on the interface block for the c_plimagefr routine
The nagfor compiler (rightly) requires that a given C routine is always
described with a consistent interface block. Arjen previously
implemented this required consistency by removing an internal
interface block describing the transform callback, and making other
changes which gave consistent but not identical code for the various
descriptions of the c_plshade interface block.
I have replaced those multiple descriptions by implementing (before
the contains) one definition of the interface block for c_plshade
which reinstates the internal interface block describing the transform
callback that was removed by Arjen's changes. I have also implemented
the C routine plshade_null in src/plshade.c which is a wrapper for
plshade_int that drops the formal transform callback and associated
data arguments and replaces those with NULL. I have described that
new routine with an interface block before the contains, and used that
interface block where it is required in the plshade_impl_0 signature
for plshade.
The new style of replacing multiple consistent but not identical
definitions of interface blocks corresponding to C routines beyond the
contains line with one interface block per C routine before the
contains line automatically satisfies the nagfor compiler requirement
mentioned above.
I have also changed to this new style for the previous interface block
work for overloaded versions of plimagefr, and the following commits
should gradually work toward the goal of adopting this new style for
all interface blocks describing C routines.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) with gfortran by building the test_diff_psc target.
There were no obvious build or run errors, and the PostScript
difference results for Fortran were perfect. In addition, I
built the svg, x15c, x15f95, and x16af targets and ran
valgrind examples/c/x15c -dev svg -fam -o testc.svg
valgrind examples/f95/x16af -dev svg -fam -o testf.svg
valgrind examples/f95/x15f -dev svg -fam -o testf.svg.
The valgrind run on x15f was done 4 times with the following variants
of examples/f95/x15f.f90:
tr_callback .false., pltr1_callback .false., mypltr_callback .false.
tr_callback .true., pltr1_callback .false., mypltr_callback .false.
tr_callback .false., pltr1_callback .true., mypltr_callback .false.
tr_callback .false., pltr1_callback .false., mypltr_callback .true.
where the first one is the committed version of that code and the next
three are local variants. As a result of running x16af and running
the x15f test with the 4 above variants to x15f.f90, all 6 signatures
of plshade (namely plshade_impl_0, plshade_impl_1, plshade_impl_2,
plshade_impl_tr, plshade_impl, and plshade_impl_data) were tested.
All these valgrind runs produced perfect (no leaks possible and no
errors) valgrind results, and there were no differences between the C
and Fortran SVG results for example 15.
In sum, these tests of the 6 possible plshade signatures showed the
expected results in all cases for the Linux gfortran compiler.
N.B. testing of these changes for the nagfor compiler will eventually
be needed, but that can be put off until my plans for additional
interface block and style changes are completed.
M bindings/f95/included_plplot_real_interfaces.f90
M src/plshade.c
commit a57b9b358b304c3182b4895be73fcc87f67a3849
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Jun 21 19:25:43 2016 -0700
Fortran binding and examples: substantially reduce nagfor warnings
This commit deals with a number of warnings given by the nagfor
compiler that were reported by Arjen Markus. From his report the
only nagfor warnings that should be left are the following:
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3521: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3619: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3521: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3619: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3720: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3720: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3794: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3857: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3921: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3979: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 4075: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3794: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3857: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3921: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 3979: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 4075: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 4174: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 4174: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 4245: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 4305: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 4366: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 4245: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 4305: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/included_plplot_real_interfaces.f90, line 4366: Unused dummy variable DEFINED
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/plplot_double.f90, line 232: Unused dummy variable DATA
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/plplot_double.f90, line 260: Unused dummy variable DATA
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/plplot_single.f90, line 78: Unused dummy variable DATA
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/plplot_single.f90, line 106: Unused dummy variable DATA
Warning: /home/markus/plplot-svn/plplot-git/bindings/f95/plplot.f90, line 1485: Unused dummy variable FILL
Warning: /home/markus/plplot-svn/plplot-git/examples/f95/x17f.f90, line 187: Symbol ERRMSG referenced but never set
None of these nagfor warnings should be addressed for now for the following reasons:
The DEFINED, DATA, and FILL warnings have not been addressed to reduce
the number of backwards-incompatible changes to our Fortran API. We
already have an uncomfortable amount of such breakage at this time in
my opinion so we should put off more Fortran API changes until later
if at all possible, and this decision is an example of that.
I have left the ERRMSG warning in example 17 because to remove it would
remove a partially complete programming stanza that we may want to
finish implementing later on.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie with gfortran) by building the test_diff_psc target with
no obvious build or run-time warning and perfect PostScript results
for our Fortran binding and examples.
N.B. The above test is for the gfortran case and Arjen should repeat
his nagfor test at his convenience to make sure the only nagfor
warnings left are the above.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_small_modules.f90
M examples/f95/x00f.f90
M examples/f95/x01f.f90
M examples/f95/x02f.f90
M examples/f95/x03f.f90
M examples/f95/x04f.f90
M examples/f95/x05f.f90
M examples/f95/x06f.f90
M examples/f95/x07f.f90
M examples/f95/x08f.f90
M examples/f95/x09f.f90
M examples/f95/x10f.f90
M examples/f95/x11f.f90
M examples/f95/x12f.f90
M examples/f95/x13f.f90
M examples/f95/x14f.f90
M examples/f95/x15f.f90
M examples/f95/x16af.f90
M examples/f95/x16f.f90
M examples/f95/x17f.f90
M examples/f95/x18f.f90
M examples/f95/x19f.f90
M examples/f95/x20f.f90
M examples/f95/x21f.f90
M examples/f95/x22f.f90
M examples/f95/x23f.f90
M examples/f95/x24f.f90
M examples/f95/x25f.f90
M examples/f95/x26f.f90
M examples/f95/x27f.f90
M examples/f95/x28f.f90
M examples/f95/x29f.f90
M examples/f95/x30f.f90
M examples/f95/x31f.f90
M examples/f95/x33f.f90
commit b7f889ed94dbb9aed5d9783a0ab955412453c4f4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jun 17 09:43:39 2016 -0700
Fortran binding: rework the interface block for c_plimagefr C routine
The nagfor compiler (rightly) demands that a given C routine is always
described with a consistent interface block. Arjen previously
implemented this required consistency by removing an internal
interface block describing the transform callback, and making other
changes which gave consistent but not identical code for the various
descriptions of the c_plimagefr interface block.
I have reimplemented those descriptions with cut-and-paste identical
code and with the internal interface block describing the transform
callback reinstated. For the one (NULL transform callback) case where
using an internal interface block to describe the transform callback
does not work, I have implemented in the plimage.c source code for our
C library a C wrapper called plimagefr_null which does not have the
callback and associated data arguments and which substitutes NULL for
those. At the Fortran level I have described that C function with its
own unique interface block (which does not violate the nagfor rule
since it is describing a different C function than c_plimagefr), and I
call that function as appropriate.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) with gfortran by building the svg, x20c and x20f
targets and running
cd examples
valgrind c/x20c -dev svg -fam -o testc.svg
valgrind f95/x20f -dev svg -fam -o testf.svg
The valgrind run on x20f was done 4 times with the following variants
of examples/f95/x20f.f90:
no_callback .false., tr_callback .false., mypltr_callback .false.
no_callback .true., tr_callback .false., mypltr_callback .false.
no_callback .false., tr_callback .true., mypltr_callback .false.
no_callback .false., tr_callback .false., mypltr_callback .true.
where the first one is the committed version of that code and the next
three are local variants. As a result of these example code changes,
all 6 signature of plimagefr (namely, plimagefr_impl_1,
plimagefr_impl_2, plimagefr_impl_null, plimagefr_impl_tr,
plimagefr_impl, and plimagefr_impl_data) were tested.
In all cases the valgrind reports were perfect (0 errors, no leaks
possible). Furthermore, the Fortran and C example 20 svg results were
identical for all variations of Fortran example 20.
In sum, these tests of the 6 possible plimagefr signatures showed the
expected results in all cases for the Linux gfortran compiler.
N.B. testing of these changes for the nagfor compiler is still needed.
M bindings/f95/included_plplot_real_interfaces.f90
M src/plimage.c
commit f218c2dab65de1e5dcaeaf8e74791485e911991e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jun 15 11:55:59 2016 -0700
Traditional build system for installed examples: nagfor requires extra level of -Wl indirection
I have inferred this change is required from an inspection of Linux
nagfor comprehensive test results from Arjen and also from
documentation of the semantics for the -Wl option for nagfor (see
<http://www.nag.co.uk/nagware/np/r61_doc/nagfor.html>) which turn out
to differ from the semantics of the -Wl option for gfortran (and ifort).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
for the gfortran case. There were no obvious build or run-time errors
and there were perfect PostScript difference results.
N.B. this test merely proves these nagfor changes have introduced no
regressions for the Linux gfortran case, and follow-up comprehensive
testing with Linux nagfor is needed.
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
commit 107438c8aac00b46ce1480c7486322d46dea4f4e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Jun 13 12:15:38 2016 -0700
Build systems for Fortran examples: fix nagfor build issues for included files
By default the nagfor compiler does not look in the location of the
source file for included files (e.g., plf95demos.inc included by
x21f.f90). Instead, (see
<http://inside.mines.edu/mio/man/nagfor.html>) included files are
looked for only in the current working directory (which can be in a
location other than the source file location). Therefore, to address
that issue must specify the source file location (the directory where
the x21f.f90 file exists) for our CMake-based build system for our
core build and install, our CMake-based build system for our installed
, and our GNU make- and pkg-config-based traditional build system for
our installed examples.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
without any obvious build or run-time issues and with perfect
PostScript difference results.
N.B. this test indicates the fix does not interfere with gfortran
results on Linux. But the equivalent test as above with the nagfor
compiler is required to see if this nagfor-related fix works for that
case.
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
commit d94191ea7a031069baa0853cf7db8dabeb91e9f9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Jun 13 11:31:55 2016 -0700
Build system: examples: remove no-longer-relevant warning
The following warning message:
is not relevant any more because this issue has long since been
addressed. Therefore remove this irrelevant warning.
M examples/ada/Makefile.examples.in
M examples/d/Makefile.examples.in
M examples/f95/Makefile.examples.in
M examples/java/Makefile.examples.in
M examples/ocaml/Makefile.examples.in
M examples/old_f95/Makefile.examples.in
commit da9da9090bbb06c79a00aacdb75ef4af043c1047
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat May 21 14:16:57 2016 -0700
PLplot core C library: Tweak API for plstripc
The colline, styline and legline arguments now consistently have the
following types: PLINT_VECTOR colline, PLINT_VECTOR styline, and
PLCHAR_MATRIX legline
M include/plplot.h
M src/plstripc.c
commit 0a41397a5672e6a9033c99468c5b1db80eec5d09
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri May 20 18:15:40 2016 -0700
Build system: DocBook documentation: CMake logic cleanup
In 2013 the DOCBOOK_XML_BACKEND=OFF option to configure using the old
SGML backend tools to build our documentation from DocBook source was
disabled by forcing DOCBOOK_XML_BACKEND to always be ON which in turn
forced BUILD_DVI to always be OFF. Since freezing these options
appears to have not caused the slightest issue, drop these options
altogether, preserve all Boolean blocks of code that corresponded to
DOCBOOK_XML_BACKEND=ON and BUILD_DVI=OFF, and drop all Boolean blocks
of code that corresponded to DOCBOOK_XML_BACKEND=OFF and BUILD_DVI=ON.
Also drop the disabled code logic that used pdf2ps to generate
PostScript results from the PDF result for the
DOCBOOK_DBLATEX_BACKEND=ON case since that code was disabled for a
strong reason (huge crummy result produced very slowly). These changes
constitute substantial simplifications of our CMake logic to configure
our DocBook documentation build.
"For what it is worth" also noted in doc/docbook/README.developers
what Debian packages needed to be installed to exercise the deprecated
option -DDOCBOOK_DBLATEX_BACKEND=OFF which uses a different set of
backend tools to produce not quite as good PDF results as the
-DDOCBOOK_DBLATEX_BACKEND=ON case.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the build_docbook_documentation target
without any obvious issues for both the -DBUILD_DOC=ON case (with
default -DDOCBOOK_DBLATEX_BACKEND=ON) and the deprecated
-DBUILD_DOC=ON -DDOCBOOK_DBLATEX_BACKEND=OFF case. I tested both
these major configurations of our documentation build because the
logic changes in this commit are so intrusive, but at some point I
will probably disable the currently deprecated
-DDOCBOOK_DBLATEX_BACKEND=OFF option as well.
M cmake/modules/docbook.cmake
M doc/docbook/README.developers
M doc/docbook/src/CMakeLists.txt
commit 5fc5a4c9e9fd22bdd8403a8e1cec87c2011f80eb
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri May 20 10:33:01 2016 -0700
DocBook documentation: Improve error messages from XML::DOM::Parser in perl scripts
The improvement in each perl script was to make the following change:
-$p = new XML::DOM::Parser;
+$p = new XML::DOM::Parser(ErrorContext => 2);
$sects = $p->parse ($api)->getElementsByTagName ("sect1");
The effect of this change is to add some context to error messages
generated when parsing the temporary file $api. This newly introduced
context for error messages makes it much more convenient to discover
the source of errors in the actual files plplotdoc_info.xml and
api.xml which are concatanated together (along with some relevant
entity definitions) to create $api.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by using the cmake -DBUILD_DOC=ON option and by
building the "man" target. As a result of the above change, the perl
script error created by using the "le" entity during local editing
of api.xml was quickly spotted and addressed by replacing "le" by
"leq" (one of the entities specifically defined in the perl scripts)
for my locally updated api.xml. The plan is to commit that
locally updated (with "le --> leq" correction for the update) api.xml as
soon as I am finished making changes to it.
M doc/docbook/bin/api2man.pl.in
M doc/docbook/bin/api2swigdoc.pl
commit 395207f85d764ab783c368816ed265cfc31d8e8a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu May 19 10:49:01 2016 -0700
DocBook documentation: Document additional C types
Those additional types are PLFLT_VECTOR, PLINT_VECTOR, PLBOOL_VECTOR,
PLCHAR_VECTOR, PLFLT_MATRIX, PLCHAR_MATRIX, PLF2EVAL_callback,
PLFILL_callback, and PLDEFINED_callback.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by using the cmake -DBUILD_DOC=ON option and by
building the "html" target without validation or title-page rendering
issues.
M doc/docbook/src/c.xml
commit 94b6aa9dcde795484f1dbc7ef725604f8e4d9f55
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Mon Jun 13 21:31:43 2016 +0200
Changes required to support the NAG Fortran compiler
The NAG Fortran compiler is much more strict in checking the code against the prevailing standard than most other compilers. Our work to get the Fortran binding and examples accepted by this compiler revealed a number of deivations from the standard were present in the code. They mostly have to do with the finer details of the Fortran/C interfacing.
Some more work needs to be done for the Windows platform (MinGW-w64/MSYS2) to make it work smoothly, because the support by CMake for this compiler is not yet fully developed and the installation of the NAG Fortran compiler on Windows uses spaces in one of the directory names, which is something our build system does not handle well.
Tested by Arjen Markus (arjenmarkus@sourceforge.net) on MinGW-w64/MSYS2 and Linux
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_small_modules.f90
M examples/f95/x14f.f90
commit f4d6c05f61bb84b425cca98d1be5688f817b1811
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Tue May 24 20:41:13 2016 +0200
Add proper decoration for plplotLibDir variable
For the Windows platform the plplotLibDir variable, defined in the PLplot
DLL must be properly imported. The attribute to do this was missing in
the Tcl binding.
Tested by Arjen Markus (arjenmarkus@users.sourceforge.net) on bare Windows
M bindings/tcl/tclAPI.c
commit cd5c4a243ff0b2b4eab619f82cee00bfe658a43d
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Mon May 23 21:31:09 2016 +0200
Add PLplot header file because of missing definition
Add the header file "plplot.h" for the definition of PLCHAR_VECTOR on Windows.
Tested by Arjen Markus (arjenmarkus@users.sourceforge.net) on Windows, using MSVC compiler
M src/ltdl_win32.c
commit 1267f81359422f721a67591eed8b4c11c0284c5d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue May 17 23:31:57 2016 -0700
DocBook documentation: Remove OS notes chapter
This removed chapter (which gave instructions concerning how to build
PLplot for various platforms) was completely out of date/misleading
compared to our wiki which should be the primary source of this
information. Also, the only internal reference to this chapter was in
the introduction, and that part of the introduction has now been
implemented a different way by providing generic build instructions
with reference to the wiki for the details.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by using the cmake -DBUILD_DOC=ON option, and by
building the "html" target without validation or title-page rendering
issues.
M doc/docbook/src/CMakeLists.txt
D doc/docbook/src/os_notes.xml
M doc/docbook/src/plplotdoc.xml.in
commit 93249bec1a97e68fb1d698fa447421ac6edf21f3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon May 16 21:36:25 2016 -0700
DocBook documentation: introduction update
Copyright and title changes; supply url for plplot-general mailing list;
replace reference to the os-notes chapter (which is going to be removed)
to a full writeup of a generic build + reference to the wiki for more
details; and rewrite the following paragraph on building users examples
against the installed PLplot version.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by using the cmake -DBUILD_DOC=ON option, and by
building the "html" target without validation or title-page rendering
issues.
M doc/docbook/src/intro.xml
commit 031aec82a86c0fef6891f5b7558e009039e7dc40
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon May 16 20:40:37 2016 -0700
DocBook documentation:info backend: Do not comment out "part" tags
This commenting out of "part" tags for the info backend was done long
ago for unknown reasons, but those tags work fine now for our info
backend (just like for every other backend) and uncommenting them in
the info case also allows cross-references to the part tag id's to
work properly for the info backend rather than generating an error.
I additionally fixed a file dependency issue for the info target.
That is, the "info" target now file depends
on the info-clean.pl perl script used for massaging (e.g., the
part tag commenting that was just removed) the DocBook source
code into a form that can be used to generate our info documentation.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linx
(Debian jessie) by using the -DBUILD_DOC=ON cmake option and
by building the "info" target without any obvious errors.
M doc/docbook/bin/info-clean.pl
M doc/docbook/src/CMakeLists.txt
commit cb22caf45069874085790cc0ef3dd309228caa1a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon May 16 19:44:10 2016 -0700
DocBook documentation: update title page
Update title, abstract, copyrights (according to the range of years
when commits were made and according to who contributed commits), and
also add all contributors (rendered in html as small print) other than
Maurice and Geoffrey as "collaborators" (in contrast to Maurice and
Geoffrey who still get the principal credit as "authors" rendered in
html in large print).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by using the cmake -DBUILD_DOC=ON option, and by
building the "html" target without validation or title-page rendering
issues.
M doc/docbook/src/plplotdoc.xml.in
commit 836dc0203f636ffcbe769bdad9c370667291cece
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun May 15 13:29:30 2016 -0700
Comprehensive test script: enforce clean start by removing install tree
This change to remove the install tree before configuring, building,
and doing build-tree tests of PLplot means all such tests proceed
independently of any stale install-tree results left from prior runs
of the script.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian testing) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
The usual perfect results (no run-time errors nor PostScript
differences) were produced.
M scripts/comprehensive_test.sh
commit 58f4da1b14e28d25c1398fe7dfee847dd4317a88
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun May 15 12:22:44 2016 -0700
Comprehensive test script: implement DYLD_LIBRARY_PATH manipulation logic for Mac OS X platforms
When the installed examples are being built and tested, the new logic
prepends the location of the installed PLplot libraries to
DYLD_LIBRARY_PATH in the shared library cases and restores
DYLD_LIBRARY_PATH back to its original value afterwards.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running a local variant of the script with Linux
platform detected rather than Mac OS X platform as in the committed
script. The tests were done both with DYLD_LIBRARY_PATH exported and
not, and in all cases the resulting DYLD_LIBRARY_PATH manipulation
appeared to be done with the correct values at the right times during
script execution.
M scripts/comprehensive_test.sh
commit be28cf176fe6c9810817a965ea7839bd8a2a70d1
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu May 5 10:01:12 2016 -0700
Website: Adjust for change in Ada naming conventions
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by following the procedure in
README.Release_Manager_Cookbook to generate a local version of our
website and checking the examples part of that website for the
presence of the Ada Standard and Traditional examples source code.
M scripts/htdocs-gen_plot-examples.sh
M www/examples.php
commit f5d730b4116c21affcb7cffbc74b23bd78fb6641
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue May 3 22:49:05 2016 -0700
Update parity_bit_check.sh and associated exclude file
As an extremely incomplete but still interesting check for file
corruption, the scripts/parity_bit_check.sh script searches for any
ascii characters that have their eighth bit set for all the files in
our source tree that are still considered to be pure ascii. Files to
be ignored by this script (i.e., binary files or files with non-ascii
UTF-8 characters) are indicated in scripts/parity_bit_check.exclude using
regular expressions.
The updates to the script were to use git rather than svn to do the
equivalent of svn export using git --checkout-index. The updates to
the exclude file contain changes to the regular expressions for the
Ada examples with UTF-8 characters consistent with the recent changes
to the Ada example naming conventions. Additional file patterns also
had to be added to the exclude file to account for the additional
files with non-ascii UTF-8 characters that are present now compared to
when this script was last invoked several years ago.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the parity_bit_check executable (using
make parity_bit_check), putting the absolute location of the utils
subdirectory of the build tree on the PATH, and running
scripts/parity_bit_check.sh. The result was no output, i.e., every
file checked had no ascii parity bit set. I also double-checked (by
locally modifying the script to not remove
/tmp/temporary_source_tree_list and then looking at the contents of
that file) that git --checkout-index was working properly to export
the entire working directory of the local plplot git repository. It
turns out there is a bug in git --checkout-index (see
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823384>) such that
it quietly does not export the entire source tree if invoked from
within a subdirectory of the source tree, but I worked around that
issue by using cd appropriately in the script.
M scripts/parity_bit_check.exclude
M scripts/parity_bit_check.sh
commit f48d82a1260cd33efd59b226c9bcabcbd28fc16a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue May 3 18:56:12 2016 -0700
Build system: Fix bugs introduced by our recent Ada naming convention changes
The bugs that have been fixed were that "make clean" did not clean all
files produced by the test_diff_psc target, "make
clean_ctest_plot_files" did not clean all files produced by ctest, and
repeated builds of the test_ada_psc or test_diff_psc targets
incorrectly regenerated results.
The issue causing all these problems was that the "list_example_files"
CMake function had not been adjusted for the recent change in the Ada
naming conventions. This commit makes that required adjustment, and
therefore removes all these issues.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target (which produced
good results), then rebuilding that target (which simply reran the
usual plplot_test/test_diff.sh scripts without rebuilding anything
(which is the desired result). Afterwards, "make clean" cleaned out
all the PostScript and text files generated by that test in
examples/test_examples_output_dir. I also did similar repeat target
tests and "make clean" tests with the test_asc_psc target with similar
good results. Finally, I ran "make all" and ctest (which had no
run-time errors and delivered good PostScript difference results)
which generated files in ctest_examples_output_dir which were
subsequently completely removed by "make clean_ctest_plot_files".
In sum, all issues with the "list_example_files" CMake function that
were recently introduced by our Ada naming convention changes now seem
to be fixed.
M cmake/modules/plplot_functions.cmake
commit b5035b34ff4bc636be791a1aa99256c20a346b45
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue May 3 18:45:24 2016 -0700
Comment spelling tweak.
M examples/CMakeLists.txt
commit dc7a3a2808ee652f2b562f34ae5f9ffc71e47f9b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun May 1 18:19:18 2016 -0700
Update developer documentation concerning avoiding unnecessary git extensions such as git-lfs
M README.developers
commit d702daa7ecb2d5365bde2370af268ff10396c934
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun May 1 17:24:28 2016 -0700
Change naming conventions for Ada examples to be consistent with naming conventions for Ada bindings
xthick??a.adb ==> xstandard??a.adb
x??a.adb ==> ==> xtraditional??a.adb
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running the following comprehensive test command:
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ada=ON" --do_test_interactive no
The commands
grep -i error ../comprehensive_test_disposeable/*/*/output_tree/*.out
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable/*/*/output_tree/*.out |less
showed these comprehensive test results were good, i.e., no obvious
build or run-time errors and the PostScript differences were perfect.
M examples/ada/CMakeLists.txt
M examples/ada/Makefile.examples.in
M examples/ada/x00_easy_a.adb
D examples/ada/x00a.adb
D examples/ada/x01a.adb
D examples/ada/x02a.adb
D examples/ada/x03a.adb
D examples/ada/x04a.adb
D examples/ada/x05a.adb
D examples/ada/x06a.adb
D examples/ada/x07a.adb
D examples/ada/x08a.adb
D examples/ada/x09a.adb
D examples/ada/x10a.adb
D examples/ada/x11a.adb
D examples/ada/x12a.adb
D examples/ada/x13a.adb
D examples/ada/x14a.adb
D examples/ada/x15a.adb
D examples/ada/x16a.adb
D examples/ada/x17a.adb
D examples/ada/x18a.adb
D examples/ada/x19a.adb
D examples/ada/x20a.adb
D examples/ada/x21a.adb
D examples/ada/x22a.adb
D examples/ada/x23a.adb
D examples/ada/x24a.adb
D examples/ada/x25a.adb
D examples/ada/x26a.adb
D examples/ada/x27a.adb
D examples/ada/x28a.adb
D examples/ada/x29a.adb
D examples/ada/x30a.adb
D examples/ada/x31a.adb
D examples/ada/x33a.adb
A examples/ada/xstandard00a.adb
A examples/ada/xstandard01a.adb
A examples/ada/xstandard02a.adb
A examples/ada/xstandard03a.adb
A examples/ada/xstandard04a.adb
A examples/ada/xstandard05a.adb
A examples/ada/xstandard06a.adb
A examples/ada/xstandard07a.adb
A examples/ada/xstandard08a.adb
A examples/ada/xstandard09a.adb
A examples/ada/xstandard10a.adb
A examples/ada/xstandard11a.adb
A examples/ada/xstandard12a.adb
A examples/ada/xstandard13a.adb
A examples/ada/xstandard14a.adb
A examples/ada/xstandard15a.adb
A examples/ada/xstandard16a.adb
A examples/ada/xstandard17a.adb
A examples/ada/xstandard18a.adb
A examples/ada/xstandard19a.adb
A examples/ada/xstandard20a.adb
A examples/ada/xstandard21a.adb
A examples/ada/xstandard22a.adb
A examples/ada/xstandard23a.adb
A examples/ada/xstandard24a.adb
A examples/ada/xstandard25a.adb
A examples/ada/xstandard26a.adb
A examples/ada/xstandard27a.adb
A examples/ada/xstandard28a.adb
A examples/ada/xstandard29a.adb
A examples/ada/xstandard30a.adb
A examples/ada/xstandard31a.adb
A examples/ada/xstandard33a.adb
D examples/ada/xthick00a.adb
D examples/ada/xthick01a.adb
D examples/ada/xthick02a.adb
D examples/ada/xthick03a.adb
D examples/ada/xthick04a.adb
D examples/ada/xthick05a.adb
D examples/ada/xthick06a.adb
D examples/ada/xthick07a.adb
D examples/ada/xthick08a.adb
D examples/ada/xthick09a.adb
D examples/ada/xthick10a.adb
D examples/ada/xthick11a.adb
D examples/ada/xthick12a.adb
D examples/ada/xthick13a.adb
D examples/ada/xthick14a.adb
D examples/ada/xthick15a.adb
D examples/ada/xthick16a.adb
D examples/ada/xthick17a.adb
D examples/ada/xthick18a.adb
D examples/ada/xthick19a.adb
D examples/ada/xthick20a.adb
D examples/ada/xthick21a.adb
D examples/ada/xthick22a.adb
D examples/ada/xthick23a.adb
D examples/ada/xthick24a.adb
D examples/ada/xthick25a.adb
D examples/ada/xthick26a.adb
D examples/ada/xthick27a.adb
D examples/ada/xthick28a.adb
D examples/ada/xthick29a.adb
D examples/ada/xthick30a.adb
D examples/ada/xthick31a.adb
D examples/ada/xthick33a.adb
A examples/ada/xtraditional00a.adb
A examples/ada/xtraditional01a.adb
A examples/ada/xtraditional02a.adb
A examples/ada/xtraditional03a.adb
A examples/ada/xtraditional04a.adb
A examples/ada/xtraditional05a.adb
A examples/ada/xtraditional06a.adb
A examples/ada/xtraditional07a.adb
A examples/ada/xtraditional08a.adb
A examples/ada/xtraditional09a.adb
A examples/ada/xtraditional10a.adb
A examples/ada/xtraditional11a.adb
A examples/ada/xtraditional12a.adb
A examples/ada/xtraditional13a.adb
A examples/ada/xtraditional14a.adb
A examples/ada/xtraditional15a.adb
A examples/ada/xtraditional16a.adb
A examples/ada/xtraditional17a.adb
A examples/ada/xtraditional18a.adb
A examples/ada/xtraditional19a.adb
A examples/ada/xtraditional20a.adb
A examples/ada/xtraditional21a.adb
A examples/ada/xtraditional22a.adb
A examples/ada/xtraditional23a.adb
A examples/ada/xtraditional24a.adb
A examples/ada/xtraditional25a.adb
A examples/ada/xtraditional26a.adb
A examples/ada/xtraditional27a.adb
A examples/ada/xtraditional28a.adb
A examples/ada/xtraditional29a.adb
A examples/ada/xtraditional30a.adb
A examples/ada/xtraditional31a.adb
A examples/ada/xtraditional33a.adb
M plplot_test/test_ada.sh.in
M plplot_test/test_diff.sh.in
commit 592f127d8e72fdfbcc28cb15b300584a8067ec2f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun May 1 12:42:18 2016 -0700
Ada bindings and examples: rename the "PLplot" thick Ada binding to "PLplot_Standard"
Using PLplot "traditional" and PLplot "standard" to name our two thick
user-visible Ada bindings has long been documented in our DocBook
documention for our Ada bindings. That is a good naming convention
since the names of these bindings nicely complement each other. Our
existing Ada thick "PLplot_Traditional" binding implementation already
follows this naming convention, and we have now changed to this same
naming convention for our other thick binding by renaming it from
"PLplot" to "PLplot_Standard".
N.B. this is a backwards-incompatible change requiring that all those
whose Ada code previously referred to the "PLplot" binding in their
with and use statements must change those references to
"PLplot_Standard".
While adjusting our "thick" Ada examples (a naming convention misnomer
that I plan to correct in the next commit) for this backwards
incompatibility, I discovered a number of white-space and ordering
inconsistencies in the with and use statements which I corrected for all
"thick" examples. Similar inconsistences in the "thin" Ada examples
(a naming convention misnomer that I plan to correct in the next
commit) were also corrected.
I also adjusted the x00_easy_a.adb for this backwards incompatibility
even though that example is not curently built by our build system.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target without
any build, run-time, or PostScript difference issues for the
Ada "thick" and "thin" examples.
M README.release
M bindings/ada/CMakeLists.txt
D bindings/ada/plplot.adb
D bindings/ada/plplot.ads
A bindings/ada/plplot_standard.adb
A bindings/ada/plplot_standard.ads
M examples/ada/x00_easy_a.adb
M examples/ada/x02a.adb
M examples/ada/x03a.adb
M examples/ada/x04a.adb
M examples/ada/x05a.adb
M examples/ada/x06a.adb
M examples/ada/x07a.adb
M examples/ada/x08a.adb
M examples/ada/x09a.adb
M examples/ada/x10a.adb
M examples/ada/x11a.adb
M examples/ada/x12a.adb
M examples/ada/x13a.adb
M examples/ada/x14a.adb
M examples/ada/x15a.adb
M examples/ada/x16a.adb
M examples/ada/x17a.adb
M examples/ada/x20a.adb
M examples/ada/x21a.adb
M examples/ada/x22a.adb
M examples/ada/x23a.adb
M examples/ada/x24a.adb
M examples/ada/x25a.adb
M examples/ada/x28a.adb
M examples/ada/x29a.adb
M examples/ada/x30a.adb
M examples/ada/x31a.adb
M examples/ada/xthick00a.adb
M examples/ada/xthick01a.adb
M examples/ada/xthick02a.adb
M examples/ada/xthick03a.adb
M examples/ada/xthick04a.adb
M examples/ada/xthick05a.adb
M examples/ada/xthick06a.adb
M examples/ada/xthick07a.adb
M examples/ada/xthick08a.adb
M examples/ada/xthick09a.adb
M examples/ada/xthick10a.adb
M examples/ada/xthick11a.adb
M examples/ada/xthick12a.adb
M examples/ada/xthick13a.adb
M examples/ada/xthick14a.adb
M examples/ada/xthick15a.adb
M examples/ada/xthick16a.adb
M examples/ada/xthick17a.adb
M examples/ada/xthick18a.adb
M examples/ada/xthick19a.adb
M examples/ada/xthick20a.adb
M examples/ada/xthick21a.adb
M examples/ada/xthick22a.adb
M examples/ada/xthick23a.adb
M examples/ada/xthick24a.adb
M examples/ada/xthick25a.adb
M examples/ada/xthick26a.adb
M examples/ada/xthick27a.adb
M examples/ada/xthick28a.adb
M examples/ada/xthick29a.adb
M examples/ada/xthick30a.adb
M examples/ada/xthick31a.adb
M examples/ada/xthick33a.adb
commit efc27f4b8d3288f6f8bf5f9db796b2a683f33cee
Author: Jerry Bauck <jbauck@users.sourceforge.net>
Date: Sat Apr 30 21:23:14 2016 -0700
Change Ada example names on web site buttons
This trivial commit changes the names on the web site's example pages buttons from Ada(thick) and Ada(thin) which are misleading because both bindings are thick, to Ada(Standard) and Ada(Traditional) to indicate more clearly the reasons for the two bindings—Traditional uses normal, documented subprogram names and Standard uses names that are thought to appeal to Ada programmers. This is in anticipation of changing the Ada example file names/main program names and Ada binding names accordingly.
Once the example file names are actually changed, lines 185 and 186 of examples.php will have to be changed.
This change is not tested but should be checked after the next web site build.
M www/examples.php
commit f84533a0047b8e1a375a1a3da9f0a11b1e613b61
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Apr 29 15:28:33 2016 -0700
Core PLplot library and C examples: implement and use additional PLplot types
The motivation for this change is to help simplify our documentation and
improve our C code understandability/consistency.
The new PLplot types are typedefed as follows:
typedef const PLFLT * PLFLT_VECTOR;
typedef const PLINT * PLINT_VECTOR;
typedef const PLBOOL * PLBOOL_VECTOR;
typedef const char * PLCHAR_VECTOR;
typedef const PLFLT * const * PLFLT_MATRIX;
typedef const char * const * PLCHAR_MATRIX;
The present set of changes is confined to our C headers, our core C
library, and our C examples.
Although these C types could be used directly in our C++ bindings and
examples and could be used in the implementation of many of our
language bindings, I will leave it to others to start using them in
those contexts.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_noninteractive target with
no build-time or run-time issues detected.
M examples/c/x01c.c
M examples/c/x04c.c
M examples/c/x08c.c
M examples/c/x09c.c
M examples/c/x11c.c
M examples/c/x13c.c
M examples/c/x14c.c
M examples/c/x16c.c
M examples/c/x17c.c
M examples/c/x19c.c
M examples/c/x20c.c
M examples/c/x21c.c
M examples/c/x22c.c
M examples/c/x23c.c
M examples/c/x24c.c
M examples/c/x26c.c
M examples/c/x28c.c
M examples/c/x33c.c
M examples/c/x34c.c
M include/plplot.h
M include/plplotP.h
M src/deprecated_plmap.c
M src/ltdl_win32.c
M src/pdfutils.c
M src/plaffine.c
M src/plargs.c
M src/plbox.c
M src/plcont.c
M src/plcore.c
M src/plctrl.c
M src/plfill.c
M src/plfreetype.c
M src/plgradient.c
M src/plgridd.c
M src/plhist.c
M src/plimage.c
M src/pllegend.c
M src/plline.c
M src/plmap.c
M src/plmem.c
M src/plmetafile.c
M src/plot3d.c
M src/plsdef.c
M src/plshade.c
M src/plstdio.c
M src/plstripc.c
M src/plsym.c
M src/pltick.c
M src/pltime.c
M src/plvect.c
commit 1553a9e09fd56010511e1f6dae5c12a12899cac2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Mar 19 13:09:21 2016 -0700
DocBook documentation: Simplify introductory chapter
The list of simplifications is as follows:
1. PLPLOT_WEBSITE (and PLplot-website) now includes "http://" part of
website address.
2. Drop "organization of manual" section since that is already
done well with the table of contents.
3. Copyright section now simply refers to the COPYING.LIB
file and the Copyright file which eliminates any ambiguities
about how PLplot is licensed.
4. Credits section now simply refers to the part of our website that
is devoted to that. This eliminates any ambiguities about who gets
the credit.
M cmake/modules/docbook.cmake
M doc/docbook/bin/api2man.pl.in
M doc/docbook/src/intro.xml
commit ae4835fea9b8b3439dc97299eee642e9683367bc
Author: Jerry Bauck <jbauck@users.sourceforge.net>
Date: Fri Apr 29 04:25:43 2016 -0700
Update Ada docs: Shapefile-related overloads
Adds a paragraph in the "One-offs" section of the Ada documention describing the overloaded procedures for plmapfill and plmapline that were required to allow the Ada programmer to code according to the PLplot documentation which allows passing two types of entities in the plotentries slot, an array of integers or a null pointer. Also mentions the the additional procedures which do not require conjuring a null pointer.
M doc/docbook/src/ada.xml
commit ea3746a7d3b477cf6d93c36c5c1593b557fb09d6
Author: Jerry Bauck <jbauck@users.sourceforge.net>
Date: Thu Apr 28 17:17:01 2016 -0700
Ada documentation: Clarification of Ada 2005 usage
Clarifies that an "Ada 2005" compiler is intended when before merely "2005" was used in two places.
M doc/docbook/src/ada.xml
commit 4ec18f8c52941238ac1af4195cb8ac1144bfc412
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Apr 28 11:28:58 2016 -0700
Fortran binding: update method of specifying private Fortran floating-point types
Previously we used kind(1.0) and kind(1.0d0) to determine the
appropriate kind values used to define private_plflt, private_single,
and private_double. However, in the spirit of the previous changes
for the private Fortran integer types, c_float and c_double are now
used as appropriate for defining private_plflt, private_single, and
private_double. Note the c_float and c_double parameters are kept
private to the plplot_types module, and I also took this opportunity
to keep the previously introduced c_int32_t parameter private to that
module as well.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie with gfortran 4.9.2) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
That script finished without any obvious run-time issues (confirmed by
grep -i error ../comprehensive_test_disposeable/*/*/output_tree/*.out
), and the PostScript differences relative to C results (determined by
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable/*/*/output_tree/*.out |less
) were perfect.
M bindings/f95/CMakeLists.txt
M bindings/f95/included_plplot_configured_types.f90.in
M bindings/f95/plplot_small_modules.f90
commit f00ee2a0fb0293e118a359d6e6312b30804b3420
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Thu Apr 28 11:16:07 2016 +0200
Fortran binding: use C_INT32_T kind for portability (PLINT etc.)
As Alan Irwin wrote:
The private types, private_plint, private_plbool, and
private_plunicode are Fortran types designed to match the C types
PLINT, PLBOOL, and PLUNICODE as closely as possible within the
constraint that Fortran does not have an unsigned integer type.
The most direct way to achieve this in a portable way is probably
to use the kind C_INT32_T from the ISO_C_BINDING module. This might
fail if the platform in question doesn't have 32 bits integers, but
then a lot of other things won't work either.
Tested by: Arjen Markus (arjenmarkus@users.sourceforge.net) on
Cygwin, MinGW64 and bare Windows, all three 64-bits platforms.
For Cygwin and MinGW64 the comprehensive test script was used, for
bare Windows the C and Fortran examples were run via a batchfile, then
the PostScript files were compared.
M bindings/f95/plplot_small_modules.f90
commit 314bae717aff3e1af3cd11cbf650f18c0a33a3ce
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Apr 27 16:39:30 2016 -0700
C examples: implement C-only if_plfsurf3d Boolean option for x08c.c
Some time ago when the capabilities of the C version of plfsurf3d were
generalized to process a variety of representations for the
two-dimensional z array, it was decided to demonstrate that C-only API
in x08c.c by replacing plsurf3d calls with more complex plfsurf3d
calls. However, that is confusing for those propagating example 8 to
other languages where plfsurf3d capabilities do not exist and likely
should not exist since we prefer to handle 2D arrays using the
preferred 2D representation for each language. Instead, for those
other languages plsurf3d should be used with the preferred
representation of the 2D z array for the language in question.
Therefore, x08c.c, has been changed to use plsurf3d by default, but
with the C-only Boolean option if_plfsurf3d to demonstrate the plfsurf3d
capabilities instead when a C user wants to try those.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target (which uses
plsurf3d by default for C example 8). All non-C languages had a perfect
PostScript comparison with the C results (calculated by default for C example
8 with plsurf3d) other than the long-standing
issues with OCaml, namely
ocaml
Missing examples :
Differing graphical output : 08 16 19 33
Missing stdout :
Differing stdout :
Furthermore I built the svg target and then tried the following tests:
valgrind examples/c/x08c -dev svg -fam -o test.svg
valgrind examples/c/x08c -dev svg -fam -o testf.svg -if_plfsurf3d
The valgrind reports were perfect (0 errors, no memory leaks are
possible) for both cases, and the (10 pages of) SVG results were identical
in both cases as well.
In sum, these are good test results for this change!
M examples/c/x08c.c
commit 3442bac79bf5a5c63a79bcc45cf0de51420dd8a5
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Apr 27 12:01:42 2016 -0700
Fortran binding: update method of specifying private Fortran integer types
These private types, private_plint, private_plbool, and
private_plunicode are Fortran types designed to match the C types
PLINT, PLBOOL, and PLUNICODE as closely as possible within the
constraint that Fortran does not have an unsigned integer type.
Previously we used kind = 4 for all these types which by historical
accident does correspond to 4-byte integers for most Fortran
compilers. But now at the suggestion of Wadud Miah of the NAG group we
use selected_int_kind(9) to determine the kind value that corresponds
to the minimum sized Fortran integers that can represent integers in
the range from -10^9 to +10^9. That will be 4-byte Fortran integers
on all platforms that support those, and, in any case, the C part of
PLplot will likely not work for the small number of platforms that
don't support 4-byte integers.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie with gfortran 4.9.2) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
That script finished without any obvious run-time issues (confirmed by
grep -i error ../comprehensive_test_disposeable/*/*/output_tree/*.out
), and the PostScript differences relative to C results (determined by
grep -B1 -A3 "Missing examples" ../comprehensive_test_disposeable/*/*/output_tree/*.out |less
) were perfect.
M bindings/f95/plplot_small_modules.f90
commit 62b5e5290f1836297fb2a411d8dc7dc5a10bd4a0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Apr 26 16:35:54 2016 -0700
libplplot: logic improvements for pl_create_tempfile and pl_create_tempfifo
Instead of using duplicate code to create the list of directories to
attempt to use for temporary file and fifo creation,
implement a static function, get_tmpdir_list, to create the list of
possible directories.
The list of directories that is tried is changed to be as follows:
The directory names in the environment variables:
"TMP" [Windows only],
"TEMP" [Windows only],
"TMPDIR" [Unix only];
the value of the P_tmpdir macro as defined in <stdio.h> [Unix only];
the current working directory; and
the following hard-coded locations as a last resort:
c:\\windows\\Temp [Windows only], and
"/tmp" [Unix only].
The above choices make the following changes in the directory list from
the previous code. "TMP" is added for the Windows case; the misspelling
P_TMPDIR ==> P_tmpdir is corrected and P_tmpdir is now only used for
the Unix case; and the current working directory is
added.
Note get_tmpdir_list delivers a list of non-NULL pointers that point
to NULL-terminated character strings, and it is up to
pl_create_tempfile and pl_create_tempfifo to use this list one string
at a time to find and use the first string that is a suitable
directory location for creating a temporary file or fifo. This is a
substantial improvement on the old code which included NULL pointers
in the list and which only tried the first list item that corresponded
to a non-NULL pointer.
A pldebug call is now made from both pl_create_tempfile and
pl_create_tempfifo to make it possible to debug cases where
there are difficulties in generating temporary files or fifos.
The bugs that were fixed in the previous code were the following:
* The misspelled P_TMPDIR macro mentioned above.
* Errors in the open function flags that are part of the solution when
mkstemp is not available. The O_BINARY, _O_SHORT_LIVED, and
_O_TEMPORARY flags are now removed for the Unix case since those flags
are not defined for that case, but those flags continue to be used for
the Windows case since they are available for that platform.
* A check for errors was implemented for the mkdtemp call in
pl_create_tempfifo. Without such a check the old code segfaulted when
an attempt was made to create a fifo in an inappropriate directory in
the list of possibilites.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_c_tk, and svg targets (to
satisfy necessary dependencies) and then running both
valgrind examples/c/x00c -dev svg -o test.svg -debug >| debug.out 2>&1
and
valgrind examples/c/x00c -dev tk -debug >| debug.out 2>&1
(The tk case is the only one that currently tests
pl_create_tempfifo.)
For the svg case, a perfect valgrind report was obtained (0 errors, no leaks are
possible) while for the tk case the valgrind report was good (0
errors, but leaks are possible). I ascribe that "leaks are possible"
result to issues with libtcl and libtk. In both cases the
appropriate debug messages were obtained as well as the appropriate
plots.
I repeated the same two tests for the 3 remaining possible combinations of the
following two local changes to the code:
* replace the preprocessing checks of the PL_HAVE_MKSTEMP macro with
PL_HAVE_MKSTEMP1 to emulate the case where mkstemp is not available.
* replace some or all of the valid directory possibilities with "whatever" to emulate
when some or all of the directories on the list are inappropriate.
The same good valgrind report results were obtained for all these three cases
which validates how these cases are currently handled by the
pl_create_tempfile and pl_create_tempfifo code.
In sum, from all this testing on a Unix platform I am pretty sure this
code will work on most Unix platforms, but testing is
required for the Windows case to make sure I haven't introduced
any showstopping bugs for that case.
M src/plstdio.c
commit a7b49bc5b013a93bf22d7f770dc109c1e6e82275
Author: Jerry Bauck <jbauck@users.sourceforge.net>
Date: Fri Apr 22 04:21:59 2016 -0700
Update Ada examples and bindings to remove all PostScript differences with corresponding C results
Update Ada thick and thin examples 8 to add page to demonstrate
limiting the extent of 3D plotting. Update Ada thick and thin examples
19 to add page to demonstrate Shapefile demo. Update Ada bindings
accordingly to add new 3D plotting with limited extent and new
Shapefile functionality. Miscellaneous white space and spelling fixes.
Tested by: Jerry Bauck <jbauck@users.sourceforge.net> on Mac OS X
(Version 10.9.5 "Mountain Lion") by configuring (using the cmake option
-DBUILD_TEST=ON), building (using make all), and running ctest. The resulting
PostScript difference summary was
ada
Missing examples :
Differing graphical output :
Missing stdout :
Differing stdout :
adathick
Missing examples :
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., perfect.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) by building the test_diff_psc target. The resulting
PostScript difference summary was also perfect for this platform.
M bindings/ada/plplot.adb
M bindings/ada/plplot.ads
M bindings/ada/plplot_auxiliary.adb
M bindings/ada/plplot_auxiliary.ads
M bindings/ada/plplot_thin.adb
M bindings/ada/plplot_thin.ads
M bindings/ada/plplot_traditional.adb
M bindings/ada/plplot_traditional.ads
M examples/ada/x08a.adb
M examples/ada/x19a.adb
M examples/ada/xthick08a.adb
M examples/ada/xthick19a.adb
commit 06ef0d0f077fdbcb8848a79f7a74772b29533e47
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Mar 16 12:34:54 2016 -0700
Tweak WARNING: messages for ocaml by consistently placing a blank after the colon
M cmake/modules/ocaml.cmake
commit c9f392ae25e48b951777951f2142046e253735e7
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Mar 15 20:40:04 2016 -0700
Style previous commits
M examples/java/x20.java
M include/plplot.h
M include/plstrm.h
M src/plshade.c
commit 55f40c01ebb5d4d18fee0012ca7c2c7562bebf30
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Mar 15 17:56:05 2016 -0700
plplottcltk library: Fix bug in plmaptexCmd
The bug was that GetEntries was used to find the last argument which
is a scalar integer quantity (unique among all the plmap* variants)
rather than a vector. When I replaced that GetEntries call by normal
processing of a scalar, then the following test
cd examples/tcl #(in the build tree)
../../bindings/tcl/pltcl -dev psc -o testt.psc
pltcl> source x19.tcl
pltcl> plinit
pltcl> x19
pltcl> plend
no longer produced the message
No matrix operator named "62"
I was also concerned that message was not emitted (before the above
plmaptexCmd fix) when the following variation of that same test was done:
../../bindings/tcl/pltcl -f x19 -dev psc -o testt.psc
That is, there appears to be a bug in the TCL error message propagation
in this case. That message is generated by Tcl_GetMatrixPtr in
bindings/tcl/tclMatrix.c, and I thought the
error in the TCL message propagation might be due to improper handling
of the case where Tcl_GetMatrixPtr returned NULL (indicating an error
condition).
To make such errors in error propagation much less likely, I have
replaced in bindings/tcl/tclAPI.c the ~100 calls to Tcl_GetMatrixPtr
and their associated hand-crafted error processing of a NULL value
returned by that function with the CHECK_Tcl_GetMatrixPtr macro
which I have #defined. It turns out, the
No matrix operator named "62"
message (before the above plmaptexCmd fix) still does not propagate
properly, but at least this macro approach is a nice code cleanup that
substantially reduces the number of lines of source code.
I also took this opportunity to comment out two debug printf
statements that had inadvertently been left in the previous commit.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target with
and without the cmake option -DHAVE_SHAPELIB:BOOL=OFF (without that
option is equivalent to -DHAVE_SHAPELIB:BOOL=ON). In both cases,
the PostScript difference result was perfect, i.e.,
tcl
Missing examples :
Differing graphical output :
Missing stdout :
Differing stdout :
That, is, the above plmaptexCmd fix and the above intrusive macro
change did not introduce any PostScript difference regressions.
M bindings/tcl/tclAPI.c
commit 1ec80b1c2faf28d86ea3b26fadfd136682bfdff9
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Tue Mar 15 21:17:45 2016 +0100
Remove typo in the handling of the plmapline wrapper function
A typo in the handling of the arguments for plmapline caused a problem for the
9 arguments version.
Tested by Arjen Markus (arjenmarkus@users.sourceforge.net) on Cygwin
M bindings/tcl/tclAPI.c
commit 1183a10d6d92fd41fb7ce38487ff45cc14feec85
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Sun Mar 13 13:33:40 2016 +0100
Solve issues with the redacted form of the Tcl API
Two examples, x15 and x18, showed differences in the PostScript output. Running
them interactively revealed small issues in example x15 (not all vectors had
the same length) and in the plpoly3 API (the vector draw must be one shorter
than the other vectors).
With these issues solved we are back to perfect results for these Tcl examples.
Tested by Arjen Markus (arjenmarkus@users.sourceforge.net) on Cygwin
M bindings/tcl/plapi.tpl
M examples/tcl/x15.tcl
commit 8c4fb79075fd00ba7d2962a250558b6fc1e159f7
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Sun Mar 13 12:42:52 2016 +0100
Add allocate statements to prevent problems if allocate-on-assign not supported by default
Some compilers, notably Intel Fortran, do not support the allocate-on-assign
feature of the Fortran 2003 standard by default. For Intel Fortran the
option -assume:lhs_realloc would have to be used.
To prevent this being necessary explicit allocations have been added.
The changes were tested on bare Windows with the Intel Fortran compiler.
Furthermore as the examples were extended to encompass all variants of the
Fortran binding to routines like plcont and others, the examples were
tested using the various logical parameters that trigger each variant.
Two examples will exhibit differences if using the identity transformations,
but this is inherent to this transformation. All variants give the exact
same PostScript files and no runtime problems.
Tested by Arjen Markus (arjenmarkus@users.sourceforge.net) on bare Windows
as well as Cygwin and MinGW-w64/MSYS2. All platforms 64-bits.
M examples/f95/x15f.f90
M examples/f95/x19f.f90
M examples/f95/x22f.f90
commit bae625420bc294febae65f692c1efe228a636869
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Mar 12 14:10:38 2016 -0800
DocBook documentation: complete rewrite of the C chapter
The C chapter of our documentation was completely out of date so had
to be rewritten. The new writeup emphasizes C99 standards compliance,
provides a list (which will eventually be referred to from elsewhere
in the documentation) of well-documented public PLplot C types
including the relevant callback types, and concludes with a paragraph
emphasizing our C examples as prototypes of how to call functions in
our core C library and the traditional (Makefile + pkg-config) and
CMake-based build systems for our installed C (and other language)
examples as prototypes for how to build C applications that use the
PLplot C library.
N.B. I suggest that all our different language chapters should be
changed to include such a paragraph if they don't do that already.
M doc/docbook/src/c.xml
M doc/docbook/src/plplotdoc.xml.in
commit e3bba2de79607fefd4c54a346e8545293299cf68
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Mar 11 14:45:56 2016 -0800
DocBook documentation: http://plplot.sourceforge.net ==> &PLplot-website;
M doc/docbook/src/deploying.xml
M doc/docbook/src/drivers.xml
M doc/docbook/src/intro.xml
commit f2c293cb4ea202ab907ad31ee8f82f14725807bb
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Mar 11 14:19:15 2016 -0800
DocBook documentation: rewrite introductory material to be consistent with website introductory material
M doc/docbook/src/intro.xml
M doc/docbook/src/plplotdoc.xml.in
commit f8373c04c17dd0952c325967f68d38e4351ef2b7
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Mar 11 14:17:14 2016 -0800
Website: tweak introductory material
M www/index.php
commit a700e71361a49af6fa481c76c7e806ca32128990
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Mar 7 17:17:28 2016 -0800
PLplot core C library: use typedefs to define callbacks
The introduced callback typedefs are the following:
typedef void ( *PLMAPFORM_callback )( PLINT n, PLFLT *x, PLFLT *y );
typedef void ( *PLTRANSFORM_callback )( PLFLT x, PLFLT y, PLFLT *xp, PLFLT *yp, PLPointer data);
typedef void ( *PLLABEL_FUNC_callback )( PLINT axis, PLFLT value, char *label, PLINT length, PLPointer data);
typedef PLFLT ( *PLF2EVAL_callback )( PLINT ix, PLINT iy, PLPointer data);
typedef void ( *PLFILL_callback )( PLINT n, const PLFLT *x, const PLFLT *y );
typedef PLINT ( *PLDEFINED_callback )( PLFLT x, PLFLT y);
These new PL*_callback types have names which are largely
self-documenting. These callback types considerably simplify the
specification of callback arguments in function prototypes and
definitions. I also anticipate they will make it much easier to
document our callback function arguments in our DocBook documentation,
although that documentation update has not been done yet.
N.B. use of these typedefs has so far been confined to our core C
library and our C++ binding, but they may also be used in the future
to simplify the implemention of callbacks in our other language
bindings.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_noninteractive target without
any configure, build, or run-time errors, and with no PostScript difference
regressions.
M bindings/c++/plstream.cc
M bindings/c++/plstream.h
M include/plplot.h
M include/plstrm.h
M src/plbox.c
M src/plcont.c
M src/plcore.c
M src/plimage.c
M src/plmap.c
M src/plshade.c
M src/plvect.c
commit 472abb7db4d1d118313f4b7b2cfaf1ed63de19c4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Mar 7 13:49:42 2016 -0800
Fix PostScript difference regressions introduced by dde39c8c (Fix long-standing off-by-one errors in plimage and plimagefr)
Commit dde39c8c was not sufficiently tested so that PostScript
difference regressions were only discovered after the commit was made.
These regressions (discovered by building the test_diff_psc target)
were that page 5 of example 20 was not rendered consistently with the
C result for the Python, Tcl, and Java languages.
These regressions were caused by pltr0 no longer having the identical
effect as a NULL callback as a result of the off-by-one fixes. The
solutions for these regressions are to use a NULL argument rather than
pltr0 for the C callback when the example has no callback-related
arguments in the call to plimagefr (this change was made to the Python
and Tcl bindings), and since the Java bindings do not currently have
an option to generate a NULL argument for the C callback modify the xg
and yg arrays in the Java example to exactly mimic the effect of a
NULL argument for the C callback.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target. As a result
of the above fixes the example 20 PostScript difference regressions are
now gone. The remaining differences (which have been with us for some
time) are the following:
tcl
Missing examples :
Differing graphical output : 15 18
Missing stdout :
Differing stdout :
ada
Missing examples :
Differing graphical output : 08 19
Missing stdout :
Differing stdout :
adathick
Missing examples :
Differing graphical output : 08 19
Missing stdout :
Differing stdout :
ocaml
Missing examples :
Differing graphical output : 08 16 19 33
Missing stdout :
Differing stdout :
M bindings/python/plplot.py
M bindings/tcl/tclAPI.c
M examples/java/x20.java
commit 89228703f355a282fab3ea5f7add03d00aa6e6c3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Feb 29 15:53:25 2016 -0800
DocBook documentation: update documentation of plerrx and plerry
Mostly replaced singular references to error bar with the proper
plural form, but some minor rewriting was done as well.
M doc/docbook/src/api.xml
commit 819e977266fd7fa8f0fbecf14e96ebf7a4613217
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Feb 25 18:41:19 2016 -0800
Fortran binding and examples: fix issues with plslabelfunc and plstransform callbacks
The issues were I had forgotten the "value" attribute in
type(c_ptr), value, intent(in) :: data
in several places for the plslabelfunc and plstransform callbacks, and
I also had failed to transform the label_out data properly for the
plslabelfunc case.
In Fortran example 19, I implemented using geolocation_labeler_data
for the plsfunclabel callback by default (ifno_label_data = .false),
but if ifno_label_data is locally set to .true. the
geolocation_labeler callback is used for plsfunclabel instead.
In Fortran example 22, I made it easier to test the two plstransform
possibilities: by default (ifno_transform_data = .false.) the
transform_data callback is used for plstransform, but if
ifno_transform_data is locally set to .true., then the transform
callback is used for plstransform instead.
The issues discussed above were turned up by the systematic testing I
did below. I thought I had done systematic testing of example 22
earlier which should have turned up the one value attribute issue for
plstransform with the transform_data callback but apparently not.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the svg, x19c, x22c, x19f95, and x22f95
targets and running the following valgrind commands:
valgrind examples/c/x19c -dev svg -o testc.svg -fam
valgrind examples/f95/x19f -dev svg -o testf.svg -fam
valgrind examples/c/x22c -dev svg -o testc.svg -fam
valgrind examples/f95/x22f -dev svg -o testf.svg -fam
For the example 19 case I ran the Fortran version twice; once
for ifno_label_data = .true. and once for .false.
For the example 22 case I ran the Fortran version twice; once
for ifno_transform_data = .true. and once for .false.
In all cases the valgrind reports were perfect (0 errors, no memory
leaks are possible), and the example 19 C and Fortran SVG results
agreed exactly, and the same for example 22.
M bindings/f95/plplot_double.f90
M bindings/f95/plplot_single.f90
M examples/f95/x19f.f90
M examples/f95/x22f.f90
commit cab11bc8c9ead8a4a2805a2752c98953b218010d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Feb 25 13:55:38 2016 -0800
Fortran example 19: normalize_longitude changed from external procedure to module procedure
Module procedures (i.e., procedures defined within a contains block)
are far superior to the external procedures that are a leftover from the
Fortran 77 era because module procedures have automatically generated interface
blocks which allows the compiler to do automatic type checking. Previously I could not
link the normalize_longitude function as a module procedure so I worked around that
by implementing it as an external procedure.
Through experimentation I discovered that the real issue was simply
(as a leftover from our old f77-like approach) that the type of the
normalize_longitude function was specified in the calling routine and
that turns out to be completely inappropriate for module procedures
that are functions. The current commit removes that type and
implements normalize_longitude as a module procedure, and the linker
is happy with that result. I also reworked the geolocation_labeler
callback to call the custom_labeler routine which does most of the
work in preparation for implementing a geolocation_labeler_data
callback alternative.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the svg, x19c, and x19f95 targets and
running
valgrind examples/c/x19c -dev svg -o testc.svg -fam
and
valgrind examples/f95/x19f -dev svg -o testf.svg -fam
The valgrind reports were perfect (0 errors, no leaks are possible),
and the C and Fortran SVG results were identical.
M examples/f95/x19f.f90
commit 2d022b98feb21c50776b40190710c512bae73aac
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Feb 25 11:32:42 2016 -0800
DocBook documentation: spelling and hyphenation fixes
M doc/docbook/src/api.xml
commit b5d5b014a4eca6b212f0ac5833e3300984650cd9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Feb 24 15:17:17 2016 -0800
Update doxygen configuration for creating call and caller graphs
I did this by setting HAVE_DOT, CALL_GRAPH and CALLER_GRAPH to YES in
doc/Doxyfile.in.
I updated that doxygen configuration file using the
doxygen -u Doxyfile.in
command.
I added all Fortran included files (see comments below in the Tested
by section) and deprecated/old files to the list of excluded files
in Doxyfile.in.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian testing with both doxygen and graphviz packages installed)
with cmake option -DBUILD_DOX_DOC=ON. My first attempt to build the
build_doxygen target failed with the following errors:
Error in file /home/software/plplot/HEAD/plplot.git/bindings/f95/included_plplot_parameters.f90 line: 186, state: 10
********************************************************************
********************************************************************
Error in file /home/software/plplot/HEAD/plplot.git/bindings/f95/included_plplot_real_interfaces.f90 line: 5203, state: 11
********************************************************************
Segmentation fault
I excluded all such Fortran include files from Doxyfile.in (this
change is part of the current commit), and that appeared to work
around these doxygen issues, but the results for Fortran source files
that, for example, include included_plplot_real_interfaces.f90 such as
plplot_double.f90 and plplot_single.f90 are seriously incomplete.
However, the remaining results look good, especially all
the call graphs and caller graphs that are now embedded in the
doxygen-generated documentation in html format.
M doc/Doxyfile.in
commit 189a7c6c3057e1831703608bc8f449ae57ce4459
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Feb 23 15:43:23 2016 -0800
Fortran examples: test the six possible plvect signatures
The signatures being tested are (1) no callback-related arguments
which means the pltr0 (identity transform) C callback is used; (2)
singly dimensioned xg and yg which means the pltr1 C callback is used;
(3) doubly dimensioned xg and yg which means the pltr2f C callback is
used; (4) tr which means a special Fortran callback is used that uses
the tr array to do the transformation; (5) Fortran callback without
data is used; and (6) Fortran callback with data is used.
By default example 22f tests 6, 2, and 3. However, convenient (change
one or two logical variable parameters) local changes can be made to
example 22f such that
tr_callback .true. ==> 6 replaced by 4
tr_callback .false., identity_callback .true. ==> 6 replaced by 1
tr_callback .false., identity_callback .false., mypltr_callback .true. ==> 6 replaced by 5
Case 1 transforms the X and Y results quite differently than the rest
so there are expected differences for this case.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the svg, x22c and x22f targets and
running
valgrind examples/c/x22c -dev svg -fam -o testc.svg
valgrind examples/f95/x22f -dev svg -fam -o testf.svg
The valgrind run on x22f was done 4 times (once with default and 3
times with local modifications of that example to replace 6 by one of
4, 1, or 5). As a result, the 6 possible signatures of plvect were
tested.
In all cases the valgrind reports were perfect (0 errors, no leaks
possible). Furthermore, the Fortran and C example 22 svg results were
identical for all variations of Fortran example 22 except expected
small changes in scale and substantial changes in tick mark placement
and labelling for the 1 case.
In sum, these tests of the 6 possible plvect signatures showed
the expected results in all cases.
M examples/f95/x22f.f90
commit d9bbb87223d68c510f450294e62a1f63bdfe30a6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Feb 21 21:21:06 2016 -0800
Fortran examples: use more modern Fortran capabilities in example 22
At the same time change from calling just the doubly dimensioned
xg and yg signature of plvect to calling that signature and also
the singly dimensioned xg and yg signature to test 2 of the 6
signature possibilities for plvect with this example.
Note this change is in preparation for a more extensive change that
tests all 6 signature possibilities.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the svg, x22c and x22f95 targets and
running
valgrind examples/c/x22c -dev svg -fam -o testc.svg
valgrind examples/f95/x22f -dev svg -fam -o testf.svg
In all cases the valgrind reports were perfect (0 errors, no leaks
possible). Furthermore, the Fortran and C example 22 svg results were
identical.
In sum, these tests of the 2 (of 6) possible plvect signatures showed the
expected results in all cases.
M examples/f95/x22f.f90
commit 096fe162038003212765a313559df0ca24276543
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Feb 21 16:18:30 2016 -0800
Fortran examples: test all (the now) six possible plimagefr signatures
N.B. this is an update of commit
2f25e6f963d205014b747bc566de401f2b103bf1 to test the recently
implemented "tr" signature of plimagefr (as well as the remaining
plimagefr signatures).
The signatures being tested are (1) no callback-related arguments which means no
callback is used and instead the x and y index ranges are linearly
transformed to the ranges specified by the xmin, xmax, ymin, and ymax
plimagefr arguments; (2) singly dimensioned xg and yg which means the
pltr1 C callback is used; (3) doubly dimensioned xg and yg which means
the pltr2f C callback is used; (4) tr which means a special Fortran
callback is used that uses the tr array to do the transformation; (5) Fortran callback without data is
used; and (6) Fortran callback with data is used.
By default example 20f tests 6, 2, and 3.
However, if local changes are made to example 20f such that
no_callback .true. ==> 6 replaced by 1
no_callback .false., tr_callback .true. ==> 6 replaced by 4
no_callback .false., tr_callback .false., mypltr_callback .true. ==> 6 replaced by 5
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the svg, x20c and x20f targets and
running
valgrind examples/c/x20c -dev svg -fam -o testc.svg
valgrind examples/f95/x20f -dev svg -fam -o testf.svg
The valgrind run on x20f was done 4 times (once with default and 3
times with local modifications of that example to replace 6 by one of
1, 4, or 5). As a result, the 6 possible signatures of plimagefr were
tested.
In all cases the valgrind reports were perfect (0 errors, no leaks
possible). Furthermore, the Fortran and C example 20 svg results were
identical for all variations of Fortran example 20.
In sum, these tests of the (now six) possible plimagefr signatures showed the
expected results in all cases.
M examples/f95/x20f.f90
commit 3fbcf3f36b63eebafe90b3daaacba61b848ba6f3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Feb 21 14:45:49 2016 -0800
Fortran binding: implement "tr" signature of plimagefr
This commit rectifies an oversight in the implementation of the new
Fortran binding which should for backwards compatibility reasons
supply a "tr" signature for plimagefr since that signature was also
supplied by the old Fortran binding.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the plplotf95 library without issues.
N.B. this is just a build test, and the implementation of a run-time
test for this plimagefr signature is planned soon.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplotf95_ifort.def
commit 2f25e6f963d205014b747bc566de401f2b103bf1
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Feb 21 11:58:29 2016 -0800
Fortran examples: test all five possible plimagefr signatures
Those signatures are (1) no callback-related arguments which means no
callback is used and instead the x and y index ranges are linearly
transformed to the ranges specified by the xmin, xmax, ymin, and ymax
plimagefr arguments; (2) singly dimensioned xg and yg which means the
pltr1 C callback is used; (3) doubly dimensioned xg and yg which means
the pltr2f C callback is used; (4) Fortran callback without data is
used; and (5) Fortran callback with data is used.
By default example 20f tests 5, 2, and 3.
However, if local changes are made to example 20f such that
no_callback .true. ==> 5 replaced by 1
no_callback .false., mypltr_callback .true. ==> 5 replaced by 4
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the svg, x20c and x20f targets and
running
valgrind examples/c/x20c -dev svg -fam -o testc.svg
valgrind examples/f95/x20f -dev svg -fam -o testf.svg
The valgrind run on x20f was done 3 times (once with default and 2
times with local modifications of that example to replace 5 by either
1 or 4). As a result, the 5 possible signatures of plimagefr were
tested.
In all cases the valgrind reports were perfect (0 errors, no leaks
possible). Furthermore, the Fortran and C example 20 svg results were
identical for all variations of Fortran example 20.
In sum, these tests of the five possible plimagefr signatures showed the
expected results in all cases.
M examples/f95/x20f.f90
commit dde39c8c1270a402230e785eb234a5a277f13d36
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Feb 21 11:47:16 2016 -0800
Fix long-standing off-by-one errors in plimage and plimagefr
Prior to this fix the selected subset of Chloe image (page 3 of
example 20) was displayed with a small offset (as determined by blink
comparing the two) from the original Chloe image (page 2 of the
example). This fix cures this offset and also maintains the good
alignment between the original image and the reduced dynamic range
variant of this image (page 5 of the example).
M src/plimage.c
commit ac55fa456ca25b9e8389d1407fa65b7b24d0a9fc
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Feb 20 09:13:44 2016 -0800
Fortran examples: test all six possible plshades signatures
Those signatures are (1) no callback-related arguments which means no
callback is used and instead the x and y index ranges are linearly
transformed to the ranges specified by the xmin, xmax, ymin, and ymax
plshades arguments; (2) singly dimensioned xg and yg which means the
pltr1 C callback is used; (3) doubly dimensioned xg and yg which means
the pltr2f C callback is used; (4) tr which means a special Fortran
callback is used that uses the tr array to do the transformation; (5)
Fortran callback without data is used; and (6) Fortran callback with
data is used.
By default example 16f tests 6, 2, and 3.
However, if local changes are made to example 16f such that
no_callback .true. ==> 6 replaced by 1
no_callback .false., tr_callback .true. ==> 6 replaced by 4
no_callback .false., tr_callback .false., mypltr_callback .true. ==> 6 replaced by 5
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the svg, x16c and x16f targets and
running
valgrind examples/c/x16c -dev svg -fam -o testc.svg
valgrind examples/f95/x16f -dev svg -fam -o testf.svg
The valgrind run on x16f was done 4 times (once with default and 3
times with local modifications of that example to replace 6 by either
1, 4, or 5). As a result, the 6 possible signatures of plshades were
tested.
In all cases the valgrind reports were perfect (0 errors, no leaks
possible). Furthermore, the Fortran and C example 16 svg results were
identical for all variations of Fortran example 16.
In sum, these tests of the six possible plshades signatures showed the
expected results in all cases.
M examples/f95/x16f.f90
commit 23aeb9c89a2cdec6c30094fdd250f5be1bff6465
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Feb 20 00:55:38 2016 -0800
Fortran examples: Fixed off-by-one error in dimension of single-argument arange
Bumping this dimension by 1 to the correct value did not make any difference
to the limited set of examples where arange was called with just one
argument, but I am still glad this "accident waiting to happen"
is gone.
I then tested the single-argument arange much more strongly by
replacing double-argument arange by single-argument arange whenever
the starting index was 0. That caused no errors, see below.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target with
perfect PostScript difference results for Fortran.
M examples/f95/plf95demolib.f90
M examples/f95/x00f.f90
M examples/f95/x03f.f90
M examples/f95/x05f.f90
M examples/f95/x08f.f90
M examples/f95/x09f.f90
M examples/f95/x11f.f90
M examples/f95/x15f.f90
commit c0a650d7c14e3d5b5d509804b61491fcc6ccdeff
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Feb 19 23:31:22 2016 -0800
Fortran examples: test all six possible plshade signatures
Those signatures are (1) no callback-related arguments which means no
callback is used and instead the x and y index ranges are linearly
transformed to the ranges specified by the xmin, xmax, ymin, and ymax
plshade arguments; (2) singly dimensioned xg and yg which means the
pltr1 C callback is used; (3) doubly dimensioned xg and yg which means
the pltr2f C callback is used; (4) tr which means a special Fortran
callback is used that uses the tr array to do the transformation; (5)
Fortran callback without data is used; and (6) Fortran callback with
data is used.
Example 16af always tests 3, and by default example 15f tests 6 and 1.
However, if local changes are made to example 15f such that
tr_callback .true. ==> 6 replaced by 4
tr_callback .false., pltr1_callback .true. ==> 6 replaced by 2
tr_callback .false., pltr1_callback .false., mypltr_callback .true. ==> 6 replaced by 5
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the svg, x15c, x15f95, and x16af targets and
running
valgrind examples/c/x15c -dev svg -fam -o testc.svg
valgrind examples/f95/x16af -dev svg -fam -o testf.svg
valgrind examples/f95/x15f -dev svg -fam -o testf.svg
The valgrind run on x15f was done 4 times (once with default and 3
times with local modifications of that example to replace 6 by either
4, 2, or 5). As a result, the 6 possible signatures of plshade were
tested.
In all cases the valgrind reports were perfect (0 errors, no leaks
possible). Furthermore, the Fortran and C example 15 svg results were
identical for all variations of Fortran example 15. The example 16af
svg results looked good, but there was no C results to compare with
those.
In sum, these tests of the six possible plshade signatures showed the
expected results in all cases.
M examples/f95/x15f.f90
commit 51169ec4117513a087747c7f63291b30fccbe5ee
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Feb 19 09:09:50 2016 -0800
Fortran examples: test all six plcont signatures
Those signatures are (1) no callback-related arguments which means the
pltr0 C "identity transform" callback is used; (2) singly dimensioned
xg and yg which means the pltr1 C callback is used; (3) doubly
dimensioned xg and yg which means the pltr2f C callback is used; (4)
tr which means a special Fortran callback is used that uses the tr
array to do the transformation; (5) Fortran callback without data is
used; and (6) Fortran callback with data is used.
By default the example now tests 2, 3, 5, and 6, but if tr_callback is
locally set to .true., then 5 and 6 are replaced by 4, and if
tr_callback is locally set to .false. and identity_callback locally
set to .true., 5 and 6 are replaced by 1.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the svg, x09c, and x09f95 targets and
running
valgrind examples/c/x09c -dev svg -fam -o testc.svg
valgrind examples/f95/x09f -dev svg -fam -o testf.svg
The valgrind run on x09f was done three times (two with local
modifications of the examples to replace (5 and 6) by either 4 or 1. As a
result, the 6 possible signatures of plcont were tested.
In all cases the valgrind reports were perfect (0 errors, no leaks
possible). Furthermore, the Fortran and C svg results were identical
when replacing (5 and 6) by 4. As expected the svg result has
different tick marks and labels of those tick marks, but not different
contours when replacing (5 and 6) by 1 since the latter (identity
transform) case maps to the range of x and y indices, rather than the
intervals of -1. to 1. that are obtained with either (5 and 6) or 4.
In sum, these tests of the six possible plcont signatures showed the
expected results in all cases.
M examples/f95/x09f.f90
commit 9d436ac6032b08f0cce78ae59a4a8ecc8ca69674
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Feb 18 11:13:57 2016 -0800
Fortran binding: implement Fortran callbacks for plcont, plshade, plshades, plimagefr, and plvect
This implementation was almost trivial because it used the compact
style, and the required transform callback infrastructure had already
been set up in that style for the plstransform case.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the plplotf95 target.
N.B. This build test was a success, but run-time testing of
all these new Fortran callbacks needs to be done as well. That
will require changes to the Fortran examples which are still
in the planning stage.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplotf95_ifort.def
commit f340a35e8457a8047898cc0d8cfb09367b5f35cc
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Feb 17 21:25:02 2016 -0800
Fortran binding: standardize implementation of plrandd, plslabelfunc, and plstransform
These 3 functions all have floating-point attributes, but they cannot
be disambiguated so we only provide the double-precision form of
these. Accordingly we previously implemented these functions in
plplot.f90, but we have now moved their implementation to
plplot_double.f90 because that allows us to use the standard compact
implementation method. The advantages of this approach are much less
name clutter (fewer explicit _double and _single name qualifiers) and
enabling of a plan to reuse the now-standard transform callbacks when
implementing full Fortran callbacks for plcont, plshade, plshades,
plimagefr, and plvect. The disadvantage of this approach is the
number of spurious warnings from gfortran, e.g.,
Warning: Symbol 'pllabelerf2c' at (1) is marked PRIVATE but has been
given the binding label 'plplot_double_private_pllabelerf2c'
concerning private C bindings have increased from 2 to 10 (5 each for
the plplot_double and plplot_single modules). However, we view those
warnings as a gfortran bug (see
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111> and
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861>) so hopefully in
time they will disappear.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target. There were no
build or run-time issues, and the PostScript difference results for
f95 were perfect.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot.f90
M bindings/f95/plplot_double.f90
M bindings/f95/plplot_single.f90
M bindings/f95/plplotf95_ifort.def
commit 0258c58b09d87866cd2e4bce40b16755efaf782b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Feb 17 17:09:17 2016 -0800
Document backwards incompatibility in plimagefr signature without callback-related arguments
I implemented this signature for the new Fortran binding some time ago
to be consistent with how the plshade and plshades signatures without
callback-related arguments are handled. But today I realized this
consistent approach was not compatible with what was implemented (in
error, I believe) in the old Fortran binding. So I have now documented
this backwards incompatibility.
M README.release
commit 55a6de0240754a47092d60b6e076de3f769ca823
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Feb 17 15:27:27 2016 -0800
Fortran binding: finish replacing pltr0f callback by pltr0
The plcont and plvect signatures without callback-related arguments
(i.e., no trailing xg, yg, tr, or callback arguments) used the pltr0f
callback internally in the old Fortran binding. However, pltr0f has a
problematic offset of one in C index interpretation compared to pltr0
(see further discussion on the plplot-devel mailing list). Therefore,
I had previously changed this signature of plcont to use the correct
pltr0 callback, and this commit completes that change by doing the
same thing for the relevant signature of plvect. As a result the
pltr0f internal callback (called plplot_private_pltr0f) is no longer
needed by our Fortran binding and has been completely removed.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target. There were no
build or run-time issues, and the PostScript difference results for
f95 were perfect.
M README.release
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_small_modules.f90
commit 062786559a01160d9f8eb36cb0e3733e3002dd46
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Feb 17 13:47:12 2016 -0800
Abort if plvect called with NULL pltr callback
This change follows what is done in the equivalent plcont case.
M src/plvect.c
commit d003776d18c0fb3159b4e4dd35b3681e9fd27ea4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Feb 17 13:46:33 2016 -0800
Style previous commit
M src/plmap.c
commit 335bc52f9b9c5deee11a6d10d5d2ad477516aad2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Feb 16 17:27:29 2016 -0800
Fortran binding: implement plsvect in compact form
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot.f90
M bindings/f95/plplotf95_ifort.def
commit 4fe0797938483ab21fdb35398ff33d9136663ed2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Feb 16 15:08:45 2016 -0800
Automatically generate plplotf95_ifort.def from the symbols in the plplotf95 library
Implement a new (Unix-only) target "check_ifort_definitions_file"
which automatically generates an ifort def file from the symbols in
the latest version of the plplotf95 library and compares that result
with the plplotf95_ifort.def file in the source tree. If the two
files are not the same, the user has a chance to review the changes.
If those changes are acceptable (the usual case), then the user can
copy by hand the generated file in the build tree on top of the
existing file in the source tree and commit that result. If the
changes are not acceptable (rare), then tweaks must be made to the
method (a combination of cmake and sed logic) of generating the ifort
def file from the symbols in the plplotf95 library.
For the current case, the changes were to insert a commentary header
(following the ";" comment syntax for .def files documented at
<https://msdn.microsoft.com/en-us/library/h41zhe21.aspx>) and to
adjust to a small number of changed symbol names that are the result
of recent changes (i.e., the plmap* and plmeridians compact style of
implementation) in the way that plplotf95 is implemented. So although
I cannot test this result (no access to MSVC), my feeling is it should
work so long as the comment syntax that is documented above actually
works for the ifort case.
M bindings/f95/CMakeLists.txt
A bindings/f95/generate_ifort_deffile.sed
M bindings/f95/plplotf95_ifort.def
commit 98800a7cb861768940ce0d6b80c91523cb72512b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Feb 16 10:44:30 2016 -0800
Sort ifort definition file
Put the existing ifort definition file in sorted order to give a good
basis of comparison with the forthcoming automatically generated
version of this file.
M bindings/f95/plplotf95_ifort.def
commit 971cb37580b50d19cab45e14da4901516dceb407
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Feb 15 17:55:44 2016 -0800
Fortran binding: simplify implementation style for plmap* and plmeridians
The old style implemented the single-precision and double-precision
variants of plmap, plmapfill, plmapline, plmapstring, plmaptex, and
plmeridians explicitly in plplot.f90 with 99 per cent of the code duplicated
between the two variants.
For the new style I have found a way to implement these functions in
included_plplot_real_interfaces.f90 which automatically cuts down on
the code that has to be maintained for these functions by 50 per cent
and which makes understanding the interfaces for these functions
substantially easier.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the x19c, x19f95, and svg targets and
then running
valgrind examples/c/x19c -dev svg -fam -o testc.svg >& valgrindc.out
and
valgrind examples/f95/x19f -dev svg -fam -o testf.svg >& valgrindf.out
These valgrind reports were perfect (i.e, 0 errors, no leaks are
possible) even for gcc optimization flags -O2 or -O3 (see previous
commit), the C SVG results looked good, and Fortran SVG results were
identical to the C results.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot.f90
M bindings/f95/plplot_double.f90
M bindings/f95/plplot_single.f90
commit 30aa66a9fc71901221a31315152d93ba726aabd2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Feb 15 17:43:24 2016 -0800
Fix memory management issue for -O2 or -O3 gcc optimization flags
The issue that was fixed was that for the libplplot core library
compiled with gcc optimization flag -O2 or -O3, example 19 produced
valgrind reports indicating memory management issues (invalid reads)
associated with the allocated filename used in src/plmap.c.
So I looked carefully at everything to do with filename and did some
code cleanup (drop attempt to concatanate an empty string, drop
attempt to save truncatedfilename which is never used, and only
calculate warning string when that warning is actually going to be
used). I also changed the type of filenamelen from int to size_t. I
have no idea which of these minor changes made the difference, but the
result is the valgrind report is now perfect (0 errors, no leaks are
possible) for both gcc options -O2 and -O3.
M src/plmap.c
commit bbff8afe3d4402a1158f90b92abf6934066f5ccd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Feb 14 12:28:15 2016 -0800
Attempt at another fix for the plplotLibDir visibility issue
The fix for this issue that was just reverted essentially dropped
visibility for all symbols in libplplottcltk. The present fix
instead drops visibility for just the plplotLibDir symbol in
libplplottcltk.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_pltcl_standard_examples target.
That custom target built all dependencies correctly which is the
principal positive test result we have at the present time for the
present fix. The custom target also ran the first 14 examples without
issues, but failed to run the 15th Tcl example because of another
recently introduced issue (the recent plplat changes for the Tcl
binding). Until those other issues are fixed we necessarily must use
such limited testing of the present fix, but so far so good with the
present fix.
M bindings/tcl/tclAPI.c
commit ca170c0961dd070bd7ec03d5825fde02a5a87fa3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Feb 14 11:49:24 2016 -0800
Revert commit b94370e because it causes build issues
Commit b94370e cannot be correct since it stops essentially all
symbols from being exported from libplplottcltk. And obviously making
the library useless like this leads to build errors and/or linking
issues for all applications that link to it. For example, pltcl
requires symbols defined by libplplottcltk to be visible. I confirmed
build errors for this application on Linux with gcc option
-fvisibility=hidden which are solved by the present commit, but
presumably similar build errors will occur for MSVC prior to
the present commit as well.
M include/pldll.h.in
commit dbc889263f38c0dea76e130475c7a91efd3d3d4a
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Sun Feb 14 15:53:57 2016 +0100
First step in implemented redacted API for Tcl
This commit makes it possible to drop most size arguments for the Tcl binding. It does not yet include an adaptation of the examples to this new set-up and testing has been limited so far. Only the generated interfaces have been adapted - for the remaining, more complicated, interfaces not much needs to be done, they already relied on the matrix functions for determining the sizes. The only thing is that some commands are missing one version.
Tested by Arjen Markus <arjenmarkus@users.sourceforge.net> on Cygwin
M bindings/tcl/plapi.tpl
M bindings/tcl/pltclgen.tcl
M bindings/tcl/tclcmd.tpl
M examples/tcl/x01.tcl
commit b94370e2b246ce8a06692c41eafce346ea2ac5d6
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Sun Feb 14 14:55:33 2016 +0100
Solve a problem with the plplotLibDir variable under "bare" Windows
When using MSVC as the C compiler under Windows, the build for the Tcl binding failed on an unresolved symbol "plplotLibDir". Apparently the combination of macros as used in pldll.h caused this symbol to be marked as "export" instead of "import". With the change in this commit the error disappears and the Tcl examples work fine. This has no consequences for platforms where symbols need not to be decorated with "import" or "export" attributes.
Tested by Arjen Markus <arjenmarkus@users.sourceforge.net> on "bare" Windows (MSVC 2013, 64 bits) and Cygwin (gcc 4.9.3)
M include/pldll.h.in
commit d6cfc33e8eb9af9640df1cb4dc737c03f5567f2a
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Sun Feb 14 14:35:43 2016 +0100
Several routines were missing in the .def file - added now
Due to an error in the Tcl bindings the previous build did not complete, so the examples were not built. A complete build turned up more routines that needed to be exported.
Tested by Arjen Markus <arjenmarkus@users.sourceforge.net> on "bare" Windows (Intel Fortran 2015)
M bindings/f95/plplotf95_ifort.def
commit 59f55b5b5dc6a286f93e7c92ee3078c020d59a68
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Sun Feb 14 13:29:03 2016 +0100
Correct the names in the .def file for Intel Fortran
The .def file defines which routines are exported from the Fortran DLL. It appears that this is no longer necessary for gfortran (Cygwin as well as MinGW). Therefore exclude adding the .def under MSYS (shell for MinGW) as well.
Note:
The older version of gfortran available under MinGW (the old version), 4.8.3, has trouble with the multiple interfaces to c_plfill and with the use of c_loc for arrays that do not have the bind(c) attribute. Later versions of gfortran do not complain about this, neither does Intel Fortran.
Tested by Arjen Markus <arjenmarkus@users.sourceforge.net> under "bare" Windows (Intel Fortran 2015), Cygwin (gfortran 4.9.3) and MinGW64/MSYS2 (gfortran 5.2.0)
M bindings/f95/CMakeLists.txt
M bindings/f95/plplotf95_ifort.def
commit 311a32685cfdb6f32b00dbeee580945c541adf01
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Feb 13 18:09:37 2016 -0800
Fortran binding: convert inconsistent array size case from error to warning
Our old Fortran binding was completely sloppy about array size
consistency so our users may well have become completely sloppy about
this as well. Our previous array-size consistency enforcement work
for the new Fortran binding consisted of emitted an error message and
immediately returning (without attempting to invoke the underlying
PLplot C API). There are a large number of such consistency rules so
Arjen and I have now decided that approach is too harsh and will
likely encourage users to use the old Fortran binding (or some other
plotting package, altogether). So we have converted from that
harsh approach to a more user-friendly one where we warn the users of
inconsistent array sizes and attempt to continue with the call to the
underlying PLplot C API.
This new more user-friendly approach to enforcement of array size consistency
has been documented in README.release, bindings/f95/README_array_sizes,
and doc/docbook/src/fortran95.xml.
M README.release
M bindings/f95/README_array_sizes
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot.f90
M doc/docbook/src/fortran95.xml
commit 105d3fdd596067b9c1c1ade47c4e21156a1488ad
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Feb 12 22:57:07 2016 -0800
Convert from "==" form to "=" form in shell-script tests
The "=" form is the form that is typically used in these scripts so
replace the remaining "==" forms by the "=" forms for the sake of
consistency and also because the "=" form is more standard usage.
This change suggested by J. Lewis Muir.
M plplot_test/test_diff.sh.in
M plplot_test/test_single_tcl.sh
M plplot_test/test_tcl.sh.in
commit 9ff8792c5ae33cc86bfa585e4858d5ab836cf33b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Feb 12 22:46:17 2016 -0800
Implement a cmake_command option to the script
This option allows users to specify a full pathname for the cmake
command rather than having to modify the PATH to specify the cmake
version they want to use.
I also reordered the --help output and also the self-documentation of
the commands that are run by the script.
M scripts/comprehensive_test.sh
commit 3ece747fbb1d1da888abff7a9b486834a538e719
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Feb 9 16:26:54 2016 -0800
Minimum CMake version is now 3.0.2 for Linux and 3.3.2 for all other platforms.
The details of the changes are as follows:
The minimum version for Linux stays the same at 3.0.2.
The minimum version for Cygwin has been bumped from 3.0.2 to 3.3.2
(which should be OK since Cygwin started providing CMake-3.3.2 in
2015-11).
The minimum version for all non-Cygwin and non-Linux platforms has
been reduced from 3.4.3 to the previous 3.3.2 at the request
of some of the PLplot developers.
In the future, the rules of thumb I will use to decide when to
bump these versions is as follows:
Linux: the CMake minimum version will be bumped when Debian stable
(currently jessie) provides that version. Debian stable currently
provides 3.0.2.
All other platforms: the CMake minimum version will be bumped when
both Cygwin and MinGW-w64/MSYS2 provide a "matured" version (the last
in any given minor series of CMake releases which is typically
released near the time the next series of minor releases is started).
For CMake 3.x those matured versions are currently 3.0.2, ...,
3.3.2, and 3.4.3. Both Cygwin (see
<http://cygwin.com/cgi-bin2/package-grep.cgi?grep=cmake&arch=x86_64>)
and MinGW-w64/MSYS2 (see
<http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/>)
currently provide CMake-3.3.2, but not (yet) CMake-3.4.3 which means
our non-Linux minimum of 3.3.2 currently follows this rule of thumb.
M CMakeLists.txt
M examples/CMakeLists.txt
commit 76562c8a5ed6277308a9474949de72905aefcbfc
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Feb 7 19:32:47 2016 -0800
Fortran binding: implement size consistency checks on array argument dimensions
I have implemented the same rules for consistency of Fortran array argument
dimensions as are already established for the swig-generated bindings
case via the "Ck" arguments in bindings/swig-support/plplotcapi.i and
also other bindings cases. I have written an explicit summary of these rules in
bindings/f95/README_array_sizes and adjusted the Fortran examples to
conform to these rules.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target with no
error messages concerning violating the dimension consistency rules in
bindings/f95/README_array_sizes and perfect PostScript
differences for the f95 case. That is there were no Fortran
regressions due to these intrusive changes.
M README.release
A bindings/f95/README_array_sizes
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot.f90
M examples/f95/x01f.f90
M examples/f95/x08f.f90
M examples/f95/x09f.f90
M examples/f95/x14f.f90
M examples/f95/x20f.f90
M examples/f95/x30f.f90
commit 640fd5c02890370b9b16038cb55f6d1725b56e8b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Feb 6 21:17:41 2016 -0800
Bump CMake minimum version to 3.4.3 for all platforms other than Linux and Cygwin
For Linux and Cygwin the minimum version remains 3.0.2.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running (using a CMake 3.4.3 version that I built myself
using the standard bootstrap method)
scripts/comprehensive_test.sh
Note the lack of script options which means the script tested
virtually every interactive and noninteractive component of PLplot in
the build tree, installed examples tree with CMake-based build system
and installed examples tree with traditional build system for each of
our 3 principal linking models (shared libraries/dynamic devices,
shared libraries/nondynamic devices, and static libraries/nondynamic
devices).
The above comprehensive test had no build issues or catastrophic
run-time issues such as segfaults confirming that all the various
ways we use CMake to find libraries, configure our build, and
configure tests all appear to work fine with CMake-3.4.3.
M CMakeLists.txt
M examples/CMakeLists.txt
commit 0641b2c85c566ab8951528d7758aaf7c830307cf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Feb 5 19:31:16 2016 -0800
Clarify copyright terms
These clarifications consist of adding many more sections in the Copyright
file concerning known cases where the copyright license is different
from our default LGPL version 2+ license, and clarifying the copyright
notice and licensing language of the www/css/style.css.in file.
M Copyright
M www/css/style.css.in
commit 838be7e1ff831035d525c47b0746f18373f09212
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Feb 5 14:43:20 2016 -0800
Update interactive Octave test script
This script runs a large subset of the Octave "p" examples for
interactive devices. This script is called by "./plplot-test.sh
--interactive_octave" and that command is also called by the
test_octave_xwin target in the build tree and also the CMake-based
installed examples tree.
I updated the script to be exactly consistent with the corresponding
"p" example part of the noninteractive octave test script except for
the list of "p" examples that are run (which is generally much more
complete than for the noninteractive test case).
I only tested the interactive octave test script for interactive
devices xwin and tk because the other interactive devices fail due to
the current well-known stunted interactive capabilities that are
implemented for the other devices compared to xwin and tk.
For the Debian jessie version of octave (3.8.2-4) I discovered a
number of "p" examples that segfaulted (p4, p5, p6, p7, p10, and p11)
so I removed those and p20 (which exercises p4, etc.) from the
complete list of "p" examples. The result was the interactive octave
tests finally became reliable again with both the xwin and tk devices.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) for the shared case by building the test_octave_xwin in the
build tree and CMake-based installed examples tree and by running
./plplot-test.sh --interactive_octave --device=xwin --verbose
and
./plplot-test.sh --interactive_octave --device=tk --verbose
in the traditionally built installed examples tree. For what it is
worth this was done after running "make test_noninteractive" and "make
test_interactive" from $prefix/share/plplot*/examples, although
building those targets should not be necessary in order to run the
above two test commands.
For all these different tests, there were no run-time errors and the
interactive results (including the new "Chloe" test image) looked good
which verifies, for example, that the single location for Chloe.pgm in
the source tree, build tree, and installed examples tree works for all
these different tests
M plplot_test/test_octave_interactive.sh.in
commit 1caa2370a9a48e0ab5a76f0908cda96a9d7b3592
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Feb 5 14:07:23 2016 -0800
Replace "Lena" image with "Chloe" image
The "Lena" test image that we used for our standard example 20
implementations for each of our supported languages (as well as
special example p17 for the octave case) has problematic licensing.
For example, see discussion in <https://en.wikipedia.org/wiki/Lenna>
and especially <https://en.wikipedia.org/wiki/File:Lenna.png>.
This situation has generated a RedHat bug
<https://bugzilla.redhat.com/show_bug.cgi?id=1295175> for PLplot, and
likely other distributions may become concerned with the problematic
license for this test image as well.
Accordingly with this commit I have removed all "Lena" content from
PLplot and replaced it with the test image of "Chloe", a Westie (West
Highland White Terrier). I created this test image using the method
given in examples/README.Chloe. This derived work has an explicit
free software license in accordance with the licensing of the original
image upon which the derived work is based (see Copyright for details
of that license).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian testing) by building the test_noninteractive and
test_interactive targets for the shared library case in the build
tree, and for both CMake-based and traditional (Makefile + pkg_config)
build systems for the installed examples tree. (I was careful to do
all six of these tests because the new Chloe.pgm image has only one
location while the previous "Lena" images had 3 separate locations.)
In all cases there were no regressions from previous results, and in
all cases the "Chloe" test image was generated and displayed faster
than the previous "Lena" image because of the lower resolution
(311x240) of Chloe.pgm.
M .gitattributes
M Copyright
M bindings/octave/PLplot/plimage.m
M examples/CMakeLists.txt
A examples/Chloe.pgm
A examples/README.Chloe
M examples/ada/x20a.adb
M examples/ada/xthick20a.adb
M examples/c++/x20.cc
D examples/c/lena.pgm
M examples/c/x20c.c
M examples/d/x20d.d
M examples/f95/x20f.f90
M examples/java/x20.java
D examples/lena.pgm
M examples/lua/x20.lua
M examples/ocaml/x20.ml
M examples/octave/CMakeLists.txt
D examples/octave/lena.img
M examples/octave/p17.m
M examples/octave/x20c.m
M examples/old_f95/x20f.f90
M examples/perl/x20.pl
M examples/python/xw20.py
M examples/tcl/x20.tcl
M plplot_test/CMakeLists.txt
M scripts/htdocs-gen_plot-examples.sh
M scripts/parity_bit_check.exclude
commit 6d4e5b1925df61c2527b616049c4ca114ff75946
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Feb 5 01:52:09 2016 -0800
Clarify copyright language
As discussed some time ago on list, I dropped the language that
essentially stated that everything distributed with PLplot could be
relicensed under the LGPL which is manifestly not true.
Instead, I have emphasized the vast majority of PLplot files are
licensensed for distribution under the LGPL, but there are some
known exceptions to this general rule which are also stated
in the Copyright file.
I reviewed the license notices in the files in bindings/octave and
examples/octave and modified the remarks about Octave file licensing
accordingly.
M Copyright
commit b53cb49fb04649e9ab66e2d5d4a4b51d2ba8a716
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Feb 4 15:06:39 2016 -0800
Numerical #defines in plplot.h must be done with numbers rather than C operators
The reason why C operators such as << are excluded is these #defines
are propagated to several other files such as
bindings/swig-support/plplotcapi.i (and indirectly)
bindings/f95/included_plplot_parameters.f90 and
bindings/tcl/plplot_parameters.h.
Make the check_f95_parameters and check_tcl_parameters targets depend
on the check_plplotcapi_defines target since those first two targets
generate check results from bindings/swig-support/plplotcapi.i, and
that file necessarily must be changed by hand if the
check_plplotcapi_defines target is failing.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the check_f95_parameters,
check_tcl_parameters, test_noninteractive, and test_interactive
targets. All check targets succeeded, and the test_noninteractive
and test_interactive targets showed no regressions from previous
results.
M bindings/f95/CMakeLists.txt
A bindings/f95/global_defines.sed
M bindings/f95/included_plplot_parameters.f90
M bindings/swig-support/CMakeLists.txt
M bindings/swig-support/plplotcapi.i
M bindings/tcl/CMakeLists.txt
M bindings/tcl/plplot_parameters.h
M include/plplot.h
commit 328f4788e1c2f9b358c6145da3d0e8903feb7b10
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Feb 4 13:59:23 2016 -0800
Style previous commits
M examples/java/x29.java
M src/plbuf.c
commit 1188156d2de1d31d62ab46c5c6be22252396b6bf
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Feb 3 19:14:23 2016 -0800
Solve -DPL_DOUBLE=OFF issues for Python binding and examples
The swig-generated Python binding was originally designed to work
well with both -DPL_DOUBLE=ON and OFF. This commit restores
good Python results for -DPL_DOUBLE=OFF by fixing the "assumption
that PLFLT was double" bugs that had crept in since this was last looked
at.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target. The
Python and Tcl PostScript difference summary from that result
is as follows:
python
Missing examples :
Differing graphical output : 08 09 16 19 27 28 29
Missing stdout :
Differing stdout :
tcl
Missing examples :
Differing graphical output : 08 09 16 19 27 28 29
Missing stdout :
Differing stdout :
I include the Tcl results because they are strikingly similar with the
Python results, and in fact deeper investigation shows the Python and
Tcl results are identical with each other (except for a minor rounding
difference for just one example). These much stronger differences
between either Tcl or Python results and the corresponding C results
are mostly due to lots more rounding errors. However, for
example 16, the differences with C results go a lot further than that
with whole lines in the PostScript file changed. However, for example
16 there is nothing visibly different with the gv PostScript viewer.
So I take the above results as a success for Python (and Tcl) for
the -DPL_DOUBLE=OFF case.
But I have two additional conclusions:
(1) I ascribe the near identicality between Python and Tcl results to
both interfacing a double-precision example environment with a
single-precision PLplot library with final PostScript results rounded
the same way in both cases.
(2) I ascribe the much larger differences between those results and
the corresponding C results to the latter being a single-precision
example environment interfacing with a single-precision PLplot
library. Thus, the result of that C example difference is there is
different rounding than in the Python and Tcl example cases.
M bindings/python/plplotcmodule.i
M examples/python/xw21.py
M examples/python/xw31.py
commit e88959ed321ca686f323a28ca4565f30c88e2eae
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Feb 3 14:24:37 2016 -0800
Change epochs used for Example 29 to maximize time-representation precision
Example 29 has been changed for all our supported languages to be much
more careful of adopted epoch to maximize the time-representation
precision. This is a good illustration of how to use epochs correctly
for our users, and also allows this example to give good results (as
opposed to errors) for the -DPL_DOUBLE=OFF case.
I also solved a time-related build issue for our PLplot library
for the -DPL_DOUBLE=OFF case.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target for both the
-DPL_DOUBLE=ON and OFF cases.
For -DPL_DOUBLE=ON the PostScript difference report for the only
languages that were not perfect was as follows:
ada
Missing examples :
Differing graphical output : 08 19
Missing stdout :
Differing stdout :
adathick
Missing examples :
Differing graphical output : 08 19
Missing stdout :
Differing stdout :
ocaml
Missing examples :
Differing graphical output : 08 16 19 33
Missing stdout :
Differing stdout :
i.e., there are no changes here compared to recent previous reports and
therefore no regressions in example 29 results were introduced by these
intrusive changes to that example.
For -DPL_DOUBLE=OFF the PostScript difference report was as follows:
c++
Missing examples :
Differing graphical output : 20 27 29
Missing stdout :
Differing stdout :
f95
Missing examples :
Differing graphical output : 08 16 19 20 27 29
Missing stdout :
Differing stdout :
tcl
Missing examples :
Differing graphical output : 08 09 16 19 27 28 29
Missing stdout :
Differing stdout :
(Note the languages missing from this report are all automatically
disabled for -DPL_DOUBLE=OFF except for Python which I had to manually
disable because of an overflow in one of the examples that I am still
tracking down.) The example 29 differences (according to ndiff -abserr
10) are all small (one unit in the last place) for c++, but there are
a few larger differences in the f95 and tcl results that lead to a
barely visible change to pages 5 and 6 (the 1961-08-01 UTC
discontinuity) for f95 but no visible changes for tcl. I have
commented on the remaining -DPL_DOUBLE=OFF example differences above
before, and I presume nothing has changed for any of those since
none of those examples have anything to do with the time changes
in this commit.
M README.release
M examples/ada/x29a.adb
M examples/ada/xthick29a.adb
M examples/c++/x29.cc
M examples/c/x29c.c
M examples/d/x29d.d
M examples/f95/x29f.f90
M examples/java/x29.java
M examples/lua/x29.lua
M examples/ocaml/x29.ml
M examples/octave/x29c.m
M examples/python/xw29.py
M examples/tcl/x29.tcl
M plplot_test/plplot-test.sh.in
M src/pltime.c
commit d5ea039ef62b86e0a6a08a51ab5d639801b2bf8e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jan 31 16:14:45 2016 -0800
Grammatical tweak to comment: bindings -> binding
M cmake/modules/TestFortranIsnan.cmake
commit f762e0216444fbd953664463bb2fc40bc64adc9c
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Sun Jan 31 15:31:10 2016 +0000
Save pls->difilt in plbuf_bop()
The various transformation functions can be called before plinit() which
cause pls->difilt to be set but don't cause pldi_ini() to be called. The
value of pls->difilt is used in plbop() for the auto scaling of text and
tick marks so we need to ensure that it is restored before rdbuf_bop()
calls plbop().
M src/plbuf.c
commit 855ac03376e73933055ccc761dbe9875356e9ebc
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jan 31 00:38:18 2016 -0800
Fix Tcl binding issues
A number of code cleanups and logic fixes were done with the
result that Tcl example 19 now gives good results.
A substantial number of -DPL_DOUBLE=OFF build issues were also fixed.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target for both the
-DPL_DOUBLE=ON and OFF cases. There were no regressions against the
previous lists of non-perfect PostScript comparisions for those
two cases and Tcl gave perfect results for -DPL_DOUBLE=ON.
That is the long-standing example 19 issue has been fixed.
The PostScript comparison summary for -DPL_DOUBLE=OFF
was
C example 29 is missing
tcl
Missing examples :
Differing graphical output : 08 09 16 19 27 28
Missing stdout :
Differing stdout :
For all differing graphical output other than 16 the absolute
numerical PostScript differences as determined by "ndiff -abserr 10
..." were small (1 or less). In contrast to the other examples,
example 16 had substantial differences (whole lines changed). However,
I could not see any differences using visual inspection of "gv"
results, and the above changes have eliminated all obvious "double"
issues in the C code in bindings/tcl. Therefore, I have no plans to
pursue this -DPL_DOUBLE=OFF issue further.
M bindings/tcl/tclAPI.c
commit 70a77d7c7d6a903311ad0b712b9b953a9dbc56d4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jan 31 00:23:47 2016 -0800
Disable example 29 for -DPL_DOUBLE=OFF
Currently this "time" example errors out (even in the C case) with
-DPL_DOUBLE=OFF so temporarily work around the issue by simply not
running this example for noninteractive tests. Removing the
workaround will be a few-line change if/when a proper fix emerges for
example 29 and -DPL_DOUBLE=OFF. The equivalent temporary workarounds
for interactive tests are possible, but requires substantial changes
to scripts and then substantial changes again to remove the
workarounds. Therefore we deliberately do not implement the temporary
workarounds in these interactive cases, and instead we will simply
wait for a proper fix to emerge.
M plplot_test/plplot-test.sh.in
M plplot_test/test_ada.sh.in
M plplot_test/test_cxx.sh.in
M plplot_test/test_d.sh.in
M plplot_test/test_f95.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_python.sh.in
M plplot_test/test_tcl.sh.in
commit c0246980b0cd8a5dce3b8c8c1a9ecba16305299d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 30 23:04:00 2016 -0800
Disable Ada, D, Java, OCaml, and Octave for -DPL_DOUBLE=OFF
The previous disablement of Lua for -DPL_DOUBLE=OFF and the present
change work around build-time or run-time issues with these bindings
for the -DPL_DOUBLE=OFF case which I feel are going to take some
considerable effort to sort out. For example, the SWIG-generated
bindings for Java, Lua, and Octave would require similar treatment
to the current Python binding which is designed to work for
both -DPL_DOUBLE=ON and OFF.
Grammatical change:
According to <https://en.wikipedia.org/wiki/Language_binding> the
singular form "binding" is appropriate whenever the binding referred
to is just for a single language. Therefore, I also took this
opportunity to change to the singular form in CMake comments and
strings in cmake/modules/*.cmake files whenever such change was
appropriate. This turned out to be a fairly widespread change
within cmake/modules/*.cmake.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target for both the
-DPL_DOUBLE=OFF and ON cases. There were no regressions against the
previous lists of non-perfect PostScript comparisions for those
two cases.
M cmake/modules/ada.cmake
M cmake/modules/c++.cmake
M cmake/modules/d.cmake
M cmake/modules/fortran.cmake
M cmake/modules/java.cmake
M cmake/modules/lua.cmake
M cmake/modules/ocaml.cmake
M cmake/modules/octave.cmake
M cmake/modules/python.cmake
M cmake/modules/qt.cmake
M cmake/modules/tcl-related.cmake
M cmake/modules/wxwidgets.cmake
commit 5670a32ffceb7d3e127ba6bee0d6d1d1571a0708
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 30 22:57:04 2016 -0800
Fix -DPL_DOUBLE=OFF issue: Example 33 (complete previous fix)
For the -DPL_DOUBLE=OFF case the scaling factor of 1.e-200 that was
used for plcolorbar results underflowed, and those zeroed results for
tick marks, etc., caused errors.
To avoid these underflows I changed the scaling factor from 1.e-200 to
1.e-20.
I completed the previous fix by doing the above also for the Python and
Ada "thick" examples. (sed script run was not extensive enough before).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target for the
default -DPL_DOUBLE=ON case. No example 33 discrepancies remain
other than the long-standing OCaml ones.
M examples/ada/xthick33a.adb
M examples/python/xw33.py
commit 2f1dd5c397a0e25fccaf534788ff0851b593dc11
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 30 13:31:17 2016 -0800
Fix -DPL_DOUBLE=OFF issue: replace double by PLFLT in all C and C++ examples
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target with
-DPL_DOUBLE=OFF. This test was done just for C, C++, and f95, and a
local change was made to drop example 29 (which has some
-DPL_DOUBLE=OFF issues of its own) from these tests. The resulting
test summary was
C example 29 is missing
c++
Missing examples :
Differing graphical output : 20 27
Missing stdout :
Differing stdout :
C example 29 is missing
f95
Missing examples :
Differing graphical output : 08 16 19 20 27
Missing stdout :
Differing stdout :
In all cases, "ndiff -abserr 10" found
the above PostScript differences were small (1 or less).
M examples/c++/x01.cc
M examples/c++/x04.cc
M examples/c++/x08.cc
M examples/c++/x11.cc
M examples/c++/x14.cc
M examples/c++/x17.cc
M examples/c++/x19.cc
M examples/c++/x21.cc
M examples/c++/x22.cc
M examples/c++/x26.cc
M examples/c++/x28.cc
M examples/c++/x29.cc
M examples/c++/x30.cc
M examples/c++/x31.cc
M examples/c/x05c.c
M examples/c/x08c.c
M examples/c/x09c.c
M examples/c/x11c.c
M examples/c/x14c.c
M examples/c/x15c.c
M examples/c/x16c.c
M examples/c/x17c.c
M examples/c/x19c.c
M examples/c/x22c.c
M examples/c/x28c.c
M examples/c/x29c.c
M examples/c/x30c.c
commit 59d4da41eaa67293fec4d288a56bba2f1aebcdaa
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 30 12:06:48 2016 -0800
Fix -DPL_DOUBLE=OFF issue: Example 33
For the -DPL_DOUBLE=OFF case the scaling factor of 1.e-200 that was
used for plcolorbar results underflowed, and those zeroed results for
tick marks, etc., caused errors.
To avoid these underflows I changed the scaling factor from 1.e-200 to 1.e-20.
M examples/ada/x33a.adb
M examples/c++/x33.cc
M examples/c/x33c.c
M examples/d/x33d.d
M examples/f95/x33f.f90
M examples/java/x33.java
M examples/lua/x33.lua
M examples/octave/x33c.m
M examples/old_f95/x33f.f90
M examples/tcl/x33.tcl
commit 3f9d18e2d12e7c4e74c9963a38cf37d5eb5b8336
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 30 11:42:31 2016 -0800
Fix -DPL_DOUBLE=OFF issue: Example 31
Example 31 was erroring out with test failures for at least C and C++
for -DPL_DOUBLE=OFF because floating-point constants (which default to
double for these languages) were being used in argument lists. I
solved this by replacing constants with PLFLT variables everywhere
possible. Replacing constants with variables is a much cleaner style
so I propagated that part of the change to all languages regardless
of whether they were strongly typed or not.
M examples/ada/x31a.adb
M examples/ada/xthick31a.adb
M examples/c++/x31.cc
M examples/c/x31c.c
M examples/d/x31d.d
M examples/f95/x31f.f90
M examples/java/x31.java
M examples/lua/x31.lua
M examples/ocaml/x31.ml
M examples/octave/x31c.m
M examples/python/xw31.py
M examples/tcl/x31.tcl
commit 96f31d68e7ca080de619a4408225f253f0a595cb
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jan 27 15:28:27 2016 -0800
Fortran examples: replace plflt by pl_test_flt
We continue to support plflt for those Fortran users who just want to
follow whatever floating-point precision is used in our C libraries,
but we also encourage users to use whatever floating-point precision
is convenient for them since that is now allowed by our new Fortran
binding.
We emphasize that pl_test_flt, which is widely used in our examples,
is a convenience parameter for our developers to help them test for
precision issues and should not be used by users. To make this crystal
clear, we have stated this in our release notes, in commentary in each
Fortran source file in examples/f95, and also in the new documentation
file dedicated to Fortran precision issues,
examples/f95/README_precision.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian testing) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
The PostScript diff summary continued to be clean, i.e., this
intrusive change did not introduce any regressions in that regard.
M README.release
M bindings/f95/plplot.f90
M examples/f95/CMakeLists.txt
A examples/f95/README_precision
M examples/f95/plf95demolib.f90
M examples/f95/plf95demos.inc.in
M examples/f95/test_plf95demolib.f90
M examples/f95/x00f.f90
M examples/f95/x01f.f90
M examples/f95/x02f.f90
M examples/f95/x03f.f90
M examples/f95/x04f.f90
M examples/f95/x05f.f90
M examples/f95/x06f.f90
M examples/f95/x07f.f90
M examples/f95/x08f.f90
M examples/f95/x09f.f90
M examples/f95/x10f.f90
M examples/f95/x11f.f90
M examples/f95/x12f.f90
M examples/f95/x13f.f90
M examples/f95/x14f.f90
M examples/f95/x15f.f90
M examples/f95/x16af.f90
M examples/f95/x16f.f90
M examples/f95/x17f.f90
M examples/f95/x18f.f90
M examples/f95/x19f.f90
M examples/f95/x20f.f90
M examples/f95/x21f.f90
M examples/f95/x22f.f90
M examples/f95/x23f.f90
M examples/f95/x24f.f90
M examples/f95/x25f.f90
M examples/f95/x26f.f90
M examples/f95/x27f.f90
M examples/f95/x28f.f90
M examples/f95/x29f.f90
M examples/f95/x30f.f90
M examples/f95/x31f.f90
M examples/f95/x33f.f90
commit 0f11ab8de82978baa7051a13966b5a871d65cebd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Jan 26 18:47:34 2016 -0800
Style previous commit
M bindings/ocaml/plplot_impl.c
commit dc0c26245b12124efe1fcc1990b22cfe01f3cb1a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Jan 26 18:38:09 2016 -0800
A second recent adjustment of the file list in the style script
As a result of the new Fortran binding effort there is no C code left
in bindings/f95 so the list of files to check for style
issues in scripts/style_source.sh has to be adjusted accordingly.
M scripts/style_source.sh
commit db021ff8c549301f8c3f14a6e247b3979ba320a9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 22 16:42:27 2016 -0800
libplplot: Change API of plparseopts, plsetopt, plMergeOpts, plFindName, plGetCursor, and plTranslateCursor
The return types of all these functions were changed from int to PLINT
to be consistent with the rest of our functions, and the type
of the second (argv) argument of plparseopts has been changed from
const char ** --> char **
because we recently discovered that plparsopts changes argv.
These changes were also propagated to our bindings
and examples.
N.B. these are backwards-incompatible changes as noted in
README.release.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by setting
export CFLAGS='-O3 -fvisibility=hidden -Wuninitialized'
export CXXFLAGS='-O3 -fvisibility=hidden -Wuninitialized'
export FFLAGS='-O3 -Wuninitialized -Wunused'
configuring the build with the cmake option -DBUILD_TEST=ON
and building the all, test_noninteractive and test_interactive
targets. In all cases the build had no relevant warnings
concerning any of the above functions, and the run-time tests
that were done as a result of the last two targets all proceeded
without issues.
M README.release
M bindings/c++/plstream.cc
M bindings/c++/plstream.h
M bindings/d/plplot.d
M bindings/java/PLStream.java
M bindings/java/plplotjavac.i
M bindings/lua/plplotluac.i
M bindings/ocaml/plplot_h
M bindings/ocaml/plplot_impl.c
M bindings/python/plplotcmodule.i
M bindings/qt_gui/plqt.cpp
M bindings/swig-support/plplotcapi.i
M bindings/tcl/plapi.tpl
M bindings/tcl/pltcl.c
M bindings/tcl/pltcl.h
M bindings/tcl/tclMain.c
M doc/docbook/src/api-c.xml
M doc/docbook/src/api.xml
M examples/c++/x00.cc
M examples/c++/x01.cc
M examples/c++/x01cc.cc
M examples/c++/x02.cc
M examples/c++/x03.cc
M examples/c++/x04.cc
M examples/c++/x05.cc
M examples/c++/x06.cc
M examples/c++/x07.cc
M examples/c++/x08.cc
M examples/c++/x09.cc
M examples/c++/x10.cc
M examples/c++/x11.cc
M examples/c++/x12.cc
M examples/c++/x13.cc
M examples/c++/x14.cc
M examples/c++/x15.cc
M examples/c++/x16.cc
M examples/c++/x17.cc
M examples/c++/x18.cc
M examples/c++/x19.cc
M examples/c++/x20.cc
M examples/c++/x21.cc
M examples/c++/x22.cc
M examples/c++/x23.cc
M examples/c++/x24.cc
M examples/c++/x25.cc
M examples/c++/x26.cc
M examples/c++/x27.cc
M examples/c++/x28.cc
M examples/c++/x29.cc
M examples/c++/x30.cc
M examples/c++/x31.cc
M examples/c++/x33.cc
M examples/c/ext-cairo-test.c
M examples/c/test_plbuf.c
M examples/c/test_plend.c
M examples/c/x00c.c
M examples/c/x01c.c
M examples/c/x02c.c
M examples/c/x03c.c
M examples/c/x04c.c
M examples/c/x05c.c
M examples/c/x06c.c
M examples/c/x07c.c
M examples/c/x08c.c
M examples/c/x09c.c
M examples/c/x10c.c
M examples/c/x11c.c
M examples/c/x12c.c
M examples/c/x13c.c
M examples/c/x14c.c
M examples/c/x15c.c
M examples/c/x16c.c
M examples/c/x17c.c
M examples/c/x18c.c
M examples/c/x19c.c
M examples/c/x20c.c
M examples/c/x21c.c
M examples/c/x22c.c
M examples/c/x23c.c
M examples/c/x24c.c
M examples/c/x25c.c
M examples/c/x26c.c
M examples/c/x27c.c
M examples/c/x28c.c
M examples/c/x29c.c
M examples/c/x30c.c
M examples/c/x31c.c
M examples/c/x32c.c
M examples/c/x33c.c
M examples/c/x34c.c
M include/plplot.h
M src/plargs.c
M src/plctrl.c
M src/plpage.c
M utils/plrender.c
commit d9feb10e10b777d0e4bb5c4f2010f0ae2d58df49
Author: Hazen Babcock <hbabcock@users.sourceforge.com>
Date: Mon Jan 25 21:01:51 2016 -0500
Move Qt4 vs Qt5 check for PyQt to be first so that either ENABLE_pyqt4 or ENABLE_pyqt5 is off in sub-sequent checks.
M cmake/modules/qt.cmake
commit 6afa66820e94bcc5d651f73a036839bc96e38685
Author: Hazen Babcock <hbabcock@users.sourceforge.com>
Date: Mon Jan 25 20:54:16 2016 -0500
Add programmatic determination of the PYQT_SIP_DIR, sort of as this is not really supported by sip/pyqt5. Separate some of the ENABLE_pyqt5 logic from the ENABLE_pyqt4 logic.
M bindings/qt_gui/pyqt5/CMakeLists.txt
M cmake/modules/qt.cmake
commit 5d27ac4293b105c2fd197b78a0e00c0b801948a2
Author: Hazen Babcock <hbabcock@users.sourceforge.com>
Date: Sun Jan 24 20:34:58 2016 -0500
Initial commit of working bindings to PyQt5. Remaining issues (1) Programmatically determine sip include directory (PYQT_SIP_DIR). Additional separation of the PyQt5 login from the the PyQ4 logic in cmake/modules/qt.cmake.
M bindings/qt_gui/CMakeLists.txt
A bindings/qt_gui/pyqt5/CMakeLists.txt
A bindings/qt_gui/pyqt5/plplot_pyqt5.sip
M cmake/modules/qt.cmake
M examples/python/CMakeLists.txt
A examples/python/pyqt5_example.py
M include/pldll.h.in
M include/qt.h
commit 7f7c97329a90d65b707785ed3db7206a8eac2b12
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 22 12:30:12 2016 -0800
DocBook documentation: More tweaks of the Fortran chapter
In addition, I took this opportunity to remove all trailing blanks
in our DocBook files using the command
sed -i -e 's? *$??' doc/docbook/src/*
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian testing) by using the -DBUILD_DOC=ON cmake option, building
the "print" target (which automatically validates all changes), and viewing the results,
doc/docbook/src/plplot-5.11.1.pdf.
M doc/docbook/src/CMakeLists.txt
M doc/docbook/src/ada.xml
M doc/docbook/src/advanced.xml
M doc/docbook/src/api-c.xml
M doc/docbook/src/api-compat.xml
M doc/docbook/src/api-internal.xml
M doc/docbook/src/api.xml
M doc/docbook/src/bibliography.xml
M doc/docbook/src/cplus.xml
M doc/docbook/src/deploying.xml
M doc/docbook/src/drivers.xml
M doc/docbook/src/fortran95.xml
M doc/docbook/src/gui.xml
M doc/docbook/src/intro.xml
M doc/docbook/src/libraries.xml
M doc/docbook/src/os_notes.xml
M doc/docbook/src/pdftex.map.in
M doc/docbook/src/plplotdoc-html.xsl.in
M doc/docbook/src/plplotdoc-print.dsl.in
M doc/docbook/src/plplotdoc-print.xsl.in
M doc/docbook/src/python.xml
M doc/docbook/src/tcl.xml
M doc/docbook/src/wish.xml
commit 15a6cce3ef59ba963a4ce386380bf0a295d8463f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 22 12:17:49 2016 -0800
DocBook documentation: remove ancient ChangeLog file
This Changelog file's last entry was in 2001 and is extraordinarily
incomplete even for the time epoch it does cover. For those
interested in the historical record of the initial stages of the
implementation of our DocBook-based documentation, the git log
(converted from cvs to svn to git) is a much better reference.
D doc/docbook/src/ChangeLog
commit 5d46894cf5351883028d0110b908bbeaf9dd6a94
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Fri Jan 22 08:50:19 2016 +0100
Small corrections to the Fortran chapter in the documentation.
The corrections consist mostly of adding <literal/</literal> pairs for
the words that represent a keyword or constant.
Edited by Arjen Markus (arjenmarkus@users.sourceforge.net), not tested
yet -- getting the tools to work (again) on Cygwin is a task still to be done.
M doc/docbook/src/fortran95.xml
commit 75414e4bcaabf2ad99baa0f31bf28a4869bb0fe6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 21 18:36:13 2016 -0800
Fortran binding and examples: Style code
I discovered f90ppr
<ftp://ftp.ifremer.fr/ifremer/fortran90/f90ppr.f90.gz> imposed some
ugly (to my eyes) style on the resulting Fortran code
(empty lines replaced by a line containing a single blank, and 7 space
indentation for many commands at the lowest indentation level).
Therefore, I have given up on f90ppr, and I decided to use
emacs instead for styling our Fortran source.
To do that I followed directions at
<http://web.mit.edu/Emacs/source/emacs-23.1/lisp/progmodes/f90.el>
to customize the f90-mode indentation levels. I set all the indentation-related
variables to 4 except for f90-continuation-indent which I set to 7.
I then edited all Fortran source code, and for each file I
selected the whole file, and then hit C-M-\ to style
all lines in that selected region.
For a few cases, the resulting line length was > 132 so I had
to split those lines via continuation.
Tests showed this change left some trailing blanks in lines
so I got rid of those as well with the following sed command:
sed -i -e 's? *$??' bindings/f95/* examples/f95/*
The total of all these style changes are quite intrusive, but the
resulting style looks good to me.
N.B. For me the most important styling goal is consistency rather than
details of whatever style is used (except, I must admit for some of
the f90ppr style decisions which choked me) so if someone has further
changes to suggest I am open to those.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target. The results
showed no build or run-time issues, and gave a perfect PostScript
difference report, i.e., no regressions in that result.
M bindings/f95/included_plplot_configured_types.f90.in
M bindings/f95/included_plplot_parameters.f90
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot.f90
M bindings/f95/plplot_double.f90
M bindings/f95/plplot_single.f90
M bindings/f95/plplot_small_modules.f90
M examples/f95/plf95demolib.f90
M examples/f95/test_plf95demolib.f90
M examples/f95/x01f.f90
M examples/f95/x02f.f90
M examples/f95/x03f.f90
M examples/f95/x04f.f90
M examples/f95/x05f.f90
M examples/f95/x06f.f90
M examples/f95/x07f.f90
M examples/f95/x08f.f90
M examples/f95/x09f.f90
M examples/f95/x10f.f90
M examples/f95/x11f.f90
M examples/f95/x12f.f90
M examples/f95/x13f.f90
M examples/f95/x14f.f90
M examples/f95/x15f.f90
M examples/f95/x16af.f90
M examples/f95/x16f.f90
M examples/f95/x17f.f90
M examples/f95/x18f.f90
M examples/f95/x19f.f90
M examples/f95/x20f.f90
M examples/f95/x21f.f90
M examples/f95/x22f.f90
M examples/f95/x23f.f90
M examples/f95/x24f.f90
M examples/f95/x25f.f90
M examples/f95/x26f.f90
M examples/f95/x27f.f90
M examples/f95/x28f.f90
M examples/f95/x29f.f90
M examples/f95/x30f.f90
M examples/f95/x31f.f90
M examples/f95/x33f.f90
commit 282983e825f9a7814a06001844e294447e928373
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jan 20 23:53:51 2016 -0800
Fortran binding: Final planned improvement for the Fortran version of plGetCursor
The improvement is to use an appropriate public derived type for the argument
of the Fortran plGetCursor function and an appropriate private derived type
for the argument of the interface_plGetCursor function (which is the
Fortran interface to the C version of plGetCursor), and when copying
back results from the private to public derived type do all appropriate
conversions.
The public derived type is called PLGraphicsIn. It has no bind(c)
attribute, and all the types for its components are the normal public types, i.e.,
* integer,
* string(len=16) :: string (which is a normal blank suffixed Fortran character
string), and
* real(kind=private_double).
(I had to make a choice between private_double and private_single,
and I chose the former for best precision.)
The private derived type is called private_PLGraphicsIn. It has the
bind(c) attribute and all the types of its components are interoerable
ones, i.e.,
* integer(kind=private_plint),
* character(len=1), dimension(16) :: string, (where string is a
NULL-terminated C string), and
* real(kind=private_plflt)
These characteristics make private_PLGraphicsIn exactly equivalent
to the C struct called PLGraphicsIn which is why this type
of argument is correct for interface_plGetCursor.
I have also updated the DocBook Fortran chapter to reflect this new
definition of the Fortran version of PLGraphicsIn and to document the
constraint that its floating-point arguments are double precision.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian testing) by building a locally modified version of Fortran
example 01 that puts it in locate mode and verifying there was no
regression in the interactive results from that mode with both -dev
xwin and -dev xcairo. In the latter case, the results were actually
an improvement because of the proper transformation from the
NULL-terminated C string component result for private_PLGraphicsIn to
the Fortran character(len=16) component result for PLGraphicsIn with
correct trailing blanks rather than the trailing garbage we had before.
M bindings/f95/plplot.f90
M bindings/f95/plplot_small_modules.f90
M doc/docbook/src/fortran95.xml
commit dcf7b3f47c7487479a545984e999a1d9c1310451
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jan 20 18:35:03 2016 -0800
Fortran binding: change plGetCursor into a function
This commit follows two patches sent to me by Arjen whose net effect
is to change plGetCursor from just an interface block describing the C
version of plGetCursor to a full-blown Fortran module procedure that
calls that interfaced C routine. However, this commit goes one step
further and changes that module procedure from a subroutine to a
function and similarly for the interface block since the underlying C
version of plGetCursor is a function that returns a non-zero value on
success and a 0 value on failure.
The use of Fortran module procedure means that Fortran examples 1 and
20 (as confirmed by nm) now no longer have an undefined symbol
plGetCursor that can only be supplied by libplplot. Instead the
symbol is __plplot_graphics_MOD_plgetcursor_impl which is supplied by
libplplotf95. As a result, examples 1 and 20 no longer have special
linking needs and can be linked just like the rest of the examples
just to libplplotf95 without it being necessary to explicitly link
libplot. I have made appropriate changes to the CMake-based and
traditional build systems to be consistent with that linking model.
Changing Fortran plGetCursor from a subroutine to a function allows
Fortran example 01 to work correctly when put in locate mode since
that correct working requires the detection of whenever the
return from C plGetCursor and therefore Fortran plGetCursor is equal
to 0 to exit a locate-mode loop.
To Do. We still need to define private and public versions of the
PLGraphicsIn type argument of plGetCursor. The private version would
have real(kind=private_plflt) floating-point components and a
NULL-terminated C string component, while the public version would
have real(kind=private_double) (and real(kind=private_single) if there
are no disambiguation issues) floating-point components and a Fortran
character array of the correct length that is right-filled with
blanks. Then the module procedure would call the interfaced routine
to fill the private version of PLGraphicsIn, then fill a public
version of PLGraphicsIn with the appropriately converted values before
returning that to the calling Fortran procedure.
Tested by: Alan W. Irwin <airwin@users.sourcforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
The summary of differences report is as follows:
f95
Missing examples :
Differing graphical output :
Missing stdout :
Differing stdout :
That is, this commit has introduced no regressions in these perfect
test results.
Another test was I ran Fortran example 01 in locate mode (by locally
changing locate_mode from .false. to .true.). The results were
identical to the corresponding -locate mode C version of the example
for the very first time. That is, clicking with any mouse button or
hitting any key outside a subwindow or hitting the escape key anywhere
on the plot permanently exits the locate-mode loop.
A final test was I ran Fortran example 20 with -dev xwin (the
only device that currently gives interactive results for
this example), and I got the same interactive results as
the C example; the left button allowed me to select an
area of the image with drag and drop and the right button
allowed me to escape that selection loop.
M bindings/f95/CMakeLists.txt
M bindings/f95/plplot_small_modules.f90
M examples/f95/CMakeLists.txt
M examples/f95/x01f.f90
M examples/f95/x20f.f90
commit e50b01189ec1ebaf9eb0640bd32b770fb7144843
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jan 20 03:36:31 2016 -0800
DocBook Documentation: second rewrite of the Fortran chapter.
M bindings/f95/included_plplot_real_interfaces.f90
M doc/docbook/src/fortran95.xml
commit 04384eeb41c4706193fb5e7489b70037a5f27595
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Sun Jan 17 15:30:02 2016 +0100
Fortran DocBook documentation; rewrite the Fortran chapter
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by using the -DBUILD_DOC=ON cmake option and by
building the "print" target. The Fortran chapter in the
resulting doc/docbook/src/plplot-5.11.1.pdf document had no
obvious rendering issues.
M doc/docbook/src/fortran95.xml
commit 498019cf47ca7f02013c027223775f6fb4ddc3c0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jan 17 18:33:07 2016 -0800
New Fortran binding: plmaptex implementation
This completes the API necessary for example 19, and, as far as I
know, this is the last API that we need to implement for this new
binding. Furthermore, the test results below are perfect. Therefore
after this commit, I plan to land this private topic branch (jointly
implemented by Arjen and me) onto our master branch.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
The summary of differences report was as follows:
f95
Missing examples :
Differing graphical output :
Missing stdout :
Differing stdout :
That is, that comprehensive PostScript test was perfect. Finally,
valgrind examples/f95/x19f -dev svg -fam -o testf.svg
gave a perfect valgrind report (0 errors, no leaks are possible) and
gave SVG results identical to the results from the corresponding C
example.
M README.release
M bindings/f95/plplot.f90
M examples/f95/Makefile.examples.in
M examples/f95/x19f.f90
M plplot_test/test_f95.sh.in
commit cf253b6c65c72cd5f0054c2b07650b65699f4392
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jan 17 16:08:51 2016 -0800
New Fortran binding: plmapstring implementation
N.B. plmapstring is implemented with separate specifically named
functions for the single and double case for the same reasons as
mentioned in the last commits for plmapfill, plmapline, plmap, and
plmeridians.
This commit reduces the missing API in the new Fortran binding to
just one function, plmaptex.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the x19f95 target.
N.B. this is only a build test and the actual functionality of
plmapstring at run time was not tested because no example currently
uses plmapstring.
M bindings/f95/plplot.f90
commit 0f3b06e3ed0ea531d55e7e790a8f685dbcd6a330
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jan 17 13:03:43 2016 -0800
New Fortran binding: plmapfill and plmapline implementation
N.B. plmapfill and plmapline are implemented with separate
specifically named functions for the single and double case for the
same reasons as mentioned in the last commits for plmap and
plmeridians.
This commit reduces the Fortran missing API to just plmapstring
(currently untested by any example) and plmaptex (normally tested by example
19)
This addition to the Fortran API now allows running the first 4 pages
of the 19th Fortran example, and the reinstated fifth page as well
(except for the plmaptex calls which have been commented out for that
page for this test).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the x19f95 target and running it with
valgrind examples/f95/x19f -dev svg -fam -o testf.svg
The valgrind report was perfect (0 errors, no leaks are possible), the
first four pages of results were identical to the results from the
corresponding C example, and the fifth page was identical to the
corresponding C result except for the missing text from the commented
out plmaptex calls. I also temporarily changed plflt to kind(1.) and
ran the same tests with the same good results except for a few
expected minor differences at the +/- 0.03 level between the
single-precision Fortran example results and double-precision example
C results.
M bindings/f95/plplot.f90
M examples/f95/x19f.f90
commit e9ce2d2d9b5eb354ff508b17edff399d30cb38ac
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 16 19:48:58 2016 -0800
New Fortran binding: plmeridians implementation
N.B. Fortran plmeridians is implemented with separate specifically named
functions for the single and double case for the same reasons
as mentioned in the last commit for plmap.
This addition to the Fortran API now allows running the first 4 pages
of the 19th Fortran example, but the last shapelib-related page
(currently temporarily removed from the Fortran example source code so
the first 4 pages can be tested) requires several more plmap* Fortran
functions to be implemented before it can be tested.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the x19f95 target and running it with
valgrind examples/f95/x19f -dev svg -fam -o testf.svg
The valgrind report was perfect (0 errors, no leaks are possible), and
the first four pages of results were identical to the results from the
corresponding C example. I also temporarily
changed plflt to kind(1.) and ran the same tests with the same good
results except for a few minor differences at the +/- 0.03 level
between the single-precision Fortran example results and
double-precision example C results.
M bindings/f95/plplot.f90
M examples/f95/x19f.f90
commit f564e8cafe9e09a35c1849c981484786fc7950d4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 16 17:02:49 2016 -0800
New Fortran binding: implementation of plmap API
N.B. this effort is implemented with separate specifically named
functions for the single and double case that are not located in
included_plplot_real.f90. As far as I can tell (and I tried pretty
hard) there is no generic wp-precision way to implement this
functionality in included_plplot_real.f90 because the C-bound callback
that is called directly from C (and which wraps the corresponding
Fortran callback with wp arguments) only has private_plflt arguments
so cannot be disambiguated.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the x19f95 target and running it with
valgrind examples/f95/x19f -dev svg -fam -o testf.svg
The valgrind report was perfect (0 errors, no leaks are possible), and
the first two pages of results were identical to the results from the
corresponding C example. (pages 3 and 4 looked fine, but they did not
include plmeridians results [not implemented yet] so were different
from the C results, and page 5 from the Fortran example is currently
missing). I also temporarily changed plflt to kind(1.) and ran
the same tests with the same good results.
M bindings/f95/plplot.f90
M bindings/f95/plplot_double.f90
M bindings/f95/plplot_single.f90
M examples/f95/CMakeLists.txt
M examples/f95/x19f.f90
commit b73b57e3728bf039c8764ac95a710180ff5146a2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 15 22:39:25 2016 -0800
New Fortran binding: intrusive Fortran style changes
In plplot.f90 that defines the plplot module I added many formal
interface blocks before the contains that refer to module procedures
named typically with a trailing _impl that are defined after the
"contains". This change was done to match the Fortran style of
included_plplot_real_interfaces.f90 that is used both for the
plplot_single and plplot_double modules.
For both included_plplot_real_interfaces.f90 and plplot.f90 I
alphabetized both the interface blocks and the routines after
the "contains" to make procedures much easier to find.
These changes were obviously quite intrusive.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the plplot_diff_psc target. There were
no regressions from the previous (good except for example 19) results.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot.f90
commit 82cb22dbb15c2715ada8359f74d1bcfcc650dc30
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 15 16:15:26 2016 -0800
New Fortran binding: split Fortran source code
This splitting is useful because it allows multiprocessors to compile
the code quicker than before, and also compilers generally have less
to do if a change is made to just one of these files (which happens in
typical development so this should be a modest help to developers).
These source files are now called the following:
plplot.f90. Contains the plplot module which depends on the rest and
which also contains all the PLplot Fortran API that is independent
of the user's chosen real precision.
plplot_single.f90. Contains the plplot_single module which is required
for those cases when users choose single precision arguments to
the PLplot Fortran API.
plplot_double.f90. Contains the plplot_double module which is required
for those cases when users choose double precision arguments to
the PLplot Fortran API.
plplot_small_modules.f90. Contains several small modules. The
plplot, plplot_single, and plplot_double modules all use these modules.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the plplot_diff_psc target. There were
no regressions from the previous (good except for example 19) results.
M bindings/f95/CMakeLists.txt
A bindings/f95/plplot.f90
D bindings/f95/plplot_bindings.f90
A bindings/f95/plplot_double.f90
A bindings/f95/plplot_single.f90
A bindings/f95/plplot_small_modules.f90
commit d4adf9e860fa15c39b583f2bc8dadb85228b502a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 15 14:19:20 2016 -0800
New Fortran binding: C routines that return values are interfaced to Fortran functions
Strict application of this rule means that plparseopts and plsetopt
have now both been changed from Fortran subroutines into Fortran
functions with plGetCursor soon to follow.
This is a (now) documented backwards-incompatibility with the new
Fortran binding. It is documented first because plparseopts is
so ubiquitous and demands users change all use of
call plparseopts(...)
to
integer :: plplarseopts_rc
plparseopts_rc = plparseopts(...)
In addition I dropped the plrandd_single function in the interest of
complying with the KISS principle of always using double precision
entities where there is no automatic way (i.e., via the precision of
arguments supplied by the user) to select the single-precision entity.
M README.release
M bindings/f95/plplot_bindings.f90
M examples/f95/x00f.f90
M examples/f95/x01f.f90
M examples/f95/x02f.f90
M examples/f95/x03f.f90
M examples/f95/x04f.f90
M examples/f95/x05f.f90
M examples/f95/x06f.f90
M examples/f95/x07f.f90
M examples/f95/x08f.f90
M examples/f95/x09f.f90
M examples/f95/x10f.f90
M examples/f95/x11f.f90
M examples/f95/x12f.f90
M examples/f95/x13f.f90
M examples/f95/x14f.f90
M examples/f95/x15f.f90
M examples/f95/x16af.f90
M examples/f95/x16f.f90
M examples/f95/x17f.f90
M examples/f95/x18f.f90
M examples/f95/x19f.f90
M examples/f95/x20f.f90
M examples/f95/x21f.f90
M examples/f95/x22f.f90
M examples/f95/x23f.f90
M examples/f95/x24f.f90
M examples/f95/x25f.f90
M examples/f95/x26f.f90
M examples/f95/x27f.f90
M examples/f95/x28f.f90
M examples/f95/x29f.f90
M examples/f95/x30f.f90
M examples/f95/x31f.f90
M examples/f95/x33f.f90
commit 9dfcae7caf8cb97a61ad52b90be63255f2e081dc
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 15 00:11:45 2016 -0800
New Fortran binding: interface plparseopts in Fortran
Because the interfacing of plparseopts in the plplot module requires
access to subroutine character_array_two_c (the same routine used to
interface Fortran character string array arguments for pllegend,
plcolorbar, and plstripc in the plplot_double and plplot_single
modules), then must move character_array_two_c to its own module
called plplot_private_utilities which is then use'd from the
plplot_single, plplot_double and plplot modules.
Because the interfacing of plparseopts can now be completely done in
Fortran, the libplplotf95c functionality is no longer used.
Therefore, remove that library source code and all references to that
library in the build system. It was a useful library while it lasted,
but I am glad to see it gone completely since it makes our Fortran
binding simpler to understand.
There was some concern that the c_plparseopts routine changes both
argc and the contents of the argv array, but I have been careful to
specify both those arguments as intent(inout) in the interface
and the results are good (see tests below).
I temporarily worked around a linking bug in the traditional build
by making libplplot a public library for builds using libplplotf95.
But a proper solution of this issue will occur when plGetCursor
is implemeneted with a module procedure (which means fortran
examples will no longer have to directly link to libplplot).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
The summary of differences report was as follows:
f95
Missing examples : 19
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., we continue to get the same results with no regressions due to
recent changes.
Because there was some concern about the intent(inout) attributed for some of
the plparseopts arguments, I did the following valgrind tests:
valgrind examples/f95/x00f -dev svg -o testf.svg
and
valgrind examples/f95/x00f
where instead of using command-line arguments in this case, I answered
the questions that were emitted by the C library instead about device
and file with "svg" and "testf.svg". In all cases, perfect (0 errors,
no leaks are possible) valgrind results were achieved and the SVG file
results were identical to the corresponding C SVG file results.
N.B. although this seems pretty good proof that this completely new
Fortran-only method to interface Fortran plparseopts with C
c_plparseopts is working correctly, this new method needs testing on
additional Fortran compilers (especially since Arjen found
compiler-dependent issues with the old C method of interfacing
plparseopts that he had to fix).
M bindings/f95/CMakeLists.txt
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
D bindings/f95/plplotf95c.c
commit ba13c7fa94d0094ab98e28f719907bfcf9c94c4b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 14 21:45:49 2016 -0800
New Fortran binding: transform Fortran character string arrays using Fortran language
Use iso_c_binding module capabilities to implement the
character_array_to_c subroutine that transforms a Fortran character
string array into a C array of pointers to C strings.
Use this routine to process the Fortran character string array
arguments of the Fortran pllegend, plcolorbar, and plstripc
subroutines to allow interfacing directly with the C routines
c_plegend, c_plcolorbar, and c_plstripc. This means we have been able
to drop the now unused "fc_" versions of these routines from
plplotf95c.c and the corresponding plplotf95c library. Thus, the only
interfacing left that is done with an "fc_" C routine is
fc_plparseopts, but I have further plans to do its interfacing in
Fortran as well, and if I can make that work, that means we can
eliminate the plplotf95c library altogether.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net" on Linux
(Debian testing) by building the test_diff_psc target which gave the
following (expected since example 19 still not implemented) summary
result.:
f95
Missing examples : 19
Differing graphical output :
Missing stdout :
Differing stdout :
For the svg device I did valgrind tests for examples 4 and 26
(which exercise pllegend), 16 (which exercises plcolorbar), 17 (which
exercises plstripc), and 33 (which exercises pllegend and plcolorbar).
In all cases perfect (0 errors, no leaks are possible) valgrind
results were obtained, and the svg results derived this way were
identical to the results from the corresponding C examples.
I did a valgrind test of example 17 with the xwin device. In that
case the interactive visual results looked like the corresponding
results from the C example for this test, and there were 0 errors
reported by valgrind in its summary line. Although valgrind did find
memory leaks in this case, the LEAK SUMMARY report was identical to
the corresponding report in the C example so these leaks can be
ascribed to the xwin device or X library and have nothing to do with
the new Fortran binding.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
M bindings/f95/plplotf95c.c
commit 5e89d995b8e911d339059c0bf4e580a7931f8265
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Thu Jan 14 21:46:46 2016 +0100
Add .def file for Intel Fortran on Windows and fix plparseopts
DLLs on Windows require that the symbols that are to be exported are specified
explicitly. This can be done in at least two ways. Here we use the "definition
file" approach.
Using the Intel Fortran and MS Visual C++ compilers revealed a bug in the
wrapper for plparseopts. If no argument was given, it could free an uninitialised
pointer. This has been corrected.
Tested by Arjen Markus (arjenmarkus@users.sourceforge.net) on "bare" Windows and on Cygwin.
M bindings/f95/plplot_bindings.f90
A bindings/f95/plplotf95_ifort.def
M bindings/f95/plplotf95c.c
commit e0af834e42a6a1e51954b23051aaa2693466696c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 14 00:11:49 2016 -0800
New Fortran binding: reorganize the plplot_precision module
Rename both template configured precision file and the configured result
from the confusing combination
included_plplot_private_types.f90.in ==> included_plplot_interface_private_types.f90
to
included_plplot_configured_types.f90(.in) and only include the one
configured type that we use in that file. The result is all
non-configured types are put directly into the plplot_precision module
rather than included which makes it much easier to interpret that
module at a single glance.
I took this opportunity to use default integer types (and a
private_double type for PL_PI, PL_TWOPI, and PL_NOTSET) in
included_plplot_parameters.f90 so that users are not exposed (except
for the 3 private_double cases) to private PLplot types from this
file.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) as stated in the previous commit, i.e., the
changes for both commits were tested at the same time.
M bindings/f95/CMakeLists.txt
A bindings/f95/included_plplot_configured_types.f90.in
M bindings/f95/included_plplot_parameters.f90
D bindings/f95/included_plplot_private_types.f90.in
M bindings/f95/plplot_bindings.f90
commit c3ec805ffccbd2a66a63786ed2b2aa6b6011f9e8
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jan 13 22:18:35 2016 -0800
New Fortran binding: Make single-precision examples work with double-precision C library
This test was made by temporarily defining plflt to correspond to
kind(1.0) while the C library continued to be double-precision.
One change that was needed was to use plflt real precision as
consistently as possible to avoid the situation where an individual PLplot
routine was called with mixed precision arguments. The typical issue that was
addressed was replacing all dble(...) by real(..., kind=plflt), using
plflt precision variants of the values of the PL_PI, PL_TWOPI, and
PL_NOTSET parameters (which are always double), and replacing all
explicit precision constants (e.g., 1.d0) by the plflt variant.
Another single-precision issue that was addressed was to change the
scaling factor in example 33 from 1.e-200 (which underflows at single
precision) to the maximum of 1.e-200 and an underflow-proof value for
the particular plflt precison being used. (This is just a workaround,
and eventually that scaling factor should be changed to 1.e-20 for all
language examples to be safe for all real precisions).
A final single-precision issue was that example 29 just cannot work at
single precision because of time representation issues at that
precision. The solution that I took for this case was to adopt fixed
double precision for example 29, but a more comprehensive approach is
needed in general (e.g., drop example 29 for all languages if the core
library is single precision).
I took this opportunity to update copyright years for Alan W. Irwin
and to use a more modern Fortran idiom in the examples such as
changing all subroutines and functions that are defined in these
examples to CONTAINed procedures and replacing generic unnamed end
statements for programs, subroutines and functions with explicitly
named end statements.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie). I took advantage of the uniform
nature of the plflt precision of the examples by temporarily adjusting
that to kind(1.) while the C library continued to be double precision.
(So this is the first real test of the new Fortran binding where example
precision is single and C library is double.) The issues addressed
above were mostly discovered with this special test, but after they
were fixed the examples built and ran without issues and produced
the following difference report compared to the double-precision
C example results:
f95
Missing examples : 19
Differing graphical output : 04 06 08 09 15 16 18 20 21 22 26 27 28 33
Missing stdout :
Differing stdout :
I did not look at detailed PostScript diff results, but their
existence is expected since our examples are notorious for being
sensitive to precision issues. I did eyeball those Fortran single-precision
example/double-precision C library PostScript plots, and they all looked
fine with no obvious visual anomalies.
I then following up by restoring plflt to its expected value of
kind=(1.d0) for this double-precision version of the C library (so both
example and library have the same (double) precision) and
built (starting from an empty build tree) the test_diff_psc
target with no build or run-time issues, and with the following
PostScript difference report:
f95
Missing examples : 19
Differing graphical output :
Missing stdout :
Differing stdout :
This is (as expected) the same as when I last ran this standard
version of the test, i.e., the large number of example changes did not
compromise this good result, but as before there is still work to do
on the API associated with example 19.
M examples/f95/x00f.f90
M examples/f95/x01f.f90
M examples/f95/x02f.f90
M examples/f95/x03f.f90
M examples/f95/x04f.f90
M examples/f95/x05f.f90
M examples/f95/x06f.f90
M examples/f95/x07f.f90
M examples/f95/x08f.f90
M examples/f95/x09f.f90
M examples/f95/x10f.f90
M examples/f95/x11f.f90
M examples/f95/x12f.f90
M examples/f95/x13f.f90
M examples/f95/x14f.f90
M examples/f95/x15f.f90
M examples/f95/x16af.f90
M examples/f95/x16f.f90
M examples/f95/x17f.f90
M examples/f95/x18f.f90
M examples/f95/x19f.f90
M examples/f95/x20f.f90
M examples/f95/x21f.f90
M examples/f95/x22f.f90
M examples/f95/x23f.f90
M examples/f95/x24f.f90
M examples/f95/x25f.f90
M examples/f95/x26f.f90
M examples/f95/x27f.f90
M examples/f95/x28f.f90
M examples/f95/x29f.f90
M examples/f95/x30f.f90
M examples/f95/x31f.f90
M examples/f95/x33f.f90
commit ec59ed7e030b9f622d4b6a99f3019af6d199130f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jan 13 03:17:25 2016 -0800
New Fortran binding: replace "includes" by "imports" inside interface blocks
This change produced a slight decrease in compile times, and it
appears to me to be a definite improvement in Fortran style
to get rid of these large numbers of include statements.
As a result of this change, there was no more need for the configured
included_plplot_private_types.f90 file (the file that was included so
many times previously) so I stopped configuring that file for the
build.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target in an initially
empty build tree for the shared library case. There were no build or
run-time errors, and the PostScript diff report for Fortran was as
follows:
f95
Missing examples : 19
Differing graphical output :
Missing stdout :
Differing stdout :
That is, there was no change from previous.
M bindings/f95/CMakeLists.txt
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
commit 6f4bb73b4141d96da6724f7376282a5290fe4bac
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jan 13 01:57:42 2016 -0800
New Fortran binding: replace "use" statements within interface blocks by the relevant import statements
Contrary to expectations this change increased build times for the x16f95
target from 3.2 seconds to 3.5 seconds. But that may be because the
gfortran compiler has been optimised for speed to deal with use
statements but not for import statements, and other compilers
may build more quickly. In any case I like this style much
better so I will stick with it.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
commit 74d178c6dfe8632e216f4573026360690b9832ef
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jan 13 01:55:22 2016 -0800
New Fortran binding: adjust the style script for new file locations
In particular the *.c code in bindings/old_f95 and a specific
C header file in that directory.
M scripts/style_source.sh
commit bc6d0be1e8b968ea693dbeb735184a537957e66a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jan 13 01:18:56 2016 -0800
New Fortran binding: get rid of trailing whitespace in Fortran examples
M examples/f95/x04f.f90
M examples/f95/x14f.f90
M examples/f95/x20f.f90
M examples/f95/x23f.f90
M examples/f95/x24f.f90
M examples/f95/x27f.f90
M examples/f95/x29f.f90
M examples/f95/x30f.f90
M examples/f95/x31f.f90
M examples/f95/x33f.f90
commit f417509843bea8e9533c4eafb55fda5d222065c5
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jan 13 00:05:50 2016 -0800
New Fortran binding: add test of locate mode for example 01
This test only works if the source code is locally modified to set
locate_mode to ".true.". The call to plGetCursor will have to be changed
to a function reference to help break out of the infinite loop waiting
for events once that subroutine ==> function issue is fixed in the new
Fortran binding. See FIXME in the updated source code.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the x01f95 target (with locally
modified source code to set locate_mode to .true.) and running both
examples/f95/x01f -dev xwin
and
examples/f95/x01f -dev xcairo
Both gave the expected printed out results you also get for the corresponding C
example (in -locate mode). However, they both have some issues
with escaping the event loop by one of the two usual methods
which is (1) to hit the escape key or (2) to click on an area
of the plot that is outside the 4 subwindows.
The xwin version was put into an infinite event loop because escape
method (1) is internally transformed to method (2) for this device and
method (2) only works if the above FIXME is fixed. The xcairo version
implements escape methods (1) and (2) independently. (2) does not
work for the FIXME reason given, but (1) does work for this device.
M examples/f95/x01f.f90
commit da0334d9591dcfce12e968ba3b910480f2494d4f
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Tue Jan 12 09:22:46 2016 +0100
Refine the Fortran equivalent of the PLGraphicsIn data structure
To make the derived type PLGrahicsIn directly useable from C, I added
the bind(c) attribute and changed all kinds to C compatible ones (using
the PLplot kind parameters).
This way the structure can be filled directly by the C routine and there
is no need for an intermediate Fortran routine. Since the structure does
not hold huge amounts of data from a user program, unlike the arrays
passed for contouring for instance, it is not necessary to have a single
and a double precision version. In fact, that would complicate matters,
as the user would have to select either one without getting any benefits.
Tested by: Arjen Markus M <arjenmarkus@users.sourceforge.net> on Cygwin
by running example x20f and printing several fields of the structure.
Tested by: Alan W. Irwin <irwin@users.sourceforge.net> on Linux
(Debian jessie) by building the x20f95 target and running it
using the xwin device. The resulting interactive selection
of a portion of Lena's image to plot worked well, just like
running the C version of that example with the xwin device.
M bindings/f95/plplot_bindings.f90
M examples/f95/CMakeLists.txt
commit 6c03e13ecdba1f79410b5c3764b71d5065393673
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Jan 11 03:19:21 2016 -0800
New Fortran binding: Add logical rectangular argument to plshade and plshades API
This backwards-incompatible change gives the same flexibility to
Fortran users in this regard as C users presently enjoy.
As part of this change we have chosen the correct rectangular argument
in the Fortran examples following what is done in the C examples,
and the result fixes the previous differences between example 16
Fortan and C results and the missing fills for Fortran example 16a
(for which there is no C counterpart). My thanks to Arjen for
figuring out that it was an incorrect rectangular argument that
was the source of all these issues.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
The summary of differences report was as follows:
f95
Missing examples : 19
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., the previous differences for example 16 have now been removed
by this fix. I also ran (for the -DPL_DEPRECATED_f95 not mentioned
case, i.e., the new bindings)
valgrind examples/f95/x16af -dev svg -fam -o testf.svg
and
valgrind examples/f95/x16f -dev svg -fam -o testf.svg
which both gave perfect (0 errors, no leaks are possible) valgrind
reports. For the latter case, the svg results were identical
to the corresponding svg results from the C example. I also verified
that the PostScript results for example 16a were identical to the
those same results for the -DPL_DEPRECATED_f95=ON case.
M README.release
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
M examples/f95/x15f.f90
M examples/f95/x16af.f90
M examples/f95/x16f.f90
M examples/f95/x19f.f90
M examples/f95/x21f.f90
commit e8b1e4e64a5a242ac05bb85e11f7e4babf155a75
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Jan 11 01:28:59 2016 -0800
Implement the -DPL_DEPRECATED_f95=ON option
I had previously copied a snapshot of bindings/f95 taken at the start
of the new Fortran binding development to bindings/old_f95, and this
commit similarly copies a snapshot of examples/f95 taken at the start
of the new Fortran binding to examples/old_f95. In addition, some
modest build-system changes have been made to implement the
-DPL_DEPRECATED_f95=ON option to consistently use this old binding
with the old examples to act as an emergency backup in case the new
Fortran binding does not work for a user and also to extend the life
of the old version of the Fortran binding to be used for old
programmes that are no longer being developed in the slightest.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running both
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON -DPL_DEPRECATED_f95=ON" --do_test_interactive no
and
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
with the expected results in both cases
-DPL_DEPRECATED_f95=ON:
f95
Missing examples : 19
Differing graphical output :
Missing stdout :
Differing stdout :
-DPL_DEPRECATED_f95 not mentioned (which is equivalent to
-DPL_DEPRECATED_f95=OFF, i.e., the new Fortran examples and new
Fortran binding):
f95
Missing examples : 19
Differing graphical output : 16
Missing stdout :
Differing stdout :
Example 19 is missing from both comparisons because that example does
not yet work in the latter case and I could not be bothered to
configure different lists of examples for -DPL_DEPRECATED_f95=ON and
-DPL_DEPRECATED_f95=OFF. For the new bindings and examples Fortran
example 16 has different graphical results than the corresponding C
example because I have implemented the fix for the rectangular issue
that Arjen discovered, but I have stashed that work for this
comparison so that stashed result could be committed and tested
separately after the present commit.
M bindings/CMakeLists.txt
M bindings/f95/CMakeLists.txt
M bindings/old_f95/CMakeLists.txt
M cmake/modules/fortran.cmake
M examples/CMakeLists.txt
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
A examples/old_f95/CMakeLists.txt
A examples/old_f95/Makefile.examples.in
A examples/old_f95/plf95demolib.f90
A examples/old_f95/plf95demos.inc.in
A examples/old_f95/test_plf95demolib.f90
A examples/old_f95/x00f.f90
A examples/old_f95/x01f.f90
A examples/old_f95/x02f.f90
A examples/old_f95/x03f.f90
A examples/old_f95/x04f.f90
A examples/old_f95/x05f.f90
A examples/old_f95/x06f.f90
A examples/old_f95/x07f.f90
A examples/old_f95/x08f.f90
A examples/old_f95/x09f.f90
A examples/old_f95/x10f.f90
A examples/old_f95/x11f.f90
A examples/old_f95/x12f.f90
A examples/old_f95/x13f.f90
A examples/old_f95/x14f.f90
A examples/old_f95/x15f.f90
A examples/old_f95/x16af.f90
A examples/old_f95/x16f.f90
A examples/old_f95/x17f.f90
A examples/old_f95/x18f.f90
A examples/old_f95/x19f.f90
A examples/old_f95/x20f.f90
A examples/old_f95/x21f.f90
A examples/old_f95/x22f.f90
A examples/old_f95/x23f.f90
A examples/old_f95/x24f.f90
A examples/old_f95/x25f.f90
A examples/old_f95/x26f.f90
A examples/old_f95/x27f.f90
A examples/old_f95/x28f.f90
A examples/old_f95/x29f.f90
A examples/old_f95/x30f.f90
A examples/old_f95/x31f.f90
A examples/old_f95/x33f.f90
M plplot_test/CMakeLists.txt
M plplot_test/plplot-test.sh.in
M plplot_test/test_f95.sh.in
commit 951776940335562cc3e39a0916a2bc9de217f7df
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 7 23:47:50 2016 -0800
New Fortran binding: add plslabelfunc API with full callback
This was much trickier than I had expected because of all the string
manipulations that had to occur.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the library and an uncommitted version of
example 19 with all the currently unimplemented API dropped.
The build was clean and
valgrind examples/f95/x19f -dev svg -fam -o testf.svg
gave a perfect result and also good-looking custom labels.
M bindings/f95/plplot_bindings.f90
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
M plplot_test/test_f95.sh.in
commit 14579b4ecff926be5f21d43543ba3a7fecc89094
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Jan 7 23:33:18 2016 -0800
New Fortran binding: Tweak example 22 commentary to make it clear need exact types for callbacks
M examples/f95/x22f.f90
commit 0a1ab9742531ed48325092f236b8ba40d650fa01
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jan 6 23:15:49 2016 -0800
New Fortran binding: Add full data argument capability to plstransform and corresponding callback
I used the method given in "V: Using type(c_ptr) Pointer" of
<http://www.fortran90.org/src/best-practices.html> to allow the user
to pass an arbitrary user-defined definition as an argument of a
callback. This additional signature for plstransform that allows this
is distinguished by an additional data argument and a Fortran callback
that has an additional data argument as well. Furthermore, we have
done all the plumbing in plplot_bindings.f90 such that this callback
is interfaced properly with c_plstransform.
This method has been used in example 22 to pass what before was a
value stored in a common block as the data argument of the newly
defined transform_data Fortran callback that is used by plstransfrom
with a properly defined data argument in the example.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the svg and x22f95 targets and running
valgrind examples/f95/x22f -dev svg -fam -o testf.svg
with a perfect valgrind report and svg results that were identical
to the corresponding C results.
M bindings/f95/plplot_bindings.f90
M examples/f95/x22f.f90
commit 388e8d493063bc1528cc39439b28ca11900bd522
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Jan 6 15:52:49 2016 -0800
New Fortran binding: fix Linux build issues with previous commit
Those build issues were the following:
* pltr0f does not exist at the C level and must be replaced with
pltr0. Furthermore the interface for it needs a different data type
for the unused (NULL) data argument, and a consistent name (now pltr0)
must be used for both the subroutine and end subroutine statements.
* The first argument to the call to interface_plfcont is changed
to plf2evalr while the transform argument is changed to pltr0.
* module procedure plstransform_double must be modified
to drop the data argument and plstransform_single must
be removed (otherwise, if it were changed the same
way there would a disambiguation issue).
N.B. the first two changes above do allow contour_0 to build, but
example 9 changes are still required to actually test this variant of
plcont at run time.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
with no obvious configuration, build, or run-time issues for our
standard 3 principal configurations. The test summary continues to be
f95
Missing examples : 19
Differing graphical output : 16
Missing stdout :
Differing stdout :
I also ran
valgrind examples/f95/x22f -dev svg -fam -o testf.svg
to test the plstransform change, and that gave a perfect (0 errors, no
leaks are possible) valgrind report and svg graphical results that
agreed exactly with the corresponding svg results from C.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
commit c646c82683b4792d862a4908ed7022ae4017417a
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Wed Jan 6 21:40:01 2016 +0100
Correct the interface routine plcontour_0 and implement a robust callback for transformations
The routine plfcont requires a transformation routine, this was missing from
the simplest version, plcontour_0. The current implementation uses the identity
mapping pltr0f.
A second small but essential change is the way the transformation callback
routines are handled. Because the Fortran standard does not allow
disambiguation via the argument list of procedure arguments, we decided to
use a different approach: the callback routine should always use double
precision, independent of the precision of the rest of the program
Tested by Arjen Markus <arjenmarkus@users.sourceforge.net> on Cygwin, using gfortran.
M bindings/f95/included_plplot_real_interfaces.f90
M examples/f95/x22f.f90
commit 1774a3dffbfd36606f43449700133bd919236336
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Jan 5 22:55:10 2016 -0800
New Fortran binding: convert 22nd example to use modern Fortran idioms
As a result of this fairly minor change to this example (mostly to the
"transform" callback function) we now have a method for enforcing the
correct number and type of arguments for callback routines. I assume
the essential here is that the transform callback now appears after
a "contains" statement which if I recall correctly automatically generates
an interface corresponding to transform, and because that interface
disagrees with the library one it generates a build-time error. That,
of course is a vast improvement over the previous situation where the
only error for wrong number or type of arguments in the callback was
a segfault at run time.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the svg and x22f95 targets and then running
valgrind examples/f95/x22f -dev svg -fam -o testf.svg
This produced a perfect valgrind report (0 errors, no leaks are
possible) and also svg results that were identical to the
corresponding C example results.
I also made tests of the type safety of the callback by changing the
number and kind of arguments to transform. In all these cases the gfortran
compiler emitted the following error message:
Error: There is no specific subroutine for the generic 'plstransform'
Strangely enough, despite gfortran being able to recognize when the
interface to the callback supplied by the user has the wrong number or
type of arguments, it still complains when attempting to build the
library that it cannot disambiguate plstransform if the disambiguation
parameter is consistently removed from the Fortran library
implemention of plstransform and also the use of plstransform in this
example.
M examples/f95/x22f.f90
commit 28ebbfd8f999e14b275605021367bd96313fe371
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Jan 3 21:48:46 2016 -0800
New Fortran binding: Add dimension checking, improve 2D transformation code consistency, and fix plimagefr bugs
The dimension checking additions (mostly for xg, and yg) were for
plshade_single_1, plshade_single_2, plshades_multiple_1,
plshades_multiple_2, plvectors_1, and plvectors_2. This means we
should now have consistent dimension checking of xg and yg
for all variants of plcont, plshade, plshades, plvect, and plimagefr.
The transformation consistency improvements were to use identical code
for pltr2f for all cases where xg and yg were two-dimensional in the
new Fortran binding. And to use identical code for transform for all
related signatures: _0, _1, _2, and _tr (referring to plcont, plshade,
plshades, plvect, and plimagefr signatures where xg, yg, and tr are
not in the argument list, 1D xg and yg are in the argument list but
not tr, 2D xg and yg are in the argument list but not tr, and xg, and
yg are not in the argument list, but tr is in the argument list.)
The plimagefr bug fix is I forgot to use xg_in and yg_in for the _1
and _2 cases. This bug would generate run-time issues for the case
when kind=kp is different than private_plflt. But we don't test that
case now which explains why the plimagefr tests looked good before
this fix.
I also made sure all "use" statements had an associated "only" clause,
and I often checked that clause to make sure the minimum necessary was
being used from each module.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target for
the shared library case. The fortran summary result remained the
same
f95
Missing examples : 19
Differing graphical output : 16
Missing stdout :
Differing stdout :
i.e., Fortran example 16 is still not consistent with the
corresponding C result. And further looks at diff files between the
Fortran and C results for the svg case and visual inspection of
example 16a showed all issues were for 2D xg and yg and were generally
due to missing fills for the Fortran case. And valgrind
results for Fortran examples 16 and 16a continue to be perfect.
So the above changes made absolutely no difference to the missing
fills issue for plshade and plshades with "_2" signature, but they
have cleared out a lot of obfuscating differences in code between the
various "_2" signatures for 2D xg and yg, and they now also do much
better checking of the dimensions of xg and yg in all cases.
M bindings/f95/included_plplot_real_interfaces.f90
commit b0f1779e39b686ae266614353c6260dc57754407
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Sun Jan 3 15:18:14 2016 +0100
New Fortran binding: Add remaining API relevant to examples 16 (and
16a), 21, and 22
That is, I implemented the full plshade. plshades and plvect families
of routines as well as plstransform. For now, the latter required an
added dummy "data" argument to disambiguate the single- and
double-precision versions, but since that is a backwards-incompatible
change to the Fortran API, Alan will attempt to find another solution.
Furthermore, because the routines for the plstransform callback are used
by C they must be externally visible and have a unique name. Therefore
I put them in the file plplot_bindings instead of in the included file.
Tested by: Arjen Markus <arjen.markus@deltares.nl> on Cygwin with
gfortran as well as compiled using Intel Fortran under Windows. One
thing that remains to be done is plGetCursor.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target for the
shared library case. The result summary was
f95
Missing examples : 19
Differing graphical output : 16
Missing stdout :
Differing stdout :
i.e., examples 16, 21, and 22 have now been added to the list of
Fortran examples which are buildable.
Examples 21 and 22 produce the same -dev psc results as the
corresponding C examples, but there are substantial differences for
example 16. Further investigation showed the 16th Fortran example had
substantially fewer fills then the corresponding C example but those
extra C fills may have been cropped or behind other fills because the
C and Fortran results were visually indistinguishable. To simplify the
investigatio I tried nx, ny = 3, 4 for both the C and Fortran example,
but in that case there were identical results. So the investigation
of this issue continues.
Example 16a was also added to the list of buildable examples, and the
resulting first page of the plot looks good (although it has been
years since I looked at it so I cannot guarantee there has been no
change). The second page of the plot has some bad-looking vacant
areas, however, so clearly there is some issue with the plshade
variant that was used to produce that result.
The valgrind reports for
valgrind examples/f95/x<example id>f -dev svg -fam -o testf.svg
where example id is (unmodified or modified) 16, 16a, 21, and 22 are all perfect (0 errors, no
leaks are possible).
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
M examples/f95/x22f.f90
M plplot_test/test_f95.sh.in
commit dc3d53727d827d19f7e8481bceb01d3e0039949b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Jan 2 01:15:31 2016 -0800
New Fortran binding: Add remaining API relevant to example 20
That is, add plimagefr (with 3 variants for no xg, yg,
single-dimensioned xg, yg, and double-dimensioned xg, yg). This is
sufficient for example 20, but still have to also add _tr variant to
give fortran users an additional standard way to map transforms
for plimagefr.
I fixed an uninitialized bug in examples/f95/x20.f90 that was
discovered by valgrind by initializing the character array that is
written to a temporary file to help determine the logical record
length of Fortran direct access files for any given Fortran platform.
I also took this opportunity to tighten up the plcont only: and size
consistency checking logic. I also noticed a bug, (but did not fix
it) for the contour_0 case which will likely currently segfault
(missing value attribute), but when that is fixed, it will just end
with an error message since c_plcont specifically does not allow a
NULL pltr callback. Instead, contour_0 needs to be changed to use the
pltr0 identity transform.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_tes
t_interactive no
with no obvious configuration, build, or run-time issues for our
standard 3 principal configurations. The test summary is
f95
Missing examples : 16 19 21 22
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., example 20 has now been added to the list of Fortran examples which
are buildable and which have the same -dev psc results as the corresponding C
examples.
For example 20 I got perfect results (0 errors, no leaks are possible)
for
valgrind examples/f95/x20f -dev svg -fam -o testf.svg
Those svg graphical results agreed exactly with the corresponding svg
results from C. (Note that the svg device has full PLplot
capabilities so this is a more powerful test than the -dev psc tests
that are done with the above comprehensive test.)
I did some additional valgrind testing of some variants (now
dropped with and "if(.false.) then [....] endif) that used both the
doubly dimensioned and singly dimensioned xg, yg variants to plot an
untransformed "Lena". The valgrind report was perfect for these
variants, and they produced identical results with each other and
results that were visually identical to the plimage results for
"Lena". But the filling method is different in the plimage versus
plimagefr cases (the pixel to the lower right of the given point is
filled in the plimagefr case) so the numerical results are different.
Because I had made substantial editing changes for the plcont cases, I
ran
valgrind examples/f95/x09f -dev svg -fam -o testf.svg
which gave a perfect valgrind report as well as SVG results
that agreed with the corresponding C results.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
M examples/f95/x20f.f90
M plplot_test/test_f95.sh.in
commit e2b403001421ea9dc11106f945227703ab492d07
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Dec 31 15:49:29 2015 -0800
New Fortran binding: Adopt a strict rule that Fortran logical corresponds to C PLBOOL type
This is a backwards-incompatible change which is documented in
README.release.
The plarc module procedure now strictly conforms to the above rule
with the extra signature with integer fill type dropped.
The plconfigtime ifbtime_offset argument has now been changed to
logical in conformity with the above rule.
I have now defined and used the private_plbool = 4 parameter to help
indicate in module procedure interfaces (by using private_plbool as a
kind value) when the corresponding C routine has an argument with
PLBOOL type.
I also took this opportunity to fix some substantial errors (no value
assigned, and comparison with wrong kind parameter of private_plflt
rather than private_plint) in logic concerning npts_local for all
three plsvect module_procedures (plsvect_double, plsvect_none, and
plsvect_single). Note, that plsvect still is not being run-tested by
the tests below since example 22, the only example that exercises
plsvect, does not currently build.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_tes
t_interactive no
with no obvious configuration, build, or run-time issues for our
standard 3 principal configurations. The test summary continues to be
f95
Missing examples : 16 19 20 21 22
Differing graphical output :
Missing stdout :
Differing stdout :
We cannot currently build or run those "missing" examples because of
the following remaining issues with the new Fortran binding:
16, plshades not implemented yet;
19, plmap*, plmeridians, plslabelfunc, and plstransform not implemented yet;
20, plimagefr not implemented yet;
21, plshades not implemented yet; and
22, plshades, plstransform, and plvect not implemented yet.
And because these examples cannot currently be run-time tested yet
additional API that is referenced in them but in no other examples (such as
plsvect mentioned above) continues not to be run-time tested.
M README.release
M bindings/f95/included_plplot_private_types.f90.in
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
M examples/f95/x03f.f90
M examples/f95/x27f.f90
M examples/f95/x29f.f90
commit d2f86191006f0ce2f8de6eae7fa0911b79458845
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Dec 30 22:02:40 2015 -0800
New Fortran binding: add API for plsdrawmode, plsmem, plsmema, and plstart
None of these are tested by the Fortran examples, but they complete
implementation of all common API (those with "c_" prefixes) for
Fortran other than deprecated routines (which we do not want to
propagate to new Fortran in any case), and the following list of
routines which have callbacks in their argument lists:
c_plimagefr
c_plmap
c_plmapfill
c_plmapline
c_plmapstring
c_plmaptex
c_plmeridians
c_plshades
c_plslabelfunc
c_plstransform
c_plvect
The above missing list of routines means we are currently unable to build
or test Fortran examples 16 19 20 21 22, but it should not take that
long to implement the remaining API above and build and test this list
of examples.
Note, I also took this opportunity to reorder the routines in
bindings/f95/included_plplot_real_interfaces.f90 and
bindings/f95/plplot_bindings.f90 in alphabetical order which makes
this commit somewhat intrusive.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the plplotf95 target without build errors
and checking the resulting library with "ldd -r".
(No run-time tests of plsdrawmode, plsmem, plsmema, and plstart are
possible at this time because no fortran examples currently call these
functions.)
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
commit 0ef04837a0ad13f3520fc2d20d81260a36d2f966
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Tue Dec 29 17:07:46 2015 +0100
New Fortran binding: Add remaining API relevant to example 15
That is, I added plshade and all relevant callbacks for that routine.
I also changed the plpat API in a backwards incompatible way to use
the standard redacted form with redundant dimension removed.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_tes
t_interactive no
with no obvious configuration, build, or run-time issues for our
standard 3 principal configurations. The test summary is
f95
Missing examples : 16 19 20 21 22
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., example 15 has now been added to the list of Fortran examples which
are buildable and which have the same -dev psc results as the corresponding C
examples.
For example 15 I got perfect results (0 errors, no leaks are possible)
for
valgrind examples/f95/x15f -dev svg -fam -o testf.svg
Those svg graphical results agreed exactly with the corresponding svg
results from C. (Note that the svg device has full PLplot
capabilities so this is a more powerful test than the -dev psc tests
that are done with the above comprehensive test.)
M README.release
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
M examples/f95/x15f.f90
M plplot_test/test_f95.sh.in
commit f74f91fb7f34033307dae5d295d9baf387d8c4f7
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Tue Dec 29 15:28:47 2015 +0100
New Fortran binding: plcont fixes and add examples x09f and x14f
Those fixes were to insert intent(in) for all dummy arguments with the value attribute
and to install all the module intermediate files (which are not
required for the gfortran case but which are required for the Intel
fortran compiler case). In addition some "only" fixes were required to
propagate the new defined types PLcGrid and PLfGrid where needed.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
with no obvious configuration, build, or run-time issues for our
standard 3 principal configurations. The test summary is
f95
Missing examples : 15 16 19 20 21 22
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., examples 9 and 14 have now been added to the list of Fortran examples which
are buildable and which have the same -dev psc results as the corresponding C
examples.
For examples 9 and 14, I got perfect results (0 errors, no leaks are possible)
for
valgrind examples/f95/x09f -dev svg -fam -o testf.svg
and
valgrind examples/f95/x14f -dev svg -fam -o testf.svg
(where I responded to the question by storing the secondary example 14
results file in test1f.svg).
Those svg graphical results agreed exactly with the corresponding svg
results from C. (Note that the svg device has full PLplot
capabilities so this is a more extensive test than the -dev psc tests
that are done with the above comprehensive test.)
M bindings/f95/CMakeLists.txt
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
M plplot_test/test_f95.sh.in
commit 797e9ae9a77101bcbc7492b5f8aeed72bf8008fc
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Tue Dec 29 09:55:30 2015 +0100
Implement the new Fortran interface for plcont. This involves defining callback functions - the interface to these functions depends on the actual form they take their data arguments in. This is not entirely ideal as there is more code involved but earlier attempts via type(c_funptr) caused coredumps.
Some remarks:
- I had to add a new module - plplot_private_exposed - to accomodate for
one of the transformation routines. This routine is now exposed to the
world. If I can get the type(c_funptr) approach to work, then this may
be eliminated again.
- The bind(c) attribute is essential, as it changes some of the semantics
of argument passing. I suspect this caused the earlier coredumps. The
current implement does its job and it is not too hard to change it again
if the previous approach works.
- Be careful to use type(c_ptr) in combination with the value attribute.
Otherwise you get the address of the pointer instead of the address.
This is the rather confusing aspect of the C technique to pass a "void *"
pointer and cast it to something useful.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
commit c7b7936d2c73024d240d6f9ceef45de2a1fd0594
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 29 11:27:50 2015 -0800
New Fortran binding: Add remaining API relevant to example 31
That is, I added plscolbga, plsdiori, plsdiplt, plsdiplz, plgfnam, and
plscmap1.
I also fixed variable naming bugs where I forgot the _out suffix, e.g.,
- aspect = real(aspect, kind=wp)
- jx = real(jx, kind=wp)
- jy = real(jy, kind=wp)
+ aspect = real(aspect_out, kind=wp)
+ jx = real(jx_out, kind=wp)
+ jy = real(jy_out, kind=wp)
in the plgdidev and plgdiori module procedures that had been
previously implemented but tested for the first time now with example
31.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
with no obvious configuration, build, or run-time issues for our
standard 3 principal configurations. The test summary is
f95
Missing examples : 09 14 14a 15 16 19 20 21 22
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., example 31 has now been added to the list of Fortran examples which
are buildable and which have the same -dev psc results as the corresponding C
examples.
For example 31 I got perfect results (0 errors, no leaks are possible)
for
valgrind examples/f95/x31f -dev svg -fam -o testf.svg >| testf.out
and those svg graphical and ascii results agreed exactly with the
corresponding svg results from C. (Note that the svg device has full
PLplot capabilities so this is a more extensive test than the -dev psc
tests that are done with the above comprehensive test.)
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
M plplot_test/test_f95.sh.in
commit ba189932ddd4f27e97717177d0d72351cfde6f8a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 28 23:23:00 2015 -0800
New Fortran binding: Change naming conventions for certain entities
The plan for the new naming convention is the entities previously
called plrandd (a function with no arguments that returns a real), PLGraphicsIn (a
defined type which contains real quantities), and PLNOT_SET, PL_PI,
and PL_TWOPI (predefined real parameters) where the previous
associated real precision was plflt will be changed to always be
double precision regardless of the real precision of the PLplot C
library. And the single-precision variants of these same quantities
will be defined with the names plrandd_single, PLGraphicsIn_single,
PL_NOTSET_single, PL_PI_single, and PL_TWOPI_single.
This commit implements this plan for plrandd and PLGraphicsIn.
I also took this opportunity to add the plgdrawmode API and to make
private_plflt, private_single, and private_double actually private.
These changes and the fact that private_plint was already actually
private required that the real(kind=private_plflt, private_single, or
private_double) or integer(kind=private_plint) type of result returned
by the plrandd and plgdrawmode functions had to have a type statement
in the body of the function rather than as part of the function
statement. To make that Fortran style uniform I used this form for
typing all function return values, and appended "!function type" to
the type statement for this case so it will be easy to find in the
future.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the plplotf95 library.
M README.release
M bindings/f95/plplot_bindings.f90
M examples/f95/x20f.f90
commit 0200406380f219739e51dc2ccf16223f375c31cd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Dec 28 00:42:48 2015 -0800
New Fortran binding: Add remaining API relevant to example 23
That is, I added plmtex3 and plptex3.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
with no obvious configuration, build, or run-time issues for our
standard 3 principal configurations. The test summary is
f95
Missing examples : 09 14 14a 15 16 19 20 21 22 31
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., example 28 has been added to the list of Fortran examples which
are buildable and which have the same results as the corresponding C
examples.
For example 28 I got perfect results (0 errors, no leaks are possible)
for
valgrind examples/f95/x28f -dev svg -fam -o testf.svg
and those svg results agreed exactly with the corresponding svg results
from C. (Note that the svg device has full PLplot capabilities
so this is a more extensive test than the above -dev psc tests.)
M bindings/f95/included_plplot_real_interfaces.f90
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
M plplot_test/test_f95.sh.in
commit 9908e79680165c70fc82c2c2869fdc8d25d8a333
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 27 23:29:52 2015 -0800
New Fortran binding: Add remaining API relevant to example 23
That is, I added plsfci and plgfci.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie). Since this is the first buildable commit for a
while, I was able to do extensive testing. I ran
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
with no obvious configuration, build, or run-time issues for our
standard 3 principal configurations. The test summary is
f95
Missing examples : 09 14 14a 15 16 19 20 21 22 28 31
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., example 23 has been added to the list of Fortran examples which
are buildable and which have the same results as the corresponding C
examples.
For example 23 I got perfect results (0 errors, no leaks are possible)
for
valgrind examples/f95/x23f -dev svg -fam -o testf.svg
and those svg results agreed exactly with the corresponding svg results
from C. (Note that the svg device has full PLplot capabilities
so this is a more extensive test than the above -dev psc tests.)
Furthermore, for all buildable examples (everything not on the above
missing list which constitutes 23 buildable examples), I configured
tests to automatically run valgrind (using the cmake option
-DVALGRIND_ALL_TESTS=ON), and built the test_f95_psc target. The
result was perfect valgrind results for the 23 currently buildable
Fortran tests that are run by that target for -dev psc.
M bindings/f95/plplot_bindings.f90
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
M plplot_test/test_f95.sh.in
commit 9a85636ac0b67d3bcf75a0bfcee95bf353d2a2da
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 27 19:17:54 2015 -0800
New Fortran binding: drop support for kind=plint and kind=plunicode integer Fortran types
We never implemented such support in a consistent way in any case so
my judgement is this previous support should be classified as experimental
and removed now since default integer Fortran types should be fine
to match the C PLINT and PLUNICODE arguments.
M README.release
M examples/f95/x19f.f90
M examples/f95/x23f.f90
commit 5f9788036bfef54d64c48e8e88d07876d091aec4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 27 17:56:32 2015 -0800
New Fortran bindings: Add API relevant to example 22
That API is plsvect (for which there is a special case of
3 signatures, i.e., no real arguments, double-precision real
arguments and single-precision real arguments). The remaining
API required by example 22 (plcont, plshades, plstransform, and
plvect) all have callback arguments and therefore remain
unimplemented at this time.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by attempting to build x22f95. That build failed
because of the missing API mentioned above, but the added plsvect
implementation did not generate any build failures.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
M examples/f95/CMakeLists.txt
commit 83615606499bab8455455ed6a410026770089214
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 27 14:25:21 2015 -0800
New Fortran binding: Fix matrix_to_c bug and add API relevant to example 21
The matrix_to_c bug fix patch hunk was
integer :: i_local
allocate( carray(size(array,2),size(array,1)) )
- allocate( caddress(size(array,2)) )
+ allocate( caddress(size(array,1)) )
carray = transpose( array )
- do i_local = 1,size(array,2)
+ do i_local = 1,size(array,1)
caddress(i_local) = c_loc(carray(1,i_local))
enddo
end subroutine matrix_to_c
The point is that each column of the Fortran carray corresponds to a
row of the corresponding C array. Furthermore, the C address of the
starting location of each column of the Fortran carray (or
equivalently the C address of the starting location of each row of the
corresponding C array) must be stored for later C use. However, the
size of caddress is the number of columns of carray which is
size(array,1)) and not size(array,2)), and the do loop must be over
the range of 1 to size(array,1)) as well.
The bug in the previous code would have no effect if size(array,2) >
size(array,1) (other than the caddress array would be larger than
needed and its trailing (unused) values would be garbage. However,
for the case where size(array,2) < size(array,1) the bug in the
previous code could have severe memory management effects because
the caddress array would be smaller than what is required by
the C routine.
The added API relevant to example 21 was plenv0, and plgriddata.
I also took the opportunity to change several
use iso_c_binding
instances that had crept back in to the appropriate
use iso_c_binding, only: ...
form.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by temporarily modifying examples/f95/x21.f90
to comment out the plshades call, building the x21f95 target,
and running it with
valgrind examples/f95/x21f -dev svg -fam -o testf.svg
That produced perfect (0 errors and no memory leaks are possible)
valgrind results and also plot file results (for the non-plshades page) that
agree exactly with the corresponding C pages.
M bindings/f95/included_plplot_real_interfaces.f90
M examples/f95/CMakeLists.txt
commit 5a1a524a1a0db63006e624c892c177bfbac3bc0f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 27 14:23:17 2015 -0800
New Fortran binding: Update description in the release notes.
M README.release
commit 9a9f7c829c854d5a67d99f8b1d994f574548b602
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 27 00:07:39 2015 -0800
New Fortran bindings: Add API relevant to example 20
That API is plimage, plxormod, plcpstrm, plsfnam, and plxormod.
I have also modified examples/f95/x20f.f90 to use the double version
of PlGraphicsIn.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by attempting to build x20f95. That build failed,
but only because plimagefr (a function with a callback argument)
has not been implemented yet.
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
M examples/f95/CMakeLists.txt
M examples/f95/x20f.f90
commit 7d97d758a71988788f4ab1ccf8f988630b4c9f19
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 26 17:52:24 2015 -0800
New Fortran binding: major style changes + implement plplot_graphics module and API for example 18
The style changes consist of the following:
* All formal arguments are declared with an intent attribute as the
last attribute before the "::".
* If the value attribute is used, it is placed just before the intent
attribute
* All variables that are not formal arguments have names with suffixes
of "_local" or "_out" to distinguish them from formal arguments. These
are the only variables which do not have an intent attribute in their
declaration.
* All interface routines whose names were previously prefixed with
"c_" have had that prefix changed to "interface_"
The plplot_graphics module adds PLGraphicsIn_single and
PLGraphicsIn_double types and (buildable but not yet completed, see
FIXME) module procedures plGetCursor_single and plGetCursor_double
which are overloaded as plGetCursor.
The API additions for example 18 are plstring3.
In addition, I took this opportunity to make the handling of the last
alt_hue_path argument to plscmap1la (tested in example 30) identical
to the plscmap1l API, i.e., process this argument as optional.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
with no obvious configuration, build, or run-time issues for our
standard 3 principal configurations. The test summary is
f95
Missing examples : 09 14 14a 15 16 19 20 21 22 23 28 31
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., example 18 has been added to the list of Fortran examples which
are buildable and which have the same results as the corresponding C
examples.
I tested a temporarily modified example 30 to show dropping the
last optional argument of plscmap1la worked properly.
For example 18 and unmodified example 30 I got perfect
results (0 errors, no leaks are possible) for
valgrind examples/f95/x18f -dev svg -fam -o testf.svg
and
valgrind examples/f95/x30f -dev svg -fam -o testf.svg
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
M plplot_test/test_f95.sh.in
commit 92d7fb3b71936e7a680718042e9f2577e155bd3b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Dec 26 17:38:58 2015 -0800
New Fortran binding: Drop installion of all PLplot module files other than plplot.mod
I discovered accidentally that our fortran examples (which only "use
plplot") can be built in the installed examples tree without access to
the other module files that are built in the build tree and which are
used by the plplot module to help build libplplotf95. I assume this
is because the details of those other plplot modules that are use(d)
by the plplot module are made part of the plplot module. Therefore,
following the principle of not exposing unneeded details to users, I
therefore dropped installing all plplot Fortran modules other than
plplot.mod.
M bindings/f95/CMakeLists.txt
commit 377a77669af5bf8051d3f7149f78ed4841b0c77d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Dec 25 01:19:05 2015 -0800
New Fortran binding: add API required by example 17
That API is plstripa and plstripc.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target. The summary of
results from that target is
f95
Missing examples : 09 14 14a 15 16 18 19 20 21 22 23 28 31
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., example 17 has been added to the list of Fortran examples which
are buildable and which have the same results as the corresponding C
examples.
I also ran
valgrind examples/f95/x17f -dev psc -o test.psc
and got perfect results (0 errors, no leaks are possible).
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplotf95c.c
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
M plplot_test/test_f95.sh.in
commit 237ae8f6b38b98621074f80ba21990da2783af4d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Dec 24 22:09:02 2015 -0800
New Fortran binding: add/fix API required by example 29
The added API required by example 29 was plbtime, plconfigtime,
plctime, plssym, and pltimefmt and the fixed API required for example
29 was plerrx, and plerry (where all arguments of the redacted
call are now arrays with consistent lengths).
I also took this opportunity to add plaxes API (which is untested by any
example) as well as implementing a consistent style for Fortran error messages
and for processing intent(out) arguments.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target. The
summary of results from that target is
f95
Missing examples : 09 14 14a 15 16 17 18 19 20 21 22 23 28 31
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., example 29 has been added to the list of examples which
are buildable and which have the same f95 and C results.
I also ran
valgrind examples/f95/x29f -dev psc -o test.psc
and got perfect results (0 errors, no leaks are possible).
M bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
M examples/f95/CMakeLists.txt
M examples/f95/Makefile.examples.in
M plplot_test/test_f95.sh.in
commit 69701ce443319dbc037dc3fbc0c0a25900af5e82
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 22 15:15:19 2015 -0800
New Fortran binding: Use module procedures to define all parts of the Fortran API
Code like the following before the "contains"
interface
subroutine plbop() bind(c,name='c_plbop')
end subroutine plbop
end interface
has now been replaced by code like the following after the
"contains"
subroutine plbop()
interface
subroutine interface_plbop() bind(c,name='c_plbop')
end subroutine interface_plbop
end interface
call interface_plbop()
end subroutine plbop
This change is more than just a style change because it has an
important linking effect; "nm --undefined-only" shows all direct
references to c_plbop, etc., are now gone from the compiled examples
so it is no longer necessary/desireable to link those examples
directly with libplplot. Furthermore, that same command shows there
are no direct references in the compiled examples to the libplplotf95c
API. So I have also changed all Fortran example linking (both
CMake-based and traditional) to only link directly to libplplotf95,
and this will be a considerable simplification for our Fortran binding
users.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by a successful run of
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_f95=ON" --do_test_interactive no
Also, ldd -r tests applied to various Fortran libraries/examples for
the shared case (the only case I tested in detail this way) showed no issues.
M bindings/f95/CMakeLists.txt
M bindings/f95/plplot_bindings.f90
M examples/f95/CMakeLists.txt
commit ac6881a9b395a92f6172caa7c58322a6ecd806ec
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 22 15:13:02 2015 -0800
New Fortran binding: Make the traditional build drop the same (currently unbuildable) examples as the CMake-based builds
M examples/f95/Makefile.examples.in
commit 163734aac8e4b03dc13731f5b42a7d23a31c725a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 22 15:09:13 2015 -0800
New Fortran binding: solve visibility bug for libplplotf95c
make fc_plcolorbar, fc_pllegend, and fc_plparseopts visible.
M bindings/f95/plplotf95c.c
commit c131184d01cbc64808bfc5a13d358491b9058a31
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 20 13:14:01 2015 -0800
New Fortran binding: Change naming convention for included files
The previous name convention (that all included files end with the
".inc" suffix) gave poor editing results because editors would not
automatically change to fortran mode when editing those files. The gdb
debugger also had trouble with recognizing such files as well.
Therefore I have changed to the naming convention for such
files that their names are prefixed with "included_" as an indicator
that they are included files, and suffixed with ".f90" to indicate
they are Fortran source files.
I also took this opportunity to add Fortran example 33 to the list
of tests that are run.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by successfully building the test_diff_psc target. The summary
of the results is
f95
Missing examples : 09 14 14a 15 16 17 18 19 20 21 22 23 28 29 31
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., example 33 has been added to the list of Fortran examples that
have no differences in results with the corresponding C example.
M bindings/f95/CMakeLists.txt
A bindings/f95/included_plplot_parameters.f90
A bindings/f95/included_plplot_private_types.f90.in
A bindings/f95/included_plplot_real_interfaces.f90
M bindings/f95/plplot_bindings.f90
D bindings/f95/plplot_parameters.inc
D bindings/f95/plplot_private_types.inc.in
D bindings/f95/plplot_real_interfaces.inc
M examples/f95/CMakeLists.txt
M plplot_test/test_f95.sh.in
commit f683249e34e17743499fb4378dfd4e996dc65967
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 20 12:46:26 2015 -0800
New Fortran binding: miscellaneous small changes
plrandd_impl renamed to plrandd so that example 17 can link to plrandd.
Implemented check of second dimension of values argument in plcolorbar.
M bindings/f95/plplot_bindings.f90
M bindings/f95/plplot_real_interfaces.inc
commit 0e7e7963e9efecc1d873feee35f2032793a5bee9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 20 00:17:29 2015 -0800
New Fortran binding: Add plcolorbar required by examples 16 and 33
Also made these additional changes/corrections:
* Corrected C name for plscolbg from c_plscol0 to c_plscolbg
* Changed incorrectly spelled "adress" to "address" everywhere
in the Fortran interface code.
* Changed use iso_c_binding to always use the only: keyword in the
most restrictive way possible.
* Use appropriate kind parameter on passed length of character arrays.
* Corrected plsmaj, plsmin, and plspage to use value attribute to
avoid passing garbage to the corresponding C routine. I chased
this particular plsmaj bug (whose symptom was missing tick marks) a long
time before I finally spotted the missing "value" attributes
in all three of these routines.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by succesfully building the x33f95 target and running
valgrind examples/f95/x33f -dev psc -o testf.psc
The valgrind report was perfect (0 errors and no leaks are possible)
and the result agreed exactly (except for date stamp) with
the result from the corresponding C example.
I also attempted to build x16f95. That build failed only because
Fortran versions of plcont and plshades are not available yet.
M bindings/f95/plplot_bindings.f90
M bindings/f95/plplot_real_interfaces.inc
M bindings/f95/plplotf95c.c
M examples/f95/x33f.f90
commit 1c29667bf612a73620ed376987fc1c0bcaa254d1
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Dec 18 22:42:44 2015 -0800
New Fortran binding: Add all API (except for plcont, plshades, and plcolorbar) required by examples 16 and 33
That is, I added plscmap1_range, plsmaj, plsmin, plspal0, and plspal1
to the new binding, but not plcont and plshades (other API currently
missing for example 16), and plcolorbar (other API missing for both
examples 16 and 33).
N.B. this is a backwards-incompatible API change for Fortran plspal1
where the last argument type has been changed from integer to logical
to be consistent with the PLBOOL type of the corresponding
argument of the C routine.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by succesfully building the plplotf95 target and attempting to
build x16f95 and x33f95 (in the latter two cases no issues
showed up other than the noted missing API).
N.B. This is a useful but still limited build test. We cannot test
run-time issues with plscmap1_range, plsmaj, plsmin, plspal0, and
plspal1 by building and running the x16f95 and x33f95 targets until
plcont, plshades, and plcolorbar are added to the new Fortran binding.
M README.release
M bindings/f95/plplot_bindings.f90
M bindings/f95/plplot_real_interfaces.inc
M examples/f95/CMakeLists.txt
M examples/f95/x16f.f90
M examples/f95/x33f.f90
commit 3fc7d1d4e11809c489a575e3680f62e87e426741
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Dec 18 21:41:47 2015 -0800
New Fortran binding: Add all API (except for plcont) required by example 14
That is, I added plgdev, plsdev, plsetopt, and plspage to the new binding, but not plcont (the only other API
currently missing for example 14).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by succesfully building the plplotf95 target.
N.B. This is a useful but still limited build test. We cannot test
run-time issues with plgdev, plsdev, plsetopt, and plspage by building
and running Fortran example 14 until plcont is added to the new
Fortran binding.
M bindings/f95/plplot_bindings.f90
M bindings/f95/plplot_real_interfaces.inc
M examples/f95/CMakeLists.txt
commit 2461d468fdde4f9f7332e2e3d60ba478396482bc
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Dec 18 18:20:44 2015 -0800
New Fortran binding: Add all API (except for plcont) required by example 9
That is, I added pl_setcontlabelformat, pl_setcontlabelparam, and
plvpas to the new binding, but not plcont (the only other API
currently missing for example 9).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by succesfully building the plplotf95 target.
N.B. This is a useful but limited build test, and we cannot test
run-time issues with pl_setcontlabelformat, pl_setcontlabelparam, and
plvpas by building and running Fortran example 9 until plcont is added
to the new Fortran binding.
M bindings/f95/plplot_bindings.f90
M bindings/f95/plplot_real_interfaces.inc
M examples/f95/CMakeLists.txt
commit b200068c23accbed68e0528ce1de7bc47f1acafe
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Dec 18 17:23:36 2015 -0800
Fortran binding: Add API required for example 13 to new binding
That is, I added plvasp to the new binding and readded example 13 to
the Fortran examples which are built and tested.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by building the test_diff_psc target with the following results:
f95
Missing examples : 09 14 14a 15 16 17 18 19 20 21 22 23 28 29 31 33
Differing graphical output :
Missing stdout :
Differing stdout :
That is example 13 has been added to the list of examples
that produce the same results as the equivalent C examples.
I also ran
valgrind examples/f95/xNNf -dev psc -o test.psc
for NN = 13 and perfect results (0 errors, no leaks are possible) were
found.
M bindings/f95/plplot_real_interfaces.inc
M examples/f95/CMakeLists.txt
M plplot_test/test_f95.sh.in
commit 5a53d9d4d1b0af705522ceae2c7da6fa233dee56
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Dec 18 16:45:36 2015 -0800
Fortran binding: Add API required for examples 10 and 11 to new binding
That is, I added plsvpa, plmesh, plmeshc, plot3d, plot3dc, and plot3dcl.
I also reviewed the very similar plsurf3d (used in example 8) and
removed the idx argument that had been appended for some reason to
the C interface defined in the module procedure since that was
not consistent with the C API for that function.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by building the test_diff_psc target with the following results:
f95
Missing examples : 09 13 14 14a 15 16 17 18 19 20 21 22 23 28 29 31 33
Differing graphical output :
Missing stdout :
Differing stdout :
That is, examples 10 and 11 have been added to the list of examples
that produce the same results as the equivalent C examples.
I also ran
valgrind examples/f95/xNNf -dev psc -o test.psc
for NN = 08, 10, and 11, and in all cases perfect
results (0 errors, no leaks are possible) were found.
M bindings/f95/plplot_real_interfaces.inc
M examples/f95/CMakeLists.txt
M plplot_test/test_f95.sh.in
commit 82a1911a0b0507008e5fb923493f924674541809
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Dec 17 22:27:34 2015 -0800
Fortran binding: Implement pllegend
The transformation of the two Fortran character array arguments must be
done in C, so the complete interfacing solution for the Fortran
version of pllegend requires calling a fc_pllegend C wrapper for the C
version of pllegend.
I deliberately introduced two backwards incompatible changes for this
implementation to be consistent with the remaining Fortran API.
1. Only the redacted form of Fortran pllegend (with redundant nlegend
dropped from the argument list) was implemented.
2. In that redacted form nlegend is determined from the size
of one of the arrays, but the rest are checked to have consistent
sizes.
These changes required that both Fortran standard examples 4 and 26 had
to be changed.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by building the test_diff_psc target. The
results summary was
f95
Missing examples : 09 10 11 13 14 14a 15 16 17 18 19 20 21 22 23 28 29 31 33
Differing graphical output :
Missing stdout :
Differing stdout :
i.e., as a result of the current commit, examples 4 and 26 (which
previously had differing graphical output) now agree
with their C counterparts.
I also ran
valgrind examples/f95/x04f -dev psc -o test.psc
and
valgrind examples/f95/x26f -dev psc -o test.psc
Both produced perfect results (0 errors and "no leaks are possible").
M bindings/f95/plplot_real_interfaces.inc
M bindings/f95/plplotf95c.c
M examples/f95/x04f.f90
M examples/f95/x26f.f90
commit a027678c1ab43dbafb1d830b25c73465a46caba0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Dec 17 22:26:35 2015 -0800
Fortran binding: Tweak coding style of plplot_bindings.f90
M bindings/f95/plplot_bindings.f90
commit e8caf25d79c3c06497cd26111b2c46e5106f43ef
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Dec 17 14:38:12 2015 -0800
Fortran binding: Write initial notes about this rewritten binding in the release notes
M README.release
commit 5b37ad0c97f229fa44a4b3b45222cb4e7b20f62b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Dec 17 12:51:02 2015 -0800
Fortran binding: move code in plparsopts.f90 into plplot_bindings.f90
The motivation for this change is there is no reason to keep
plparseopts implemented in a separate file, and having all the
non-real Fortran API defined in one file makes it easier to do overall
modern Fortran style changes.
D bindings/f95/plparseopts.f90
M bindings/f95/plplot_bindings.f90
commit 85b2ef4168091a13d2c179292a4c0cb669c58c05
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Dec 17 12:23:22 2015 -0800
Fortran binding: Rename plplot_interfaces.inc -> plplot_real_interfaces.inc
The motivation for this renaming is this file is exclusively concerned
with the PLplot Fortran interfaces for the subset of the API that
has real arguments. The interfaces where the API has no real arguments
are implemented separately in plplot_bindings.f90.
M bindings/f95/plplot_bindings.f90
D bindings/f95/plplot_interfaces.inc
A bindings/f95/plplot_real_interfaces.inc
commit 762337a59ab0372894604970a3d3106a90075968
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Dec 16 21:27:15 2015 -0800
Fortran binding: Initial implementation of libplplotf95c, the C part of the interface for the new binding
Some aspects of implementing the new Fortran binding cannot be handled
completely by the iso_c_binding Fortran module capabilities. A good
example of this is the transformation of a blank-padded character
array Fortran argument to the required C array of pointers to
null-terminated character strings argument of plparsopts. I have
dealt with this issue by implementing in the new plplotf95c C library
a C function to make the required argument transformation, and a
fc_plparseopts function that calls that transformation function and
then calls plparseopts with its argument in the correct (transformed)
form.
Because of this correct implementation of Fortran plparseopts
I was able to reinstate calling plparseopts for
examples/f95/x00f.f90, and test (see below) building and running
the Fortran examples (in the form they all had before the start of
this topic branch) with the new binding.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux by
attempting to build the test_diff_psc target. Roughly ~60 per cent of
the examples did not build (typically because of certain parts of the
Fortran API that are currently missing from the new binding), but once
those examples were eliminated from the build list and run list, then
I could build the test_diff_psc target with the following result:
f95
Missing examples : 09 10 11 13 14 14a 15 16 17 18 19 20 21 22 23 28 29 31 33
Differing graphical output : 04 26
Missing stdout :
Differing stdout :
where the missing examples are the ones that do not yet build. There
is obviously still quite a bit of work to do, but nevertheless the
examples that do build and have no differences with the equivalent C
results (i.e., 00 01 02 03 05 06 07 08 12 24 25 27 30) are a
promising start for the new Fortran binding, and the rest of this
project will simply consist of eliminating the problems that cause the
above differing graphical output and missing examples.
M bindings/f95/CMakeLists.txt
M bindings/f95/plparseopts.f90
A bindings/f95/plplotf95c.c
M examples/f95/CMakeLists.txt
M examples/f95/x00f.f90
M plplot_test/test_f95.sh.in
commit b3ebcaf2cca47f5d97bb97ab8e977afe3e1bc0e4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 15 19:40:45 2015 -0800
Fortran binding: Fix example build and run-time errors for the new binding
The fixes were the following:
* Name the C version of plparseopts correctly (as c_plparseopts and not f_plparseopts)
* Link the examples to both the plplotf95 and plplot libraries. The
latter is required by the iso_c_binding method. Very shortly (see
below) the plplotf95c library (the part of the Fortran interface that
is too complicated to be handled by the iso_c_binding method so it
must be written in C) will be added to the list of libraries that must
be linked.
* Temporarily drop the call to plparseopts in examplex/f95/x00f.f90.
This change is not needed to build that example, but it is needed to
run it. Otherwise, the plparseopts call in this (and other examples)
currently just segfaults. The issue is that plparseopts must interface an array
of character strings from fortran to C. That complicated interfacing
task cannot be done by the iso_c_binding module and instead must be
done at the C level in the the planned small plplotf95c library that
will now be needed again.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by building the ps and x00f95 targets and then running
valgrind examples/f95/x00f
(note no command line arguments are used because plparseopts is
temporarily not called in this example in order to get it to run
without segfaults. The PostScript results looked good (after entering
the device and output file by hand), the valgrind report was pristine
(no errors, no leaks possible), and the ldd -r test gave clean results
as well.
M bindings/f95/plparseopts.f90
M examples/f95/CMakeLists.txt
M examples/f95/x00f.f90
commit 1df8874a864c8d2d2e03eb65e4ba8a5cb31d507d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 15 17:26:10 2015 -0800
Fortran binding: Fix the last of the current set of build errors for libplplotf95
The fixes were to implement the definition of the maxlen parameter
(which is required by plparseopts) before the contains in the plplot
module, and the removal of "use plplot" from plparseopts which is one
of the files that are included in the plplot module beyond the
contains statement.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by building the plplotf95 target. Note, however, that the
test_diff_psc target still does not work because the Fortran
examples are linked with both the plplotf95 and plplotf95c libraries
and the latter does not exist (yet) in the new Fortran binding.
M bindings/f95/plparseopts.f90
M bindings/f95/plplot_bindings.f90
commit 4684dea3765eca0b6a2bc5acddf8fe9408f06435
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 15 17:19:35 2015 -0800
Fortran binding: remove plplot_types.f90.in file that was added in error to the new binding
I added this file to the new binding because it was configured by
bindings/f95/CMakeLists.txt, but it defines a plplot_types module in
nameclash conflict with the plplot_types module defined in
plplot_bindings.f90 and the latter definition should be the module
that is used for the new binding Therefore remove this file as well as
the bindings/f95/CMakeLists.txt references to it.
N.B. The new Fortran binding still does not build, but the removal of
this confusion between two modules with identical names has
substantially reduced the build errors.
M bindings/f95/CMakeLists.txt
D bindings/f95/plplot_types.f90.in
commit 89da458811039af2a7f9ce01c9a3c9d70ef517de
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 15 13:54:53 2015 -0800
Fortran binding: add missing files to the new binding
Arjen made two attempts to implement this new binding. These 4 files
that are required by his second attempt are missing from that
attempt so I copied them from his first attempt.
N.B. This commit completes Arjen's most recent work on this topic.
However, this new Fortran binding still does not build ("use plplot"
inside the plplot module and maxlen not defined) so I plan some
immediate additional changes to address these issues.
A bindings/f95/plparseopts.f90
A bindings/f95/plplot_parameters.inc
A bindings/f95/plplot_private_types.inc.in
A bindings/f95/plplot_types.f90.in
commit 7dad4e95be0745a6b4d4015873656e8416234d6e
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 15 13:48:07 2015 -0800
Fortran binding: start implementation of new Fortran binding
Move bindings/f95 to bindings/old_f95 and copy all three files from
Arjen's new attempt at the new bindings to bindings/f95.
N.B. This version does not build (missing files).
M bindings/f95/CMakeLists.txt
D bindings/f95/global_defines.sed
D bindings/f95/plparseopts.f90
A bindings/f95/plplot_bindings.f90
A bindings/f95/plplot_interfaces.inc
D bindings/f95/plplot_parameters.inc
D bindings/f95/plplot_types.f90.in
D bindings/f95/plplotf95.def
D bindings/f95/plplotf95_ifort.def
D bindings/f95/plplotf95_mingw.def
D bindings/f95/plstubs.h
D bindings/f95/readme_f95.txt
D bindings/f95/sc3d.c
D bindings/f95/sccont.c
D bindings/f95/scstubs.c
D bindings/f95/sfstubs.inc
D bindings/f95/sfstubsf95.f90
D bindings/f95/strutil.f90
A bindings/old_f95/CMakeLists.txt
A bindings/old_f95/global_defines.sed
A bindings/old_f95/plparseopts.f90
A bindings/old_f95/plplot_parameters.inc
A bindings/old_f95/plplot_types.f90.in
A bindings/old_f95/plplotf95.def
A bindings/old_f95/plplotf95_ifort.def
A bindings/old_f95/plplotf95_mingw.def
A bindings/old_f95/plstubs.h
A bindings/old_f95/readme_f95.txt
A bindings/old_f95/sc3d.c
A bindings/old_f95/sccont.c
A bindings/old_f95/scstubs.c
A bindings/old_f95/sfstubs.inc
A bindings/old_f95/sfstubsf95.f90
A bindings/old_f95/strutil.f90
commit 406d8cff7d4aea9930bbea11e66fdcf2057e0006
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Jan 11 16:43:47 2016 -0800
Change -locate mode for C example 01 to give more information
In fact, we now print out all fields from the PLGraphicsIn struct that
is returned by plGetCursor. This additional information makes the
locate mode for this example a much better diagnostic tool for exactly
how each device fills this struct.
M examples/c/x01c.c
commit 6a8474bc8974d6df615e769882b7723094733aa1
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Jan 11 16:43:02 2016 -0800
Style previous wxwidgets-related commit
M drivers/wxwidgets_dev.cpp
commit 3f05b0b2af985124c4f3102a54291c556ca3de44
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Jan 11 17:08:01 2016 +0000
Removed ellipse added to wxWidgets text rendering for debug purposes
M drivers/wxwidgets_dev.cpp
commit 8d10b036c97c213368050ad8f3ce36d525f80269
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Jan 11 15:47:33 2016 +0000
Created a PlDevice class, separate from wxPLDevice, fixed wx aspect
problems and text height
Unfortunately this commit ended up including multiple items that I
couldn't disentangle. The initial plan was to create a PlDevice C++
class which can be used as a base class for wxPLDevice and other
future drivers. In particular I plan to split the wxDevice into
two, one where a wxDC is passed in and one which uses the viewer.
However I ended up moving some of the wxWidgets text code around
and then ended up fixing a long standing aspect ratio problem too.
Regarding the PlDevice class, this class is still declared in
wxwidgets.h. It mostly consists of some virtual method declarations
and very little code. The only code I did move into this class was
the code which parses text into lines and line sections. The
conversion to wxString still occurs in this code and it uses
wxCoord, so it is not entirely wxWidgets free, but I will deal with
these later.
The moving around of the text code, made me change how text
transforms are performed and caused me to look into a previous
wxWidgets driver aspect ratio bug. In the end I found that this was
caused by the wxPLplotwindow not being created with the intended
size (it was resized to that size later) and this caused plinit to
be called with the wrong aspect ratio. The wcPLplotwindow class has
had a size parameter added to its constructor to fx this.
I also found that wxWidgets reports the total line spacing as line
height, not just the ascender as assumed in the text size
calculations. This has been fixed.
M bindings/wxwidgets/wxPLplotwindow.h
M drivers/wxwidgets.h
M drivers/wxwidgets_dev.cpp
M utils/wxplframe.cpp
M utils/wxplviewer.cpp
commit aab6dd1adf692f7031643948dcb2d8ef7881cef1
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 8 20:04:58 2016 -0800
Core library: modify plmap code so that the library rather than examples emits warning messages concerning missing resources/capabilities
This change is a fix for the previous approach which used the
PL_USE_SHAPEFILES macro in examples to decide what warnings to emit, but
such a macro-based approach does not work for languages other than C
or C++ so we have now removed all references to PL_USE_SHAPEFILES
in the C and C++ examples (as well as the rest of our source tree).
Furthermore, I have now factored the src/plmap.c file so
that src/plmap.c is exclusively concerned with the shapelib
approach and therefore no longer has any reference to the old deprecated
plmap approach, and src/deprecated_plmap.c is exclusively concerned
with the old deprecated plmap approach and has no reference to
the modern shapelib approach. The build system has been adjusted so
that when PL_DEPRECATED=OFF (the usual default) only the plmap.c code
and not deprecated_plmap.c is compiled into libplplot, and when PL_DEPRECATED=ON
only deprecated_plmap.c and not plmap.c is compiled into libplplot.
We discuss 3 cases:
I. PL_DEPRECATED=OFF, HAVE_SHAPELIB=ON
II. PL_DEPRECATED=OFF, HAVE_SHAPELIB=OFF
III. PL_DEPRECATED=ON
Case I.
This the usual case and it gives good results with no warning messages
for all pages of example 19.
Case II.
For this case most of the code in plmap.c is ignored by the
preprocessor (because the macro HAVE_SHAPELIB corresponding to the
CMake variable of the same name is not #defined). Thus, the only code that
is left all the plmap* functions which
simply emit a warning message similar to
*** PLPLOT WARNING ***
plmap is a no-op because shapelib is not available.
and return. Also, for what it is worth the plmeridians function is
available.
The net result for example 19 for Case II is as expected; all the
boxes are blank on each page of this example except for the
plmeridians results for two of them and "Baltimore" string for one of
them. Also a warning message similar to the above is emitted by the
library (not the example!) each time example 19 calls any of the
plmap* functions.
Case III.
For this case, the code in deprecated_plmap.c is used which makes no
reference to shapelib functionality or HAVE_SHAPELIB at all so you get
the same result regardless of whether HAVE_SHAPELIB is OFF or ON. The
plmap function does plot the maps of the first 4 pages of example 19
using the old-fashioned non-shapelib method and data, but the rest of
the plmap* functions simply emit a warning similar to
*** PLPLOT WARNING ***
plmapfill not available when the -DPL_DEPRECATED=ON cmake option is used.
The net result for example 19 case III is as expected; the first four
pages of the example are plotted without issues or warning messages,
and the last shapelib-related page plots a blank box and the library
(not the example!) emits warning messages of the above type every time any plmap*
function is called in that example page. (Note, plmap itself is not
called by that page.)
Tested by: Alan W. Irwin ,airwin@users.sourceforge.net> on Linux
(Debian jessie). For each of Cases I, II, and III, the expected
results as described above were obtained and the command
valgrind examples/c/x19c -dev svg -fam -o testc.svg
gave a perfect report (0 errors, no leaks are possible).
M cmake/modules/shapelib.cmake
M examples/c++/x19.cc
M examples/c/x19c.c
M include/plConfig.h.in
M src/CMakeLists.txt
A src/deprecated_plmap.c
M src/plmap.c
commit 71674bfbb80449ddae3218fa16401ec3b8e7e16f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Jan 8 14:29:15 2016 -0800
Style previous wxwidgets-related commit.
M drivers/wxwidgets.h
M drivers/wxwidgets_dev.cpp
commit 02d88cf83b3521cb836c33ac31687dd398fb7b48
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Jan 6 20:47:01 2016 +0000
Restructured the wxWidgets text size again and remove tests for
wxGraphicsContext
It seems that although the previous solution worked it is not supported
to create wxBitmaps or wxMemoryDCs in a console app. It is however
supported (although it seems undocumented) to create wxGraphicsContexts
from a wxImage in a console application - see
http://trac.wxwidgets.org/ticket/17319 and
http://trac.wxwidgets.org/ticket/17320
Also removed all checks for wxUSE_GRAPHICS_CONTEXT because this is now
supposedly set to 1 for all wxWidget platforms and also because there is
no officially supported fallback.
M drivers/wxwidgets.h
M drivers/wxwidgets_dev.cpp
commit 4677df1d837a3b775f1a9e60b8d61db469816143
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Jan 6 15:11:51 2016 +0000
Restyle of previous commits
M drivers/wxwidgets.cpp
M drivers/wxwidgets.h
M drivers/wxwidgets_dev.cpp
commit 526930623af6bcb3ef683f4d97a00d14680d7c9d
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Jan 6 14:52:46 2016 +0000
Added comments regaeding m_interactiveTextGcdc in wxWidgets driver
M drivers/wxwidgets_dev.cpp
commit 4716981fc65f87f7918df81c6efa24b8fcac40c4
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Jan 6 14:32:36 2016 +0000
Fixed incorrect #ifdef && syntax from previous commit
M drivers/wxwidgets_dev.cpp
commit 14a9b64ada9d90a9f4f5c7f8849a7b7e5fc50fbe
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Jan 6 14:24:05 2016 +0000
In the wxWidgets driver only use wxGraphicContext under Windows
Ideally we want to use a wxGraphicsContext (wxGCDC) to determine the
size of text because that is what is used in wxPLViewer. However under
Linux creation of the wxGrahicsContext causes a crash. It might be that
this is only for wxGTK2, not wxGTK3 as wxWidgets does slightly different
things for these two cases, but until I have access to a GTK3 machine
for testing I can't be sure.
So for all OSs other than Windows we do the text measuring using a
wxMemoryDC. For Windows we use a wxGCDC.
M drivers/wxwidgets_dev.cpp
commit 7500643d57ebd5cca44b0602ec5544a60f397d5e
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Jan 6 10:52:18 2016 +0000
Sort wxWidget initialization
In order to call GUI functions there appears to be a need for some
initialization which results from the creation of a wxApp. This seems to
be the case on Linux when creating wxFonts (which we need to be able to
do to get text sizes), although Windows seems less fussy. However, we
don't want to start the message loop,
so rather than using one of the wxWidget macros we just create and
initialize a default wxApp without calling wxApp::OnRun, which is the
function which begins the message loop.
M drivers/wxwidgets.cpp
commit 46dd29042f02ad24dc5c56c5b06e3780c1fd2412
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Jan 5 21:42:18 2016 +0000
Fix the interactive text wxBitmap at 24 bpp
Using the screen depth does not work on Linux as wxWidgets tries to
derive this from the top level window which doesn't exist. This causes a
crash. It doesn't actually matter what bit depth is used as the bitmap
is never actually drawn on - it just allows a valid wxMemoryDC to be
constructed for defining text size.
M drivers/wxwidgets_dev.cpp
commit 1cbdb58d49483df1dca9d3c2563c64c5b48ef67c
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Jan 5 21:39:31 2016 +0000
Make the text sizing wxGraphicsContext in the wxWidgets driver temporary
The wxGCDC takes ownership of the wxGraphicContext pointer and deletes
it, so we can pass it straight in and forget about it. We don't need to
(and shouldn't) delete it ourselves.
M drivers/wxwidgets.h
M drivers/wxwidgets_dev.cpp
commit 10973c88cf309bba9556db166633853d02e60f5e
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Jan 4 13:21:39 2016 +0000
Added copyright notice for map data
M Copyright
commit 5a774c56b0c284fda1faf99efe8cc49bcbd94b7f
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Jan 4 12:17:04 2016 +0000
Formatting of previous commit
M drivers/wxwidgets.h
M drivers/wxwidgets_dev.cpp
commit fc76e0a3379ba8ff5c98428cb1684f6f7fef36a6
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Jan 4 11:49:13 2016 +0000
Changed strategy to get text size in wxWidgets driver
The delay in getting the text size from the wxPLViewer has been of
concern. Doing this required both the calling application and the viewer
to repeatedly poll the shared memory checking for updates which can
introduce significant delays. We now create a memory DC in the driver to
use specifically for getting text size when the user does not pass in a
wxDC.
M drivers/wxwidgets.h
M drivers/wxwidgets_dev.cpp
commit d63d0aef732c949fab7fbc01791824ad879465b2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Jan 4 00:41:13 2016 -0800
Core library: move the warning concerning a NULL pltr callback from plcont to plfcont
plcont calls plfcont immediately with unchanged callback argument so
moving the warning to the latter function provides the warning for
both functions. Previously, the warning was only emitted for the
plcont call so a direct call to plfcont (which unconditionally
executes the callback) would previously have had run-time errors with
a NULL callback.
M src/plcont.c
commit a7730f58694ea8b8e39c7e2567e25e9386df1fce
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Dec 30 16:07:24 2015 -0800
Build fix for C++ example 20: revert back to previous termination method if lena.pgm cannot be found
That is, the termination method is changed as follows:
- fprintf(stderr, "No such file");
- plend();
- exit(1);
+ cout << "No such file - aborting" << endl;
+ delete pls;
+ exit( 1 );
The "delete pls" not only terminates pls properly (including an
internal call to plend) but also eliminates the erroneous direct call
to the libplplot routine plend. That direct call meant that example
20 failed to build since like all other C++ examples it is
deliberately linked directly just to libplplotcxx and not libplplot.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by building the test_diff_psc target with the
following expected perfect C++ results:
c++
Missing examples :
Differing graphical output :
Missing stdout :
Differing stdout :
Furthermore, I used valgrind to run C++ example 20 from the top-level
build tree (as it happens for the "-dev svg -fam" options) and got the
expected (from the above change) "No such file - aborting" message as
well as perfect (0 errors, no leaks are possible) valgrind results. I
also did the same thing from within the examples/c++ directory for the
case when that file was available and again got perfect valgrind
results.
M examples/c++/x20.cc
commit e84e29e0741b03f1504a9e8ae36f8ab2e2098d1f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Dec 30 16:06:19 2015 -0800
Style previous commits.
M drivers/wxwidgets_dev.cpp
M examples/c/x20c.c
commit 36bd058bc5470d10fd7964cc56b6f3d76c1d4d81
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Dec 29 17:21:30 2015 +0000
Fix compile error for wxPLplotwindow for gcc
GCC seems to require the scope for the GetClientSize() method from the
inherited WXWINDOW class. This has been added and tested on Cygwin.
M bindings/wxwidgets/wxPLplotwindow.h
commit 08d4864e5fc3302cd34515815d840725465acd5f
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Dec 28 20:29:06 2015 +0000
Removed named mutex for perfomance boost to the wxWidgets driver.
As far as I can tell the mutex used in wxPLDevice::TransmitBuffer is not
needed as the buffer records the read and write positions and avoids
overtaking that way. Generating this mutex adds about 25% overhead on
Windows. Not sure about the overhead in Linux, but hopefuly this will
help performance issues reported by Alan.
M drivers/wxwidgets_dev.cpp
commit f847a2a0bdd4455598770c023a0844ef038ed310
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Mon Dec 28 17:54:45 2015 +0000
Allowed x20 to run directly from VS build
When building with Visual Studio the examples are built in a Release or
Debug subdirectory which requires an extra .. in the path for the Lena
file.
M examples/c++/x20.cc
M examples/c/x20c.c
commit aef40748666b87f2bc46cd2116ec2c12325015ac
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Sun Dec 27 21:56:58 2015 +0000
Recomment out the WXPLVIEWER_DEBUG define
M drivers/wxwidgets_dev.cpp
commit 8f73a317f887a9d3834a382fde1cdca471eda68c
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Sun Dec 27 20:18:39 2015 +0000
Noted that the -j4 option does not work on Cygwin for the documentation
build.
M doc/docbook/README.developers
commit 9863b15a8376f373c9561e1b660e440552f3f755
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Dec 22 22:32:59 2015 +0000
Added documentation for PLGraphicsIn::state and moved PLTranslateCursor documentation to the C-api.
M doc/docbook/src/api-c.xml
M doc/docbook/src/api.xml
M doc/docbook/src/plplotdoc.xml.in
commit 7a0a47da75d455d60ec7efb8cd7304a52441d1bb
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 15 12:08:42 2015 -0800
Ada language support: Update CMAKE_Ada_CREATE_SHARED_LIBRARY and CMAKE_Ada_CREATE_SHARED_MODULE for the Mac OS X case
This change is necessary to get the new Ada language support to work
on Mac OS X. The change follows the special support for C, CXX, and
Fortran in CMake's installed version of Modules/Platform/Darwin.cmake
where that special support for those languages has not changed since
CMake-3.0.2.
Tested by: Jerry Bauck <jbauck@users.sourceforge.net> on Mac OS X
10.9.5 "Mavericks" for both the AdaCore version of Ada-4.7.4 and the
FSF version of Ada-4.9.1. The successful tests that were performed
for each Ada install was to configure, build, run, and test the
test_ada project at cmake/test_ada following the directions at
cmake/test_ada/README for both the shared build and static build
cases. Note this is a direct test that the basic Ada language support
works for the extremely simple cmake/test_ada project that creates an
Ada library that writes out "hello, world" and an Ada executable that
calls that library. So this is naturally not as comprehensive as the
test below, but it is an excellent sign that the more comprehensive
test below will work on Mac OS X once Jerry is in position to try it.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian jessie) by running
scripts/comprehensive_test.sh --do_test_interactive no --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ada=ON"
with no configure, build, or run-time issues for all comprehensive
testing configurations. Note, this is a comprehensive test of the Ada
language support files at cmake/modules/language_support/cmake which
are identical (except for one line concerning the location of the
support files) with the files at cmake/test_ada/Modules that were
tested by Jerry.
M cmake/modules/language_support/cmake/CMakeAdaInformation.cmake
M cmake/test_ada/cmake/Modules/CMakeAdaInformation.cmake
commit fc396824c0369dd60c60a848ac154fae6ade8658
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Dec 15 12:07:25 2015 -0800
test_ada: Add Mac OS X instructions to the README
M cmake/test_ada/README
commit 3d35f9ebc9500683c5cd25904dcd6d3bf8a56cf5
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Dec 22 22:23:41 2015 +0000
Added key bindings to mouse events in wxPLplotwindow and the wx demo
M bindings/wxwidgets/wxPLplotwindow.h
M examples/c++/wxPLplotDemo.cpp
M include/plplot.h
commit b74bde7a5b83b84b533175c6e6a0dbee71b64b9a
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Dec 22 21:07:12 2015 +0000
Added defines for the different masks used in PLGraphicsIn::state
M include/plplot.h
commit 24f08b0e73f715bdced6558a0bc265db369f61c3
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Dec 22 20:18:45 2015 +0000
make the destructor of wxPLplotwindow virtual to ensure safe destruction
of child classes
M bindings/wxwidgets/wxPLplotwindow.h
commit 81f8e82cc3086bc5b9f2b31e525607e63caa8f31
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Dec 22 20:18:04 2015 +0000
remove some commented out code
M bindings/wxwidgets/wxPLplotwindow.h
commit a0208c3bdab4107c90e461776f275e21ca2d8095
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Dec 22 20:09:07 2015 +0000
Stopped capturing mouse button down events in wxPLplotwindow
Apparently this can stop windows receiving focus. We now only capture
button up events.
M bindings/wxwidgets/wxPLplotwindow.h
commit b90635d9fcba816f5bdd75c547c18bfe25d67ec0
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Dec 22 11:52:17 2015 +0000
Exposed plTranslateCursor in C++ binding
This exposed it in the wxWidgets binding also where it is used to
process mouse events. These can be accessed via the virtual OnLoad
method. The wxPLplotDemo makes use of this.
The function has now also been documented.
Styling of the changes made changes to map.c too.
M bindings/c++/plstream.cc
M bindings/c++/plstream.h
M bindings/wxwidgets/wxPLplotwindow.h
M doc/docbook/src/api.xml
M drivers/wxwidgets_dev.cpp
M examples/c++/wxPLplotDemo.cpp
M src/plmap.c
commit a847a9df374db00094e4239780cd25ea60b74dc4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Dec 20 00:52:08 2015 -0800
DocBook documentation: white space tweak
M doc/docbook/src/api.xml
commit a18f0de89e23acff33c269faa09dc8c96b989f00
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Fri Dec 11 12:45:36 2015 +0000
Fixed typo in ifdef in example 19
This now allows the final shapelib page to be rendered.
M examples/c++/x19.cc
M examples/c/x19c.c
commit 49705055fb4d02c294fafd11e3e205ecee991aee
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Dec 10 11:43:23 2015 -0800
Build system: shapelib: remove comma from set(PL_USE_SHAPEFILES, TRUE)
Note this fix for the recent shapelib changes is needed, but the default
result is the last page of example 19 does not display at all so more
shapelib-related changes are required.
M cmake/modules/shapelib.cmake
commit a388c9b630d9ff7b620f01b8e5ada2b821376cda
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Dec 10 11:34:59 2015 -0800
Tweak release manager cookbook
Change all references from Debian Wheezy to Debian Jessie.
M README.Release_Manager_Cookbook
commit dcc53449c53b9cecb052929888ea89e3a6981078
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Dec 10 12:39:30 2015 +0000
Fixed compile error when using no shapelib and deprecated is off and
attempt to silence x19 warnings
The error was simply a variable defined in the wrong #ifdef section.
To avoid the warnings we need to not run the shapelib example when no
shapelib support is on. I tried to set up a PL_USE_SHAPEFILE, but this
doesn't seem to have worked. Awaiting Alan's input to fix.
M cmake/modules/shapelib.cmake
M examples/c++/x19.cc
M examples/c/x19c.c
M include/plConfig.h.in
M src/plmap.c
commit a3e9db5aa5cb3b6b4112121e0198aa488819f491
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Nov 28 23:34:59 2015 -0800
test_ada and PLplot Ada language support: adopt .o extension for object files for all platforms
Contrary to C++ (and other mainstream compilers) where this extension
is either .o for Unix or .obj otherwise we have evidence on both MinGW
(from years ago with a fix implemented in the old Ada language
support) and MinGW-w64 (now for the new Ada language support where
this fix is now required) that this extension is always .o for Ada
regardless of platform. So use that assumption unless or until we
find a platform where that assumption is not correct (i.e., one where
the error message "gnat1: incorrect object file extension" is emitted
by the gnat1 Ada compiler front-end to the gcc compiler.
M cmake/modules/language_support/cmake/CMakeAdaInformation.cmake
M cmake/test_ada/cmake/Modules/CMakeAdaInformation.cmake
commit 6a6241e918cd05e2cd20a02011bb33ac7ba62468
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 27 21:25:07 2015 -0800
Update C example 7 to include a plptex Hershey escape sequence debugging mode
The introduced -plptex_mode example option replaces the plsym call by
the largely equivalent plptex call. This change does not need to be
propagated to non-C languages. The intention of this debugging mode is
to allow direct comparison of plsym results (which use Hershey fonts
directly) with the corresponding plptex results for the equivalent
Hershey code.
For device drivers that use Hershey fonts (e.g., the xwin device) the
results with and without the -plptex_mode option are identical aside
from occasional horizontal offsets that typically are too small to be
seen but which for certain characters can be as large as 1/20th the
box width. Despite those relatively large offsets in a minority of
cases, the only hypothesis I have to explain this difference is the
possibility of different internal coordinate systems and rounding of
those positional results. But why are the large offsets only in X,
but not Y? Anyhow, this is an issue that should be revisited once we
review and completely update the internal coordinate systems for
PLplot to not be limited to just 16-bit integers.
For unicode-aware devices (such as -dev qtwidget), there is a
translation done internally between Hershey escape sequences (as in
the present very extensive example when -plptex_mode is used) and
equivalent unicode. And for -dev ps and -dev psc there is a further
translation between that derived unicode result and the corresponding
Type 1 Adobe font code for characters. So to further debug the
Hershey-to-unicode transformation, it is planned to compare example 7
results with and without -plptex_mode for -dev qtwidget and to further
debug the Unicode to type1 transformation, the equivalent experimenet
is planned for -dev ps.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux by
comparing -dev xwin results for example 7 with and without the new
-plptex_mode option with results that have been described above.
Additional systematic testing using this mode is planned (also
described above). One of those planned comparisons (for the -dev psc
device) has already been spot checked for the "#(855)" case, and as
currently discussed on the plplot-devel list, the plsym result shows
the Hershey font arrow while the plptex result shows a blank (unlike
other devices). I am virtually positive this difference is due to a
missing entry in the Unicode to type1 transformation table, but it is
also probable this is a result of no glyph to represent an arrowhead
in the set of 35 standard type 1 fonts, i.e., this is an artifact of
the limitations of Type 1 fonts.
M examples/c/x07c.c
commit 18a989a59b40be9401ebb7f168b685928f7c8ea0
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 27 21:23:34 2015 -0800
Update the release notes to reflect the current (fairly minimal) progress made so far in this release cycle.
M README.release
commit 783c4934c4acf498372debfe8cb95144faaba6bd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 27 20:46:34 2015 -0800
PLplot core library: remove octal number interpretation for numerical escape sequences
The long-standing but undocumented octal possibility for numerical
escape sequences (first introduced in 2008, but just brought to my
attention now) concerns the semantics of the strtoul C library
function (used in text2num which in turn is used in the chain of calls
from plptex, plptex3, plmtex, and plmtex3, but not plsym).
Previously the base in the strtoul call was set to 0. Here is what
the strtoul Linux man page says about that case:
"If base is zero or 16, the string may then include a "0x" prefix, and
the number will be read in base 16; otherwise, a zero base is taken as
10 (decimal) unless the next character is '0', in which case it is
taken as 8 (octal)."
Furthermore, my experiments and also some of the man pages for strtoul
on the web (e.g., <http://illumos.org/man/3C/strtoul>) indicate the
Linux man page should state that strtoul interprets both "0x" and "0X"
as the hexadecimal case. So for base 0, the strtoul interpretation of
numbers assumes a base following exactly what is done for C numerical
constants.
But that "feature" contradicts our documentation where hexadecimal and
decimal possibilities are documented (e.g., in
<http://plplot.sourceforge.net/docbook-manual/plplot-html-5.11.1/characters.html>
for the present release), but the octal possibility is undocumented.
Furthermore, newbie C programmers and programmers who have no
experience with C may be surprised by that octal interpretation. For
example, before the present fix the Hershey encoding sequence
"#(0855)" (the one where I discovered this issue) chokes on the 8
because of the octal interpretation due to that leading zero, and such
users will experience even a larger surprise when they discover that,
e.g., "#(0123)" and "#(123)" silently give very different results
because of the respective octal (because of the leading zero) and
decimal interpretations.
Accordingly, instead of documenting this feature, I have made the
choice to remove the octal intepretation from our code (by setting
base for the strtoul call to 10 unless the string prefix is 0x or 0X
in which case base is set to 16).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux using
some modified C examples where plptex and plmtex calls included
Hershey escape sequences with leading 0's (those numbers interpreted
now as decimal rather than the previous octal) and both leading 0x and
0X (those numbers interpreted as hexadecimal as always).
M src/plcore.c
commit 0cc31228a38de78be4b0e4066f54bdb6edbaadbd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Nov 25 08:58:30 2015 -0800
test_ada and PLplot Ada language support: restore explicit linking of Ada libraries to libgnat
This change solves an underlinking issue for the Ada libraries that
was nonconsequential on Linux (except that ldd -r on Ada libraries
revealed the issue) but which caused a build error on Cygwin.
On all platforms use the PRIVATE CMake keyword for the
target_link_libraries command used to link the Ada library with
libgnat. That means that Ada applications that are linked to the Ada
library will not be overlinked to libgnat.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux using
CMake-3.3.2 (built using the bootstrap procedure).
For the test_ada project I followed the test procedure documented in
cmake/test_ada/README. The configuration with cmake, build, run-time,
valgrind, and ldd -r results (including ldd -r on the Ada library and
Ada executable) were all clean.
For the PLplot project I used the cmake options
-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON
-DENABLE_ada=ON to limit the test to Ada and built the
test_noninteractive target in the build tree using VERBOSE=1 without
any obvious configuration, build, or run-time issues and with the
usual
Comparison test using psc device
ada
Missing examples :
Differing graphical output : 08 19
Missing stdout :
Differing stdout :
adathick
Missing examples :
Differing graphical output : 08 19
Missing stdout :
Differing stdout :
results. In addition, the VERBOSE=1 build results revealed (as
expected from using the PRIVATE keyword) no underlinking of libgnat
for the Ada library and no overlinking of libgnat for any of the Ada
thin or thick examples. Furthermore, ldd -r gave good results on both
the Ada library and all Ada examples.
M bindings/ada/CMakeLists.txt
M cmake/modules/ada.cmake
M cmake/test_ada/CMakeLists.txt
M cmake/test_ada/README
A cmake/test_ada/ada.cmake
M cmake/test_ada/src_lib/CMakeLists.txt
commit f1b07d1e4530b75c51c8fa5d1de2ae611cfab466
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Nov 25 14:19:03 2015 +0000
Fixed scaling bug in wxWidgets driver
Changed the scaler object to have it use the GetUserScale and
SetUserScale functions. This is due to a bug in wxWidgets for
Windows where the LogicalScale varieties don't apply the changes.
This has been reported and fixed - see
http://trac.wxwidgets.org/ticket/17053, but this ensures backwards
compatibility.
M drivers/wxwidgets_dev.cpp
commit cbaa084f5e5fa6675443a03380a62031deecd29a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Nov 23 16:46:47 2015 -0800
PLplot Ada language support: integrate the new Ada language support
This process was done with the following steps:
1. recursive copying from cmake/test_ada/cmake/Modules to
cmake/modules/language_support/cmake to include all updated and new
files in that source directory tree in the destination directory tree;
2. updating the one specific location in
cmake/modules/language_support/cmake/CMakeDetermineAdaCompiler.cmake;
3. updating the lists of language support module files
in cmake/modules/language_support.cmake and examples/CMakeLists.txt;
4. updating cmake/modules/ada.cmake and bindings/ada/CMakeLists.txt to
drop all logic concerning GNAT_LIB since for the new Ada language
support we no longer search for the gnat library or explicitly
link to it.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux using
scripts/comprehensive_test.sh --do_test_interactive no --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ada=ON"
These comprehensive test options drop everything other than what is
required for comprehensive testing of the Ada component in the
interests of speeding up the test. This test showed no configuration,
build, or run-time errors, and also yielded for all the 12 different
test cases the following comparison results with C:
Comparison test using psc device
ada
Missing examples :
Differing graphical output : 08 19
Missing stdout :
Differing stdout :
adathick
Missing examples :
Differing graphical output : 08 19
Missing stdout :
Differing stdout :
These differences have been long-standing ones.
M bindings/ada/CMakeLists.txt
M cmake/modules/ada.cmake
M cmake/modules/language_support.cmake
M cmake/modules/language_support/cmake/CMakeAdaCompiler.cmake.in
M cmake/modules/language_support/cmake/CMakeAdaInformation.cmake
M cmake/modules/language_support/cmake/CMakeDetermineAdaCompiler.cmake
M cmake/modules/language_support/cmake/CMakeTestAdaCompiler.cmake
A cmake/modules/language_support/cmake/Compiler/GNU-Ada.cmake
A cmake/modules/language_support/cmake/Platform/CYGWIN-GNU-Ada.cmake
A cmake/modules/language_support/cmake/Platform/Darwin-GNU-Ada.cmake
A cmake/modules/language_support/cmake/Platform/Linux-GNU-Ada.cmake
A cmake/modules/language_support/cmake/Platform/Windows-GNU-Ada.cmake
A cmake/modules/language_support/cmake/README_Ada_language_support
M examples/CMakeLists.txt
commit eaebfc6d20dead6d0edae662454dcc204e90f225
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Nov 23 15:32:31 2015 -0800
test_ada Ada language support: Do not explicitly link the library to libgnat
This change means the created Ada library will have some unresolved
references (as revealed by (ldd -r src_lib/libhello.so), but
apparently the Ada builder (gnatmake) used to build Ada executables
that link to Ada libraries knows how to link libgnat in properly for
the executable (as revealed by ldd -r src_executable/hello), the
explicit linking required finding the gnat library (which required
some complications which have now all been removed), and there is a
possibility that current Cygwin build issues for the executable are
being caused by the explicit linking of the library (or else because
the wrong gnat library was being found on that platform).
M cmake/test_ada/CMakeLists.txt
M cmake/test_ada/README
D cmake/test_ada/ada.cmake
M cmake/test_ada/src_lib/CMakeLists.txt
commit 887982c08587aae41847af4bcd1f47b6eaa51b65
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Nov 23 14:04:50 2015 -0800
test_ada Ada language support: Do not enable C
This simplification of the test_ada project means life is a bit
more complex for testers of this project since CMAKE_LIBRARY_PATH
must be set in order to find libgnat for this special case where
none of the core languages (C, CXX, Fortran) are enabled. But
this change is fully documented in cmake/test_ada/README.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux using
CMake-3.3.2 (built using the bootstrap procedure) following the test
procedure documented in cmake/test_ada/README. The configuration with
cmake, build, run-time, valgrind, and ldd -r results were all clean.
M cmake/test_ada/CMakeLists.txt
M cmake/test_ada/README
M cmake/test_ada/ada.cmake
M cmake/test_ada/cmake/Modules/CMakeDetermineAdaCompiler.cmake
commit d6d33565c0b70652bcb9d31168c3a62bf8026e65
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Nov 23 11:24:32 2015 -0800
test_ada Ada language support: include Compiler/GNU-Ada.cmake
This changes means that compiler-specific information such as
CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS (where lang=Ada) should be
correctly initialized for all platforms. This change should solve a
Cygwin issue with incorrect initialization of
CMAKE_SHARED_LIBRARY_CREATE_Ada_FLAGS which meant the essential
-share attribute was missing from this definition for the Cygwin case.
Note this change requires testing on Cygwin.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux using
CMake-3.3.2 (built using the bootstrap procedure) following the test
procedure documented in cmake/test_ada/README. The configuration with
cmake, build, run-time, valgrind, and ldd -r results were all clean.
M cmake/test_ada/cmake/Modules/CMakeAdaInformation.cmake
M cmake/test_ada/cmake/Modules/CMakeDetermineAdaCompiler.cmake
A cmake/test_ada/cmake/Modules/Compiler/GNU-Ada.cmake
commit 2b52e9ef8523e95849ea6e1569535520f3ab63eb
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Nov 23 09:42:33 2015 -0800
test_ada Ada language support: Define and use CMAKE_Ada_MODULES for the location of the Ada-related modules
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux using
CMake-3.3.2 (built using the bootstrap procedure) following the test
procedure documented in cmake/test_ada/README. The configuration with
cmake, build, run-time, valgrind, and ldd -r results were all clean.
M cmake/test_ada/cmake/Modules/CMakeDetermineAdaCompiler.cmake
M cmake/test_ada/cmake/Modules/CMakeTestAdaCompiler.cmake
commit a118d72d809b195c86f8b08e5017100de1a67bac
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Nov 21 23:20:22 2015 -0800
Update instructions for the test_ada project
M cmake/test_ada/README
commit 36f30df3b8930ea1be3e2680446a1a5f3af9d1cd
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Nov 21 16:38:55 2015 -0800
Test Ada language support: override CMAKE_Ada_LINK_EXECUTABLE
On some platforms (e.g., Cygwin and Windows),
CMAKE_Ada_LINK_EXECUTABLE is set by default with completely wrong form
for Ada. So if such a default value exists, do not honor it (as
before which caused cmake to error out on Cygwin), but instead
override it with the correct form.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux using
CMake-3.3.2 (built using the bootstrap procedure) following the test
procedure documented in cmake/test_ada/README. The configuration with
cmake, build, run-time, valgrind, and ldd -r results were all clean.
M cmake/test_ada/cmake/Modules/CMakeAdaInformation.cmake
commit 7ce93f7408ad5ff7af9a19d753998db005c1a85c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 20 15:57:08 2015 -0800
Rename cmake/test_ada/cmake/Modules/Notes -> cmake/test_ada/cmake/Modules/README_Ada_language_support
D cmake/test_ada/cmake/Modules/Notes
A cmake/test_ada/cmake/Modules/README_Ada_language_support
commit a48c91ca3ece1c9e2fe96d965033a3236a8046a6
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 20 15:44:39 2015 -0800
Test Ada language support: Improve designation of location of Ada support files
Replace ${CMAKE_MODULE_PATH} by the equivalent but more specific
${CMAKE_SOURCE_DIR}/cmake/Modules for the location of the support
files. Note, that this location needs to be changed whenever the
location of the support files (e.g., when they are copied to the
PLplot project) is changed so also document that issue with
appropriate FIXME comment.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux using
CMake-3.3.2 (built using the bootstrap procedure) following the test
procedure documented in cmake/test_ada/README. The configuration with
cmake, build, run-time, valgrind, and ldd -r results were all clean.
M cmake/test_ada/cmake/Modules/CMakeDetermineAdaCompiler.cmake
M cmake/test_ada/cmake/Modules/CMakeTestAdaCompiler.cmake
commit f7e81e7384a4d12b738db504d0caffa419897bd4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 20 12:56:05 2015 -0800
Test Ada language support: update test instructions
M cmake/test_ada/README
commit d1c85c8c4896947cb8d25b66d8d540cf7fdd1ce3
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 20 12:29:57 2015 -0800
Test Ada language support: Add platform files
These platform files add platform-dependent tweaks to the Ada language
support. In all cases I followed exactly (except for substituting Ada
for CXX) what was done for the CXX equivalent using CMake-supplied
language-support infrastructure macros, but these platform tweaks have
only been so far tested (see below) on Linux where for that case they
didn't appear to make any important difference. But my hope (i.e., I
did not wade through the logic to confirm this) is the tweaks in the
Cygwin and MinGW (Windows) cases will sort out any issues with
generating the import library form of the shared library that was
missing before for Cygwin and which also might be an issue for
MinGW-w64/MSYS2 and/or MinGW/MSYS.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux using
CMake-3.3.2 (built using the bootstrap procedure) following the test
procedure documented in cmake/test_ada/README. The configuration with
cmake, build, run-time, valgrind, and ldd -r results were all clean.
M cmake/test_ada/cmake/Modules/CMakeAdaInformation.cmake
M cmake/test_ada/cmake/Modules/CMakeDetermineAdaCompiler.cmake
A cmake/test_ada/cmake/Modules/Platform/CYGWIN-GNU-Ada.cmake
A cmake/test_ada/cmake/Modules/Platform/Darwin-GNU-Ada.cmake
A cmake/test_ada/cmake/Modules/Platform/Linux-GNU-Ada.cmake
A cmake/test_ada/cmake/Modules/Platform/Windows-GNU-Ada.cmake
commit 850f5bfc22ba693a3ad65999516b2aefa36de800
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Nov 19 15:39:08 2015 -0800
Test Ada language support: rename cmake_working subdirectory to cmake
Also change CMakeLists.txt and cmake/Modules/CMakeTestAdaCompiler.cmake
within the test_ada subproject to adjust to this new directory name
location.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux using
CMake-3.3.2 (built using the bootstrap procedure) following the test
procedure documented in cmake/test_ada/README. The configuration with
cmake, build, run-time, valgrind, and ldd -r results were all clean.
M cmake/test_ada/CMakeLists.txt
A cmake/test_ada/cmake/Modules/CMakeAdaCompiler.cmake.in
A cmake/test_ada/cmake/Modules/CMakeAdaInformation.cmake
A cmake/test_ada/cmake/Modules/CMakeDetermineAdaCompiler.cmake
A cmake/test_ada/cmake/Modules/CMakeTestAdaCompiler.cmake
A cmake/test_ada/cmake/Modules/Notes
D cmake/test_ada/cmake_working/Modules/CMakeAdaCompiler.cmake.in
D cmake/test_ada/cmake_working/Modules/CMakeAdaInformation.cmake
D cmake/test_ada/cmake_working/Modules/CMakeDetermineAdaCompiler.cmake
D cmake/test_ada/cmake_working/Modules/CMakeTestAdaCompiler.cmake
D cmake/test_ada/cmake_working/Modules/Notes
commit 9009ee86c30745b701760ac964f54a0bc6535b30
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Nov 19 15:24:39 2015 -0800
Test Ada language support: move cmake_experimental directory contents to cmake_working
D cmake/test_ada/cmake_experimental/Modules/CMakeAdaCompiler.cmake.in
D cmake/test_ada/cmake_experimental/Modules/CMakeAdaInformation.cmake
D cmake/test_ada/cmake_experimental/Modules/CMakeDetermineAdaCompiler.cmake
D cmake/test_ada/cmake_experimental/Modules/CMakeTestAdaCompiler.cmake
D cmake/test_ada/cmake_experimental/Modules/Notes
M cmake/test_ada/cmake_working/Modules/CMakeAdaCompiler.cmake.in
M cmake/test_ada/cmake_working/Modules/CMakeAdaInformation.cmake
M cmake/test_ada/cmake_working/Modules/CMakeDetermineAdaCompiler.cmake
M cmake/test_ada/cmake_working/Modules/CMakeTestAdaCompiler.cmake
A cmake/test_ada/cmake_working/Modules/Notes
commit d8f6988f929361dc69b8250aac4d859960e8110b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Nov 19 15:03:02 2015 -0800
Experimental test Ada language support: add gcc to the list of compilers
When gcc is on the list (and for the case where ccache is installed)
the resulting Ada compiler is /usr/lib/ccache/gcc. Previously I
thought that would be an issue, but evidentally (see test below) it is
not, i.e., the ccache result is the same as if /usr/bin/gcc (which is
a symlink to gcc-4.9) had been used for the compiler. (Note the
alternative Ada compiler name gnatgcc is also a symlink to gcc-4.9 on
Debian Jessie).
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux by
using the -DEXPERIMENTAL_SUPPORT=ON cmake option (which tests the
language support in cmake_experimental rather than cmake_working)
while otherwise following the test procedure documented in
cmake/test_ada/README. For CMake-3.3.2 (built using the bootstrap
procedure) the run-time, valgrind, and ldd -r results were clean.
M cmake/test_ada/cmake_experimental/Modules/CMakeDetermineAdaCompiler.cmake
commit 10956e85ffd03d1b01711317ee8773060eb10909
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Nov 19 13:55:20 2015 -0800
Rewrite experimental test Ada language support
This rewrite is based on Ada modifications to the modern
(CMake-3.4.0-rc3) C++ language support with good notes concerning all
the C++ to Ada changes so it should be much easier to understand than
the old Ada language support which was poorly documented and based on
what CMake provided in terms of language support from a decade ago.
This new Ada language support is currently only in
cmake/test_ada/cmake_experimental and has not yet been propagated to
PLplot itself. Also, like the old Ada language support it does not yet
provide a means to create the necessary import library for the shared
case on Windows platforms such as Cygwin.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux by
using the -DEXPERIMENTAL_SUPPORT=ON cmake option (which tests the
language support in cmake_experimental rather than cmake_working)
while otherwise following the test procedure documented in
cmake/test_ada/README. For cmake-3.0.2 (the official Debian Jessie
version) and CMake-3.3.2 and CMake-3.4.0-rc3 (both built by myself
using the bootstrap procedure) the run-time, valgrind, and ldd -r
results were clean.
M cmake/test_ada/CMakeLists.txt
M cmake/test_ada/README
M cmake/test_ada/ada.cmake
M cmake/test_ada/cmake_experimental/Modules/CMakeAdaCompiler.cmake.in
M cmake/test_ada/cmake_experimental/Modules/CMakeAdaInformation.cmake
M cmake/test_ada/cmake_experimental/Modules/CMakeDetermineAdaCompiler.cmake
M cmake/test_ada/cmake_experimental/Modules/CMakeTestAdaCompiler.cmake
M cmake/test_ada/cmake_experimental/Modules/Notes
commit 142e9d2fbcfb54f8880e7c7ce74806d9478a5ed1
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Nov 13 17:23:09 2015 -0800
Build system: Fix minor bug with the test_extXdrawable target
The issue was if extXdrawable_demo is not built for some reason (such
as the Cygwin package for gtk+ not correctly depending on the
libxrandr package) then the extXdrawable_demo target does not exist
and the test_extXdrawable target should not be built for this case. A
simple change (adding AND TARGET extXdrawable_demo) to an if statement
controlling whether test_extXdrawable is built) fixed this issue, and
my thanks to Greg for running the Cygwin test that found this issue.
M examples/CMakeLists.txt
commit 747984161a74f785c5eade60bc9d53d43fdcbde4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Nov 10 11:59:57 2015 -0800
Build system: Bump minimum CMake version to 3.3.2 for most platforms
The exceptions are the Linux or Cygwin platforms where the minimum
CMake version remains at 3.0.2 (to accomodate using system versions of
CMake for Cygwin and most modern Linux distributions). In addition,
in the Linux or Cygwin case, the user is warned if they have a CMake
version between 3.2.0 and 3.3.1 because of a regression for that range
of CMake versions (corrected in 3.3.2) that compromised the find
ability of cmake.
M CMakeLists.txt
M examples/CMakeLists.txt
commit 16fe6dcb1e5acc3284f265af366eccc1b2099bfc
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Nov 9 17:28:58 2015 -0800
Build system: Update CMake D language support for CMake 3.4.0 or greater
Following suggestion by Brad King to adapt to different internal language support
infrastructure introduced for CMake 3.4.0 or greater replace
<FLAGS>
by
<INCLUDES> <FLAGS>
in definition of CMAKE_D_COMPILE_OBJECT,
CMAKE_D_CREATE_ASSEMBLY_SOURCE, and (commented out)
CMAKE_D_CREATE_PREPROCESSED_SOURCE. CMAKE_D_COMPILE_OBJECT is the
only definition of the three that is used and tested by PLplot, but I
updated CMAKE_D_CREATE_ASSEMBLY_SOURCE and
CMAKE_D_CREATE_PREPROCESSED_SOURCE to be consistent with what happens
for CMAKE_C_CREATE_ASSEMBLY_SOURCE and
CMAKE_C_CREATE_PREPROCESSED_SOURCE for cmake-3.4.0-rc3.
Tested by Alan W. Irwin <airwin@users.sourceforge.net> on Linux by
building (both with cmake-3.3.2 and cmake-3.4.0-rc3 and for the shared
and static libraries case) the test_diff_psc target. For all 4 cases
the D results were perfect, i.e.,
d
Missing examples :
Differing graphical output :
Missing stdout :
Differing stdout :
M cmake/modules/language_support/cmake/CMakeDInformation.cmake
M cmake/modules/language_support/cmake/Platform/Darwin-dmd.cmake
M cmake/modules/language_support/cmake/Platform/Linux-dmd.cmake
M cmake/modules/language_support/cmake/Platform/Linux-gdc.cmake
M cmake/modules/language_support/cmake/Platform/Windows-dmd.cmake
M cmake/modules/language_support/cmake/Platform/Windows-gdc.cmake
commit 5722b1754e384b62a18e20dc45d41785c1b40cbb
Author: Orion Poplawski <orion@cora.nwra.com>
Date: Sun Nov 1 19:51:48 2015 -0700
Add support for cmake 3.4 for Ada
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by building (both with cmake-3.3.2 and cmake-3.4.0-rc3) the
test_diff_psc target. For both cmake versions the Ada results were
ada
Missing examples :
Differing graphical output : 08 19
Missing stdout :
Differing stdout :
adathick
Missing examples :
Differing graphical output : 08 19
Missing stdout :
Differing stdout :
(Those issues for examples 8 and 19 are long-standing ones.)
Also for both versions of CMake I followed
the directions in cmake/test_ada/README to build and test the test_ada project
for both the static and shared libraries case. Those tests gave the
expected "hello, world" results.
M cmake/modules/language_support/cmake/CMakeAdaInformation.cmake
M cmake/test_ada/cmake_experimental/Modules/CMakeAdaInformation.cmake
M cmake/test_ada/cmake_working/Modules/CMakeAdaInformation.cmake
commit 5fde587a1d1b2bcd80c53b2ab4ea7ad593b84a7c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Nov 8 21:09:12 2015 -0800
Build system: Complete rewrite of file and target dependency logic for test targets
The test issue that lead me to open this whole can of worms was that
wxPLViewer was not being built as a necessary dependency for
wxwidgets tests for ENABLE_DYNDRIVERS=OFF. I was trying to use
target dependencies to force wxPLViewer to be built before the
wxwidgets target, but that idea obviously does not work correctly
for ENABLE_DYNDRIVERS=OFF since the wxwidgets target
does not exist for that case (i.e., the wxwidgets device driver
is part of the core plplot library in this case).
So the proper way to deal with this issue is to have wxwidgets
tests depend on the wxPLViewer target, but once I started reviewing
target dependencies of tests, I realized the CMake logic
implementing that had to be rewritten so that custom test targets
associated with interactive tests that normally do not have a
corresponding custom command should not have any DEPENDS and instead
add_dependencies should be used appropriately for that case. The
single "virgin" tests below also showed a large number of target
dependency issues that had to be addressed.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux. I
performed "virgin" tests (i.e., where the test target was built alone
starting from an empty build tree without any other test target
obfuscating whether the particular single target dependencies are
properly built or not) on a subset of the noninteractive tests and on
essentially all interactive tests for both the ENABLE_DYNDRIVERS=ON
and ENABLE_DYNDRIVERS=OFF cases. I also ran the following two
comprehensive tests:
scripts/comprehensive_test.sh --do_test_interactive no
scripts/comprehensive_test.sh --do_ctest no --do_test_noninteractive no
which is essentially equivalent to running
scripts/comprehensive_test.sh
M examples/CMakeLists.txt
M utils/CMakeLists.txt
commit 94850ccef599cbec7b582642c797c983c1d39ba2
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Nov 8 18:48:54 2015 -0800
plplottcltk library: GetEntries now returns NULL on failure
This change also gets rid of a warning about potential
uninitialized entries return from GetEntries.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
(Debian Jessie) using
examples/c/x19c -dev tk
(since example 19 is the specific example that exercises GetEntries in
the Tcl/Tk case) and the test_plserver_standard_examples and
test_wish_standard_examples targets.
M bindings/tcl/tclAPI.c
commit 76308e97c11dd781b60620c9af87694cca6d267b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Oct 24 14:09:51 2015 -0700
Build system: broaden search for itcl.h and itk.h
Debian Jessie stores these headers in /usr/include/itcl3 so calculate
SHORT_PLPLOT_ITCL_VERSION (= 3 in the Jessie case) and include
PATH_SUFFIXES itcl${SHORT_PLPLOT_ITCL_VERSION} in the search.
M cmake/modules/tcl-related.cmake
commit 03b4f656dedf626453e8599a1ae6bb23c2b35528
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Oct 24 13:53:36 2015 -0700
Fix build system bug which left pkg_config_QT_LIBRARIES undefined
This variable must be defined for the core build case in order to configure Makefile.examples
to link qt_example correctly for the traditional build of the
installed examples.
M examples/c++/CMakeLists.txt
commit 893625ca34ed22f4d8941f9902aa71bf30eaf8fb
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Oct 24 13:30:10 2015 -0700
Build system: Disable OCAML_HAS_CAIRO
I have taken this step because substantial maintenance will be
required before this component of PLplot will configure, build, or run
again because of backwards incompatibilities that have been introduced
in ocaml support of cairo. For example, the package name "cairo2" no
longer exists any more and should probably be replaced by the package
name cairo, but that is just the start of the backwards
incompatibilities.
M cmake/modules/ocaml.cmake
commit 37ddc8c984ffefd49b5bab09fae67629165cc871
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Oct 24 13:20:03 2015 -0700
Build system: broaden search for hd5f.h
Debian Jessie stores hd5f.h in /usr/include/hdf5/serial so broaden
the search for that header to include that location.
M cmake/modules/octave.cmake
commit aa80392bdc82aa90f7b6a4b2a262800d176749e9
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 16 12:41:02 2015 -0700
Device drivers and core library: update centralized default settings for plspage
Used more rationalized names for plspage default values and propagated
those to the cgm, gd, and wxwidgets devices that currently use
centralized default setting.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux by
building against epa_built gtk+ version 3 and wxwidgets (so that I can
build and test wxwidgets) and also using the configuration options
-DDEFAULT_ALL_DEVICES=ON -DPLD_plmeta=OFF to allow building all
devices. After building all devices and examples with "make -j4 all",
I ran the second example for the cgm, png (from gd device driver), and
wxwidgets devices for a variety of -geometry and -dpi values.
All three of these devices have length units of pixels. So for my
monitor whose actual dpi value of 90 matches the default assumed by
PLplot, the actual default sizes of these three devices should be A5,
and I have confirmed that which is the principal desired result
for using centralized default settings for plspage.
If I specify -geometry the size changes as expected for -dev wxwidgets
and -dev gd, but there is some bug in cgm where the size remains the
default but the resolution decays.
If I specify a -dpi value, the character size changes as expected for
wxwidgets since the character size specified in mm should be converted
to pixels using this dpi value. However, an unexpected result is both
-dev cgm and -dev png results seem unaffected by -dpi value. I don't
completely understand the code paths that are used for the pure
Hershey text processing used for -dev cgm or the plfreetype unicode
processing used for -dev png. However, one explanation of these
results is there are dpi-related bugs in these code paths.
M drivers/cgm.c
M drivers/gd.c
M drivers/wxwidgets_dev.cpp
M include/plplotP.h
commit a095365a14a5168b84568985f97d4405dd538deb
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 16 11:11:44 2015 -0700
DocBook documentation: Drop cgm device driver from the discussion of the plfreetype approach
When recently updating the documentation of the plfreetype approach I
forgot that the cgm device driver uses Hershey fonts alone and does
not use the plfreetype approach despite its other similarities with
the gd device driver. Correct that by dropping cgm from the discussion
of the plfreetype approach.
M doc/docbook/src/advanced.xml
commit 2027d895efc3e62874934eb15946f7dac01f7d66
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 16 10:33:28 2015 -0700
Build system: refine what gets dropped when -DDROP_GTK_PLUS_2_BUILDS=ON
The purpose of -DDROP_GTK_PLUS_2_BUILDS=ON is to drop GTK+ version 2
components from a GTK+ version 3 build on those platforms (e.g., where
epa_build has been used to provide GTK+ version 3 libraries but the
system libraries are still GTK+ version 2) where both GTK+ versions 2
and 3 are available.
This fix refines what is dropped. Previously, anything having to do
with xcairo was dropped, e.g., the xcairo device and the
extXdrawable_demo application. The extXdrawable_demo is indeed a pure
GTK+ version 2 application, but when GTK+ version 3 is available the
xcairo device is pure GTK+ version 3. So for
-DDROP_GTK_PLUS_2_BUILDS=ON do not allow extXdrawable_demo to be built
but do allow the xcairo device to be built.
M cmake/modules/cairo.cmake
M examples/c/CMakeLists.txt
commit 4295f04ce093339c2925e78b75be2880c219edfc
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Sep 14 22:12:50 2015 -0700
DocBook documentation: Update description of both Hershey and unicode font methods
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux by
configuring using the cmake option -DBUILD_DOC=ON, building the
html form of the documentation using "make html", and looking at the
generated html pages where I changed the documentation using a browser.
M doc/docbook/src/advanced.xml
M doc/docbook/src/api.xml
M doc/docbook/src/plplotdoc.xml.in
commit 442f735dc2b41bd18d1d8fb8a9537169ccdee5a1
Author: Greg Jung <gvjung@gmail.com>
Date: Sat Sep 12 13:18:00 2015 -0700
Update FindwxWidgets to accommodate the next wxWidgets version
They are calling the wxWidgets in the git repository "3.1.0" whereas version
3.0.2 is the latest release. Update FindwxWidgets.cmake to accommodate the new package.
Tested by: Greg Jung <gvjung@gmail.com>, insofar as it doesn't break a current search.
M cmake/modules/FindwxWidgets.cmake
commit 8e97cb2b2fdc0245b5dc0ce99a9650f8c0758b7c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Sep 11 11:13:42 2015 -0700
Build system: Use the official version of the freetype find module
Previously we used our own copy of the CMake-3.0.2 version of this
find module to benefit our cmake-2.8.x users, but this is pointless
now that our minimum version of CMake is 3.0.2 on Linux and higher on
other platforms. Furthermore, this change means our users benefit
from the bug fixing in the official version of the find module that
has occurred for cmake versions > 3.0.2 if they happen to be using
such versions of cmake.
D cmake/modules/FindFreetype.cmake
commit 2d0451ca8cc1c840ffc641930059a8699cccc13a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Sep 10 22:01:16 2015 -0700
Build system: Finish retiring wxpng device
To minimally (i.e., no source code changes) retire a device you have
to (a) comment it out of cmake/modules/drivers-init.cmake (already
done in commit 6f80549) and (b) modify
drivers/<device_name>.driver_info.in to remove the device from the
list of devices if there are some left as in the wxwidgets device
driver case. That change to finish retiring the wxpng device is what
was done in this commit.
This commit (and commit a6d2a439 to fix a wxwidgets build issue for
the Linux g++ compiler) allows wxwidgets-related PLplot software to
build again on Linux.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> by building
essentially all components (including wxwidgets-related components) of
PLplot on Linux. Since the minimum acceptable wxwidgets version is
3.0.0 which is not available as a system library on my Debian oldstable
platform, the build was configured to use an epa_built
wxwidgets-3.0.2 library using appropriate PATH, LD_LIBRARY_PATH, and
PKG_CONFIG_PATH environment variables to help CMake find that
epa_built version of wxwidgets, and its epa_built gtk+ library
dependencies while using
export NO_AT_BRIDGE=1
to quiet spurious dbus run-time warnings concerning the epa_built gtk+ libraries.
The CMake (3.2.3) special configuration options were
-DBUILD_TEST=ON
-DDEFAULT_ALL_DEVICES=ON
-DPLD_plmeta=OFF
-DDROP_GTK_PLUS_2_BUILDS=ON
to build all components of PLplot except for plmeta (which has a build
issue currently being investigated by Jim Dishaw). The
-DDROP_GTK_PLUS_2_BUILDS=ON option is necessary to drop gtk+ version 2
components of PLplot that are inconsistent with the epa_built gtk+
version 3 libraries. The actual build was done using
make -j4 all >& all.out
with no build issues (especially for wxwidgets) being reported.
M drivers/wxwidgets.driver_info.in
commit a6d2a43954a6d31f79b6d07d86cac6bf3537b682
Author: Greg Jung <gvjung@gmail.com>
Date: Thu Sep 10 15:21:27 2015 -0700
Cast PLUNICODE to wxChar32 while calling wxUstring
DrawTextLine converts the 32 bit ucs4 encoded string into a wxString.
Some Linux compilers refused to make the cast to one of the several
possible inputs to the overloaded routine. wxUString( (wxChar32)
ucs4[i]) appears to resolve the issue.
M drivers/wxwidgets_dev.cpp
commit 62ee1290be6f1f65ad9a799e8a097b574adbfbfe
Author: Greg Jung <gvjung@gmail.com>
Date: Tue Sep 1 12:23:26 2015 -0700
Reformulate call to GetTextExtent using intermediate variable
We need to pass an address of the font, obtained through font.getExFont. Some compilers wont accept &(font.function()) as an argument.
M drivers/wxwidgets_dev.cpp
commit b4245b3f938b8a91dbcc681d97fda65e6e5b4101
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 9 14:24:16 2015 -0700
Build system: Bump minimum wxwidgets version to 3.0.0
This is necessary because Phil's recent commit 9dc7393d = "Rewrite of
the wxWidgets text processing methods" depends on wx/ustring.h which
is only available for wxwidgets-3.0.0 and later.
M cmake/modules/wxwidgets.cmake
commit 6f8054955ee8242be99a9cf2b7b8d9bb21d56a1b
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 9 13:02:31 2015 -0700
Build system: retire wxpng device
I have decided to retire this device (at least for the forseeable
future) because it never worked correctly, breaks the current build
(if the user specifies -DPLD_wxpng=ON or -DDEFAULT_ALL_DEVICES=ON),
and currently Phil is currently working on other more important
wxwidgets issues (see his comment in
<http://sourceforge.net/p/plplot/bugs/161/>). However, leave the code
in place as a reminder just in case someone wants to work on creating
file device results from the wxwidgets platform.
M cmake/modules/drivers-init.cmake
commit 4a2de077363b13185eb337f8be2931874f1b18c5
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Sep 9 12:31:26 2015 -0700
Style previous commits.
M drivers/wingcc.c
M drivers/wxwidgets.h
M drivers/wxwidgets_comms.h
M drivers/wxwidgets_dev.cpp
M utils/wxplframe.cpp
commit 33735bb7acd9a3f1fc96ffc9c4de9379d5e3ec5f
Author: Jim Dishaw <jim@dishaw.org>
Date: Sun Sep 6 19:49:22 2015 -0400
Revised wingcc_dev struct to be compatible with an earlier version
The wingcc_dev struct was modified by removing the "PLGraphicsIn gin" member,
which was inserted mid-2014. The gin member broke compatibility with the GNU
Data Language project that was relying on the previous struct layout. That
member was not needed and has been removed from the wingcc_dev struct.
M drivers/wingcc.c
commit ac0f09f9b69bcdc7812cfcda6c5902d8539da62a
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Sep 3 16:37:34 2015 -0700
Build system: use check_symbol_exists rather than check_function_exists to find snprintf or _snprintf
This change works on Linux (tested below) and is also apparently
required for the VC14 (a.k.a Visual Studio 2015) platform because
certain io functions have been inlined for that platform. See
comments for
<http://public.kitware.com/Bug/bug_relationship_graph.php?bug_id=15659>
which suggest that check_symbol_exists and not check_function_exists
should be used to check for the existence of functions that might be
inlined.
M cmake/modules/plplot.cmake
commit ecd52bec3bb04c2e58520dac4e7c4d72568005a5
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Sep 3 16:28:33 2015 -0700
Build system: improve control of CMAKE_REQUIRED_* variables
Use the CMake macros cmake_push_check_state and cmake_pop_check_state
that are defined in the CMakePushCheckState module to control how
CMAKE_REQUIRED_* variables are set and retrieved for CMake check_*
function use. These changes should only affect our qhull and wxwidgets
components.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
using cmake on an initially empty build tree with good qhull and
wxwidgets configuration results obtained.
M cmake/modules/csiro.cmake
M cmake/modules/plplot.cmake
M cmake/modules/wxwidgets.cmake
commit c051d277a557cb82b826d5f44fd034116c97bd5f
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Sep 3 13:16:38 2015 -0700
Build system: style changes for cmake/modules/CheckDIRSymbolExists.cmake
These style changes mostly consisted of lowercasing the CMake command
names, but I also took this opportunity to improve the commentary
and output messages.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by running cmake. The relevant output from that run was
-- Looking for DIR symbol in sys/types.h;dirent.h
-- Looking for DIR symbol in sys/types.h;dirent.h - found
which is the expected result on that platform.
M cmake/modules/CheckDIRSymbolExists.cmake
commit c1bfcae19c8203368d5920c426c4d0eb24c4ed02
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Aug 26 14:11:53 2015 +0100
Fixed 3d text in wxWidgets driver - but with a fudge.
It seems that the rotated text code only uses device coordinates.
Because the wxWidgets driver reports the same device size (max int) in
each direction, this causes issues.
By contrast the rotated text uses mm sizes. Because we report different
device pixels per mm for x and y this worked fine.
To fix this we report identical pixels per mm in both directions then
make a correction to the rotation and shear angles in DrawText()
M drivers/wxwidgets_dev.cpp
commit 9dc7393d6bae89b1b002f35890317227b4d44e32
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Aug 25 19:44:22 2015 +0100
Rewrite of the wxWidgets text processing methods
The text processing routines were left unchanged in the recent driver
rewrite. The changes simplify the code, making it more readable. This
change fixes two bugs from the tracker:
subscript and superscript scales and offsets, however a multiple of
0.75 is made to the offset otherwise it doesn't match other devices
and just looks too large (it is 100% of the text height otherwise).
which copied the text into the memory buffer had been somehow delete so
wxPLViewer always saw an empty string.
In terms of restructuring. The text is dealt with in three stages, as
before, but the responsibilites of each stage are more clearly defined.
DrawText receives the full string. It sets up the dc state to be ready
to render text. It only sets up items that cannot be changed mid string.
It splits the string into lines and passes each line to DrawLine.
DrawTextLine converts the 32 bit ucs4 encoded string into a wxString. As
it does so it parses escape sequences and breaks the string at format
changes. Each of these sections is then passed to DrawTextSection.
DrawTextSection is dumb in that it has no concept of formatting. It
simply draws the text that it is tolde to, where it is told to draw it.
It has no concept of formatting such as superscript. It's only
responsibility is to select the font based on the given fci and size
and then draw the text/calculate the text size.
It should be noted that there is a commented out peice of code in
DrawText that corrects for aspect ratio of the plot based on the
assumption that plplot core code thought the plot was square. This fixes
3d text, but breaks regular 2d rotated text. The final solution of how
to deal with this needs further exploration of the core code to discover
why.
M drivers/wxwidgets.cpp
M drivers/wxwidgets.h
M drivers/wxwidgets_comms.h
M drivers/wxwidgets_dev.cpp
M utils/wxplframe.cpp
commit 68c02562a2adedaae7fd7c39791501f8fd1dc842
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Tue Aug 25 10:59:24 2015 +0100
Removed BOM from the beginning of the api.xml file
M doc/docbook/src/api.xml
commit 246eea01aed0256fea864eaf6296d2f78bb45319
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Aug 23 23:49:56 2015 -0700
Device drivers: Replace PLPLOT_DEFAULT_DPI with PLPLOT_DEFAULT_PIXPI
PLPLOT_DEFAULT_PIXPI is used to define the default 90 pixels per inch
used for devices with dimensions measured in pixels.
In addition define PLPLOT_DEFAULT_MMPI which is intended to be the
default 25.4 mm/inch used to determine the real-world units per inch
for devices with dimensions measured in real-world units (points =
1/72 inch, mm, cm, inches, etc.). Only in bizarre circumstances would
this default value be overridden by the user of these kinds of
devices.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by building the cgm, png (from gd device drivers), and wxwidgets
devices, and running example 2 for all those devices.
M drivers/cgm.c
M drivers/gd.c
M drivers/wxwidgets_dev.cpp
M include/plplotP.h
commit 4c9a2112d4944c4eeece31d3c9cd9ae2563cb8d0
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Sun Aug 23 11:36:05 2015 +0100
Removed PLStream::pageset
This varible was set by c_setpage to indicate that the page parameters
had been set, however calls to this function which use 0s do not set
parameters so when this variable is set there is actually no guarentee
that the page parameters are in a usable state. It turned out that this
parameter is not used in any plplot or driver code so given its lack of
usefulness I have deleted it.
M include/plstrm.h
M src/plcore.c
commit 4b4ebda8cb5d44bed6b886f41157d43c176e1525
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Aug 23 00:45:37 2015 -0700
Fix wxwidgets dpi/size bug
The issue was the if ( !plsc->pageset ) logic to decide whether
to set default (pixel) width and height since the -dpi option for
example, calls plspage and sets plsc->pageset even when width and
height are still at zero! So that logic is now replaced by correct
if ( pls->xlength == 0 || pls->ylength == 0 ) logic.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by building the second example and wxwidgets and then running
examples/c/x02c -dev wxwidgets -dpi 45.
which indeed doubles the size of characters as expected from the
rewritten dpi documentation. Before the current fix this test failed
with the error message
Gtk-CRITICAL **: IA__gtk_window_resize: assertion width > 0' failed
and blank black GUI screen for wxPLViewer.
M drivers/wxwidgets_dev.cpp
commit f9d726c07a19c4875bc6205b533c8fae774efbaa
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Aug 23 00:45:16 2015 -0700
Style previous commit
M include/plplotP.h
commit 338492fde81b7f73a3b1166c435e45e47f3cfe87
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sat Aug 22 13:53:14 2015 -0700
Build system and epa_build: Changes that make epa_built octave binding of PLplot work
The changes consist of the following:
1. Build system bug fix: replace all PATHS by HINTS in the find commands used to
find octave components. This insures a consistent find result when
searching for a special version of octave that is not in one of the
standard locations. This fix solves a segfault that otherwise occurs
when PLplot attempts to use the epa_built version of octave.
2. epa_build: Decrement octave version to 3.8.2 from 4.0.0. This may
not have been necessary to get a good result since the previous 4.0.0
segfaults for octave PLplot examples were likely due to issue 1.
Nevertheless, octave-4.0.0 is backwards-incompatible with octave-3.x.y
so the more conservative choice is to try octave-3.8.2 for now.
3. epa_build: update plplot and plplot_lite configurations to use
epa_built octave.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by building the test_noninteractive target in the build tree of
an epa_built plplot_lite that depends on epa_built octave.
There were no run-time issues at all, and the octave and C results for
the standard examples were identical.
M cmake/epa_build/octave_lite/CMakeLists.txt
M cmake/epa_build/plplot/CMakeLists.txt
M cmake/epa_build/plplot_lite/CMakeLists.txt
M cmake/modules/octave.cmake
commit 7f9a27279fabe6263dd3a40344a24675ffad8bce
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Sat Aug 22 21:45:30 2015 +0100
CHANGED THE WxWidgets driver to use the plplot default size.
M drivers/wxwidgets_dev.cpp
commit 5ef44d32eb3df126ebf4e03dc41d3127e5a8b51f
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Sat Aug 22 21:33:40 2015 +0100
Added default page sizes to plplotP.h
There are two defaults. One for drivers which have real world pages
(e.g. the postscript driver) which is specified in mm and one for
drivers which use pixel pages (e.g. the Cairo or the interactive
drivers). The mm page size is A4 as this is the most commonly used
metric paper size used. The pixel size is approximately A5 when scaled
using the default 90 dpi. This was chosen as it has the same aspect
ratio as the mm size, but fits comfortably on most computer screens.
M include/plplotP.h
commit d5ee62bb9dbad09d3b67c2682b3dfd31505990bc
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Sat Aug 22 21:14:47 2015 +0100
Documentation changed for plspage and setchr
After some discussion it has been agreed that we need to standardise the
text and page sizing accross drivers. These documentation changes now
ensure that the documentation accurately represents the required
behaviour for the drivers.
M doc/docbook/src/api.xml
commit 93f6677af1582a51a209df51bd70cb750818492d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Aug 21 14:31:31 2015 -0700
Build system: modernize support for our gd device driver
This change updates the find module and how those results are used to
support the gd device driver. These changes should allow those who
are still interested in this deprecated device to much more easily
diagnose any trouble in finding the GD library or headers.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
using the -DDEFAULT_ALL_DEVICES=ON option both for when the
GD library was not installed and when it was installed. In the
latter case, I also built the test_c_png, test_c_gif,
and test_c_jpeg targets without any obvious (segfault, etc.) run
time issues.
M cmake/modules/FindGD.cmake
M cmake/modules/gd.cmake
commit 3e430aebd4c88feed2271bafa12fe5865526f3bc
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Aug 21 13:04:04 2015 -0700
Set default DPI to be used by our device drivers
The PLPLOT_DEFAULT_DPI symbolic constant is #defined and initially
used in the cgm, gd, and wxwidgets device drivers. Use of the
PLPLOT_DEFAULT_DPI default DPI in additional device drivers is
requested if the choice is between some arbitrary default value for
the device driver that has been used in the past and
PLPLOT_DEFAULT_DPI.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
by building the cgm and wxwidgets devices.
M drivers/cgm.c
M drivers/gd.c
M drivers/wxwidgets_dev.cpp
M include/plplotP.h
commit 16a006f87f18643fef7f2893214c7882e8e9128f
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Thu Aug 20 21:28:09 2015 +0100
Restyle previous commits
M drivers/wxwidgets.h
M drivers/wxwidgets_dev.cpp
commit 92cd45cb182eb391b58047c69ccf4ce807e03b62
Author: Phil Rosenberg <p.d.rosenberg@gmail.com>
Date: Wed Jul 29 14:13:14 2015 +0100
Fix problem with wxFont affecting Ubuntu withwxWidgets 3.0
Creating a wxFont without a valid application in Ubuntu using wxWidgets
3,0 causes a crash. To work around this I have created a Font class
which encapsulates a wxFont and the plplot font metrics. This allows the
Font to be created and compared to other Fonts for caching puposes, but
the actual creation of a wxFont object is delayed until the wxFont is
requested. We can check for a valid wxDC bbefore we do thisavoiding the
problems.
M drivers/wxwidgets.h
M drivers/wxwidgets_dev.cpp
commit 04f7f48a3c41494d2d7e3d6bf7c27a9e6d2305e4
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Tue Aug 18 14:58:05 2015 -0700
Build system: Output pyqt4-related variables
Specifically those variables are SIP_EXECUTABLE, PYQT_SIP_DIR, and
PYQT_SIP_FLAGS which are all used to help generate the pyqt4 bindings
with sip.
M cmake/modules/qt.cmake
commit 83faf872e35ac991f8a04b6b94de9e3ebae458c7
Author: Arjen Markus <arjen.markus@deltares.nl>
Date: Tue Aug 18 13:45:53 2015 +0200
Correct the path to the DLLs for those platforms that require it.
-- tested under Cygwin by Arjen Markus
M plplot_test/plplot-test.sh.in
commit d13814734e8276c1b7403ef4a3aa3b39ef616f19
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Aug 17 22:57:28 2015 -0700
Improve comprehensive test script
The improvements were the following
(1) Collect values of any environment variable with PLPLOT somewhere
in the name, such as PLPLOT_DRV_DIR. In general such variables should not be set except
as a very last resort and only if you know exactly what you are doing, but there
is ancient advice that has been propagated to a lot of Windows users
to always set these variables so be sure to collect any such deprecated
settings if they exist since they generally screw up comprehensive
testing.
(2) Completely reorganize the order of tests. The previous order was
for shared, nondynamic, and static configurations do the following...
ctest in build tree
test_noninteractive in build tree
test_noninteractive in installed examples tree
traditional test_noninteractive in installed examples tree
test_interactive in build tree
test_interactive in installed examples tree
traditional test_interactive in installed examples tree
That order has now been revised to
for shared, nondynamic, and static configurations do the following...
test_interactive in build tree
test_interactive in installed examples tree
traditional test_interactive in installed examples tree
for shared, nondynamic, and static configurations do the following...
test_noninteractive in build tree
ctest in build tree
test_noninteractive in installed examples tree
traditional test_noninteractive in installed examples tree
Note that interactive results are kept in shared/interactive,
nondynamic/interactive, and static/interactive directory trees and
noninteractive and ctest results are kept in shared/noninteractive,
nondynamic/noninteractive, and static/noninteractive directory trees.
Therefore, there is no interference between the interactive and
noninteractive cases.
The large convenience advantage of the new order is it gets the interactive stuff (if
any) completely done first for all configurations. So all the user busy
work dealing with interactive tests is done immediately and all at
once rather than having to wait long times for noninteractive parts of
the tests to complete before there is a temporary burst of
interactivity.
The other advantage of the new order is that ctest
--extra-verbose output is problematic on some platforms (e.g., Cygwin) so you can get a
ctest error with no extra verbose explanation of the cause. The
test_noninteractive results are essentially a superset of the ctest
ones (although implemented quite differently with real dependencies)
with no known issues with verbose output. So the new order means you
should always get verbose output from test_noninteractive if one
of the non-interactive tests is failing. And only if
test_noninteractive succeeds in the build tree does the comprehensive test continue
with ctest in the build tree.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux using
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_xwin=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON"
to give a quick check of the reorganized script with both interactive
and noninteractive components. The script completed without issues,
and the table of contents of the resulting report tarball seemed to be
complete.
M scripts/comprehensive_test.sh
commit a1dd48fe6aca48ea932a193534c85a29c510085c
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Aug 17 15:04:35 2015 -0700
Fix static variable bug in svg device
The problem was due to using a static variable which_clip to keep track of
clip id's. This meant that
group file results (as generated by e.g., the Octave examples) had
different clip id numbers in the various files being generated
compared to individual file results (as generated, e.g., by the C
examples). So using -DPLPLOT_TEST_DEVICE:STRING=svg generated
differences for every example between the octave and other results.
I fixed this bug by making which_clip part of the SVG struct (which
automatically initializes that variable to 0 because the struct memory
is calloced). Here are the remaining ctest octave issues after this
fix for -DPLPLOT_TEST_DEVICE:STRING=svg
octave
Missing examples : 14a 31
Differing graphical output :
Missing stdout :
Differing stdout :
So this fix clearly makes the octave result much better, but is not
the full story for the octave examples (which give clean results for
the default psc device).
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
using the -DPLPLOT_TEST_DEVICE:string=svg cmake option and
make -j4 all >& all.out
ctest -j4 --extra-verbose --tests-regex '_c$|_cxx|_f95|_java|_octave|_python|_tcl|_ada|_ocaml|_lua|_d|_compare' >& ctest.out
The regex expression is to save time by doing only do the subset of
the ctests involving file comparisons of various bindings results with
the svg device.
This test gave clean results for all bindings other than octave (see
above) and ada, adathick, and ocaml, i.e.,
ada
Missing examples :
Differing graphical output : 08 19
Missing stdout :
Differing stdout :
adathick
Missing examples :
Differing graphical output : 08 19
Missing stdout :
Differing stdout :
ocaml
Missing examples :
Differing graphical output : 08 19 33
Missing stdout :
Differing stdout :
These issues (which are similar to but not exactly the same as the
equivalent test for the default -DPLPLOT_TEST_DEVICE:STRING=psc case)
are due to the ada and ocaml bindings and examples not being kept up
to speed with the bindings and examples for all other languages.
M drivers/svg.c
commit 4e165ef3019807916fa9b6d6158a238b9f6b8811
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Mon Aug 17 14:51:09 2015 -0700
Test system: improvements in the logic for setting up ctest
TEST_DEVICE --> PLPLOT_TEST_DEVICE
Preferred the "PLPLOT_" prefix on this important user-configurable
string detailing what file device to use for bindings comparisons.
Compacted the logic (and also dropped any maintenance burden) by using
FILE_DEVICES_LIST to figure out what tests to generate for the C
language.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux
using the -DPLPLOT_TEST_DEVICE:string=svg cmake option and
make -j4 all >& all.out
ctest -j4 --tests-regex '_c$|_cxx|_f95|_java|_octave|_python|_tcl|_ada|_ocaml|_lua|_d|_compare' >& ctest.out
The regex expression is to only do the subset of the ctests involving
file comparisons of various bindings results with the svg device.
The result showed severe file comparison problems for the Octave case
which will be dealt with later, but no issues with the logic changes
in how the ctest tests are configured.
M plplot_test/CMakeLists.txt
commit 2fb39ec6abf73ee896d0352e484988fc562283ac
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Sun Aug 16 16:31:56 2015 -0700
Traditional build system: fix linking to rt library
For ENABLE_DYNDRIVERS=OFF case, wxwidgets device code is part of
libplplot, and therefore that library must be linked to the rt
library. This linking issue has long since been solved for the CMake-based build
system case, and what the current fix does is propagate that rt
library linking fix to the configured pkg-config plplot.pc file and
therefore to the traditional build of the installed examples as well.
For some reason this linking issue for the traditional build has not
caused any problems on Debian wheezy, but it is hoped this fix will
solve a rt-related linking problem for the traditional build in the
static case that comprehensive testing by Greg Jung on the openSUSE
platform has turned up.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux using
scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DPLD_ps=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_wxwidgets=ON -DENABLE_cxx=ON" --do_test_interactive no
which merely proves the fix does no harm in the Debian wheezy case.
However, I also checked the pkg-config results now contain the -lrt
link flag, and also that flag (as expected) is used for the
traditional build of, e.g., the C examples so the fix is working as
designed with the only question remaining concerning this fix being
whether that design will completely fix the openSUSE issue.
M src/CMakeLists.txt
commit 2122b1e37f9bfd5345a856d79b3c670398c10cda
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Fri Aug 14 10:34:18 2015 -0700
Build system: libcsironn: libplplot: implement choice between qhull/qhull_a.h and libqhull/qhull_a.h form of include for qhull headers
Because libqhull uses common names for header files (e.g.,
io.h which is also a standard Windows header) the #include must be of
the form
where <unique_name> solves the name clash between qhull headers and
other headers. The qhull documentation recommends "qhull" for the
unique name, and most software distributions have adopted that, but
some of them (e.g., Cygwin and openSUSE) use "libqhull" instead for
the unique name. So this commit implements an automatic choice between those
two variants where both forms are looked for, and the one that is
found is used for compilations of libcsironn and libplplot.
Tested by: Alan W. Irwin <airwin@users.sourceforge.net> on Linux by
building the csironn and plplot targets for the "qhull" case that is
appropriate to my Debian Linux distro. N.B. Tests of this change for
distributions of software using the "libqhull" unique name convention
also need to be done.
M cmake/modules/FindQHULL.cmake
M lib/nn/CMakeLists.txt
M lib/nn/delaunay.c
M src/CMakeLists.txt
M src/plgridd.c
commit 40303210cb73637636c8f9d9fe5d4d1386bab47d
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Thu Aug 13 16:43:23 2015 -0700
Correct GTK+ spelling and mention MinGW-w64/MSYS2 platform on the home page of our website
M www/index.php
commit d6775bdc9b107c32803181dcf35fdf6d73069888
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Aug 12 12:02:07 2015 -0700
Prepare for the current (post-5.11.1) release cycle
M OLD-README.release
M README.release
commit 77a3dcd951abb04d65fef40adba79061db8eb158
Author: Alan W. Irwin <airwin@users.sourceforge.net>
Date: Wed Aug 12 11:55:50 2015 -0700
Last minute tweaks that did not make it into the 5.11.1 release tarball or tag
M README.Release_Manager_Cookbook
M README.release
Download Latest Version
plplot-5.15.0.tar.gz (15.4 MB)
