Re: [Plplot-devel] Cross-compilation of PLplot
On 2022-02-23 07:23- Arjen Markus wrote: Hi, Sebastian Ehlert asked me about cross-compilation of PLplot for different platforms as part of cond-forge/plplot-feedstock. He found out that this needs to be done in two steps, one to build the auxiliary programs for use on the native platform and the second for the actual cross-compilation. Does anyone have experience with this? What procedure would you recommend? Is there an easy way to make this build scenario easier? Hi Arjen: Andrew Ross got cross-compilation to work (with some limitations) back in 2009. I suggest if you haven't done so already you review that mailing list thread (which you can find with a subject line search for "cross compilation" in the plplot_devel mailing list archive at SF). Andrew commented in that thread that he had documented some of his cross-compilation experiences in our old wiki. All the contents of that old wiki were transferred to our SF wiki back when I established that SF wiki so his (dated) documentation/comments about cross-compilation should be accessible at our SF wiki. Indeed, if you search there, there are 7 wiki pages that mention "cross" so if you follow up on those hits (which I did not) I assume you will find what Andrew (and others?) wrote about cross compilation back in 2009 or so. Of course, if you make some modern progress with cross-compilation, please update the SF wiki accordingly following the wiki update procedure in README.developers. 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] The Debian PLplot fails
On 2021-10-30 20:33+0100 António Rodrigues Tomé wrote: Hi Alan I do not know if I will be able to solve in short/medium time whatever the problem is as I usually do not use python or pyqt. So I will try to learn what this is all about. Thanks for being willing to take this on. Sip (which is how we generate our pyqt bindings) advertises itself as a really easy-to-use method of generating such bindings. So by consulting that sip documentation page (referenced in my recent email), you might be able to very quickly figure out what to do for the latest sip version. If/when you get modern sip to generate our pyqt5 binding by hand, I would be happy to help with any CMake-related adjustments that need to be made. For example, I have just discovered that "sip -V" generates the sip version string which would allow me to create a simple CMake test for the sip version. That test would allow us to use the present method for old sip versions and any new method you figure out for later sip versions. 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] The Debian PLplot fails
On 2021-10-30 07:26+0200 Rafael Laboissière wrote: Yes, [-DENABLE_pyqt5=OFF] is the simplest way to get the package building without issues. However, from the point of view of the Debian distribution, this means that python3-plplot-qt should be dropped from the list of binary packages built from the plplot source package. This change that we have to tweak the package and, then, once uploaded, it will have to go through the NEW queue [*], in order to get the approval of the ftp-masters. Finally, when the PyQt/SIP issues will be fixed in the future, then we will have to tweak back the changes, reintroduce python3-plplot-qt and the package will have to got through the NEW queue again. I would rather prefer to wait until the issue is fixed upstream. There is no rush for that, because the next release of Debian stable will not happen any soon (the latest release was done this year and the Debian release life cycle is two years). To Rafael and António: @Rafael: It sounds like your "wait and see" strategy (instead of changing the package and putting it through the NEW queue potentially twice) is the right way to go. @both: I am not happy with how riverbankcomputing keeps breaking things for sip users with no explicit documentation of the breakage (as far as I could tell with my google searches, see yesterday's post). @António: If you prefer not to fix this season's breakage with the prospect of having to do it again every few years, then I would strongly lean toward removing our pyqt binding and example completely just to make our upstream life (and downstream packaging life) easier. 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] The Debian PLplot fails
On 2021-10-29 13:44-0700 Alan W. Irwin wrote: [...]I assume that our Qt developer, António Tomé, will eventually be able to find a way to build our pyqt5 bindings against sip 6.3.1, but that will likely take a while since sip is not very good (in my experience) at documenting what their churn is and how to adjust to it. To expand on that comment, google searches for sip are obfuscated by other (telephony) software called sip which has nothing to do with the sip we need. Therefore, I just did a number of google searches using site:riverbankcomputing.com (since that company is the author of the sip we need), and I could find no mention of sip release notes. I did find [sip documentation](https://www.riverbankcomputing.com/static/Docs/sip/index.html) which might help António find a solution (even though this documentation is for 6.4, and I could find no riverbankcomputing documentation for earlier versions of sip!) 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] The Debian PLplot fails
On 2021-10-29 13:42+0200 Rafael Laboissière wrote: Dear PLplot developers, The Debian plplot package is failing to build against version 6.3.1 of sip-tools. The latest correct build of the package was done against sit-tools 6.1.1.¹ This issue has been reported in Bug#997739.² This bug is tagged "serious". I could not find a way to fix it. If it is not fixed, then the plplot package will be removed from Debian testing and, consequently, from the next Debian release. Hi Rafael: Thanks for reporting this build issue against a new version of sip tools. My impression is our pyqt bindings have *always* been precarious because of the rather large sip churn, and this issue seems to be another example of that. I assume that our Qt developer, António Tomé, will eventually be able to find a way to build our pyqt5 bindings against sip 6.3.1, but that will likely take a while since sip is not very good (in my experience) at documenting what their churn is and how to adjust to it. Meanwhile, there is absolutely no need for packagers like yourself to give up on PLplot because one minor component of it does not build against new versions of libraries/tools. Instead, simply use (in this case) -DENABLE_pyqt5=OFF, and it should build and run without issues. 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
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 <https://sourceforge.net/p/plplot/plplot/ci/6a12ffe24060803e1d66ae457fa7663dc4ded5bf/>. 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
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
[Plplot-devel] Welcome to António as our newest core PLplot developer!
It is my pleasure to announce publicly that António Rodrigues Tomé has just become an official member of the PLplot core development team. (For a list of all official members of that team, see <https://sourceforge.net/p/plplot/_members/>.) António's primary development interest in PLplot is in that software's Qt5 related components, and he plans further changes (if necessary) for PLplot to make it compatible with Qt6 as well. It's great to have that Qt maintenance expertise on our core team because our Qt-related components provide some of our best-looking plots. However, I also encourage António to work on more than just the Qt-related components of PLplot if he spots anything else he would like to improve. Welcome, António! 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
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 __ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] What are the development priorities for the csironn library?
On 2021-07-04 01:16-0700 Alan W. Irwin wrote: [...* It "would be nice"] for libcsironn to change its dependence on libqhull to a dependence on libqhull_r. DONE (thanks mostly to Stefan). See <https://sourceforge.net/p/plplot/plplot/ci/b6023bf465e9b024d3b161ba52ef01a1aff3e901/> for the details. * It "would be nice" to update our fork to the latest version of nn-c. The reason I suggest this as a worthwhile goal is I assume that Pavel's fairly constant development of nn-c since 2003 has found and fixed more bugs in the nn-c code than we have found and fixed in our fork of that code. As a short-cut to make this development topic easier, our fork could continue to ignore everything in nn-c that is not relevant to the problem of interpolating from non-gridded sample points to gridded sample points, but see the next item below. I haven't looked at what would be required by this development topic, but my guess is it could be implemented by simply replacing the csironn routines with the corresponding nn-c routines while keeping just the part of of the csironn routines that set up and call the libqhull routines and/or fix bugs in the nn-c version of these routines that are already in csironn and which have not already been fixed by Pavel. So it might all end up as a glorious git conflict resolution. :-) * The above "would be nice" development topic should be done first, but in addition it "would be nice" to not strip nn-c at all. My guess is what was stripped was pretty minor stuff since the csironn ability to interpolate from non-gridded to gridded sample points captures all the essential functionality of nn-c. But regardless of that question, the result should be that csironn should have all the functionality of modern nn-c (i.e., it passes all nn-c tests) with the only changes being conversion of *all* triangle library calls to the equivalent libqhull calls. I would be happy to see patches or pushes implementing these development topics. :-) 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] What are the development priorities for the csironn library? (was Bug#990397: depends on deprecated qhull library)
Hi Timo: As a Debian user, I agreed with what you said all the way down the line concerning how Debian is dealing with this transition from libqhull to reentrant libqhull_r. Furthermore, it looks like there is already a patch submitted to upstream PLplot to solve this issue which I will be looking at fairly soon. If comprehensive testing works for that patch I will accept it upstream, and in that case and assuming Rafael's tests work as well, I assume Rafael will also accept that patch downstream in order to close your bug#990397 against PLplot as fixed. Best wishes for many more such quick fixes for this issue, 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] What are the development priorities for the csironn library? (was Bug#990397: depends on deprecated qhull library)
A message on this thread from Atri Bhattacharya bounced (presumably because he used a non-subscription return address). But as list administrator I saw that bounced message which turned out to be of immediate interest. So I am reposting it here without asking Atri to resubmit with subscription address == return address. Atri said: _ For openSUSE's plplot package, we have a patch to build against libqhull_r, kindly contributed by Stefan. Here is the bug reference which has the patch as an attachment: <https://sourceforge.net/p/plplot/bugs/196/>. Would be great to get this checked into plplot upstream. Hope that helps. _ Hi Atri: I don't know how I missed that PLplot bug report with a patch that from its title likely implements the csironn library development topic that I just discussed on this thread! Anyhow, thanks for drawing this patch to my attention, and I hope I have time to take a close look at in in the coming week or so. 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
[Plplot-devel] What are the development priorities for the csironn library? (was Bug#990397: depends on deprecated qhull library)
mplement. * It "would be nice" to update our fork to the latest version of nn-c. The reason I suggest this as a worthwhile goal is I assume that Pavel's fairly constant development of nn-c since 2003 has found and fixed more bugs in the nn-c code than we have found and fixed in our fork of that code. As a short-cut to make this development topic easier, our fork could continue to ignore everything in nn-c that is not relevant to the problem of interpolating from non-gridded sample points to gridded sample points, but see the next item below. I haven't looked at what would be required by this development topic, but my guess is it could be implemented by simply replacing the csironn routines with the corresponding nn-c routines while keeping just the part of of the csironn routines that set up and call the libqhull routines and/or fix bugs in the nn-c version of these routines that are already in csironn and which have not already been fixed by Pavel. So it might all end up as a glorious git conflict resolution. :-) * The above "would be nice" development topic should be done first, but in addition it "would be nice" to not strip nn-c at all. My guess is what was stripped was pretty minor stuff since the csironn ability to interpolate from non-gridded to gridded sample points captures all the essential functionality of nn-c. But regardless of that question, the result should be that csironn should have all the functionality of modern nn-c (i.e., it passes all nn-c tests) with the only changes being conversion of *all* triangle library calls to the equivalent libqhull calls. I hasten to add I don't want to discuss this "vapour ware" with Pavel until it turns into "real ware". However, if we accomplish that goal (i.e., if the updated csironn library passes all nn-c testing) I bet Pavel (who is a really approachable guy) would be willing to adopt our changes right into nn-c (likely as an option), and that would clear the way for that useful library to be packaged by Debian as "free" rather than "contrib" and would also allow us to abandon our fork (since it would have been merged back into mainstream nn-c development) which I think would be a highly desired outcome. I have stated on this list before (but you may have missed that), I work most efficiently on just one development topic at a time. And my current primary development topic is getting the next release of FreeEOS out the door and my two topics following that are (i) getting the next libLASi release out the door using recent PLplot to comprehensively test it, and (ii) getting the PLplot release out the door. In sum, because of these other development commitments I don't plan for now to contribute much toward any of the above three "would be nice" development topics for libcsironn other than discussing them. But if you or anyone else here that was interested in libcsironn were inspired by this discussion to create a patch to implement any of those topics (or any other libcsironn development topic that interested you), I would be happy to comprehensively test that patch in a timely manner and (assuming that was a success) push that commit to make sure your work gets into the next release of PLplot. Best wishes, 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
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é on the 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 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 __ valgrind.out.gz Description: valgrind report showing details of the segfault regression introduced by Antóni ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Port to SIP5?
On 2020-12-03 19:28+0300 Dmitry Shachnev wrote: H Alan! On Tue, Dec 01, 2020 at 01:34:50PM -0800, Alan W. Irwin wrote: Hi Dmitry: From the PLplot bug discussion above, it appears Rafael was unable to modify PLplot to use sip5 with two different methods which are (1) to generalize our present method for generating our pyqt5 binding so that method works for both sip4 and sip5 or (2) adopting the completely new approach of using a sip5-based build system to generate our pyqt5 binding. I likely will also not be able to convert PLplot to use sip5 because my sip expertise is not particularly good. Also note we must continue to support sip4 because many latest versions of distros (including (!) Debian Unstable, see <https://packages.debian.org/sid/sip-dev>) support that version of sip. If you do provide a patch for this issue, I would *far* prefer you to use method 1 that was described above. Let me try to convince you of the opposite. - SIP 5 was released in October 2019. It's not that much new. - SIP 5 is what users when they are installing PyQt5 from pypi.org (using pip tool). So most people who are not relying on distros' package manager will get it. - The upstream SIP developer writes [1]: > SIP v4 has been deprecated for more than a year. *Nobody* should still be > using it. - I am SIP maintainer in Debian. At the moment we support both 4 and 5. The reason why I filed these bugs is that I *do* want to abandon SIP 4. This won't happen in time for Debian 11 (Bullseye), but it will definitely happen in Debian 12 (Bookworm). The same applies to Ubuntu, which gets SIP synced from Debian. So at this point there are few reasons to care about SIP 4. Then, upstream is going to release SIP 6 soon (maybe in a few months). It will be *not* co-installable with SIP 5, so distros will probably have to ship either only SIP 6, or for some time SIP 4 and SIP 6 (but not SIP 5). If plplot keeps using the old sip/sip5 tool (approach 1), then it will work with SIP 4 and SIP 5, but will need changes when porting to SIP 6. If plplot starts using the new buildsystem (approach 2), then it will work with SIP 5 and SIP 6 without much changes. So I think approach 2 makes more sense than approach 1. Hi Dmitry: Thanks for sharing your knowledge of sip development and version status which I was sorely lacking. And armed with that knowledge the points you have made with regard to moving to approach 2 seem pretty good to me. Therefore, if/when you send me a patch implementing approach 2, I would be willing to modify it to keep the present pure sip4 approach as a (deprecated) alternative until most modern versions of distros support sip5 (if that is going to be an issue). I am not promising anything, but when I have time I may look at building plplot with SIP 5, regardless on what approach we decide on. This codebase is unknown to me, so it may take a while. To help encourage that effort, here is what I would recommend for your first steps. # Use the latest git version of PLplot following the directions at # <https://sourceforge.net/p/plplot/plplot/ci/master/tree/> git clone git://git.code.sf.net/p/plplot/plplot plplot.git # Start configuration with a clean build directory that is located # relative to the plplot.git directory. cd plplot.git mkdir ../build_dir cd ../build_dir # Configure a minimalist PLplot that still enables the pyqt5 binding cmake -DDEFAULT_NO_BINDINGS=ON -DDEFAULT_NO_DEVICES=ON -DENABLE_python=ON -DENABLE_qt=ON -DENABLE_pyqt5=ON -DPLD_extqt=ON -DBUILD_TEST=ON ../plplot.git >& cmake.out) # Test that configuration by building that binding and running an example that uses it. make test_pyqt5_example Note we currently also support Qt4 and pyqt4, but those are about to be removed so ignore that part of our build system. The files and directories within our source tree that are relevant to our pyqt5 binding and the example that tests it are cmake/modules/qt.cmake, bindings/qt_gui/pyqt5, examples, and examples/python. Good luck, and let me know how the above simple steps work for you to test our present sip4 pyqt5 binding. 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] Port to SIP5?
On 2020-11-30 17:54+0100 Rafael Laboissière via Plplot-devel wrote: Dear PLplot developers, [For more context regarding the request below, see https://bugs.debian.org/964127] Please, consider porting the Python-Qt build system to use SIP5 instead of SIP4. Hi Dmitry: From the PLplot bug discussion above, it appears Rafael was unable to modify PLplot to use sip5 with two different methods which are (1) to generalize our present method for generating our pyqt5 binding so that method works for both sip4 and sip5 or (2) adopting the completely new approach of using a sip5-based build system to generate our pyqt5 binding. I likely will also not be able to convert PLplot to use sip5 because my sip expertise is not particularly good. Also note we must continue to support sip4 because many latest versions of distros (including (!) Debian Unstable, see <https://packages.debian.org/sid/sip-dev>) support that version of sip. If you do provide a patch for this issue, I would *far* prefer you to use method 1 that was described above. Of course, it is normally a good idea for PLplot to support new versions of external software such as sip5 so long as support for older versions that are still being used by most distros (e.g., sip4) is not compromised. However, unless you can find an easy way to support both sip4 and sip5 (e.g., with method 1 above), we should likely just stick with sip4 for quite some time to come. After all, sip4 is a mature and stable product that upstream sip (riverbankcomputing) has continued to support this year via minor feature and bug-fix releases, and it appears that Debian also has no immediate plans to abandon sip4. 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] Set the libplplotada_SOVERSION on the CMake command line
On 2020-11-17 03:25+0100 Rafael Laboissière wrote: I think it is a good idea to cache both *_SOVERSION and *_VERSION variants. Even though we only need SOVERSION for now in Debian, this move will probably cause no harm for the upstream development. I have implemented this change, see my recent push of commit 28ffa1e84. 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] Set the libplplotada_SOVERSION on the CMake command line
On 2020-11-15 07:36+0100 Rafael Laboissière wrote:
Dear PLplot developers,
Please find here attached a patch developed by Nicolas Boulenguez that we are
currently applying to the Debian package. The patches regards the setting of
the libplplotada's shared object version.
Here is the description of the patch, as written by Nicolas:
“The SOVersion sometimes needs to evolve independently of the API (and thus,
is unrelated with semantic versioning), or even without knowledge by the
upstream author. For example, a rebuild of the library with a different
compiler may break its ABI.
This patch provides redistributors like Debian an easy way to set the
libplplotada_SOVERSION on the CMake command line, without patching CMake
files.
This patch only affects the Ada library, but the suggestion applies to any
language allowing dynamic linking.
As far as I know, the part added by _VERSION and the related symbolic links
are a complexity added by CMake (probably in order to follow the GNU libtool
conventions), but the linker only cares about the SOVERSION.”
Please consider applying this patch to PLplot.
To Nicholas and Rafael:
I would be happy to cache *_SOVERSION variables for each of our
libraries to help packagers who are up against some ABI change for
their distribution. However, packagers also would need to update the
*_VERSION variables as well if their distribution mandated some rule
for those such as semantic versioning (which is the set of library
SOVERSION/VERSION rules that libtool has adopted). For example, if
*_VERSION remains uncached as now, then the VERSION result will
combine the packager's SOVERSION with a default suffix that is
consistent with the semantic versioning rules (e.g., the ".2.0" suffix
in ${plplotfortran_SOVERSION}.2.0) for the default SOVERSION supplied
by PLplot but *not* the SOVERSION supplied by the packager. So I am
strongly leaning toward caching both *_SOVERSION and *_VERSION
variants of all library version variables.
@Nicholas:
Thanks for (indirectly) bringing this issue to our upstream attention.
@Rafael:
Historically (back in our autotools days) you were the PLplot guru on
library soversion/version issues. So I would appreciate a comment
from you about whether you see any downside to my idea above to cache
both forms of library version variables to allow packagers to override
both.
@both:
Best wishes,
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] Fix for Debian Sid sip file find problem
On 2020-10-06 19:21+0200 Rafael Laboissière wrote: Hello Alan and Ole, Commit 61e41ac6a from Alan worked fine for me. I uploaded version 5.15.0+dfsg-15 of plplot to Debian unstable: https://tracker.debian.org/news/1181045/accepted-plplot-5150dfsg-15-source-into-unstable/ The package built correctly on all architectures: https://buildd.debian.org/status/package.php?p=plplot Thanks, Rafael, for that test of my commit on Debian Sid, and the good news concerning those results. 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
[Plplot-devel] Fix for Debian Sid sip file find problem
To Ole and Rafael: @Ole: Rafael has contacted me off list concerning the sip file find problem for Debian Sid that he feels is the cause of <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971215>. Accordingly I have solved that find problem as part of a larger rationalization of the CMake logic to find needed sip files (see commit 61e41ac6a). I am virtually positive this fix will work on Debian Sid because I checked the file list there was consistent with the PATHS and PATH_SUFFIXES I now use to help find the relevant sip files. However, I don't currently have convenient access to Debian Sid so I could only test this commit introduced no regressions on Debian Buster. @Rafael: Could you try that commit to confirm it works the same as your own hackish patch to solve the issue? Please report back those test results to both Ole and me. @Ole: Please see whether commit 61e41ac6a solves Debian bug 971215. 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] One development topic left for memqt_example [there appear to be two possible solutions to choose from!]
On Tue, Jul 14, 2020 at 2:35 AM Alan W. Irwin wrote: Hi António: [...] I have just found <https://stackoverflow.com/questions/51010194/qt-5-10-semi-transparent-background-on-qmainwindow-using-stylesheet> . Could you please take a careful look at this reference which mentions two possible solutions? On 2020-07-14 11:47+0100 António Rodrigues Tomé wrote: Amazingly simple. here the code Hi António: After running scripts/style_source.sh --apply to style your changes, I tested them and pushed them (git commit 3876b262c, described as plplot-5.15.0-77-g3876b262c). It is really great you followed up on that reference and found a solution that satisfies my long-standing semi-transparency dream for Qt5. @others on list: If any of the rest are interested in what we accomplished, try building the "test_memqt_example" target and clicking on the "actions" menu for the resulting GUI that is displayed. @António: For the time being, at least, I think we are done with memqt_example development, Best wishes, 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] FindLua
On 2020-07-13 18:03-0600 Orion Poplawski wrote: Is cmake/modules/FindLua.cmake useful anymore? No, and thanks for this reminder which I have just acted on. For further details concerning this change, see the git commit 096358394 (described as plplot-5.15.0-76-g096358394). 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
[Plplot-devel] One development topic left for memqt_example
Hi António: Please take a look at my most recent push. The highlights are I have committed the changed version of aurora.png that you donated, done a substantial code cleanup, moved to linking with the plplotcxx library rather than the plplot library, fixed some build issues, and figured out how to enable *and* use plscolbg(a) properly for the memqt device without compromising functionality. Please try this method (using a transparent Qt5 image initialization or transparent PLplot background as needed) also for your own private examples to confirm my claim of no compromise of functionality for this method is true. I am pretty sure you will like what I have done, but if you feel there is any problem with my changes, I will try and figure it out to your satisfaction. Assuming you like what I have done, that leaves only one remaining memqt_example issue as far as I am concerned. That issue is the proper display of the actions which are supposed to contain semi-transparent results. Currently, they are plotted as semi-transparent on a white background imposed by Qt5, but that is not the correct result as we have recently discovered by looking at pqiv results. @everybody: for the others here I have recently discovered a method of displaying semi-transparent PLplot plots correctly which is to use the --transparent-background option of pqiv (that option name is a misnomer which should have been called something like --honor-alpha since all it does is honor the alpha channel information contained in the image that is being displayed). To see what this option can do, try the following to build the relevant pngqt device and C example 11, create a semi-transparent version of that example, and display that result properly: make qt make x11c examples/c/x11c -dev pngqt -o test.png -bg FFF_0.4 -fam pqiv -i --transparent-background test.png.8 This works well on my Debian Buster KDE compositing desktop where the composited result is 40 per cent PLplot result and 60 per cent whatever is below that plot on the desktop. However, this nice result is not what is delivered by Qt5 because its default action is to insert an opaque white layer as an additional background for the semi-transparent memqt_example actions. @António: I am not sure whether you have tried the above pqiv example yet on your own (openSUSE) KDE compositing desktop, but I think it should "just work" for you as well as it did for me. Which leaves the development topic of how to convince Qt5 to do similar correct rendering of the semi-transparent actions of memqt_example? Google is no help (because of an enormous number of irrelevant hits for the search terms "qt5 semi-transparent" (without the quotes) which discuss creating semi-transparent results [which we already have done with memqt_example] but those hits typically do not discuss rendering those results properly with Qt5). So can you use your Qt5 expertise to help me figure out how to do this? 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] #include needed in qt.h by newer qt versions
On 2020-06-30 11:43+0100 António Rodrigues Tomé wrote: Hi alan Everything seems to work fine. In the future I'll extend the memqt example to do interesting things, this was only a little program i used to test the driver. I will also try to replace QLinkedList in the qt drivers as it is now deprecated, it will still be around for quite a while to keeping old code working but better to replace it, I'l do that without compromising the build of the drivers in older versions of qt. Thanks for the changes best regards, Hi António: I am glad the present test_memqt_example and memqt_example targets that I implemented work well for you, and I look forward to your planned future "interesting" changes to memqt_example, and any other help you can give to keep the Qt-related parts of PLplot up to date with Qt5. My Qt skills are limited so my own plans for the Qt-related parts of PLplot are simple, and I think I have mentioned them on list before. But just to remind you (and the list), my plan is to deprecate our Qt4 support (likely for the forthcoming release) and remove it altogether for the release after that which should very much simplify the Qt-related part of our build system (since for Qt4 all the CMake logic is hand-generated, while Qt5 CMake support is much better automated). And, of course, I am quite happy to support with any CMake logic (as I have just done) anything new for the Qt5-related parts of PLplot that you want to implement. Best wishes, 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 fails to build with ocaml 1.08
On 2020-05-22 16:31+0100 Richard W.M. Jones wrote: Xavier changed cpp -traditional back to cpp (https://github.com/xavierleroy/camlidl/issues/18), and I have added the new camlidl 1.09 to Rawhide. I will rebuild plplot against this shortly. Thanks, Orion, for initiating camlidl bug 18 and Richard (and Xavier) for following up on it. From the discussion there, it sounds like all is now well with unit testing of the problem, and I therefore assume the above test with a full PLplot build will confirm that. And if so, kudos to everybody for figuring out this issue so swiftly. 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 fails to build with ocaml 1.08
On 2020-05-21 10:01+0100 Richard W.M. Jones wrote: On Wed, May 20, 2020 at 09:28:10PM -0600, Orion Poplawski wrote: With the update from ocaml 1.05 to 1.08 plplot now fails to build: 4.05 -> 4.08 ? Hi Richard: Your messages are being rejected by the list for obvious reasons (no subscription), but I do have access to them as list coordinator so I will answer (with a copy to the list). No, the above problem in version numbers was because Orion misidentified the package which is camlidl and not ocaml. [...] Nothing has changed significantly under bindings/ocaml/ for a long time, so I don't know why specifically it works from git and not from the Fedora build. Maybe one of the huge number of cmake flags? The issue was with the camlidl command. But according to Debian packaging information that application depends on the ocaml-nox package that "contains everything needed to develop OCaml applications". Also, I have the following result: irwin@merlin> file /usr/bin/camlidl /usr/bin/camlidl: a /usr/bin/ocamlrun script executable (binary data) And ocamlrun is the OCaml byte-code interpreter. So from your further result that everything works fine for the latest git version of ocaml (where I assume you are still using the same pre-release version of camlidl), it appears the issue is caused (indirectly) by some Fedora inconsistency between their packaged pre-released versions of camlidl and ocaml. Anyhow, it appears the issue does not have a lot to do with PLplot (except as a platform that exposes the issue). So good luck solving it, and let me know how you progress. 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 fails to build with ocaml 1.08
Hi Orion: Thanks for your report. On 2020-05-20 21:28-0600 Orion Poplawski wrote: With the update from ocaml 1.05 to 1.08 plplot now fails to build: The ocaml versions on Debian Buster are 4.0.5* while the camlidl version there is 1.0.5*, and it is camlidl that failed below. Therefore, I assume you meant camlidl rather than ocaml above. [ 4%] Generating plplot_core.idl, plplot_core.mli, plplot_core.ml, plplot_core_stubs.c, plplot_core.h cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml && /usr/bin/cmake -E copy /builddir/build/BUILD/plplot-5.15.0/bindings/ocaml/plplot_core.idl /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml/plplot_core.idl cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml && /usr/bin/camlidl -I /builddir/build/BUILD/plplot-5.15.0/bindings/ocaml -header plplot_core.idl File plplot_core.idl, line 369, column 13: Illegal character # This line is: RAW_ML(external plgriddata : float array -> float array -> float array -> float array -> float array -> plplot_grid_method_type -> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata") The macros involved are: #define QUOTEME(x) #x #define RAW_ML(x) quote(mlmli, QUOTEME(x)); Now, I know nothing about ocaml so I'm hoping Richard can clue us in on what has changed. For your information, here is the effect of the RAW_ML macro (as generated by camlidl Version: 1.05-15.1 on Debian Buster = Stable). software@merlin> grep -i plgriddata plplot_core* |grep -iv binary plplot_core.idl:// Hand-translated PL_GRID_* flags for use with plgriddata plplot_core.idl:RAW_ML(external plgriddata : float array -> float array -> float array -> float array -> float array -> plplot_grid_method_type -> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata") plplot_core.ml:external plgriddata : float array -> float array -> float array -> float array -> float array -> plplot_grid_method_type -> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata" plplot_core.mli:external plgriddata : float array -> float array -> float array -> float array -> float array -> plplot_grid_method_type -> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata" So RAW_ML appears to do what its name implies (generate an exact copy in the relevant output files generated by camlidl). But my OCaml (and camlidl) knowledge is pretty limited as well so I don't understand (at all) how that simple result is implemented with the macros #define QUOTEME(x) #x #define RAW_ML(x) quote(mlmli, QUOTEME(x)); So I also hope you can get help from Richard on how this result is generated, but since the result is so simple, my best guess is this issue is due to a bug in the particular pre-release 1.0.8 version that Fedora has decided to package. I am tied up with a large number of different projects for the next month or so. But when I get a free moment (and if this Fedora issue has not been resolved by then), I will attempt to obtain the latest camlidl from <https://github.com/xavierleroy/camlidl> to see if I can replicate the issue you have found. N.B. from the latest commit message there, 1.0.8 hasn't actually been released yet. Therefore, if the issue is because of a bug in the particular pre-release version of camlidl that Fedora has packaged, then it is alway possible that Xavier Leroy has already fixed this bug in a later pre-release version. But if changing the Fedora package to the latest pre-release version does not fix the current issue, then I would recommend you contact Xavier Leroy about this issue to see if he can fix it before he releases 1.0.8. Good luck, and let me know how it goes. 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
[Plplot-devel] Expanding the PLplot contract test to more platforms
CMake contract tests are a useful but obscure possibility with CMake. They implement an informal test contract between CMake developers and some software package developer to test the latest development version of CMake every night in the standard way supplied by cmake with one additional "contract" test added that that downloads, configures, builds, and installs the software package using that latest development version of CMake. The results are automatically collected by the ctest component of CMake as a dashboard that is uploaded to the open.cdash.org dashboard server with results displayed at <https://open.cdash.org/index.php?project=CMake>. What CMake developers get out of such contracts is an integrated test of CMake for a whole build system (as opposed to their normal "unit" tests that just test tiny bits and pieces of CMake functionality). What developers for a given package get out of such contracts is nightly confirmation that a certain version of their software identified by commit id works for the latest development version of CMake. The joint advantage for CMake and software package developers is this contract process finds early in the CMake development process bad CMake development ideas that would break the software package's build system even if the unit tests are succeeding. Currently, CMake implements contract tests for PLplot and two other software packages as can be seen from software@merlin> ls Tests/Contracts/ Home.cmake PLplot/ Trilinos/ VTK/ And if you check the above dashboard for "merlin" (the name of my computer) you will see that the PLplot contract test is currently succeeding for the commit id "plplot-5.15.0" (i.e., the latest release of PLplot) on my Debian Buster=Stable platform. However, if you explore the calendar options at that site you will also discover that the "merlin" PLplot contract test failed in recent times for several weeks due to what turned out to be a faulty cable modem for my home computer. But once that modem was replaced the "merlin" PLplot contract test started succeeding again just like it has done ever since the release of 5.15.0 and also (with commit-id "plplot-5.14.0") between the 5.14.0 and 5.15.0 releases. And just like in those previous release cycles I plan late in this current plplot-5.16.0 release cycle to do a preliminary contract test for some near-release commit id that will be changed to "plplot-5.16.0" just after that release. Of course, the PLplot contract test I am running only tests our build system against the latest CMake development version for just my platform, and expanding that test to more platforms would be substantially strengthen this test of both PLplot and CMake. So if you are interested in helping out with that desired expansion, I have attached my notes (README.gz) (and also the key configuration file, my_dashboard.cmake.gz, referred to by those notes) on how I set up (with a lot of initial help from Brad Kind) the above "merlin" PLplot contract test on my own computer. Assuming you understand those notes and the documentation referred to by those notes, then then all you really need to participate further is network connectivity and the ability to build and install PLplot automatically at the time you choose in the (24-hour) day to perform this "Nightly" test (typically with crontab on Unix computers and the equivalent of that on Windows systems that is referred to by the contract test documentation.) And, of course, you should make sure that the name you choose to describe your computer in my_dashboard.cmake does not name-clash with all the other computer names (including "merlin") that show up at the above dashboard URL. If you are interested in helping out with both PLplot and CMake testing in the way I have described above for any platform for PLplot that interests you, I would be happy to help you with any further questions you may have. 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 __ README.gz Description: Notes on configuring a PLplot contract test my_dashboard.cmake.gz Description: configuration file referred to by those notes ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] ndiff software commit
On 2020-03-02 10:02-0500 Hazen Babcock via Plplot-devel wrote: Hello, The ndiff software commit (a974e9802cc0b54ed33d9078b7767b29286c5684 I believe) added a lot of files and directories in the utils/ndiff directory that appear to be output files (checkXYZ.xyz). Perhaps this was a mistake? Hi Hazen: I implemented the CMake-based build system for ndiff years ago so to answer your question I needed to take a quick look at the test part of that build system again to confirm all was well. If you look at the test logic in ndiff/CMakeLists.txt the bash script ndiff_check.sh that is configured refers to $1.xyz where xyz takes on the values "err", "out", "opt", "in1", "in2". Furthermore, if you look further at ndiff/CMakeLists.txt that $1 argument to the script takes on the values check001 through check009, and check010 through check026. So from this quick check it appears the files you refer to are a legitimate part of the test system so including them in the commit was the right thing to do. But thanks for asking because two heads are much better than one, and you will likely catch one of my commits that needs fixing some day. But just not today. :-) 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.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] D language support topic
I have just pushed plplot-5.15.0-46-gd6670a304 The principal change here is I have improved the test_d implementation to make it conform more closely to what I have planned for -pthread handling for the plplot project case. In addition, I have updated the test_d README file to reflect the fact that the -Xcc feature for dmd that we need for -pthread handling for that D compiler has evolved from an experimental dmd feature to mainstream (on the dmd git master branch and scheduled to be part of the dmd 2.089.0 release on November 1st). In addition, I have substantially updated the instructions concerning how to build that master branch version of dmd. This version of test_d shows no regressions compared to the previous version and like that version continues to force use of -pthread on most platforms (e.g., Linux, Mac OS X, and MSYS2) to provide a strong test with this project that truly reflects the -pthread handling needs of the plplot project. @Takeshi: I am sorry it took me so long to mature test_d, but now that has occurred could you please test the (updated) test_d project on your Mac OS platform following what the (updated) cmake/test_d/README file says? Note in order to do this test (and also to test the plplot project later) you will need a CMake version built from a recent master branch (I think you already have that) and similarly for dmd. For your convenience I have attached my current bash script for building dmd. I suggest (after looking through it to confirm that what it does is consistent with the build instructions in the above README file) you run it in a dedicated directory (so the git clones that occur and the creation of the install subdirectory that contains the install tree don't mess up anything else) as follows: ./dmd_git_build.sh HEAD to build dmd and associated libraries for the HEAD of the master branch of the set of four repositories that are required. Note, the script takes a lot of care so that you can run the same command days later (to get access to the latest HEAD master branch result on that day) without stale file issues from the previous build within the same dedicated directory. Good luck, and let me know how it goes with the required dmd build (unless you want to wait for (a) the dmd 2.089.0 release on November 1st and (b) the MacPorts packaging of that release that will presumably be finished substantially later). And once that build is done, I am, of course, interested in your comprehensive test results for the (substantially updated) test_d project. 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.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 __ dmd_git_build.sh.gz Description: (compressed) bash script for building dmd on Posix platforms ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] D language support topic (success for test_d on Darwin!)
On 2019-09-24 17:24-0700 Alan W. Irwin wrote: But the other issue (where our various thread library needs are met by the -pthread *compiler* option used for linking which neither dmd nor ldc2 understands) has proved much more difficult to solve (even though it is extremely easy to solve the issue by hand) *within the current constraints imposed by CMake*. See <https://gitlab.kitware.com/cmake/cmake/issues/19757> for a CMake feature request that would elegantly solve this issue. But meanwhile, I have implemented (commit ab8a90546 git-described as plplot-5.15.0-44-gab8a90546) for the test_d project a workaround for the current lack of am implementation for the 19757 feature request. That workaround gives good results for dmd and ldc2 for an updated test_d project and gdc (which does not require the workaround) continues to work well for that updated test_d where (as in the plplot project case) the test_d C library is linked with the -pthread option. So this commit is a considerable step forward for test_d and implements a workaround for the above issue that should also work (once I implement it) for the plplot project case. @Takeshi: would you please test the (updated) test_d project on your Mac OS platform following what the (updated) cmake/test_d/README file says? Note, that file tells you how to build an extremely specific version of dmd that has the -Xcc capability that my current D language support for dmd needs. This variant of dmd is being considered for the next release of dmd, and likely the dmd developers will favor it for inclusion the more platforms we use to test it (see the latter part of the discussion at <https://github.com/dlang/dmd/pull/10438> and also the on-going discussion at <https://github.com/dlang/dmd/pull/10441>). So we are right at the "cutting edge" of dmd development now with a lot of care required to build the dmd versions that we need, but in a year from now I am hoping that the -Xcc dmd capability is just part of mainstream dmd versions that are being released with no special version of dmd being required for our D language support. More later as I transfer from the test_d project to the plplot project what I have learned about a solution to the above -pthread 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.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] D language support topic (success for test_d on Darwin!)
On 2019-09-15 15:35-0700 Alan W. Irwin wrote: Hi Takeshi: [...] I would appreciate you testing that result [plplot-5.15.0-34-g6b47c717e] for the test_d project (to make sure my further one-line change I committed beyond what you have tested already did not screw anything up) and also (if that test is a success) the plplot project itself. For the others here I subsequently contacted Takeshi (and Arjen for the MSYS2 case) off list to put those tests on hold because I wanted to fix some additional issues I discovered when I attempted to comprehensively test ldc2 and dmd on Linux for a PLplot with all possible Linux components configured (as opposed to the good comprehensive tests results on my Linux platform that I get for a PLplot where only the C and D components were configured). The rest of this post is a status report on the remaining D build-system issues for a fully configured PLplot on Linux. I solved one of the issues (where Qt5 was polluting the D builds in the static case with the -fPIC compile option which ldc2 did not understand) by using the target_link_libraries PRIVATE option for the static library build. But the other issue (where our various thread library needs are met by the -pthread *compiler* option used for linking which neither dmd nor ldc2 understands) has proved much more difficult to solve (even though it is extremely easy to solve the issue by hand) *within the current constraints imposed by CMake*. For those interested, I have just posted a detailed report about this CMake-based build-system limitation and a possible feature request to solve it at <https://cmake.org/pipermail/cmake-developers/2019-September/031239.html>. As part of writing up that post today, I thought up a workaround for the issue that is a bit messy (since part of the workaround requires an extra library called PLPLOT::plplot_nothread to be built that is exactly the same as PLPLOT::plplot except for its modified INTERFACE_LINK_LIBRARIES property), but I think it will work until the day (if it ever comes) when the CMake developers decide to implement the above possible feature request. In sum, at least I finally have a plan to work around this issue, and (because a fair amount of build-system changes will be required) I hope to implement that plan (unless the CMake developers advise me of a simpler way to do the same thing) by (very roughly) the end of this week. Furthermore, the hold on non-Linux platform testing of D language support should continue for both Takeshi and Arjen until I demonstrate that the three D compilers all pass comprehensive testing of a fully configured PLplot on my platform. So until then... 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.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] Issue with ocaml in tree tests
On 2019-09-22 20:06-0600 Orion Poplawski wrote: I'm trying to update the Fedora plplot package to 5.15.0 but running into the problem that the build tree rpath is not being set: plplot-5.15.0/fedora/examples/ocaml/CMakeFiles/target_x13ocaml.dir/build.make: cd /home/orion/fedora/plplot/plplot-5.15.0/fedora/examples/ocaml && /usr/bin/ocamlopt.opt -g -I /home/orion/fedora/plplot/plplot-5.15.0/fedora/bindings/ocaml -ccopt "-L /home/orion/fedora/plplot/plplot-5.15.0/fedora/src -Wl,-rpath -Wl, " plplot.cmxa -o x13ocaml x13.ml The problem is we build with USE_RPATH=OFF but the ocaml_RPATH variables are only set with USE_RPATH=ON. I think we want a special case to always set the build_*_RPATH variables. Hi Orion: Good catch. This build-system bug for the combination of ocaml and -DUSE_RPATH=OFF in the core build tree is now fixed in the git commit described (using "git describe master") as plplot-5.15.0-37-g6b215267e. 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.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] D language support topic (success for test_d on Darwin!)
On 2019-09-15 09:48- 榎本 剛 wrote: Alan, The test was a success. Hi Takeshi: I am now taking this discussion back to the plplot-devel mailing list. Thanks for all your work in obtaining this good D language support test result for the test_d project for your Darwin dmd (MacPorts) platform. I made one additional (untested) change to Darwin-dmd.cmake for the reasons discussed in the commit message for plplot-5.15.0-34-g6b47c717e. Please update your local git repository to the latest master branch version (so you have access to that commit and there will be no need to patch PLplot). I would appreciate you testing that result for the test_d project (to make sure my further one-line change I committed beyond what you have tested already did not screw anything up) and also (if that test is a success) the plplot project itself. The rest of this post concerns that further comprehensing testing of the plplot project. That is done by changing directory to the top-level directory of the PLplot source tree (so NOT cmake/test_d) and running scripts/comprehensive_test.sh --help to get a sense of what is available for that much more sophisticated comprehensive testing script than you ran for the test_d case. Now the thing to remember about this script is it really is comprehensive by default. So usually you constrain it to avoid doing tests that are currently not relevant to some topic such as D language support for the plplot project. So please look in the PLplot git log for commit f7d9bec368f3 where I demonstrate how to limit that comprehensive test to just the D binding and examples, the svg device, and (by default since these components are always part of testing) the core C library and the C examples. Of course, for that test I did a lot of special things relevant to my own platform such as testing blanks in source-, build-, and install-tree pathnames. So you don't want to repeat exactly what I did. So instead, here is my best (informed by what you did for test_d) guess concerning how you would modify that plplot comprehensive test invocation for your own needs: # Important cd # Important, set DC environment variable to select D compiler and # options for that compiler and set PATH environment variable to # access a CMake version >= 3.15.20190829-g3ec986c that has (on your # platform) the essential CMake master branch fix needed so that D # language support works for dmd. Also drop the interactive # component of comprehensive testing since that is not relevant # to D. env DC="/opt/local/bin/dmd -v" PATH=/usr/local/cmake/bin:$PATH scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_BINDINGS=ON -DENABLE_d=ON -DDEFAULT_NO_DEVICES=ON -DPLD_svg=ON" --build_command "make -j18" --ctest_command "ctest -j18" --do_test_interactive no) Note that script run will be noticeably longer (but likely not too bad because of all the above constraints limiting the test) compared to the test_d script run because this script does much more than happens for test_d (for example running all the PLplot C and D examples and comparing those results for 15 different combinations of 2 test_noninteractive tests + 2 ctests + 1 traditional test (for 5 tests in all) for our 3 different major configurations. As with test_d, regardless of whether that script run is a success or not, please collect the report tarball (which by default will be stored in a different prefix area than in the test_d case) and send it to me for further analysis. Good luck with this (PLplot) constrained comprehensive test which when it is a success will demonstrate improved D language support for both the upstream version of PLplot that I have been helping to maintain and ultimately the MacPorts port of PLplot that you have been maintaining. 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.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] Patch set for postscript driver
On 2019-09-15 14:12-0400 Jim Dishaw wrote: While fixing the plm render bug, I’m working on how text is handled in general. I’ve made some minor changes to the postscript driver in preparation for the bigger changes. I’m in a bit of a hobbled development environment right now and running the test suite and pushing the change is not really practical (I’m doing the work entirely on Windows and using Visual Studio Express). So, if someone is willing to test and push, it would be greatly appreciated. Hi Jim: I would be happy to help you this way. Using "git am" to apply your commit worked, but there were the following minor formatting issues: * "git am" detected some trailing blanks on some of your changed lines. * The resulting commit message did not separate paragraphs properly (with an end of line). So the git log result looks like this: Cleanup of the postscript driver -- Changed unnecessary calls of fprintf() to fputs. -- The fputs() call is more efficient with fixed strings -- Changed the TRMFLT() from a macro to an inline static function -- Preprocessor macros can have unintended side effects -- Eliminated the the shared ouput buffer (outbuf) variable -- Dynamically allocating the output buffer variable on the stack on function entry has negligible performance impact -- The shared output buffer would cause problems when threads are implemented Instead of what you likely intended which was Cleanup of the postscript driver -- Changed unnecessary calls of fprintf() to fputs. -- The fputs() call is more efficient with fixed strings -- Changed the TRMFLT() from a macro to an inline static function -- Preprocessor macros can have unintended side effects -- Eliminated the the shared ouput buffer (outbuf) variable -- Dynamically allocating the output buffer variable on the stack on function entry has negligible performance impact -- The shared output buffer would cause problems when threads are implemented where "git log" has inserted the leading spaces so you should not do that in your commit message. Note that both of these formatting issues are easy for me to deal with here, but for your next iteration (which is necessary, see below) you may want to address these issues yourself. I tested your code changes by comparing the results of test_c_psc between the ps device driver for the master branch and your patched version of same, and there are two issues in the PostScript results for each of the examples, but I will just show you those issues for the 00 example: diff -Naur ../test_examples_output_dir_psc/x00c.psc examples/test_examples_output_dir/x00c.psc --- ../test_examples_output_dir_psc/x00c.psc2019-09-15 12:01:58.435910736 -0700 +++ examples/test_examples_output_dir/x00c.psc 2019-09-15 12:09:36.511559691 -0700 @@ -3,7 +3,7 @@ %% %%Title: PLplot Graph %%Creator: PLplot Version 5.15.0 -%%CreationDate: Sun Sep 15 12:01:58 2019 +%%CreationDate: Sun Sep 15 12:09:36 2019 %%Pages: (atend) %%EndComments @@ -342,7 +342,7 @@ 397 3228 D 356 3256 D 315 3284 D S eop -%%Trailer +Trailer %%Pages: 1 @end -%%EOF +EOF Of course, the %%CreationDate changes are expected, but your change currently creates incorrect %%Trailer and %%EOF directives by prepending "%%" to them for every example. So please fix those code update issues so that the PostScript results are identical to what is produced by the present code from the master branch except for the %%CreationDate date/time stamp. And optionally fix the above formatting issues. And we can take it from there. 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.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] Which cmake do I need to modify?
On 2019-09-14 22:04-0400 Jim Dishaw wrote: I need to add comctl32.lib as one of the libraries when building Windows executables. Which cmake file should be modified such that the examples are built correctly? The wingdi driver needs that library. Thanks A search for the comctl32 library is already occurring in cmake/modules/wingdi.cmake. If it is found you should be getting a cmake message "Looking for gdi32 header and library - found" and your CMakeCache.txt should show the actual location of that library. That library location becomes part of wingdi_LINK_FLAGS which should be used appropriately in the rest of the build system so everything (dynamic driver or else plplot library if dynamic drivers are not used) and the examples link correctly. It sounds like something is currently interfering with this process that worked before for you so please send me a complete bug report with all the details so that I can help you find what the problem is. 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.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] test-drv-info
On 2019-09-12 17:59+0100 Phil Rosenberg wrote:
Hi Alan
I think I have found a problem with test-drv-info. I think it is
unaware of the CMake flag CMAKE_DEBUG_POSTFIX. I've started using
-DCMAKE_DEBUG_POSTFIX=d as part of my cmake commands to add d to the
end of all debug libraries. But this causes test-drv-info to report:
Could not open the driver module
If I go onto the command line ant try running test-drv-info myself,
adding d to the module name, I get
Could not read symbol plD_DEVICE_INFO_d in driver module d
Is it possible to pull the postfix into the test-drv-info source? It
would simply need concatenating at line 76 of test-drv-info.c
Hi Phil:
I have no objection to such a change so long as it is completely
general (any postfix string of any length that the user has specified
for any possible CMAKE_BUILD_TYPE). For example, it should work
(to take an absurd example) if the user specifies
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_RELEASE_POSTFIX="_my_release_version_of_this_library"
and also, of course, the case that interests you
-DCMAKE_BUILD_TYPE=Debug -DCMAKE_DEBUG_POSTFIX="d"
Please try the following change on line 176 of
drivers/CMakeList.txt where CMake does the necessary concatanation:
- "${WRITEABLE_TARGET}" ${SOURCE_ROOT_NAME}
+ "${WRITEABLE_TARGET}"
${SOURCE_ROOT_NAME}"${CMAKE_${CMAKE_BUILD_TYPE}_POSTFIX}"
If that works for the two CMAKE_BUILD_TYPES and corresponding CMAKE...POSTFIX
variables
above, please go ahead and commit that change.
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.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] Font issues for -dev plm and plrender
On 2019-09-11 21:41-0400 Jim Dishaw wrote: On Sep 11, 2019, at 9:30 PM, Alan W. Irwin wrote: Hi Jim: My understanding is plbuf supports unicode-aware system fonts. But my recent test (for details of the test, see the commit message for the commit git-decribed as plplot-5.15.0-31-g3af0b2cf1) showed the combination of -dev plm (which I presume writes plbuf information to a file) and plrender (which I presume reads that information) is still using Hershey fonts! Could you please figure out a fix for this issue? I’ll take a look at it this weekend. I think the font support may need to be cleaned up because there is a lot of duplicated code. Thanks for being willing to try to fix this and good luck with that effort! 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.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
[Plplot-devel] Font issues for -dev plm and plrender
Hi Jim: My understanding is plbuf supports unicode-aware system fonts. But my recent test (for details of the test, see the commit message for the commit git-decribed as plplot-5.15.0-31-g3af0b2cf1) showed the combination of -dev plm (which I presume writes plbuf information to a file) and plrender (which I presume reads that information) is still using Hershey fonts! Could you please figure out a fix for this 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.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] Tentative plan for removing our support of Qt4
On 2019-09-07 16:46+0930 Jonathan Woithe wrote: Hi Alan On Mon, Sep 02, 2019 at 01:36:30PM -0700, Alan W. Irwin wrote: As someone here with a large familiarity with Qt, I would appreciate you letting me know if you forsee any trouble with this overall plan to remove our Qt4 support. And comments on this plan from the other PLplot developers here are also encouraged. Depending on the timing between the versions which make up the plan, I suspect this will be fine. FYI Slackware does not (yet) ship Qt5 (there are various reasons for this, the discussion of which is outside the scope of this thread). There is a third-party source of Qt5 for Slackware though which users can install if they have a need for Qt5. Therefore once PlPlot 5.18.0 rolls around, plplot will no longer be usable under a standard Slackware installation unless the Qt5 packages from the AlienBob repository are installed. The other option (which I'm personally *really* hoping for) is that Qt5 ships in Slackware by that time. If this happens, the yet to be released Slackware 15 will be the first Slackware version to ship Qt5 as part of the distribution. Given the low number of users of plplot on Slackware I don't believe your plan should be changed as a result of the above information, especially since there is a viable workaround. I mention it only for completeness so people are aware of the possible impact and the steps needed to circumvent it. Hi Jonathan: Thanks for this information about the current lack of Qt5 on official Slackware. My gut feeling is Qt4 has become dated and Qt5 is its worthy successor. Therefore, I would be surprised if this lack of Qt5 on Slackware persists much longer, i.e., I think it is likely you will get your wish sooner rather than later. But if that doesn't happen for some reason, PLplot-5.18.0 would still be usable on official Slackware if a user decided not to use the workaround you mentioned above. Of course, Qt-related components of PLplot such as the devices provided by our "qt" device driver would be automatically dropped by our build system when it did not find Qt5, but other excellent choices for devices such as those provided by our "cairo" device driver would still be available (assuming our build system finds on Slackware the Pango and Cairo libraries upon which our "cairo" device driver depends). By the way, Slackware was my very first Linux distribution (in 1996 on a pentium-133). Happy days! 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.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] Tentative plan for removing our support of Qt4
On 2019-09-06 21:33-0400 Hazen Babcock wrote: @Hazen: In light of the smoke binding issue we should discuss this still tentative roadmap further. That smoke binding issue is bindings/qt_gui/smoke/ needs to be removed when we drop support for Qt4 because [smoke is not available for Qt5](https://news.ycombinator.com/item?id=20636312). You apparently implemented the PLplot smoke binding because that binding was needed by another independent project of yours. No problem, go ahead and remove the smoke bindings. Hi Hazen: Thanks for that clarification. As a result, the timing of the roadmap for removing everything to do with Qt4 (including our smoke and pyqt4 bindings) from PLplot is much more certain and now reads as follows: Revised roadmap: * PLplot-5.17.0. Officially deprecate everything in PLplot that is related to Qt4 in our release notes and also mention there the planned dropping of everything in PLplot that is related to Qt4 in PLplot-5.18.0. Despite those planned remarks in the release notes, the only change from the Qt-related build system logic for 5.16.0 that has just been committed will be a deprecation warning to the user when they specify -DPLPLOT_USE_QT5=OFF. * PLplot-5.18.0. Drop everything in PLplot that is related to Qt4. That essentially means removing all logic stanzas in our build system that are currently only exercised when -DPLPLOT_USE_QT5=OFF. The removal of our smoke binding and our pyqt4 binding (only available when -DPLPLOT_USE_QT5=OFF) will be part of this change. The result of this change should be a substantial simplification of our build system. Also, our current lack of testing of the -DPLPLOT_USE_QT5=OFF case (because I don't have time to test both -DPLPLOT_USE_QT5=ON and -DPLPLOT_USE_QT5=OFF) obviously will no longer be a concern after this change. 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.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] Tentative plan for removing our support of Qt4
On 2019-09-02 13:36-0700 Alan W. Irwin wrote: Hi António: Your fix of the serious Qt5 font configuration bug for PLplot made our Qt5 results in PLplot-5.15.0 essentially as good as our Qt4 results for the first time ever. So ever since that release it has been on my mind to greatly reduce the complexity of our build-system *and* testing of our Qt and PyQt components by only supporting Qt5 (i.e., dropping our support for Qt4). The current build-system situation is Qt4 is looked for first, but if it is not found Qt5 is used as a backup with the exception that Qt5 is forced if the user specifies -DPLPLOT_USE_QT5=ON (which defaults to OFF). So my proposed plan to reach the above goal with minimum disruption for users is the following: * PLplot-5.16.0. Use the exact same build system logic except that 4 and 5 are swapped. That is Qt5 is looked for first, but if it is not found Qt4 is used as a backup with the exception that Qt4 is forced if the user specifies -DPLPLOT_USE_QT4=ON (which defaults to OFF). Warn in the release notes of this change and the corresponding replacement of the PLPLOT_USE_QT5 option with PLPLOT_USE_QT4 and also mention we plan to deprecate Qt4 support in the next release and remove it in the next release after that. To Hazen and António: @António: Thanks for your support (in a different post) for my preliminary roadmap for dropping Qt4. @Both: In the event, the above "5.16.0" step was much easier than the intrusive change I described above. Instead, all I essentially did was to change the default value for PLPLOT_USE_QT5 from OFF to ON. (See the Qt-related change in the new (commit 24d0bdf70) version of README.release for the details.) Revised rest of the roadmap. * PLplot-5.17.0. Officially deprecate Qt4 in the release notes and also say we intend to drop it for 5.18.0 there. The only change from the above build system logic is an additional deprecation warning to the user when they specify -DPLPLOT_USE_QT5=OFF and no fall back to Qt5 if Qt4 cannot be found. * PLplot-5.18.0 (or whenever we decide to pull the plug on Qt4 support considering the smoke issue below). Completely remove support for Qt4 (which will finally achieve the desired build-system and test simplifications which is the fundamental motivation for this change). @Hazen: In light of the smoke binding issue we should discuss this still tentative roadmap further. That smoke binding issue is bindings/qt_gui/smoke/ needs to be removed when we drop support for Qt4 because [smoke is not available for Qt5](https://news.ycombinator.com/item?id=20636312). You apparently implemented the PLplot smoke binding because that binding was needed by another independent project of yours. Assuming you do want to develop a Qt5-based binding which would satisfy the needs of your independent project in the same way the your current Smoke Qt4-based binding does, from the "history lesson" in the above URL it appears one possible way forward for Qt5 bindings of any kind is [Shiboken](https://wiki.qt.io/Qt_for_Python/Shiboken). For example, Shiboken is used to implement pyside2 (python binding for Qt5), but I have no clue how difficult it would be for you to replace your smoke binding with a corresponding Shiboken binding. Anyhow, please let me know whether you plan to replace the above smoke binding once it is removed as part of dropping our Qt4 support. And your input on the timing of dropping our Qt4 support is needed as well. By the way, when that support is dropped our pyqt4 binding will have to be removed as well, but that should not be an issue at least for now since our current pyqt5 binding seems to work OK. But that pyqt5 binding does depend on the external pyqt5 project which depends on another external project (sip). So our pyqt5 binding will become vulnerable if either the external projects pyqt5 or sip becomes unmaintained. The above pyside2 project is a recent competitor to pyqt5. And contrary to the expectations of the above 2017 discussion, pyside2 has been released and is apparently going strong. (For example, Debian Buster has many pyside2 packages and the necessary shiboken packages to support pyside2.) Therefore, if you were interested, I would encourage you to implement a pyside2 binding and pyside2_example corresponding to pyqt5_example just in case it turns out that external pyqt5 of sip ever goes the same way that smoke has gone. 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.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ L
[Plplot-devel] Tentative plan for removing our support of Qt4
Hi António: Your fix of the serious Qt5 font configuration bug for PLplot made our Qt5 results in PLplot-5.15.0 essentially as good as our Qt4 results for the first time ever. So ever since that release it has been on my mind to greatly reduce the complexity of our build-system *and* testing of our Qt and PyQt components by only supporting Qt5 (i.e., dropping our support for Qt4). The current build-system situation is Qt4 is looked for first, but if it is not found Qt5 is used as a backup with the exception that Qt5 is forced if the user specifies -DPLPLOT_USE_QT5=ON (which defaults to OFF). So my proposed plan to reach the above goal with minimum disruption for users is the following: * PLplot-5.16.0. Use the exact same build system logic except that 4 and 5 are swapped. That is Qt5 is looked for first, but if it is not found Qt4 is used as a backup with the exception that Qt4 is forced if the user specifies -DPLPLOT_USE_QT4=ON (which defaults to OFF). Warn in the release notes of this change and the corresponding replacement of the PLPLOT_USE_QT5 option with PLPLOT_USE_QT4 and also mention we plan to deprecate Qt4 support in the next release and remove it in the next release after that. * PLplot-5.17.0. Deprecate Qt4, i.e., use it as a fall back from Qt5 *only* if the users sets -DPLPLOT_QT4=ON. Warn in the release notes of this change and also warn we plan to remove support for Qt4 in the next release. * PLplot-5.18.0. Completely remove support for Qt4 which will finally achieve the desired simplifications mentioned above. As someone here with a large familiarity with Qt, I would appreciate you letting me know if you forsee any trouble with this overall plan to remove our Qt4 support. And comments on this plan from the other PLplot developers here are also encouraged. I will likely implement the 5.16.0 part of the above plan late this week if there are no strong disagreements expressed here in the next several days. 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.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] D language support topic
On 2019-09-02 07:47- Arjen Markus wrote: Hi Alan, I will have a look at this - I have built CMake before, that should not be a problem . I have no experience, however, with the D compiler you mention. Hi Arjen: Thanks for your willingness to do the requested test_d tests on MSYS2 with dmd. The results of those tests should help me to get our CMake D language support working correctly for the Windows-dmd case for both test_d and PLplot. Alan -Original Message- From: Alan W. Irwin Sent: 01 September 2019 01:40 To: Takeshi Enomoto ; Arjen Markus ; PLplot development list Subject: Re: [Plplot-devel] D language support topic To Takeshi and Arjen: I have now (git described as plplot-5.15.0-21-gf7d9bec36) pushed this topic to the PLplot master branch at SourceForge. This new D language support (see README.release for details) works perfectly on Linux (all comprehensive tests have passed perfectly on my Debian Buster platform), and I hope Takeshi (who contributed part of the changes that have gone into this push) would be willing to test this new D language support for PLplot on the MacPorts platform and Arjen on the MSYS2 platform. @Takeshi: as MacPorts maintainer of the plplot package for that distribution, this push cannot help you immediately with dmd because the push only works for that compiler if you have first built an extremely recent version of CMake, and it will take quite a while until that recent version of CMake propagates officially to MacPorts. But if you are still interested in testing for your future dmd MacPorts benefit (or want to test gdc instead which should work with the current official MacPorts version of CMake), then please follow the directions in cmake/test_d/README (which include building an extremely recent version of CMake to use for all testing) to generate a report tarball in the two ways requested so I can analyze those results and adjust the "Darwin" Platform files accordingly. @Arjen: the only D compiler you have access to on Windows is one you download for yourself [from Digital Mars](https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdlang.org%2Fdownload.htmldata=02%7C01%7C%7Ca962fd3984664e88519308d72e6c7d4b%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C637028915813958706sdata=Q5GbOISrDsA%2Fyxn16s2s4FeEor02in2aGUIFKRSkRLA%3Dreserved=0). I would appreciate you testing our new D language support on MSYS2 with that compiler. As in Takeshi's case I suggest you start with the test_d project for an extremely recent version of CMake from its git master branch that you have built yourself. 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.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 __ 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. ______ 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.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] D language support topic
To Takeshi and Arjen: I have now (git described as plplot-5.15.0-21-gf7d9bec36) pushed this topic to the PLplot master branch at SourceForge. This new D language support (see README.release for details) works perfectly on Linux (all comprehensive tests have passed perfectly on my Debian Buster platform), and I hope Takeshi (who contributed part of the changes that have gone into this push) would be willing to test this new D language support for PLplot on the MacPorts platform and Arjen on the MSYS2 platform. @Takeshi: as MacPorts maintainer of the plplot package for that distribution, this push cannot help you immediately with dmd because the push only works for that compiler if you have first built an extremely recent version of CMake, and it will take quite a while until that recent version of CMake propagates officially to MacPorts. But if you are still interested in testing for your future dmd MacPorts benefit (or want to test gdc instead which should work with the current official MacPorts version of CMake), then please follow the directions in cmake/test_d/README (which include building an extremely recent version of CMake to use for all testing) to generate a report tarball in the two ways requested so I can analyze those results and adjust the "Darwin" Platform files accordingly. @Arjen: the only D compiler you have access to on Windows is one you download for yourself [from Digital Mars](https://dlang.org/download.html). I would appreciate you testing our new D language support on MSYS2 with that compiler. As in Takeshi's case I suggest you start with the test_d project for an extremely recent version of CMake from its git master branch that you have built yourself. 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.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] D language support topic
This topic is being rapidly matured. The current status for the remaining work to be done is as follows: * Implement a simple standalone "test_d" project (in cmake/test_d) which is designed to allow rapid testing of D language support (that has been updated from the cmake-d project) for all available D compilers on all platforms with a simplified (compared to the PLplot project) comprehensive test script. This work is almost completed. For example, the simplified test script for test_d gives perfect results on my Debian Buster=Stable platform for gdc, ldc, and dmd. However, there is a bit more to do to finish the work on this test_d project. * Replace our ancient fork of CMakeD with a modern fork of cmake-d. This work is almost completed. * Fix any issues for our traditional (Makefile + pkg-config) build of the installed examples for both dmd and ldc without compromising the good gdc results we currently have for that particular build system. Once this is done the comprehensive test of the PLplot project itself (which includes tests of this traditional build system) should work properly for all three D compilers for the first time ever. An important caveat for the above good CMake language support results for ldc and dmd is those depend on a small fix to CMake general language support which I have applied to my own locally built version of CMake. Brad King is currently shepherding this fix through the [mostly automatic process](https://gitlab.kitware.com/cmake/cmake/merge_requests/3747) to make this fix part of a future CMake release. The current estimate is this fix should get into the CMake-3.16.0 release (likely due out in November), but [see this discussion](https://gitlab.kitware.com/cmake/cmake/issues/19631), this CMake fix is also available right now as a [simple patch that should apply to any recent version of CMake source code](https://gitlab.kitware.com/cmake/cmake/uploads/92e4545dc691a0760a52656acaea9607/0001-linking-Support-language-specific-variants-of-CMAKE_.patch.gz). In sum, in comparison to my last status report for this topic, I am much closer to reaching the goal that comprehensive testing for both test_d and PLplot itself is working correctly on Debian Buster for all three D compilers. 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.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] D language support topic
On 2019-08-14 18:29-0700 Alan W. Irwin wrote: So replacing our ancient fork of CMakeD with a modern fork of cmake-d currently looks like the proper way forward. However, before implementing that I need to do more comparisons between the two CMake D language support projects for dmd, and assuming I can get dmd to work correctly for our needs for cmake-d using modest changes to cmake-d, I also need to try out ldc (not available for our ancient fork of CMakeD) using cmake-d. The current status is I am making good progress with bug fixes for the cmake-d D language support so that it works for our needs. So for example, I have gotten dmd to work well enough for our CMake-based core build of the D binding and examples on Debian Buster (for a dmd compiler I built for myself since Debian does not package that compiler) that I was able to build the D binding and compile (but not yet link because of at least one remaining issue with cmake-d) all the (updated) D examples with dmd. The results of that dmd compilation of the examples confirmed all of the example fixes (other than x16d.d) that Takeshi Enomoto donated via our patch tracker, and I was also able to solve the remaining dmd compilation errors (which occurred only for x16d.d). My plan for maturing this topic before I push it to master includes the following general steps: * Fix the remaining cmake-d issues for the dmd compiler (as far as I know there is only one such issue left which is the current bad linking of the D examples). And confirm this cmake-d change does not compromise the current good cmake-d results with the gdc compiler. * Fix any cmake-d issues with the ldc compiler without compromising the good gdc results and the (now) good dmd results. * Fix any issues for our traditional (Makefile + pkg-config) build of the installed examples for both dmd and ldc without compromising the good gdc results we currently have for that particular build system. * Replace our ancient fork of CMakeD with a modern fork of cmake-d. In other words, all the above steps will be done with external (patched) cmake-d, and this step will integrate that patched version into PLplot source code for the convenience of our users. The test of whether this topic has truly been matured will continue to be our comprehensive test script (which tests our three build systems for all our library and device variants) should produce perfect results for D for each D compiler (gdc, dmd, and ldc). 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.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
[Plplot-devel] D language support topic
Some essential background information for this post is "D" is an interesting and distinct computer language that is a re-engineered version of C++. Presumably because of all the programmer interest in "D", there are three well-known D compilers with free software licenses. They are 1. dmd (the fundamental D compiler from "Digital Mars" which effectively sets the D syntax standards); 2. ldc (a D compiler with dmd front-end [the part of the compiler that transforms D syntax to a language-independent intermediate representation] and LLVM back-end); and 3. gdc (the GNU-implemented D compiler which has its own unique front-end and gcc backend). My own Debian Buster platform gives me access to official ldc and gdc packages, and I have built a working dmd on that platform from the Digital Mars source code for that compiler. So I think with some work all developers here with access to Unix platforms and an interest in "D" should be able to gain access to all three compilers. The D compiler choice is more limited on Windows. For example, there are no official packages for ldc and gdc on Cygwin or MSYS2 so I suspect both compilers would need a lot of work before they worked on Windows. However, dmd is apparently available for all Windows platforms as a free download from Digital Mars so developers here who are limited to just Windows platforms can still try out our D binding and examples once I make dmd one of the compilers that are correctly supported for the PLplot needs by our CMake D language support logic. I started this development topic a few days ago in response to <https://sourceforge.net/p/plplot/patches/35/> where the poster's commentary indicated the installed D examples would not traditionally compile with dmd, and his substantial patch to the source code for the D examples fixed all such issues except for x16d (where his issue for that example may have been due to the differences between the gdc-built plplotdmd library that was presumably installed and the dmd-built examples). I have since been able to update our D examples (on a private topic branch which I plan to push in due course) with that patch and show that gdc D compiler was able to compile and run those updated examples without run-time or diff-report issues in our build tree. So that (examples that now work locally for me with gdc and externally for someone else with dmd) is a promising start to this topic, but to finish it I want to generalize our CMake D language support logic and overall logic so that the ldc and dmd D compilers work as well for me as the gdc compiler currently does for our 3 different D builds (the CMake-based build of our D binding and examples, the CMake-based build of our installed D examples that are linked to our installed D binding, and the traditional (Makefile + pkg-config) build of our installed D examples that are linked to our installed D binding). Our current CMake D language support (located in cmake/modules/language_support/cmake) was forked by Werner Smekal from the (now defunct) CMakeD project in 2009. My comprehensive tests show our fork does support gdc well on Linux (except for some known limitations such as being forced to use a static version of the plplotdmd library). Our fork does have dmd support which might have been tested by Werner in 2009, but I don't think anyone has tested it since with dmd. Our fork has no support for ldc. Our changes to the 2009 version of CMakeD have been fairly small but significant, but since then there have been other more substantial changes and forks of that project culminating with the cmake-d project at <https://github.com/dcarp/cmake-d> which continues to be actively developed. Note that project advertises that it supports all three of dmd, ldc, and gdc. That ldc support is just not available with our fork of CMakeD, and I think it is quite likely (modulo a few modest changes like the rpath one below) that cmake-d has better support for dmd than our fork. So I tried gdc with cmake-d language support (accessed externally), and I ran into an rpath issue which should easily be fixed (since our fork of CMakeD does handle rpath well) but which I temporarily worked around with LD_LIBRARY_PATH. They results of that experiment were perfect (no run-time or diff report issues with the updated D examples). So replacing our ancient fork of CMakeD with a modern fork of cmake-d currently looks like the proper way forward. However, before implementing that I need to do more comparisons between the two CMake D language support projects for dmd, and assuming I can get dmd to work correctly for our needs for cmake-d using modest changes to cmake-d, I also need to try out lcd (not available for our ancient fork of CMakeD) using cmake-d. More later. Alan __ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar inte
[Plplot-devel] Plans for a last Python2 versus Python3 fix, Python2 deprecation by 5.16.0 and removal by 5.17.0
On 2019-08-06 13:18+0100 Phil Rosenberg wrote: Sorry, my last email wasn't sent to the list - see below. I think I have found the solution, by changing the shebang to python2 rather than python. I'm going to commit this change as it is a change that only affects us developers. Alan - if you could test to check it works on your linux system, that would be great. Hi Phil: Sorry for my own delay in answering you which was caused by gmail troubles (started by a bad recovery) that has finally been straightened out yesterday (Thursday) after 5 days of no gmail access for me. Glad you found a solution for the scripts/convert_comment.py issue. That's a good solution in the short term but unfortunately not in the long term. The problem is Python2 is near its end of life (see, for example, the discussion in <https://lwn.net/Articles/756628/>). And in any case very likely due to anticipation by Python developers of that end of life, my experience is Python2 is buggy and not as well supported as Python3. So in any case I planned to deprecate the PLplot Python2 support soon and remove it completely fairly soon after. So I will need to generalize your above solution for the Python3 case. [The essential documentation for this general solution](https://portingguide.readthedocs.io/en/latest/exceptions.html) shows there are both "except" and "raise" differences in Python2 versus Python3 syntax for handling exceptions. Furthermore, there are a number of different places in our Python code where we use "except" and "raise", and apparently they are all currently implemented in Python2 syntax (as you discovered for the case of the raise command in scripts/convert_comment.py). My plan for dealing with this issue is to change all "except" and "raise" Python commands to Python3 syntax only (this will include scripts/convert_comment.py and therefore changing your shebang from python2 to python3 and testing that change works here under python3) and deprecation of Python2 (meaning users will have to go out of their way to specify -DPL_DEPRECATED_PYTHON=ON in order to still access Python2). This planned deprecation in the current release cycle should propagate to the forthcoming 5.16.0 release, and the further plan is to remove Python2 completely early in the next release cycle that will lead to 5.17.0. If you or anyone else here has concerns about any aspect of the above general plans (but especially the timing of the Python2 deprecation and/or removal), please let me know soon. Alan On Tue, 6 Aug 2019 at 12:50, Phil Rosenberg wrote: Hi Alan The error message I gave is the complete error message, there is no output of the line variable. This, combined with the fact that the carat is pointing to the end of the line of python code, made me think this was a syntax error in the python code itself. When I opened convert_comment.py in visual studio, the error highlighting underlined all instances of raise RuntimeError. Hovering the mouse over displayed the following error invalid syntax, only exception value is allowed in 3.x Googling this error lead me to https://stackoverflow.com/questions/34463087/valid-syntax-in-both-python-2-x-and-3-x-for-raising-exception So I think, basically the syntax for raise has changed between 2.x and 3.x and for whatever reason, on my system the script is being executed using 3.x Any fix suggestions? I don't really know python at all. Phil On Wed, 31 Jul 2019 at 19:49, Alan W. Irwin wrote: On 2019-07-31 12:44+0100 Phil Rosenberg wrote: Thanks Alan I've just tried again with the style_source script, but I'm hitting another problem. I now get the error: File "scripts/convert_comment.py", line 72 raise RuntimeError, "Cannot interpret trailing character(s) after */ for this line" ^ SyntaxError: invalid syntax ERROR: scripts/convert_comment.py failed for file plplot_config.h.in Any suggestions? I have both python 2 and 3 installed. That error message comes from this logic in scripts/convert_comment.py which hasn't been changed (from git blame -w) since 2010. # Note trailing "\n" has not (yet) been removed from line so # that the next to last character is at position len(line) - 3. if end_comment >=0 and end_comment != len(line) - 3: if ifsingleline and start_comment >=0: # Skip most further processing for a line with embedded # comments outside of multiline blocks of comments. start_comment = -1 end_comment = -1 else: sys.stderr.write(line) raise RuntimeError, "Cannot interpret trailing character(s) after */ for this line" So that error message should have included the results from sys.stderr.write(line) from the line in plplot_config.h.in that is stored in the Python "line" variable that appears to be causing thi
[Plplot-devel] What more steps do you need to do to finish up your part of the PLplot error handling topic?
Hi Phil: There are a number of unresolved topics between us including getting styling and comprehensive testing to work on MSYS2 and to fix up the remaining "interactive" errors for the wxwidgets device (e.g., making examples 17 and 20 display "interactively" like they currently do for xwin). But this post is about yet another unresolved topic between us concerning the steps necessary to finish up all but the tedious final editing work (which I can take responsibility for) on your PLplot exception handling topic. If I remember the status of that topic correctly, you got your setjmp/longjmp C exception handling to work well in a proof-of-concept way with at least one public API function providing the TRY and CATCH blocks with plexit changed to throw exceptions with THROW. Assuming that summary is correct as far as it goes, can you comment on whether you handled the problem of one public API function calling one or more other public API functions? (plbox calling plaxes is a trivial example of this, but there are many more such examples.) In other words, can you propagate the exception introduced by plexit back through one or more public API calls until you reach the first public API call in the chain that has been called by an external library or app? Assuming the solution to that propagation problem is straightforward (or has been implemented already) are all the remaining steps simply editing ones, e.g., putting the appropriate TRY and CATCH blocks of code at the start of each public API function and replacing all calls to exit by calls to plexit? If so, I would be willing to do those necessary editing steps and conclude this project by merging all our combined work (in a private topic branch shared between us) to the master branch. But I don't know how much effort it will take you to get to the stage with this topic where I can take over by finishing it that way. I also don't know whether you think your work on this topic is higher or lower priority than your work on the other unresolved PLplot topics I have mentioned above. So please let me know what your PLplot priorities are so I have some idea what to expect from you by the time 5.16.0 is released (which should ideally occur before December 1st, i.e., we are already roughly one third of the way through the current release cycle). 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.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] uncrustify msys2
On 2019-07-31 12:44+0100 Phil Rosenberg wrote: Thanks Alan I've just tried again with the style_source script, but I'm hitting another problem. I now get the error: File "scripts/convert_comment.py", line 72 raise RuntimeError, "Cannot interpret trailing character(s) after */ for this line" ^ SyntaxError: invalid syntax ERROR: scripts/convert_comment.py failed for file plplot_config.h.in Any suggestions? I have both python 2 and 3 installed. That error message comes from this logic in scripts/convert_comment.py which hasn't been changed (from git blame -w) since 2010. # Note trailing "\n" has not (yet) been removed from line so # that the next to last character is at position len(line) - 3. if end_comment >=0 and end_comment != len(line) - 3: if ifsingleline and start_comment >=0: # Skip most further processing for a line with embedded # comments outside of multiline blocks of comments. start_comment = -1 end_comment = -1 else: sys.stderr.write(line) raise RuntimeError, "Cannot interpret trailing character(s) after */ for this line" So that error message should have included the results from sys.stderr.write(line) from the line in plplot_config.h.in that is stored in the Python "line" variable that appears to be causing this python logic problem. The usual interpretation of this error message is you have commentary in plplot_config.h.in which is not in legitimate form. For example, you might have forgotten the trailing "*/" on a comment. So I would test that possibility by attempting to build the plplot target before styling, which would necessarily attempt to compile the configured plplot_config.h. However, if that "easy" answer is not the correct one, please send the complete error message including the output of the Python "line" variable that is causing the issue. Of course, the above Python logic only works if there are no line-ending issues in Python, i.e., the Python "line" variable contains a string that is terminated simply by \n rather than \r\n. And note that by git default plplot_config.h.in will have \r\n line endings on MSYS2. But the discussion in <https://stackoverflow.com/questions/10785131/line-endings-in-python> seems to imply that on Python automatically converts all \r and \r\n line endings for text files to \n. Also, my impression is you have exercised the above scripts/convert_comment.py logic from 2010 with no issues in the past on Cygwin (where again, the checked out plplot_config.h.in should have \r\n line endings.) So I would only look at this potential line ending issue (by dumping out each raw byte of the above line) only as a last resort (i.e., only if the line that is causing this error compiles with no issues). 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.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] Preliminary good PLplot results with Brad King's fork of Ninja
P.S. @Brad: I should have also mentioned that the build script does the following inside the git repository: # For rebuilds *using a separate build tree*, "git status" reveals # ninja has a build bug where re2c modifies src/lexer.cc in the source # tree. So remove this source-code change so you are guaranteed to start # with a completely fresh source tree: git checkout -- src/lexer.cc Which works around a ninja source-tree contamination bug that needs fixing. 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.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
[Plplot-devel] Preliminary good PLplot results with Brad King's fork of Ninja
To the PLplot developers and Brad King: @Brad: I am including you in this discussion because I thought you might be interested in these good PLplot results with your fork of Ninja. @Developers: Ninja should be of interest to us as a back-end for CMake because ninja works on all platforms and has a reputation for being fast because of its design philosophy (which is to execute all the low-level build system stuff as quickly as possible while leaving all the complex decision making for builds to higher-level build system software such as CMake). And Brad King's fork of ninja is of interest to us because it fixes Fortran issues with the upstream version. I. Building, testing, and installing Brad King's fork of ninja. I attach a bash script to do that. It should be run as follows: ./king_ninja_git_build.sh v1.9.0.g99df1.kitware.dyndep-1.jobserver-1 Here are the extra messages (i.e., those without leading '[') that are generated by ninja_test The last one of these should be "passed". Raise [ulimit -n] above 1025 (currently 1024) to make this test go ninja: warning: -jN forced on command line; ignoring GNU make jobserver. passed @Brad: In response to that first message I tried ulimit -n 1026 (which worked according to ulimit -a), but then after that ninja_test failed with ninja: fatal: pipe: Too many open files and the only way to fix that was to go back to "ulimit -n 1024" I don't know the significance of the second message, but I thought you should be informed of it. II. PLplot testing of Brad's fork on ninja @Everybody: This is a preliminary test of PLplot because I found that the Java, Octave, and Ada components of PLplot did not work with ninja. I need to investigate further to decide whether these issues are due to our own language-support issues for Ada, build-system issues for all three components, and/or CMake/ninja issues. But for now I shut down those components with -DENABLE_java=OFF -DENABLE_octave=OFF -DENABLE_ada=OFF and under these conditions the times required to configure PLplot with cmake were as follows: -G"Ninja" real0m8.732s user0m6.867s sys 0m3.156s -G"Unix Makefiles" real0m9.730s user0m7.781s sys 0m3.134s ==> Significant configuration time advantage for Ninja Here were the times required to build the test_noninteractive target after each of the above clean configurations: -G"Ninja" software@merlin> time env PATH=/home/software/ninja/install-v1.9.0.g99df1.kitware.dyndep-1.jobserver-1/bin:$PATH ninja -j16 test_noninteractive >& test_noninteractive.out real1m5.298s user7m19.614s sys 0m47.019s -G"Unix Makefiles software@merlin> time (make -j16 test_noninteractive >& test_noninteractive.out) real1m21.388s user7m31.672s sys 0m58.231s ==> Significant run-time advantage for Ninja In both cases the resulting test_noninteractive.out file showed no obvious run-time issues and gave a clean difference report for the default svg device, e.g., c++ Missing examples: Differing graphical output : Missing stdout : Differing stdout: d Missing examples: Differing graphical output : Missing stdout : Differing stdout: fortran Missing examples: Differing graphical output : Missing stdout : Differing stdout: lua Missing examples: Differing graphical output : Missing stdout : Differing stdout: ocaml Missing examples: Differing graphical output : Missing stdout : Differing stdout: python Missing examples: Differing graphical output : Missing stdout : Differing stdout: tcl Missing examples: Differing graphical output : Missing stdout : Differing stdout: By the way, I haven't tested this, but apparently an even more significant speed advantage for Ninja is it reduces the CMake reconfiguration time when, for example, you have edited one PLplot file and wish to reconfigure/rebuild. So for now, I would advise all those that are not interested in the Java, Octave, or Ada components of PLplot to give the Brad King fork of ninja a try. In particular since ninja has been designed from the ground up to support parallel builds while parallel builds are an add-on for the GNU-make case it is likely you should get good parallel build results for ninja on the Cygwin and MSYS2 platforms where Arjen's experience is that parallel builds are not reliable on those two platforms for GNU-make. I haven't tried upstream ninja, but since Brad's fork of that software is designed to fix fortran issues, then I assume everything that worked above except the fortran component should work well if one of you prefers to try the upstream version o
Re: [Plplot-devel] uncrustify msys2
On 2019-07-25 16:09-0700 Alan W. Irwin wrote: [ C]ompletely finishing this project will take much longer than expected because of [...] complications with styling the swig directive (*.i) files that occur in bindings/ where is one of java, python, lua, or octave [] Those complications have finally been dealt with (see commit plplot-5.15.0-13-g2ec8daf88), and, as far as I know from my successful noninteractive and interactive tests on Linux, this commit completes the work of moving from uncrustify 0.60 to 0.69.0 to style our source code. However, the source code styling changes for this topic were quite intrusive so further testing of these style changes would be a good idea for non-Linux platforms. 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.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] uncrustify msys2
On 2019-07-25 18:30-0700 Alan W. Irwin wrote: For those interested in building uncrustify 0.69.0 from the git tag (which should be all developers here who would like to run the bash script scripts/style_source.sh to style their source-code updates before committing those changes), I have attached my newly implemented bash script for building uncrustify. (I have recently successfully used this script to configure, build, install, and test uncrustify 0.69.0 for myself with complete success.) Note this script has a number of useful comments about how to run the script, how to tailor it for local conditions, and the details of the git clone command that needs to be run just once (in the same directory where you have placed this script) to get access to the git version of the uncrustify source code *before the first time* you run the script. P.S. I have configured gmail to *not* filter mail with their spam filtering application, and to deliver all email (regardless of whether gmail decides it is spam or ham) to my local computer using the getmail application on that computer. That application uses procmail to actually deliver the mail to my local inbox (following the general "Unix/Linux" philosophy that applications are designed to do just one thing well, and to hand off to another well-designed application to do some other step in a chain of steps.) And because of that procmail link in my input mail chain, I can use spam_bayes to filter for spam just in one place in that chain under my sole control. And this whole system works well so that very little spam gets into my inbox, and, for example, the bash script attachment came back to me from the SF mailing list without being stripped. However, I now recall others here do not have complete control of their spam filtering so the possibility exists that such filtering will silently strip out bash script attachments. So I resend that attachment in this e-mail in gzipped form. And, of course, if you have a spam filter somewhere in your input mail chain that strips out all attachments including gzipped ones, then it is time for you to either complain to those who are doing such complete stripping and/or gain sole control of your spam filtering so you to can enjoy use of such attachments. :-) 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.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 __ git_build.sh.gz Description: gzipped form of git_build.sh bash script for building uncrustify from git tag ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] uncrustify msys2
For those interested in building uncrustify 0.69.0 from the git tag (which should be all developers here who would like to run the bash script scripts/style_source.sh to style their source-code updates before committing those changes), I have attached my newly implemented bash script for building uncrustify. (I have recently successfully used this script to configure, build, install, and test uncrustify 0.69.0 for myself with complete success.) Note this script has a number of useful comments about how to run the script, how to tailor it for local conditions, and the details of the git clone command that needs to be run just once (in the same directory where you have placed this script) to get access to the git version of the uncrustify source code *before the first time* you run the script. 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.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 __ git_build.sh Description: bash script for building uncrustify from a git tag ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] uncrustify msys2
On 2019-07-24 01:40-0700 Alan W. Irwin wrote: [...]so my current ETA for the above proposed commit is late tomorrow (Wednesday) or so. Sorry, but completely finishing this project will take much longer than expected because of a complication with align_number_left (which I have dealt with) and complications with styling the swig directive (*.i) files that occur in bindings/ where is one of java, python, lua, or octave (which I have not been able to completely deal with yet). See the plplot-5.15.0-10-g16d554223 commit message for the details concerning these complications. (Use the --name-status option on git log to insure you get a feel for the large number of files changed in this commit.) Although that commit skips styling the swig directive files, it is otherwise complete so you should now be able to use scripts/style_source.sh without issues on MSYS2 for either version (one built from the appropriate git tag, one built from the appropriate tarball) of uncrustify-0.69.0. Therefore, please go ahead and run that script on that platform for your version (built from the tarball) of uncrustify-0.69.0, and let me know whether that script runs without issues. Also because the source code changes included in plplot-5.15.0-10-g16d554223 are so intrusive it is important to make additional tests beyond my own strong Linux platform test on non-Linux platforms. So along with the tests you normally perform for MSVC please also try comprehensive testing on MSYS2 (at least for the non-interactive case) to confirm these extensive source code changes are not causing any trouble on that platform. The other issue, of course, is all these source code changes introduce conflicts for topic branches that have not been rebased to the lastest master branch. However, resolution of these conflicts should be entirely straightforward since "git diff --ignore-all-space" showed all the source code changes were simply whitespace changes. 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.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] uncrustify msys2
Hi Phil: On 2019-07-23 18:44+0100 Phil Rosenberg wrote: Hi I just wanted to check if anyone on the list has used uncrustfy in msys2 to run the style-source script? I am very happy to hear you are making progress with MSYS2, and I look forward to your comprehensive test reports for that platform.. I couldn't find an uncrustify package to install via pacman, so I built it from source. However, when I run style_source.sh I get the following error Detected uncrustify version = 'Uncrustify-0.69.0_f'. This script only works with uncrustify 0.60. Out of inertia I have stuck with uncrustify 0.60 up to now, but it is obviously way past time to move to the latest version (0.69.0) so I have taken responsibility for making that change. One minor issue that I am currently looking at is the following (mild) warning message I encountered from the CMake-based build system for uncrustify: -- scripts/make_version.py exited with code 64: Unknown version control system in '/home/software/uncrustify/uncrustify-0.69.0'. As a fallback, version 'Uncrustify-0.69.0_f' will be used. Since the version string reported by you is 'Uncrustify-0.69.0_f' I assume your build has the same warning message. I am virtually positive that warning is due to us both building from the appropriate tarball rather than appropriate git tag, but I will know a lot more tomorrow (after getting some sleep) after I finish implementing a bash script to configure, build, install, and test from the appropriate git tag corresponding to the desired uncrustify version. (For git enthusiasts like me such a build is actually easier to do than a build from a tarball). But my guess at this stage is that script result will be the above minor issue will be fixed (since git is virtually certainly the version control system that their build system is looking for) and the uncrustify executable version string we both encountered with the tarball build of 'Uncrustify-0.69.0_f' will likely be replaced by 'Uncrustify-0.69.0'. But I will see about that version string tomorrow and see also the FIXME note below concerning that. Here is the PLplot commit message I have in mind for tomorrow (adapted from the git commit message when I updated from 0.58 to 0.60 ~5 years ago): Update from uncrustify version 0.60 to 0.69.0. This commit includes the following changes. 1. Update annotated configuration file using uncrustify --update-config-with-doc -c uncrustify.cfg > uncrustify-0.69.0.cfg mv uncrustify-0.69.0.cfg uncrustify.cfg 2. Update scripts/style_source.sh to change from 'uncrustify 0.60' for the allowed uncrustify version string to either 'Uncrustify-0.69.0' (built from appropriate git tag) or 'Uncrustify-0.69.0_f' (built from appropriate tarball) (FIXME if the git version of the build provides a version string different than 'Uncrustify-0.69.0') 3. Run that script to update the style of a large number of our source code files according to the uncrustify 0.69.0 rules. We ascribe these large number of whitespace changes to changes in the implementation (new features with default configuration, bug fixes, and/or introduced bugs) between uncrustify 0.60 and 0.69.0. Note that visual sampling of these changes didn't reveal any obvious style issues, and these changes also passed the test below: Tested by Alan W. Irwin on Linux (Debian Buster) by building the test_noninteractive target in the build tree and evaluating the result to demonstrate no build-time or run-time errors, and no issues with the SVG difference report. Finishing implementing the uncrustify build, install, and test script and all the above changes, tests, and test evaluations is obviously going to take me a while, but it all appears to be entirely straightforward so my current ETA for the above proposed commit is late tomorrow (Wednesday) or so. More then. 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.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] CMake problem with hyphen in path
On 2019-07-13 08:05- Phil Rosenberg wrote: Hi Alan You may be right. I tried commenting out the offending regex replace, which meant cmake finished with no issues. But, when I tried to compile I found I had a similar problem with header files. I couldn't actually find the offending code that is causing that problem. I tried adding some quotes, but that didn't seem to help. So whatever workload you thought it was, it is actually double! Actually there is at least one or two orders of magnitude more work according to my Linux tests if you consider dealing with this problem for all external free software libraries that PLplot depends on rather than just wxwidgets. And the results would depend on all external libraries (and CMake itself) dealing with blank in pathname issues correctly which some preliminary tests I have done appears to be far from the case. So the fundamental issue is PLplot has been responsible about its own internal source, build, and install tree blanks in pathname issues, but other free software has not been that responsible. And a large supplementary issue is that even if external software eventually becomes completely responsible about this case, there would still be a lot more to do on the PLplot side to make "space in external library prefix" case work properly for all external libraries. Would it be relatively straightforward to add a check, so if the user supplies an install or library/header path that contains " -" then we error out at that point? The problem with *complete* configuration-time detection of that case is that we would have to have reliable parsing to detect the difference between hyphenated/spaced pathnames as opposed to the " -" that delimits linker options. That said, we could easily warn against the case where "- " appears anywhere in the options string since that case is obviously not a linker option. If you agree, I will take responsibility for implementing such a check. But that check would obviously not guard against the case of, say, an -L option of the form -L/whatever -hyphen_pathname where "whatever -hyphen_pathname" was the complete pathname rather than "whatever" being the pathname with "-hyphen_pathname" being a separate linker option. And the check would only be available for the external wxwidgets library and all external libraries that use pkg-config. So to supplement that proposed incomplete configuration-time check I think we should create a prominent warning in our wiki for users not to use installation prefixes that contain spaces for external free software libraries. I emphasize spaces rather than hyphens here since it is the spaces that generate all the issues with or without hyphens according to my Linux tests. Also, most experienced Unix users would not try spaces in installed library prefixes, but some might do that so I think the warning should be a general one rather than Windows only. If you agree that wiki "no-space in external library prefixes" warning would be useful as well, would you take responsibility for updating the most fundamental PLplot build page in our wiki (whatever that is) to that effect? 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.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] CMake problem with hyphen in path
On 2019-07-13 00:35+0100 Phil Rosenberg wrote: There are no .pc files. I'm building on native windows with visual studio (not with Cygwin or MSYS2) so there is no pkg-config. All libraries get found with the findXXX.cmake modules. In this case it is shapelib and wxwidgets libraries. On windows CMake basically hunts in certain locations for the libs and headers. In this case it finds shapelib by checking in my CMAKE_INSTALL_PREFIX and it finds wxWidgets via the WXWIN environment variable. [...] Output (original _link_flags_list) = debug;C:/Users/earpros/OneDrive - University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib; [...] (post regex replace _link_flags_list) = debug;C:/Users/earpros/OneDrive;- University of Leeds/Documents/usr/src/wxWidgets-3.0.4/lib/vc_x64_lib/wxbase30ud.lib; [...] Hi Phil: Thanks for the above detailed information which contradicted some of my assumptions (natch). However, I am frankly beginning to get cold feet about working much further on this topic since from my Linux test of the case where external libraries have blanks and hyphens in their installation prefixes, there are a huge bunch of issues we would have to deal with before that case worked, i.e., it would be a lot of work for little real gain. For example, my understanding is Windows installers typically give you a choice of any installation prefix you want. So wouldn't it be a lot easier to ask our Windows users to be careful of that choice, i.e., pick installation prefixes without blanks or hyphens? For example, MSYS2 allows users to choose any installation prefix they like. And I think they even recommend not choosing an installation prefix with spaces because of all the trouble that causes with free software. 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.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
[Plplot-devel] CMake problem with hyphen in path
Oops, I sent this to the wrong list so I am correcting that now. On 2019-07-12 05:05-0700 Alan W. Irwin wrote: I am virtually positive pkg-config has a way (likely with quotes) to properly distinguish between these two cases, but I am going to have to find what that is and adjust the above parsing logic accordingly for the general fix. Hi Phil: It turns out that the correct *.pc file syntax to handle blanks in pathnames is to quote all -L and -I options, e.g., -L"whatever blank". Could you send me all the *.pc files (wrapped in a tarball for my convenience) for the external libraries used by PLplot that you have installed with " - " in the pathname? Unless I am missing something those *.pc files will have " - " embedded in every pathname mentioned in those files. And if so, then I want to check that those pathnames are all quoted correctly. 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.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] Possible Windows development agendas for the next 6 months
On 2019-06-14 13:10+0100 Phil Rosenberg wrote: Just a note about MSVC, what are the ABI concerns you have? It is of note that GCC for windows does not provide ABI forward compatibility https://stackoverflow.com/a/23521099. My understanding is that MSVC's C ABI is consistent across versions and I just did a quick google and found that for C++ MSVC2015, 2017 and 2019 are all ABI compatible. https://devblogs.microsoft.com/cppblog/cpp-binary-compatibility-and-pain-free-upgrades-to-visual-studio-2019/ My concern is gcc/g++ ABI changes fairly often between versions as noted in the stackoverflow link you provided. But as the link implied modern gcc/g++ does provide an option to allow users to specify some older ABI version. So that is what Arjen had to do some time ago when he ran into a MSYS2 library that was compiled with a dated gcc suite of compilers with an older ABI. That condition is caused by the fact it takes a while for Alex to to rebuild every library to be ABI consistent with the latest gcc suite of compilers provided by MSYS2 so with MSYS2 you do run into this temporary (until libraries are rebuilt) problem periodically whenever the gcc suite of compilers has an ABI change. Note, Arjen recently also ran into the opposite problem (MSYS2 compiler had older ABI than compiler used to build the MSYS2 libraries), but that was an artifact of him attempting to use an MSYS2 platform that was not consistently updated. In sum, if using gcc/g++ to be ABI safe you should always build PLplot with exactly the same version of that suite of compilers that are used to build the libraries from the distribution (Cygwin, MSYS2, Debian, etc.). And mixing MSVC-built PLplot with gcc-built libraries or vice versa is not a good idea. However, it sounds from your experience, that if you stick with MSVC that compiler suite ABI does not change very often with version allowing you to use downloaded or built free software libraries that are built with a fairly different MSVC version (but same ABI). Interestingly it looks like Microsoft is also developing some sort of open source library packaging system, called Vcpkg, to reduce the existing pain of having to build all open source libraries from scratch https://devblogs.microsoft.com/cppblog/vcpkg-a-tool-to-acquire-and-build-c-open-source-libraries-on-windows/. Might be worth looking into. Had a quick scan down the list of available libraries and Cairo, Pango, Curl, wxWidgets are there. HA HA - JUST CHECKED AND SO IS PLPLOT!!! At version 5.13. That additional distribution of free software for Windows does sound like it is worth checking out. But the link you gave only provided a list of libraries so I am not sure whether the bash, cmp, diff, etc., Unix tools necessary for comprehensive testing are included or not. If so, then you have found a third free software distribution for Windows that generally provides what is available from MSYS2 and Cygwin. However, if not, in theory you can put the MSYS2 versions of those tools at the bottom of your PATH to allow comprehensive testing on the platform using nmake. But that workaround (which historically has worked once for Arjen when he was testing an MSVC environment with no free software libraries) makes testing life a bit tricky so you may want to just stick with pure MSYS2 instead. 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.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] [EXTERNAL] Re: Patch for PLPLOT
On 2019-06-13 16:31- Daniel Eliason wrote:
Hi Alan,
Unfortunately I made mistakes in the commit messages of the patches - here they are again, but I
edited the messages. The correct messages mention the "acc" parameter, and that
artifacts appear when the "acc" parameter is set false.
Hi Daniel:
I am Ccing the plplot-devel list because other PLplot developers there may
be interested in these changes.
I have pushed (see
<https://sourceforge.net/p/plplot/plplot/ci/9394d4358f9dc385d38e052311adfd5b557625f5/>
and
<https://sourceforge.net/p/plplot/plplot/ci/7cd47798470a816c083d4c706f3c2ff23272aff4/>)
your two commits, and these two changes will become part of the next
release of PLplot (currently planned in early December this year).
I left the first commit (memcpy to memmove) exactly as it was because
it is obviously a good change in general. However, it might interest
you to know that this commit did not change results here at all (with
or without a local change to make acc true both places in example
17). From this evidence on my platform (and also a hint in the man
page that some platforms do this) I believe that memcpy is implemented
on Debian as an alias of memmove, but from your results (as given by
your spectacularly bad screenshots of example 17 results without your
changes) that is obviously not the case for CentOS.
I have modified your second ("commentary and style") commit as follows:
* Styled your commit with our standard script. The net effect of this
modification was to move to our desired "//" form of commentary.
* Removed three of your changes where either it was obvious to me the
the effect of your change would be to actually change the result or
where I was not sure what the effect would be. The motivation for
dropping those changes is I discovered that the effect of your
unmodified commit changed results here, but that issue (for what
purports to be a style and commentary change) disappeared when I
dropped your 3 problematic changes.
Please test the git master tip version from the SF git server yourself
now, and if it turns out you actually need one or more of your 3
dropped changes, we can add another commit to that effect with an
explanation why that further change is necessary. And if you have any
other desired change you would like to make to PLplot, please contact
me again directly (or ideally on the plplot-devel mailing list for the
reason given above).
Best wishes,
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.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] Possible Windows development agendas for the next 6 months
On 2019-06-12 12:27-0700 Alan W. Irwin wrote: On 2019-06-11 17:29-0400 Jim Dishaw wrote: I think the earliest version of windows we should support is win7. Keeping XP support will be a challenge. According to <https://en.wikipedia.org/wiki/Windows_XP>, XP was introduced in 2001, Microsoft quit fundamental support for it in 2014, and the percentage of Windows users who are still using it has dropped to ~2 per cent as of a few months ago. So yes, I am fine with us dropping XP support as well. I have just discovered my answer above did not go far enough because I forgot XP was followed by Vista which was followed by Windows 7. From <https://en.wikipedia.org/wiki/Windows_Vista> Vista share of the Windows market is down to 0.5% while from <https://en.wikipedia.org/wiki/Windows_7> the Windows 7 share is still at 33% with both numbers sampled just a few months ago. So I agree we should drop support for both XP AND Vista now so that the earliest version we should support is Windows 7. 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.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] Possible Windows development agendas for the next 6 months
On 2019-06-11 17:29-0400 Jim Dishaw wrote: I found this in my spam--sorry for the delay and sorry for too posting. I'll take a look at the list and work a plan of action. My quick read is that it should be doable. I think the earliest version of windows we should support is win7. Keeping XP support will be a challenge. Hi Jim: I hope you can figure out a way to tune up your spam filters so PLplot traffic is not interfered with. The spam filter I use is called [SpamBayes](http://spambayes.sourceforge.net), and it works well for me. In any case, I am glad you reviewed your spam folder and as a result we are now back in e-mail contact again. According to <https://en.wikipedia.org/wiki/Windows_XP>, XP was introduced in 2001, Microsoft quit fundamental support for it in 2014, and the percentage of Windows users who are still using it has dropped to ~2 per cent as of a few months ago. So yes, I am fine with us dropping XP support as well. @Jim: I am glad to hear you think this agenda is doable for you during this release cycle (especially when not worrying about XP support). 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.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
[Plplot-devel] Possible Windows development agendas for the next 6 months
hat at <https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-plplot> to help you further. However, if you just look at the PKGBUILD file there you should notice some problematic configuration issues (relying on the gd library and associated png and jpeg device drivers that have been deprecated for a very long time, and dropping (!) the high-quality qt device driver that is working so well for Arjen). So once you are familiar with building PLplot on MSYS2, you should be able to give Alex (the primary MSYS2 developer and also the author of the PLplot package for that platform) some good advice (through patches to that PKGBUILD file and testing the effect of those changes on the plplot binary package results) about how to substantially improve that PLplot package. @Jim: Here are the priorities I believe you should have in reverse priority order. Of course, if you think these priorities should be reordered or there are more important ones that I forgot, please let me know. 1. Phil has already told me he is willing to give MSYS2 a try so I hope you are in as well during this release cycle. See topic 2. in my remarks to him. 2. Deal with <https://sourceforge.net/p/plplot/bugs/195/>. My feeling is there is a reasonable chance you can replicate this guy's Cygwin issue on MSYS2 (since MSYS2 is a fork of Cygwin), and if that proves to be the case, that should provide some essential help to your effort to fix this bug. 3. If the wingdi device is anything like my memory of the wingcc device results long ago when I was testing that device on Wine, it has problems with the -np option and example 17. See topic 3 in my remarks to Phil about a similar issue for the wxwidgets device and the MSYS2 interactive device comparisons he can use to discover the correct behaviour of all interactive devices. And if you verify this bug for wingdi on MSYS2, it would be great if you could also come up with a fix for it. But I would not bother with fixing wingcc in this regard since I hope we will be able to retire that device driver soon (see below). 4. Enhance the wingdi device so it can properly handle UTF-8 text? This is the obvious and long-discussed next step for this device that would allow us to permanently retire wingcc so I hope you have some time during this release cycle to finish off this topic. @ Arjen, Phil, and Jim: Don't take what I said too seriously above because my Windows experience is from quite a while ago on the Wine platform with MinGW/MSYS (as opposed to the modern alternative to that ancient platform, MinGW-w64/MSYS2). But I do hope to stir up some discussion from you three PLplot developers with access to Windows. So I am looking forward to your individual replies to my remarks above. 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.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
[Plplot-devel] My recent PLplot support-request triage
For the information of the PLplot developers, I have recently gone through all the open/pending support requests at <https://sourceforge.net/p/plplot/support-requests/> and changed the status to "closed" with a comment of "too old" for all the support requests that were more than two years old since I don't think any of those (two-years old or more!) support requests can possibly be relevant to modern PLplot. That triage left just 4 open/pending support requests where one of them was an obvious bug report which I moved to our bug reports, and the 3 remaining ones I have classified as pending since either the discussion of the support topic appears to be over, or we are waiting for more feedback from the originator of the support request. 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.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
[Plplot-devel] Current status of the PLplot-5.15.0 release process
Here is the current status of the PLplot-5.15.0 release process. N.B. the freeze (with a few well-understood exceptions) on pushes of source code or build system changes will continue until this release process is completed. My apologies that some personal distractions delayed my further work on this release until today. However, today I did make some substantial progress which was to finalize (commit plplot-5.14.0-47-g4baf2b49a) the release notes for 5.15.0 based on my review of all the commit messages during this release cycle. All the rest of the steps in the release process should be largely mechanical, and you should be able to follow those on git as I do them. Therefore, I hope to release PLplot-5.15.0 in another day or two without further status reports like this one concerning how close I am to reaching 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 __ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Current status of the PLplot-5.15.0 release process
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 __ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Testing of the next PLplot release
On 2019-05-22 07:07- 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 __ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Testing of the next PLplot release
On 2019-05-21 18:21- 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 __ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Testing of the next PLplot release
On 2019-05-21 07:05- 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 __ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] git blog
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 __ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] swig 4.0.0 issues
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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] A complete rewrite of the build system INSTALL_RPATH configuration logic has now been finished
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). ___
[Plplot-devel] CMake minimum version bump and removing cmake/modules/FindwxWidgets.cmake
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 __ git_build.sh Description: Bash script to build a local version of CMake ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Help needed for plplot runtime tests
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
Re: [Plplot-devel] Help needed for plplot runtime tests
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 L
[Plplot-devel] findwxwidgets.cmake module
On 2019-01-31 17:37- 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 // form to :/
+ # 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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] qt_example memory management issues (SOLVED!)
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 __ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Testing of latest qt pushes requested
On 2018-12-31 16:05- 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 __ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] qt_example memory management issues
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
__
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] qt_example memory management issues
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] qt_example memory management issues
On 2018-12-31 16:05- 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
__
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Testing of latest qt pushes requested
Hi António: I have just pushed your change and my subsequent followup to make the initQtApp and close QtApp code easier to read and more robust. Please look carefully at the code changes in my last commit (plplot-5.14.0-15-g790754f35) and also test those changes to make sure they work fine for your use case (qt applications using qt devices). Unless you find something that needs changing with that last commit, that should complete our joint qt development work until you have a chance to work on PLplot again in a couple of months. However, ideally it would be good to not have to wait that long for the resolution of the occasional segfaults on exit for qt_example that I encountered when comprehensive testing 5.14.0. So now that I understand our qt device driver and binding a bit better, I am going to look at that issue again. And if I can find a simple fix, I will commit that, but if I still cannot find such a simple fix (as happened during the 5.14.0 release because I am still in the early stages of learning C++ and Qt), I will leave that (more complex?) fix to you in a couple of months. 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] qt_example intermittent segfaults on exit
On 2018-12-29 21:45- António Rodrigues Tomé wrote: Hi Alan I just tried another thing as I was not feel comfortable by the fact that apparently QtExtWidget is setup in the main window but free in the driver however just found out that in fact the plD_tidy_extqt( PLStream * pls ) is never reached. Hi António: That is an interesting result. Normally, the way plD_tidy_extqt is called is via plend1 which in turn is called by plend. But there is no mention of either of those in qt_example.cpp or qt_PlotWindow.cpp. So based on a very quick look (so this is just slightly informed speculation), I think part of the solution is to modify the PlotWindow destructor to call plend to properly terminate PLplot. In addition you have to figure out a way to delete win instance of PlotWindow within qt_example.cpp so that the PlotWindow destructor is actually called at the correct time. But maybe if you completely rewrite extqt as you suggested, proper termination will not be so difficult as this? Anyhow, I leave the solution of the qt_example termination issues we have been discussing completely to you. [...]In two months time I will look careful into this. [...] Good! I look forward to whatever solution you come up with then. 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Dropping the closeQtapp call
On 2018-12-29 11:56- António Rodrigues Tomé wrote: On Sat, Dec 29, 2018 at 11:20 AM Alan W. Irwin wrote: On 2018-12-29 09:17- António Rodrigues Tomé wrote: On Sat, Dec 29, 2018 at 2:28 AM Alan W. Irwin < alan.w.irwin1...@gmail.com> I'm puzzled my changes do not in any way affect the extqt case. the ext-qt also should never call closeQtapp() but in fact it calls it but it is a flaw in code that does do not arm because as you said appCounter becomes -1 and nothing is done besides the mutex instruction that i'm still uneasy with them, otherwise it would kill the program. Actually, this is the source of my unease with this code as well. Therefore, I plan to drop that closeQtapp call from plD_tidy_extqt not only to make the code cleaner but also because the current code would fail if some external qt application tried to use the combination of extqt with, say, pngqt (e.g., to make a permanent PNG file corresponding to what was displayed on the screen using extqt). just put the mutex instruction in plD_tidy_extqt; Sorry, António, but I think this comment about the mutex means you misunderstood my comments above. So to explain them further, the current situation is plD_init_extqt (rightly because all uses of extqt create their own qApp) does not call initQtApp. Therefore, from the perspective of code cleanliness it makes sense to drop the closeQtapp call from plD_tidy_extqt. Also, for the case where some external qt application attempted to use both extqt and some other qt device, appCounter ends up as 0 rather than -1 causing an incorrect delete of qApp for that case. So to avoid this potential error it also makes sense to drop the closeQtapp call from plD_tidy_extqt. Further to your remark about the mutex above (and your much earlier remark that you didn't quite understand the purpose of that mutex), I am pretty sure I understand its use in the code now. It does give thread safety for multiple use of the static appCounter variable, i.e., if two different threads were using qt devices and looking at and modifying appCounter simultaneously. Of course, PLplot has many instances where it is not (yet) thread safe, but Alban didn't want to add to them with appCounter. So this "due diligence" on his part is the reason that QMutexLocker locker( ::mutex ); is called in the routines that read or write appCounter, namely initQtApp and closeQtapp. However, calling it in plD_tidy_extqt would have no purpose since that routine doesn't access appCounter. Anyhow, I am pretty confident of my analysis so I still plan to push the above change later today. However, if I missed something let me know, and if your reply happens after the push because of time zone differences between us, we can make further corrections after that push as well. The original author never considered the need of any of the others qt drivers from a qt application what for me is amazing... Actually, Alban, was one of those guys that understood Qt and C++ completely. So back in 2009 he was the right choice from the QSAS development team to create all the Qt components of PLplot for us. And he amazed us all by doing that 3 times or so (with an initial write and a couple of complete rewrites in response to our questions) in the last month or so he worked for QSAS. So I think he did an amazingly good job for such quick work. However, there are obviously still a few problems left in his code, and I am glad you are finding those and fixing them. For example, your font fix for our qt devices finally made our qt devices essentially the same high quality as our cairo devices which previously I considered to be our best set of devices. And our qt binding has a lot of potential as well (as you have discovered with your own qt applications). 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] qt_example intermittent segfaults on exit
On 2018-12-29 16:50- António Rodrigues Tomé wrote: Hi Alan it is easy to put this in a more standard qt way where plot win is not defined as a pointer and put win.show replacing // a.setActiveWindow( win ); // win->setVisible( true ); before the return a.exec() the fun thing is that in this case the program always crashes when one closes the window. It crashes when the destructor of PlotWindow::~PlotWindow() is called. it crashes there even if you empty the destructor. so I would conclude something very wrong with the extqt driver. My experience was the same. Any change I attempted caused reliable segfaults rather than rare segfaults. So I agree there is some flaw in the current extqt device. I'll promise to have a look, and probably completely replace it by something different as I do not like it, unlike the others that are nice. That would be great when you have time for this. 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] qt_example intermittent segfaults on exit
On 2018-12-29 09:17- António Rodrigues Tomé wrote: Unfortunately I was not able to make qt-example seg fault in my system so could not found out what was the problem. I could only trigger the segfaults in a busy environment, i.e., the interactive part of comprehensive testing with all sorts of other interactive tests going at the same time. So I am not surprised you found it difficult to reproduce this issue. However, if you try a valgrind run on qt_example, you should find like I did that there is a memory leak associated with win because the combination QApplication a( argc, argv ); PlotWindow * win = new PlotWindow( Argc, Argv ); a.setActiveWindow( win ); win->setVisible( true ); [...] return a.exec(); leaves some memory associated with win undeleted. Note, cleanly deleting win is difficult (or at least I have had no success trying to do that without creating more segfaults) because of win's use by "a" above and the necessity (at least according to Qapplication documentation) that the exec method call be the last thing done in a main routine. Anyhow, if you can find some way to modify the above code so there is no memory leak associated with win, then that might solve the intermittent segfault on exit issue shown by qt_example. 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 __ ______ 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Dropping the closeQtapp call
On 2018-12-29 09:17- António Rodrigues Tomé wrote: On Sat, Dec 29, 2018 at 2:28 AM Alan W. Irwin I'm puzzled my changes do not in any way affect the extqt case. the ext-qt also should never call closeQtapp() but in fact it calls it but it is a flaw in code that does do not arm because as you said appCounter becomes -1 and nothing is done besides the mutex instruction that i'm still uneasy with them, otherwise it would kill the program. Actually, this is the source of my unease with this code as well. Therefore, I plan to drop that closeQtapp call from plD_tidy_extqt not only to make the code cleaner but also because the current code would fail if some external qt application tried to use the combination of extqt with, say, pngqt (e.g., to make a permanent PNG file corresponding to what was displayed on the screen using extqt). So unless you have some second thoughts about removal of the closeQtapp call, I plan to push that change later today after your current appCounter fix is pushed. 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Change to appCounter logic within qt.cpp
Hi António: I am still slowing learning about both Qt and C++ so I was happy to hear from you my analysis of the appCounter logic was correct. I plan to push your commit later today. __ 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Change to appCounter logic within qt.cpp
On 2018-12-27 16:30- António Rodrigues Tomé wrote: As for the another important change to allow all qt drivers to be called from within a qt application I think your worries are not justifiable as the function I changed is not called when an extqt is used. my change if(appCounter == 1 && qApp != NULL) ++appCounter; //This was added to allow qt drivers to be called from within a qt program. is in function initQtApp that is called by plD_init_rasterqt plD_init_svgqt plD_init_epspdfqt plD_init_qtwidget plD_init_memqt is not called by plD_init_extqt as this driver is, as I understand to be called from within a qt application so does not try to open another qApp. Hi António: I have changed the subject line to something more specific to this different topic. I have been trying to understand why this change had to be made, and here is what I have discovered so far by digging my way through the qt.cpp code. All qt devices need a qApp in order to work and the purpose of initQtApp (where I have confirmed your statement above that it is called from all plD_init* routines *other than plD_init_extqt* that are implemented in drivers/qt.cpp) is to create argv memory and an associated qApp if a qApp doesn't exist already (either created by a previous call to initQtApp or in external qt code such as your own external qt application that uses ordinary (non-extqt) qt devices and qt_example (which does not use qt devices other than extqt). And the purpose of closeQtApp (which is called from all the plD_tidy_* routines implemented in drivers/qt.cpp) is to delete that qApp and associated (argv) memory that was initially created in initQtApp. And the purpose of appCounter is to make sure only one creation and only one deletion occurs. Assuming that analysis is correct, I now understand how your external qt application failed before your change because your application had created a new (or automatic) instance of qApp already so initQtApp called indirectly by your use of an ordinary qt device would increment appCounter from 0 to 1 and return (since qApp was already non-NULL) while when you were done with that ordinary qt device, PLplot would tidy up for that device and call closeQtApp which decremented appCounter to 0 and therefore would then proceed to attempt to delete the qApp *created by your external qt application* in error. So your fix for that error was to initialize appCounter to 2 within initQtApp (if qApp non-NULL and appCounter was 1) so that incorrect closeQtApp deletion never occurs for this situation. It also follows from the above analysis why extqt (used by qt_example) rightly does not call initQtApp. And when PLplot tidys up extqt, closeQtApp gets called with appCounter equal to its static initial value of 0, that routine then decrements that counter to -1, and therefore an incorrect cleanup of the qApp from qt_example is not done (as it should be). So my gut feeling is this code and also your modification of it is pretty fragile, but it does appear to work (at least according to the above mental model of what is going on), and I have nothing better to offer. However, the reason I am concerned with what I perceive as fragility in this code is I want to be really careful about creating and destroying qApp since qt_example currently has memory management issues that make it segfault *sometimes* on exit. And I presume those are due to some screwup in the interaction between specific cleanups (possibly the one we are discussing above) and automatic ones. So if you can think of a cleaner way (perhaps recording the actual qApp value that is created in initQtApp that should be destroyed later) to destroy the qApp that is specifically created by initQtApp, that would be great. Please confirm my above analysis is correct or let me know where I went wrong. If it turns out my analysis is correct, but you still do not share my concerns about the robustness of the code in its present state (i.e., with your change), then I will add information to your commit message based on the above analysis and go ahead and push your change. 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt5 support, strange driver output
Hi António: I have just pushed your (modified) commit plplot-5.14.0-12-gaa0dd85fc. (By the way, "plplot-5.14.0-12-gaa0dd85fc" is the result of "git-describe aa0dd85fc" which is a convenient way to show aa0dd85fc is the 12th commit after plplot-5.14.0.) Congratulations on this result! Your code changes were small, but they were a significant improvement to our qt device driver which is much appreciated. Assuming you have a continued interest in PLplot development I would advise you to login to SF and click on the icon at <https://sourceforge.net/p/plplot/plplot/ci/master/tree/> to subscribe you to our git feed. That will give you convenient e-mail notification of each of our future git changes. Of course, that future notification process will not notify you of the present change so to find out details of that (i.e., how I adapted what you said about your tests today as well as earlier for the commit message) click on the history link at <https://sourceforge.net/p/plplot/plplot/ci/master/tree/>. However, it is hard to remember to do that every day so e-mail notification of all git changes as I suggested above is a much better long-term choice. 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt5 support, strange driver output
On 2018-12-27 08:58- António Rodrigues Tomé wrote:
[...]
Hi Alan.
Let start by saying that my English sucks. I've never learn it when I was
young only latter on on life I've learned some english reading math and
physics text books.
Hi António:
Actually, I admire your ability to pick up completely understandable
written English later on in life since even as a young man I had
trouble with attempting to learn even one non-English language, and my
own written English is the result of hard work and lots of re-editing
even the most trivial e-mails and not something that is easy for me.
Anyhow, your explanation about what is going on with Qt (including
your additional P.S. post) gave me enough clues to find further
documentation and articles. So using "git commit --amend" simply to
modify the commit message for your commit according to that new
knowledge, here is how that message reads now:
-8<---
software@merlin> git log --name-status -1 |cat -
commit 8612dc30bdd6aa5bf3026c5b130206efb5df895c
Author: António R. Tomé
Date: Mon Dec 24 14:58:00 2018 +
Fix background transparency bug in the qt raster devices
We found experimentally that QtRasterDevice::QtRasterDevice required
the following two changes to solve a long-standing bug where the alpha
value of the background was being completely ignored by qt raster
devices (so semi-transparent backgrounds were being rendered as
completely opaque):
1. Change the QImage format of results for raster devices from
QImage::Format_RGB32 to QImage::Format_ARGB32. This change (or
possibly changing to the QImage::Format_ARGB32_Premultiplied format in
the future for efficiency reasons) is required because the
QImage::Format_RGB32 documentation at
<http://doc.qt.io/qt-5/qimage.html#Format-enum> states "The image is
stored using a 32-bit RGB format (0xffRRGGBB)" i.e., the alpha channel
is completely fixed at opaque. So this previously adopted opaque
format was not correct.
2. Insert a transparent fill canvas (with color Qt::transparent which
is transparent black according to
<http://doc.qt.io/qt-5/qt.html#GlobalColor-enum> as the first layer of
the image. Transparent black is essential since the normal "over"
compositing rule (see the compositing formula in
<https://en.wikipedia.org/wiki/Alpha_compositing> which composites the
semi-transparent PLplot background on top of that transparent black
canvas gives a result which is exactly the PLplot background, with
unchanged ARGB values.
Tested by: António R. Tomé on Linux
(openSUSE leap 15.0) by ???
Tested by: Alan W. Irwin on Linux
(Debian Testing) by building the x30c and qt targets and running
valgrind examples/c/x30c -dev pngqt -o test3_qt.png -fam -bg 00F_0.3
The valgrind report showed "ERROR SUMMARY: 0 errors from 0 contexts
(suppressed: 64975 from 1)" which is a good memory management report
aside from the memory leaks which were also mentioned (which should be
looked at in detail later to make sure those are due to Qt library
issues rather than qt device driver issues).
When test3_qt.png was viewed with either the "display" or "pqiv" image
viewer applications the results showed the above blue background with
30 per cent opacity (or 70 per cent transparency) composited with a
black and white checkerboard canvas. Those canvases were rendered by
the two different applications (as proved by the different sized
squares in the two cases) as the traditional means of marking a
semitransparent background. Previous to this fix, the checkerboards
were not present indicating an incorrect opaque blue background.
M bindings/qt_gui/plqt.cpp
-8<---
So assuming you like what I have written above and also just as soon
as you let me know how you tested this commit (see the ??? above in
this commit message that still needs to be filled in by you), I will
push it.
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 mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt5 support, strange driver output
ckgroundColor( int r, int g, int b, double alpha ) if ( !m_painterP->isActive() ) return; + QBrush brush( QColor( r, g, b, (int) ( alpha * 255 ) ) ); m_painterP->fillRect( 0, 0, width(), height(), brush ); } So far so good. Now I test example 30 with a semi-transparent background after rebuilding the qt target to incorporate the above (white-space modified) change. examples/c/x30c -dev pngqt -o test2_qt.png -fam -bg 00F0.3 Unfortunately, display -alpha activate png:test2_qt.png.1 (where "display" is an imagemagick application) renders an opaque blue background in this case rather than a checkerboard with our semi-transparent blue background superimposed. That is, apparently imagemagick has not figured out that test2_qt.png.1 has a semi-transparent blue background. For what it is worth I attach test2_qt.png.1 so you can compare it with your own. Could you send me the equivalent result you get there for the exact experiment above? Also, please let me know what application you use (assuming it is not "display") to look at your own test2_qt.png.1 file generated as above. 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 __ test2_qt.png.1 Description: Alan's results for fixed case ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt5 support, strange driver output
On 2018-12-26 13:00-0800 Alan W. Irwin wrote: [...] Here are two alternative suggestions: "Fix background transparency in the raster qt Drivers" or "Fix transparency in the raster qt Drivers" Let me know which of these you prefer. P.S. That should have been "raster qt devices" rather than raster qt Drivers" This change is consistent with our normal terminology where we refer to the code in, e.g., drivers/qt.cpp that implements the qt device driver, but we refer to the individual devices that are implemented by that code as the pngqt device, etc. Note your two separate commits are completely independent of each other so I suggest you reply first to my questions concerning 0001-correction-in-QtRasterDevice-QtRasterDevice-to-fix-a.patch and wait until that commit is pushed by me before answering my further questions concerning 0002-correction-in-initQtApp-to-allow-qt-drivers-to-be-ca.patch Finally, I really appreciate your successful effort to learn enough about git so you can send us your git commits in the convenient "git format-patch" form. 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt5 support, strange driver output
On 2018-12-25 23:06- António Rodrigues Tomé wrote: Hi Alain sorry I haven carefully read up to the end all the README.developers file here the patch Hi António: Thanks for those commits. My apologies in advance for the number of questions I have for you in this reply, but I would appreciate you answering all of them to help improve my overall knowledge concerning the Qt-related components of PLplot and also to improve the commit messages associated with your two commits. One issue I immediately noticed with your commits is both have only a one-line commit message, and those should be expanded with a following paragraph with details and two further Tested by: paragraphs. I can do the necessary editing of your commit messages here to make those changes, but in order to do that I will need additional information from you as detailed below for your two different commits. I. 0001-correction-in-QtRasterDevice-QtRasterDevice-to-fix-a.patch Your current summary line, "correction in QtRasterDevice::QtRasterDevice to fix a alpha problem in the raster qt Drivers" is too repetitive and also too vague. Here are two alternative suggestions: "Fix background transparency in the raster qt Drivers" or "Fix transparency in the raster qt Drivers" Let me know which of these you prefer. (Note I do plan to mention QtRasterDevice::QtRasterDevice in the explanatory paragraph which is why I dropped that phrase from the summary line.) The reason I used the "background" qualifier for the first alternative is I can find no problem with the non-background transparency in these devices. For example, without your fix I attach test_qt.png.1 (the first page of the example) generated with examples/c/x30c -dev pngqt -o test_qt.png -fam where that result clearly shows the effects of transparency for the various semi-transparent blocks displayed by that example and also agrees with the first page displayed at <http://plplot.org/examples.php?demo=30> which was generated with -dev pngcairo. However, if your result there (without your fix) on openSUSE is not the same, then this may be another case of openSUSE exposing bugs in the PLplot qt device driver better than Debian (i.e., Debian Qt fixups and workarounds may be more extensive than those from openSUSE). The reason I am asking about this in detail is one of your changes involved moving from QImage::Format_RGB32 ==> QImage::Format_ARGB32. From the description at <http://doc.qt.io/qt-5/qimage.html#Format-enum> it appears that is absolutely the right thing to do (unless you decide later to move to QImage::Format_ARGB32_Premultiplied for efficiency reasons, but that is obviously a separate issue). But from that description it seems our unfixed RGB32 format should not be able to produce the semitransparent results we see in the attached plot. But maybe Debian (and openSUSE?) works around that by automatically switching from RGB32 to ARGB32 if alpha information is provided? Your response to these questions and comments will help determine whether I drop "background" from the summary line and greatly improve the explanatory paragraph I need to write. Also, can you explain why you had to add fill(Qt::transparent); ? Does that mean in the unfixed version there was no background fill at all for these devices so Qt was falling back to some opaque background? I haven't tested this commit yet, but once I do that I plan to add the following "Tested by" paragraph. Tested by: Alan W. Irwin on Linux (Debian Testing) . Could you give me those test details for yourself that I could add to a paragraph started by Tested by: António Rodrigues Tomé on Linux (openSUSE version number?) ? II. 0002-correction-in-initQtApp-to-allow-qt-drivers-to-be-ca.patch Do you agree with shortening your summary line from "correction in initQtApp to allow qt drivers to be called from a qt program" ==> Allow qt devices to be called from a qt program with initQtApp mentioned in the explanatory paragraph? That paragraph does not have to be too long, but can you explain to me why you need to increment appCounter one additional time? Is the problem that the devices are decrementing that somehow when your application is finished with them? If so, wouldn't a better solution be to specifically increment appCounter in each of the qt devices? The reason I am concerned about these appCounter details is I am pretty sure your current fix will add a memory leak for non-device Qt applications such as examples/c++/qt_example.cpp. That example already has a memory leak due to PlotWindow * win = new PlotWindow( Argc, Argv ); with no corresponding xwin delete, but when I attempted to fix that recently by deleting win that did not work because some other destructor currently destroys part of it (as far as I can tell from my limited Qt/C++ knowledge). Anyhow, I do not want to make the already bad
Re: [Plplot-devel] Qt5 support, strange driver output
On 2018-12-25 17:54- António Rodrigues Tomé wrote: Hi alan I do not pretend to understand everything you are asking for. But i think the changes I purpose completely solve the alpha problem in qt raster drivers. 1) I send you three files of the same plot with a yellow background with alpha=1, alpha=0.5, Alpha=0 (full background transparency). then I upload them to a template of the libreoffice impress just to ilustrate the effect. Hi António: Merry Christmas! Those illustrations do look like your changes have solved the transparency issue for at least the qt raster devices. For example, that checkerboard pattern is a traditional indication for non-compositing desktops that you have had semi-transparency success, indicating in better compositing environments (like your pdf example) you will actually show the appropriate amount of semi-transparency. In my own case, the ImageMagick "display" application for semi-transparent images displays those with a checkerboard background pattern to indicate a semi-transparent background was detected. I am not seeing that pattern currently for qt devices, but it appears from your own results there is a good chance your change will fix that. 2) I think to commit these changes by git someone must give me permition in the plplot git repository. For now, the "git commit" command should be used to commit your changes to your own local topic branch. Last I heard from you on that issue it appeared all you needed to do was to execute "git add" first. Was that a success? If so, the current status should be you have two separate commits on your local topic branch (one for your changes to allow use of qt devices from a QT application, and the other the above transparency changes), and the next question is how to communicate those git commits to us for evaluation. That is done with the git format-patch command as documented in README.developers. Once we have your commits in that format, we will likely test them and amend them (e.g., by adding additional "Tested by:" stanzas to the your commit message). And assuming those tests are a success we will then push your amended commit to the master branch of our SF git server with the normal git credit to you for your (amended) git commits. With regard to the question of pushing your commits directly yourself, that privilege is reserved to core PLplot developers. And you become one of those by showing sustained interest using the above git format-patch method of getting your development work (eventually) pushed. That said, we are always looking for future core PLplot developers and especially someone with Qt expertise who has a sustained interest! So let's see how it goes with the above git format-patch approach. 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt5 support, strange driver output
On 2018-12-23 10:14- António Rodrigues Tomé wrote: Just an update. qt drivers do not behave well with alfa values. [...] I'll try to upload this changes using git as I cannot find any other problem with qt drivers at least for the use I make of them. (well memqt does not work quite well but neither did memcairo) Make sure you split your changes into separate commits with appropriate commit message. Will the transparency change you refer to above give us a nice semi-transparent background (e.g., with the -bg 000_0.1 command-line option to give a black background with alpha=0.1) with all qt devices? I see lots of cool semi-transparent desktop effects on my KDE desktop, where you can view one desktop through another. I would also like to see similar effects possible with PLplot where you, for example, can view the command-line that produced a plot through the plot, if you use a semi-transparent background. Have a nice Christmas You too. 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt5 support, strange driver output
On 2018-12-20 13:21-0800 Alan W. Irwin wrote: On 2018-12-20 18:56- António Rodrigues Tomé wrote: Hi Alan I do not completely understand the need of using a mutex in the qt driver however without any change in the actual driver approach it is easy to allow the driver to work well within a qt app and also in any other c or c++ program if in the file qt.cpp function bool initQtApp( bool isGUI ) we add after the ++appCounter; line (line 90) the instruction if(appCounter == 1 && qApp != NULL) ++appCounter; this will prevent the call delete qApp; when one closes the driver within a qt application, that would crash teh application, and it does not conflict with the actual behavior of the qt driver it onnly takes account for the fact that there is a qApp that was not started by the driver. Hi António: [...] So from the point of view of a non-expert for this code, I would suggest if you think the mutex is no longer needed because of your change, then go ahead an remove it to see whether that combined change passes all tests you care to make including ideally running the comprehensive test script as documented in doc/wiki_source/Testing_PLplot. With regard to the mutex, I have included what Alban initially said about it way back when. From his comment my guess is the mutex is a necessity to keep the Qt components of PLplot thread-safe because the PLplot core is not thread safe (although fixing that bad state of affairs is on our long-term agenda). And subsequently there was a whole lot of plplot-devel traffic about properly setting up that mutex with no question from anyone about its necessity. Anyhow, forget my naive idea above that you might want to drop the mutex. Alan -- Forwarded message -- Date: Fri, 20 Mar 2009 17:00:49 + From: Alban Rochel To: Alan W. Irwin Subject: Qt driver update Alan, I've made a break from QSAS for an hour and I've made a couple of improvements to the Qt driver. - I've introduced a mutex to make some parts thread-safe (I haven't checked if all the driver was). - Someone noticed that when 2 qtwidgets were running on 2 streams, closing them didn't close the driver properly. This should be fixed by now. When qApp is run, all the qtwidgets created before are tagged as being run, and so the driver shouldn't try to run one qApp per widget. Cheers, Alban ______ 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 mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
