plplot-devel — Technical discussion about PLplot development

[Plplot-devel] Current status of the PLplot-5.15.0 release process

[Alan W. I. <Ala...@gm...>]

Here is the current status of the PLplot-5.15.0 release process.

N.B. the freeze on pushes of source code or build system changes I
declared yesterday will continue until this release process is completed.

I have assessed Arjen's recent MSYS2 comprehensive test and posted
that assessment off-list to him.  I have also completed a
comprehensive test of my own on my Linux (Debian Testing) platform,
and summaries of both comprehensive tests have been added to our wiki
(see commits plplot-5.14.0-43-g15ffb9d10 and
plplot-5.14.0-44-g9c113444c and the new table entries at
<https://sourceforge.net/p/plplot/wiki/Testing_Reports/>).

The most important result of these comprehensive tests on MSYS2 and
Linux is that no release-critical issues have been detected on either
platform.  Therefore, the release process for PLplot-5.15.0 continues
with an ETA some time later this week.

Alan
__________________________
Alan W. Irwin

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-devel] Testing of the next PLplot release

[Alan W. I. <Ala...@gm...>]

On 2019-05-22 07:07-0000 Arjen Markus wrote:

>>> AM: I have attached last night's tarball hoilding the result of the comprehensive test. At a first casual glance, all is well. I do not think I will have time before Friday to redo the installation and the testing, so let's use this result.

Hi Arjen:

Thanks for that timely test result for MSYS2 when you had a lot of
other stuff on your plate.  I agree the initial impression of this
result looks good.  Therefore, assuming a deep look (which I plan to
do after I get some sleep) reveals no release-critical issues, I plan
to follow up by releasing 5.15.0 as quickly as possible this week.

My thanks again for your testing help.

Alan
__________________________
Alan W. Irwin

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-devel] Testing of the next PLplot release

[Arjen M. <Arj...@de...>]

Hi Alan,

See my answers below.

Regards,

Arjen

-----Original Message-----
From: Alan W. Irwin <Ala...@gm...>
Sent: 21 May 2019 22:12
To: Arjen Markus <Arj...@de...>
Cc: 'Phil Rosenberg' <p.d...@gm...>; PLplot development list <Plp...@li...>
Subject: RE: Testing of the next PLplot release

On 2019-05-21 07:05-0000 Arjen Markus wrote:

>>> AM: If you ask for "git" via "pacman -Ss git", youget a long list of packages that are maintained via git and therefore have "git" in their name. The only package that I could find which was about git itself, was "msys/git". And indeed, that works.

In principle, we should depend on as few packages from the msys repo as possible.  So to finish this discussion could you please use the normal pacman technique (I cannot recall the details, but you have used it before) to list all installed AND uninstalled packages that contain the file git.exe?  That's the definitive test of whether there is a package containing git.exe from the mingw repo.  Of course, if such a package doesn't exist, then git.exe from the msys version of the git package appears to be working well.

>>AM: I have tried finding out what package contains git.exe, but the command for that (pacman -Ql or pacman -Sl) fails - either the package or the repository is not found.
From the packages listed via "pacman -Ssy git" I see two possible candidates:

mingw64/mingw-w64-x86_64-git-repo 0.4.20-1 (mingw-w64-x86_64)
    The multiple Git repository tool (mingw-w64)

msys/git 2.21.0-1 (VCS) [installed]
    The fast distributed version control system

I have the second one installed as that seemed the most likely to be the correct one.

>>> AM: I turned it (python) off because I had seen a compile error with SWIG. When I tried it yesterday in the straightforward build, all was well and I have Qt drivers, including qtwidget. So I intend to allow Python again for the comprehensive testing.

Good.

>>> AM: Just an aside: while the programs you get with MinGW-w64/MSYS2 do not depend on the installation of MinGWw-w64/MSYS2 and can there in principle be run outside the mingw64 shell, there are dependencies on various run-time libraries: the C examples depend on libwinpthread-1.dll, libshp-2.dll, libfreetype-6.dll, libqhull.dll and possibly others (I just listed the ones mentioned in message boxes I got when trying to run a sample program). For the Fortran examples I got a dependency on libgfortran-4.dll, libfreetype-6.dll and libshp-2.dll. So deployment is not entirely as simple as all that.

I don't want to beat this to death, but my point was all those dll's you mentioned as dependencies are all native, i.e., they do not depend on any special msys2.dll that turns an ordinary Windows environment into something unique/non-native.  So I am virtually positive any PLplot executable or library that is linked to them should just work (e.g., in an ordinary Windows CMD environment) so long as the PATH is set to include the location of the MSYS2 native dll's that are built by PLplot or provided as dependencies of PLplot by the native mingw repo provided by MSYS2.  And even that PATH requirement disappears if you can figure out how to convince CMake to link a static PLplot against the static libraries provided by the mingw repo.

>>AM: That is personal frustration speaking 😉. It makes things difficult that you always have to hunt down the DLLs that a program depends on. On Windows these can be hidden deeply and a tool like dependency walker cannot always detect the right ones.
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Testing of the next PLplot release

[Alan W. I. <Ala...@gm...>]

On 2019-05-21 18:21-0000 Arjen Markus wrote:

>>> AM: Well, I did have wxWidgets installed, I was looking for the wrong file names. So, I rebuilt PLplot with "MSYS Makefiles", as that does enable CMake to find the wxWidgets library, but alas, the result is a run-time error: some discrepancy between the ABI in various libraries. See the attached screenshot.

For the record when you ran into this issue before (several years ago,
now) the screenshot back then said the following:

Mismatch between the program and library build versions detected. The
library used 3.0 (wchar_t,compiler with C++ ABI 1008,wx
containers,compatible with 2.8), and your program used 3.0
(wchar_t,compiler with C++ ABI 1010,wx containers,compatible with
2.8).

And the solution that worked back then was to adopt -fabi-version=8 (note the 8 matches
the 8 in ABI 1008 used to build the wxwidgets system library).

However, your latest screenshot has the following text:

Mismatch between the program and library build versions detected. The
library used 3.0 (wchar_t,compiler with C++ ABI 1013,wx
containers,compatible with 2.8), and your program used 3.0
(wchar_t,compiler with C++ ABI 1011,wx containers,compatible with
2.8).

where those 1013 and 1011 numbers are quite important showing that
currently the problem is your compiler is *older* than the one used to
build the system library (as opposed to the result in the past where
your compiler was *newer* than the one used to build the system
library).


Indeed, if you look at the report tarball you sent me ~5 days ago for this platform the
result is

-- cxx_compiler_library_pathname_list = C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/7.3.0/libstdc++.dll.a; [...]

i.e., you are using version 7.3.0 of g++ which is greatly out of date since (from
<http://repo.msys2.org/mingw/x86_64/>) the latest
g++ version provided by the mingw repo is 8.3.0-2.

So it appears your attempt to update your MSYS2 system in place did
not work for at least g++.  I have no clue why that issue occurred,
but I would never advise you to try an update in place again since you
could end up with no MSYS2 system working at all if something goes
wrong with that procedure.  Thus, the only solution I can recommend
for the current "old g++" issue is simply to install MSYS2 from
scratch.  (N.B. with a separate install prefix so you preserve your
current system just in case something goes wrong with that install
from scratch.)

> I would say that concludes most tests for this platform. What is left is the comprehensive testing and documenting what works and what does not work.

>From what you have said before, the install from scratch should be
trivial now since you have automated virtually everything for that
install.  However, time is of the essence since my current goal is to
release before this weekend (likely on Friday).  So if you don't have
time to do that install then I would be happy to settle for a
comprehensive test with wxwidgets disabled before that deadline.  So
do the other time pressures you have allow you to conform to that
deadline (with or without an install from scratch) or would you prefer I
delay the ETA beyond Friday?

In any case, the sooner you can give me a comprehensive test result
the better since it has been a long time since you have had complete
success with that script (where the the issues that are not release
critical have been bypassed).  So there is still a chance that your
forthcoming attempt at more complete testing that is allowed by such
bypasses will find a release-critical issue.

Alan
__________________________
Alan W. Irwin

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-devel] Testing of the next PLplot release

[Alan W. I. <Ala...@gm...>]

