plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Soft freeze on December 3rd and release on December17th?

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

Hi Alan
Those dates look good to me, and I will investigate my 3 thread issues 
(wxWidgets, Qt, error messages ) well before the freezing date
-Pedro

----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "PLplot development list" <Plp...@li...>
Sent: Tuesday, November 22, 2016 7:50 PM
Subject: [Plplot-devel] Soft freeze on December 3rd and release on 
December17th?


> Tom Schoonjans made some good points on plplot-general about
> officially releasing timely fixes for PLplot rather than expecting
> packagers and others to dig those out of git, and I also feel it is
> critical to give our users good access to the recent big improvements
> in both our Fortran and Tcl bindings.  So to answer these concerns my
> plan is to release PLplot-5.12.0 on ********** December 17th **********.
> That is roughly the last release date possible in December without
> intruding on Christmas holiday time, and I don't want to put off this
> release until January for the above reasons.
>
> Note, I don't want the release any sooner than the above date because
> there are a lot of (fairly minor) topics I am still working on that I
> would like to get into this release.  Therefore, I plan to continue
> working on those topics for the rest of this week and the next one and
> declare a soft freeze (where only minor bug fixing and documentation
> improvements should occur after that freeze date until the release) on
> ********** December 3rd **********. That freeze date should give us
> two weeks for extensive testing of PLplot (and fixing all bugs that
> are turned up by such testing) on all platforms accessible to PLplot
> developers and users.  (Note, I do plan to ask our users on
> plplot-general to help with testing during those two critical weeks on
> the platforms accessible to them.)
>
> Please speak out if either of the two dates above need an adjustment
> from your perspective.  For example, another freeze date alternative
> could be December 10th (which still gives us the minimum one week of
> time we need for testing).  But that freeze date would be completely
> inflexible, and I would prefer a more flexible freeze date (to
> accommodate last-minute requests to change it for those developers who
> discover they need a few more days to get their topics merged) which
> is why I have suggested December 3rd as the freeze date.
>
> If nobody has any suggestions for changes in the above two critical
> dates by (say) late Wednesday I will follow up by announcing the above
> two critical dates on PLplot-general.
>
> Alan (your friendly release manager).
> __________________________
> 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-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 

[Plplot-devel] Soft freeze on December 3rd and release on December 17th?

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

Tom Schoonjans made some good points on plplot-general about
officially releasing timely fixes for PLplot rather than expecting
packagers and others to dig those out of git, and I also feel it is
critical to give our users good access to the recent big improvements
in both our Fortran and Tcl bindings.  So to answer these concerns my
plan is to release PLplot-5.12.0 on ********** December 17th **********.
That is roughly the last release date possible in December without
intruding on Christmas holiday time, and I don't want to put off this
release until January for the above reasons.

Note, I don't want the release any sooner than the above date because
there are a lot of (fairly minor) topics I am still working on that I
would like to get into this release.  Therefore, I plan to continue
working on those topics for the rest of this week and the next one and
declare a soft freeze (where only minor bug fixing and documentation
improvements should occur after that freeze date until the release) on
********** December 3rd **********. That freeze date should give us
two weeks for extensive testing of PLplot (and fixing all bugs that
are turned up by such testing) on all platforms accessible to PLplot
developers and users.  (Note, I do plan to ask our users on
plplot-general to help with testing during those two critical weeks on
the platforms accessible to them.)

Please speak out if either of the two dates above need an adjustment
from your perspective.  For example, another freeze date alternative
could be December 10th (which still gives us the minimum one week of
time we need for testing).  But that freeze date would be completely
inflexible, and I would prefer a more flexible freeze date (to
accommodate last-minute requests to change it for those developers who
discover they need a few more days to get their topics merged) which
is why I have suggested December 3rd as the freeze date.

If nobody has any suggestions for changes in the above two critical
dates by (say) late Wednesday I will follow up by announcing the above
two critical dates on PLplot-general.

Alan (your friendly release manager).
__________________________
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-devel] The wxwidgets device driver speed/idle time

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

Hi Alan
It's on my list - I will do it as soon as I can :-). I actually think
I had a similar system like this set up - although I think I used
named semaphores. I would have to go back to the code to check.

Phil

On 19 November 2016 at 07:39, Alan W. Irwin <ir...@be...> wrote:
> Hi Phil:
>
> I got tired of speculating about more efficient Linux IPC methods so I
> implemented (as of commit e166866) the "Unnamed semaphores example"
> paradigm outlined starting on page 73 of
> <http://man7.org/conf/lca2013/IPC_Overview-LCA-2013-printable.pdf>. (I
> discussed this possibility in earlier versions of this thread.)
> This test project is described in cmake/test_linux_ipc/README.  Follow
> the directions there to test it on your own Linux systems.
>
> My tests show this method is quite efficient for transferring data
> between processes on POSIX-compliant systems.  The transfer process is
> under complete control of unnamed semaphores that reside in the shared
> memory so coordinating required data transfer between two applications
> is completely straightforward, and there is very little idle time
> required during these transfers.
>
> The IPC-relevant routines that are called in this test project are
> shm_open, ftruncate, mmap, sem_init, sem_wait, sem_post, and
> shm_unlink, and according to the Linux man pages, all of these
> functions are provided by platforms that are compliant with POSIX.1-2001.
>
> So on the present evidence from this test project I think this method
> looks extremely promising for efficiently transferring data both ways
> between -dev wxwidgets and wxPLViewer for POSIX-compliant systems.
>
> If after trying the test of the method documented in
> cmake/test_linux_ipc/README you agree with this assessment, would you
> be willing to have a go at the required wxwidgets and wxPLViewer
> source code changes to see if that essentially eliminates the
> large idle times we have now on Linux?
>
>
> 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-devel] [bug] plmap with a polygon map causes a call to plabort

