Re: [Plplot-devel] plplot qt driver deprecated functions

[Alan W. Irwin]

Hi António:

Based on the testing information you supplied I have now pushed your
commit (with revised commit message but no other changes).  See 
.

On 2021-08-04 11:33+0100 António Rodrigues Tomé wrote:


And for qt6 I kind hijacked the qt5 optins and just  replaced the
conditions for qt5 with the ones for qt6
cmake/modules/qt.cmake

and some of the
CMakeLists.txt

CMakeLists.txt
bindings/qt_gui/CMakeLists.txt
examples/c++/CMakeLists.txt
src/CMakeLists.txt



[...O]ne must decide if to keep two distinct options choose qt5
or qt5 or let the system decide what to use.
[...C]hanges were very slim. most of them were replacing QT5:: by Qt6::
but for the qt.cmake that I also attach


I will likely implement a default of looking first for Qt6 then Qt5
(if the build system cannot find Qt6) but with an option for
knowledgeable users to force one or the other.

It will probably be several months until I can get to this (and it
will also be after I completely strip out Qt4), but based on the above
extremely useful information from you I think I now know what needs to
be done to fully support both Qt5 and Qt6 with our build system.

Cheers,

Alan
__
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

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.org); 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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] plplot qt driver deprecated functions

[Alan W. Irwin]

On 2021-08-03 12:20+0100 António Rodrigues Tomé wrote:


Hi Alan

I was able to build the plplot using qt6.1 and found out that there were
other classes (the 2D transformation Matrix class) that were dropped in
qt6. So I made a small patch replacing that class and some others minor
changes with function members that became deprecated in qt 6.0

I've tested it in my default qt 5.15 and in the latest qt6.1.2  version.
Everything looks to work very fine.
So I think that when the time is right one can face without any worries the
transition from qt5 to qt6 without the need to use the Core5Compat package.


Hi António:

Thanks for this next step in future-proofing PLplot for the Qt6 case.

For your commit I built the test_all_qt target without issues for my Debian 
Stable
Qt5.11 case so I am ready to push your commit as soon as you can
clarify (for the associated commit message) how you tested it with
both Qt5 and Qt6.

What method did you use to build our qt-related components for the Qt6 case
since our build system is not currently ready for Qt6?  For example, did
you build all those PLplot components by hand?

And for both the Qt5 and Qt6 cases did you build the test_all_qt
target or did you use some other method to run-time test your commit?

It is going to be a while until I can do this, but obviously my next
Qt-related step here is to strip out all Qt4 from our build system
(which will greatly simplify builds of our Qt-related components
because builds against Qt4 use ancient CMake methods while builds
against later Qt versions use quite different and much more powerful
modern CMake methods).

Also considering the problem of supporting both Qt5 and Qt6 I will need
more information from you.  For example, how far do you get with
the following change to line 144 of cmake/modules/qt.cmake and
using -DENABLE_pyqt5=OFF (since pyqt5 is unlikely to work with Qt6).

- find_package(Qt5 5.7.1 COMPONENTS Svg Gui PrintSupport Widgets)
+ find_package(Qt6 6.1.2 COMPONENTS Svg Gui PrintSupport Widgets)
+ # temporary workaround
+ set(Qt5_FOUND Qt6_FOUND)

please capture the stdout and stderr output from cmake and make using

cmake  >& cmake.out
# Only if cmake works
make VERBOSE=1 test_all_qt >& test_all_qt.out

and send those *.out files to me.

Alan
__
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

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.org); 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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] plplot qt driver deprecated functions

[António Rodrigues Tomé]

Hi Alan

I was able to build the plplot using qt6.1 and found out that there were
other classes (the 2D transformation Matrix class) that were dropped in
qt6. So I made a small patch replacing that class and some others minor
changes with function members that became deprecated in qt 6.0

I've tested it in my default qt 5.15 and in the latest qt6.1.2  version.
Everything looks to work very fine.
So I think that when the time is right one can face without any worries the
transition from qt5 to qt6 without the need to use the Core5Compat package.

