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

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

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 <Ala...@gm...>
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 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 needs of our 14th
> standard example.
>
> Also, for your next version of the patch will you please try all the
> relevant
> test targets and then report those testing results in a "Tested by":
> stanza similar to the following?
>
> Tested by: António R. Tomé <ar...@gm...> on the <specify your
> platform details, e.g., Linux distribution name and version but also
> including your qt5.15.2 version> platform by configuring PLplot,
> building the test_pyqt5_example, test_qt_example, test_memqt_example,
> and test_c_qtwidget targets with no configuration, build, run-time, or
> GUI issues.
>
> Because our two Qt5 platforms are so different it is essential to test on
> both platforms.  So I plan to do these tests also and append my own
> "Tested by:" stanza to yours as
> follows (once those tests all succeed):
>
> Tested by: Alan W. Irwin <ai...@us...> on Linux
> (Debian Buster = Stable with qt5.11.3) by configuring PLplot, building
> the test_pyqt5_example, test_qt_example, test_memqt_example, and
> test_c_qtwidget targets with no configuration, build, run-time, or GUI
> issues.
>
> By the way, what I mean by no GUI issues above is that for the test targets
> that allow you to interact with a GUI (i.e., everything but
> test_c_qtwidget which because of the -np option for that test just
> runs through a critical subset of our standard examples automatically
> with no user intervention), you have exercised all possible actions
> (including exiting from the GUI which is always critical) to make sure
> all those GUI actions work).
>
> Also, if you have any trouble getting test_pyqt5_example to configure,
> remember you have to have the latest python3 and sip development
> packages installed for your platform.  Note I have included that
> possibility (if you have time to test it) because it already generates
> deprecated warnings here on my older platform, and it would be good to get
> our pyqt5 example future-proofed as well.
>
> For all those here wondering about the hiatus (for the last year now)
> in my PLplot development work, the reason for that is I am spending
> virtually 100 % of my current development time on FreeEOS with the
> goal of getting out a critical release for that software soon which
> will include all my work on modernizing that Fortran code (e.g., by
> using Fortran 2008 best practices) and by comprehensively testing that
> code's results.  So all that I have had time for from the PLplot
> perspective is to monitor other's PLplot development activities and
> help out where I can (as in the present segfault report to António).
>
> Of course, after that FreeEOS release is completed, I do hope to
> return to a more active PLplot development role starting with a fix to
> a pllegend issue (incorrect vertical line spacing when there are
> subscripts or superscripts in the legend text) that has been exposed
> by many of the FreeEOS research plots I have been producing using
> PLplot.  Of course, if you look back at the PLplot history, I first
> got active in PLplot development because of PLplot issues turned up by
> FreeEOS.  So it looks like my strong motivation for helping to develop
> PLplot will be continuing just like always!  :-)
>
> 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:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013