On 2019-05-21 07:05-0000 Arjen Markus wrote:

>>> AM: If you ask for "git" via "pacman -Ss git", youget a long list of packages that are maintained via git and therefore have "git" in their name. The only package that I could find which was about git itself, was "msys/git". And indeed, that works.

In principle, we should depend on as few packages from the msys repo
as possible.  So to finish this discussion could you please use the
normal pacman technique (I cannot recall the details, but you have
used it before) to list all installed AND uninstalled packages that
contain the file git.exe?  That's the definitive test of whether there
is a package containing git.exe from the mingw repo.  Of course, if
such a package doesn't exist, then git.exe from the msys version of
the git package appears to be working well.

>>> AM: I turned it (python) off because I had seen a compile error with SWIG. When I tried it yesterday in the straightforward build, all was well and I have Qt drivers, including qtwidget. So I intend to allow Python again for the comprehensive testing.

Good.

>>> AM: Just an aside: while the programs you get with MinGW-w64/MSYS2 do not depend on the installation of MinGWw-w64/MSYS2 and can there in principle be run outside the mingw64 shell, there are dependencies on various run-time libraries: the C examples depend on libwinpthread-1.dll, libshp-2.dll, libfreetype-6.dll, libqhull.dll and possibly others (I just listed the ones mentioned in message boxes I got when trying to run a sample program). For the Fortran examples I got a dependency on libgfortran-4.dll, libfreetype-6.dll and libshp-2.dll. So deployment is not entirely as simple as all that.

I don't want to beat this to death, but my point was all those dll's
you mentioned as dependencies are all native, i.e., they do not depend
on any special msys2.dll that turns an ordinary Windows environment
into something unique/non-native.  So I am virtually positive any
PLplot executable or library that is linked to them should just work
(e.g., in an ordinary Windows CMD environment) so long as the PATH is
set to include the location of the MSYS2 native dll's that are built
by PLplot or provided as dependencies of PLplot by the native mingw
repo provided by MSYS2.  And even that PATH requirement disappears if
you can figure out how to convince CMake to link a static PLplot
against the static libraries provided by the mingw repo.

Alan
__________________________
Alan W. Irwin

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-devel] Testing of the next PLplot release

[Arjen M. <Arj...@de...>]

Hi Alan,

Here is an update.

Regards,

Arjen

-----Original Message-----


That leaves the following issues:

>> * Use "MSYS Makefiles" to work around a wxwidgets cmake find bug for the "Unix Makefiles" case.

NOT TRIED YET.

>>AM: Not yet indeed, I seem not to have installed wxwidgets yet 😉.

>>AM: Well, I did have wxWidgets installed, I was looking for the wrong file names. So, I rebuilt PLplot with "MSYS Makefiles", as that does enable CMake to find the wxWidgets library, but alas, the result is a run-time error: some discrepancy between the ABI in various libraries. See the attached screenshot. I tried to get it working using the option -DCMAKE_CXX_FLAGS=-fabi-version=8 that I had used before, but the same error message popped up.

I would say that concludes most tests for this platform. What is left is the comprehensive testing and documenting what works and what does not work.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Testing of the next PLplot release

[Arjen M. <Arj...@de...>]

Hi Alan,

I have added my responses and findings below.

Regards,

Arjen

-----Original Message-----
From: Alan W. Irwin <Ala...@gm...>
Sent: 17 May 2019 23:21
To: Arjen Markus <Arj...@de...>
Cc: 'Phil Rosenberg' <p.d...@gm...>; PLplot development list <Plp...@li...>
Subject: RE: Testing of the next PLplot release

Hi Arjen:

See my review of your changes below.  Note depending on how quickly you can respond to the three minor issues that are left, we might have a release by early next week so I am sharing this post with the PLplot development list so other developers will also be aware that release is coming soon.

By the way, for all developers here I am declaring a push freeze on code or build-system changes unless it is a specific response to a bug that we discover in the next few days.

Note, that freeze still allows you to update our DocBook-generated documentation.

On 2019-05-17 07:31-0000 Arjen Markus wrote:

> Hi Alan, Phil,
>
> I made some progress - see the attached tarball.

>> -----Original Message-----
>> From: Alan W. Irwin <Ala...@gm...>
>> Sent: 16 May 2019 12:20
>> To: Arjen Markus <Arj...@de...>
>> Cc: 'Phil Rosenberg' <p.d...@gm...>
>> Subject: RE: Testing of the next PLplot release
>>
>> That leaves just the following issues:
>>
>> * Specify -DENABLE_java=OFF to avoid non-MSY2 java being found (which in turn causes run-time errors).

DONE.

>>
>> * Find MSYS2 perl rather than the Cygwin version.  (The CMAKE_PREFIX_PATH trick may also have
>>   solved this issue.)

SOLVED.

>> * Install git (from the "mingw" repository for MinGW-w64/MSYS2).

LIKELY SOLVED.

The git you are using (from CMakeCache.txt) is

GITCOMMAND:FILEPATH=C:/msys64/usr/bin/git.exe

which is from the msys repo rather than the mingw repo.  However, that git clearly works (as you can see from the first few lines of comprehensive_test.sh.out) so I think it is OK.

>>AM: If you ask for "git" via "pacman -Ss git", youget a long list of packages that are maintained via git and therefore have "git" in their name. The only package that I could find which was about git itself, was "msys/git". And indeed, that works.

>> * Specify -DENABLE_ada=OFF (for now).

DONE.

That leaves the following issues:

>> * Use "MSYS Makefiles" to work around a wxwidgets cmake find bug for the "Unix Makefiles" case.

NOT TRIED YET.

>>AM: Not yet indeed, I seem not to have installed wxwidgets yet 😉.

>> * Fix our build system to find the ".exe" version of lua.

> [out of order] But lua is still presenting the problem we have seen last year (I updated it, but to no avail):

> One possible workaround for this is
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fmsys2%2FMINGW-packages%2Fissues%2F949&amp;data=02%7C01%7C%7C9
> e4efd85aac14134bb2508d6db0d7ffa%7C15f3fe0ed7124981bc7cfe949af215bb%7C0
> %7C0%7C636937248363105436&amp;sdata=G%2FK%2BBoN9YABlwFrgM6fRybkGikd9UM
> So6M5a2YZAHHk%3D&amp;reserved=0, but I do not know how well this will
> work (I probably need to move the lua.exe executable to a different
> location or rename it or some such trick)

That's an ugly workaround, and it looks even uglier if you follow the link to further discussion.  So I don't think we should even attempt to use it, and instead until this upstream general Windows issue for lua is correctly solved, and that fix becomes part of MSYS2, we should simply specify -DENABLE_lua=OFF.  (And similarly for the Cygwin case if you run into the same issue there.)

>>AM: That saves a lot of messing about 😉. I was not particularly fond of this workaround, as there might be considerable confusion between a script file lua and an executable lua.exe - on Windows the file extension does play a role in how things are started and I am not sure how MinGW-w64/MSYS2 handles that.

* Python currently disabled.

I assume you did that because of some pyqt5 issue.  Instead, I suggest you use -DENABLE_pyqt5=OFF to allow ordinary python testing.

>>AM: I turned it off because I had seen a compile error with SWIG. When I tried it yesterday in the straightforward build, all was well and I have Qt drivers, including qtwidget. So I intend to allow Python again for the comprehensive testing.

In sum, use the "MSYS Makefiles" generator, disable lua, and be more specific about what python component you disable, and you will likely (since all this has worked before) be completely done with testing this platform for the release.

By the way.  With regard to that release I consider that
MinGW-w64/MSYS2 is our primary Windows platform because it gives access to almost all the same PLplot-relevant free software as Cygwin, but with the very large advantage that that software is in Windows native form (i.e., no dependence on a special DLL).  Furthermore, I am at a reasonable stopping point on my current PLplot development topics.
Therefore, I don't plan to push those topics until after the release of 5.15.0, and I currently plan to make that release just a few days after you finalize your MinGW-w64/MSYS2 testing.  This means that we will release without finalizing testing of our secondary Windows platforms (Cygwin and MSVC), but I am OK with that especially because you have an opportunity to finish off that secondary platform testing just after the release.  Is that plan OK with you are do you prefer we wait to release until you have finalized testing on those secondary platforms as well?

