plplot-general — PLplot user discussion group

[Plplot-general] Status of the release of 5.12.0

[Alan W. I. <ir...@be...>]

The release date of December 27th is still uncertain because I am
still working on finishing a large documentation update I want
included in this release, and there is also one release-critical bug
for wxwidgets on the Linux platform where we have a potential fix, but
it needs some critical testing and evaluation by our development team
before we make the decision on December 27th to go with that fix for
the release or implement something else.

So on the 27th we will see where we stand for the release and make a
new estimate of its ETA then.

Meanwhile, Merry Christmas and Happy New Year! to everybody here.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] plotting date time axis

[Pedro V. <ped...@sp...>]

> I think the above loop is the source of the trouble because
> it assigns the same value to all elements of x.  That is,
> tinterval has to be multiplied by i.


yes, that was it, thanks

----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Pedro Vicente" <ped...@sp...>
Cc: <plp...@li...>
Sent: Monday, December 19, 2016 2:41 AM
Subject: Re: [Plplot-general] plotting date time axis


> On 2016-12-19 01:32-0500 Pedro Vicente wrote:
>
>> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
>> {
>> x[idx_orb] = tstart + tinterval;
>> }
>
> I think the above loop is the source of the trouble because
> it assigns the same value to all elements of x.  That is,
> tinterval has to be multiplied by i.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> 

Re: [Plplot-general] plotting date time axis

[Alan W. I. <ir...@be...>]

On 2016-12-19 01:32-0500 Pedro Vicente wrote:

> for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
> {
> x[idx_orb] = tstart + tinterval;
> }

I think the above loop is the source of the trouble because
it assigns the same value to all elements of x.  That is,
tinterval has to be multiplied by i.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] plotting date time axis

[Pedro V. <ped...@sp...>]

Hi all

I am trying to do a plot where the X axis has a date format.

I'm following the example x29.cc , but I am having some trouble figuring it 
out


this is my code


this example plots 19 points, between these 2 dates

pls->ctime(2016, 5, 30, 0, 0, 0, tstart);
pls->ctime(2016, 6, 1, 0, 0, 0, tend);


that is, 2016-05-30 and 2016-06-01

for the example, I calculate the time interval for the 19 points as

time_t tinterval = (tend - tstart) / NSIZE;

then the x points are made this way, the start time plus the interval

for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
{
x[idx_orb] = tstart + tinterval;
}


the plot is made in

pls->env(tstart, tend, 0, NSIZE, 0, 0);
pls->line(NSIZE, x, y);


however I don't get a date axis

the complete code:
thanks


pls->init();
pls->adv(0);
pls->scol0(0, 255, 255, 255);
pls->clear();
pls->scol0(1, 0, 0, 0);
pls->col0(1);

//data
const int NSIZE = 19;
PLFLT *x, *y;
x = new PLFLT[NSIZE];
y = new PLFLT[NSIZE];

//time
PLFLT tstart, tend;
pls->timefmt("%Y-%m-%d");
pls->ctime(2016, 5, 30, 0, 0, 0, tstart);
pls->ctime(2016, 6, 1, 0, 0, 0, tend);
time_t tinterval = (tend - tstart) / NSIZE;

for (int idx_orb = 0; idx_orb < NSIZE; idx_orb++)
{
x[idx_orb] = tstart + tinterval;
y[idx_orb] = idx_orb;
}

pls->env(tstart, tend, 0, NSIZE, 0, 0);
pls->line(NSIZE, x, y);
delete[] x;
delete[] y; 

[Plplot-general] Freeze for this release is now official + Fortran testing advice

[Alan W. I. <ir...@be...>]

This if official notice from your friendly release manager that the
freeze has just been declared for the 5.12.0 release that is scheduled
roughly 10 days from now.  So further changes during this test period
between now and release are going to be limited to non-intrusive bug
fixes (except for documentation updates).  We are currently chasing a
pretty serious wxwidgets device bug (an unexplained long pause where
everything is idle between one example using that device and the next
example during interactive testing) and a pretty serious wxwidgets
binding bug (our current code is making some incorrect assumptions
about when one particular wxwidgets event is going to fire) on Linux
so the actual release date is a bit uncertain.  However, I currently
hope to release PLplot-5.12.0 soon after Christmas, i.e., roughly 10
days from now depending on how that bug fixing goes and depending on
any other bugs that show up during this testing period.

If you are interested in what tests have already been run on what
platforms, I have just finished documenting those (most recently for
Cygwin, MinGW-w64/MSYS2, and Linux) for largely unconstrained
comprehensive tests at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
and
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Fortran%20Testing%20Reports>.

That latter summary table has been set up specifically for those here
who have an interest in any issues with the completely new Fortran
binding we will be part of this release.

So far those Fortran comprehensive test results are completely
reassuring.  For example, the NAGFOR compiler (notorious for being
picky about standards compliance) generates no errors or warnings for
our new Fortran binding and examples. But I urge those with an
interest in Fortran here to comprehensively test now on their
platforms (and in particular with their favourite Fortran compiler) to
make sure they will be able to use this new Fortran binding for this
release we are about to make.  Please
read the release notes in README.release for the git master branch
version of PLplot (that version will be turning into this release soon) for
all the Fortran caveats which are typically backwards
incompatibilities we have introduced to produce a really clean Fortran
interface.

N.B. an additional important caveat is this new Fortran binding
requires good standards-compliant support for the Fortran
iso_c_binding module upon which our new Fortran binding is based.  So,
for example, gfortran-4.9 and higher qualifies, but 4.9 is the minimum
version of gfortran that we can support because earlier versions do
not provide an iso_c_binding module with all the capabilities that we
need.  And I am sure there are similar stories for really old versions
of other Fortran compilers as well.