cheers



On Thu, Jul 8, 2021 at 12:26 AM Alan W. Irwin 
wrote:

> On 2021-07-06 23:34+0100 António Rodrigues Tomé wrote:
>
> > [... I built] all the examples and the patch i send you now seems to work
> > very fine:
>
> Same here so I pushed it.  See
> <
> https://sourceforge.net/p/plplot/plplot/ci/cf04f2e6b555edab673a9703cea909d7239ce21b/
> >
> for the substantially changed commit message that includes details of
> the tests I ran.
>
> Thanks very much for getting this revised version of your commit to work
> without generating
> the segfaults produced by the prior version.
>
> > P.s. Latter on I will try to understand how to deploy  pyqt5_example.
>
> The missing Python library issue that was previously stopping you can
> obviously be addressed by installing the right opensuse package.  But
> finding the name of that needed package is more "an art rather than a
> science".
>
> To help you with that "art" here are the equivalent details on my
> Debian Stable platform.
>
> # Find the names of all packages which include a partial filename
> "libplplot*.so$"
> # where ".so" with nothing further added is important since it is that
> exact suffix the linker looks for.
> irwin@merlin> apt-file search libpython |grep '\.so$' |less
>
> There were 17 different possibilities, but one of those
>
> libpython3.7-dev: /usr/lib/x86_64-linux-gnu/libpython3.7m.so
>
> referred to the development version of libpython3 so I am sure
> that is the library that is needed, and I do have that package
> already installed.  So I think this
> result for Debian Stable means you need to install the development
> version of either the python3 or libpython3 package (depending on how
> opensuse organizes its package names and designates the name of the
> development version of those).  Of course, opensuse will not have
> the apt-file application, but it should have something equivalent so
> that you can associate filenames with the packages (either installed
> or not installed) that include those files.
>
> After a successful build I confirmed that /usr/lib/x86_64-linux-gnu/
> libpython3.7m.so name as follows:
>
> # Find the exact name of that library (at least for Debian Stable after a
> successful build
> of the python binding):
>
> software@merlin> readelf -d bindings/python/_plplotc.so |grep -E
> 'PATH|NEEDED'
>   0x0001 (NEEDED) Shared library: [libplplot.so.17]
>   0x0001 (NEEDED) Shared library:
> [libpython3.7m.so.1.0]
>   0x0001 (NEEDED) Shared library: [libc.so.6]
>   0x001d (RUNPATH)Library runpath:
> [/home/software/plplot/HEAD/build_dir/src:]
>
> Hope this working Debian Stable example helps you figure out what to do
> for opensuse to gain
> access to that distro's python3 library.
>
> > also going to try to see how i can force plplot to build with qt6 and
> then
> > one will know if this small patch is enough to deal with the next major
> > version of the qt,
>
> Good luck implementing these important Qt6-ready goals for PLplot.
>
> Alan
> __
> Alan W. Irwin
>
> Research affiliation with the Department of Physics and Astronomy,
> University of Victoria, Victoria, BC, Canada.
>
> 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.org); 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:
art...@gmail.com
art...@ubi.pt
http://www.researcherid.com/rid/A-5681-2013
From c8fcaf873dbe2f142d668971b5e3b2ff85c45e5b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ant=C3=B3nio=20Rodrigues=20Tom=C3=A9?= 
Date: Tue, 3 Aug 2021 11:16:51 +0100
Subject: [PATCH] This patch resulted from the first qt6 testing. there where
 still some classes  that are no long present in qt6. The patch was tested in
 Opensuse leap15.3   Using Qt version 5.15.2 from kde opensude official
 repositories. And also tested using opensuse leap15.3 Q6.1.2 from the
 offiocial qt account https://login.qt.io/. Please be aware this is only a
 patch to the c++ qt driver 

Re: [Plplot-devel] plplot qt driver deprecated functions

[Alan W. Irwin]

On 2021-07-06 23:34+0100 António Rodrigues Tomé wrote:


[... I built] all the examples and the patch i send you now seems to work
very fine:


Same here so I pushed it.  See

for the substantially changed commit message that includes details of
the tests I ran.

Thanks very much for getting this revised version of your commit to work 
without generating
the segfaults produced by the prior version.


P.s. Latter on I will try to understand how to deploy  pyqt5_example.


The missing Python library issue that was previously stopping you can
obviously be addressed by installing the right opensuse package.  But
finding the name of that needed package is more "an art rather than a science".

To help you with that "art" here are the equivalent details on my
Debian Stable platform.

# Find the names of all packages which include a partial filename 
"libplplot*.so$"
# where ".so" with nothing further added is important since it is that exact 
suffix the linker looks for.
irwin@merlin> apt-file search libpython |grep '\.so$' |less

There were 17 different possibilities, but one of those

libpython3.7-dev: /usr/lib/x86_64-linux-gnu/libpython3.7m.so

referred to the development version of libpython3 so I am sure
that is the library that is needed, and I do have that package
already installed.  So I think this
result for Debian Stable means you need to install the development
version of either the python3 or libpython3 package (depending on how
opensuse organizes its package names and designates the name of the
development version of those).  Of course, opensuse will not have
the apt-file application, but it should have something equivalent so
that you can associate filenames with the packages (either installed
or not installed) that include those files.

After a successful build I confirmed that 
/usr/lib/x86_64-linux-gnu/libpython3.7m.so name as follows:

# Find the exact name of that library (at least for Debian Stable after a 
successful build
of the python binding):

software@merlin> readelf -d bindings/python/_plplotc.so |grep -E 'PATH|NEEDED'
 0x0001 (NEEDED) Shared library: [libplplot.so.17]
 0x0001 (NEEDED) Shared library: [libpython3.7m.so.1.0]
 0x0001 (NEEDED) Shared library: [libc.so.6]
 0x001d (RUNPATH)Library runpath: 
[/home/software/plplot/HEAD/build_dir/src:]

Hope this working Debian Stable example helps you figure out what to do for 
opensuse to gain
access to that distro's python3 library.


also going to try to see how i can force plplot to build with qt6 and then
one will know if this small patch is enough to deal with the next major
version of the qt,


Good luck implementing these important Qt6-ready goals for PLplot.

Alan
__
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

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.org); 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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] plplot qt driver deprecated functions

[António Rodrigues Tomé]

Hi Alan,

unfortunately I couldn't test the pyqt5_example as I do not use python and
in spite having it installed I couldn't understand exactly what else to
install but  trying to build plplot
i get
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.13",
minimum required is "3")
-- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES
PYTHON_INCLUDE_DIRS)

however I build all the examples and the patch i send you now seems to work
very fine:

cheers

P.s. Latter on I will try to understand how to deploy  pyqt5_example. I'm
also going to try to see how i can force plplot to build with qt6 and then
one will know if this small patch is enough to deal with the next major
version of the qt,





On Sun, Jun 6, 2021 at 10:33 PM Alan W. Irwin 
wrote:

> Hi António:
>
> On 2021-06-05 20:53+0100 António Rodrigues Tomé wrote:
>
> > Hi Alan,
> >
> > I hope you are well and managed to be free of the virus.
>
> So far so good.  And I hope that is true for everyone on this list
> and their close families!
>
> > new versions of QT5 produce some warnings about the use of  deprecated
> > functions in the driver.
> > The new qt6 will remove most of the obsolete functions,  unless one uses
> an
> > additional back compatibility module. Namely the  QLinkedList will no
> > longer be supported in qt6.
> >
> > So I send you a patch where I replace all the functions that (my qt5.15.2
> > versions) warns about.
> > I think that everything will work fine even with older qt versions,
> >
> > This was needed mainly because for qt6 it will be necessary.
>
> Thanks, António for making this effort to future-proof the PLplot qt
> component.
> You are very close to something I would be happy to push, but there is
> a regression in results that you need to fix in your patch.
>
> Here are the details concerning that regression.
>
> Your patch builds fine here on my Debian Buster = Stable with qt5.11.3
> platform and gives good run-time test results when I build the
> test_pyqt5_example (other than some deprecation warnings that eventually
> do need to be fixed), test_qt_example, and test_memqt_example targets
>
> However, it introduces a segfault regression when I attempt to build
> the test_c_qtwidget target.
>
> The previous (before your patch was applied) result for that target showed
> no warnings or errors for that target.  And there continue to be no
> warnings with this target when your patch is applied.  However,
> here is the error result for that case:
> Generate C results for qtwidget interactive device
> Testing subset of C examples for device qtwidget
> x01c
> x04c
> x08c
> x16c
> x24c
> x30c
> x14c
> /home/software/plplot/HEAD/build_dir/plplot_test/test_c_interactive.sh:
> line 47:  3746 Segmentation fault  $DEBUG_CMD "$cdir"/x${index}${lang}
> -dev $device $NP_OPTION 2> c_interactive_${device}_test.error >|
> "${OUTPUT_DIR}"/x${index}${lang}_${device}.txt
> make[3]: *** [examples/CMakeFiles/test_c_qtwidget.dir/build.make:58:
> examples/CMakeFiles/test_c_qtwidget] Error 1
> make[2]: *** [CMakeFiles/Makefile2:6635:
> examples/CMakeFiles/test_c_qtwidget.dir/all] Error 2
> make[1]: *** [CMakeFiles/Makefile2:6642:
> examples/CMakeFiles/test_c_qtwidget.dir/rule] Error 2
> make: *** [Makefile:2108: test_c_qtwidget] Error 2
>
> So it looks like all examples other than x14c work correctly with your
> patch, but
> x14c (which has quite special needs) apparently exposes an issue with your
> patch.
>
> In fact, after that test_c_qtwidget target was built (in order to build all
> necessary prerequisites) I could replicate the above segfault with
>
> software@merlin> examples/c/x14c -dev qtwidget
> Demo of multiple output streams via the qtwidget driver.
> Running with the second stream as slave to the first.
>
> Segmentation fault
>
> AND
>
> for a *fresh* configuration and build with
>
> software@merlin> printenv |grep FLAG
> FFLAGS=-g
> CXXFLAGS=-g
> CFLAGS=-g
>
> I confirmed the segfault (with these quite different compiler options)
> and also obtained the attached valgrind result determined
> from (after a build of the test_c_qtwidget target to build all
> prerequisites)
>
> valgrind --num-callers=400 examples/c/x14c -dev qtwidget 2>| valgrind.out
>
> Exactly the same test for the version of PLplot before your change
> produces the following results (if I keep hitting the enter key when
> the cursor was on the left-hand plot to proceed through the entire
> example successfully):
>
> software@merlin> valgrind --num-callers=400 examples/c/x14c -dev qtwidget
> ==9772== Memcheck, a memory error detector
> ==9772== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==9772== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==9772== Command: examples/c/x14c -dev qtwidget
> ==9772==
> Demo of multiple output streams via the qtwidget driver.
> Running with the second stream as slave to the first.
>
> ==9772==
> ==9772== HEAP SUMMARY:
> ==9772== in use at exit: 526,787 bytes in 6,853 

Re: [Plplot-devel] plplot qt driver deprecated functions

[Alan W. Irwin]

Hi António:

On 2021-06-05 20:53+0100 António Rodrigues Tomé wrote:


Hi Alan,

I hope you are well and managed to be free of the virus.


So far so good.  And I hope that is true for everyone on this list
and their close families!


new versions of QT5 produce some warnings about the use of  deprecated
functions in the driver.
The new qt6 will remove most of the obsolete functions,  unless one uses an
additional back compatibility module. Namely the  QLinkedList will no
longer be supported in qt6.

So I send you a patch where I replace all the functions that (my qt5.15.2
versions) warns about.
I think that everything will work fine even with older qt versions,

This was needed mainly because for qt6 it will be necessary.