Assuming you are OK with that plan and the above three changes work for the MSYS2 case, then there is a reasonable possibility the release will be made early next week!

>>AM: Just an aside: while the programs you get with MinGW-w64/MSYS2 do not depend on the installation of MinGWw-w64/MSYS2 and can there in principle be run outside the mingw64 shell, there are dependencies on various run-time libraries: the C examples depend on libwinpthread-1.dll, libshp-2.dll, libfreetype-6.dll, libqhull.dll and possibly others (I just listed the ones mentioned in message boxes I got when trying to run a sample program). For the Fortran examples I got a dependency on libgfortran-4.dll, libfreetype-6.dll and libshp-2.dll. So deployment is not entirely as simple as all that.


DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Testing of the next PLplot release

[Alan W. I. <Ala...@gm...>]

Hi Arjen:

See my review of your changes below.  Note depending on how quickly
you can respond to the three minor issues that are left, we might have a
release by early next week so I am sharing this post with
the PLplot development list so other developers will also
be aware that release is coming soon.

By the way, for all developers here I am declaring a push freeze on
code or build-system changes unless it is a specific response to a bug
that we discover in the next few days.

Note, that freeze still allows you to update our DocBook-generated
documentation.

On 2019-05-17 07:31-0000 Arjen Markus wrote:

> Hi Alan, Phil,
>
> I made some progress - see the attached tarball.

>> -----Original Message-----
>> From: Alan W. Irwin <Ala...@gm...>
>> Sent: 16 May 2019 12:20
>> To: Arjen Markus <Arj...@de...>
>> Cc: 'Phil Rosenberg' <p.d...@gm...>
>> Subject: RE: Testing of the next PLplot release
>>
>> That leaves just the following issues:
>>
>> * Specify -DENABLE_java=OFF to avoid non-MSY2 java being found (which in turn causes run-time errors).

DONE.

>>
>> * Find MSYS2 perl rather than the Cygwin version.  (The CMAKE_PREFIX_PATH trick may also have
>>   solved this issue.)

SOLVED.

>> * Install git (from the "mingw" repository for MinGW-w64/MSYS2).

LIKELY SOLVED.

The git you are using (from CMakeCache.txt) is

GITCOMMAND:FILEPATH=C:/msys64/usr/bin/git.exe

which is from the msys repo rather than the mingw repo.  However, that git
clearly works (as you can see from the first few lines of comprehensive_test.sh.out)
so I think it is OK.

>> * Specify -DENABLE_ada=OFF (for now).

DONE.

That leaves the following issues:

>> * Use "MSYS Makefiles" to work around a wxwidgets cmake find bug for the "Unix Makefiles" case.

NOT TRIED YET.

>> * Fix our build system to find the ".exe" version of lua.

> [out of order] But lua is still presenting the problem we have seen last year (I updated it, but to no avail):

> One possible workaround for this is https://github.com/msys2/MINGW-packages/issues/949, but I do not know how well this will work (I probably need to move the lua.exe executable to a different location or rename it or some such trick)

That's an ugly workaround, and it looks even uglier if you follow the
link to further discussion.  So I don't think we should even attempt
to use it, and instead until this upstream general Windows issue for
lua is correctly solved, and that fix becomes part of MSYS2, we should
simply specify -DENABLE_lua=OFF.  (And similarly for the Cygwin case
if you run into the same issue there.)

* Python currently disabled.

I assume you did that because of some pyqt5 issue.  Instead, I suggest you
use -DENABLE_pyqt5=OFF to allow ordinary python testing.

In sum, use the "MSYS Makefiles" generator, disable lua, and be more
specific about what python component you disable, and you will likely
(since all this has worked before) be completely done with testing
this platform for the release.

By the way.  With regard to that release I consider that
MinGW-w64/MSYS2 is our primary Windows platform because it gives
access to almost all the same PLplot-relevant free software as Cygwin,
but with the very large advantage that that software is in Windows
native form (i.e., no dependence on a special DLL).  Furthermore, I am at
a reasonable stopping point on my current PLplot development topics.
Therefore, I don't plan to push those topics until after the release
of 5.15.0, and I currently plan to make that release just a few days after you
finalize your MinGW-w64/MSYS2 testing.  This means that we will
release without finalizing testing of our secondary Windows platforms
(Cygwin and MSVC), but I am OK with that especially because you
have an opportunity to finish off that secondary platform testing just
after the release.  Is that plan OK with you are do you prefer we
wait to release until you have finalized testing on those secondary
platforms as well?

Assuming you are OK with that plan and the above three changes work
for the MSYS2 case, then there is a reasonable possibility the release
will be made early next week!

Alan
__________________________
Alan W. Irwin

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-devel] git blog

[Alan W. I. <Ala...@gm...>]

On 2019-05-07 17:51-0600 Orion Poplawski wrote:

>> 
>> See commit plplot-5.14.0-38-g6b00b9717.
>> 
> Thanks.  Looks like someone filed a Fedora bug with a patch as well so I'm 
> all set now.  BTW - I have no idea how to find the above commit ID. It git 
> proper it seems to be 6b00b9717a6c98ee16e49f991957f91cb5b76c1f

For everyone here that is not aware of this way of describing git
commits, the "plplot-5.14.0" is the last tag (release) before the
commit, the "-38-" means the commit is 38 commits beyond that release,
the "g" is a delimiter, and 6b00b9717 is the first part of the actual
commit id.  Use

git help describe

to see more details about this way of describing commits.

Alan

__________________________
Alan W. Irwin

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-devel] swig 4.0.0 issues

[Orion P. <or...@nw...>]

On 5/7/19 3:27 PM, Alan W. Irwin wrote:
> On 2019-05-06 19:12-0600 Orion Poplawski wrote:
> 
>> FYI - swig 4.0.0 just landed in Fedora Rawhide and it looks like it 
>> broke plplot's python bindings:
> 
> Hi Orion:
> 
> Thanks for this report, but for once I am (slightly) ahead of you.  :-)
> 
> Try the latest git version where this issue has been fixed.
> 
> See commit plplot-5.14.0-38-g6b00b9717.
> 
> No promises at this stage, but I am hoping to stick to a 6-month
> release cycle, i.e., I hope to release plplot-5.15.0 (with this
> important fix, the Qt5 important font fix, and several others) within
> a month or so.

Thanks.  Looks like someone filed a Fedora bug with a patch as well so 
I'm all set now.  BTW - I have no idea how to find the above commit ID. 
It git proper it seems to be 6b00b9717a6c98ee16e49f991957f91cb5b76c1f

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Plplot-devel] swig 4.0.0 issues

[Alan W. I. <Ala...@gm...>]

On 2019-05-06 19:12-0600 Orion Poplawski wrote:

> FYI - swig 4.0.0 just landed in Fedora Rawhide and it looks like it broke 
> plplot's python bindings:

Hi Orion:

Thanks for this report, but for once I am (slightly) ahead of you.  :-)

Try the latest git version where this issue has been fixed.

See commit plplot-5.14.0-38-g6b00b9717.

No promises at this stage, but I am hoping to stick to a 6-month
release cycle, i.e., I hope to release plplot-5.15.0 (with this
important fix, the Qt5 important font fix, and several others) within
a month or so.

Alan
__________________________
Alan W. Irwin

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-devel] swig 4.0.0 issues

[Orion P. <or...@nw...>]

FYI - swig 4.0.0 just landed in Fedora Rawhide and it looks like it 
broke plplot's python bindings:

https://apps.fedoraproject.org/koschei/package/plplot?collection=f31

       Start  5: examples_python
5: Test command: /usr/bin/bash "-c" 
"EXAMPLES_PREFIX=/builddir/build/BUILD/plplot-5.14.0/fedora/examples 
SRC_EXAMPLES_PREFIX=/builddir/build/BUILD/plplot-5.14.0/examples 
OUTPUT_DIR=/builddir/build/BUILD/plplot-5.14.0/fedora/ctest_examples_output_dir 
VC_CTEST_DIRECTORY= ./plplot-test.sh --verbose --device=svg 
--front-end=python"
5: Test timeout computed to be: 15000
5: Testing front-end python
5: x00
5: x01
5: x02
5: x03
5: x04
5: x05
5: x06
5: x07
5: x08
5: x09
5: x10
5: x11
5: x12
5: x13
5: x15
5: x16
5: x18
5: x19
5: x20
5: call to python pltr function with 3 arguments failed
5: call to python pltr function with 3 arguments failed
5: call to python pltr function with 3 arguments failed
5: call to python pltr function with 3 arguments failed
5: call to python pltr function with 3 arguments failed
....