[Mark de W. <m.d...@da...>]

Hi,

While testing plplot 5.11.1 with a map with polygons on Windows my 
application terminated due to a call to plabort. It was caused by 
calling plfill with n < 3. I investigated further on my Debian Stable 
system with a recent version of master [d71e48]. The bug is still 
present in this version.

Attached a modified x19.cc which calls plabort when drawing the map. In 
order to do so I replaced the cglobe.sh? files with the files in this 
archive [1] (854.21 KB). The first plot is fine, the seconds calls plabort.

I added a proof-of-concept fix, which also cleans up the duplicate tests 
in the if statements in drawmapdata. I'm not convinced this is the right 
approach. I still see glitches, but I'm not sure whether they are all 
caused by fact lines at the left hand side of the plot are sometimes 
omitted.


[1] 
http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/50m/cultural/ne_50m_admin_0_countries_lakes.zip

Regards,
Mark de Wever

Re: [Plplot-devel] Continuous Integration

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

Hi Hazen,


That’s exactly how I do it though: trial and error :-)
If you worry about the commit history, then I recommend you do this in a separate branch, open a PR, commit until you get it right and then use “squash and merge”. In fact I recommend you make master a protected branch meaning that no direct commits can be made into it, only via the PR system. This also ensure that no disasters via “git push —force” happen :-)

But before you do any of this, make sure that Travis-CI is properly configured in Settings -> Integrations & Services. On the Travis-CI page you will also have to activate support for PRs (or maybe that is the default, not sure).

Best regards,

Tom

> On 20 Nov 2016, at 15:58, Hazen Babcock <hba...@ma...> wrote:
> 
> 
> Hi Tom,
> 
> Any pointers for getting started with continuous integration? I'm planning to set this up on the Github PLplot mirror using Travis-CI to start.
> 
> In particular I'd like to know what you think is the best way to go about debugging the Travis scripts? It appears to me that this is going to involve lots of cycles of editing, pushing and waiting for Travis results, along with a lot of commit noise. Is there a better way?
> 
> best,
> -Hazen

[Plplot-devel] Continuous Integration

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

Hi Tom,

Any pointers for getting started with continuous integration? I'm 
planning to set this up on the Github PLplot mirror using Travis-CI to 
start.

In particular I'd like to know what you think is the best way to go 
about debugging the Travis scripts? It appears to me that this is going 
to involve lots of cycles of editing, pushing and waiting for Travis 
results, along with a lot of commit noise. Is there a better way?

best,
-Hazen

Re: [Plplot-devel] Reducing loudness of compiler "Error" messages

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

On 2016-11-12 01:07-0800 Alan W. Irwin wrote:

> On 2016-11-12 00:08-0500 Pedro Vicente wrote:
>
>> I have a couple suggestions, however
>> 
>> the Cmake output is full of messages like
>> 
>> CMake Error at CMakeLists.txt:18 (enable_language):
>> 
>> No CMAKE_Fortran_COMPILER could be found.
>> 
>> -- Configuring incomplete, errors occurred!
>> 
>> these are not really errors, just features that are not detected, like a 
>> Fortran compiler
>> 
>> would it be possible to replace this just with a information message , like
>> 
>> --detected fortran compiler
>> --fortran compiler not found
>
> I agree those "Error" messages are too loud for simply an issue with a
> missing compiler so ideally it would be good to reduce that loudness.
> I will think about methods of doing that, but it may be a bit tricky
> so no promises.

Hi Pedro:

I have addressed this issue as of commit 6dd5069.  To test these
changes, I deliberately broke the Fortran compiler by specifying

export FFLAGS=-whatever

and here is the default diagnostic you now get in this case:

-- A test cmake run with language = Fortran enabled failed.
-- Specify -DENABLE_compiler_diagnostics=ON to see full CMake diagnostics concerning this failure.
-- WARNING: no working Fortran compiler so disabling f95 binding and examples.

So it is nice and quiet by default just like you asked for.

If you specify -DENABLE_compiler_diagnostics=ON, then here are the
diagnostics you get for that case:

-- A test cmake run with language = Fortran enabled failed with the following output:
---------------------------------------------------------------------------------------------------------
-- CMAKE_GENERATOR = Unix Makefiles
-- The Fortran compiler identification is unknown
-- Check for working Fortran compiler: /usr/bin/f95
-- Check for working Fortran compiler: /usr/bin/f95  -- broken
CMake Error at /home/software/cmake/install-3.5.2/share/cmake-3.5/Modules/CMakeTestFortranCompiler.cmake:54 (message):
   The Fortran compiler "/usr/bin/f95" is not able to compile a simple test
   program.

   It fails with the following output:

    Change Dir: /home/software/plplot/HEAD/build_dir/language_tests/Fortran/CMakeFiles/CMakeTmp



   Run Build Command:"/usr/bin/make" "cmTC_9e5f0/fast"

   /usr/bin/make -f CMakeFiles/cmTC_9e5f0.dir/build.make
   CMakeFiles/cmTC_9e5f0.dir/build

   make[1]: Entering directory
   '/home/software/plplot/HEAD/build_dir/language_tests/Fortran/CMakeFiles/CMakeTmp'

   Building Fortran object CMakeFiles/cmTC_9e5f0.dir/testFortranCompiler.f.o

   /usr/bin/f95 -whatever -c
   /home/software/plplot/HEAD/build_dir/language_tests/Fortran/CMakeFiles/CMakeTmp/testFortranCompiler.f
   -o CMakeFiles/cmTC_9e5f0.dir/testFortranCompiler.f.o

   f95: error: unrecognized command line option ‘-whatever’

   CMakeFiles/cmTC_9e5f0.dir/build.make:65: recipe for target
   'CMakeFiles/cmTC_9e5f0.dir/testFortranCompiler.f.o' failed

   make[1]: *** [CMakeFiles/cmTC_9e5f0.dir/testFortranCompiler.f.o] Error 1

   make[1]: Leaving directory
   '/home/software/plplot/HEAD/build_dir/language_tests/Fortran/CMakeFiles/CMakeTmp'

   Makefile:126: recipe for target 'cmTC_9e5f0/fast' failed

   make: *** [cmTC_9e5f0/fast] Error 2





   CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
   CMakeLists.txt:18 (enable_language)