Anyhow, to find out about potential Fortran problems before as opposed
to after the release, please test the git master branch version of
PLplot with your favourite Fortran compilers now, using, e.g.,

# Select Fortran compiler you are going to test with
export FC=nagfor

# Run comprehensive test of the Fortran-related (and C for comparison
# purposes) parts of PLplot using that compiler.

time (nice -19 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

Send the report tarball (normally stored at
../comprehensive_test_disposable/comprehensive_test.tar.gz) to me.
That will allow me summarize that result at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Fortran%20Testing%20Reports>.
if that bash script finishes or advise you about how to constrain that
comprehensive test with further options to allow the script to
complete if you run into some issue with it.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] Fix for CMake error that was turning up on recent dashboards + comment on ctest error for those same dashboards

[Alan W. I. <ir...@be...>]

On 2016-12-14 10:42-0800 Alan W. Irwin wrote:

> Hi Hazen:
>
> A version check on libhpdf (implemented in cmake/modules/pdf.cmake) is
> an excellent idea.  [...] I will try to implement this check before the
> release if I have time, but no promises.

DONE as of commit e386818.  This should solve the reason for the recent
dashboard failures with test_c_pdf.

Thanks for this idea.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] Fix for CMake error that was turning up on recent dashboards + comment on ctest error for those same dashboards

[Alan W. I. <ir...@be...>]

On 2016-12-14 08:17-0500 Hazen Babcock wrote:

> On 12/14/2016 06:10 AM, Alan W. Irwin wrote:
>> Those tests also showed one ctest error for Ubuntu concerning the test
>> of our pdf device for C example 24. The fix for that has been known a
>> long time and has been accepted upstream by the libhpdf developers,
>> and even packaged experimentally downstream by Debian (see
>> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726069>), but that
>> package of the new 2.3.0 upstream version of libhpdf has for some
>> unknown reason never made it into Debian stable releases and also not
>> into Ubuntu releases.  So until those packaging issues are fixed,
>> Debian and Ubuntu users will always run into this PLplot ctest issue
>> unless they build that latest libhpdf version for themselves (like
>> I do for my own comprehensive tests).
>
> Based on my tests using docker images, I believe that this version of libhpdf 
> is currently only available in arch-linux, and is not available in any of 
> debian stable, debian latest, fedora latest, opensuse tumbleweed or ubuntu 
> latest. This might merit a check by cmake for the correct version? Otherwise 
> I think this test is going to fail for pretty much everyone.

Hi Hazen:

A version check on libhpdf (implemented in cmake/modules/pdf.cmake) is
an excellent idea.  I notice the hpdf headers on the 2.2.1 version
system headers #define the following version macros.

#define HPDF_MAJOR_VERSION 2
#define HPDF_MINOR_VERSION 2
#define HPDF_BUGFIX_VERSION 1

Those should make such a check easy to implement with the appropriate
try_compile logic.  I will try to implement this check before the
release if I have time, but no promises.  (i.e., if you want to help
out by implementing that, please let me know and go ahead!)

Meanwhile, until we implement such a version check, if users are stuck
with a version of libhpdf such that the test_c_pdf ctest fails on
example 24, then they should do the obvious thing to bypass the issue
which is to specify

--cmake_added_options "-DPLD_pdf=ON"

in order to help the comprehensive test script complete.  And
similarly for any other component of PLplot that they have to disable
in order to complete the test.  Of course, when the report tarball
from some tester shows such constraints were applied to the test I
will ask the tester about the motivation for the constraints if they
don't volunteer that information with their report tarball (e.g., "I
had to disable the pdf device because it failed on example 24").  I
need such constraint motivation information from testers to allow me
to footnote the constraint on the test properly at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>.

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] Fix for CMake error that was turning up on recent dashboards + comment on ctest error for those same dashboards

[Hazen B. <hba...@ma...>]

On 12/14/2016 06:10 AM, Alan W. Irwin wrote:
> Those tests also showed one ctest error for Ubuntu concerning the test
> of our pdf device for C example 24. The fix for that has been known a
> long time and has been accepted upstream by the libhpdf developers,
> and even packaged experimentally downstream by Debian (see
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726069>), but that
> package of the new 2.3.0 upstream version of libhpdf has for some
> unknown reason never made it into Debian stable releases and also not
> into Ubuntu releases.  So until those packaging issues are fixed,
> Debian and Ubuntu users will always run into this PLplot ctest issue
> unless they build that latest libhpdf version for themselves (like
> I do for my own comprehensive tests).

Based on my tests using docker images, I believe that this version of 
libhpdf is currently only available in arch-linux, and is not available 
in any of debian stable, debian latest, fedora latest, opensuse 
tumbleweed or ubuntu latest. This might merit a check by cmake for the 
correct version? Otherwise I think this test is going to fail for pretty 
much everyone.

-Hazen

[Plplot-general] Fix for CMake error that was turning up on recent dashboards + comment on ctest error for those same dashboards

[Alan W. I. <ir...@be...>]

The dashboards submitted by an anonymous user on December 10th and
11th showed a CMake error on Ubuntu which was due to a PLplot build
system bug which I just fixed.  Thanks for those reports! Whoever
submitted those dashboards should try doing so again.

Those tests also showed one ctest error for Ubuntu concerning the test
of our pdf device for C example 24. The fix for that has been known a
long time and has been accepted upstream by the libhpdf developers,
and even packaged experimentally downstream by Debian (see
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726069>), but that
package of the new 2.3.0 upstream version of libhpdf has for some
unknown reason never made it into Debian stable releases and also not
into Ubuntu releases.  So until those packaging issues are fixed,
Debian and Ubuntu users will always run into this PLplot ctest issue
unless they build that latest libhpdf version for themselves (like
I do for my own comprehensive tests).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] Freeze and release dates now much better determined + call for comprehensive testing