Thanks, António for making this effort to future-proof the PLplot qt component.
You are very close to something I would be happy to push, but there is
a regression in results that you need to fix in your patch.

Here are the details concerning that regression.

Your patch builds fine here on my Debian Buster = Stable with qt5.11.3
platform and gives good run-time test results when I build the
test_pyqt5_example (other than some deprecation warnings that eventually
do need to be fixed), test_qt_example, and test_memqt_example targets

However, it introduces a segfault regression when I attempt to build
the test_c_qtwidget target.

The previous (before your patch was applied) result for that target showed no 
warnings or errors for that target.  And there continue to be no warnings with 
this target when your patch is applied.  However,
here is the error result for that case:
Generate C results for qtwidget interactive device
Testing subset of C examples for device qtwidget
x01c
x04c
x08c
x16c
x24c
x30c
x14c
/home/software/plplot/HEAD/build_dir/plplot_test/test_c_interactive.sh: line 47:  3746 Segmentation fault 
 $DEBUG_CMD "$cdir"/x${index}${lang} -dev $device $NP_OPTION 2> 
c_interactive_${device}_test.error >| "${OUTPUT_DIR}"/x${index}${lang}_${device}.txt
make[3]: *** [examples/CMakeFiles/test_c_qtwidget.dir/build.make:58: 
examples/CMakeFiles/test_c_qtwidget] Error 1
make[2]: *** [CMakeFiles/Makefile2:6635: 
examples/CMakeFiles/test_c_qtwidget.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:6642: 
examples/CMakeFiles/test_c_qtwidget.dir/rule] Error 2
make: *** [Makefile:2108: test_c_qtwidget] Error 2

So it looks like all examples other than x14c work correctly with your patch, 
but
x14c (which has quite special needs) apparently exposes an issue with your 
patch.

In fact, after that test_c_qtwidget target was built (in order to build all
necessary prerequisites) I could replicate the above segfault with

software@merlin> examples/c/x14c -dev qtwidget
Demo of multiple output streams via the qtwidget driver.
Running with the second stream as slave to the first.

Segmentation fault

AND

for a *fresh* configuration and build with

software@merlin> printenv |grep FLAG
FFLAGS=-g
CXXFLAGS=-g
CFLAGS=-g

I confirmed the segfault (with these quite different compiler options)
and also obtained the attached valgrind result determined
from (after a build of the test_c_qtwidget target to build all prerequisites)

valgrind --num-callers=400 examples/c/x14c -dev qtwidget 2>| valgrind.out

Exactly the same test for the version of PLplot before your change
produces the following results (if I keep hitting the enter key when
the cursor was on the left-hand plot to proceed through the entire
example successfully):

software@merlin> valgrind --num-callers=400 examples/c/x14c -dev qtwidget
==9772== Memcheck, a memory error detector
==9772== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9772== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==9772== Command: examples/c/x14c -dev qtwidget
==9772== 
Demo of multiple output streams via the qtwidget driver.

Running with the second stream as slave to the first.

==9772== 
==9772== HEAP SUMMARY:

==9772== in use at exit: 526,787 bytes in 6,853 blocks
==9772==   total heap usage: 216,516 allocs, 209,663 frees, 39,317,429 bytes 
allocated
==9772== 
==9772== LEAK SUMMARY:

==9772==definitely lost: 6,888 bytes in 40 blocks
==9772==indirectly lost: 5,109 bytes in 125 blocks
==9772==  possibly lost: 2,112 bytes in 6 blocks
==9772==still reachable: 512,678 bytes in 6,682 blocks
==9772== suppressed: 0 bytes in 0 blocks
==9772== Rerun with --leak-check=full to see details of leaked memory
==9772== 
==9772== For counts of detected and suppressed errors, rerun with: -v

==9772== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

So aside from some memory leaks (likely due to a Qt5-5.11.3 issue
rather than a PLplot issue) the 14th standard example runs perfectly
under valgrind before your patch.

I hope the attached detailed valgrind results for the segfault case
with your patch will help you to figure out how your patch needs to be
changed to fix this regression for the special