-- Configuring incomplete, errors occurred!
See also "/home/software/plplot/HEAD/build_dir/language_tests/Fortran/CMakeFiles/CMakeOutput.log".
See also "/home/software/plplot/HEAD/build_dir/language_tests/Fortran/CMakeFiles/CMakeError.log".
---------------------------------------------------------------------------------------------------------
-- WARNING: no working Fortran compiler so disabling f95 binding and examples.

As you can see, the above details do include the specific issue (which
in this case is that the "-whatever" option is not recognized by
gfortran).   So -DENABLE_compiler_diagnostics=ON should be useful
to users when the missing or broken compiler is a surprise for them.

Finally, for completeness here are the diagnostics you get with a working Fortran
compiler:

-- The Fortran compiler identification is GNU 4.9.2
-- Check for working Fortran compiler: /usr/bin/gfortran
-- Check for working Fortran compiler: /usr/bin/gfortran  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/bin/gfortran supports Fortran 90
-- Checking whether /usr/bin/gfortran supports Fortran 90 -- yes
-- Check if isnan function is available in fortran
-- Check for isnan in fortran - not found
-- NOTICE: Found: /usr/bin/gfortran

I am happy with this resolution of the issue, and thanks for drawing
it to my attention in the first place!

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-devel] The wxwidgets device driver speed/idle time

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

Hi Phil:

I got tired of speculating about more efficient Linux IPC methods so I
implemented (as of commit e166866) the "Unnamed semaphores example"
paradigm outlined starting on page 73 of
<http://man7.org/conf/lca2013/IPC_Overview-LCA-2013-printable.pdf>. (I
discussed this possibility in earlier versions of this thread.)
This test project is described in cmake/test_linux_ipc/README.  Follow
the directions there to test it on your own Linux systems.

My tests show this method is quite efficient for transferring data
between processes on POSIX-compliant systems.  The transfer process is
under complete control of unnamed semaphores that reside in the shared
memory so coordinating required data transfer between two applications
is completely straightforward, and there is very little idle time
required during these transfers.

The IPC-relevant routines that are called in this test project are
shm_open, ftruncate, mmap, sem_init, sem_wait, sem_post, and
shm_unlink, and according to the Linux man pages, all of these
functions are provided by platforms that are compliant with POSIX.1-2001.

So on the present evidence from this test project I think this method
looks extremely promising for efficiently transferring data both ways
between -dev wxwidgets and wxPLViewer for POSIX-compliant systems.

If after trying the test of the method documented in 
cmake/test_linux_ipc/README you agree with this assessment, would you
be willing to have a go at the required wxwidgets and wxPLViewer
source code changes to see if that essentially eliminates the
large idle times we have now on Linux?

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-devel] [Bug] Plmap omits lines at the left hand side of themap

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

Hi Mark
Thanks for the report. I'll have a look at your example over the weekend and see if I can fix the issue.

Phil

Sent from my Windows 10 phone

From: Mark de Wever
Sent: 18 November 2016 11:06
To: plplot-dev
Subject: [Plplot-devel] [Bug] Plmap omits lines at the left hand side of themap

Hi,

Recently I ran into an issue with the plplot 5.11.1 on Windows. The 
plmap code seems to omit lines entirely when a part of the line is not 
visible. This only occurs when the line is not visible on the left hand 
side of the plot. When a part is not visible on the right hand side it 
is properly shown.

At my Debian Stable system I use the system's 5.10.0 version. There the 
issue doesn't occur. (I noticed the plmap code has been rewritten 
between 5.10.0 and 5.11.0.) I also tested the bug on Debian Stable with 
5.11.1 and a recent master [d71e48], both have the issue.

Attached a modified example 19 where the bug is shown. The first plot 
shows the entire coast of Ireland. The second plot should only omit a 
small part of the coast, but instead the entire coast has been removed. 
Only the internal border of Ireland remains visible. This seems to 
happen with all coast lines; I picked Ireland since it shows the bug nicely.


Regards,
Mark de Wever

PS: It seems the old deprecated plmap code no longer shows a map (at 
least on Windows). I didn't investigate further, I just installed the 
shapelib library.

PPS: There also seems to be another issue with a filled polygon map, but 
I'm still investigating. If it really is an issue, I'll report it.

Re: [Plplot-devel] How to build with QT5?

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