[Alan W. I. <ir...@be...>]

The freeze deadline is now chiselled in stone as December 17th, 3 days
from now. That deadline is just the end date for intrusive fixes for
this release, but as far as I know nobody is planning any more of those.
Of course, you should expect small bug fixes and large or small
documentation updates to continue through to the day of the release
which might be only December 22 (if our further comprehensive testing
doesn't turn up any release critical issues), or December 27th (if
there are some release-critical issues to address).

I personally have already finished my comprehensive testing with
completely satisfactory results on Debian Jessie with both CMake-3.0.2
and CMake-3.7.0 (see
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>).
So I am happy with the quality of what is going to become 5.12.0 right
now although more comprehensive test reports from you guys would be
appreciated to confirm that.

Note, the recommended way to do such testing now is

time (nice -19 scripts/comprehensive_test.sh --do_submit_dashboard yes --do_test_interactive no)

--do_test_interactive no makes your life much easier.

--do_submit_dashboard yes is optional.  It submits a dashboard
consisting of the ctest subset of the results to
<http://my.cdash.org/index.php?project=PLplot_git> to be displayed in
quite nice format without violating your privacy.  If nobody has
submitted a dashboard on the day you try this, and you would like to see
what they look like before submitting one yourself, there should
always be some good dashboard results on today's date, 2016-12-14, for
you to look at.

nice -19 allows your computer to be usable during this long test
(typically a couple of hours if the interactive part is turned off
like above).

time () provides a nice time summary of how long it took at the end.

The above comprehensive test creates a tarball (stored in
../comprehensive_test_disposable/comprehensive.tar.gz) report
collecting all sorts of information about the test such as what
environment variables you set that are relevant to the test, a
complete listing of the files that were created by the test,
CMakeCache.txt files, and lots of output results from various cmake
and make invocations made during the comprehensive testing.  Please
look at the contents of that tarball to satisfy yourself there is
nothing there that violates your privacy.  Then follow up by sending
me that tarball to help me diagnose what went wrong and help you to
avoid it if the script did not complete or else post a summary of your
comprehensive test report at 
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
with your permission when the script does complete (with a summary of
whatever components of PLplot you had to drop to obtain that desired
completion on your particular platform).

Note on Debian Jessie I got through the entire test with no such
issues at all, but other Linux platforms, and especially Windows and
Mac OS X platforms might not be as kind to you.  But that is the point
of the above reports; to find out the platform limitations of the
forthcoming PLplot-5.12.0 release, and your help in establishing those
limits on the platforms that are accessible to you would be much
appreciated.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] Bump in freeze date and new estimate for release date

[Alan W. I. <ir...@be...>]

As discussed on the plplot-devel list, we have encountered some
last-minute development needs so I have decided to bump the freeze
date to next weekend, December 17th to give us a chance to get a bit
more development matured enough to get merged into this release.  We
are also in the middle of a wxwidgets bug hunt that might lead to an
important fix for that component of PLplot as well.  There is still
quite a bit of uncertainty in that freeze date, but if we can stick to
it, then the actual release would be ~10 days later (to miss
Christmas) to give us ample opportunity to find and fix regressions
and minor bugs and update our documentation between freeze date and
release date.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] PLplot-5.12.0 is going to be released after a ~one-week test period that starts soon

[Alan W. I. <ir...@be...>]

On 2016-11-29 03:37-0800 Alan W. Irwin wrote:

> As PLplot release manager, my current release plan for 5.12.0 is to
> declare a freeze for merging in large developments into our git master
> branch as of this Saturday, December 3rd, which will give us a
> two-week test period (for running tests and debugging any issues that
> show up as a result of those tests) between then and the planned
> release date of December 17th.  I am warning ahead about those two
> significant dates that start and end the test period because I am
> hoping for lots of testing help from guys to make this release of
> 5.12.0 as high quality as possible.

Because of some of my own last-minute needs for getting a major topic
matured enough so that it is release-worthy, that freeze deadline has
now slipped to at least December 8th, and ultimately might slip to
December 10th, but that should be the latest allowed freeze date
because we do need at least a week of testing without major code
changes going on, and I really do want to stick with a release date of
December 17th.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] PLplot-5.12.0 is going to be released after a two-week test period that starts soon

[Alan W. I. <ir...@be...>]

On 2016-11-29 03:37-0800 Alan W. Irwin wrote:

> Anyhow, I hope to start seeing some preliminary test report tarballs
> from you guys soon with even more finalized reports later on a wide
> variety of platforms during our key two-week test period where we plan
> to keep PLplot changes as minimal as possible consistent with fixing
> the bugs you guys find as a result of these comprehensive tests.

To substantially reduce the testing time for these preliminary tests,
you can limit which components of PLplot are comprehensively tested by
use of the --cmake_added_options option.

For example, I recently had complete comprehensive testing success
with just our Tcl binding and examples using

scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON  -DDEFAULT_NO_BINDINGS=ON -DENABLE_tcl=ON" --do_test_interactive no

and with just our
f95 binding and examples (which are completely rewritten, by the way,
for this release, see README.release) using

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

I particularly encourage all our Fortran users to try the above test
to make sure the new Fortran binding and examples work perfectly for
their particular Fortran compiler.  As always, please send me the
report tarball for both failure and success.  If failure, that report
tarball helps me to diagnose any issues there might be or at least
identify the Fortran compiler that is failing, and if success, then
that report tarball gives me the details to report (with your
permission) that success at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Fortran%20Testing%20Reports>