I haven't had a chance to investigate yet...

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

[Plplot-devel] A complete rewrite of the build system INSTALL_RPATH configuration logic has now been finished

[Alan W. I. <Ala...@gm...>]

This post is especially important for those Unix users who install
PLplot dependencies (such as libLASi) in non-standard locations and
who use the traditional build of our installed examples rather than
the CMake-based build of those examples.

DT_RPATH and its more modern variant DT_RUNPATH are two ways on Unix
systems to inform the run-time loader of non-standard locations of
shared libraries that are needed by applications.  Therefore, the
details of how our build system configures use of the INSTALL_RPATH
target property (which controls DT_RPATH on old Unix systems such as
Debian Jessie and DT_RUNPATH on more modern Unix systems such as
Debian Testing) become important for the traditional build of
installed examples if any external library (e.g., libLASi) needed by
any PLplot component is installed in a non-standard location.  (Note
that CMake-based builds automatically take care of all rpath concerns
so our CMake-based core build and CMake-based build of the installed
examples automatically work fine regardless of where our external
libraries are installed or the INSTALL_RPATH target property set for
them.)

Our INSTALL_RPATH configuration worked fine for our traditional builds
of installed examples on DT_RPATH platforms such as Debian Jessie and
was extensively tested in that era with epa_built external libraries
that were installed in non-standard locations.  However, that
configuration did not work correctly for DT_RUNPATH platforms such as
Debian Testing since it was not always consistent the following
additional constraint on the use of DT_RUNPATH that has been taken
from
<https://refspecs.linuxfoundation.org/elf/gabi4+/ch5.dynamic.html>:

   "The set of directories specified by a given DT_RUNPATH entry is
   used to find only the immediate dependencies of the executable or
   shared object containing the DT_RUNPATH entry. That is, it is used
   only for those dependencies contained in the DT_NEEDED entries of
   the dynamic structure containing the DT_RUNPATH entry, itself. One
   object's DT_RUNPATH entry does not affect the search for any other
   object's dependencies."

As a result PLplot's use of the new libLASi release (which necessarily
had to be built locally and with a non-standard install prefix) failed
for our traditional build.

To address this issue I have completely rewritten our rpath
configuration logic (see commits plplot-5.14.0-24-ge418008c8 through
plplot-5.14.0-29-g3b140b22f) to (i) be consistent with the above
additional DT_RUNPATH constraint, and (ii) have that configuration
done in a standardized way for all our installed targets (executables,
dll's (modules) generated by swig, ordinary dll's, shared libraries
and static libraries).  The result of this work is a substantial
reduction in the number of lines of CMake logic in our build system
(since virtually all of the INSTALL_RPATH logic is now taken care of
in the configure_executable_build and configure_library_build
functions) and the install of the new libLASi release is found and
used for traditional builds without issues.

Note that this new logic always uses transitive INSTALL_RPATH logic
for the static build case and by default uses non-transitive
INSTALL_RPATH logic for the shared library case (regardless of whether
the device drivers are dynamic or nondynamic).  And that default for
the shared library case works well for Debian Testing.  But if there
are still some Unix platforms out there that only work for transitive
INSTALL_RPATH logic for the shared library case, the user can choose
that logic by setting the -DNON_TRANSITIVE_RPATH=OFF cmake option.
And as always if the user (typicall a binary package maintainer)
specifies -DUSE_RPATH=OFF, the INSTALL_RPATH target property
(transitive or otherwise) will not be set at all for installed targets
with the result that DT_RPATH (old Unix systems) and DT_RUNPATH
(modern Unix systems) will not be set for those targets.

In sum, my recent comprehensive tests support the idea that our
INSTALL_RPATH configuration should "just work" now for the combination
of the traditional build of our installed examples and non-standard
installed locations of PLplot dependencies.  But if the run-time
loader errors out by saying it cannot find a library, the first thing
you should try is -DUSE_RPATH=ON (if you were not using that default
already) and the second thing you should try if this trouble occurs
for the shared build case is -DNON_TRANSITIVE_RPATH=OFF.

Alan
__________________________
Alan W. Irwin

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-devel] CMake minimum version bump and removing cmake/modules/FindwxWidgets.cmake

[Alan W. I. <Ala...@gm...>]

On 2019-01-31 13:01-0800 Alan W. Irwin wrote:

[...]
> So yes, I agree that it is time for us to drop our own version, and if
> we find the above patch is necessary on any Windows platform of
> interest to us we can always submit that change for inclusion into the
> upstream version.
>
> Meanwhile, the upstream version of this find module would likely fail
> for our users that are using cmake versions less than 3.9.0.  But that
> is not going to be an issue since I plan in any case today to bump the
> minimum version of cmake that PLplot accepts to a version of CMake
> that all modern Linux, Mac, and Windows free software distributions
> support.  That new minimum version will be 3.13.2 for Linux, but I
> still have to look at the Mac OS X distributions Fink, MacPorts, and
> HomeBrew, and the Windows distributions Cygwin, and MinGW-w64/MSYS2 to
> see if that or a higher version of CMake is available for all of
> those.

As of commit plplot-5.14.0-21-gc67d153a5 I have bumped our minimum
version of CMake to 3.13.2 and (as requested by Phil and agree with by
me) removed cmake/modules/FindwxWidgets.cmake.

@Arjen:

My apologies to you for the inconvenience this version bump will temporarily
create on the Cygwin and MinGW-w64/MSYS2 platforms since they don't yet
supply CMake 3.13.2 or higher.  However, if you script the required CMake
builds on both platforms, this inconvenience should be minimized.

Feel free to adapt the bash script I have attached which I use for this
purpose.  For example, earlier this morning I invoked this script using

./git_build.sh 3.13.2 yes

to build a local version of the minimum CMake version (now) required by
PLplot which I used to thoroughly test the current set of changes and
which I plan to use for most of my testing from now until the next
CMake minimum version bump.

Alan
__________________________
Alan W. Irwin

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-devel] Help needed for plplot runtime tests

[Alan W. I. <Ala...@gm...>]

Hi Ole:

On 2019-02-02 15:38+0100 Ole Streicher wrote:

> Hi Alan,
>
>
> I must confess that I disabled both build time and CI tests for plplot
> in Debian, since I could not get them working properly. The main problem
> is that the tests don't play well with the way Debian maintains its
> Python extensions (especially renaming them).

The Python status when we last discussed this is I encouraged your
desire to simplify your packaging life by dropping Python2 support in the
Debian package since upstream we use Python3 by default, and within a
year or so we might drop Python2 completely ourselves.

> and I got finally lost in
> CMake, where I must admit that I do often not understand what happens.

I am pretty good with CMake if I do say so myself.  :-)

So feel free to ask questions about it here.  (I would be willing
to answer private questions about CMake as well, but others
here might be interested in both your questions and my answers so
I prefer you keep this on this mailing list.)

> On 02.02.19 10:50, Alan W. Irwin wrote:
>> I haven't yet made the upstream fix to allow users who have installed
>> only a subset of the PLplot binary packages to test the installed
>> examples.  But that fix is still on my near-term agenda (e.g., before
>> the release of 5.15.0 tentatively scheduled for mid-2019).  But
>> meanwhile, have either of you made any progress on those requested
>> tests of the "all packages installed case" for the PLplot git master
>> tip version?  Such test reports from you would be most helpful since
>> they would verify what I have done upstream up to now.
>
>
> I think this is not a problem anymore, since I now centralized all
> examples in the -doc package.