On 11/18/2016 02:34 AM, Alan W. Irwin wrote:
> On 2016-11-17 20:43-0500 Hazen Babcock wrote:
>
>> Sorry, it appears that I was missing the qttools5-dev package.
>
> Glad that "how to build" issue is sorted out.
>
>> As an aside it looks like x02c works fine with Qt5 even in -fam mode.
>
> Does that mean valgrind reports no memory management issues?  That is
> a pretty reliable measurement of the probability of encountering
> segfaults with Qt5, and would be an important improvement compared to
> my Qt5 version 5.3.2 from Debian Jessie.

I just meant that it ran without segfaulting. However it does also seem 
to have fewer invalid reads than the Qt4 equivalent.

$ qmake --version
QMake version 3.0
Using Qt version 5.5.1 in /usr/lib/x86_64-linux-gnu

-Hazen

[Plplot-devel] [Bug] Plmap omits lines at the left hand side of the map

[Mark de W. <m.d...@da...>]

Hi,

Recently I ran into an issue with the plplot 5.11.1 on Windows. The 
plmap code seems to omit lines entirely when a part of the line is not 
visible. This only occurs when the line is not visible on the left hand 
side of the plot. When a part is not visible on the right hand side it 
is properly shown.

At my Debian Stable system I use the system's 5.10.0 version. There the 
issue doesn't occur. (I noticed the plmap code has been rewritten 
between 5.10.0 and 5.11.0.) I also tested the bug on Debian Stable with 
5.11.1 and a recent master [d71e48], both have the issue.

Attached a modified example 19 where the bug is shown. The first plot 
shows the entire coast of Ireland. The second plot should only omit a 
small part of the coast, but instead the entire coast has been removed. 
Only the internal border of Ireland remains visible. This seems to 
happen with all coast lines; I picked Ireland since it shows the bug nicely.


Regards,
Mark de Wever

PS: It seems the old deprecated plmap code no longer shows a map (at 
least on Windows). I didn't investigate further, I just installed the 
shapelib library.

PPS: There also seems to be another issue with a filled polygon map, but 
I'm still investigating. If it really is an issue, I'll report it.

Re: [Plplot-devel] How to build with QT5?

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

On 2016-11-17 20:43-0500 Hazen Babcock wrote:

> Sorry, it appears that I was missing the qttools5-dev package.

Glad that "how to build" issue is sorted out.

> As an aside it looks like x02c works fine with Qt5 even in -fam mode.

Does that mean valgrind reports no memory management issues?  That is
a pretty reliable measurement of the probability of encountering
segfaults with Qt5, and would be an important improvement compared to
my Qt5 version 5.3.2 from Debian Jessie.

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-devel] How to build with QT5?

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

On 11/17/2016 07:26 PM, Alan W. Irwin wrote:
>
> Hi Hazen:
>
> My recent set of changes introduced no changes concerning the meaning
> of PLPLOT_USE_QT5.  In fact, my recent tests of those changes (see my
> commit message) show Plplot builds properly here with both
> -DPLPLOT_USE_QT5=ON (i.e., Qt5) and -DPLPLOT_USE_QT5=OFF (i.e, Qt4).
> But in each case I used scripts/comprehensive_test.sh which
> automatically executes cmake in the ideal way, i.e., in an initially
> empty build tree.
>
> In your case, it looks like -DPLPLOT_USE_QT5=ON is being ignored and
> you are getting consistent Qt4 results instead.  (Your cache file
> reports PLPLOT_USE_QT5=OFF and nothing is found that is Qt5 related.)
>
> Is a dirty build tree reflecting previous Qt4 builds causing you the
> present difficulties with attempting to use Qt5?
>
> Of course, if that speculation is not correct, then the next thing you
> should do is look at your complete cmake output starting with an empty
> build tree and pristine source tree to see what it says regarding
> finding Qt5 when you specify -DPLPLOT_USE_QT5=ON.  If our build system
> cannot
> find Qt5 with -DPLPLOT_USE_QT5=ON it forces PLPLOT_USE_QT5 to
> OFF and falls back to looking for and using Qt4 in a consistent way.
>
> So either scenario (dirty build tree or cannot find Qt5) is consistent
> with your current cache file.

Sorry, it appears that I was missing the qttools5-dev package.

As an aside it looks like x02c works fine with Qt5 even in -fam mode.

-Hazen

Re: [Plplot-devel] How to build with QT5?

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

On 2016-11-17 16:35-0500 Hazen Babcock wrote:

>
> How does one get PLplot to build with QT5 now?
>
> This is what I used to do:
> cmake -DPLPLOT_USE_QT5=ON ../plplot
>
> However the cmake cache now has the following mistakes (or what appear to me 
> to be mistakes):
>
> //Enable pyqt4 Python extension module
> ENABLE_pyqt4:BOOL=ON
>
> //Enable pyqt5 Python extension module
> ENABLE_pyqt5:BOOL=OFF
>
> ..
>
> //Where can the qmake-qt4 library be found
> QT_QMAKE_EXECUTABLE:FILEPATH=/usr/bin/qmake-qt4
>
> PyQt4 will not work with Qt5, and qmake-qt4 also seems to be the wrong choice 
> for a Qt5 build.

Hi Hazen:

My recent set of changes introduced no changes concerning the meaning
of PLPLOT_USE_QT5.  In fact, my recent tests of those changes (see my
commit message) show Plplot builds properly here with both
-DPLPLOT_USE_QT5=ON (i.e., Qt5) and -DPLPLOT_USE_QT5=OFF (i.e, Qt4).
But in each case I used scripts/comprehensive_test.sh which
automatically executes cmake in the ideal way, i.e., in an initially
empty build tree.

In your case, it looks like -DPLPLOT_USE_QT5=ON is being ignored and
you are getting consistent Qt4 results instead.  (Your cache file
reports PLPLOT_USE_QT5=OFF and nothing is found that is Qt5 related.)