Note, we have already had comprehensive testing success for our new
powerful Fortran binding and examples with the NAG fortran compiler
(self described as "valued by developers all over the globe for its
checking capabilities and detailed error reporting"), the ifort
compiler, and gfortran-4.9.2.  So I don't anticipate many more changes
are required for our new Fortran binding and examples.  But we have
had a bad report for gfortran-4.8.x apparently because that older
version of the compiler does not provide an iso_c_binding module (upon
which our new binding is based) of sufficient quality.  So you should
take gfortran-4.9.2 as the minimum version of gfortran that we
support, and if you are temporarily stuck with an older version, we do
provide the -DPL_DEPRECATED_f95=ON option which will give you access
to our old deprecated Fortran binding and examples for at least this
release, and probably a few more until with consultation with Fortran
users here we drop this currently deprecated code completely.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] PLplot-5.12.0 is going to be released after a two-week test period that starts soon

[Alan W. I. <ir...@be...>]

As PLplot release manager, my current release plan for 5.12.0 is to
declare a freeze for merging in large developments into our git master
branch as of this Saturday, December 3rd, which will give us a
two-week test period (for running tests and debugging any issues that
show up as a result of those tests) between then and the planned
release date of December 17th.  I am warning ahead about those two
significant dates that start and end the test period because I am
hoping for lots of testing help from guys to make this release of
5.12.0 as high quality as possible.

Those who would like to help with testing our git master branch (which
is going to end up as 5.12.0) might want to consider starting with
such testing now (assuming you have access to real Unices like Linux
and Mac OS X or Unix-like platforms such as Cygwin or MinGW-w64/MSYS2
which provide the executables such as bash that we need for
comprehensive testing).

The first order of business is to gain access to the PLplot git master
branch following the directions at
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>.  Then read
the release notes in README.release which documents the changes
made for 5.12.0.

After that, comprehensive testing is simple for humans but gives your
computer a real workout.  Essentially all you have to do is set up
the relevant environment variables that you normally use to build PLplot,
then run the bash script

scripts/comprehensive_testing.sh --help

and

scripts/comprehensive_testing.sh --do_test_interactive no

That first command gives you extensive documentation of the
capabilities of the script.  Often you leave almost everything as
default as in the second command which should provide a valuable
comprehensive test of the noninteractive parts of PLplot on your
computer platform.

I have had recent success with the above script with no options (i.e.,
both interactive and noninteractive comprehensive tests were run) on
Linux (Debian Jessie) so with any luck at all, you should be able to
replicate that success on other platforms as well at least for the
non-interactive portion of the tests.  You will likely want to wait
until you have complete noninteractive success before you run the
interactive component of the comprehensive tests because such
interactive tests necessarily mean you have to babysit the test as you
click on all the GUI's simply to get through all the interactive
exampes to finish the test. (The point of these interactive
comprehensive tests is to run through as many interactive examples as
possible to check for major run-time issues like segfaults so there is
a lot of boring clicking involved, and if you choose not to do that
and only provide non-interactive comperhensive test results that is
extremely valuable to us as well.)

The script creates a report tarball (normally stored as
../comprehensive_test_disposable/comprehensive_test.tar.gz) containing
the key results from your test which I ask you to send to me if the
script fails to finish so I can diagnose what went wrong for you. (I
also ask you to send that tarball to me if the script succeeds and you
give me permission to post the details of that success at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>.

Anyhow, I hope to start seeing some preliminaary test report tarballs
from you guys soon with even more finalized reports later on a wide
variety of platforms during our key two-week test period where we plan
to keep PLplot changes as minimal as possible consistent with fixing
the bugs you guys find as a result of these comprehensive tests.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] Possible move to github?

[Hazen B. <hba...@ma...>]

On 11/20/2016 06:57 AM, Alan W. Irwin wrote:
>
> @Hazen:
>
> Could you please check out the above possibility at github and test it
> by attempting some merge commits?  If that test confirms as expected
> such commits are rejected at github with the above setup, then that
> means any PLplot developer can use the PLplot github server in
> confidence that those results can be pushed to our definitive server
> at SF without any issues so long as the precautions mentioned in
> README.developers are followed.  Note the "definitive" designation
> means the server used by our release manager (currently me), and the
> git server we advertise on our website.

I have set this flag but I don't plan to test it. This is a just mirror 
and the only thing that will get pushed to Github master is whatever is 
in SF master, so it should by definition pass the SF repository criteria.

> By the way, I can honestly say you did a great job as release manager
> years ago (better than I am doing now in terms of how many releases
> per year you got out the door), and if you wanted to take on that role
> again (after I get 5.12.0 is out the door) that would give me more
> time to do PLplot development and testing which would make me quite
> happy. :-)

My apologies but I am not interested in being release manager again.

-Hazen

Re: [Plplot-general] CMake 3.7.0 corrupts pkg-config files

[Tom S. <tom...@me...>]

Hi Alan,


> On 20 Nov 2016, at 13:15, Alan W. Irwin <ir...@be...> wrote:
> 
> Hi Tom:
> 
> You obviously have a very keen interest in PLplot via your project at
> <https://github.com/tschoonj/gtkmm-plplot>.  Just out of curiosity,
> how soon do you expect to mature that project (i.e., support all
> PLplot C++ API).  And which of our plot capabilities do you personally
> expect to use the most once you have matured that project?
> 

I am actually quite pleased with its current functionality: it supports everything I need it to for my project (XMI-MSIM) that makes extensive use of it. 
Would the need arise I will definitely restart work on it (probably when Gtk4 is out). I will of course gladly accept pull requests from anyone willing to contribute code.