Yes, but my goal here is your integrated installed examples package
should work regardless of what PLplot binary packages are installed.
And I have completed step 1 in that process which was to factor our
exported target support into separate configuration files for each of
those exported targets.  But that change requires work by packagers to
make sure that those many different target support files (now
interpreted as imported targets) become part of the PLplot binary
package containing the executable, library, or dll (device driver)
that those (now) imported targets refer to.  Once you have completed
that packaging work, than the imported targets will exist or not
depending on whether the relevant binary packages are installed
or not.

Note, I have not yet finished the final step 2 in this upstream change
which is to make the installed example builds and tests depend on the
existence (or not) of the relevant imported targets.  But you are in a
position now to do the above binary packaging effort and test it so
long as you have installed all the relevant binary packages.  But as
soon as step 2 is completed that caveat will no longer hold and you
should be able to also test any combination of installed (or not)
binary packages with your examples package.

>> [...] So Ole (most likely) and Orion (likely) will
>> run into this libLASi bug when testing the installed PLplot examples
>> unless you either (i) disable both the psttf
>> and psttfc devices or (ii) convince Debian and Fedora packagers to
>> package libLASi-1.1.3.  I have just released that new version (see
>> <https://sourceforge.net/p/lasi/news/2019/02/liblasi-113-has-been-released/>
>>
>> which includes my quite important bugfix for the showstopping case
>> when pango/fontconfig decides to use a pure bitmapped font.
>
>
> I do not really understand what the connection between plplot and lasi
> is? Lasi is not a dependency of plplot -- is this wrong? Can you explain
> what the relation is?

Yes.  The psttf device driver (which implements the psttf and psttfc
devices) depends directly on libLASi.  Which is why this libLASi
showstopper bug that is only fixed in libLASi-1.1.3 is so important to
PLplot (unless you go out of your way to disable both the psttf and
psttfc devices).

>> @Ole: My understanding from
>> <https://packages.debian.org/source/sid/lasi> is Debian packaging
>> efforts for libLASIi are 3 bugfix versions behind (libLASi version
>> 1.1.0 is packaged rather than 1.1.3).  I think Debian is in freeze now
>> for the stable release of Debian Buster, but after that is done would
>> you be willing to package libLASi-1.1.3 and do an NMU in response to
>> [Debian bug
>> 921139](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921139).
>> That effort would propagate the important upstream pure bitmapped font
>> bug fix for all Debian and Debian derivative users.
>
>
> Lasi is an "orphaned" Debian package, which means that nobody
> specifically takes care of it. Only our QA team looks to fix serious
> problems. But since the package is rarely used, it may even be removed.
> "Someone" should take care of it. BTW, the VCS (on sourceforge) with the
> Debian package seems to not work.

The libLASi VCS at SF is subversion and is working great here
(although resurrecting my knowledge of svn felt a bit strange for a while).

But you can try out libLASi for yourself with no need to resurrect
your knowledge of subversion or learn about it for the first time.
All you need to do is to download the libLASi-1.1.3 tarball and use
standard cmake, "make all", ctest, and "make install" to configure,
build, test, and install it.

Please also look at the project sample at
<https://sourceforge.net/projects/lasi/> to see one of the beautiful
results that can be generated by this library.  (You should also find
that beautiful result in examples/ComplexTextLayoutExample.eps and
examples/ComplexTextLayoutExample.png in the build tree once you have
built the "all" target with make.  And you should find a snapshot of
that *.png file before you build in the examples subdirectory of the
source tree.

In sum, it would be a shame to lose this capability for Debian because
no maintainer had the time to change the package from 1.1.0 to 1.1.3
(which should be straightforward since the libLASi build system has
not changed that much between those versions).  And this is not a
large commitment because it is a small library that is in deep
maintenance mode with a track record of new bug fix releases not
occurring that often.  So I frankly hope you are interested enough to
try libLASi for yourself and follow up with an NMU.  But if not, then
you should definitely drop the psttf and psttfc devices from your
PLplot package.

>> @Everybody: there are still some minor PLplot issues for the psttf
>> device driver that Ole and Orion won't face when testing
>> system versions of PLplot.
>>
>> Those issues are the following:
>>
>> * The PLplot build system currently does not configure rpath
>>   information for the case when libLASi is installed in a non-system
>>   location.  To work around this issue I currently set the
>>   LD_LIBRARY_PATH environment variable appropriately to help the Linux
>>   loader find my locally built and installed version of libLASi.
>
>
> In Debian, we would specifically remove RPATH information, since libs
> are supposed to be installed in the standard dirs.

Yes, that is likely true of all distributions since they use system
locations for installed files and for that case RPATH has some
downsides with no benefits whatsoever.  To accomodate this
distribution need we have the option to turn off installed RPATH
capability using -DUSE_RPATH=OFF (which I assume your packages are
already using).  But most individual downloaders install PLplot in
non-system locations so they use the default -DUSE_RPATH=ON option
because that is the most convenient choice for their use case, i.e.,
it means they don't have to maintain the LD_LIBRARY_PATH environment
variable setting in order to get installed PLplot to work properly.

Alan
__________________________
Alan W. Irwin

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-devel] Help needed for plplot runtime tests

[Alan W. I. <Ala...@gm...>]

On 2018-12-18 13:16-0800 Alan W. Irwin wrote:

[...]
> But meanwhile, I hope you are both able to test your binary packages
> for PLplot and your package containing the installed examples for
> plplot-5.14.0-10-g66d68d93e in the above way subject to the temporary
> "all installed" constraint.

@Ole and Orion:

I haven't yet made the upstream fix to allow users who have installed
only a subset of the PLplot binary packages to test the installed
examples.  But that fix is still on my near-term agenda (e.g., before
the release of 5.15.0 tentatively scheduled for mid-2019).  But
meanwhile, have either of you made any progress on those requested
tests of the "all packages installed case" for the PLplot git master
tip version?  Such test reports from you would be most helpful since
they would verify what I have done upstream up to now.

The other purpose of bringing this installed examples test topic up
again, is as a recent Debian Buster update (and very likely on Fedora as well)
fontconfig has by default started to give the highest preference to
the Noto fonts.  Most of those are really nice with deserved
popularity, but one of them, "Noto Color Emoji" is an old-fashioned
pure bitmapped font (likely OK for Emoji's in text but not much
else) that has exposed a long-standing issue in libLASi which simply
gave up (threw an error and exited) for libLASi-1.1.2 and all prior
versions when encountering a pure bitmapped font.

The reason for this result is old-fashioned pure bitmapped fonts are
completely incompatible with the libLASi library (since it needs
scalable outline font information to represent glyphs rather than an
old-fashioned bitmap).  Of course, this library response to pure
bitmapped fonts is much too severe, and the result of this libLASi bug
is that PLplot comprehensive tests error out for the psttf and psttfc
devices (which depend on libLASi to do the work).  This error occurs
when PLplot encounters the Aries glyph symbol in example 7 since
pango/fontconfig by default chooses "Noto Color Emoji" to render that
glyph and ~15 others).  So Ole (most likely) and Orion (likely) will
run into this libLASi bug when testing the installed PLplot examples
unless you either (i) disable both the psttf
and psttfc devices or (ii) convince Debian and Fedora packagers to
package libLASi-1.1.3.  I have just released that new version (see
<https://sourceforge.net/p/lasi/news/2019/02/liblasi-113-has-been-released/>
which includes my quite important bugfix for the showstopping case
when pango/fontconfig decides to use a pure bitmapped font.

@Ole: My understanding from
<https://packages.debian.org/source/sid/lasi> is Debian packaging
efforts for libLASIi are 3 bugfix versions behind (libLASi version
1.1.0 is packaged rather than 1.1.3).  I think Debian is in freeze now
for the stable release of Debian Buster, but after that is done would
you be willing to package libLASi-1.1.3 and do an NMU in response to
[Debian bug
921139](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921139).
That effort would propagate the important upstream pure bitmapped font
bug fix for all Debian and Debian derivative users.

@Orion: My understanding from
<https://rpmfind.net/linux/rpm2html/search.php?query=libLASi.so.1()(64bit)>
is that Fedora packaging of libLASi is only one bugfix version behind
(libLASi 1.1.2 is packaged rather than the desired 1.1.3).  The Fedora
libLASi packager may not have dealt with 1.1.3 yet because the 1.1.3
release is so recent, but if that situation persists I hope you get in
touch with him to remind him there is an important upstream bugfix
release that should be packaged instead of 1.1.2 to avoid PLplot
comprehensive testing errors with the psttf and psttfc devices.

@Everybody: there are still some minor PLplot issues for the psttf
device driver that Ole and Orion won't face when testing
system versions of PLplot.

Those issues are the following:

* The PLplot build system currently does not configure rpath
   information for the case when libLASi is installed in a non-system
   location.  To work around this issue I currently set the
   LD_LIBRARY_PATH environment variable appropriately to help the Linux
   loader find my locally built and installed version of libLASi.

* PLplot currently accepts any version of libLASi.  I need to change that
   so it only accepts libLASi-1.1.3 or above since the prior versions
   are obviously contaminated with the showstopper pure bitmapped font issue
   and several other important issues as well that are fixed in libLASi-1.1.3.

I hope to deal with both these PLplot issues by early next week.

Alan
__________________________
Alan W. Irwin

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-devel] findwxwidgets.cmake module