Is a dirty build tree reflecting previous Qt4 builds causing you the
present difficulties with attempting to use Qt5?

Of course, if that speculation is not correct, then the next thing you
should do is look at your complete cmake output starting with an empty
build tree and pristine source tree to see what it says regarding
finding Qt5 when you specify -DPLPLOT_USE_QT5=ON.  If our build system cannot
find Qt5 with -DPLPLOT_USE_QT5=ON it forces PLPLOT_USE_QT5 to
OFF and falls back to looking for and using Qt4 in a consistent way.

So either scenario (dirty build tree or cannot find Qt5) is consistent
with your current cache file.

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-devel] Speculation about why Qt5 sucks compared to Qt4

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

As my recent tests of the PLplot qt device driver have demonstrated the
Qt5 near-vanilla version that Debian Jessie gives access to really
sucks compared to their Qt4 version.

To attempt to understand why, I looked up the Qt history at
<https://en.wikipedia.org/wiki/Qt_(software)> and discovered that Qt4
was released in 2005 while the original company that was completely 
focussed on Qt and nothing else, Trolltech, was still in charge of Qt
support and development.  In contrast Qt5 was released in late 2012
long after Trolltech had disappeared thanks to Nokia's acquisition of
them and subsequent aquisitions/mergers.) So my speculation is the
poor quality of Qt5 is a reflection of its commercial support being
essentially a commercial football. (Otherwise, 4 years of feedback
from Qt5 users should have created a much better quality product with
essentially no memory management issues at all.)

Of course, recently (May this year) Qt development and support is
again the sole focus of a single independent company (now called "The
Qt Company", see <https://en.wikipedia.org/wiki/The_Qt_Company>), and
my hope is that improved focus should help to quickly and drastically
improve Qt5 based on customer bug reports so that it is finally
comparable in quality to Qt4.  But we will see how this goes...

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-devel] ctest failure with Qt file devices

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

On 2016-11-17 16:25-0500 Hazen Babcock wrote:

> On 11/17/2016 04:49 AM, Alan W. Irwin wrote:
>> 
>> So you will want to try that version as well.
>
> I'm still seeing the same problem.
>
>> However, if the example 2 memory management issues continue to show up
>> for qt4 (in contradiction to my good valgrind result above), then I
>> suspect your Qt4
>> library is not a very good one (since I am getting good results with
>> the Debian Jessie Qt4 library for all our standard examples).  So I
>> don't think it is worth your time trying to figure out this issue which
>> is very likely not our problem.
>> 
>> For the record what version of Qt4 and what Linux distro are you
>> running?
>
> $ qmake-qt4 --version
> QMake version 2.01a
> Using Qt version 4.8.7 in /usr/lib/x86_64-linux-gnu
>
> $ uname -a
> Linux hbabcock-laptop2 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 
> UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID:	Ubuntu
> Description:	Ubuntu 16.04.1 LTS
> Release:	16.04
> Codename:	xenial
>
> Back in 2010 we decided that it was a difference between the Gnome and KDE 
> desktops.

Hi Hazen:

I run a Debian Jessie KDE4 desktop (which depends on Qt4) in a really
basic way. (I do almost everything interesting using the command-line
available from an xterm.) But for that basic use the combination works
well as a desktop (e.g., essentially no run-time issues at all), and I
attribute that success to the Debian developers pretty much sticking
with the "vanilla" versions of KDE and Qt4.  And my recent PLplot tests
confirm the quality of the Debian Jessie version of Qt4.

In contrast to Debian, Ubuntu does have a long-standing and well known
bad track record for KDE/Qt support with the problem always seeming to
be they attempt to change it in a non-careful way from the "vanilla"
original designed carefully by the KDE and Qt developers.  Anyhow, the
result always tends to be buggy, and that seems to be confirmed by the
memory management issues you are encountering for Qt4 on Ubuntu.  I
think Ubuntu has one of the worst Qt track records in this regard so I
would suggest using a different distro such as Debian or a
Debian-based distro that is specifically not based on Ubuntu if you
want to get the best results for our qt devices.

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-devel] How to build with QT5?

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

How does one get PLplot to build with QT5 now?

This is what I used to do:
cmake -DPLPLOT_USE_QT5=ON ../plplot

However the cmake cache now has the following mistakes (or what appear 
to me to be mistakes):

//Enable pyqt4 Python extension module
ENABLE_pyqt4:BOOL=ON

//Enable pyqt5 Python extension module
ENABLE_pyqt5:BOOL=OFF

..

//Where can the qmake-qt4 library be found
QT_QMAKE_EXECUTABLE:FILEPATH=/usr/bin/qmake-qt4

PyQt4 will not work with Qt5, and qmake-qt4 also seems to be the wrong 
choice for a Qt5 build.

-Hazen

Re: [Plplot-devel] ctest failure with Qt file devices

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

On 11/17/2016 04:49 AM, Alan W. Irwin wrote:
>
> So you will want to try that version as well.

I'm still seeing the same problem.

> However, if the example 2 memory management issues continue to show up
> for qt4 (in contradiction to my good valgrind result above), then I
> suspect your Qt4
> library is not a very good one (since I am getting good results with
> the Debian Jessie Qt4 library for all our standard examples).  So I
> don't think it is worth your time trying to figure out this issue which
> is very likely not our problem.
>
> For the record what version of Qt4 and what Linux distro are you
> running?

$ qmake-qt4 --version
QMake version 2.01a
Using Qt version 4.8.7 in /usr/lib/x86_64-linux-gnu