> More below in answer to your recent comments....
> 
> On 2016-11-20 10:07-0000 Tom Schoonjans wrote:
> 
>> Hi Alan,
>> 
>> 
>> Many thanks for your quick fix! It works fine: the pkg-config files are working fine now.
> 
> You are welcome.
> 
>> I would like to renew my request for a PLplot bug fix release
> though. Currently, 3 patches need to be applied to get the 5.11.1
> compiling and working properly with the latest CMake.
> 
> I assume this request is on principle and not for your own personal
> needs since you can readily use the git version.  Of course, I do
> agree with this principle of creating bugfix releases so I would like
> to grant this request, but I believe it is really too late in the
> current release cycle to do that. However, if I cannot convince Hazen
> to take over as release manager after 5.12.0 is out the door, then I
> promise to study what I need to do from the git perspective so that I
> will be well prepared to make a bugfix release after 5.12.0 if that
> becomes necessary.  But I am not at all well prepared now in this
> regard (I am not as familiar with git as I should be) so I prefer to
> avoid this distraction until after the release of 5.12.0 is completed.
> 

It is indeed mostly for my personal needs, but it’s a bit more complicated than that.
Most people that use PLplot, or any software package for that matter, use official releases, and not git master. 
Mostly because there is no guarantee that git master is API-stable or even reasonably bug free. git master is only meant for those that really need a particular cutting-edge new feature or so.

Apart from being an enthusiast user of PLplot, I am also a Homebrew maintainer, and I am the one who is currently maintaining the PLplot formula.
Given the popularity of Homebrew, it is probably fair to say that a large share (perhaps even the largest) of PLplot’s MacOS users, use Homebrew to install PLplot. Since Homebrew policy is to ensure that always the most recent releases of software packages are included, this sometimes means that tarballs need patching. Sometimes we get the patches from upstream, sometimes we produce them ourselves (and submit them upstream), but either way there is quite some time involved to get the formula up to date and working properly.
Homebrew is run by volunteers with little time to contribute so we are happy when no patches are required to get a formula up and running :-)
So in the case of PLplot, the formula currently requires two patches (from three commits I took from git master) to get it working for our (and your) users.

I am hoping you won’t take offense, but based on what you have told me so far I find it hard to believe that it is either too late or too complicated to make a bug fix release.
I don’t see how this is significantly different from:

git checkout plplot-5.11.1
git checkout -b plplot-5.11.2-bugfixes
git cherry-pick cac0198537a260fcb413f7d97301979c2dfaa31c 11c496bebb2d23f86812c753e60e7a5b8bbfb0a0 db396b9fbdc9cd54fb8545ea655185ca73a2a07e (+ any other bug fixes you think should be added here)
run tests
update changelog and commit
git tag plplot-5.11.2
make tarball and release

It is also certainly not too late: even if you would release 5.11.2 the day before releasing 5.12.0, that wouldn’t mean anything at all. No one would think less of PLplot or its developers. 
On the other hand, having a release out that cannot properly be built with the latest version of its build system for many months, while fixes are in git master, that may raise some eyebrows though :-)


Best regards,

Tom

>> Also, this kind of bug would have been detected easily with a
> continuous integration setup: that’s how I discovered this particular
> bug in fact.
> 
> I independently came to the same conclusion earlier today. This
> nameclash between our build system and the CMake code provided by the
> CMake official release (caused by the old CMP0054 CMake policy we are
> stuck with at the moment) should have (easily) been caught when
> CMake-3.7.0 was a release candidate. So to catch all such PLplot bugs
> early in the future (and/or to catch CMake regressions that affect
> PLplot in the CMake release candidate phase of their release cycle) we
> need to continously test the latest master branch version of PLplot
> that is built with the last tagged release of CMake, i.e., currently
> CMake-3.7.0, but presumably CMake-3.7.1 is coming fairly soon and
> CMake-3.8.0-rc1 will be coming slightly later, and they both will need
> to be tested this way when their time comes.
> 
> I plan to set up such continuous testing here with the results posted
> at my.cdash.org.  This should be trivial with PLplot's well-understood
> ctest facility.  (In fact, years ago I published ctest results as a
> one-time experiment at my.cdash.org to make sure the process worked
> and generating nightly test results instead and posting them at
> my.cdash.org should be no more difficult.) Because of that triviality
> and because the results are potentially so useful during a release
> process, this is something I hope to do soon so we can get some use
> out of this continuous testing at the tail end of this 5.12.0 release
> cycle.
> 
> By the way, my.cdash.org is a free service for a given project like
> PLplot with the limitation that only 3 different ctest users can
> publish results for a given project.  So once I set this up for
> ctesting on my Linux platform, I will be looking for two others (one
> on a Cygwin or MinGW-w64/MSYS2 platform and one on Mac OS X to get as
> wide platform coverage as possible) to publish nightly ctest results
> at my.cdash.org.
> 
> Alan
> __________________________
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
> 
> Linux-powered Science
> __________________________

Re: [Plplot-general] CMake 3.7.0 corrupts pkg-config files

[Alan W. I. <ir...@be...>]

Hi Tom:

You obviously have a very keen interest in PLplot via your project at
<https://github.com/tschoonj/gtkmm-plplot>.  Just out of curiosity,
how soon do you expect to mature that project (i.e., support all
PLplot C++ API).  And which of our plot capabilities do you personally
expect to use the most once you have matured that project?

More below in answer to your recent comments....

On 2016-11-20 10:07-0000 Tom Schoonjans wrote:

> Hi Alan,
>
>
> Many thanks for your quick fix! It works fine: the pkg-config files are working fine now.

You are welcome.

> I would like to renew my request for a PLplot bug fix release
though. Currently, 3 patches need to be applied to get the 5.11.1
compiling and working properly with the latest CMake.