[Phil R. <p.d...@gm...>]

Okay, well it sounds like the best thing to do is when you bump the minimum version, remove the find wxwidgets module too. Or if you prefer me to get rid of it now, then just say.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Alan W. Irwin <Ala...@gm...>
Sent: Thursday, January 31, 2019 9:01:23 PM
To: Phil Rosenberg
Cc: PLplot development list
Subject: findwxwidgets.cmake module

On 2019-01-31 17:37-0000 Phil Rosenberg wrote:

> Hi Alan
> I half thought that we had scrapped our findwxWidgets.cmake module,
> but I just found that this isn't actually the case.
>
> I've just disabled our version by renaming it, and I've found that the
> CMake version does appear to work on Windows. This is using cmake
> 3.13.3 (the latest release as of writing this email).
>
> I seem to remember that it was for windows builds that we were
> maintaining our own version. Perhaps this can now be removed?

Hi Phil:

I am moving this development discussion to the plplot-devel list since that is what
that list is for, and plplot-general is normally just used for user support.

I followed up on your question by using

git log cmake/modules/FindwxWidgets.cmake

to check the history of this file.  As of commit 59344dc51a25
it was updated to the official upstream version for
CMake-3.9.0-rc3, and since there has been 3 commits, but
one of them cancelled another one so the net effect of our changes
since commit 59344dc51a25 is as
follows:

software@merlin> git diff 59344dc51a25 HEAD cmake/modules/FindwxWidgets.cmake
diff --git a/cmake/modules/FindwxWidgets.cmake b/cmake/modules/FindwxWidgets.cmake
index 82f34ec32..4d3a2d115 100644
--- a/cmake/modules/FindwxWidgets.cmake
+++ b/cmake/modules/FindwxWidgets.cmake
@@ -915,8 +915,17 @@ if (_wx_lib_missing)
  endif()
  unset(_wx_lib_missing)

-# Check if a specfic version was requested by find_package().
+# Check if a specific version was requested by find_package().
  if(wxWidgets_FOUND)
+  # On at least one Windows platform (MinGW/MSYS) find_file fails
+  # unless convert from /<drive_letter>/ form to <drive_letter>:/
+  # form.  So use both forms to be sure on that platform without
+  # disrupting other platforms.
+  string(REGEX REPLACE ";/([a-zA-z])/" ";\\1:/" wxWidgets_search_path ";${wxWidgets_INCLUDE_DIRS}")
+  list(REMOVE_AT wxWidgets_search_path 0)
+  if(NOT "${wxWidgets_search_path}" STREQUAL "${wxWidgets_INCLUDE_DIRS}")
+    list(APPEND wxWidgets_INCLUDE_DIRS ${wxWidgets_search_path})
+  endif(NOT "${wxWidgets_search_path}" STREQUAL "${wxWidgets_INCLUDE_DIRS}")
    find_file(_filename wx/version.h PATHS ${wxWidgets_INCLUDE_DIRS} NO_DEFAULT_PATH)
    dbg_msg("_filename:  ${_filename}")

That change was to help support the legacy MinGW/MSYS system which is now likely
of zero interest to us (since its successor MinGW-w64/MSYS2 is so much better).
And this change may not be necessary on any other platform.

Meanwhile, since CMake-3.9.0-rc3 the CMake developers have been
actively maintaining the upstream version of FindwxWidgets.cmake to
the point that from your experience it is a big improvement on our
version.

So yes, I agree that it is time for us to drop our own version, and if
we find the above patch is necessary on any Windows platform of
interest to us we can always submit that change for inclusion into the
upstream version.

Meanwhile, the upstream version of this find module would likely fail
for our users that are using cmake versions less than 3.9.0.  But that
is not going to be an issue since I plan in any case today to bump the
minimum version of cmake that PLplot accepts to a version of CMake
that all modern Linux, Mac, and Windows free software distributions
support.  That new minimum version will be 3.13.2 for Linux, but I
still have to look at the Mac OS X distributions Fink, MacPorts, and
HomeBrew, and the Windows distributions Cygwin, and MinGW-w64/MSYS2 to
see if that or a higher version of CMake is available for all of
those.

Just to remind developers here that are not aware of this, the
motivation for such bumps in the minimum version of CMake we accept
for PLplot configuration is all the bug fixing and improved find
capability (e.g., for the wxwidgets find module) that has gone on, and
the improved CMake policy that has been established for modern CMake
versions.  So in general every such bump makes our build system more
robust and easier to maintain (e.g., it allows us to drop our own
version of the wxwidgets find module).

Alan
__________________________
Alan W. Irwin

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-devel] findwxwidgets.cmake module

[Alan W. I. <Ala...@gm...>]

On 2019-01-31 17:37-0000 Phil Rosenberg wrote:

> Hi Alan
> I half thought that we had scrapped our findwxWidgets.cmake module,
> but I just found that this isn't actually the case.
>
> I've just disabled our version by renaming it, and I've found that the
> CMake version does appear to work on Windows. This is using cmake
> 3.13.3 (the latest release as of writing this email).
>
> I seem to remember that it was for windows builds that we were
> maintaining our own version. Perhaps this can now be removed?

Hi Phil:

I am moving this development discussion to the plplot-devel list since that is what
that list is for, and plplot-general is normally just used for user support.

I followed up on your question by using

git log cmake/modules/FindwxWidgets.cmake

to check the history of this file.  As of commit 59344dc51a25
it was updated to the official upstream version for
CMake-3.9.0-rc3, and since there has been 3 commits, but
one of them cancelled another one so the net effect of our changes
since commit 59344dc51a25 is as
follows:

software@merlin> git diff 59344dc51a25 HEAD cmake/modules/FindwxWidgets.cmake 
diff --git a/cmake/modules/FindwxWidgets.cmake b/cmake/modules/FindwxWidgets.cmake
index 82f34ec32..4d3a2d115 100644
--- a/cmake/modules/FindwxWidgets.cmake
+++ b/cmake/modules/FindwxWidgets.cmake
@@ -915,8 +915,17 @@ if (_wx_lib_missing)
  endif()
  unset(_wx_lib_missing)

-# Check if a specfic version was requested by find_package().
+# Check if a specific version was requested by find_package().
  if(wxWidgets_FOUND)
+  # On at least one Windows platform (MinGW/MSYS) find_file fails
+  # unless convert from /<drive_letter>/ form to <drive_letter>:/
+  # form.  So use both forms to be sure on that platform without
+  # disrupting other platforms.
+  string(REGEX REPLACE ";/([a-zA-z])/" ";\\1:/" wxWidgets_search_path ";${wxWidgets_INCLUDE_DIRS}")
+  list(REMOVE_AT wxWidgets_search_path 0)
+  if(NOT "${wxWidgets_search_path}" STREQUAL "${wxWidgets_INCLUDE_DIRS}")
+    list(APPEND wxWidgets_INCLUDE_DIRS ${wxWidgets_search_path})
+  endif(NOT "${wxWidgets_search_path}" STREQUAL "${wxWidgets_INCLUDE_DIRS}")
    find_file(_filename wx/version.h PATHS ${wxWidgets_INCLUDE_DIRS} NO_DEFAULT_PATH)
    dbg_msg("_filename:  ${_filename}")