$ uname -a
Linux hbabcock-laptop2 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 
19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.1 LTS
Release:	16.04
Codename:	xenial

Back in 2010 we decided that it was a difference between the Gnome and 
KDE desktops.

-Hazen

[Plplot-devel] Moved to automoc method

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

With commit 7bea18c, I have moved to the automoc method of generating
appropriate moc results for our Qt-related code.  Note, I have done
this for both the Qt4 and Qt5 cases.

This commit completes all but the pkg-config issues in the
long-standing project to update our Qt5 support to the latest
recommended CMake methods.  So all the PRIVATE/PUBLIC issues that were
giving us trouble before for the Qt5 case are now gone, and (except
for some remainig pkg-config issues) I am now completely happy with
how we build qt against Qt5 libraries.

N.B. I still view -DPLPLOT_USE_QT5=ON as an experimental option and
label it that way because of the known deficiencies of the Qt5 library
with regard to memory management.  For example, according to valgrind
such memory management issues show up quite systematically for 22 of
our 33 standard examples for -DPLPLOT_USE_QT5=ON, but in large
contrast there are no such issues for -DPLPLOT_USE_QT5=OFF so I am
going to leave that option OFF by default.

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-devel] ctest failure with Qt file devices

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

On 2016-11-16 12:20-0800 Alan W. Irwin wrote:

Hi Hazen:

I cannot verify the issue you are currently investigating
for example 2 and Qt4 here.  Instead, what I get here is

software@raven> valgrind examples/c/x02c -dev pngqt -fam -o test.pngqt
==24632== Memcheck, a memory error detector
==24632== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==24632== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==24632== Command: examples/c/x02c -dev pngqt -fam -o test.pngqt
==24632== 
==24632== 
==24632== HEAP SUMMARY:
==24632==     in use at exit: 278,874 bytes in 3,630 blocks
==24632==   total heap usage: 51,435 allocs, 47,805 frees, 19,826,765 bytes allocated
==24632== 
==24632== LEAK SUMMARY:
==24632==    definitely lost: 8,744 bytes in 45 blocks
==24632==    indirectly lost: 9,329 bytes in 213 blocks
==24632==      possibly lost: 4,676 bytes in 83 blocks
==24632==    still reachable: 256,125 bytes in 3,289 blocks
==24632==         suppressed: 0 bytes in 0 blocks
==24632== Rerun with --leak-check=full to see details of leaked memory
==24632== 
==24632== For counts of detected and suppressed errors, rerun with: -v
==24632== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

There are obviously memory leaks, but there is no memory management
issues (invalid reads or writes, for example) could cause this 
example to segfault due to heap corruption.

I then followed up by using the -DVALGRIND_ALL_TESTS=ON cmake option
and built the test_c_pngqt target to investigate for any memory
management issues for any of our examples. All those resulting
valgrind reports in examples/examples/valgrind.x*.log showed plenty of
leftover memory allocations after the "HEAP SUMMARY:" line at the end
of the report, but there were no actual memory management issues such
as invalid reads showing up during the actual executation of the
example that occurs before that "HEAP SUMMARY:" line is emitted by
valgrind. So there is no chance of Qt4 segfaults here due to heap
corruptions with our
standard examples, and that is also true of examples/c++/qt_example.

In contrast to the Qt4 case, Qt5 (version 5.3.2 from Debian Jessie) 
does show lots of memory management issues.  For example, 22 of the
examples had invalid reads while 11 of them did not according to the
above experiment, and there were invalid reads also for
examples/c++/qt_example. I attribute all those Qt5 memory management
issues to remaining memory management errors in Qt5 (at least the
Debian Jessie version of that library) since we have clean results for
Qt4, and our qt device uses Qt5 exactly like it uses Qt4.

All the above results were for the updated handling of Qt5 and Qt4
linking I have just completed (see commit 7bea18c).

So you will want to try that version as well.

However, if the example 2 memory management issues continue to show up
for qt4 (in contradiction to my good valgrind result above), then I suspect your Qt4
library is not a very good one (since I am getting good results with
the Debian Jessie Qt4 library for all our standard examples).  So I
don't think it is worth your time trying to figure out this issue which
is very likely not our problem.

For the record what version of Qt4 and what Linux distro are you
running?

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-devel] ctest failure with Qt file devices

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

On 2016-11-16 08:58-0500 Hazen Babcock wrote:

>> I also tried running it in gdb, where it did segfault with the following
>> backtrace:
>> 
>> (gdb) backtrace
>> #0  0x00007fffedf1012d in gtk_container_add () from
>> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
> ..
>> #18 0x0000000000400e5c in main (argc=1, argv=0x7fffffffdf38) at
>> /home/hbabcock/Code/plplot/examples/c/x02c.c:28
>> 
>> One thing that at least looks suspicious is frame #10:
>> initQtApp (isGUI=true)
>> 
>> Maybe isGUI should be false for the non-interactive devices?
>
> Never mind, I see that we have previously discussed isGUI and why it should 
> be true in 2010 in the thread: "tiffqt device hangs in test_noninteractive".

Sorry, still no time to do this myself, and your knowledge of the qt
device driver is much better than mine in any case.  However, the
quick gdb tutorial for this situation (if you need one) is the
following:

Establish an important breakpoint with

break initQtApp

Then run (from the start) with

run -dev pnqt -fam -o test.pngqt