I assume this request is on principle and not for your own personal
needs since you can readily use the git version.  Of course, I do
agree with this principle of creating bugfix releases so I would like
to grant this request, but I believe it is really too late in the
current release cycle to do that. However, if I cannot convince Hazen
to take over as release manager after 5.12.0 is out the door, then I
promise to study what I need to do from the git perspective so that I
will be well prepared to make a bugfix release after 5.12.0 if that
becomes necessary.  But I am not at all well prepared now in this
regard (I am not as familiar with git as I should be) so I prefer to
avoid this distraction until after the release of 5.12.0 is completed.

> Also, this kind of bug would have been detected easily with a
continuous integration setup: that’s how I discovered this particular
bug in fact.

I independently came to the same conclusion earlier today. This
nameclash between our build system and the CMake code provided by the
CMake official release (caused by the old CMP0054 CMake policy we are
stuck with at the moment) should have (easily) been caught when
CMake-3.7.0 was a release candidate. So to catch all such PLplot bugs
early in the future (and/or to catch CMake regressions that affect
PLplot in the CMake release candidate phase of their release cycle) we
need to continously test the latest master branch version of PLplot
that is built with the last tagged release of CMake, i.e., currently
CMake-3.7.0, but presumably CMake-3.7.1 is coming fairly soon and
CMake-3.8.0-rc1 will be coming slightly later, and they both will need
to be tested this way when their time comes.

I plan to set up such continuous testing here with the results posted
at my.cdash.org.  This should be trivial with PLplot's well-understood
ctest facility.  (In fact, years ago I published ctest results as a
one-time experiment at my.cdash.org to make sure the process worked
and generating nightly test results instead and posting them at
my.cdash.org should be no more difficult.) Because of that triviality
and because the results are potentially so useful during a release
process, this is something I hope to do soon so we can get some use
out of this continuous testing at the tail end of this 5.12.0 release
cycle.

By the way, my.cdash.org is a free service for a given project like
PLplot with the limitation that only 3 different ctest users can
publish results for a given project.  So once I set this up for
ctesting on my Linux platform, I will be looking for two others (one
on a Cygwin or MinGW-w64/MSYS2 platform and one on Mac OS X to get as
wide platform coverage as possible) to publish nightly ctest results
at my.cdash.org.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] Possible move to github?

[Alan W. I. <ir...@be...>]

On 2016-11-20 10:10-0000 Tom Schoonjans wrote:

> Hi Alan,

> Github supports exactly the workflow you want as shown in the
attached screen shot. All that needs to be done is uncheck all except
“Allow rebase merging”.

Hi Tom:

Thanks for letting us know about this ability of github to enforce our
rebase-only workflow.

@Hazen:

Could you please check out the above possibility at github and test it
by attempting some merge commits?  If that test confirms as expected
such commits are rejected at github with the above setup, then that
means any PLplot developer can use the PLplot github server in
confidence that those results can be pushed to our definitive server
at SF without any issues so long as the precautions mentioned in
README.developers are followed.  Note the "definitive" designation
means the server used by our release manager (currently me), and the
git server we advertise on our website.

By the way, I can honestly say you did a great job as release manager
years ago (better than I am doing now in terms of how many releases
per year you got out the door), and if you wanted to take on that role
again (after I get 5.12.0 is out the door) that would give me more
time to do PLplot development and testing which would make me quite
happy. :-)

And assuming you can prove to your own satisfaction that our
rebase-only workflow is enforced properly at github, then as release
manager you could designate the github server as the definitive one
which would make SF git server users like me responsible for pushing
our results to github (which again should be easy to do if the same
workflow is enforced by both servers).

By the way.  My understanding is github does not support file
releases, but that still means you can synchronize your local git
server with the github one, create the release tarball from that local
server version (as I do now where my local server is synchronized with
the SF one), and then follow up by using sftp to copy that tarball
release to SF (as I do now).  In other words, file releases are
completely independent of what git server is the designated as the
definitive one, but it makes sense for the definitive server to be the
one that the current release manager prefers for his convenience so
long as users are well-informed (e.g., on our website and on this
mailing list) which git server is definitive.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] Possible move to github?

[Tom S. <tom...@me...>]

Hi Alan,


Github supports exactly the workflow you want as shown in the attached screen shot. All that needs to be done is uncheck all except “Allow rebase merging”.

Best,

Tom


> On 15 Nov 2016, at 01:05, Hazen Babcock <hba...@ma...> wrote:
> 
> On 09/23/2016 06:29 AM, Tom Schoonjans wrote:
>> Moving the git repository to Github itself would be trivial. Just
>> use https://github.com/new/import, but I do recommend using the PLplot
>> organization as owner. Just add yourself to it first and get sufficient
>> privileges. Hazen I think you would be able to help out here since you
>> seem to be in charge of this organization.
> 
> I have transferred my personal PLplot github mirror to the PLplot organization (Hezekiah and are currently the only members):
> https://github.com/PLplot/PLplot
> 
> Now I would like to add some things into master that I think would be of some benefit to the project, but are primarily there specifically for Github.
> 
> (1) A README.md file. This would have a short project description as well as links to the SF site, the documentation, etc. as well as some badges (see (2) below).
> 
> (2) Some .yml files, for example, one to provide "continuous" testing using Travis-CI (.travis.yml).
> 
> Thoughts? Is this Ok?
> 
> -Hazen
> 

Re: [Plplot-general] CMake 3.7.0 corrupts pkg-config files

[Tom S. <tom...@me...>]

Hi Alan,


Many thanks for your quick fix! It works fine: the pkg-config files are working fine now.