That change was to help support the legacy MinGW/MSYS system which is now likely
of zero interest to us (since its successor MinGW-w64/MSYS2 is so much better).
And this change may not be necessary on any other platform.

Meanwhile, since CMake-3.9.0-rc3 the CMake developers have been
actively maintaining the upstream version of FindwxWidgets.cmake to
the point that from your experience it is a big improvement on our
version.

So yes, I agree that it is time for us to drop our own version, and if
we find the above patch is necessary on any Windows platform of
interest to us we can always submit that change for inclusion into the
upstream version.

Meanwhile, the upstream version of this find module would likely fail
for our users that are using cmake versions less than 3.9.0.  But that
is not going to be an issue since I plan in any case today to bump the
minimum version of cmake that PLplot accepts to a version of CMake
that all modern Linux, Mac, and Windows free software distributions
support.  That new minimum version will be 3.13.2 for Linux, but I
still have to look at the Mac OS X distributions Fink, MacPorts, and
HomeBrew, and the Windows distributions Cygwin, and MinGW-w64/MSYS2 to
see if that or a higher version of CMake is available for all of
those.

Just to remind developers here that are not aware of this, the
motivation for such bumps in the minimum version of CMake we accept
for PLplot configuration is all the bug fixing and improved find
capability (e.g., for the wxwidgets find module) that has gone on, and
the improved CMake policy that has been established for modern CMake
versions.  So in general every such bump makes our build system more
robust and easier to maintain (e.g., it allows us to drop our own
version of the wxwidgets find module).

Alan
__________________________
Alan W. Irwin

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-devel] qt_example memory management issues (SOLVED!)

[Alan W. I. <Ala...@gm...>]

Hi António:

Thanks for your recent replies concerning my Qt5 education
and also your successful tests of the previous commit.

With commit plplot-5.14.0-16-g02652c9a4 I am virtually positive from
valgrind results that I have solved these qt_example memory management
issues while still being able to properly delete the PLplot library
and the PlotWindow instance.  See that commit message for details.

The comprehensive test for that commit did not turn up any segfaults
for the first time ever!  However, that test did turn up an
intermittent hang for qt_example on exit similar to what I found in
December for pyqt5_example (but no hang for pyqt5_example this time
although that example is unchanged).  But in this case, I
could prove the hang was because the exec method for the qApp
never returned control to the main routine of qt_example.

See the commit message for documentation I discovered with a google
search of the recommended signals and slots procedure for making the
current problematic cleanup procedure completely robust and possibly
solving these intermittent hang on exit problems

I suspect this recommended and documented change is a matter of 15
minutes or so for someone who is expert in Qt5.  But that is not me.
(For example, I am just learned about Qt signals and slots today.)  Of
course, I am retired so I have much more time than the rest of the
PLplot developers here to work on PLplot.  So if you (or someone else
here with Qt5 expertise) don't have time/inclination to fix this
according to the web prescription I have documented, I do plan to do
it myself after a substantial break to work on PLplot components that
are a lot easier for me!

Alan
__________________________
Alan W. Irwin

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-devel] Testing of latest qt pushes requested

[António R. T. <ar...@gm...>]

Yes Alan it was. It worked without problem from my qt apps.
Cheers

On Wed, 2 Jan 2019, 09:49 Alan W. Irwin <Ala...@gm... wrote:

> On 2018-12-31 16:05-0000 António Rodrigues Tomé wrote:
>
> > p.s
> > I will have a look at your commit and test it on my own applications
>
> Hi António:
>
> Just to finish off this topic, was that test a success?
>
> Alan
>
> __________________________
> Alan W. Irwin
>
> 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-devel] Testing of latest qt pushes requested

[Alan W. I. <Ala...@gm...>]

On 2018-12-31 16:05-0000 António Rodrigues Tomé wrote:

> p.s
> I will have a look at your commit and test it on my own applications

Hi António:

Just to finish off this topic, was that test a success?

Alan

__________________________
Alan W. Irwin

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-devel] qt_example memory management issues

[António R. T. <ar...@gm...>]

On Tue, Jan 1, 2019 at 10:09 PM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-31 11:44-0800 Alan W. Irwin wrote:
>
> > On 2018-12-31 11:28-0800 Alan W. Irwin wrote:
> >
> >> [...] by the following temporary changes to
> >> qt_example:
> >>
> >>    argc = 1;
> >>    QApplication a( argc, argv );
> >>    // Must construct an instance of PlotWindow after QApplication.
> >>    PlotWindow   * win = new PlotWindow( Argc, Argv );
> >>
> >>    // Clean up Argv now that we are done with processing arguments.
> >>    for ( int i = 0; i < Argc; ++i )
> >>    {
> >>        delete[] Argv[i];
> >>    }
> >>    delete[] Argv;
> >>
> >>    delete win;
> >>    return 0;
> >>
> >> So the QApplication never gets explicitly used in this experimental
> >> version of the code whose job is simply to test the PlotWindow
> >> constructor and destructor without actually using the PlotWindow
> >> instance for anything.  An additional important part of these
> >> experiments is to make some changes to the destructor such as calling
> >> plend from there.  And now I am going to test the effect of the
> >> Qt::WA_DeleteOnClose attribute as well.
> >
> > P.S. Something that just struck me is the above experimental code and
> > also the normal version of this code create the "a" instance of
> > QApplication on the stack.  So that instance should automatically be
> > deleted when the above code or the non-experimental version of this
> > code return from qt_example main routine.  So setting the above
> > attribute seems like overkill and, in fact, might cause a double free.
> > So at this stage I am hoping that not setting this attribute (as you
> > tried in your own experiment) is the key step required in fixing the
> > qt_example memory management.
> >
> > More later.
>
> Hi António:
>
> A google search for "qapplication delete "WA_DeleteOnClose"" (without
> the outer quotes) showed what appeared to be mass confusion about
> deleting qApps, but one of those discussions
> <
> https://stackoverflow.com/questions/3153155/when-setting-the-wa-deleteonclose-attribute-on-a-qt-mainwindow-the-program-cras
> >
> does contain the following advice:
>
> "Remember that your main window destructor should run only once. That is
> to say that it should run either because of a stack unwind, or because of
> WA_DeleteOnClose, not both."
>
> The documentation at <http://doc.qt.io/qt-5/qt.html#WidgetAttribute-enum>
> of this attribute
> says the following:
>
> "Makes Qt delete this widget when the widget has accepted the close event
> (see QWidget::closeEvent())."
>
> which seems consistent with the advice.  However, the only mentions of
> closeEvent in
> our entire code base are the following:
>
> software@merlin> find . -type f |grep -v .git |xargs grep closeEvent
> ./bindings/qt_gui/pyqt4/plplot_pyqt4.sip:    void closeEvent(QCloseEvent
> *event);
> ./bindings/qt_gui/plqt.cpp:void QtPLWidget::closeEvent( QCloseEvent* event
> )
> ./bindings/qt_gui/pyqt5/plplot_pyqt5.sip:    void closeEvent(QCloseEvent
> *event);
> ./include/qt.h:    void closeEvent( QCloseEvent* event );
>
> So closeEvent is defined but never explicitly used in our code.  So to
> help with my Qt education is this a case where closeEvent is
> essentially a callback that Qt demands must be defined and then it
> uses it internally for its own purposes (e.g., when a user closes a Qt
> GUI)?
>

closeEvent is a protected function  that is in qt_example case called when
you click in the X in the window application that closes/ends.
One may redefine it if needs extra actions to be performed before close the
window.  Must of the times it is redefined to prompt to the user if he in
fact wants to close the window.
citing qt documentation
  By default, the event is accepted and the widget is closed. You can
reimplement this function to change the way the widget responds to window
close requests. For example, you can prevent the window from closing by
calling ignore() on all events.

cheers




>
> Regardless of your reply to that "Qt education question" it appears to
> me that to avoid double frees we must either drop this attribute or
> else create the qApp on the heap and not delete it explicitly.
> However, the above experimental code never gives the user the chance
> to close the GUI so closeEvent is likely never called and setting the
> attribute or not should make no difference for that experimental case.
> However, once I have figured out how to cleanly delete PlotWindow with
> the above experimental version of the code, then I plan to follow up
> by using that delete method in the non-experimental version of
> qt_example and look at valgrind results in that case (where setting
> the attribute would matter) with the qApp created on the stack (as in
> the original version of qt_example), and the above attribute dropped.
>
> Alan
> __________________________
> Alan W. Irwin
>
> 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
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] qt_example memory management issues