The when that breakpoint is hit, run the "cont" command to continue
until you finally find the problematic call to initQtApp that
generates the segfault.  Count the number of times you have to
continue, and then run again with one less continue and then look more
carefully at the problematic call that ends in the segfault by
stepping through the code after the breakpoint is reached with "next"
and printing out all relevant variables until you reach the condition
that causes that segfault.

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-devel] ctest failure with Qt file devices

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

On 11/15/2016 10:47 PM, Hazen Babcock wrote:
>>
>> If I recall correctly example 2 moves through the pages in a unique
>> but legitimate way that other examples do not use so that may be
>> triggering this issue for the qt devices.  So I plan to take a look
>> later when I have finished up some other PLplot issues I am currently
>> dealing with unless you are able to solve this issue first on your own.
>>
>> Assuming you do want to investigate further on your own, I would try
>> compiling with
>>
>> export CFLAGS="-g"
>> export CXXFLAGS="-g"
>>
>> (so the valgrind results properly identify code lines and you can
>> attach a gdb session (if you like) whenever valgrind finds a memory
>> management issue.  Then run valgrind (with --db-attach=yes) on example
>> 2 with familying and a variety of qt devices to see if they all have
>> memory management issues and exactly what part of our qt code is
>> generating those.  My guess is it is something one or all of our qt
>> devices does wrong for the end-of-page processing in familying mode
>> for the unique way example 2 navigates through its two pages.
>
> Apparently --db-attach has been deprecated. My valgrind results are
> attached, but I'm not sure they tell us that much as (naturally) the
> example does not segfault when run in the context of valgrind.
>
> I also tried running it in gdb, where it did segfault with the following
> backtrace:
>
> (gdb) backtrace
> #0  0x00007fffedf1012d in gtk_container_add () from
> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
..
> #18 0x0000000000400e5c in main (argc=1, argv=0x7fffffffdf38) at
> /home/hbabcock/Code/plplot/examples/c/x02c.c:28
>
> One thing that at least looks suspicious is frame #10:
> initQtApp (isGUI=true)
>
> Maybe isGUI should be false for the non-interactive devices?

Never mind, I see that we have previously discussed isGUI and why it 
should be true in 2010 in the thread: "tiffqt device hangs in 
test_noninteractive".

-Hazen

Re: [Plplot-devel] libplplottcltk now has a pure redacted API

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

Hi Alan,



See my answers below.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, November 15, 2016 9:14 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: libplplottcltk now has a pure redacted API
>
> Hi Arjen:
>
> Thanks for your report.
>
> On 2016-11-15 11:59-0000 Arjen Markus wrote:
>
> > I ran the comprehensive tests for Cygwin and MinGW (no interactive
> tests) as well as the interactive comprehensive tests for Cygwin. The non-
> interactive tests were perfect for both platforms. But I had some trouble with the set
> of interactive tests [....]
>
> > [out of order] The oddities seem to be related to Cygwin and the set-up I use,
> rather than the redacted Tcl interface.
>
> That sounds promising, and I may have some further comments about those
> oddities once I see the tarball report(s) from running scripts/comprehensive_test.sh
> that I request below.
>
> I hope "MinGW" is shorthand for MinGW-w64/MSYS2 for the reasons we have
> discussed before, but could you confirm that please?
>

AM: Yes, simple shorthand. Nowadays I always use that version, unless I have compelling reasons to do something else.

> Also, you appear to be having some trouble with the interactive case and did not
> report back any *.out results.  Therefore, I have now changed my mind and would
> like you to run true comprehensive tests (if you were not doing that before).  That is,
> please run scripts/comprehensive_test.sh and send me the report tarball that
> creates to give me all the data I need to make intelligent comments on your results.
> To keep those tests short and to the point of testing just the Tcl/Tk bindings and
> examples, I highly recommend the
>
> --cmake_added_options "-DDEFAULT_NO_DEVICES=ON -DPLD_ntk=ON -
> DPLD_tk=ON -DPLD_tkwin=ON -DPLD_xwin=ON -DPLD_ps=ON -
> DDEFAULT_NO_BINDINGS=ON -DENABLE_tcl=ON -DENABLE_tk=ON -
> DENABLE_itcl=ON -DENABLE_itk=ON"
>
> option for scripts/comprehensive_test.sh.  Also, for now, I would limit it to the
> shared case for just the build tree (i.e., the test I requested before from you, but
> with the better report facilities provided by this script) using the
>
> --do_nondynamic no --do_static no --do_test_install_tree no --
> do_test_traditional_install_tree no
>
> script options.
>

AM: Ah, I missed that bit and ran the script using the above options instead.

> > -        The Cygwin interactive tests ran for some 5 hours - then I interrupted the
> script. I came across the same tests so many times that I started to suspect an
> infinite loop. Not sure what to make of it.
>
> As I recall, your previous Cygwin interactive tests were incredibly slow (because
> those tests [other than the ones that use -dev ntk] are all done directly or indirectly
> with X, and Cygwin X is very slow). So
> 5 hours might be typical if you are running all our interactive tests for all our major
> configurations, and for build tree, install tree, and traditional install tree. So when
> you attempt to do this again using scripts/comprehensive_test.sh, make sure to
> limit what is tested as I recommend above.  I would hope that severe limiting of the
> components, the build configurations, and the trees that are tested would allow both
> the interactive and noninteractive parts of this test to complete in a much more
> reasonable length of time.
>

AM: the non-interactive tests take no more than half an hour or so. It is the interactive tests that take the time. Partly due to the extreme slowness of the Cygwin X server - I can see the graph being built up, which is excruciatingly slow for the transformed Chloe picture ;). However, I have seen it being drawn much more often than I had imagined.