I would like to renew my request for a PLplot bug fix release though. Currently, 3 patches need to be applied to get the 5.11.1 compiling and working properly with the latest CMake.

Also, this kind of bug would have been detected easily with a continuous integration setup: that’s how I discovered this particular bug in fact.

Best,

Tom




> On 20 Nov 2016, at 00:46, Alan W. Irwin <ir...@be...> wrote:
> 
> On 2016-11-15 03:37-0800 Alan W. Irwin wrote:
> 
>> On 2016-11-15 09:38-0000 Tom Schoonjans wrote:
>> 
>>> Hi all,
>>> 
>>> 
>>> I would like to report that the last official CMake release produces buggy and therefore useless PLplot pkg-config files.
>>> 
>> 
>> Thanks, Tom, for your report of this issue.  Is this report for the
>> official release of PLplot-5.11.1 or for the much later git master
>> branch version which is about to released as PLplot-5.12.0?  The
>> reason I ask is it is possible whatever the problem is has been fixed
>> in the git version.  But if you report that is not the case, I promise
>> to take a look at the issue (although likely late this week after I
>> have dealt with some other PLplot issues that are currently on my
>> plate).
> 
> Hi Tom:
> 
> I have now dealt with this issue (see commit db396b9).  Please look at
> that commit message for the detailed explanation.  Bottom line though,
> is we rely on sharp-eyed users or developers to pay close attention
> whenever there is a CMP0054 related warning because it is normally a
> sure sign that our CMake code is no longer working correctly (e.g.,
> this case) because of a subtle name clash.  In this case the variable
> called "c" was defined by CMake-3.7.0, and that nameclashed with our
> previous logic
> 
> if(BINDING STREQUAL "c")
> 
> As soon as we adopt a minimum version of CMake that is not in the dark
> ages, CMP0054 will automatically take on the NEW behaviour (anything
> in quotes within an if statement will not be dereferenced) and these
> nasty and completely unexpected nameclashes will be a thing of the
> past!
> 
> Alan
> __________________________
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
> 
> Linux-powered Science
> __________________________

Re: [Plplot-general] CMake 3.7.0 corrupts pkg-config files

[Alan W. I. <ir...@be...>]

On 2016-11-15 03:37-0800 Alan W. Irwin wrote:

> On 2016-11-15 09:38-0000 Tom Schoonjans wrote:
>
>> Hi all,
>>
>>
>> I would like to report that the last official CMake release produces buggy and therefore useless PLplot pkg-config files.
>>
>
> Thanks, Tom, for your report of this issue.  Is this report for the
> official release of PLplot-5.11.1 or for the much later git master
> branch version which is about to released as PLplot-5.12.0?  The
> reason I ask is it is possible whatever the problem is has been fixed
> in the git version.  But if you report that is not the case, I promise
> to take a look at the issue (although likely late this week after I
> have dealt with some other PLplot issues that are currently on my
> plate).

Hi Tom:

I have now dealt with this issue (see commit db396b9).  Please look at
that commit message for the detailed explanation.  Bottom line though,
is we rely on sharp-eyed users or developers to pay close attention
whenever there is a CMP0054 related warning because it is normally a
sure sign that our CMake code is no longer working correctly (e.g.,
this case) because of a subtle name clash.  In this case the variable
called "c" was defined by CMake-3.7.0, and that nameclashed with our
previous logic

if(BINDING STREQUAL "c")

As soon as we adopt a minimum version of CMake that is not in the dark
ages, CMP0054 will automatically take on the NEW behaviour (anything
in quotes within an if statement will not be dereferenced) and these
nasty and completely unexpected nameclashes will be a thing of the
past!

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] CMake 3.7.0 corrupts pkg-config files

[Tom S. <tom...@me...>]

Hi Alan,


This is occurring for both PLplot 5.11.1 and master.

Thanks for looking into this.

Best,

Tom

> On 15 Nov 2016, at 11:37, Alan W. Irwin <ir...@be...> wrote:
> 
> On 2016-11-15 09:38-0000 Tom Schoonjans wrote:
> 
>> Hi all,
>> 
>> 
>> I would like to report that the last official CMake release produces buggy and therefore useless PLplot pkg-config files.
>> 
> 
> Thanks, Tom, for your report of this issue.  Is this report for the
> official release of PLplot-5.11.1 or for the much later git master
> branch version which is about to released as PLplot-5.12.0?  The
> reason I ask is it is possible whatever the problem is has been fixed
> in the git version.  But if you report that is not the case, I promise
> to take a look at the issue (although likely late this week after I
> have dealt with some other PLplot issues that are currently on my
> plate).
> 
> Alan
> 
> __________________________
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
> 
> Linux-powered Science
> __________________________

Re: [Plplot-general] CMake 3.7.0 corrupts pkg-config files

[Alan W. I. <ir...@be...>]

On 2016-11-15 09:38-0000 Tom Schoonjans wrote:

> Hi all,
>
>
> I would like to report that the last official CMake release produces buggy and therefore useless PLplot pkg-config files.
>

Thanks, Tom, for your report of this issue.  Is this report for the
official release of PLplot-5.11.1 or for the much later git master
branch version which is about to released as PLplot-5.12.0?  The
reason I ask is it is possible whatever the problem is has been fixed
in the git version.  But if you report that is not the case, I promise
to take a look at the issue (although likely late this week after I
have dealt with some other PLplot issues that are currently on my
plate).

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] CMake 3.7.0 corrupts pkg-config files

[Tom S. <tom...@me...>]

Hi all,


I would like to report that the last official CMake release produces buggy and therefore useless PLplot pkg-config files.

Here are the contents of plplot-c.pc and plplot-c++.pc as produced on my Mac OS X (but I noticed the exact same problem on my MSYS2 installation too).