[Alan W. I. <Ala...@gm...>]

On 2018-12-31 11:44-0800 Alan W. Irwin wrote:

> On 2018-12-31 11:28-0800 Alan W. Irwin wrote:
>
>> [...] by the following temporary changes to
>> qt_example:
>>
>>    argc = 1;
>>    QApplication a( argc, argv );
>>    // Must construct an instance of PlotWindow after QApplication.
>>    PlotWindow   * win = new PlotWindow( Argc, Argv );
>>
>>    // Clean up Argv now that we are done with processing arguments.
>>    for ( int i = 0; i < Argc; ++i )
>>    {
>>        delete[] Argv[i];
>>    }
>>    delete[] Argv;
>>
>>    delete win;
>>    return 0;
>> 
>> So the QApplication never gets explicitly used in this experimental
>> version of the code whose job is simply to test the PlotWindow
>> constructor and destructor without actually using the PlotWindow
>> instance for anything.  An additional important part of these
>> experiments is to make some changes to the destructor such as calling
>> plend from there.  And now I am going to test the effect of the
>> Qt::WA_DeleteOnClose attribute as well.
>
> P.S. Something that just struck me is the above experimental code and
> also the normal version of this code create the "a" instance of
> QApplication on the stack.  So that instance should automatically be
> deleted when the above code or the non-experimental version of this
> code return from qt_example main routine.  So setting the above
> attribute seems like overkill and, in fact, might cause a double free.
> So at this stage I am hoping that not setting this attribute (as you
> tried in your own experiment) is the key step required in fixing the
> qt_example memory management.
>
> More later.

Hi António:

A google search for "qapplication delete "WA_DeleteOnClose"" (without
the outer quotes) showed what appeared to be mass confusion about
deleting qApps, but one of those discussions
<https://stackoverflow.com/questions/3153155/when-setting-the-wa-deleteonclose-attribute-on-a-qt-mainwindow-the-program-cras>
does contain the following advice:

"Remember that your main window destructor should run only once. That is to say that it should run either because of a stack unwind, or because of WA_DeleteOnClose, not both."

The documentation at <http://doc.qt.io/qt-5/qt.html#WidgetAttribute-enum> of this attribute
says the following:

"Makes Qt delete this widget when the widget has accepted the close event (see QWidget::closeEvent())."

which seems consistent with the advice.  However, the only mentions of closeEvent in
our entire code base are the following:

software@merlin> find . -type f |grep -v .git |xargs grep closeEvent
./bindings/qt_gui/pyqt4/plplot_pyqt4.sip:    void closeEvent(QCloseEvent *event);
./bindings/qt_gui/plqt.cpp:void QtPLWidget::closeEvent( QCloseEvent* event )
./bindings/qt_gui/pyqt5/plplot_pyqt5.sip:    void closeEvent(QCloseEvent *event);
./include/qt.h:    void closeEvent( QCloseEvent* event );

So closeEvent is defined but never explicitly used in our code.  So to
help with my Qt education is this a case where closeEvent is
essentially a callback that Qt demands must be defined and then it
uses it internally for its own purposes (e.g., when a user closes a Qt
GUI)?

Regardless of your reply to that "Qt education question" it appears to
me that to avoid double frees we must either drop this attribute or
else create the qApp on the heap and not delete it explicitly.
However, the above experimental code never gives the user the chance
to close the GUI so closeEvent is likely never called and setting the
attribute or not should make no difference for that experimental case.
However, once I have figured out how to cleanly delete PlotWindow with
the above experimental version of the code, then I plan to follow up
by using that delete method in the non-experimental version of
qt_example and look at valgrind results in that case (where setting
the attribute would matter) with the qApp created on the stack (as in
the original version of qt_example), and the above attribute dropped.

Alan
__________________________
Alan W. Irwin

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-devel] qt_example memory management issues

[Alan W. I. <Ala...@gm...>]

On 2018-12-31 11:28-0800 Alan W. Irwin wrote:

> [...] by the following temporary changes to
> qt_example:
>
>    argc = 1;
>    QApplication a( argc, argv );
>    // Must construct an instance of PlotWindow after QApplication.
>    PlotWindow   * win = new PlotWindow( Argc, Argv );
>
>    // Clean up Argv now that we are done with processing arguments.
>    for ( int i = 0; i < Argc; ++i )
>    {
>        delete[] Argv[i];
>    }
>    delete[] Argv;
>
>    delete win;
>    return 0;
>
> So the QApplication never gets explicitly used in this experimental
> version of the code whose job is simply to test the PlotWindow
> constructor and destructor without actually using the PlotWindow
> instance for anything.  An additional important part of these
> experiments is to make some changes to the destructor such as calling
> plend from there.  And now I am going to test the effect of the
> Qt::WA_DeleteOnClose attribute as well.

P.S. Something that just struck me is the above experimental code and
also the normal version of this code create the "a" instance of
QApplication on the stack.  So that instance should automatically be
deleted when the above code or the non-experimental version of this
code return from qt_example main routine.  So setting the above
attribute seems like overkill and, in fact, might cause a double free.
So at this stage I am hoping that not setting this attribute (as you
tried in your own experiment) is the key step required in fixing the
qt_example memory management.

More later.

Alan
__________________________
Alan W. Irwin

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-devel] qt_example memory management issues

[Alan W. I. <Ala...@gm...>]

On 2018-12-31 16:05-0000 António Rodrigues Tomé wrote:

> Hi Alan
> let's do a small change in qt_example. cpp to make it more orthodox.
>
>   QApplication a( argc, argv );
>    PlotWindow   win ( Argc, Argv );
>    win.show();
>
> when I do this the program always crashes on close in my system.
> much likely because there is an attempt to free twice a memory block.
> It may result from
>
> setAttribute( Qt::WA_DeleteOnClose );
> on qt_Plotwindow.cpp as at destructor level qt may try to free something
> that the driver has already  free.
> the fact is if I erase or comment that line the program does not crash
> anymore on exit.

Hi António:

Thanks for these comments.  In particular your remark on
setAttribute( Qt::WA_DeleteOnClose ) is likely to be quite
relevant to my experiments today.

Just to let you know where I am at the
moment, I have been looking carefully at PlotWindow since that class
is a part of qt_example (i.e., not part of the extqt device or the
PLplot qt binding).  And since I am not that familiar with extqt, I
have been taking an experimental approach to learning about it
starting with figuring out all the ramifications of PlotWindow
construction and destruction by the following temporary changes to
qt_example:

     argc = 1;
     QApplication a( argc, argv );
     // Must construct an instance of PlotWindow after QApplication.
     PlotWindow   * win = new PlotWindow( Argc, Argv );

     // Clean up Argv now that we are done with processing arguments.
     for ( int i = 0; i < Argc; ++i )
     {
         delete[] Argv[i];
     }
     delete[] Argv;

     delete win;
     return 0;

So the QApplication never gets explicitly used in this experimental
version of the code whose job is simply to test the PlotWindow
constructor and destructor without actually using the PlotWindow
instance for anything.  An additional important part of these
experiments is to make some changes to the destructor such as calling
plend from there.  And now I am going to test the effect of the
Qt::WA_DeleteOnClose attribute as well.

For each such variant of the destructor I build the qt_example
target (which builds the qt_example application and all its PLplot
prerequisites) with the -g option for gcc and g++ and analyzed
run-time results using

valgrind --leak-check=full --show-leak-kinds=all --num-callers=500 examples/c++/qt_example >| valgrind.out 2>&1

The goal of these experiments is to implement a rock-solid destructor
for PlotWindow that leaves no memory directly allocated by PLplot that
continues to be allocated after PlotWindow destruction.  I hasten to
add I am no where near that goal at the moment, but these experiments
are yielding a lot of data that I hope will help me to eventually reach
that goal.

Alan
__________________________
Alan W. Irwin

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
__________________________