If I run a window manager like twm, I do get a cursor, so that navigation is easier. I will have to use the various devices more systematically than I had time for yesterday. Not everything seems to be working properly - or my expectations are wrong, so that is something I want to look into a bit closer.

> > -        Some of the programs running the NTK device did not produce any graphs,
> which is odd.
>
> The point of these mass interactive tests is to check for important run-time issues
> such as segfaults with all our interactive devices.
> But clicking through all the pages of those results by hand would get old very
> quickly.  So to make that burden a lot lighter these mass tests use the -np option.
>
> But if you compare the results from
>
> examples/c/x00c -dev ntk -np
>
> and
>
> examples/c/x00c -dev ntk
>
> you may find the former just gives you a "flash" of the final result on the screen
> which may be hard to see.
>
> When in doubt you can run the latter form of the command by hand, but that would
> get old very quickly if you were doing that for all our standard examples and all our
> interactive devices!  :-)
>


AM: I ran the MinGW-w64/MSYS2 examples manually with the ntk device and they all run fine. When I run the runAllDemos.tcl program to do all of them, I do get a segmentation fault. Could that be due to the very large number of graphs that are produced that way (several hundreds, all remaining in memory)?

When I run the comprehensive interactive tests (see attachment) on this platform I get a segmentation fault as well - from the output I cannot deduce which program or which step was responsible, though, as messages come in out of order.

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] libplplottcltk now has a pure redacted API

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

Hi Alan,



I have not tested the ntk device on Windows just yet. I can probably find some time today to do so.



Regards,



Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, November 15, 2016 9:17 PM
>
> Does -dev ntk produce good results on this platform as well?
>

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] ctest failure with Qt file devices

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

On 11/15/2016 03:36 PM, Alan W. Irwin wrote:
>
>> This is happening with Qt4, specifically:
>
> OK. That very likely means this is our problem and nothing
> to do with Qt4.
>
>> [this] command does not segfault:
>> ./x02c -dev pngqt -o ex2.png
>>
>> But it does segfault in family mode:
>> ./x02c -fam -dev pngqt -o ex2.png
>
> If I recall correctly example 2 moves through the pages in a unique
> but legitimate way that other examples do not use so that may be
> triggering this issue for the qt devices.  So I plan to take a look
> later when I have finished up some other PLplot issues I am currently
> dealing with unless you are able to solve this issue first on your own.
>
> Assuming you do want to investigate further on your own, I would try
> compiling with
>
> export CFLAGS="-g"
> export CXXFLAGS="-g"
>
> (so the valgrind results properly identify code lines and you can
> attach a gdb session (if you like) whenever valgrind finds a memory
> management issue.  Then run valgrind (with --db-attach=yes) on example
> 2 with familying and a variety of qt devices to see if they all have
> memory management issues and exactly what part of our qt code is
> generating those.  My guess is it is something one or all of our qt
> devices does wrong for the end-of-page processing in familying mode
> for the unique way example 2 navigates through its two pages.

Apparently --db-attach has been deprecated. My valgrind results are 
attached, but I'm not sure they tell us that much as (naturally) the 
example does not segfault when run in the context of valgrind.

I also tried running it in gdb, where it did segfault with the following 
backtrace:

(gdb) backtrace
#0  0x00007fffedf1012d in gtk_container_add () from 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#1  0x00007ffff53095ee in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#2  0x00007ffff530a61e in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#3  0x00007ffff530d4be in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#4  0x00007ffff52efe01 in QGtkStyle::QGtkStyle() () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#5  0x00007ffff5276cbd in QStyleFactory::create(QString const&) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#6  0x00007ffff4f68cce in QApplication::style() () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#7  0x00007ffff4f69115 in QApplicationPrivate::initialize() () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#8  0x00007ffff4f692aa in QApplicationPrivate::construct(_XDisplay*, 
unsigned long, unsigned long) ()
    from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#9  0x00007ffff4f69678 in QApplication::QApplication(int&, char**, bool, 
int) ()
    from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#10 0x00007ffff5cf1092 in initQtApp (isGUI=true) at 
/home/hbabcock/Code/plplot/drivers/qt.cpp:104
#11 0x00007ffff5cf136f in plD_init_rasterqt (pls=0x7ffff7dccee0 <pls0>) 
at /home/hbabcock/Code/plplot/drivers/qt.cpp:279
#12 0x00007ffff7b69de1 in plP_init () at 
/home/hbabcock/Code/plplot/src/plcore.c:144
#13 0x00007ffff7b7b7ce in plGetFam (pls=0x7ffff7dccee0 <pls0>) at 
/home/hbabcock/Code/plplot/src/plctrl.c:2781
#14 0x00007ffff5cf2334 in plD_bop_pngqt (pls=0x7ffff7dccee0 <pls0>) at 
/home/hbabcock/Code/plplot/drivers/qt.cpp:578
#15 0x00007ffff7b6a027 in plP_bop () at 
/home/hbabcock/Code/plplot/src/plcore.c:211
#16 0x00007ffff7b97894 in c_plbop () at 
/home/hbabcock/Code/plplot/src/plpage.c:125
#17 0x0000000000400ed9 in demo2 () at 
/home/hbabcock/Code/plplot/examples/c/x02c.c:70
#18 0x0000000000400e5c in main (argc=1, argv=0x7fffffffdf38) at 
/home/hbabcock/Code/plplot/examples/c/x02c.c:28

One thing that at least looks suspicious is frame #10:
initQtApp (isGUI=true)

Maybe isGUI should be false for the non-interactive devices?

-Hazen