libdir=/usr/local/Cellar/plplot/5.11.1/lib
includedir=/usr/local/Cellar/plplot/5.11.1/include/plplot
drvdir=/usr/local/Cellar/plplot/5.11.1/lib/plplot5.11.1/drivers

Name: PLplot 
Description: Scientific plotting library (Double precision Core C library)
Requires.private: plplot
Version: 5.11.1
Libs: -L"${libdir}" -lplplot 
Libs.private: -L"${libdir}" -L"/usr/local/lib" -lltdl -L"/usr/lib" -lm -lcsirocsa -lqsastime /Applications/Xcode2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libc++.tbd
Cflags: -I"${included}"

libdir=/usr/local/Cellar/plplot/5.11.1/lib
includedir=/usr/local/Cellar/plplot/5.11.1/include/plplot
drvdir=/usr/local/Cellar/plplot/5.11.1/lib/plplot5.11.1/drivers

Name: PLplot C++
Description: Scientific plotting library (Double precision C++ binding)
Requires.private: plplot
Version: 5.11.1
Libs: -L"${libdir}" -lplplotcxx 
Libs.private: -L"${libdir}" -lplplot
Cflags: -I"${includedir}” 



Both files contain the line “Requires.private: plplot”, and therefore assumes the presence of a file plplot.pc, which does not exist.
Either way, using pkg-config now yields this error:

pkg-config --cflags plplot-c
Package plplot was not found in the pkg-config search path.
Perhaps you should add the directory containing `plplot.pc'
to the PKG_CONFIG_PATH environment variable
Package 'plplot', required by 'plplot-c', not found


If I switch back to CMake 3.6.3, only the files plplot.pc and plplot-c++.pc are created with contents:

libdir=/usr/local/Cellar/plplot/5.11.1/lib
includedir=/usr/local/Cellar/plplot/5.11.1/include/plplot
drvdir=/usr/local/Cellar/plplot/5.11.1/lib/plplot5.11.1/drivers

Name: PLplot 
Description: Scientific plotting library (Double precision Core C library)
Requires.private: 
Version: 5.11.1
Libs: -L"${libdir}" -lplplot 
Libs.private: -L"${libdir}" -L"/usr/local/lib" -lltdl -L"/usr/lib" -lm -lcsirocsa -lqsastime /Applications/Xcode2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libc++.tbd -L"/Applications/Xcode2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/7.3.0/lib/darwin" -lclang_rt.osx
Cflags: -I"${included}"

libdir=/usr/local/Cellar/plplot/5.11.1/lib
includedir=/usr/local/Cellar/plplot/5.11.1/include/plplot
drvdir=/usr/local/Cellar/plplot/5.11.1/lib/plplot5.11.1/drivers

Name: PLplot C++
Description: Scientific plotting library (Double precision C++ binding)
Requires.private: plplot
Version: 5.11.1
Libs: -L"${libdir}" -lplplotcxx 
Libs.private: -L"${libdir}" -lplplot
Cflags: -I"${includedir}"


Any thoughts on what’s going on here?

Thanks,

Tom

Re: [Plplot-general] Possible move to github?

[Alan W. I. <ir...@be...>]

On 2016-11-14 20:05-0500 Hazen Babcock wrote:

> On 09/23/2016 06:29 AM, Tom Schoonjans wrote:
>> Moving the git repository to Github itself would be trivial. Just
>> use https://github.com/new/import, but I do recommend using the PLplot
>> organization as owner. Just add yourself to it first and get sufficient
>> privileges. Hazen I think you would be able to help out here since you
>> seem to be in charge of this organization.
>
> I have transferred my personal PLplot github mirror to the PLplot 
> organization (Hezekiah and are currently the only members):
> https://github.com/PLplot/PLplot
>
> Now I would like to add some things into master that I think would be of some 
> benefit to the project, but are primarily there specifically for Github.
>
> (1) A README.md file. This would have a short project description as well as 
> links to the SF site, the documentation, etc. as well as some badges (see (2) 
> below).
>
> (2) Some .yml files, for example, one to provide "continuous" testing using 
> Travis-CI (.travis.yml).
>

Hi Hazen:

I don't mind you adding individual github-related files like you have
indicated above, but I do have some overall concerns with use of
github by PLplot developers. For example, as a major contributor to
PLplot, I really like our "no merge commit" workflow rules since it
leads to a clear history mere humans can understand on all master and
topic branches.  I am also satisfied with the service provided by our
SF git server and our configuration of that server so that it enforces
our workflow rules on the server side. Therefore, I currently plan to
stick with that server as our definitive git repository for now.

My primary concern is use of github would allow PLplot developers to
be sloppy about following our workflow rules leading to convoluted git
history that is impossible for humans to understand. However, if you
can reassure me that the github version also _enforces_ our workflow
rules like the SF server does (or you plan to configure the github git
server for PLplot that way soon) that would clearly answer this
concern. That github workflow enforcement would make it trivial to
push github master branch updates to our definitive SF git server
following exactly the workflow documented in README.developers that
any PLplot developer with a local git repository follows now.  But if
you don't have that github enforcement, then the github master branch
history will inevitably get filled with merge commits making it
impossible to push that branch to the SF server.

In sum, it would be a positive thing to establish a github git server
for PLplot that enforces our workflow rules on the server side since
that insures workflow discipline for all those using that repository
and would be a step towards the possibility that we might move our
definitive git repository to github. (Or at least it gives us that
option in the future if we ever get dissatisfied with the SF git
service).  But without that workflow enforcement, I believe a github
repository for PLplot would not be very practical for many of us to
use because of the "merge commit" and bad history reasons stated above.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________