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
[Plplot-devel] git blog
On 2018-12-22 17:46- António Rodrigues Tomé wrote: Hi I must confess that I'm completely unable to work with git. As git is a widely used tool it is certainly my problem. After many hours just to be able to perform first instructions in develop file specially because I tried to read a git instruction to do a new branch but always get the info not a git repository. Only after many hours I conclude that was my local folder that was not a git and not the remote plplot site. so I made a clone git clone https://git.code.sf.net/p/plplot/plplot SourceforgePlplot ~/SourceforgePlplot> git checkout -b QtIssues Switched to a new branch 'QtIssues' changed the file qt.cpp git commit On branch QtIssues Changes not staged for commit: modified: drivers/qt.cpp no changes added to commit no clue what to do next. Hi António: I like to use the subject line "git blog" for git questions. So I have changed to that. The short answer to your question is use "git status" to find out what is possible to do with your files under git. In this case you want to stage your changed files for commit so use "git add" to do that before you execute "git commit". To give someone who is just getting started with git some good background, I recommend reading the the first chapter of <https://git-scm.com/book/en/v2> in its entirety. In particular, <https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository> answers your question above with more background than I have given. 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
Re: [Plplot-devel] Qt5 support, strange driver output
On 2018-12-22 17:46- António Rodrigues Tomé wrote: Hi I must confess that I'm completely unable to work with git. As git is a widely used tool it is certainly my problem. After many hours just to be able to perform first instructions in develop file specially because I tried to read a git instruction to do a new branch but always get the info not a git repository. Only after many hours I conclude that was my local folder that was not a git and not the remote plplot site. so I made a clone git clone https://git.code.sf.net/p/plplot/plplot SourceforgePlplot ~/SourceforgePlplot> git checkout -b QtIssues Switched to a new branch 'QtIssues' changed the file qt.cpp git commit On branch QtIssues Changes not staged for commit: modified: drivers/qt.cpp no changes added to commit no clue what to do next. Hi António: I like to use the subject line "git blog" for git questions. So I have changed to that. The short answer to your question is use "git status" to find out what is possible to do with your files under git. In this case you want to stage your changed files for commit so use "git add" to do that before you execute "git commit". To give someone who is just getting started with git some good background, I recommend reading the the first chapter of <https://git-scm.com/book/en/v2> in its entirety. In particular, <https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository> answers your question above with more background than I have given. 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 22:30- António Rodrigues Tomé wrote: Hi Alan I've never used git (I'm still a svn user) but I can give it a try. Hi António: Thanks for your willingness to try git to make it easier to communicate your suggested changes to us. Everything you should need to know about git from the PLplot development perspective is documented in README.developers, but if you don't understand something there, don't hesitate to ask your further git questions here. 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 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: For your information all our Qt-related code got contributed by Alban Rochel from the QSAS group back in 2009. And Alban move on to other work soon after so no current PLplot developer completely understands that code. This problem is made worse in my own case because my C++ and Qt skills are not that great. Also note that my recent tests of qt_example and pyqt5_example for the Qt5 case have not gone well with qt_example segfaulting on exit on one occasion and pyqt5_example hanging on exit on one occasion. Despite these issues, the Qt-related components generally produce extremely high-quality results so any help you can give us with this code to make it more reliable would be much appreciated subject to the constraint that comprehensive testing of your changes has to work as well as my previous comprehensive tests. 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. Also, descriptions of code changes (as you attempted to do above) are not really the best way to present your suggested changes to us. So instead, I suggest you follow the "git format-patch" cookbook in README.developers in order to do that. And don't hesitate to ask here if you have any trouble following that specific procedure or any other git advice we give 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.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] Help needed for plplot runtime tests
On 2018-11-15 01:10-0800 Alan W. Irwin wrote: [...] I need to implement the following two upstream upgrades: 1. I need to factor the exported target files, e.g., the two export_plplot* files mentioned above. Such factoring had already been highly recommended to me by CMake gurus, and I think it should be entirely straightforward. [...] 2. Currently the installed examples generally just check if a given component has been configured in the core build, by, e.g., checking ENABLE_cxx. But with some of those configured components potentially missing because a user did not install all plplot binary packages such a check is not correct and needs to be replaced by a test for the existence of the exported target, e.g., PLPLOT::plplotcxx. These sorts of changes should also be straightforward. To Ole and Orion: Here is the current status of these proposed upstream changes. As of commit plplot-5.14.0-10-g66d68d93e I have implemented (and thoroughly tested) the first upgrade above. Because of this change, the list of export-related files (for my normal case of a fully loaded Debian Testing platform where I don't specify a build configuration) has now expanded to the following: export__Pltk_init-noconfig.cmake export__Pltk_init.cmake export__plplotc-noconfig.cmake export__plplotc.cmake export_cairo-noconfig.cmake export_cairo.cmake export_csirocsa-noconfig.cmake export_csirocsa.cmake export_csironn-noconfig.cmake export_csironn.cmake export_mem-noconfig.cmake export_mem.cmake export_ntk-noconfig.cmake export_ntk.cmake export_null-noconfig.cmake export_null.cmake export_pdf-noconfig.cmake export_pdf.cmake export_plfortrandemolib-noconfig.cmake export_plfortrandemolib.cmake export_plplot-noconfig.cmake export_plplot.cmake export_plplot_octave-noconfig.cmake export_plplot_octave.cmake export_plplot_pyqt5-noconfig.cmake export_plplot_pyqt5.cmake export_plplotada-noconfig.cmake export_plplotada.cmake export_plplotcxx-noconfig.cmake export_plplotcxx.cmake export_plplotdmd-noconfig.cmake export_plplotdmd.cmake export_plplotfortran-noconfig.cmake export_plplotfortran.cmake export_plplotluac-noconfig.cmake export_plplotluac.cmake export_plplotqt-noconfig.cmake export_plplotqt.cmake export_plplottcltk-noconfig.cmake export_plplottcltk.cmake export_plplottcltk_Main-noconfig.cmake export_plplottcltk_Main.cmake export_plplotwxwidgets-noconfig.cmake export_plplotwxwidgets.cmake export_plserver-noconfig.cmake export_plserver.cmake export_pltcl-noconfig.cmake export_pltcl.cmake export_pltek-noconfig.cmake export_pltek.cmake export_ps-noconfig.cmake export_ps.cmake export_psttf-noconfig.cmake export_psttf.cmake export_qsastime-noconfig.cmake export_qsastime.cmake export_qt-noconfig.cmake export_qt.cmake export_svg-noconfig.cmake export_svg.cmake export_tclmatrix-noconfig.cmake export_tclmatrix.cmake export_tk-noconfig.cmake export_tk.cmake export_tkwin-noconfig.cmake export_tkwin.cmake export_wxPLViewer-noconfig.cmake export_wxPLViewer.cmake export_wxwidgets-noconfig.cmake export_wxwidgets.cmake export_xfig-noconfig.cmake export_xfig.cmake export_xwin-noconfig.cmake export_xwin.cmake plplotConfig.cmake plplot_exports.cmake See the detailed commit message for plplot-5.14.0-10-g66d68d93e for the implications of this change for packagers. Once you have added the above export files to the correct binary packages following that advice, you should be able to configure the installed examples project with cmake (with no options) and run make -j$JOBS test_noninteractive without issues just like before (i.e., you will still be subject to the constraint that all binary packages for PLplot have to be installed in order for this to work). To finish off this topic, my next PLplot priority is to follow up with the second upstream change mentioned above which should remove the constraint that all binary packages for PLplot have to be installed in order to test both your binary PLplot packages that are installed, and your package containing the installed examples in the above way. 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. 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] git workflow plans for the proposed bug-fix plplot-5.14.1 release
Hi Phil: On 2018-12-18 00:33- Phil Rosenberg wrote: Sounds like a generally good plan to me. Good. The only issues might be picking what is a bug fix commit vs a non bug fix commit - I'm sure we are all guilty of finding a bug while changing code and not submitting it as a separate commit. But providing we all try to be good in that sense, I think a bug fixes release is a good idea. The other important issue is whether the bug is a regression or not. Regressions mean by definition that users of prior versions of PLplot are going to get a nasty surprise by the new version of PLplot. So avoidance of regressions is my motivation for asking for comprehensive testing on all platforms prior to each release, and anytime such a regression is turned up by such testing, I view it as release critical, i.e., the release should be held until a proper fix for the regression has been implemented. However, if a regression actually gets into a release despite our testing efforts, then that would be a large motivation to immediately issue a bug-fix release containing the fix for that regression. But I would rather not learn about the git steps needed for a bug-fix release under such time pressure, and the present bug fix has a wide impact for all our present or future qt device users. So I am going to use the present impactful bug fix as a good excuse to get educated on the git steps needed to create a bug-fix release. However, I will likely not be willing to do this again unless the bug fix is actually a fix for a regression. Instead, I would like to spend most of my PLplot effort on development and making sure that our regular releases (which normally include both bug fixes and new development) occur every 6 months or less. Due to a variety of excuses I haven't managed to do that recently, but I am planning on having a much better ordinary release outcome in the latter part of the first half of 2019. 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 workflow plans for the proposed bug-fix plplot-5.14.1 release
Can some git guru here review my proposed git workflow for the planned 5.14.1 release below? The reason I ask for that review is because I currently have no practical experience with some of the special git commands that will be needed. In fact, because of that lack of experience I previously did not create a bug-fix release in an earlier release cycle for PLplot (at least in its git era) when I likely should have! So this bug-fix release will be a long-overdue learning experience for me. That said, I am pretty sure from reading on-line material and a hint from one of our users what git steps I would have to take. Also note these proposed steps do not violate our (enforced) workflow rule that no merge commits other than fast-forwarded ones are allowed. Those git steps are as follows: * Create a local branch called 5.14.0-bugfix from the existing plplot-5.14.0 tag. * Cherry pick bug-fix commits such as plplot-5.14.0-8-gdb9d90d0b onto that branch. * Go through the usual release procedure while staying strictly on that branch which will add other commits to that branch such as the new (short) release notes and ChangeLog for that 5.14.1 release without ever merging those commits back to master. Which means none of this bugfix release work impacts on the ordinary development of the master branch. One of the last steps in that procedure would be to push the local tag that points to the tip of 5.14.0-bugfix (called plplot-5.14.1 in this case) to our SF git repository (again without changing the master branch). * From remarks in <https://stackoverflow.com/questions/9265278/what-happens-if-i-push-a-tag-for-a-commit-that-hasnt-been-pushed> it appears that pushing a tag pushes the associated commit and also pushes all ancestors of that commit that have not been pushed before. If that is correct, then all commits on my local branch called "5.14.0-bugfix" will end up accessible at SF but not organized as a formal branch there. That result is fine with me since it doesn't clutter the SF version with extra branch names, and the result is enough to allow anybody (after they use the "git refresh" command) to access the commit corresponding to the plplot-5.14.1 tag or any of that commit's ancestors. For example, if later on during the release cycle I decided to release another bug-fix release called 5.14.2, I could start that process by branching from the plplot-5.14.1 tag. Furthmore after pushing the plplot-5.14.1 tag I would likely delete the 5.14.0-bugfix local branch to be consistent with the SF repository; I would have no further use for that branch; and that branch deletion does not get rid of the plplot-5.14.1 tag, the associated commit or any ancestors of that commit; Of course, with this model of workflow for bug-fix releases, no attempt would ever be made to merge bug-fix branches back to master since that makes no sense in any case and would violate our (enforced) rebase work flow rule that there can be no merge commits that cannot be fast-forwarded. Again, comments on this plan from the git gurus here will be most welcome. 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-16 10:13- António Rodrigues Tomé wrote: Hi all I found no evidence of fontconfig not being working properly in my system. so I've made a small test instead of setting font family to null string I've set it to a bogus name. f.setFamily( "BOUGUSTRASHFAMILY" ); // no family name, forcing Qt to find an appropriate font by itself and in x01c example as there are four plots i edited the source to add theplfont(1); before plot 1, plfont(2); before plot 2, plfont(3); before plot 3, plfont(4); before plot 4, I also get erase the esc text sequence that put title always in Roman. The results are what one would expected. Hi António: I agree, that one-line change seems to have solved all qt device driver issues on your platform. So I tried the equivalent here, and it solves some less obvious Qt issues here for examples 23 and 24 that have been around for quite a while. So congratulations on finding a solution to a PLplot qt device driver bug that has apparently been around since the very first development of that device! I commited a small variation (I added commentary and I replaced your bogus family name because it was [barely] conceivable a valid font might adopt that family name) of your fix as of plplot-5.14.0-8-gdb9d90d0b. So please test that commit (by using git checkout plplot-5.14.0-8-gdb9d90d0b before building PLplot from the git version) to make sure it answers all your qt device needs (other than character size). @Everybody: This fix is pretty crucial for our qt device driver because it appears to fix all long-standing font problems (including character alignment for António) for that device driver. Therefore, I intend to release 5.14.1 with this fix and any other critical fixes that show up in the next few weeks. More about the git process I should use to create a bug-fix release (such as the proposed 5.14.1) in my next post. 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-16 00:07- António Rodrigues Tomé wrote:
Hi all
after trying a long time playing with cmake options trying to see if I
could get my qt5 plplot loading suitable f fonts I came to conclude that my
distribution in a way acts differently from Alan's.
I get very nice results if in the file plqt.cpp line 182
where is
f.setFamily(""); // no family name, forcing Qt to find an appropriate
font by itself
I replaced by
f.setFamily("Helvetica"); // no family name, forcing Qt to find an
appropriate font by itself
it seems in my system qt does not find an appropriate font by itsel. I
attach the very nice results obtained only by performed this small change.
Hi António:
The problem with this workaround is Helevetica is a Sans-Serif font so this
approach means you have
excluded serif and monospace possibilities for the PLplot qt device driver user.
Furthermore, how fonts are chosen by Qt is documented in
<http://doc.qt.io/qt-5/qfont.html#details>.
There is a lot of information there, but the relevant points for this
discussion are
---
enum QFont::StyleHint
Style hints are used by the font matching algorithm to find an appropriate
default family if a selected font family is not available.
ConstantValue Description
QFont::AnyStyle 5 leaves the font matching algorithm to choose the
family. This is the default.
QFont::SansSerifHelvetica the font matcher prefer sans serif
fonts.
QFont::Helvetica0 is a synonym for SansSerif.
QFont::SerifTimes the font matcher prefers serif fonts.
QFont::Times1 is a synonym for Serif.
QFont::TypeWriter Courier the font matcher prefers fixed pitch fonts.
QFont::Courier 2 a synonym for TypeWriter.
QFont::OldEnglish 3 the font matcher prefers decorative fonts.
QFont::Decorative OldEnglish is a synonym for OldEnglish.
QFont::Monospace7 the font matcher prefers fonts that map to the
CSS generic font-family 'monospace'.
QFont::Fantasy 8 the font matcher prefers fonts that map to the CSS
generic font-family 'fantasy'.
QFont::Cursive 6 the font matcher prefers fonts that map to the CSS
generic font-family 'cursive'.
QFont::System 4 the font matcher prefers system fonts.
---
---
The font matching algorithm works as follows:
1. The specified font family is searched for.
2. If not found, the styleHint() is used to select a replacement family.
3. Each replacement font family is searched for.
4. If none of these are found or there was no styleHint(), "helvetica" will be
searched for.
5. If "helvetica" isn't found Qt will try the lastResortFamily().
6. If the lastResortFamily() isn't found Qt will try the lastResortFont() which
will always return a name of some kind.
---
Here is more context for the code we are discussing from
bindings/qt-gui/plqt.cpp.
switch ( fontFamily )
{
case 1:
f.setStyleHint( QFont::Serif );
break;
case 2:
f.setStyleHint( QFont::TypeWriter );
break;
case 0: case 3: case 4: default:
f.setStyleHint( QFont::SansSerif );
break;
}
f.setFamily( "" ); // no family name, forcing Qt to find an appropriate
font by itself
So by this code setting the Family to an empty string we force Step 1
above to fail and fall back to one of the QFont::Serif,
QFont::TypeWriter, or QFont::SansSerif depending on what the user has
requested for the (generic) font family. And this font finding all
works fine (as you would expect from the above documentation) for
Debian Buster with Qt-5.11.2, for the much older Qt5 version I used
for Debian Oldstable last year, and for many different versions of Qt4
before that.
I strongly suspect what is going on is you don't have fontconfig installed, in
which
case the search algorithm above would drop through to step 6 consistent with
your
observation that the unmodified PLplot code has an extremely
limited font selection.
But if you confirm you do have fontconfig installed, then you have a
strong basis for a bug report to opensuse since setStyleHint appears
not to be working on that platform.
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
ype fonts based on URW Fonts ii freetype2-doc 2.9.1-3 all FreeType 2 font engine, development documentation ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4.4 all Fonts for the Ghostscript interpreter(s) ii gucharmap 1:11.0.3-1 amd64Unicode character picker and font browser ii kbd 2.0.4-4 amd64Linux console font and keytable utilities ii libfont-afm-perl 1.20-2 all Font::AFM - Interface to Adobe Font Metrics files ii libfontconfig1:amd64 2.13.1-2 amd64generic font configuration library - runtime ii libfontconfig1-dev:amd64 2.13.1-2 amd64generic font configuration library - development ii libfontenc1:amd64 1:1.1.3-1+b2 amd64X11 font encoding library ii libfreetype6:amd642.9.1-3 amd64FreeType 2 font engine, shared library files ii libfreetype6-dev:amd642.9.1-3 amd64FreeType 2 font engine, development files ii libgraphite2-3:amd64 1.3.12-1 amd64Font rendering engine for Complex Scripts -- library ii libkfontinst5 4:5.14.3-1 amd64Tools and widgets for the desktop library ii libkfontinstui5 4:5.14.3-1 amd64Tools and widgets for the desktop library ii libotf0:amd64 0.9.13-4 amd64Library for handling OpenType Font - runtime ii libsdl-ttf2.0-0:amd64 2.0.11-5 amd64TrueType Font library for Simple DirectMedia Layer 1.2, libraries ii libsdl2-ttf-2.0-0:amd64 2.0.14+dfsg1-3 amd64TrueType Font library for Simple DirectMedia Layer 2, libraries ii libwoff1:amd641.0.2-1 amd64library for converting fonts to WOFF 2.0 ii libxfont2:amd64 1:2.0.3-1 amd64X11 font rasterisation library ii libxft-dev:amd64 2.3.2-2 amd64FreeType-based font drawing library for X (development files) ii libxft2:amd64 2.3.2-2 amd64FreeType-based font drawing library for X ii lmodern 2.004.5-5 all scalable PostScript and OpenType fonts based on Computer Modern ii t1utils 1.41-2 amd64Collection of simple Type 1 font manipulation programs ii tex-gyre 20180621-2 all scalable PostScript and OpenType fonts based on URW Fonts ii texlive-fonts-recommended 2018.20181116-1 all TeX Live: Recommended fonts ii timgm6mb-soundfont1.3-2 all TimGM6mb SoundFont from MuseScore 1.3 ii xfonts-100dpi 1:1.0.4+nmu1 all 100 dpi fonts for X ii xfonts-75dpi 1:1.0.4+nmu1 all 75 dpi fonts for X ii xfonts-base 1:1.0.4+nmu1 all standard fonts for X ii xfonts-encodings 1:1.0.4-2 all Encodings for X.Org fonts ii xfonts-scalable 1:1.0.3-1.1 all scalable fonts for X ii xfonts-utils 1:7.7+6 amd64X Window System font utility programs ---8<- I find gucharmap (a GTK+ application) extraordinarily helpful in figuring out which of the system fonts that fontconfig will select for *any* unicode glyph. I highly recommend that you install that package and use it since it should be able to quickly find out independent of PLplot if fontconfig is working properly on your system. 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 Lin
Re: [Plplot-devel] Qt5 support, strange driver output
On 2018-12-12 15:24- António Rodrigues Tomé wrote: Hi Alan, now that 5.14 is out I would like to be more useful in solving the qt5 driver problem. However I do not complete understand the driver system to be of big help.However for me I found a work arround that seems to work quite well. I send you 4 files, output of x01 example using qt driver, png and pdf) the ones with Realease in name were created by the actual qt driver version 5.14 that I constructed with the command cmake -DCMAKE_INSTALL_PREFIX=/home/artome/plplot/PLPLOTNEW/ -DDEFAULT_NO_CAIRO_DEVICES=ON -DDEFAULT_NO_QT_DEVICES=OFF DENABLE_cxx=ON -DPL_DOUBLE=ON -DPLPLOT_USE_QT5=ON DEFAULT_NO_BINDINGS=ON../ >& cmake.out Hi António: Please keep this discussion thread on list. I think it would be better style (and also I think -DBUILD_TEST=ON is essential) to use instead cmake -DCMAKE_INSTALL_PREFIX=/home/artome/plplot/PLPLOTNEW/ -DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON -DENABLE_qt=ON -DPLPLOT_USE_QT5=ON -DDEFAULT_NO_CAIRO_DEVICES:BOOL=ON ../ >& cmake.out I just tried all those options here (except for your -DCMAKE_INSTALL_PREFIX), and they worked fine, i.e., eliminated all bindings other than cxx and qt, dropped the cairo devices, and included all qt devices (which happens by default if -DENABLE_qt=ON). What is your exact platform (I think it might still be opensuse, but what version?) and what are the results of the "uname -a" command on that platform? Also, what is the version of Qt5 that you are using? The reason these details are important is I cannot replicate the text alignment issues you demonstrated with pdfqt and pngqt results for example one on your platform. My platform is Debian Buster (with the Qt5 5.11.2 suite of libraries) installed on AMD64 hardware (Ryzen 7 1700). I demonstrated that I cannot replicate your badly aligned results by configuring cmake in the way I described above and then executing the following commands: # Build the prerequisites for the specific examples below make -j16 test_c_pngqt make -j16 test_c_pdfqt # Build two specific examples examples/c/x01c -dev pngqt -o test.pngqt examples/c/x01c -dev pdfqt -o test.pdfqt I have attached those two result files so you can see for yourself that there are no text alignment issues. Also your suggested changes to plqt.cpp likely conflate two issues. (i) alignment issues caused by your platform and not PLplot, and (ii) the size of the resulting characters (which I would prefer to put off discussing until later). So to check those are two separate issues, what happens if you restore plqt.cpp to its original form except for this one line change: PLDLLIMPEXP_QT_DATA( int ) vectorize = 0; ==> PLDLLIMPEXP_QT_DATA( int ) vectorize = 1; ? I am pretty sure that is the equivalent of the first part of your change where you are forcing the vectorize part of the code to be executed. If that one-line change is all you need to bypass your Qt5 platform issues, then I would be willing to test that simple change here to see if it also works on my platform. But the vectorize = 1 code path has not been tested by anybody but you over the years and is just likely a workaround for your Qt5 platform issue so I likely won't push that one-line change in general. Also you do appear to be having text alignment troubles consistently over the years with your (opensuse?) Qt5 platforms so perhaps it is time to try other Qt5 platforms? For example, you could build the upstream version of Qt5 yourself. The very early versions of Qt5 did have character alignment difficulties in that upstream version, but my experiments showed they solved the alignment issues important to PLplot by 5.3.x so you will likely find the latest upstream Qt5 also does not have text alignment issues. And if that is the case, then that experiment should be the basis of a bug report to your distribution. Of course, if that bug report gets no response another possibility is to try Debian (which I know works well now with Qt5) some Debian derivative such as Ubuntu or Mint or some other rpm-based distribution such as Fedora. Good luck, and let me know how it goes. 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 __ test.pdfqt Description: pdfqt properly aligned result test.pngqt Description: pngqt properly aligned result ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plplot-5.14.0 has been released
On 2018-12-12 16:33+0100 Ole Streicher wrote: Hi Alan, "Alan W. Irwin" writes: A comprehensive test and some additional specific tests of my fix for the release critical bug went well, and as a result I have now released 5.14.0. See my forthcoming post to plplot-general for the details concerning that release. thank you very much for preparing the new release! And congratulations for the success! You are welcome. I am now preparing the Debian package, and for there, I have a few questions: * the soname (ABI version) of libplplot changed to 16, right? Any other soname changes? Yes. Here is the transformed git diff results on soname changes: software@merlin> git diff 5cac57603d^ 5cac57603d cmake |grep '^[+-]set' |grep 'SOVERSION ' |sort --key=1.2 -set(plplot_SOVERSION 15) +set(plplot_SOVERSION 16) -set(plplotada_SOVERSION 2) +set(plplotada_SOVERSION 4) -set(plplotcxx_SOVERSION 13) +set(plplotcxx_SOVERSION 14) -set(plplotdmd_SOVERSION 3) +set(plplotdmd_SOVERSION 4) -set(plplottcltk_SOVERSION 13) +set(plplottcltk_SOVERSION 14) I plan to put some variant of this command in README.Release_Manager_Cookbook for next time since it makes obvious any typograpical errors in the library version updates such as incrementing plplotada_SOVERSION by 2 rather than 1, above. Sigh... * Is it now possible to build for more than one Python version? In Debian, we would need to build it for all available Python 3 versions (Python 3.6 and 3.7 in the moment), it would be nice if that would be supported directly. Same is for the pyqt5 driver. Sorry, we don't have direct support for building against multiple soft dependencies. So to provide this capability I assume you have some combination of multiple builds for multiple Python 3 versions. But for the second and subsequent builds you can eliminate most of the repeated stuff that you don't need to make the multiple builds quite efficient. For example, if you use the CMake options -DDEFAULT_NO_BINDINGS=ON -DENABLE_python -DENABLE_pyqt5 -DDEFAULT_NO_DEVICES=ON you will end up not building any devices and no bindings other than python and pyqt5. So the only redundant builds left should be the small libraries in the lib directory and the core C library itself that depends on those. * Given that Python 2 will die in 16 months, do you object when removing the Python 2 (python-plplot and python-plplot-qt) packages? A year or more ago I had direct advice from a Python developer that bugs in Python 2 (i.e., a corruption I discovered back then in one of my Python2-generated *.pyc files that was due to a Python2 race condition) are rarely fixed any more. So I haven't deprecated our Python 2 capabilities yet, but it is "on my radar", and if you choose to remove those capabilities for your Debian packages that is fine with me. [...] When I try to run the build time test, I get an error: 8<- ctest --extra-verbose UpdateCTestConfiguration from :/build/plplot-5.14.0+dfsg/DartConfiguration.tcl UpdateCTestConfiguration from :/build/plplot-5.14.0+dfsg/DartConfiguration.tcl Test project /build/plplot-5.14.0+dfsg Constructing a list of tests Updating test list for fixtures Added 0 tests to meet fixture requirements Checking test dependency graph... Checking test dependency graph end No tests were found!!! /usr/bin/make -C obj-* VERBOSE=1 test_diff_psc make[2]: Entering directory '/build/plplot-5.14.0+dfsg/obj-x86_64-linux-gnu' make[2]: *** No rule to make target 'test_diff_psc'. Stop. 8<- Should I do now something different than $ ctest --extra-verbose $ make -C obj-* VERBOSE=1 test_diff_psc You have to build the "all" target before you run ctest. Otherwise, you will get no tests as above. I have never tried the -C option to make, but apparently it is a way to short-circuit recursive invocations of make. But I doubt that idea is robust for all versions of cmake, and therefore I suggest you just drop that option. After all, running make VERBOSE=1 test_diff_psc is already quite fast and the time difference between using the -C option (when it works) versus not has got to be negligible since that time is dominated by running all the C examples for the psc device. By the way, why are you building individual low-level test targets such as test_diff_psc? Wouldn't it be much more efficient to, say, build all low-level noninteractive tests in parallel, with, say (assuming you have access to a computer with 16 threads) make -j16 VERBOSE=1 test_noninteractive ? Right now, when I do that here, I am getting time results equivalent to 4.5 threads, but other compilation-only tests I have done show that efficiency statistic can rise to the equivalent of about 15 threads (on my Ryzen 7 1700 system with 8 cpus and 16 hardware threads). So I
[Plplot-devel] plplot-5.14.0 has been released
Dear PLplot developers: A comprehensive test and some additional specific tests of my fix for the release critical bug went well, and as a result I have now released 5.14.0. See my forthcoming post to plplot-general for the details concerning that release. Here, I wish to thank Arjen Markus and Phil Rosenberg for their direct contributions to this release, and many others here for their indirect contributions via bug reports, using the git master tip version to make sure it is always working for your particular needs, participating in development discussions, etc. Please take a critical look at plplot.org. That site has been newly reviewed, regenerated and uploaded as part of the recent release process by me but other eyes on it will likely find more that needs changing. Of course, the soft freeze for pushing commits to SF is now over so I encourage you to mature your git topic branches and push those as well as push bug fixes as soon as possible in this new release cycle to maximize the time we can test such changes during this current release cycle which I currently plan will be something like 6 months long. My first priority for this release cycle is to make my Linux computer stable so that lockups (and attempts to find the cause of those) that occur on time scales of 1 day to 5 days are not distracting me near the end of this release cycle. But I also have a whole host of quick bug fixes and small development topics on my ToDo list that I put off near the end of the last release cycle, that I want to finish up early in this release cycle. Thus, if all goes well, you will see lots of git activity from me in the coming weeks as I clear out that ToDo list. Good luck with your own PLplot development and testing during this 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.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] 5.14.0 release status
On 2018-12-10 19:04-0800 Alan W. Irwin wrote: Hi Phil: This is mostly addressed to you because it turns out one of your commits is causing release-critical trouble with the plsori call in example 3 as well as any attempt to use a non-zero -ori option. [...] I used the commands make -j16 x01c ; make -j16 cairo examples/c/x01c -dev xcairo -ori 0.001 to help git bisect the issue. [...] @Phil: This commit (or its reverse) is not intrusive at all so it should not be that difficult to figure out why this change had such a catastrophic effect on plsdiori. Hi Phil (again): After some investigation I decided to make the following *local* change to the master tip version. diff --git a/src/plcore.c b/src/plcore.c index 8d82b5b0f..33c84eeb7 100644 --- a/src/plcore.c +++ b/src/plcore.c @@ -1965,10 +1965,10 @@ calc_didev( void ) // Set clip limits to conform to new page size -plP_sclp( (PLINT) ( plsc->didxax * plsc->phyxmi + plsc->didxb ), -(PLINT) ( plsc->didxax * plsc->phyxma + plsc->didxb ), -(PLINT) ( plsc->didyay * plsc->phyymi + plsc->didyb ), -(PLINT) ( plsc->didyay * plsc->phyyma + plsc->didyb ) ); +plsc->diclpxmi = (PLINT) ( plsc->didxax * plsc->phyxmi + plsc->didxb ); +plsc->diclpxma = (PLINT) ( plsc->didxax * plsc->phyxma + plsc->didxb ); +plsc->diclpymi = (PLINT) ( plsc->didyay * plsc->phyymi + plsc->didyb ); +plsc->diclpyma = (PLINT) ( plsc->didyay * plsc->phyyma + plsc->didyb ); } This change reverses one part of your commit that is obviously incorrect (since plP_sclp does not set plsc->diclpxmi et al and instead sets struct elements with almost the same name (clpxmi rather than diclpxmi, etc.)) My quick tests of this change shows it restores proper functioning of -ori and example 3 while also having good rendering results for examples/c/x33c -dev wxwidgets as well as -dev xwin, -dev xcairo, and -dev qtwidget. So I am hugely relieved to have found this solution for this regression so quickly. However, I haven't pushed this change yet because I haven't comprehensively tested it yet. 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] 5.14.0 release status
Hi Phil: This is mostly addressed to you because it turns out one of your commits is causing release-critical trouble with the plsori call in example 3 as well as any attempt to use a non-zero -ori option. The current status of the PLplot-5.14.0 release process is as follows: The PLplot development freeze that started on October 27th contines, i.e., do not push any topics other than documentation updates or well-tested bug fixes. I had gotten to the stage in README.Release_Manager_Cookbook where I was checking a locally generated version of our website when I discovered all lines were missing from example 3 for pngcairo. Further checking revealed that if plsori is called with a non-zero value (example 3) or the -ori option is used with a non-zero value (all other examples), then all graphical elements in the plot disappear for all device drivers! The plsori routine is simply a wrapper for plsdiori, and the -ori command-line option calls plsdiori directly. So this changed behaviour for plsdiori since 5.13.0 is a substantial regression which is therefore release critical. I used the commands make -j16 x01c ; make -j16 cairo examples/c/x01c -dev xcairo -ori 0.001 to help git bisect the issue, and from that bisection the first commit to cause missing graphics (i.e., missing lines) for that last command (or the same command for any other device) was your commit plplot-5.13.0-47-g124a0c3a2, with the subject line: "Set all clip limit changes I could find to use plP_sclp and hence get recorded in the buffer" Furthermore, for a local topic branch based on master tip, if I locally reverse that commit, the problem with missing graphics for the above example is solved and similarly (note that example 3 contains a call to plsori) examples/c/x03c -dev xcairo (or any other device) works fine (without missing graphics) as well. With the reversed commit, one thing that does not work well is (as expected) examples/c/x33c -dev wxwidgets which has rendering issues (missing lines and other graphical items). However, my test of that example with -dev xcairo, -dev qtwidget, and -dev xwin do render well with this reversed commit. @Phil: This commit (or its reverse) is not intrusive at all so it should not be that difficult to figure out why this change had such a catastrophic effect on plsdiori. N.B. Once I have that figured out, I will likely just go ahead and reverse your commit so that -ori and calls to plsori continue to work properly for our users just like they did for release 5.13.0. Of course, reversing your commit means that your attempt to record clip limits in the buffer this way in order to fix "examples/c/x33c -dev wxwidgets" will have to be addressed post-release in a way that preserves the functionality of -ori and plsori, but likely that will be far more intrusive than your commit plplot-5.13.0-47-g124a0c3a2 so it very likely should be a post-release change in any case. In sum, if I don't hear back from you quickly, I will likely just go ahead and reverse your commit tomorrow (Tuesday) and comprehensively test that change in anticipation of making the release later tomorrow. 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
Re: [Plplot-devel] Help needed for plplot runtime tests
On 2018-12-06 14:41+0100 Ole Streicher wrote: Hi Alan, sorry for the delay; I now managed to adjust and run the test suite on the installed package. I'll attach the full log; commands were $ cmake /usr/share/doc/plplot-doc/examples/ $ make VERBOSE=1 test_noninteractive I needed to downgrade to cmake 3.12; see bug #191. Hi Ole: I am glad to hear you are so close to complete success. My recent comprehensive test with 3.13.1 works perfectly here for Debian Buster and the git master tip version of PLplot. That master tip version includes a fix for bug 191 so could you confirm that by trying the master tip version (and then closing that bug if that indeed fixes it)? The only remaining errors are now ADA errors: Building Ada object ada/CMakeFiles/xstandard16a.dir/xstandard16a.o make[3]: *** No rule to make target 'plplotada-NOTFOUND', needed by 'ada/xstandard16a'. My recent comprehensive test using cmake-3.13.1 had no such Ada issue. So very likely this issue is because your installation is missing the plplotada *.so file or *.so.*.* file it links to, or this issue is an artifact of the way Debian packaging software changes locations or *.so names to some special Debian package naming scheme. So to debug this final issue do the following: * Make sure you are using the PLplot master tip version so we are on the same page with regard to bug fixes. This is really important since many 5.13.0 bugs are fixed in master tip which is now very close to 5.14.0. (I am now in the process of updating the release notes for that forthcoming release.) * Make sure your Ada binary package or packages are installed, and in those you should find the full pathname of the plplotada *.so file that should be installed by that package. * Check the Ada information in your installed and sed-transformed export files for consistency with that full pathname. If there is an Ada install directory inconsistency, then adjustment of the Ada install location you use for your core build should fix that. If there is a name inconsistency, then you need to make that consistent with some special Debian naming scheme for Ada *.so files by transforming our export files with a sed script. You told me of one such naming inconsistency you discovered before for a python related *.so file, and this may be just one other instance of the problem or all *.so files may have names that are inconsistent with the actual install name. In all cases if the *.so file name (without the path) does not match what is actually installed, a sed script should correct that inconsistency. Otherwise, it is "an accident waiting to happen" as appears to be the case both for that *.so Python module and now the Ada *.so file. If those steps don't help you to completely resolve this matter, please collect the following information and send it to me. (i) The complete list of files in your Ada binary packages (presumably some rpm command will generate that), (ii) the output from the cmake command you used *for the core build*, and (iii) the actual original and sed-modified export files. I am virtually positive that information will be sufficient for me to figure out what is wrong. 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] 5.14.0 release status
@All: The current status of the PLplot-5.14.0 release process is as follows: The PLplot development freeze that started on October 27th contines, i.e., do not push any topics other than documentation updates or well-tested bug fixes. @Phil: As part of the release process I added (commit plplot-5.13.0-157-g6e7b51cae) a number of sections to README.release discussing important improvements that were committed during this release cycle. There are more such sections to add, but I believe I am finished with the sections that are already there. However, I am certainly capable of mistakes and/or bad writing so I would appreciate you critically reading section 2.9 which summarizes your work on plmap during this release cycle, and especially section 2.10 which summarizes what I think are the current important wxwidgets issues. While writing up the -DPL_WXWIDGETS_IPC3=OFF or ON discussion that is part of section 2.10, I was reminded from my preliminary ChangeLog for this release how hard you had worked during this release cycle on fixing wxwidgets bugs. So in light of all those changes I repeated tests I had done earlier in the release cycle before your changes for -DPL_WXWIDGETS_IPC3=OFF and ON for -locate mode for example 1. Previously that interactive example had failed in two different ways on Linux for those two cases as I reported to you back then. With your fixes (none of which directly affected our IPC code for either -DPL_WXWIDGETS_IPC3=OFF or ON as far as I know) I continued to get the same bad results as before (the display of the plot would not appear until several mouse clicks had occurred on the blank plotting area of the GUI) for the -DPL_WXWIDGETS_IPC3=OFF case. However, the -DPL_WXWIDGETS_IPC3=ON test case result was a really good surprise; it worked for the first time ever for that interactive example! So I am very happy about whatever non-IPC fix you did that made that happen. And I am left wondering if whether that example will also work (e.g., without the deadlocks you noticed before) on Windows now (i.e., after your seemingly unrelated fixes) for the -DPL_WXWIDGETS_IPC3=ON case. So I would appreciate you letting me know about that so I can update section 2.10 accordingly. @All: The 5.14.0 release process will continue next with adding several additional topics to README.release to finish preparation of those release notes for 5.14.0. 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
Re: [Plplot-devel] 5.14.0 release status
On 2018-12-01 18:35-0800 Alan W. Irwin wrote: The current status of the PLplot-5.14.0 release process is as follows: The PLplot development freeze that started on October 27th contines, i.e., do not push any topics other than documentation updates or well-tested bug fixes. As part of the release process I have summarized (commit plplot-5.13.0-156-g39a15ae66) my recent comprehensive test reports for Debian Buster as the first two entries in the table at <https://sourceforge.net/p/plplot/wiki/Testing_Reports/>. The late October test was with cmake-3.7.2 (our minimum allowed version of CMake). Those results were perfect except that I forgot to install the haru software package so -dev pdf did not get tested. I corrected that oversight for my latest comprehensive test which I performed using cmake-3.13.1 (the latest release of CMake). Those results were perfect except for a run-time regression against the October results where the installed versions of qt_example and pyqt5_example.py both segfaulted. So for the final run of the comprehensive test script (which was perfect) I had to drop those tests using -DPLD_extqt=OFF. I don't think this issue is release critical so I am going to continue with the rest of the release process in README.Release_Manager_Cookbook with no code changes or further comprehensive tests. However, I have since discovered that for one combination (cmake 3.7.2 + shared libraries/dynamic devices + build tree), valgrind shows no memory management errors (i.e, segfaults were impossible for that combination) so a detailed valgrind comparison of all combinations possible (for all combinations tested by the comprehensive test script where only qt_example is tested for both cmake-3.7.2 and cmake-3.13.1) should easily find the specific PLplot or external cause of these segfaults, and if it is a PLplot issue I hope to make the fix soon after 5.14.0 is released. The 5.14.0 release process continues 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] 5.14.0 release status
The current status of the PLplot-5.14.0 release process is as follows: The PLplot development freeze that started on October 27th contines, i.e., do not push any topics other than documentation updates or well-tested bug fixes. As part of the release process I have summarized (commit plplot-5.13.0-153-g0d50e2a2a) Arjen's recent Cygwin and MinGW-w64/MSYS2 comprehensive test reports as the first two entries in the table at <https://sourceforge.net/p/plplot/wiki/Testing_Reports/>. @Arjen: Could you please review those table entries to make sure my summaries of your comprehensive tests are correct? My next planned step is to update that table again with my own recent comprehensive test reports, and then continue with the remaining parts of README.Release_Manager_Cookbook to finish the 5.14.0 release. 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] Rewrite of our Testing_PLplot wiki entry and new method of updating our wiki pages
On 2018-11-29 07:45- Arjen Markus wrote: Hi Alan, I will read this page on my way home, but for now my main critique is that it does not show up on the front page of the Wiki, whereas the first sentence is: "We encourage those who build PLplot to test both their build-tree and installed-examples-tree versions on any Linux, Windows, or Mac OS X platform." Currently, you have to know the page exists to find it 😉. Thanks for this good suggestion which I have just implemented (commit plplot-5.13.0-151-g38f41b6bf and <https://sourceforge.net/p/plplot/wiki/Home/>. I am trying to develop the habit of using "git describe" to describe all commits as above. For those who don't know about "describe" results yet, "plplot-5.13.0-151" says the commit is the 151st since plplot-5.13.0, and "g38f41b6bf" says the git commit id is 38f41b6bf (i.e. drop the "g" which I assume stands for git, but it is easy to remember to drop it in any case since "g" is not hexadecimal). By the way, this change fitted in well with the current organization of that Home page which I like. So I believe the only real issue with our wiki at that stage is too many of the pages are severely outdated. To illustrate this point, here are the current results adapted from <https://sourceforge.net/p/plplot/wiki/browse_tags/> 2006Configure_PLplot_for_Borland_CXX_5.5_(free_command_line_tools) 2007 Configure_PLplot_for_Borland_Turbo_C++_Explorer_Edition_(free_IDE_and_compiler) 2008Additional_notes_for_ifort_users; Aquaterm; Debugging_code; Documenting_the_undocumented; List_of_Debian_Ubuntu_packages; Mac_OSX; Qhull; Setup_watcom 2009Apply_a_patch; Configuration_of_wxWidgets_driver; Freetype; Frequently_Asked_Questions; Lua; OCaml_tutorial; Qt; Setup_mingw; Submit_a_patch; Swig; Using_PLplot; WxWidgets 2010Cairo_pango; Configure_PLplot_for_MinGW_CLI; Git_miscellanea; Install_3rd_party_libraries; Install_Lua; Install_MinGW_MSYS; Install_Octave; Install_SWIG; Install_Tcl; Libgd; Third-party_libraries 2011Building_PLplot_with_a_cross-compiler; Mac_OSX_Status; Todo_List 2012Configure_PLplot_for_Visual_CXX_CLI 2013Install_Python; Setup_Visual_Studio_Express; Setup_visualc; Specifics_for_various_platforms 2014Building_PLplot; Configure_PLplot_for_the_Visual_Studio_IDE; General_CMake_documentation_links 2015CMake_options_for_PLplot; Configure_PLplot_for_cygwin; Linux; Setup_cygwin 2017Overview_of_the_status_on_Windows 2018Home; MinGW-w64-MSYS2; Testing_PLplot; Testing_Reports From this list only 9 of our 54 pages have been updated since 2014! To all those here who would like to help out with our wiki. Please pick one of the topics above and update the corresponding markdown format file in doc/wiki_source, and commit that change to a local topic branch of your git repository. Those here who are not core developers should send us your suggested change in "git format-patch" form. After applying your commit on our own local topic branch, we will review your suggested change, cut and paste it to the SF GUI editor for the wiki page in question, test the resulting changed wiki page (e.g., check the history GUI to make sure there were no cut and paste failures, check the new links, check the rendering of the markdown format looks good), amend your commit if necessary, and push your (amended) commit following the directions in README.developers. Core developers here can skip the "git format-patch" command, but otherwise do everything else in the paragraph above (just like I did for Home) to update wiki pages that are important to you. 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] Help needed for plplot runtime tests
On 2018-11-29 13:33+0100 Ole Streicher wrote:
[...]
Now, all C examples pass.
Excellent!
For ADA, I now however get
[ 11%] Built target test_c_psc
Scanning dependencies of target xstandard16a
[ 11%] Building Ada object ada/CMakeFiles/xstandard16a.dir/xstandard16a.o
make[3]: *** Keine Regel vorhanden, um das Ziel „plplotada-NOTFOUND“,
benötigt von „ada/xstandard16a“, zu erstellen. Schluss.
make[2]: *** [CMakeFiles/Makefile2:5655:
ada/CMakeFiles/xstandard16a.dir/all] Fehler 2
make[1]: *** [CMakeFiles/Makefile2:387:
CMakeFiles/test_noninteractive.dir/rule] Fehler 2
The build of xstandard* examples is configured by the CMake logic in
examples/ada/CMakeLists.txt.
I am pretty sure the relevant CMake logic lines to build the Ada examples in
that file for this case where it is not the CORE_BUILD are
set(adalinkflags "\"-aI${CMAKE_CURRENT_SOURCE_DIR}\" \"-aI${ADA_INCLUDE_DIR}\"
\"-aL${ADA_LIB_DIR}\"")
[...]
set_target_properties(${TARGET_NAME} PROPERTIES LINK_FLAGS ${adalinkflags})
target_link_libraries(${TARGET_NAME} PLPLOT::plplotada PLPLOT::plplot)
So are the install locations ${ADA_INCLUDE_DIR} and ${ADA_LIB_DIR} set
where your Debian package actually installs Ada files? And if you
look in the PLplot export file, is the PLPLOT::plplotada location
property set there consistent with the full pathname of the plplotada
library that is installed by your debian package?
If those hints don't solve it or if they do solve it but another error
is encountered, please use a clean start (i.e., an initially empty
build tree), and send me the the complete cmake output and also the
complete results of
make VERBOSE=1 test_noninteractive >& test_noninteractive.out
(i.e., without any parallel build options).
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
I just discovered the --word-diff option to "git diff" command. That option has proven to be essential for evaluation of my recent commits concerning markdown format files (which all have extraordinarily long lines which makes "git diff" output without the --word-diff option essentially impossible to interpret). To show how useful this option is, compare results from git diff 7bedc70ad0^ 7bedc70ad0 and git diff --word-diff 7bedc70ad0^ 7bedc70ad0 The former result is essentially impossible to interpret because of the very long lines while the latter clearly shows the small tweaks I performed on those long lines for commit 7bedc70ad0. I am happy we are using git because I keep finding such cool functionality (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 __ ___ 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
On 2018-11-27 13:44+0100 Ole Streicher wrote: Hi Alan, thanks for the help so far! Hi Ole: You are welcome. On 26.11.18 19:52, Alan W. Irwin wrote: On 2018-11-26 16:46+0100 Ole Streicher wrote: It appears that CMake hard codes the filename on export. For example, software@merlin> grep _Pltk_init.so export_plplot-noconfig.cmake IMPORTED_LOCATION_NOCONFIG "/home/software/plplot/HEAD/comprehensive_test_disposeable blank/shared/noninteractive/install_tree/lib/python3.6/site-packages/_Pltk_init.so" list(APPEND _IMPORT_CHECK_FILES_FOR_PLPLOT::_Pltk_init "/home/software/plplot/HEAD/comprehensive_test_disposeable blank/shared/noninteractive/install_tree/lib/python3.6/site-packages/_Pltk_init.so" ) where export_plplot-noconfig.cmake is (on my system) installed in the $prefix/lib/cmake/plplot directory. And you will find similar hard-coded filenames for all other libraries and shared objects (dll's) in that file. I now just remove the checks via sed: sed '/\/_Pltk_init.so/d;/\/_plplotc.so/d;/\/plplot_pyqt5_/d;/\/libplplotada.so/d' \ -i /usr/lib/*/cmake/plplot/export_plplot-none.cmake And I also removed them from the dependencies in CMakeList.txt of the examples subdir. This is not a good idea. I haven't checked deeply, but our build and test system for the installed examples may use the location property of the imported PLPLOT::_Pltk_init target which you have removed with the above step. Or we may make such a change later. So if this is not an issue now, it is "an accident waiting to happen". So I strongly suggest instead you fix this properly by using your sed command to replace (not remove) _Pltk_init.so with the correct Debianized name for that installed file. Then, cmake runs fine But the "make" command gives errors after 8% completion: --8<- x19c *** PLPLOT ERROR, ABORTING OPERATION *** Could not find ss/ss64ne_Landform_Area file., aborting operation [... repeating the same warning for different files] *** PLPLOT ERROR, ABORTING OPERATION *** Could not find ss/ss64ne_General_Text file., aborting operation make[3]: *** [CMakeFiles/test_c_svgqt.dir/build.make:294: test_examples_output_dir/x00c01.svgqt] Fehler 1 --8<- A recent install of mine has the following shapelib data files installed in $prefix/share/plplot$version/ss os_open_conditions.txtss64ne_Height_Contours.dbf ss64ne_Landform_Line.prj ss64ne_Water_Area.shp ss64ne_Building_Area.dbf ss64ne_Height_Contours.prj ss64ne_Landform_Line.shp ss64ne_Water_Area.shx ss64ne_Building_Area.prj ss64ne_Height_Contours.shp ss64ne_Landform_Line.shx ss64ne_Water_Line.dbf ss64ne_Building_Area.shp ss64ne_Height_Contours.shx ss64ne_Road_Centreline.dbf ss64ne_Water_Line.prj ss64ne_Building_Area.shx ss64ne_Landform_Area.dbf ss64ne_Road_Centreline.prj ss64ne_Water_Line.shp ss64ne_General_Text.dbf ss64ne_Landform_Area.prj ss64ne_Road_Centreline.shp ss64ne_Water_Line.shx ss64ne_General_Text.prj ss64ne_Landform_Area.shpss64ne_Road_Centreline.shx ss64ne_General_Text.shp ss64ne_Landform_Area.shxss64ne_Water_Area.dbf ss64ne_General_Text.shx ss64ne_Landform_Line.dbfss64ne_Water_Area.prj Example 19 depends on these map data so these files are absolutely necessary for example 19 to work. Also, I believe we have had some discussion in the past on the licensing of these files, and I am positive you were satisfied on that issue. An apt-file search for these files here tells me they have not been included in the past in Debian PLplot packages (likely because of unclear licensing concerns which we have addressed), but once you address that issue, the above errors should go away. And that change (and the sed command change I recommended above) might be all you need to do to have a complete test success since the above error occurring for example 19 means almost half the standard examples work fine for you now. And, yes, I am a "glass half full" rather than "glass half empty" kind of guy. :-) 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] 5.14.0 release status
The current status of the PLplot-5.14.0 release process is as follows: The PLplot development freeze that started on October 27th contines, i.e., do not push any topics other than documentation updates or well-tested bug fixes. I have just finished pushing a rewrite of the Testing_PLplot wiki page, and I plan to follow up with 1. Updating the new wiki page, Testing_Reports, with recent comprehensive test results. 2. Doing all the usual steps documented in README.Release_Manager_Cookbook to finish up this release. So even though the computer instability I mentioned before is still something of a distraction, I have developed some temporary workarounds for the issue that should allow me to get through the above steps without too many more delays. 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] Rewrite of our Testing_PLplot wiki entry and new method of updating our wiki pages
Hi Arjen: I have just (the series of commits leading up to f7bedc70a) pushed a much-needed documentation update for <https://sourceforge.net/p/plplot/wiki/Testing_PLplot> where the test reports (so far not updated) have been separated out into their own wiki area <https://sourceforge.net/p/plplot/wiki/Testing_Reports>. Since you also use our test system a lot, I would appreciate your critical review of this updated documentation. As my next step, I intend to update the Testing_Reports page with results from your recent good comprehensive tests on your Cygwin and MinGW-w64/MSYS2 platforms and my own recent good comprehensive tests on my Linux (Debian Buster) platform. N.B. I seriously do not like the really weird markdown editor that is available at SourceForge for our wiki pages. As far as I am concerned that GUI editor is mostly good for the extremely old-fashioned version (with ctrl-c, ctrl-v, and delete) of cut and paste and that is about it. And I am also not happy with the SF methods to allow us to only backup those markdown files in non-standard JSON format that no JSON converter can convert back to markdown! Therefore, as part of the preliminaries to updating Testing_PLplot, I have put all the markdown source for our SF wiki pages under git control in the PLplot source tree. So from now on, updating a wiki page such as Testing_PLplot means you should edit the definitive markdown source for that wiki page in our source tree (at doc/wiki_source/Testing_PLplot for this particular example) using your favorite editor, check the results by cutting and pasting those changes to the wiki edit GUI (available at <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/> for this particular example), exit that SF GUI editor (which allows you to view the revised SF wiki entry generated by that GUI edit session), and if happy with that result, git commit the updated markdown file in our source tree. Or if you really like that GUI editor you can use it to edit our wiki at SF so long as you remember to cut and paste (that revised result directly from that GUI editor (not the SF page that links to that editor!) to the appropriate file in doc/wiki_source in our source tree and git commit that revised result. 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] Help needed for plplot runtime tests
On 2018-11-26 16:46+0100 Ole Streicher wrote: Hmm, no. It installs the file on the expected place, but *after* this (just before the files are put into the package), its name is changed to_Pltk_init.x86_64-linux-gnu.so (so, the architecture triple is added). Similarly for _plplotc.so (to _plplotc.x86_64-linux-gnu.so) and for the Python 3 shared libs (there, the name contains the Python version as well). So, it is not an inconsistent location, but a different file name. It appears that CMake hard codes the filename on export. For example, software@merlin> grep _Pltk_init.so export_plplot-noconfig.cmake IMPORTED_LOCATION_NOCONFIG "/home/software/plplot/HEAD/comprehensive_test_disposeable blank/shared/noninteractive/install_tree/lib/python3.6/site-packages/_Pltk_init.so" list(APPEND _IMPORT_CHECK_FILES_FOR_PLPLOT::_Pltk_init "/home/software/plplot/HEAD/comprehensive_test_disposeable blank/shared/noninteractive/install_tree/lib/python3.6/site-packages/_Pltk_init.so" ) where export_plplot-noconfig.cmake is (on my system) installed in the $prefix/lib/cmake/plplot directory. And you will find similar hard-coded filenames for all other libraries and shared objects (dll's) in that file. To solve this I suggest you simply use a sed script to add the architecture triple expected by Debian for the relevant filenames in the above file. Good luck with that suggested change and let me know how it goes. 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] Help needed for plplot runtime tests
On 2018-11-24 19:06-0700 Orion Poplawski wrote:
On 11/24/18 11:55 AM, Alan W. Irwin wrote:
Hi Orion:
This thread has previously been directed mostly at Ole, but
I am including you now because I think it will interest you. It concerns
the
problems (one of them upstream which I plan to fix soon by factoring
the export files [as I promised you long ago, but it got lost on the
stack until Ole ran into this problem again!]) that Ole has been having
with Debian to get testing working properly for the installed
examples.
I would appreciate you contributing to this thread. For example, if
all Fedora binary packages are installed (which works around the above
factoring problem until I can get it fixed) do the following tests of the
CMake-based and legacy-based installed examples work?
# CMake-based build system for the installed examples
# Move to initially empty build tree first.
rm -rf /tmp/plplot_cmake_test
mkdir /tmp/plplot_cmake_test
cd /tmp/plplot_cmake_test
cmake $prefix/share/plplot$plplot_version/examples
make -j test_noninteractive >&
test_noninteractive.out
# Legacy-based build system for the installed examples
# Keep the install-tree clean by copying the installed examples elsewhere
cp -a $prefix/share/plplot$plplot_version/examples /tmp
cd /tmp/examples
make -j test_noninteractive >&
test_noninteractive.out
If the above tests work on Fedora that proves that the Fedora
PLplot installation has correctly configured CMake export
and pkg-config *.pc files for the final Fedora installation locations.
Currently such tests fail for Ole's Debian packages, but I think some
attention to the details of PLplot installation locations will solve this
issue. And similarly in your case if those tests fail for Fedora.
Alan
It mostly seems to work fine. The one strange error for cmake is:
Generate C results for bmpqt file device
/usr/share/plplot5.13.0/examples/test_lua.sh: line 50: lua_svg_test.error:
Permission denied
[ 92%] Built target xtraditional16a
cat: lua_svg_test.error: No such file or directory
make[3]: *** [CMakeFiles/test_lua_svg.dir/build.make:374:
test_examples_output_dir/x00lua01.svg] Error 1
and for make/pkgconfig:
Generate Octave results for svg device
./plplot-test.sh --verbose --front-end=octave --device=svg
/usr/bin/bash: ./plplot-test.sh: Permission denied
make: *** [Makefile:126: x01o01.svg] Error 126
which is due to my removing the executable bit for the example script to
avoid issues with automatic dependencies.
Hi Orion:
I am glad to hear you appear to have what appear to be only two minor
issues flawing complete success with the above tests.
N.B. I regret now specifying the /tmp directory for both tests since that might
get overflowed
by the ~3GB of files that are produced by each of these tests when they are
successful.
So modify my instructions above to create an initially empty build directory
under your home
directory for the CMake-based case, and cp the installed example tree to an
initially empty
examples directory under your home directory.
Here are my comments on those two issues.
I. For CMake-based build system for the installed examples, issue with
lua_svg_test.error: Permission denied.
Just to remind you, official Debian lua version 5.3.3 (but not Fedora Lua
5.3.5) has a really bad bug
that can only be avoided by using a home-built 5.3.5 (which I use for my
testing).
So in my results the lua location will look quite different than yours.
Line 50 of the configured test.lua.sh file in my case is
/home/software/lua/install-5.3.5/bin/lua x${index}.${lang} -dev $device -o
"${results}"/x${index}${lang}%n.$dsuffix \
$options 2> lua_${device}_test.error >|
"${results}"/x${index}${lang}_${dsuffix}.txt
So my guess is in your case the equivalent lua command is having trouble
gaining permissions to write
to /tmp. To check that try running
lua test.lua 2> test.stderr >| test.stdout
in /tmp and also your home directory where
test.lua simply writes separate test strings to stderr and stdout.
Of course, if /tmp was overflowing doing the same test under your home
directory might cure the
issue.
II. For legacy build system for the installed examples, issue with
./plplot-test.sh: Permission denied
The configured and installed (in /share/plplot5.13.0/examples)
test scripts in my case have the following permissions
software@merlin> ls -lt *.sh
-rwxr-xr-x 1 software software 14080 Oct 27 12:16 plplot-test-interactive.sh*
-rwxr-xr-x 1 software software 13782 Oct 27 12:16 plplot-test.sh*
-rwxr-xr-x 1 software software 2211 Oct 27 12:16 test_ada.sh*
-rwxr-xr-x 1 software software 2326 Oct 27 12:16 test_c.sh*
-rwxr-xr-x 1 software software 2981 Oct 27 12:16 test_c_interactive.sh*
-rwxr-xr-x 1 software software 2802 Oct 27 12:16 test_cxx.sh*
-rwxr-xr-x 1 software software 2427 Oct 27 12:16 test_d.sh*
-rwxr-xr-x 1 software software 7150 Oct 27 12:16 test_diff.sh*
-rwxr-xr-x
[Plplot-devel] Help needed for plplot runtime tests
Hi Orion: This thread has previously been directed mostly at Ole, but I am including you now because I think it will interest you. It concerns the problems (one of them upstream which I plan to fix soon by factoring the export files [as I promised you long ago, but it got lost on the stack until Ole ran into this problem again!]) that Ole has been having with Debian to get testing working properly for the installed examples. I would appreciate you contributing to this thread. For example, if all Fedora binary packages are installed (which works around the above factoring problem until I can get it fixed) do the following tests of the CMake-based and legacy-based installed examples work? # CMake-based build system for the installed examples # Move to initially empty build tree first. rm -rf /tmp/plplot_cmake_test mkdir /tmp/plplot_cmake_test cd /tmp/plplot_cmake_test cmake $prefix/share/plplot$plplot_version/examples make -j test_noninteractive >& test_noninteractive.out # Legacy-based build system for the installed examples # Keep the install-tree clean by copying the installed examples elsewhere cp -a $prefix/share/plplot$plplot_version/examples /tmp cd /tmp/examples make -j test_noninteractive >& test_noninteractive.out If the above tests work on Fedora that proves that the Fedora PLplot installation has correctly configured CMake export and pkg-config *.pc files for the final Fedora installation locations. Currently such tests fail for Ole's Debian packages, but I think some attention to the details of PLplot installation locations will solve this issue. And similarly in your case if those tests fail for Fedora. 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] FW: Exponential labels - custom position
On 2018-11-23 12:11- Allen, Anthony J wrote:
Alan,
just to confirm, QSAS does not use your colour bar code, nor does it
use label_box_custom(). Alban wrote his own colour bar using plbox().
This means any change we made to label_box_custom is historical and nugatory,
and only the
changes to plbox() are relevant ( the else{ } ).
In fact we do not include pllegend.c in our version of plplot at all, which is
why I did
not see label_box_custom() being called.
Hi Tony:
Of course, upstream does use both label_box and label_box_custom. So
from that upstream perspective, I believe the plan should be to (1)
implement the test case I suggested (a simple example that plots both
a box and a color bar where both require exponential labels with
different custom locations for each); and (2) assuming that simple
example demonstrates the bug you discovered, then fix the bug in a
consistent way for both label_box and label_box_custom.
I have put this plan on my ToDo list and will keep you informed of my
progress once I start working on this topic (likely early in 2019).
However, if you decide to work along the lines of that upstream
plan yourself before I can get to it, please keep me informed of your
progress as well.
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] Help needed for plplot runtime tests
On 2018-11-23 08:28+0100 Ole Streicher wrote: [...] It is the cmake command. When I start with an empty dir, and then do $ cmake /usr/share/doc/plplot-doc/examples/ I get the following output: 8< -- The C compiler identification is GNU 8.2.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- CMake version = 3.12.3 -- CMAKE_SYSTEM_NAME = Linux -- CMAKE_PLATFORM_INFO_DIR = /home/ole/Projects/2011/debian/plplot/x/CMakeFiles/3.12.3 -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29") -- Looking for pkg-config - found -- cxx_compiler_library_pathname_list = -- A test cmake run with language = Ada enabled failed. -- Specify -DENABLE_compiler_diagnostics=ON to see full CMake diagnostics concerning this failure. -- WARNING: no working Ada compiler so disabling ada examples. -- The CXX compiler identification is GNU 8.2.0 -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- The Fortran compiler identification is GNU 8.2.0 -- Check for working Fortran compiler: /usr/bin/gfortran -- Check for working Fortran compiler: /usr/bin/gfortran -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /usr/bin/gfortran supports Fortran 90 -- Checking whether /usr/bin/gfortran supports Fortran 90 -- yes -- Found JNI: /usr/lib/jvm/default-java/lib/libjawt.so -- Could NOT find Qt5Svg (missing: Qt5Svg_DIR) CMake Warning at /usr/lib/x86_64-linux-gnu/cmake/plplot/plplotConfig.cmake:5 (find_package): Found package configuration file: /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake but it set Qt5_FOUND to FALSE so package "Qt5" is considered to be NOT FOUND. Reason given by package: Failed to find Qt5 component "Svg" config file at "/usr/lib/x86_64-linux-gnu/cmake/Qt5Svg/Qt5SvgConfig.cmake" Call Stack (most recent call first): CMakeLists.txt:471 (find_package) -- CORE_Qt5_FOUND = ON -- CORE_Qt5_VERSION_MAJOR = 5 -- CORE_Qt5_VERSION_MINOR = 11 -- CORE_Qt5_VERSION_PATCH = 2 -- Qt5_FOUND = 0 -- Qt5_VERSION_MAJOR = 5 -- Qt5_VERSION_MINOR = 11 -- Qt5_VERSION_PATCH = 2 -- WARNING: Qt5 core build-tree and install-tree inconsistency CMake Error at /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:279 (message): The imported target "_Pltk_init2.7" references the file "/usr/lib/python2.7/dist-packages/_Pltk_init.so" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib/x86_64-linux-gnu/cmake/plplot/plplotConfig.cmake:20 (include) CMakeLists.txt:471 (find_package) -- Configuring incomplete, errors occurred! 8< A Makefile is not produced then. The produced logfile is attached. Any idea? Hi Ole: I think there are at least two issues above. I. Missing package Everything above leading up to -- WARNING: Qt5 core build-tree and install-tree inconsistency indicates there is an inconsistency between the environment you used to build and install PLplot and the environment you are using to test the installed examples tree. From the first set of messages, especially, Failed to find Qt5 component "Svg" config file at "/usr/lib/x86_64-linux-gnu/cmake/Qt5Svg/Qt5SvgConfig.cmake" I think the solution is you must install libqt5svg5-dev which apt-file tells me contains /usr/lib/x86_64-linux-gnu/cmake/Qt5Svg/Qt5SvgConfig.cmake. II. The second problem above starts with the message CMake Error at /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:279 (message) I am virtually positive what is going on is that PLplot installs the files corresponding to the exported target PLPLOT::_Pltk_init.so in one location, e.g., "/usr/lib/python2.7/dist-packages/_Pltk_init.so" and your Debian packaging automatically changes that location to something else creating an inconsistency between the location expected by the exported target, and the location where the file was installed. To avoid such exported target inconsistent location issues, it is imperative that you change the *PLplot* installation locations to the locations expected by Debian. Please look at your core build (not the build of the installed examples you were testing above) cmake output for instructi
Re: [Plplot-devel] Help needed for plplot runtime tests
On 2018-11-22 20:54+0100 Ole Streicher wrote: Hi Alan, back from the US (ADASS), I found an hour to look further into the CI tests problem: "Alan W. Irwin" writes: On 2018-11-13 18:23+0100 Ole Streicher wrote: Upstream PLplot installs all examples configured in the core build in one place which contains a self-contained CMake-based build and test system for those examples. Therefore, I have to agree splitting up those installed examples in various locations is not a good idea since that means you have to implement a build system for each component of the examples! Therefore, I suggest instead you create a plplot-examples package that contains only text files, which are *all* the example files that upstream currently installs in $PREFIX/share/plplot$VERSION/examples, but it sounds like instead for debian if you do this suggested reorganization you should install them in /usr/share/doc/plplot-examples/examples. OK, so I now moved all examples to the "examples" subdir of the plplot-doc package, and now I am closer to a working test ;-) Next problem is that the Debian installation script renames the shared libraries that are installed for the Python package: On Python 2.7, - _Pltk_init.so becomes _Pltk_init.x86_64-linux-gnu.so resp. - _plplotc.so becomes _plplotc.x86_64-linux-gnu.so On Python 3.6 - /usr/lib/python3.6/dist-packages/_Pltk_init.so becomes /usr/lib/python3/dist-packages/_Pltk_init.cpython-36m-x86_64-linux-gnu.so - _plplotc.so similar And Python 3.7 similar. Hi Ole: I am glad to hear you are making significant progress. I looked deeper at the names of the python *.so files for Debian Buster for one arbitrary python package (curses). irwin@merlin> find /usr/lib/python3.7/ -type f |grep 'curses' |grep -E '(.py|.so)$' /usr/lib/python3.7/curses/panel.py /usr/lib/python3.7/curses/__init__.py /usr/lib/python3.7/curses/has_key.py /usr/lib/python3.7/curses/textpad.py /usr/lib/python3.7/curses/ascii.py /usr/lib/python3.7/lib-dynload/_curses.cpython-37m-x86_64-linux-gnu.so /usr/lib/python3.7/lib-dynload/_curses_panel.cpython-37m-x86_64-linux-gnu.so And that relocation (to lib-dynload) and extra ".cpython-37m-x86_64-linux-gnu" description in the *.so file names made no difference to the *.py files. For example, panel.py had the following import statement from _curses_panel import * with no mention of the location or extra name decoration of the corresponding *.so file. So from the results of that quick check, I don't understand why the installed PLplot example tests are complaining about the renaming (and even relocating to a different directory) of PLplot's installed python *.so files). Which leads to the following response to your question Is there a way to switch off the consistency check for Python? Please clear up exactly what you mean here by giving me the VERBOSE=1 output of the test target that is failing. For example, if you are building the test_noninteractive target, you could extract that necessary output this way. make VERBOSE=1 test_noninteractive >& test_noninteractive.out Given that output file, I could probably figure out a quick patch for you to get by whatever the error is because (as I found out above for curses) renaming and relocating *.so should not matter. My guess is that likely the PLplot build system is being much too specific about a name and/or location in the installed python files for PLplot. But assuming that is the case, I can find out where that is done a lot easier once I have your VERBOSE=1 test target build output in hand. BTW, I would still keep the dependencies of the -doc package as they are, and only for the tests install everything. Well, if you haven't done this already, I would suggest putting all the names of the relevant binary packages into the Suggests: list for the -doc package. (I assume that will be the final form you want once I get the upstream code properly factored since once that is done those binary packages will add substantially to the functionality of the -doc package which I believe is what Suggests: is for.) 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] FW: Exponential labels - custom position
sed code. N.B. I am happy to take a quick break (as now) from getting out the 5.14.0 release to discuss these changes with you, but we are in deep freeze now (i.e., it is obviously much too late in the present release cycle to get these or virtually any other code change into that release). But once you provide a good simple test example to make sure all is well with these changes, it would be ideal to get these changes accepted for PLplot early in the release cycle for 5.15.0. 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.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] 5.14.0 release status
The PLplot development freeze that started on October 27th contines, i.e., do not push any topics other than documentation updates or well-tested bug fixes. I am sorry to report that my pace for getting this release out has frankly slowed to a crawl, but there is some hope I will be able to restore a normal pace soon. The reason for this delay is I have been distracted in the last week by researching a chance to finally work around random lockups I have been encountering for my new Ryzen 7 1700 Linux box since I bought it in May. (For background information about Ryzen instability problems caused by a fundamentel AMD Ryzen hardware design flaw see <https://community.amd.com/thread/225795> and <https://bugzilla.kernel.org/show_bug.cgi?id=196683>.) Those links state one possible workaround requires building a specially configured custom Linux kernel. I finally managed to do that today after many false starts, and I am running that custom kernel now. And with luck perhaps this lockup distraction will be considerably reduced or even eliminated by this custom kernel. In sum, time will tell, and in any case I will continue to keep you informed about how the plplot-5.14.0 release process is going with status reports like this one every week 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
Re: [Plplot-devel] Help needed for plplot runtime tests
On 2018-11-13 18:23+0100 Ole Streicher wrote:
Hi Alan,
On 11.11.18 03:17, Alan W. Irwin wrote:
Everything you have done above should work fine for building and
testing the installed examples using the CMake-based build system for
those examples.
My problem is that I have actually split the examples by the language
binding: C and C++ go to libplplot-dev, tcl goes to plplot-tcl-dev etc.
It looks that this is not a really smart idea, right?
It also implies that they are not all at the same place: Debian
filesystem rules require that the examples are installed under
/usr/share/doc//examples (and they are partially zipped in the
moment).
Can I re-create the cmake files required for the tests somehow from the
source? Then I could avoid a bigger restructuration of the packages.
Hi Ole:
Upstream PLplot installs all examples configured in the core build in
one place which contains a self-contained CMake-based build and test
system for those examples. Therefore, I have to agree splitting up
those installed examples in various locations is not a good idea
since that means you have to implement a build system for each
component of the examples!
Therefore, I suggest instead you create a plplot-examples
package that contains only text files, which are *all* the example files
that upstream currently installs in
$PREFIX/share/plplot$VERSION/examples, but it sounds like instead
for debian if you do this suggested reorganization
you should install them in /usr/share/doc/plplot-examples/examples.
Then *if* you install all binary PLplot packages (with those examples
removed from then) and that plplot_examples package, then the
test procedure I suggested before for those installed examples should
"just work". So would you be willing to reorganize your packages that way and
verify the tests are working for that case?
That is a good "proof-of-concept first step to make sure we are at the same
starting point, but the obvious issue with that step is plplot-examples depends
on all
plplot binary packages, i.e., it won't work unless all are installed.
The rest of this e-mail concerns two up-stream fixes which I plan to
work on after the 5.14.0 release to relax that constraint.
As I have said before, the key command in the top-level CMakeList.txt
file for the installed examples is
find_package(plplot)
That command uses the exported files (located for
the Debian Buster libplplot-dev package at
libplplot-dev: /usr/lib/x86_64-linux-gnu/cmake/plplot/plplotConfig.cmake
libplplot-dev: /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake
libplplot-dev: /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot-none.cmake
) to implement imported targets such as PLPLOT:plplot,
PLPLOT:plplotcxx, etc., and our build system for the installed
examples then goes on to use those imported targets to build and test
the examples.
However, suppose a user only installs a subset of the configured
components of PLplot. To get the installed examples build system to
work for that case I need to implement the following two upstream
upgrades:
1. I need to factor the exported target files, e.g., the two
export_plplot* files mentioned above. Such factoring had already been
highly recommended to me by CMake gurus, and I think it should be
entirely straightforward.
Instead of using the "EXPORT export_plplot" signature for all library
and shared object installs and exporting all of that information to
just the two files export_plplot.cmake and export_plplot-none.cmake
using
install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot NAMESPACE
${PROJECT_NAMESPACE})
I simply use the "EXPORT export_" signature for all
library and shared object installs, and for each of those I add a
install(EXPORT export_ DESTINATION ${LIB_DIR}/cmake/plplot
NAMESPACE ${PROJECT_NAMESPACE})
The net result will be two files per target installed with names
export_.cmake and export_-none.cmake
where the first one automatically includes the second.
Also, I will need to change the plplotConfig.cmake file to use the
OPTIONAL signature of the cmake command "include" for a list of every
possible export_.cmake file to include just those that
are currently installed. But that change is completely
straightforward.
To take advantage of this factoring, you would also have to reorganize
what is in your binary packages a small amount. For example,
libplplot15 which currently includes
libplplot15: /usr/lib/x86_64-linux-gnu/plplot5.13.0/drivers/svg.so
should also need to contain the export files export_svg.cmake and
export_svg-none.cmake that are now would be associated with that
shared object. And similarly for all packages that contain installed
libraries and shared objects.
As a result of this factoring and your package reorganization to
include the many export_.cmake and
export_-none.cmake files generated by that factoring in
the correct binary packages, the "find_package(plplot)" command
m
Re: [Plplot-devel] Help needed for plplot runtime tests
On 2018-11-09 23:16+0100 Ole Streicher wrote: Hi, in the Debian package, we usually try to run CI tests regularly on each dependency change. This gives us the opportunity to early find problems with the package or one of its dependencies. However, I have some difficulties to do that; this may be connected with my limited knowledge of cmake. The test is started with the binaries installed in the system and the sources unpacked. The working dir is the root of the sources. What I basically do now is to run the following script: 8<- #!/bin/sh set -e SRC=$(pwd) test_dir=$(mktemp -d) cd $test_dir cmake $SRC/examples make test_diff_psc make test_noninteractive 8<- However, the "cmake" step fails with 8<- [...] -- CMAKE_SYSTEM_NAME = Linux -- CMAKE_PLATFORM_INFO_DIR = /tmp/tmp.TwEFoteIXX/CMakeFiles/3.12.3 CMake Error at CMakeLists.txt:469 (include): include could not find load file: plplot_configure 8<- How could I fix this? Hi Ole: Everything you have done above should work fine for building and testing the installed examples using the CMake-based build system for those examples. For example, similar tests here are normally successful, and that error message has never occurred here. So looking deeper, it turns out that include(plplot_configure) is a command that occurs in the installed CMakeLists.txt file in the top-level source directory for the installed examples, SRC=/usr/share/plplot5.13.0/examples (although that 13 will change to 14 when 5.14.0 is released). That command is looking for $SRC/cmake/modules/plplot_configure.cmake which normally is installed by PLplot. So since the error message says that installed file cannot be found, I strongly suspect the problem is simply that your RPM needs updating to include that installed file in the manifest. So please let me know if (a) $SRC/cmake/modules/plplot_configure.cmake is actually installed and if not (b) whether my guess is correct that the incompleteness of the rpm manifest is the issue. 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.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] 5.14.0 release status
The ETA for the release of PLplot-5.14.0 is likely sometime next week. The PLplot development freeze that started on October 27th contines, i.e., do not push any topics other than documentation updates or well-tested bug fixes. We have good comprehensive testing results for Arjen's Cygwin and MinGW-w64/MSYS2 platforms and my Debian Buster platform so I doubt there will be any further bug fixes before the release. However, the actual release has been somewhat delayed because I have added the task of making a much-needed update to the wiki documentation of our test procedure to the other release-related tasks (documented in README.Release_Manager_Cookbook) that I still need to do to complete this release. 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] Finalized plans for 5.14.0 freeze date, testing period, and release
The current status is Arjen has come through with good comprehensive testing results on Cygwin and (except for one issue that is likely not release critical) also good comprehensive testing results on MinGW-w64/MSYS2. So we appear to be in good shape on both these platforms as well as on my Linux platform (Debian Buster). If somebody volunteers by tomorrow (the freeze date) to do some much needed comprehensive testing on the Mac OS X platform, I will delay starting the release process to give them a chance to complete their tests (and me a chance to make any required adjustments to our build system for the Mac OS X case). But if nobody cares enough about that platform to volunteer to do such testing, then I plan to go ahead and start the release process tomorrow without Mac OS X testing results. N.B. Because of my new Debian Buster platform I cannot predict very accurately how long the release process is going to take me, but conceivably we might have a release of PLplot-5.14.0 as early as tomorrow night. However, more realistically it is likely going to be several days later than that. 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] Finalized plans for 5.14.0 freeze date, testing period, and release
On 2018-10-03 10:18-0700 Alan W. Irwin wrote: On 2018-09-23 18:56-0700 Alan W. Irwin wrote: I continue have a large list of different topics I would like to work on for PLplot, but, on the other hand, comprehensive tests are looking good (at least on Debian Buster) right now, and it has been much too long since our last release (mostly because of the "new computer" and "new distro version" issues I have been encountering). So I plan to spend the next several weeks working on the most urgent development topics I have a good chance of finishing before the soft freeze, with a proposed date of the freeze near the end of October followed by a testing and debugging period with the actual release of 5.14.0 occurring roughly in mid November. Please let me know if the general timing of that soft freeze, testing period, and subsequent release will cause you any issues with development topics you would like to push before the release of 5.14.0. But if I don't hear any strong objections along those lines, then later this week I plan to finalize that soft freeze date as October 27th (to be definite and to place it on the last Saturday in October). This is official notice that I will be going ahead with this plan. In particular, the soft freeze date has now been finalized as of October 27th. Current status: This is a reminder that the soft freeze deadline is only 5 days away. But I am going to stick to it (e.g., some of the small topics I am currently working on may have to be put off until post release, but such postponent is convenient to do with git since I am working on these topics using topic branches.) Comprehensive testing is going well. With the current master tip version I am getting essentially perfect results on Linux (Debian Buster). That is there are no obvious configure, build, or run-time issues and there is a perfect test_diff_device report for the (default) svg testing device. Also Arjen is getting promising-looking results for Cygwin. There is one regression there (the octave binding does not build) but a follow-up comprehensive test with octave disabled worked without issues, and the solution for the octave build difficulty may simply be a Cygwin system upgrade for one of the octave-related components. In any case, I am very happy with this preliminary result since a lot of build-system development has occurred since the last time that Cygwin was comprehensively tested. Despite this complete comprehensive testing success on Linux and almost-complete preliminary comprehensive testing success on Windows some additional volunteers to help out with comprehensive testing would add a lot to the value of this release. For example, we need someone to comprehensively test the MinGW-w64/MSYS2 Windows platform if Arjen does not have time to get to it, and we need someone to test any or all of Mac OS X + fink, MacPorts, and/or HomeBrew. In addition "redundant" comprehensive testing on the already tested Cygwin and Linux platforms would be useful since there are so many different Windows platforms that underlie Cygwin, and so many different Linux distributions that do things differently than my Debian Buster platform. N.B. the advantages of comprehensively testing this release on as many different platform variants as possible are obvious from the PLplot release integrity perspective, but I would also like to emphasize an additional individual advantage for testers which is testing helps you learn how to get the most out of PLplot (e.g., which packages to install to enhance the power of PLplot) for your platform of choice. Also once your particular system is set up properly for PLplot, running the comprehensive testing script is pretty trivial if you specify the "--do_test_interactive no" option so you don't have to baby-sit the tests generated by the script. But in any case, please run "scripts/comprehensive_test.sh --help" to get an idea of what is possible. Just to give you an idea of what is involved with the "--do_test_interactive no" case you do need access to 6 GB of spare disk space to store the many plot files that are generated by these tests, and my ~11-year old Intel box took something like ~5 hours to complete this set of tests while my modern Ryzen 7 1700 box with faster memory and CPUs and 4 times as many CPUs takes roughly ~one hour to complete the noninteractive tests. In my case for "--do_test_interactive no", I simply use the bash source command to set relevant environment variables, start the script, and then I do something else until the tests complete. And it should be just that simple for you as well once you have installed all relevant platform packages and decided which components of PLplot have to be disabled if they are not working on your particular platform. In sum, comprehensive testing should be straightforward so I hope to hear from *all* of you lurking on this list who h
[Plplot-devel] Finalized plans for 5.14.0 freeze date, testing period, and release
On 2018-09-23 18:56-0700 Alan W. Irwin wrote: I continue have a large list of different topics I would like to work on for PLplot, but, on the other hand, comprehensive tests are looking good (at least on Debian Buster) right now, and it has been much too long since our last release (mostly because of the "new computer" and "new distro version" issues I have been encountering). So I plan to spend the next several weeks working on the most urgent development topics I have a good chance of finishing before the soft freeze, with a proposed date of the freeze near the end of October followed by a testing and debugging period with the actual release of 5.14.0 occurring roughly in mid November. Please let me know if the general timing of that soft freeze, testing period, and subsequent release will cause you any issues with development topics you would like to push before the release of 5.14.0. But if I don't hear any strong objections along those lines, then later this week I plan to finalize that soft freeze date as October 27th (to be definite and to place it on the last Saturday in October). This is official notice that I will be going ahead with this plan. In particular, the soft freeze date has now been finalized as of October 27th. 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] How to use plplot in my own project?
On 2018-09-29 09:53+0100 Phil Rosenberg wrote: [...] - Alan do you know if it [library suffix] is still implemented and if so what it is? There used to be a d suffix added to represent the fact that the library was built with double precision floating point variables, but I don't think this is the case any more. We dropped library suffixes some time ago because of the much cleaner solution you state below. [...] Anyway, my solution was to install my debug libraries in a folder specific to debug libraries. Almost every library has a way to specify the install prefix. With plplot you can do this with the -DCMAKE_LIBRARY_PATH or -DCMAKE_INSTALL_PREFIX Exactly. 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] How to use plplot in my own project?
On 2018-09-25 22:05+0200 Laurent Berger wrote:
Hi,
I want to use plplot in my own project using cmake and I miss something. my
cmakelists.txt is see below and it works. But in include_directories cmake
command I must write :
include_directories(${plplot_DIR}/../../../include) and it is really weird.
what's variable name for include ?
[...]
CMakeLists.txt
[...]
find_package(plplot)
[...]
ADD_EXECUTABLE (${NomProjet} ${Projet_SRCS} )
[...]
if (plplot_FOUND)
include_directories(${plplot_DIR}/../../../include)
target_link_libraries( ${NomProjet} PUBLIC PLPLOT::plplotwxwidgets)
else (plplot_FOUND)
message( " PROBLEME" )
endif(plplot_FOUND)
Hi Laurent:
I have reviewed the redacted version above, and all seems well. For
example, our installed examples are similarly built against the
installed version of PLplot, and what you have implemented above
follows that same method. For example, you can see
"find_package(plplot)" (in the non-CORE_BUILD part of
examples/CMakeLists.txt), and a combination of add_executable,
include_directories (which refers to the installed location of PLplot
for the non-CORE_BUILD case just like you apparently have
implemented), and target_link_libraries in examples/c/CMakeLists.txt.
However, you were right to question that include_directories command
which is necessary now, but should not be necessary in future once I
set up the export of PLplot to handle compile options properly. But
that implementation is a little tricky so although it is on my ToDo
list now, I am going to put it off until after the 5.14.0 release that
is coming soon.
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] Is there some important reason for using the -single-module linker option on modern Mac OS X?
On 2018-03-22 19:12-0700 Alan W. Irwin wrote: To those here with knowledge of Mac OS X linking: According to <http://www.manpages.info/macosx/ld.1.html> there exists the following ld options: " -single_module When building a dynamic library build the library so that it contains only one module. -multi_module When building a dynamic library build the library so that it contains one module for each object file linked in. This is the default. " We currently use -single_module for linking on this platform (see CMAKE_USER_MAKE_RULES_OVERRIDE in the top-level CMakeLists.txt file). However that override was imposed 12 (!) years ago to address a linking issue that I suspect no longer exists. For example, a google search for the terms found nothing relevant beyond the CMake mailing-list discussion I generated about this issue back then. So unless I hear from Mac OS X experts here that there is some important reason for using the -single_module option for linking dynamic libraries on modern Mac OS X, I plan (on Sunday to give you a couple of days to respond) to drop this override completely to conform to how other CMake-based build systems configure linking of dynamic libraries on Mac OS X. From the "better late than never" department, I have indeed now (commit d6a762704) removed this override that is specific to Mac OS X "on Sunday", but frankly I forgot all about this until reminded of it today by my ToDo list so it is a large number of Sundays later than I anticipated in the above post! N.B. This fundamental linking change for Mac OS X platforms needs to be comprehensively tested on Mac OS X. So I need a volunteer (with lots of free disk space that is temporarily consumed by the test until deletion of many plot files at the end of the test) to do that. Just run scripts/comprhensive_test.sh --help to see what is possible with that script. However, be warned that if you specify no options the default is *all* components of the comprehensive test are run. This means, for example, that you will be doing a lot of babysitting as you work through the interactive components of the test so at minimum for a first try you will likely want to constrain the test with the --do_test_interactive no script option to make the test into something that can quietly be run in the background with little interaction needed from you. Also, note the test generates a report tarball with all the details of the test whether it succeeds or not. So please send me that report tarball regardless of results since in case of failures that tarball helps me to analyze the reason for the failures, and in case of success that tarball helps me to assemble a report of your comprehensive test success for our wiki. 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] Tentative plans for 5.14.0 freeze date, testing period, and release
I continue have a large list of different topics I would like to work on for PLplot, but, on the other hand, comprehensive tests are looking good (at least on Debian Buster) right now, and it has been much too long since our last release (mostly because of the "new computer" and "new distro version" issues I have been encountering). So I plan to spend the next several weeks working on the most urgent development topics I have a good chance of finishing before the soft freeze, with a proposed date of the freeze near the end of October followed by a testing and debugging period with the actual release of 5.14.0 occurring roughly in mid November. Please let me know if the general timing of that soft freeze, testing period, and subsequent release will cause you any issues with development topics you would like to push before the release of 5.14.0. But if I don't hear any strong objections along those lines, then later this week I plan to finalize that soft freeze date as October 27th (to be definite and to place it on the last Saturday in October). To give you more details about the actual events leading up to the release, the overall timing of the release depends critically on the soft freeze date, i.e., the date where we ask our developers to quit pushing new development topics and instead concentrate on fixing bugs and updating the documentation until the release is completed. What that means practically is just after the freeze date I will call for intensive testing and use those results to solve as many bugs as possible without introducing any new development topics. That process will likely take one or two weeks after the freeze date before I can start the official release process currently described for Debian Oldstable = Jessie in README.Release_Manager_Cookbook. But that release process (which normally just takes a day or two) will likely get stretched out a bit because that cookbook likely needs quite a bit of updating as I encounter issues that are caused by my current platform of Debian Buster. In sum, the official release should occur something like two to three weeks after the soft freeze date depending on the participation from you guys in the testing, how difficult it is to sort out the bugs found by that testing, and how much I have to upgrade the release process for Debian Buster. So that's how the currently proposed freeze date of October 27th gets transformed into a release date that is roughly in mid November. 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] Cannot compile plplot using VS 2017
On 2018-09-22 23:16+0100 Phil Rosenberg wrote: Hi Laurent I have implemented your first solution. If you could let me know that things now work for you that would be great. Hi Phil: Although your question was addressed to Laurent, it should interest you to know your fix causes no issues for Linux (i.e., building the test_c_wxwidgets and test_wxPLplotDemo targets caused no obvious build or run-time 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.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] Plplot now working well with Debian Buster + release timing
Hi Ole: I have just now updated PLplot (commit d2d9461a3) to allow our build system to use local builds of Lua in a consistent fashion, and using that capability I have proved the Debian Lua-5.3.3 issue is in upstream 5.3.3 which is fixed in upstream 5.3.5 (see the latest discussion at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for more details). Furthermore, if you look at <https://tracker.debian.org/pkg/lua5.3> the official maintainer has been inactive for the last three years so others have been occasionally contributing with the last such activity a year ago. Therefore, would you be willing to do a NMU of lua-5.3.5 to allow the upstream fix for the lua issue I have been discussing to propagate to Debian? Such propagation should simplify your life as the Debian maintainer for PLplot as well as being a big help to each Debian user who is encountering this severe issue with Lua-5.3.3. 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] Cannot compile plplot using VS 2017
On 2018-09-21 18:38+0200 Laurent Berger wrote: Hi, I have just done a git clone : (Date: Thu Sep 20 22:36:48 2018 -0700 ) commit caf4801dfef32207b74f5374eff52bf2a4c24e3d and delete cmakecache.txt and I I'm trying to build plplot in static BUILD_SHARED_LIBS:BOOL=OFF and ENABLE_DYNDRIVERS:BOOL=OFF and I have got 59 errors compiling wxwidgets_dev.cpp. In git repo I can find this file https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp I copy https://github.com/PLplot/PLplot/blob/14ecc4bd943caa40a830e0da066ff7a220b9d5e8/drivers/wxwidgets.cpp#L28-L36 and insert those lines here https://github.com/PLplot/PLplot/blob/master/drivers/wxwidgets_dev.cpp#L41 I can compile and link plplot. Hi Laurent: Thanks for your test of my recent PLplot development activity. I have looked at commits 14ecc4bd94 (= plplot-5.13.0-59-g14ecc4bd9) and caf4801dfe (current master tip), and your description of the required change appears to correspond to copying some wxwidgets includes from one part of the old commit (or alternatively the latest commit since those lines haven't changed) to just after #include "wxwidgets.h" As far as I can tell such a copy of includes should have zero effect so it appears either I misunderstood the change you described above or else the github repo for PLplot is not properly up to date with the definitive SourceForge repo. So to remove this uncertainty please give us the results of git diff to describe the definitive version of the change to the master tip of PLplot that works for you (i.e., allows a static build of PLplot to compile and link for your VS2017 platform). By the way, a comprehensive test of PLplot has recently (one commit behind master tip) worked perfectly here on Linux (Debian Buster). Such comprehensive tests include not only building a static wxwidgets device but run-time testing it as well. Also that last commit on the master branch is a minor one involving how to control the Lua version that is searched for and is therefore extremely unlikely to introduce wxwidgets issues. Therefore, I cannot replicate your issue on Linux so someone with access to recent Windows platforms will have to attempt that 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.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] Plplot now working well with Debian Buster + release timing
On 2018-09-20 21:09-0600 Orion Poplawski wrote: On 09/20/2018 12:22 AM, Alan W. Irwin wrote: On 2018-09-19 22:06-0600 Orion Poplawski wrote: On 09/15/2018 01:49 PM, Alan W. Irwin wrote: To Orion and Ole: Commit a730ebe34 has removed the last of the "new software" issues I have identified with Debian Testing = Buster. @Orion: I encourage you to try that commit on Fedora to see if you get similarly good results for all Linux-available components of PLplot for that other cutting-edge Linux platform. @Both: You both also might want to experiment with this commit as the basis for much-improved PLplot packages for Fedora and Debian. However such packages can only be considered preliminary until PLplot makes an official release. What I can say on that topic is commit a730ebe34 is an important milestone on the trail to the next release, but we are not there yet. For example, the CMake test that is automatically produced every night by my computer for the CMake developers builds and tests the latest CMake. One of those tests is the PLplot contract test which tests whether a build (but not test) of PLplot is successful. That test is formally succeeding, but those PLplot builds are incomplete (with the cairo device driver dropped) because of incompatibilities with the way we configure our cairo device driver using internal details of the CMake pkg-config capability. Although the use of such internal details has worked well over many years with few adjustments needed for changes to those internal details with CMake version, it is again no longer working with the very latest CMake. This reflects the fundamental fragility of any method that uses internal details. Therefore, to deal with this issue my plan is to completely rewrite our support for the cairo device using the official CMake pkg-config support rather than internal details of that support. And there are also a few other topics I would like to squeeze into the next release. So this makes the ETA of our next PLplot release still somewhat uncertain, but I am still hoping to get it done this year (before Christmas season) rather than early next year. Latest git (a9d9500c) built on Fedora Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905 Despite the overall failure to build, looks mostly okay, but it appears that you don't support lua 5.3: -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version "5.2") -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version "5.1") -- LUA_INCLUDE_DIR = -- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so -- WARNING: Lua header and/or library not found. Disabling Lua binding Hi Orion: Thanks for that feedback. Lua5.3 worked here (Debian Testing = Buster) for all but one example, but that one example exposed a Lua-5.3 bug (at least for the Debian version of Lua5.3) that was severe (arithmetic quit working if more than 8 (!) arrays were initialized). See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for a simple Lua script that triggers this Lua-5.3 bug and other details about this bug. I temporarily worked around the problem by using our build system to blacklist Lua-5.3 until this bug is fixed (i.e., in the absence of Lua5.1 or 5.2 our build system should just cleanly drop the Lua PLplot component and continue). Please try that simple Lua script to see whether the Fedora version of Lua-5.3 also has this severe bug. If you do confirm, then that is pretty good evidence it is a general Lua-5.3 bug (rather than just Debian related), and in this case I would be willing to take this issue to the Lua developers rather than waiting for some response to my bug report from the Debian packagers. It appears from <https://kojipkgs.fedoraproject.org//work/tasks/1906/29771906/build.log> the blacklisting worked without actual build issues (as expected), but the actual error you get is because your rpm logic is expecting Lua files from PLplot that are not there because of the blacklisting. So your response to this issue likely depends on whether you can get the above simple test script to work for Fedora's version of Lua5.3. If that test actually works for Fedora, then it appears the Lua5.3 issue is simply a Debian packaging issue that has nothing to do with Fedora, and you should edit cmake/modules/lua.cmake to make the slight change to look first for 5.3, then 5.2, then 5.1. However, if that test also fails for you, and you think the upstream Lua5.3 fix is going to take a while to get fixed, then you should change your rpm logic to drop all the expected Lua results. Alan I replied to the debian bug. It appears that lua 5.3.5 on Fedora rawhide is fine. See my further traffic there. In any case I was coming around to the view that our build system should not blacklist Lua5.3 since the issue I observe is a run-time issue, i.e., it does not affect builds or generation of a
Re: [Plplot-devel] Plplot now working well with Debian Buster + release timing
On 2018-09-19 22:06-0600 Orion Poplawski wrote: On 09/15/2018 01:49 PM, Alan W. Irwin wrote: To Orion and Ole: Commit a730ebe34 has removed the last of the "new software" issues I have identified with Debian Testing = Buster. @Orion: I encourage you to try that commit on Fedora to see if you get similarly good results for all Linux-available components of PLplot for that other cutting-edge Linux platform. @Both: You both also might want to experiment with this commit as the basis for much-improved PLplot packages for Fedora and Debian. However such packages can only be considered preliminary until PLplot makes an official release. What I can say on that topic is commit a730ebe34 is an important milestone on the trail to the next release, but we are not there yet. For example, the CMake test that is automatically produced every night by my computer for the CMake developers builds and tests the latest CMake. One of those tests is the PLplot contract test which tests whether a build (but not test) of PLplot is successful. That test is formally succeeding, but those PLplot builds are incomplete (with the cairo device driver dropped) because of incompatibilities with the way we configure our cairo device driver using internal details of the CMake pkg-config capability. Although the use of such internal details has worked well over many years with few adjustments needed for changes to those internal details with CMake version, it is again no longer working with the very latest CMake. This reflects the fundamental fragility of any method that uses internal details. Therefore, to deal with this issue my plan is to completely rewrite our support for the cairo device using the official CMake pkg-config support rather than internal details of that support. And there are also a few other topics I would like to squeeze into the next release. So this makes the ETA of our next PLplot release still somewhat uncertain, but I am still hoping to get it done this year (before Christmas season) rather than early next year. Latest git (a9d9500c) built on Fedora Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=29771905 Despite the overall failure to build, looks mostly okay, but it appears that you don't support lua 5.3: -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version "5.2") -- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is exact version "5.1") -- LUA_INCLUDE_DIR = -- LUA_LIBRARIES = /usr/lib64/liblua.so;/usr/lib64/libm.so -- WARNING: Lua header and/or library not found. Disabling Lua binding Hi Orion: Thanks for that feedback. Lua5.3 worked here (Debian Testing = Buster) for all but one example, but that one example exposed a Lua-5.3 bug (at least for the Debian version of Lua5.3) that was severe (arithmetic quit working if more than 8 (!) arrays were initialized). See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902238> for a simple Lua script that triggers this Lua-5.3 bug and other details about this bug. I temporarily worked around the problem by using our build system to blacklist Lua-5.3 until this bug is fixed (i.e., in the absence of Lua5.1 or 5.2 our build system should just cleanly drop the Lua PLplot component and continue). Please try that simple Lua script to see whether the Fedora version of Lua-5.3 also has this severe bug. If you do confirm, then that is pretty good evidence it is a general Lua-5.3 bug (rather than just Debian related), and in this case I would be willing to take this issue to the Lua developers rather than waiting for some response to my bug report from the Debian packagers. It appears from <https://kojipkgs.fedoraproject.org//work/tasks/1906/29771906/build.log> the blacklisting worked without actual build issues (as expected), but the actual error you get is because your rpm logic is expecting Lua files from PLplot that are not there because of the blacklisting. So your response to this issue likely depends on whether you can get the above simple test script to work for Fedora's version of Lua5.3. If that test actually works for Fedora, then it appears the Lua5.3 issue is simply a Debian packaging issue that has nothing to do with Fedora, and you should edit cmake/modules/lua.cmake to make the slight change to look first for 5.3, then 5.2, then 5.1. However, if that test also fails for you, and you think the upstream Lua5.3 fix is going to take a while to get fixed, then you should change your rpm logic to drop all the expected Lua results. 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] Plplot now working well with Debian Buster + release timing
To Orion and Ole: Commit a730ebe34 has removed the last of the "new software" issues I have identified with Debian Testing = Buster. @Orion: I encourage you to try that commit on Fedora to see if you get similarly good results for all Linux-available components of PLplot for that other cutting-edge Linux platform. @Both: You both also might want to experiment with this commit as the basis for much-improved PLplot packages for Fedora and Debian. However such packages can only be considered preliminary until PLplot makes an official release. What I can say on that topic is commit a730ebe34 is an important milestone on the trail to the next release, but we are not there yet. For example, the CMake test that is automatically produced every night by my computer for the CMake developers builds and tests the latest CMake. One of those tests is the PLplot contract test which tests whether a build (but not test) of PLplot is successful. That test is formally succeeding, but those PLplot builds are incomplete (with the cairo device driver dropped) because of incompatibilities with the way we configure our cairo device driver using internal details of the CMake pkg-config capability. Although the use of such internal details has worked well over many years with few adjustments needed for changes to those internal details with CMake version, it is again no longer working with the very latest CMake. This reflects the fundamental fragility of any method that uses internal details. Therefore, to deal with this issue my plan is to completely rewrite our support for the cairo device using the official CMake pkg-config support rather than internal details of that support. And there are also a few other topics I would like to squeeze into the next release. So this makes the ETA of our next PLplot release still somewhat uncertain, but I am still hoping to get it done this year (before Christmas season) rather than early next year. 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] Intermittent Ada example build failures are now back again (SOLVED by gnat-8)
On 2018-09-14 12:19- Arjen Markus wrote: Hi Alan, -Original Message- From: Alan W. Irwin [mailto:alan.w.irwin1...@gmail.com] To Jerry and Arjen: On Sunday (just before commit 7ec926fae) I discovered that my installs of gdc-7 and gnat-7 were probably not good choices because although I had both gcc-7 and gcc-8 installed, PLplot was being built with gcc-8 rather than gcc-7 on my Debian Buster system. So in this case at least Debian does not have tight version consistency requirements between either gdc or gnat and gcc. And perhaps that is justified since previously I was getting perfect results with the combination of gdc-7 and gcc-8. However, the above parallel build issue with gnat-7 encouraged me to try gnat-8, and I decided to install gdc-8 as well just to be consistent with gcc-8. It turns out (see the above commit message for the details) the combination of gdc- 8, gnatmake-8, and gcc-8 produces perfect massively (-j10) parallel build and test results for a comprehensive set of of configurations and build trees, and for three different CMake versions. So it seems once again that on Linux at least, parallel builds of our Ada bindings and examples work well, and I advise on other platforms to avoid gnat-7 in all cases, to use parallel builds with caution, and at least for the sake of consistency use the same version of gdc, gnat, and gcc (e.g., gdc-8, gnat-8, and gcc-8). I just checked the Cygwin set-up: there is at this moment at least no version 8 available within that environment. I do not know if there are any plans to incorporate it, but I will keep an eye out. Indeed, from <https://cygwin.com/cgi-bin2/package-grep.cgi> a search for gcc shows that currently the maximum gcc version available is gcc-7 and similarly gnat-7 is the maximum version of gnat that is available. So you might want to try those two (in fact your previous tests might have already been done with those two), but from my Linux experience I would not bother with parallel builds with gnat-7. But as I recall, Cygwin has other troubles with parallel builds so that might be a moot constraint. In contrast to the Cygwin case, <http://repo.msys2.org/mingw/x86_64/> shows for the MinGW-w64/MSYS2 case that the maximum gcc and gnat versions are 8.2.0 which is also the versions of those two software packages I used recently for my successful Debian Buster tests. So the next time you test this platform I suggest you try version 8 of gcc and gnat if you are not doing that already. And since parallel builds and tests worked so well for the Linux case you might want to try those on this platform especially if those have been successful before. By the way, it is a bit of a concern for the Cygwin rolling release that the CMake, gcc, and gnat versions are getting pretty far behind what is available with MinGW-w64/MSYS2, but, of course, those packaging delays could all be special cases. Does the overall health of the Cygwin project seem fine (e.g., all legitimate questions answered in a timely way by Cygwin developers, and packaging progress continuing to be made for a large number of packages) from what you have been reading on the Cygwin mailing list? 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] Intermittent Ada example build failures are now back again (SOLVED by gnat-8)
On 2018-07-16 10:10-0700 Alan W. Irwin wrote: On 2018-06-09 13:30-0700 Alan W. Irwin wrote: On 2018-04-15 11:15-0700 Alan W. Irwin wrote: Hi Jerry: [...] So once this Ada build issue appeared again for me yesterday after all those previous successful hardware checks, I did a google search for the terms (without the quotes) "gnatmake intermittent build error" and found <https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=65451> which was a bug report in 2015 about intermittent Ada build issues which was immediately fixed back then. However, my gnat version (= 4.9.2) is from 2014 so I don't have that bugfix and I am pretty sure at this stage that bug 65451 is the issue that is causing the intermittent Ada build issues for me. Therefore, I plan to use the -DENABLE_ada=OFF option for my further testing until I can get access to a later version of the Ada build tools myself, and I suggest others who currently don't have access to Ada build tools with bug 65451 fixed should do the same. Just to follow up for Debian Buster with gnat-7 (as opposed to gnat-4 that I was using for Debian Jessie) the first test of Ada has been a complete success. See commit 994723471 for the details of the tests I ran. Hi Jerry: I just ran into this issue for the first time for my new hardware and latest Ada/gnat (version 7.3.0) from Debian Buster (sigh). I was doing a parallel build (with -j10 for my new system with 8 real cores), when the following error was encountered: ./plplot_standard.o: file not recognized: File truncated collect2: error: ld returned 1 exit status gnatlink-7: error when calling /usr/bin/gcc-7 gnatmake: *** link failed. examples/ada/CMakeFiles/xstandard30a.dir/build.make:77: recipe for target 'examples/ada/xstandard30a' failed make[3]: *** [examples/ada/xstandard30a] Error 4 A google search found <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857831> which appears to be a similar (or the same bug) for 7.1. At the time, the Debian packagers thought they had a fix, but it seems from my experience either that was not true or else the fix has not been propagated to 7.3. I have just now privately reported the situation to Matthias Klose (the author of the bug 857831 report, and they guy who decided that bug was fixed), and we will see what he says. But to work around this problem until it is fixed for Debian Buster, I plan to use -DENABLE_ada=OFF for my testing. To Jerry and Arjen: On Sunday (just before commit 7ec926fae) I discovered that my installs of gdc-7 and gnat-7 were probably not good choices because although I had both gcc-7 and gcc-8 installed, PLplot was being built with gcc-8 rather than gcc-7 on my Debian Buster system. So in this case at least Debian does not have tight version consistency requirements between either gdc or gnat and gcc. And perhaps that is justified since previously I was getting perfect results with the combination of gdc-7 and gcc-8. However, the above parallel build issue with gnat-7 encouraged me to try gnat-8, and I decided to install gdc-8 as well just to be consistent with gcc-8. It turns out (see the above commit message for the details) the combination of gdc-8, gnatmake-8, and gcc-8 produces perfect massively (-j10) parallel build and test results for a comprehensive set of of configurations and build trees, and for three different CMake versions. So it seems once again that on Linux at least, parallel builds of our Ada bindings and examples work well, and I advise on other platforms to avoid gnat-7 in all cases, to use parallel builds with caution, and at least for the sake of consistency use the same version of gdc, gnat, and gcc (e.g., gdc-8, gnat-8, and gcc-8). 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] Recent bump of CMake minimum version
Hi Arjen: For your information I have recently obtained perfect (no configure, build, or install issues, and perfect PostScript difference reports) comprehensive test results for the noninteractive case for CMake versions 3.7.2, 3.11.0, and 3.12.2. I have also bumped the CMake minimum version from 3.6.2 for all platforms to 3.7.2 for the Linux platform and 3.11.0 for all other platforms. The principal positive impact of this change is to reduce our exposure to bugs which occur in older CMake versions (especially for non-Linux platforms). But for Cygwin users like you, the negative impact of this change is that you will have to build your own CMake with version >= 3.11.0 before you can build PLplot. I am sorry about that inconvenience for you and other Cygwin users, but this situation is due to the CMake package on Cygwin being unmaintained since the date some time ago when CMake version 3.6.2 was released. So perhaps the way to resolve this issue is to volunteer on the Cygwin list to maintain that Cygwin CMake package 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.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] Installed version of PLplot working again!
least December or possibly into early 2019. However, if someone here has a strong preference for an earlier release than that sort of time scale, I would certainly be willing to consider that possibility by dropping some of the topics I want to work on before the release. 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 __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave
On 2018-08-13 08:41- Arjen Markus wrote: Hi Alan, However, I hope those comments (such as the possibility mentioned above of building an octave MinGW-w64/MSYS2 package for yourself using the pacman packaging information at <https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg>) are still of some use to you. I have tried to build Octave under MinGW-w64/MSYS2 using that webpage. However: - I had to remove the references to the patches, as these do not seem to be available. No idea what the effect is - The build failed on a mismatch in the checksums: $ makepkg -sCLf ==> Making package: mingw-w64-octave-hg r19590.6d75f1683ce8-1 (Sun, Aug 12, 2018 15:56:07) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Updating gnulib git repo... Fetching origin -> Found tip.tar.bz2 ==> ERROR: Integrity checks (sha256) differ in size from the source array. This is the point where I stopped. I have no clue as to whether this is a serious issue or not. Let's ignore octave for a bit and look at the more general picture. If you like the goal (in its own right) of learning to build packages for the MinGW-w64/MSYS2 platform, then I suggest you follow the package build documentation examples under the heading "Re-building a package" at <https://github.com/msys2/msys2/wiki/Creating-packages>. Can you use those steps to build both their examples (flex and python3)? If not, then you should take the problem to the MSYS2 mailing list to get help with that documentation. But if that general procedure works for you, then the next obvious step is to help out with the PLplot packaging at <https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-plplot> by first building that package as is, fixing it according to your own experience (e.g., by moving to Python 3, and by enabling qt), and drawing Alex's attention to your improvements (likely via a pull request) so they will be made part of the official Plplot package for this platform. Moving back to the octave case, I am pretty sure unless that semi-official package is completely broken, that the same procedures used to build flex, python3, and PLplot should also work fine for octave without all the issues you encountered above. Assuming you can build that octave package, then the next steps would be to evaluate the result for our needs, and assuming it does work for those needs (or can easily be fixed), advocate making it an official package that the PLplot package depends on. I guess an alternative could be to simply build Octave and install it without pacman, but I have not tried that yet. I would advise against that since unofficial octave builds are not going to help our octave users that much on this particular platform and may turn out to be a black hole sucking up a lot of your time. Instead, I think it would be better in the long-run to help get an official octave package running for this platform as I have outlined 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 __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave
On 2018-08-07 06:37- Arjen Markus wrote: Hi Alan, I can confirm clean test results for Octave 4.2.2 on Cygwin - I cannot do the same for MinGW-w64/MSYS2 as that does not provide an octave package as far as I can tell. There is an Octave pacakge on github (https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg) but its status is completely unclear to me. As is how it should be installed (pacman does not recognise it) Hi Arjen: Thanks for that confirmation on Cygwin. That is the first time in a long time (if ever?) that octave has worked on that platform for us which I regard as a big step forward. And as far as MinGW-w64/MSYS2 is concerned, my guess is the information at <https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg> is for a pacman package for octave that has not matured yet so the package build results are not included in the official pacman packages for MinGW-w64/MSYS2. But the small part of that package that we use for our octave binding build and tests might work well. So if you want to follow up further, I suggest you build the pacman package for octave following the cookbook located at <https://github.com/msys2/msys2/wiki/Creating-packages>. As you know, my long-term dream has been to use Wine to help you out more with both Cygwin and MinGW-w64/MSYS2 testing so recently I looked into that again. But currently it does not look good. For example, both Cygwin and MinGW-w64/MSYS2 upgraded from Windows XP to Windows Vista functionality a couple of years back, but according to discussion at <https://github.com/Alexpux/MSYS2-packages/issues/682> Wine has a lot of missing Vista functionality that has to be implemented before either of those two distributions will work on Wine again. So until that happens, I am limited to just commenting from the sidelines concerning those distributions. However, I hope those comments (such as the possibility mentioned above of building an octave MinGW-w64/MSYS2 package for yourself using the pacman packaging information at <https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg>) are still of some use to you. 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 __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave
On 2018-07-31 21:10-0700 Alan W. Irwin wrote: To Orion and Arjen: As of <https://sourceforge.net/p/plplot/plplot/ci/d7310aa9864ce1676177f39323c9daf593ae0765/> our octave binding and all examples/octave/x??c.m examples give a perfect PostScript difference report for Octave 4.4.0 for Debian Buster == Debian Testing. Please do equivalent checks (i.e., by simply building the test_noninteractive target in the build tree) for Cygwin, MinGW-w64/MSYS2, and Fedora to check all is well on platforms other than Debian Buster. I emphasize build-tree checks because install-tree checks currently won't work [] That request for testing help still applies, but I can now report (see the log for commit 391ec0ad0 for the details) that I have been able to replace the cellstr-based workaround with an actual fix for the issue which should work for late octave-3 as well as all versions of octave-4. 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 __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave
To Orion and Arjen: As of <https://sourceforge.net/p/plplot/plplot/ci/d7310aa9864ce1676177f39323c9daf593ae0765/> our octave binding and all examples/octave/x??c.m examples give a perfect PostScript difference report for Octave 4.4.0 for Debian Buster == Debian Testing. Please do equivalent checks (i.e., by simply building the test_noninteractive target in the build tree) for Cygwin, MinGW-w64/MSYS2, and Fedora to check all is well on platforms other than Debian Buster. I emphasize build-tree checks because install-tree checks currently won't work until I finish another project that was half-completed when I discovered the octave-4 cell array workaround described below. The way I got the previously dropped octave examples 26 and 33 to work was to use cell arrays at those points in the examples where Octave non-cell arrays were not working due to an upstream bug in Octave 4.4 for the transformation method used to determine C strings from an Octave non-cell array of strings. For a long time I thought the issue was UTF-8, but I discovered when testing the recent commit that pure ascii strings could also cause issues. Since that commit I have discovered (with my hex_print private test project) the issue is a simple one which is the transformation method that used to work fine for octave 3.8 no longer works for octave-4.4 *if* there are more than 15 bytes in the character strings in the non-cell arrays. (Of course, UTF-8 strings tend to have more bytes which is why they tend to expose this upstream bug more than ascii strings, but with hex_print I found in every case whether using the ascii subset of UTF-8 or more general UTF-8 strings that short strings worked, but when the number of bytes in the Octave string (excluding the NULL byte) exceeded 15, the result was an invalid UTF-8 C string. I have just submitted this issue to the upstream octave developers (see <https://savannah.gnu.org/bugs/index.php?54415>). That bug report is based on the hex_print experience summarized above, and since that experience proves there is now an explicit length limit of 15 imposed by the octave code, the issue should be easy to find and fix (I hope). But meanwhile, the cellstr workaround in the above commit for long strings avoids this issue so with luck the PLplot testers lurking here will now get perfect octave-4 results when building the test_noninteractive target on all platforms of interest to them. Also note in the subsequent commit 95f823ec0, I have changed our octave detection method so that octave-4 is no longer a special case with warnings attached. Which finally (from the better late than never department) answers Orion's question about those warnings from long ago. :-) 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 __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] rgb colourscale interpolation
Hi Phil: I am moving this discussion to plplot-devel where it belongs. I think your backwards-incompatible changes [h,l,s ==> c1,c2,c3 changed member names] in the PLControlPt struct are likely a good idea since h,l,s was a misnomer. Nevertheless, those changes did cause important build problems in the Tk-related part of the build which I have now fixed (commit 94e2e5b01). Example 12 (which uses RGB interpolation) shows the effect of your change. The old code produced <http://plplot.org/examples-data/demo12/x12.01.png> which shows fairly discontinous colour results from 1982 to 1986, while the new code produces much smoother colour changes in that date range. So from this evidence I feel your change is a nice win. I previously said (in response to your question about how you should edit README.release): I assume you will want to insert a paragraph concerning your change in a new section 2.8 of "Improvements relative to the previous release". Also, since you changed the semantics of the two functions (although not their API) for the RGB case you should probably specifically warn the users of this forthcoming release about that semantics change by adding a one-sentence new section 1.10 in "OFFICIAL NOTICES FOR USERS" that refers to your new section 2.8 for the details. Since your backwards-incompatible API change to the PLControlPt struct is going to cause build problems (just like it did in our Tk-related code) for the minority of our users who actually use that struct in their code, you should expand that suggested single sentence in 1.10 to warn users of this specific change to PLControlPt. I look forward to your commit with the suggested changes in README.release. 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 __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Intermittent Ada example build failures are now back again
On 2018-06-09 13:30-0700 Alan W. Irwin wrote: On 2018-04-15 11:15-0700 Alan W. Irwin wrote: Hi Jerry: [...] So once this Ada build issue appeared again for me yesterday after all those previous successful hardware checks, I did a google search for the terms (without the quotes) "gnatmake intermittent build error" and found <https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=65451> which was a bug report in 2015 about intermittent Ada build issues which was immediately fixed back then. However, my gnat version (= 4.9.2) is from 2014 so I don't have that bugfix and I am pretty sure at this stage that bug 65451 is the issue that is causing the intermittent Ada build issues for me. Therefore, I plan to use the -DENABLE_ada=OFF option for my further testing until I can get access to a later version of the Ada build tools myself, and I suggest others who currently don't have access to Ada build tools with bug 65451 fixed should do the same. Just to follow up for Debian Buster with gnat-7 (as opposed to gnat-4 that I was using for Debian Jessie) the first test of Ada has been a complete success. See commit 994723471 for the details of the tests I ran. Hi Jerry: I just ran into this issue for the first time for my new hardware and latest Ada/gnat (version 7.3.0) from Debian Buster (sigh). I was doing a parallel build (with -j10 for my new system with 8 real cores), when the following error was encountered: ./plplot_standard.o: file not recognized: File truncated collect2: error: ld returned 1 exit status gnatlink-7: error when calling /usr/bin/gcc-7 gnatmake: *** link failed. examples/ada/CMakeFiles/xstandard30a.dir/build.make:77: recipe for target 'examples/ada/xstandard30a' failed make[3]: *** [examples/ada/xstandard30a] Error 4 A google search found <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857831> which appears to be a similar (or the same bug) for 7.1. At the time, the Debian packagers thought they had a fix, but it seems from my experience either that was not true or else the fix has not been propagated to 7.3. I have just now privately reported the situation to Matthias Klose (the author of the bug 857831 report, and they guy who decided that bug was fixed), and we will see what he says. But to work around this problem until it is fixed for Debian Buster, I plan to use -DENABLE_ada=OFF for my testing. 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 __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Long-standing '\0' issue fixed + development news
I am happy to report that with some help from Nils Gladitz on the
CMake list a long-standing PLplot issue where parallel builds of test
targets (e.g., test_noninteractive) had groups of ascii nul ('\0')
characters inserted into the output has now been fixed. The fix (see
the log message for commit a4bada0048 for more details) was to address
name clashes in the plplot_test test scripts that I had introduced
more than a decade (!) ago in commit 7e39e59f2b.
Other PLplot development news is I have been using my new computer
with Debian Buster installed to solve a number of issues like this
current one that I have been reminded of by my recent
test_noninteractive results in the build tree for the shared libraries
case. For example, later today I plan to make the final commit in
this series that will solve all valid warning messages that have shown
up with the latest versions (from Debian Buster) of software libraries
that PLplot depends on. I then plan to follow up by doing the same
thing for ctest, the test_interactive target, and all major
configurations and build trees covered by the comprehensive_test.sh
script. Then push upstream octave and lua to fix some obvious
upstream regressions I have discovered during these tests to achieve
on the new computer the perfect PostScript difference reports that I
was achieving on my old computer that had (very) old versions of
software libraries installed from Debian Jessie. And finally, I plan
to go back to the PLplot ToDo list I was pursuing before the advent of
this new computer interrupted everything in a good way.
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
__
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of examples/c/extXdrawable_demo.c
On 2018-06-22 08:56+0930 Jonathan Woithe wrote: Hi Alan On Wed, Jun 20, 2018 at 04:51:04PM -0700, Alan W. Irwin wrote: As far as I can tell from git log --follow examples/c/extXdrawable_demo.c Jonathan Woithe implemented that example a decade ago ... I did. The purpose of the example was to show how the external X drawable device could be used to integrate into toolkits for which there was no native PLplot device. This example is really dated because it contains calls to the GTK+ API that were already deprecated for GTK+ version 2 and non-existent for GTK+ version 3. And it is not a good idea to mix this GTK+ version 2 example with a PLplot core library that can depend directly (in the non-dynamic drivers case) on GTK+ version 3 which has long been the standard version of GTK+. So I have effectively disabled the build of examples/c/extXdrawable_demo.c in my recent commit 9893349d1. These are all valid points, and disabling the build of the code seems like a sensible step at this point. Although it hasn't been mentioned, I would be reluctant to see the example removed completely though, since it still serves to show one possible way that the External X Drawable device can be used. With that said, it would be good to update it for gtk3. I would be willing to take a look at this myself, but it might be a few months before I have the time to do so due to an elevated workload. I am by no means an expert on gtk but I might be able to get something functional happening. It's also worth noting that there was nothing special about choosing gtk for this demo. At the time I was working on an internal company tool which needed to plot data in a GUI context. It was a simple program and it ended up using gtk (Qt wasn't an option at that point for various unrelated reasons). Since the demo came out of that work, the demo ended up using gtk. Feel free to ping me in about 3 months if you haven't heard from me by then. Hi Jonathan: I was glad to see that you are still lurking on the PLplot devel list and also willing to take a look at updating/replacing this example later on when you anticipate more free time to work on this topic. From what you have said, it appears this "external X" method should transcend individual toolkits. So any toolkit (e.g., Qt5 or GTK+ version 3) you decide to use in an implementation of a modern "external X" example would be fine and also feel free to implement this example in whichever of the C or C++ languages you prefer for the task. When the time comes I encourage you to call on me for any PLplot build/test system help that you might need to integrate your work into PLplot. 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 __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Status of examples/c/extXdrawable_demo.c
Hi Hazen: As far as I can tell from git log --follow examples/c/extXdrawable_demo.c Jonathan Woithe implemented that example a decade ago, you did the actual commit, and we have been (minimally) maintaining it ever since. This example is really dated because it contains calls to the GTK+ API that were already deprecated for GTK+ version 2 and non-existent for GTK+ version 3. And it is not a good idea to mix this GTK+ version 2 example with a PLplot core library that can depend directly (in the non-dynamic drivers case) on GTK+ version 3 which has long been the standard version of GTK+. So I have effectively disabled the build of examples/c/extXdrawable_demo.c in my recent commit 9893349d1. I did take a look at porting this example to GTK+ version 3 following the precepts in <https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html>. For example, after PLplot was built, I built the example directly using cd examples/c gcc ../../../plplot.git/examples/c/extXdrawable_demo.c -DUSINGDLL -I/home/software/plplot/HEAD/plplot.git/include -I/home/software/plplot/HEAD/build_dir/include -I/home/software/plplot/HEAD/plplot.git/lib/qsastime -I/home/software/plplot/HEAD/build_dir/lib/qsastime -O3 -fvisibility=hidden -Wuninitialized $(pkg-config --cflags --libs gtk+-x11-2.0) ../../src/libplplot.so |& less If you try the -DGTK_DISABLE_SINGLE_INCLUDES flag that is recommended in the above URL that works, but as soon as you try the additional recommended -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED flags a whole host of issues show up, i.e., porting this example is not going to be trivial. Therefore I abandoned that idea for myself, but I encourage you to take a look at porting this example because I believe your GTK+ skills/experience are a lot more extensive than mine. 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 __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] PLplot on Debian Buster looking fairly good so far
It's a long story involving a new graphics card that I by mistake bought for my new computer. That card is only (partially) supported by the cutting-edge Linux graphics stack so the upshot is I have decided to run Debian Buster on my (new) principal computer that I use for PLplot testing. Buster is a constantly changing rolling release that stays fairly close (but likely not quite as close as Fedora and MinGW-w64/MSYS2) to the cutting edge of free software packages. So this is a huge change compared to my previous testing environment (Debian Jessie) which was at least 3 years away from the cutting edge. So by using this Debian Buster test environment I should be some help to Orion (Fedora) and Arjen (MinGW-w64/MSYS2) in changing PLplot so it will work properly with cutting-edge free software. Commit 994723471 contains the first tranche of fixes that get PLplot more-or-less working on Debian Buster (including perfect results for Ada, see my previous post to this list). See the associated commit message for all the details of what was changed, what was tested, and any remaining regressions in the configuration and test results. I want to get all these regressions fixed before the next PLplot release so that means it will likely be several more months before I can even start to plan that release. So this period continues to be an excellent opportunity for the rest of the PLplot developers to pursue the development topics that interest them. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Intermittent Ada example build failures are now gone again!
On 2018-04-15 11:15-0700 Alan W. Irwin wrote: Hi Jerry: [...] So once this Ada build issue appeared again for me yesterday after all those previous successful hardware checks, I did a google search for the terms (without the quotes) "gnatmake intermittent build error" and found <https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=65451> which was a bug report in 2015 about intermittent Ada build issues which was immediately fixed back then. However, my gnat version (= 4.9.2) is from 2014 so I don't have that bugfix and I am pretty sure at this stage that bug 65451 is the issue that is causing the intermittent Ada build issues for me. Therefore, I plan to use the -DENABLE_ada=OFF option for my further testing until I can get access to a later version of the Ada build tools myself, and I suggest others who currently don't have access to Ada build tools with bug 65451 fixed should do the same. Just to follow up for Debian Buster with gnat-7 (as opposed to gnat-4 that I was using for Debian Jessie) the first test of Ada has been a complete success. See commit 994723471 for the details of the tests I ran. Alan ______ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Intermittent Ada example build failures are now gone again!
Hi Jerry: On 2018-04-10 14:15-0700 list_em...@icloud.com wrote: Thanks for your work on trying to figure this out. I really have no idea what the problem could be. I’ve never had a problem with gnatmake but you recall a problem from the past that pretty much escapes me by now. I was referring to your attempts to get the test_ada project to work on Mac OS X. I have forgotten the details, but as I recall you never had complete success with that test. But on the other hand, the issue you discovered was consistent and that was also true for the issue that Arjen discovered for Cygwin. Therefore, it is likely the issues you guys discovered on two different platforms don't have anything in common with the issue I am dealing with. [...] I don’t know if you will find this useful, but on https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/building_executable_programs_with_gnat.html at the end of "4.1. Building with gnatmake" appears this: "Note that for advanced forms of project structure, we recommend creating a project file as explained in the GNAT_Project_Manager chapter in the GPRbuild User’s Guide, and using the gprbuild tool which supports building with project files and works similarly to gnatmake.” [...] Thanks for pointing out the gprbuild possibility. From my further reading in <https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/building_with_gprbuild.html> it appears gprbuild is designed to handle more project complexity than gnatmake, but it is not of sufficient generality to implement complete build systems like is possible with CMake. Furthermore, it appears that gprbuild does not use gnatmake but provides the same functionality at the build level, i.e., it uses the same building blocks (gcc to compile, gnatbind to bind, and gnatlink to link) that gnatmake does. Note it is the gnatlink step where the intermittent errors occur for me. So it is useful to know about the gprbuild possibility, but since CMake has everything covered at the build system level (i.e., does not need to use gprbuild) and gnatmake has everything covered at the detailed (gcc, gnatbind, and gnatlink) building block level I plan to stick with that combination. Here is some recent news about these intermittent Ada build errors. They disappeared for me for several comprehensive tests after a reboot 3 days ago, but yesterday they came back again! That is, I built the test_diff_psc target by hand from scratch and it failed due to Ada. Then I repeated the exact test again, and it succeeded with perfect (PostScript) results and no Ada build issues at all! So rebooting the system may have nothing to do with these errors. Of course, the possibility always exists that intermittent results are due to hardware issues, and the gnat building process may be particularly sensitive to such hardware issues. So after the first encounter with these intermittent Ada build failures, I did some detailed comparisions of rsync results using the --checksum option (which checked that 4 trillion bits on two rsynced disks were the same), RAM tests, disk filesystem checks, and git filesystem checks to see if any hardware issue shows up via such detailed checks, but none did. So those results pretty much restored my confidence that my hardware was fine. So once this Ada build issue appeared again for me yesterday after all those previous successful hardware checks, I did a google search for the terms (without the quotes) "gnatmake intermittent build error" and found <https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=65451> which was a bug report in 2015 about intermittent Ada build issues which was immediately fixed back then. However, my gnat version (= 4.9.2) is from 2014 so I don't have that bugfix and I am pretty sure at this stage that bug 65451 is the issue that is causing the intermittent Ada build issues for me. Therefore, I plan to use the -DENABLE_ada=OFF option for my further testing until I can get access to a later version of the Ada build tools myself, and I suggest others who currently don't have access to Ada build tools with bug 65451 fixed should do the same. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's mos
[Plplot-devel] Intermittent Ada example build failures are now gone again!
My last commit message (for commit 0df4e30) contained the following paragraph concerning intermittent Ada example build failures during various comprehensive tests that I encountered: "These checks showed intermittent failures for certain parts (xtraditional28a, xtraditional33a) of the Ada part of the build with two separate complaints about various files written by the gnat compiler. At this stage I cannot figure out the source of this issue since it comes and goes and is hard to reproduce. But at one point I got through the entire test above without Ada failures, and found an obvious issue with the static OCaml binding library which I fixed and which has absolutely nothing to do with Ada. I then tried the test above again, which failed for the nondynamic case for the build of one of the Ada examples. I then followed up by a specific static build of the ocaml binding library that exercised the fixed build-system CMake code for that case, and all was well. Therefore, I think from these piecemeal results that all is well with the current commit, but further testing needs to be done as above once I figure out the source of the intermittent Ada build errors." One possibility to explain intermittent failures like this is some hardware issue. But after the above result I hammered my box with all sorts of hardware tests which it passed with flying colours. Part of those tests involved a system reboot, and after that the comprehensive test that previously was failing in different places due to different Ada example build issues on successive runs completed with perfect results! Which is a nice result since it confirms the intrusive changes I made for commit 0df4e30 are valid. Furthermore, because the Ada results were perfect for this comprehensive test after a reboot, and many prior tests except for the ones used for this particular commit for a Linux operating system that had been up for a long time, there is a possibility that the gnatmake issue on Linux is it becomes unreliable if the Linux platform is up too long. So those good hardware tests, the good Ada example builds (and all other builds and tests) that occurred in the comprehensive test *after* a reboot, and the intermittent failures before the reboot just for this commit occurring just for Ada example builds argues strongly these intermittent failures are not due to hardware issues. So that leaves some issue with one or all of the components (gnatlink, etc.) of my system gnatmake Ada build tool or the software stack those components depend on as the likely culprit for the intermittent Ada example build failures in this case. And one possibility is the Linux kernel itself was beginning to get wonky after many days up, and gnatmake is peculiarly sensitive to such issues. Anyhow, if you combine that bad gnatmake experience on Linux with Arjen's known difficulties with gnatmake on Cygwin and Jerry's known difficulties with gnatmake on Mac OS X, I get the impression that gnatmake is pretty unreliable regardless of platform (perhaps through no fault of its own other than possibly a design that depends on the underlying operating system working perfectly). Anyhow, the observed gnatmake unreliability is something to keep in mind going forward for those of you who run into issues with gnatmake. Alan __________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Is there some important reason for using the -single-module linker option on modern Mac OS X?
To those here with knowledge of Mac OS X linking: According to <http://www.manpages.info/macosx/ld.1.html> there exists the following ld options: " -single_module When building a dynamic library build the library so that it contains only one module. -multi_module When building a dynamic library build the library so that it contains one module for each object file linked in. This is the default. " We currently use -single_module for linking on this platform (see CMAKE_USER_MAKE_RULES_OVERRIDE in the top-level CMakeLists.txt file). However that override was imposed 12 (!) years ago to address a linking issue that I suspect no longer exists. For example, a google search for the terms found nothing relevant beyond the CMake mailing-list discussion I generated about this issue back then. So unless I hear from Mac OS X experts here that there is some important reason for using the -single_module option for linking dynamic libraries on modern Mac OS X, I plan (on Sunday to give you a couple of days to respond) to drop this override completely to conform to how other CMake-based build systems configure linking of dynamic libraries on Mac OS X. Alan __________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Namespaced ALIAS library targets which are the first step in planned CMake best-practice upgrades
Recently (commit 593c07f) I have introduced namespaced ALIAS library targets (e.g., the target PLPLOT::plplot created by the add_library(PLPLOT::plplot ALIAS plplot) command where plplot is an ordinary library target created previously) into our build system, and I plan to extend their use to modules (CMake speak for dll's) as well. I am also planning to use namespaced library and module targets for our install-tree build system (by using the NAMESPACE PLPLOT:: argument of the install(EXPORT ...) command). N.B. these namespaced versions of the targets associated with our libraries and dll's are read only (i.e., you cannot change their properties). And they do not change the actual names of the associated library and dll files. But according to recent help I have gotten on the CMake mailing list, use of namespaced versions of targets for libraries and modules are considered to be CMake best practice because they make it possible to be safer when using the target_link_libraries command. For example, consider target_link_libraries(mycode.c plplot) versus target_link_libraries(mycode.c PLPLOT::plplot) The "plplot" in the former potentially could refer to the plplot target (if that exists). But if that target does not exist (because the user forgot to find the PLplot package which creates that imported target), then CMake will happily find the plplot system library (if that exists) and use that instead. Such subtle errors are not possible for the latter form since CMake recognizes that any item in target_link_libraries that has a "::" in the name must be a read-only IMPORT or ALIAS target so if that target does not exist an immediately obvious CMake error occurs which should be easy to diagnose and fix. In sum, I consider this commit to be the first in a long series trying to upgrade our build system (whose implementation style is roughly consistent with the CMake bad practices that existed a decade ago) to modern CMake best practices. For an extremely useful introduction to those good practices see the simple build-system example and associated description of it at <https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/>. That article had several examples of bad practice and the corresponding good practice. So because those bad practices occur extensively in our build system it appears that article is is going to be my build-system bible for quite some time to come! Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] -h command-line issue on Cygwin
On 2018-01-07 11:03- Arjen Markus wrote: There is a small issue though with the gfortran compiler under Cygwin. I do not understand it (*) but here is the output to screen if I use the -h option: $ ./x01f -h pl_parse_dynamic = T argv before call to plparseopts(..., PL_PARSE_SKIP) i = 0, argument = ./x01f i = 1, argument = -h /bin/sh: C:\Program: command not found This does not happen for Intel Fortran - then I get an overview of all the options that are available. (*) From a closer look at the code I think this is due to the fragment: #ifdef HAVE_POPEN FILE *pager = NULL; if ( getenv( "PAGER" ) != NULL ) pager = (FILE *) popen( "$PAGER", "w" ); if ( pager == NULL ) pager = (FILE *) popen( "more", "w" ); if ( pager != NULL ) outfile = pager; #endif It is probably trying to run a pager program like "more" but that does not quite work on Cygwin. Hi Arjen: Since both x01c and x01f have special command-line parsing, I suggest the first thing you should do is try other C and Fortran examples (e.g., x00c or x00f) to see if the -h option works in those less special cases. My guess is it won't work, i.e., the problem you discovered with the -h option on Cygwin is a general one for our standard C and Fortran examples rather than specific to just x01f. I looked up the popen man page on Linux which states it "opens a process by creating a pipe, forking, and invoking the shell". So I assume what the above code fragment does is redirect the normal output of the -h option from stdout to whatever you have specified as the PAGER environment variable or the "more" pager as a fallback if you have not specified PAGER. So I suspect what has happened on your Cygwin platform is you don't have any pager installed. You should be able to fix that by installing "more" via the "util-linux" package and/or "less" via the "less" package (while setting your PAGER environment variable to "less"). Let me know whether one or the other of those two measures fixes the above -h issue. By the way, I highly recommend "less" as a much better pager than "more". So the developers of "less" used some self-deprecating humor when they picked the name of their pager. :-) Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran
On 2018-01-07 11:03- Arjen Markus wrote: I can now confirm that it [running examples/fortran/x01f built with local change pl_parse_dynamic = .true.] works for both compilers. Excellent. Now that you have confirmed the "_dynamic" versions of plget_arguments and plparseopts work with modern versions of gfortran and ifort, I will encourage others with access to other Fortran compilers to try this test as well. Alan ______ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran
On 2018-01-05 08:09- Arjen Markus wrote: First the C example: "x01c -dev wingcc" complains that I did not give the value for the -dev option. If I give other options like "a b c", I get complaints that these are unknown. If I run "x02c -dev wingcc", all works as usual. $ ./x01c -dev wingcc Argument missing for -dev option. Hi Arjen: I have responded already to your fortran report with a bug fix, but I respond here also to the above C issue you discovered. I get a similar error for examples/c/x01c -dev xwin but not for the valgrind-clean variant I checked before examples/c/x01c -dev psc -o test.psc I have no idea why the former form does not work while the latter form works perfectly in all regards, but I will definitely look into this weird difference between these two different parsing results. Alan ______ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran
On 2018-01-05 13:38- Arjen Markus wrote: [...] That [extra printouts of locations reached] limits the possibilities considerably ;). I have narrowed it further to the call of max_cstring_length, but of course this is merely the location where it is noted something is wrong, not necessarily the cause. Hi Arjen: Your experiments appear to have nailed exactly where the issue was. So much thanks for that work! As a direct result of that work I discovered I had forgotten an essential slice specification in the call to max_cstring_length which I have now fixed (commit 70ec495). As a result my strong expectation is your next test of Fortran example 1 for the allocated length and size case will give perfect results for both modern gfortran and ifort. By the way, this fix has nothing to do with the gfortran-4.9.2 issue where the allocate length and size command in plget_arguments_dynamic (that already works for your modern gfortran and ifort cases) overflows when doing a simple internal calculation of the amount of memory needed. I double-checked with gdb that the length and size are properly defined for that allocate command. Therefore my conclusion must be that gfortran-4.9.2 is just plain broken for such allocate commands (while your ifort and more modern gfortran are obviously not broken in this regard). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran
On 2018-01-03 13:28- Arjen Markus wrote: -Original Message- From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] This commit completes my parsing API changes in bindings/fortran/*.f90 and my changes to examples/fortran/x01f.f90 to test all of these parsing API's. I would appreciate your review of my implementation. Furthermore, I would appreciate you following the parsing testing advice in README.release section 2.7.2 to discover which parts of this API work for gfortran with version > 4.9.2 (e.g., for your Cygwin and MinGW-w64/MSYS2 platforms) as well as the ifort compiler you have access to (and possibly the nagfor compiler you have arranged access to in the past). By the way, I am not sure of the correct terminology for character arrays that have both length and size allocated. I refer to them above as "dynamic length and size", but I have also seen the term "deferred-length" used for character strings with allocated length. Unless I am mistaken the official term is deferred-length. I have not yet tested this with my compilers, but I have reviewed the implementation. I have very few comments about it: -It is a pity that we cannot disambiguate on the deferred/assumed length alone, but that is an issue of the language rules (the type of "assumed-length character string" simply encompasses the type of "deferred-length character string". Elaborate workaround might be possible, using classes/derived types, but that is not worth the trouble I think). -If we decide at some point that we need to keep the various implementations, then perhaps we could "layer" the versions: o The deferred-length variant can call the assumed-length + allocated size variant o This can in turn call the fixed size variant It would reduce the amount of code, by a small amount of source lines. But again, that may not be worth our while. I should have time to test the implementation tomorrow. Maybe that will bring out more comments ;). Thanks for your review of the code and your comments above based on that review. With regard to the "layering" idea, I would like to keep the 3 variants completely independent of each other because the deferred-length + allocated size variant is preferred and the assumed-length + allocated size and the assumed-length + assumed size variants are deprecated. Furthermore, I agree the required disambiguate parameter on the assumed-length + allocated size variant is a "wart" for that variant, but I don't think we need to be too concerned about that wart since it is a deprecated variant. I did look at <https://www.fortranplus.co.uk/app/download/23704631/fortran_2003_2008_compiler_support.pdf> and support for "allocatable character length" (what we now call deferred-length character) is pretty widespread (e.g., gfortran-5.2, ifort 17.0, and nagfor 6.1 and above) so I am pretty sure your tests tomorrow of the modern gfortran and ifort cases (and presumably your eventual test of nagfor) as well as my eventual (once I install Debian Stretch with gfortran-6.3.0) test of modern gfortran will all go well. That said, one notable (because they feature PLplot capability) holdout is Absoft where the box in the above PDF is blank indicating support for this important Fortran 2003 feature is unknown. Absoft do claim they support "essentially all" of Fortran 2003 so that is a good sign, but a site:www.absoft.com google search showed no mention of "character(len=:)" or "deferred length" or "allocatable length" so that is a bad sign. Anyhow, I plan to reestablish contact with Absoft (assuming you can demonstrate good test results of the deferred-length + allocated size variant for modern gfortran and ifort) and ask them to do the same test you are doing and temporarily keep or throw away the deprecated versions of the above API before the release depending on those results. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran
On 2017-12-27 14:26-0800 Alan W. Irwin wrote: Hi Arjen: I have done some further investigation and it appears that even today allocatable character arrays are problematic to a certain extent for Fortran compilers. For example, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945>. I have no clue whether that particular modern gfortran bug would affect us. However, the existence of such bug reports for a modern version of a Fortran compiler indicates we should proceed with caution with allocatable character arrays. Therefore, once we implement allocatable character array variants of plget_arguments and plparseopts we should survey the modern versions of gfortran, ifort, and nagfor to see which of those work well with that API. Also we will likely want to retain the the current static assumed shape character arrays API's for those functions for a while so that users with access only to older Fortran compilers (e.g., gfortran-4.9.2) that are unreliable with the allocatable character array approach have a plget_arguments and plparseopts API that they can use. Hi Arjen: I have just pushed commit 6f2f4e4 to master which implements dynamic length and size as well as static length and dynamic size variants of plget_arguments and plparseopts. The former does not work with gfortran-4.9.2, but the latter (as well as the static length and size variants implemented before) works well. For more details about how these tests should be done and results for gfortran-4.9.2, please see the revised version of README.release section 2.7.2. This commit completes my parsing API changes in bindings/fortran/*.f90 and my changes to examples/fortran/x01f.f90 to test all of these parsing API's. I would appreciate your review of my implementation. Furthermore, I would appreciate you following the parsing testing advice in README.release section 2.7.2 to discover which parts of this API work for gfortran with version > 4.9.2 (e.g., for your Cygwin and MinGW-w64/MSYS2 platforms) as well as the ifort compiler you have access to (and possibly the nagfor compiler you have arranged access to in the past). By the way, I am not sure of the correct terminology for character arrays that have both length and size allocated. I refer to them above as "dynamic length and size", but I have also seen the term "deferred-length" used for character strings with allocated length. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] qhull import library and corresponding dll missing for MinGW-w64/MSYS2
On 2017-12-30 22:10-0800 Greg Jung wrote: I also found, although it isn't important for me downstream, that my QHULL installation was not found correctly. I checked where they were to be found, here is a partial listing of that: $ cat local/mingw-w64-i686-qhull-git-r157.f0bd8ce-1/files [...] Hi Greg: Thanks for that report of your qhull find troubles on the MinGW-w64/MSYS platform. The rest of this is addressed to Arjen (or anyone else here with interest in the important qhull component of our plgriddata API on that platform) because I think he is going to encounter those same troubles soon. @Arjen: Your latest latest (2017-08-17) successful test of the mingw64 version of MinGW-w64/MSYS2 shows the following qhull-related find results: -- Found QHULL: D:/mingw64-2/mingw64/include -- QHULL_INCLUDE_DIRS = D:/mingw64-2/mingw64/include -- HAS_LIBQHULL_INCLUDE = OFF -- QHULL_LIBRARIES = D:/mingw64-2/mingw64/lib/libqhull.dll.a -- QHULL_RPATH = So all *was* well in that case. However, it appears there is qhull trouble ahead for you just like Greg has encountered. Note that the above import library and corresponding dll is available for both <http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-qhull-git-r113.60d5581-3-any.pkg.tar.xz> and <http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-qhull-git-r151.5bbc756-1-any.pkg.tar.xz>, but they are not available for the latest version, <http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-qhull-git-r157.f0bd8ce-1-any.pkg.tar.xz>. and the corresponding latest 32-bit version, <http://repo.msys2.org/mingw/i686/mingw-w64-i686-qhull-git-r157.f0bd8ce-1-any.pkg.tar.xz> that Greg used. So when you update to that latest 64-bit version of the qhull library for MinGW-w64/MSYS2 I assume you will run into the same issue that Greg has encountered, and when that occurs you should follow up with an error report to the MSYS2 list concerning that missing import library and dll situation for their latest qhull package. Alan __________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran
On 2017-12-27 09:02- Arjen Markus wrote: I am currently catching up with my e-mail (Christmas is a busy time ...), so this is the first opportunity I have found to respond to your mails. Sure, I will have a look at this. (I even have a generic solution for this type of programming problem, but it may not be better than yours ;) - I respond before having seen it.) Hi Arjen: I have done some further investigation and it appears that even today allocatable character arrays are problematic to a certain extent for Fortran compilers. For example, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945>. I have no clue whether that particular modern gfortran bug would affect us. However, the existence of such bug reports for a modern version of a Fortran compiler indicates we should proceed with caution with allocatable character arrays. Therefore, once we implement allocatable character array variants of plget_arguments and plparseopts we should survey the modern versions of gfortran, ifort, and nagfor to see which of those work well with that API. Also we will likely want to retain the the current static assumed shape character arrays API's for those functions for a while so that users with access only to older Fortran compilers (e.g., gfortran-4.9.2) that are unreliable with the allocatable character array approach have a plget_arguments and plparseopts API that they can use. By the way, I am already using this new Fortran parsing feature in one of my te_gen examples where the command-line has a mixture of PLplot options and a file name, e.g., software@raven> examples/f95/test_asteroids \ -dev psc -o test.psc \ /home/software/time_ephemeris/HEAD/asteroid_ephemerides/ephcom_binary_ast343de430 where that last command-line option (although it could have been anywhere on the command line) is obviously not relevant to PLplot. After calling plget_arguments(nargv, argv) to get the nargv and argv corresponding to that command-line, that example then calls plparseopts(nargv, argv, PL_PARSE_SKIP) which parses all the command-line options that are relevant to PLplot and removes them from argv. The result is plparseopts returns nargv = 1 and argv(1) equal to the asteroid ephemeris filename specified on the command line. The example then opens that ephemeris file and uses it to help calculate the many asteroid results that are plotted by that example. Alan ______ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Command-line parsing improvements for both C and Fortran
Hi Arjen: I have just finished (commit 71944db) implementing the C and Fortran command-line parsing improvements that I first brought up with you (off-list) just a few days ago. Please see the revised version of README.release for the details concerning these changes. Since your modern Fortran experience is more extensive than mine, and I felt right on the edge of the limit of my own modern Fortran expertise when implementing this, I would appreciate you reviewing the Fortran part of this topic, for substance (should it work perfectly in all cases), standards-compliance (i.e., should it work for nagfor), and overall style. On that style point, in the new function c_to_character_array that appears in bindings/fortran/plplot_small_modules.f90 I implemented do i_local = 1, length_column_local character_array(j_local)(i_local:i_local) = string_ptr(i_local) enddo to copy from a pointer vector of size length_column_local one-byte characters to character_array(j_local), an element of a character array whose length is the same as the string_ptr size. Is there a more modern Fortran method of implementing the equivalent of this loop with just one assignment statement or are we stuck with this do-loop style? One caveat I discussed in README.release with the present parsing-related additions to the Fortran API is that API needs to be converted from the present assumed shape character arrays to allocatable character arrays to simplify the arguments and reduce the necessary size checking required with the present static array approach. But I am holding off from doing that change because allocatable character arrays are not reliable on my present Debian Jessie (gfortran-4.9.2) platform. For example, this simple test code, irwin@raven> cat test_allocatable_character_arrays.f c test of allocatable character arrays character(len=100), dimension(10) :: argv_array ! character(len=:), dimension(:), allocatable :: argv_array ! allocate(character(len=100) :: argv_array(10)) argv_array(5)(1:10) = "hello, world" write(*,'(a)') argv_array(5)(1:10) end works fine as is on my platform, i.e. has perfect Valgrind results (0 errors, no leaks are possible). However, if you comment the second line and uncomment the 3rd and 4th lines to change this from a static character array test to an allocatable character array test, it spectacularly fails (outputs gibberish) and valgrind also shows all sorts of memory management issues. Would you be willing to build and run both versions of the above test code on Cygwin (with gfortran-6.4.0) to make sure no obvious problems occur with that gfortran version? If your tests indicate no such problems then I would encourage you to try updating the API to the allocatable version as indicated in README.release, and test that change as indicated there as well. But if you don't have time for that just now, I plan to make the change myself just as soon as I upgrade to Debian Stretch. I am assuming here (especially if you get good results for the above test) that gfortran-6.3.0 that comes with that platform will have no trouble with the above simple example and also the allocatable version of the new code. Merry Christmas to you, your family, and all others interested in PLplot that are lurking here on this list! Alan __________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] libieee.a is no more
On 2017-12-12 17:36-0700 Orion Poplawski wrote:
Sorry I wasn't clear. The test was failing because of the compile error.
With the patch the test returns "found" and the build is normal/successful.
Hi Orion:
Thanks for that key clarification. Based on that good news for gcc
NaN awareness with no special options on i686 hardware, I have made a
slightly more conservative upstream change then your patch (just in
case there is any non-gcc i*86 cases where the -mieee-fp compiler
option builds and is still required for the NaN awareness test to
still work). See
<https://sourceforge.net/p/plplot/plplot/ci/5c628406e9a1c941dbe34d3db056f985e1ec8b08>
for details. For your pure gcc case, your patch and the git master upstream
version, i.e.,
[...]
if(CMAKE_SYSTEM_PROCESSOR MATCHES "i[0-9]86" AND NOT CMAKE_C_COMPILER MATCHES
"gcc")
set(NAN_CFLAGS "${NAN_CFLAGS} -mieee-fp")
elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "alpha.*")
if(CMAKE_C_COMPILER MATCHES "gcc")
set(NAN_CFLAGS "${NAN_CFLAGS} -mieee")
else(CMAKE_C_COMPILER MATCHES "gcc")
set(NAN_CFLAGS "${NAN_CFLAGS} -ieee")
endif(CMAKE_C_COMPILER MATCHES "gcc")
endif(CMAKE_SYSTEM_PROCESSOR MATCHES "i[0-9]86" AND NOT CMAKE_C_COMPILER MATCHES
"gcc")
[...]
should give the same result (no -mieee-fp option used for gcc
on i*86). The git master version should become the basis of a PLplot release
in early 2018.
Thanks once again for your key help with PLplot for the cutting-edge versions of
Linux system software that you get with Fedora.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] libieee.a is no more
On 2017-12-12 15:36-0700 Orion Poplawski wrote: Apparently glibc is dropping libieee.a in the next release. In Fedora Rawhide, -mieee-fp on i686 results in: /usr/bin/ld: Cannot find -lieee Dropping -mieee-fp from csiro.cmake fixes it for me. Hi Orion: For i686 hardware and your patched case, what is the result of the test? In other words, does the CMake output say "Check for NaN awareness in C compiler - found" or "Check for NaN awareness in C compiler - not found" followed by WARNING: Setting PL_HAVE_QHULL and WITH_CSA to OFF. ? The latter result is a fairly serious constraint on our plgrid function for i686 hardware. So I am hoping for the former result since that simply means the gcc option -mieee-fp is no longer required to get this NaN test to work correctly on i686 hardware. Alan __________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] We now have a clean PostScript difference report!
On 2017-12-09 11:18-0800 Alan W. Irwin wrote: I am happy to report I have just solved the long-standing inconsistency between OCaml example 16 results and the results from other languages. See commit 35eafc1 for details. This breakthrough means that an absolutely perfect PostScript difference report is finally within our grasp again after ~6 years without that. "All" that needs to be done is to implement the color bar parts of example 33 in OCaml. I will take responsibility for that implementation. DONE. See <https://sourceforge.net/p/plplot/plplot/ci/a7be76715300e829523be309c64d99b1b28c1bcc/> and the updated version of README.release for the details. In sum, we now have a clean PostScript difference report for the first time in many years (i.e., the standard examples written in all our supported languages give the same PostScript results for all those languages), and I am happy I was able to learn enough about our OCaml binding implementation and the language itself to fix this long-standing issue. Alan __________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Long-standing OCaml example 16 inconsistency solved
I am happy to report I have just solved the long-standing inconsistency between OCaml example 16 results and the results from other languages. See commit 35eafc1 for details. This breakthrough means that an absolutely perfect PostScript difference report is finally within our grasp again after ~6 years without that. "All" that needs to be done is to implement the color bar parts of example 33 in OCaml. I will take responsibility for that implementation. Alan ______ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Patch for OCaml 4.06
On 2017-11-20 09:02-0700 Orion Poplawski wrote: Fedora patch to fix build with OCaml 4.0.6. Hi Orion: I assume you meant 4.06.0 (see the list of releases at <https://ocaml.org/releases/>). Thanks (!) for your fix for this backwards-incompatible change to OCaml. However, I am going to delay applying your fix because it breaks my build of examples/ocaml/x20.ml for my (Debian Jessie) ocaml-4.01.0. The problem (according to <https://stackoverflow.com/questions/30887196/install-ocaml-bytes-module-on-debian>) is the Bytes module (used by your patch) was first introduced in OCaml 4.02.0 so it is not avaliable for Debian Jessie. I have put on my PLplot ToDo list (which I review for each PLplot release) to upgrade from my current Debian Jessie to Debian Stretch = Stable, apply your patch, and put in the release notes that we only support OCaml 4.02.3 (the version available for Debian Stretch) or higher. I plan to do that Debian update soon, and if all goes well with that update your fix should be part of the next release of PLplot (tentatively scheduled for early 2018). Best wishes, Alan __________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] The Contracts.PLplot test of CMake has now been implemented and works well for me
CMake, don't hesitate to get in touch with me. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Forwarded message -- Date: Thu, 9 Nov 2017 21:40:36 -0800 (PST) From: Alan W. Irwin To: Brad King , Ben Boeckel , cmake-develop...@cmake.org Subject: Re: [cmake-developers] PLplot contract test On 2017-11-08 18:00-0800 Alan W. Irwin wrote: [...] Changing topics back to the Nightly case where the job is started in a crontab environment rather than on the normal desktop command line as above, further research indicates it is possible to set DISPLAY for such environments (assuming that DISPLAY exists at the time the crontab job fires as is typical for my case). So I am going to try that to see if that change plus the above setting of XAUTHORITY solves the Nightly issue as well. Thanks to that crontab change to define the DISPLAY environment variable, all is now well with the Nightly case, see <https://open.cdash.org/testDetails.php?test=598968882&build=5135648>. So that appears to be the end of the configuration issues with the Contracts.PLplot test, and my thanks to Brad for implementing this test in the first place, and both Brad and Ben for some key help with my configuration of this test. So for others here that might be interested, Contracts.PLplot tests a build of the stage/master/nightly/latest branch of CMake by using ExternalProject_Add to git checkout a specified version of PLplot and to configure, build, and install that version with user control of the PLplot version selected for the test and the CMake options used to build PLplot. So this test is good from the PLplot perspective because it makes it more difficult for some new CMake development to cause PLplot developers problems without us knowing it long in advance of CMake releases. And it is also good from the CMake testing perspective since it is a test that exercises a lot of different CMake functionality in a realistic way (i.e., as used in a rather complex build system, warts and all). Additional notes are (1) because of the relatively small size of the PLplot project (despite its build-system complexity) this test adds less than ~30 per cent to the overall cost of building and testing CMake, and (2) this test should work on essentially all platforms (the build of PLplot is known to work on at least Linux, Mac OS X, Cygwin, MinGW-w64/MSYS2, and MSVC). So if anyone else is interested in trying this test on their favorite platform(s), feel free to contact me for help with configuring it and overcoming any PLplot build failures in the unlikely event of you encountering those. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers my_dashboard.cmake.gz Description: compressed dashboard script which configures the Contracts.PLplot test of CMake -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)
On 2017-11-08 07:49- Arjen Markus wrote: Hi Alan, -Original Message- From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] Sent: Tuesday, November 07, 2017 11:20 PM Hi Arjen: To clean up some preliminary stuff, please don't set GNAT_LIB unless absolutely necessary. Specifying that variable is a workaround that bypasses all testing of the find_library command (see <https://cmake.org/cmake/help/v3.10/command/find_library.html> for why that is so. Oh, that was a stupid mistake - too many little tasks clogging my head and thus I simply followed the advice from the error message: an unaided "comprehensive_test_ada.sh" does not find the Gnat library. With CMAKE_LIBRARY_PATH set to the right directory the test does succeed but fails in the same way as before. So the CMake build script finds the proper library, but there is something going on with the library itself. I agree with that general conclusion based on what I see in your report tarball for this shared case. But I would add that the fundamental run time error you are seeing is raised PROGRAM_ERROR : EXCEPTION_ACCESS_VIOLATION for the hello.exe that is built from the installed example source code. And for me any error message that mentions "access violation" in any way likely means there is a memory management issue. So I think the most obvious next step is to run a memory management analysis tool like valgrind (although not that exact tool since it apparently does not work on Windows platforms) on the hello.exe executables that are built in the build tree and the install tree. I have attached two tarballs: one with only the CMAKE_LIBRARY_PATH set and one excluding the shared build, leaving the static case. This fails on account of duplicate symbols again. I also looked at that additional report tarball, and the build system has done everything in the static case that I thought it should do, i.e., always link with import form of the gnat library regardless of whether the test_ada Ada library is built as a shared library (which builds without issues from your other report tarball) or as a static library (this case which you have just showed obviously does not build correctly). So please follow up by using GNAT_LIB in this emergency situation for the static case to specify libgnat.a, and let me know those results to help guide me toward the correct find_library configuration for the normal case where CMAKE_LIBRARY_PATH is specified on Cygwin. No time right now to look into your other suggestions. I promise to be patient. And in any case I think we are headed toward preparing a bug report for the Ada components of the gcc toolchain on Cygwin. So patience is needed in any case because that bug (once we isolate it for the simplest case possible and prepare the bug report) is likely going to take some time for the Cygwin gcc package maintainers or possibly even the upstream Ada compiler developers to fix. Nevertheless, even though I think we are likely stuck in a long process, I would like to continue moving forward with that process without too many inefficient long gaps. So the next chance you have to work on PLplot I would appreciate it if you followed up with this issue in the two ways I have suggested above. Alan ______ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)
valgrind shared/noninteractive/install_build_tree/ada/hello ==26390== Memcheck, a memory error detector ==26390== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==26390== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==26390== Command: shared/noninteractive/install_build_tree/ada/hello ==26390== ==26390== ==26390== HEAP SUMMARY: ==26390== in use at exit: 0 bytes in 0 blocks ==26390== total heap usage: 4 allocs, 4 frees, 740 bytes allocated ==26390== ==26390== All heap blocks were freed -- no leaks are possible ==26390== ==26390== For counts of detected and suppressed errors, rerun with: -v ==26390== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) As you can see, there are perfect memory management results on Linux for both these cases. Therefore, since test_ada is so simple, I am beginning to lean toward an explanation that there is something fundamentally wrong with the Ada component of the gcc tool chain on Cygwin. To test that hypothesis further is there an equivalent to valgrind (see <https://stackoverflow.com/questions/413477/is-there-a-good-valgrind-substitute-for-windows> for some ideas) that you could run? And if you do find a memory management issue on Cygwin that way, could you also try the same tool on the simplest shared gnatmake example I asked you to build the other day? That would be the first step in preparing a bug report to the Cygwin mailing list concerning the Ada component of the gcc tool chain based not on test_ada but on that even simpler shared gnatmake example. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)
On 2017-11-07 08:34- Arjen Markus wrote: Hi Alan, -Original Message- From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] Sent: Friday, November 03, 2017 8:37 PM When you get a chance please commit this change on a local topic branch using "git am" and try it out on Cygwin using cmake/test_ada/scripts/comprehensive_test.sh I applied the patch and got some encouraging results: - With -DCMAKE_LIBRARY_PATH=/path/to/ada-libraries I go the same errors as before - With -DGNAT_LIB=/path/and/name/of/import-library I got - finally - working Ada examples. Both the standard and traditional versions work fine. It appears from your last comment that you have been testing the plplot project. Those do sound like promising results, but they are premature. The present patch was limited to just the test_ada project. So to test that patch you need to follow my test instructions above. Likely you will have to set CMAKE_LIBRARY_PATH to the location of the import library to get that comprehensive test (of test_ada) to work. Once you have complete success with the test_ada project, than I will want to make a similar change to the PLplot project, but I haven't done that yet. Alan ______ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)
On 2017-11-03 11:52- Arjen Markus wrote:
Yes, I saw it [new Ada packaging for Cygwin] and I have updated my
installation.
Good.
I see the import library now, but my very preliminary
tests (test_ada and a simple build) have failed so far:
- test_ada does not produce an executable - see the tarball (sorry,
output to the screen is missing, but there was nothing much to see
anyway).
- a simple build finds the static library and then the duplicate
symbols problem is back.
I guess PLplot needs to be told to use the import library before
trying the static one. I have not had time yet to do the manual steps
that you suggest.
On Linux I have tried the experiment of forcing the shared
or static versions of gnat lib as follows:
-DGNAT_LIB=/usr/lib/gcc/x86_64-linux-gnu/4.9/adalib/libgnat.so
or
-DGNAT_LIB=/usr/lib/gcc/x86_64-linux-gnu/4.9/adalib/libgnat.a
The shared version (equivalent to the import library version for
you) works both with -DBUILD_SHARED_LIBS=ON or OFF. (N.B.
-DBUILD_SHARED_LIBS affects only how our Ada library is built
and does not affect how that library and our
Ada executables are linked to external libraries such as gnat.)
The static version of the gnat library only works for the
-DBUILD_SHARED_LIB=OFF case. (The Linux issue for the
-DBUILD_SHARED_LIB=ON case is libgnat.a was built without the -fPIC
flag, but I presume there are similar compilation flag issues when
attempting to use libgnat.a for -DBUILD_SHARED_LIB=ON on Cygwin that
cause the duplicate symbols issue you see there.)
So I agree with you we should likely be fine if we always find the shared
version of the gnat
library on Linux and the import version of the gnat library on Cygwin (and
other Windows platforms).
That happens automatically (if not forcing like above) in the Linux
case since CMake always prefers to find the shared version of
libraries if given a choice with the same basename ("gnat" above with
no version number). So that is why comprehensive testing of test_ada
has "just worked" on that platform.
But Windows has no standard naming conventions
for libraries so you have to identify independently what filename
corresponds to the import library (in the Cygwin case that filename is
libgnat-6.dll.a, but who knows, for example, what it might be for
MinGW-w64/MSYS2 or some arbitrary build of the gnu tool chain on
Windows) so we have to be quite specific for what library name we want
to find in the Windows case in order to guarantee we have the import
form of the gnat library.
The attached commit makes this change for the Cygwin case (and fills
in something generic for the non-Cygwin Windows case which will likely
need to be corrected in the future for the MinGW-w64/MSYS2 case).
When you get a chance please commit this change on a local topic branch using "git
am" and
try it out on Cygwin using
cmake/test_ada/scripts/comprehensive_test.sh
Alan
______
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
0001-test_ada-build-system-Find-the-non-static-version-of.patch.gz
Description: test_ada build system: Find the non-static version of the gnat library on Cygwin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)
On 2017-10-30 11:33-0700 Alan W. Irwin wrote:
Hi Arjen (returning this discussion to the plplot-devel list):
Thanks for sending me (off list) the output from the
gnatmake -v hello.adb -cargs -fPIC -bargs -shared -largs -v -shared
gnatmake -v hello.adb -bargs -static -largs -v -static
commands on Cygwin. Based on that information I have come up with the
attached local commit (prepared with "git format-patch") to workaround
(just for the test_ada project for now) the Cygwin Ada packaging issue
revealed by the first of the above commands.
Could you let me know if that commit works for you,
i.e., once it is locally applied with "git am" does
cmake/test_ada/scripts/comprehensive_test.sh
finally work for you on Cygwin? Also, win or lose, I would like to
see the report tarball from this test.
Hi Arjen:
As you are probably aware, thanks to the efforts of Marco to bring
this Ada packaging issue to the Cygwin mailing list and Jon
to implement the packaging fix, my workaround patch
is no longer relevant. See
<https://cygwin.com/ml/cygwin-announce/2017-11/msg7.html> where
the latest version of the gcc collection of compilers now properly
includes the gnat import library. I followed up with a gnat-6.dll
search on <http://cygwin.com/cgi-bin2/package-grep.cgi> and the
gcc-ada-6.4.0-2 package includes
2017-10-31 04:09 9473456
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/libgnat-6.dll.a
2017-10-31 04:0916423982
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/libgnat.a
and the libgnat6-6.4.0-2 package includes
2017-10-31 04:11 2984467 /usr/bin/cyggnat-6.dll
Note how the import library form is much larger than the dll form and
therefore completely distinct from it (as expected).
So the next chance you have to work on PLplot, please upgrade your
Cygwin installation to this latest (6.4.0-2) gcc collection of
compilers, and confirm the following tests now work (note the change
from the above for the shared one which is a simpler and better form
of the test):
# Create the simple Ada test code (if you have not done so before)
cat > hello.adb
with Ada.Text_IO; use Ada.Text_IO;
procedure Hello is
begin
Put_Line ("Hello WORLD!");
end Hello;
# shared case
# remove results of all previous build attempts (if any)
rm -f hello hello.ali hello.o
gnatmake -v hello.adb -bargs -shared -largs -v
# test shared case
./hello
# static case
# remove results of all previous build attempts (if any)
rm -f hello hello.ali hello.o
gnatmake -v hello.adb -bargs -static -largs -v
# test static case
./hello
I find these tests work here (Debian Jessie with gcc 4.9.2) without
issues, and I urge anyone here who wants to test their Ada and gnat
installation to try these simple tests first.
Assuming the above simple gnatmake tests work on Cygwin for the
6.4.0-2 case, please follow up by running
cmake/test_ada/scripts/comprehensive_test.sh for our current master
branch without my patch (i.e., nothing locally changed in
cmake/test_ada).
I am pretty sure the net result when linking the test_ada library will
be the import form of the gnat library will be found and linked in the
shared case and the static form of the gnat library will be found and
linked in the static case, and the test will "just work". However, if
your report tarball shows any remaining issues for the test_ada
comprehensive test, I will fix them.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Possible fix for the test_ada project on Cygwin
Hi Arjen (returning this discussion to the plplot-devel list): Thanks for sending me (off list) the output from the gnatmake -v hello.adb -cargs -fPIC -bargs -shared -largs -v -shared gnatmake -v hello.adb -bargs -static -largs -v -static commands on Cygwin. Based on that information I have come up with the attached local commit (prepared with "git format-patch") to workaround (just for the test_ada project for now) the Cygwin Ada packaging issue revealed by the first of the above commands. Could you let me know if that commit works for you, i.e., once it is locally applied with "git am" does cmake/test_ada/scripts/comprehensive_test.sh finally work for you on Cygwin? Also, win or lose, I would like to see the report tarball from this test. Alan __________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ 0001-test_ada-build-system-Work-around-Cygwin-packaging-i.patch.gz Description: Possible fix for test_ada on Cygwin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] CMake-3.10.0-rc2 yields good comprehensive test results for PLplot
I just completed a comprehensive test of PLplot on Linux (Debian Jessie) using a cmake version that I built myself from the CMake-3.10.0-rc2 source code using the bootstrap method. The result was a complete success for the three different PLplot build systems (CMake-based build systems for the core build and installed examples, and a CMake-configured traditional [Makefile + pkg-config] build system for the installed examples) and the 3 major PLplot build configurations (shared libraries/dynamic devices, shared libaries/nondynamic devices, and static libraries/nondynamic devices). So from the PLplot perspective, CMake-3.10.x is looking quite promising. For further details of this comprehensive test, see the "Tested by" stanza of the git log for PLplot commit 6906798 <https://sourceforge.net/p/plplot/plplot/ci/69067983c65013058cfbe4cf047f0817f1933d37/>). Alan __________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32 (NOW FIXED)
On 2017-10-10 06:52-0400 Jim Dishaw wrote: [] I read the MSDN Documentation as well as the Intel, MinGW, and GNU compiler documentation. The WIN32 should not be used and appears to be an older convention The MSDN and Intel documentation define _WIN32 and _WIN64. MinGW appears to be following MSDN, which makes sense. Moving away from WIN32 will break builds on older platforms that we no longer support, but I don’t think that is a problem. I would stay away from __WIN32__ as that is not in the MSDN documentation. To Arjen and Jim: @Arjen: Thanks for running that quick check (in a different post than the above) on Cygwin which gave the expected result, but it is always good to be sure. @Jim: Thanks very much for that clear advice above. I agree with you the proposed change (to move strictly to _WIN32) will break builds for older versions of compilers that we don't support in any case. But with modern versions of Intel, MSVC, gcc, and clang compilers all providing the _WIN32 macro for their pure native Windows builds, I would frankly be amazed if modern versions of much less popular compilers (e.g., Borland and Watcom) did not provide that macro as well. So I have decided to go ahead with this proposed change. @Those here with access to Windows: Accordingly I have now replaced use of the WIN32 and __WIN32__ macros with the _WIN32 macro throughout our C and C++ source code (commit 14ecc4b). This is an intrusive change so I would appreciate tests of it on all Windows compilers and Windows platforms (e.g., MSVC, Cygwin, and MinGW-w64/MSYS2) accessible to you. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32
Hi Arjen: I agree its a dated table. So, for example, it is possible MinGW-w64 later severely changed course from the documentation of the classical MinGW in this table. However, if we changed to _WIN32, and MinGW-w64 did not #define that then your comprehensive test of MinGW-w64/MSYS2 would show problems immediately. But I don't think that is going to happen (i.e., I don't believe MinGW-w64 took a different course than MinGW in what WIN32-related macros they #define). More below. On 2017-10-10 07:20- Arjen Markus wrote: Hi Alan, I have had a look at the two discussions Alaric and you mention, and I agree that the best choice seems to be _WIN32 to indicate the Windows platform. I hesitate, however, to be absolutely sure, on the following grounds: - The tip on detecting the operating systems mentions that there is no 64-bits Cygwin system, but that was the case back in 2012. I have been using Cygwin 64-bits for a couple of years now. - There is also mention of Cygwin in a POSIX and in a non-POSIX variant. I have no clue as to how to determine which one I am working with or how to specify that at install time. My understanding is non-POSIX Cygwin is a thing of the past, i.e., you have the POSIX version where no variant of WIN32 is #defined. But to be absolutely sure on this point, write a simple programme which includes the following: #if defined(WIN32) || defined(_WIN32) || defined (__WIN32__) #error Cygwin defines at least one of the variants of the WIN32 macro #endif - Also the table "Windows, Cygwin (non-POSIX), and MinGW" has columns for the "Windows target" and the "MinGW target". It is unclear to me what they mean by that. I think the following note for the table explains it: "Based on command-line options, the Clang/LLVM and GCC compilers can build Windows applications or POSIX applications that run under Windows using POSIX compatibility libraries." I am virtually positive they are referring to the same distinction used on MinGW-w64/MSYS2 between the "mingw" and "msys" repositories where the first is native Windows while the second requires POSIX compatibility libraries (the MSYS2 dll) in order to run under Windows. In contrast, for modern Cygwin you build applications and libraries that require the cygwin.dll compatibility library in order to run on Windows. - Furthermore: is "MinGW" the old-style MinGW or the new one, MinGW-w64/MSYS2? From the date of the post, I would say the former. I agree. But see my initial note above. All that does not mean that we should not consistently use _WIN32, but perhaps some care is to be taken. The page https://msdn.microsoft.com/en-us/library/b0084kay.aspx indicates that Visual C++ does define _WIN32 for both the 32-bits and 64-bits platforms. On the other hand, this page from the GNU C compiler documentation says that macros whose name starts with two (!) underscores are to be considered reserved and does not mention the one-underscore macros as being special (only historical): https://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/System-specific-Predefined-Macros.html#System-specific%20Predefined%20Macros. Nevertheless, everything I have read indicates non-Cygwin gcc on Windows does #define _WIN32. I guess that only adds to the confusion :(. Well, if we make a mistake here, it is easily rectified (assuming testing on all 3 of your platforms). As you can likely tell, I feel we should probably just go ahead with this change, and just make sure it is well tested. But before doing that I will wait to see your response to my comments above (as well as your results from the simple Cygwin test I proposed above). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32
Hi Arjen: I am addressing you because you are our primary Windows platform expert, but I would be happy to hear from others here as well (including Alaric) with some knowledge of that platform. What would be your advice concerning replacing our use of the WIN32 and __WIN32__ macros in our source code? Basically, Alaric (see his bug report below) has found a platform where the _WIN32 macro is #defined but not WIN32, and the stackoverflow discussion he referenced appears to say the two macros ordinarily have the same meaning but the underscored one is a bit safer to use because there is a convention it should not be changed by anyone other than the compiler vendor. Note, however, that Alaric's bug report does not cover the entire problem in our code because we also make use of the __WIN32__ macro. Another stackoverflow discussion concerning that macro referenced <https://web.archive.org/web/20140625123925/http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system>. My conclusion from reading the "Windows, Cygwin (non-POSIX), and MinGW" section of that article is the safest course for supporting all Windows compilers is for us to replace all use of the WIN32 and __WIN32__ macros in our C and C++ code with use of the _WIN32 macro instead. Do you agree? If so, I would be willing to take responsibility for the actual code change since Linux has excellent facilities (find and sed) for automatic mass-editing of code. Alan __________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Forwarded message -- Date: Mon, 09 Oct 2017 15:52:10 + From: Alaric Senat Reply-To: Ticket 189 <1...@bugs.plplot.p.re.sf.net> To: Ticket 189 <1...@bugs.plplot.p.re.sf.net> Subject: [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32 --- ** [bugs:#189] Using WIN32 Macro instead of _WIN32** **Status:** open **Group:** **Created:** Mon Oct 09, 2017 03:52 PM UTC by Alaric Senat **Last Updated:** Mon Oct 09, 2017 03:52 PM UTC **Owner:** nobody Hello, This ticket is just about a little detail and its not exactly a bug. Me and my team are cross-compiling for windows, and we noticed that you are often using the WIN32 macro in your source files to check the current compilator platform. We needed to switch these macros to \_WIN32 because in our case, we are compiling with the *-std=c++14* flag and is disable WIN32 cause it's not in the standard. To my mind, It would be a bit safer if those WIN32 were switched to \_WIN32 in a further version of PlPlot! Here is a nice topic on that point : https://stackoverflow.com/questions/662084/whats-the-difference-between-the-win32-and-win32-defines-in-c/662543#662543 Regards, Alaric Senat --- Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/plplot/bugs/189/> To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/> -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Issues with locate mode for the non-IPC3 case
On 2017-10-08 12:54+0100 Phil Rosenberg wrote: On 7 October 2017 at 02:14, Alan W. Irwin wrote: Hi Phil: I just discovered on Linux that your IPC3 workaround does allow -locate mode for example 1 to work perfectly for mouse clicks. (IPC3 locate mode key hits are not implemented yet.) But I also think that workaround should not be necessary, and the fundamental problem is when I originally implemented IPC3 locate mode I used the non-IPC3 version of wxPlFrame::ReadTransmission to model what the IPC3 version of that routine should do in locate mode, but it turns out that is a flawed model! So it is no wonder that you had to implement a workaround to get locate mode to work at all for the IPC3 case. Here are the current (master HEAD) problems with locate mode for the non-IPC3 case as demonstrated when I run examples/c/x01c -dev wxwidgets -locate on Linux. 1. The initial wxPLViewer response is always a blank screen. 2. Furthermore, initial blind mouse clicking on the position of viewports 2, 3, and 4 gets no response at all. Blind clicking on the (upper-left) position of viewport 1 does typically get a response (but sometimes only after several clicks), and if I keep clicking eventually the actual plot appears, and then after that clicking on viewports 2, 3, and 4 finally begins to work. Just tested the latest master head on Windows and it works perfectly. Not sure why it would be different on Linux. My own gut feeling is there is some general issue with the way events are set up that is cause of these issues, but the bug is only exposed on some platforms (similar to the Linux OnCreate delay bug that you fixed in January this year just before the release of 5.12.0.) 3. In no case have I gotten key hits to work (even though there is code to handle that case for the non-IPC3 version of wxPlFrame::ReadTransmission). You are correct, key presses don't work on Linux, that is due to a difference between Linux and windows in ter,s of event capture that I wasn't aware of when I wrote the viewer. It is on my fix list, but feel free to add it to the bug tracker so I don't forget. I was unaware until reading your above remark there was a difference between Linux and Windows event capture. However, given that is the case is it possible you still need to make an adjustment for that difference in order to solve Linux issues 1 and 2 as well? Alan ______ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] non-IPC3 interactive issues with example 20
Hi Phil: In the same spirit of getting interactive non-IPC3 to work properly as a model of what should be done for the IPC3 case, please fix the following non-IPC3 issue that shows up for example 20 for the current master HEAD: The plot page display is out of sync (due to screwed up processing of events?). Page 1 is displayed no matter how much I hit the enter key to move on to the next page, but if I select a region (something that should happen after the second page is displayed), the second page is displayed rather than the third, and so forth. Until this situation is resolved, I cannot tell if this is the only interactive issue for this example or whether there are more. For the record, the way this example is supposed to work is as follows: # Move to examples subdirectory where image of Chloe resides. cd examples # Run example 20 c/x20c -dev wxwidgets 1. First "sombrero" page displayed. 2. After user hits enter key, the entirety of the "Chloe" page should be displayed with instructions to select a region using the mouse. 3. After the user selects a region (by drag and drop with mouse 1 and clicking with mouse 2 to terminate that selection), that selected region is displayed at the original (small) scale. 4. After the user hits the enter key, the next page is displayed which should contain the selected region of the Chloe image at large scale. 5. After the user hits the enter key, the next page is displayed of the full Chloe image at reduced dynamic range. 6. After the user hits the enter key, the next page is displayed of the full Chloe image with distorted geometry. 7. After the user hits the enter key, wxPLViewer quits. I hope this description of the way the interactive steps of this example should work will help you to sort out all non-IPC3 problems for this example so I can use that corrected non-IPC3 model to figure out what to do in the IPC3 case. Alan __________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] non-IPC3 interactive issues with example 14
Hi Phil: In the same spirit of getting interactive non-IPC3 to work properly as a model of what should be done for the IPC3 case, please fix the following non-IPC3 issues that show up for example 14 for the current master HEAD: 1. Slave GUI is blank (i.e., does not show any plot). I am pretty sure this issue is likely caused by the same issue (screwed up processing of events?) that is causing non-IPC3 display issues for example 1 in locate mode. 2. Slave GUI finishes and disappears even with no action taken by the user. I recently analyzed the cause of this situation in detail. For all other interactive devices core coincides with viewer so when the viewer pauses at page end waiting for the user to hit the enter key the core automatically pauses as well. And that assumption is fundamental to the way that example 14 works. So to cure this issue you have to implement the same scenario for the wxwidgets device so that when the (separate) master viewer pauses at page end, the master core must be forced to pause as well. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] ocaml and antialiased gtk embedding (cairo)
On 2017-10-07 13:57- Philippe STRAUSS wrote: finally there! I've reversed the two commits of hez and the cairo2 based plplot runs fine. Hi Phillipe: You dropped the plplot-devel mailing list address from your post (likely because you just used reply rather than reply-all), but I added it back because I want this discussion to be available there. I am glad you got something to work, but please clarify your description above of exactly what it was you got to work. For example, reversing the two last commits from Hez and also my two small commits that disabled plcairo should allow plcairo to support "cairo" rather than "cairo2". Leaving Hez's commits as is, but just reversing my two commits should allow plcairo to support "cairo2" rather than "cairo". Whichever of "cairo" or "cairo2" you got to work, could you also try the alternative to see if that works as well? to be honest, i could not reply myself to the cairo vs cairo2 ocaml bindings debate, so I've asked on the ocaml mailing list. Could you give me a URL of the mailing-list archive that contains the full thread of this discussion? I would like to see the original question you asked, and any additional responses (possibly in the future) beyond the one you quoted. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
