Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: Alan W. Irwin <irwin@be...> - 2014-01-21 09:45:04
|
My personal development goal for this release is to get a clean comprehensive test of epa_build results both on Linux and MinGW/MSYS. So far (aside from the known propagation issues with OCaml) the results of a somewhat limited version of the test have looked good on PLplot. However, on MinGW/MSYS this comprehensive test fails at run time with a return code of 3 for the installed Ada examples. I encountered this same test failure before when I hand-tested 5.9.11 on MinGW/MSYS, and it is good to know the recently updated (revision 12946) comprehensive test script finds the problem as well. Ada example builds are quite complex with many different directory locations pointed to by various flags. My plan for tomorrow is to do such a build by hand using the build-tree locations for everything. And assuming that works (like it does for actual build-tree tests for MinGW/MSYS) gradually change over all locations to the install-tree counterparts until I run into the build issue that is causing the return code of 3 at run time. If the MSYS version of strace worked, that would likely be an even quicker way to solve this issue. But currently I have not been able to get it to work so I have a query into the MinGW mailing list about that issue. So that is the status of what I am working on currently. I also encourage both Arjen and Andrew (who have both told me they plan some bug fixing between now and the 5.10.0 release) to give progress reports and updated plans from time to time here so I don't get surprised by anything they do. 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 __________________________ |
|
From: Arjen Markus <Arjen.Markus@de...> - 2014-01-21 15:43:13
|
Hi Alan, I am currently trying to reproduce the errors you documented via Cygwin, as that is the most convenient platform available to me that comes close to Linux. And while this has the benefit of unearthing the idiosyncracies of Cygwin that we need to deal with it does also slow down my progress. Still, I have good hopes to at least weed out a few more bugs before the release of 5.10.0. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:irwin@...] > Sent: Tuesday, January 21, 2014 10:45 AM > To: Arjen Markus; Andrew Ross > Cc: PLplot development list > Subject: Still on track for a February 1st release of 5.10.0 > > My personal development goal for this release is to get a clean comprehensive test > of epa_build results both on Linux and MinGW/MSYS. > So far (aside from the known propagation issues with OCaml) the results of a > somewhat limited version of the test have looked good on PLplot. However, on > MinGW/MSYS this comprehensive test fails at run time with a return code of 3 for the > installed Ada examples. I encountered this same test failure before when I hand- > tested 5.9.11 on MinGW/MSYS, and it is good to know the recently updated (revision > 12946) comprehensive test script finds the problem as well. > > Ada example builds are quite complex with many different directory locations pointed > to by various flags. My plan for tomorrow is to do such a build by hand using the > build-tree locations for everything. > And assuming that works (like it does for actual build-tree tests for > MinGW/MSYS) gradually change over all locations to the install-tree counterparts > until I run into the build issue that is causing the return code of 3 at run time. > > If the MSYS version of strace worked, that would likely be an even quicker way to > solve this issue. But currently I have not been able to get it to work so I have a query > into the MinGW mailing list about that issue. > > So that is the status of what I am working on currently. I also encourage both Arjen > and Andrew (who have both told me they plan some bug fixing between now and the > 5.10.0 release) to give progress reports and updated plans from time to time here so > I don't get surprised by anything they do. > > 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 > __________________________ DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. Irwin <irwin@be...> - 2014-01-22 10:39:12
|
On 2014-01-21 01:44-0800 Alan W. Irwin wrote: > My personal development goal for this release is to get a clean > comprehensive test of epa_build results both on Linux and MinGW/MSYS. > So far (aside from the known propagation issues with OCaml) the > results of a somewhat limited version of the test have looked good on > [Linux]. However, on MinGW/MSYS this comprehensive test fails at run > time with a return code of 3 for the installed Ada examples. Today I fixed that problem (which I think was due to a MinGW-4.7.2 Ada compiler bug, but I found a simple way to work around it). I also fixed a MinGW/MSYS PATH manipulation issue in scripts/comprehensive_test.sh that I discovered via a preliminary test today. I now have started an overnight noninteractive comprehensive test job running on my MinGW/MSYS/Wine platform. The equivalent job on Linux takes about 30 minutes, but on Wine it should be much longer (if it goes all the way through to a success on that platform) because of the command startup latency issue for Wine that I have discussed before. 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 __________________________ |
|
From: Alan W. Irwin <irwin@be...> - 2014-01-29 02:50:34
|
On 2014-01-22 02:39-0800 Alan W. Irwin wrote: > On 2014-01-21 01:44-0800 Alan W. Irwin wrote: > >> My personal development goal for this release is to get a clean >> comprehensive test of epa_build results both on Linux and MinGW/MSYS. >> So far (aside from the known propagation issues with OCaml) the >> results of a somewhat limited version of the test have looked good on >> [Linux]. However, on MinGW/MSYS this comprehensive test fails at run >> time with a return code of 3 for the installed Ada examples. > > Today I fixed that problem (which I think was due to a MinGW-4.7.2 Ada > compiler bug, but I found a simple way to work around it). I also > fixed a MinGW/MSYS PATH manipulation issue in > scripts/comprehensive_test.sh that I discovered via a preliminary test > today. > > I now have started an overnight noninteractive comprehensive test job > running on my MinGW/MSYS/Wine platform. The equivalent job on Linux > takes about 30 minutes, but on Wine it should be much longer (if it > goes all the way through to a success on that platform) because of the > command startup latency issue for Wine that I have discussed before. That project has been interrupted over the last ~5 days by the more important project (in my view) of getting our api.xml documentation into good consistency with plplot.h. This opportunity was made possible thanks to Hǎilià ng Wáng's "check" application that was written on Go. With revision 12971 that api.xml consistency project has been completed with an absolute clean report for the check_api_xml_consistency target! The downside of this excellent news concerning our documentation is it was quite time consuming for me to deal with those ~150 API inconsistencies in api.xml so it is going to be difficult for me to finish the MinGW/MSYS/Wine platform tests by the scheduled February 1st release date. So I propose to change the release date to February 8th with tuning the actual release date to slightly earlier or later than that nominal date depending on how soon we can finish our planned projects for this release. Of course such tuning of the actual release date depends on good communications. Therefore, Arjen and Andrew please communicate whether you could you use a little extra time to finish the planned changes for this release that you mentioned to me or indicate whether you are actually finished making changes for this release already. 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 __________________________ |
|
From: Arjen Markus <Arjen.Markus@de...> - 2014-01-29 05:10:37
|
Hi Alan, here is my quick answer, as I am rather pressed for time at the moment: I have been able to pinpoint the piece of code that causes the mysterious crash when wish/tclsh executes the [exit] command, but sofar I have not been able to identify the real cause. I will dive further into it tonight, but it is a nasty mystery - I can find no reason at all for the difference in behaviour between wish/tclsh and plserver. Moreover, the error does not occur on Cygwin. It has something to do with the particular alternative start-up of the xwin device (the function OpenXWin). If my attempt fails, I will focus on a few minor details instead. Regards, Arjen ________________________________________ From: Alan W. Irwin [irwin@...] Sent: Wednesday, January 29, 2014 3:50 AM To: Arjen Markus; Andrew Ross Cc: PLplot development list Subject: Re: [Plplot-devel] Still on track for a February 1st release of 5.10.0 On 2014-01-22 02:39-0800 Alan W. Irwin wrote: > On 2014-01-21 01:44-0800 Alan W. Irwin wrote: > >> My personal development goal for this release is to get a clean >> comprehensive test of epa_build results both on Linux and MinGW/MSYS. >> So far (aside from the known propagation issues with OCaml) the >> results of a somewhat limited version of the test have looked good on >> [Linux]. However, on MinGW/MSYS this comprehensive test fails at run >> time with a return code of 3 for the installed Ada examples. > > Today I fixed that problem (which I think was due to a MinGW-4.7.2 Ada > compiler bug, but I found a simple way to work around it). I also > fixed a MinGW/MSYS PATH manipulation issue in > scripts/comprehensive_test.sh that I discovered via a preliminary test > today. > > I now have started an overnight noninteractive comprehensive test job > running on my MinGW/MSYS/Wine platform. The equivalent job on Linux > takes about 30 minutes, but on Wine it should be much longer (if it > goes all the way through to a success on that platform) because of the > command startup latency issue for Wine that I have discussed before. That project has been interrupted over the last ~5 days by the more important project (in my view) of getting our api.xml documentation into good consistency with plplot.h. This opportunity was made possible thanks to Hǎilià ng Wáng's "check" application that was written on Go. With revision 12971 that api.xml consistency project has been completed with an absolute clean report for the check_api_xml_consistency target! The downside of this excellent news concerning our documentation is it was quite time consuming for me to deal with those ~150 API inconsistencies in api.xml so it is going to be difficult for me to finish the MinGW/MSYS/Wine platform tests by the scheduled February 1st release date. So I propose to change the release date to February 8th with tuning the actual release date to slightly earlier or later than that nominal date depending on how soon we can finish our planned projects for this release. Of course such tuning of the actual release date depends on good communications. Therefore, Arjen and Andrew please communicate whether you could you use a little extra time to finish the planned changes for this release that you mentioned to me or indicate whether you are actually finished making changes for this release already. 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 __________________________ DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. Irwin <irwin@be...> - 2014-01-29 07:48:31
|
On 2014-01-29 05:10-0000 Arjen Markus wrote: > Hi Alan, > > here is my quick answer, as I am rather pressed for time at the moment: > I have been able to pinpoint the piece of code that causes the mysterious crash when wish/tclsh executes the [exit] command, but sofar I have not been able to identify the real cause. I will dive further into it tonight, but it is a nasty mystery - I can find no reason at all for the difference in behaviour between wish/tclsh and plserver. > Moreover, the error does not occur on Cygwin. It has something to do with the particular alternative start-up of the xwin device (the function OpenXWin). > > If my attempt fails, I will focus on a few minor details instead. Hi Arjen: Note the changed subject line. Thanks for that feedback, and good luck in debugging that segfault. My principle concern right now is adjusting the timing of the release, but from what you said above, it looks like you can be fairly flexible about that. Therefore, I will just go ahead and adjust that timing for my own needs, but I will try to keep everybody here well informed as I narrow down that timing so nobody gets surprised when that actual release happens. By the way, once I figure out the required build system tweaks so I obtain a good comprehensive test result on MinGW/MSYS/Wine, (probably a number of days from now since Wine is so slow) I hope you will still have some time/energy left to confirm that result on your own MinGW/MSYS Windows platform. 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 __________________________ |
|
From: Arjen Markus <Arjen.Markus@de...> - 2014-01-30 16:47:40
|
Hi Alan, I have noticed it ;). Right now I am less than optimistic that I will be able to find the cause: - I have tried to reduce the differences between wish (failing) and plserver (working) to a minimum (by loading the Pltk package dynamically, by excluding manner of extra bits and pieces, such as the renaming of [exit]): no change in behaviour. - I have identified that the call to plP_escape to initialise the xwin device is instrumental to the crash and I thought that perhaps the display connection was closed twice, leading to the problem. So, I have made sure that it occurs only once (passing on the connection from Tcl/Tk to the xwin device instead of opening a new one and allowing Tcl/Tk to close it via the [exit] command). Still no positive result. - I have studied the source code, but I have not found any location where the difference in behaviour might be coming from. One possibility is that the Tcl/Tk library is built with threads enabled and the crash occurs in some pthreads routine. Whether that is any clue (and how to take advantage of that knowledge) is unclear to me. Well, so far my detailed feedback. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:irwin@...] > > Note the changed subject line. > > Thanks for that feedback, and good luck in debugging that segfault. > > My principle concern right now is adjusting the timing of the release, but from what > you said above, it looks like you can be fairly flexible about that. Therefore, I will just > go ahead and adjust that timing for my own needs, but I will try to keep everybody > here well informed as I narrow down that timing so nobody gets surprised when that > actual release happens. > > By the way, once I figure out the required build system tweaks so I obtain a good > comprehensive test result on MinGW/MSYS/Wine, (probably a number of days from > now since Wine is so slow) I hope you will still have some time/energy left to confirm > that result on your own MinGW/MSYS Windows platform. > > 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 > __________________________ DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. Irwin <irwin@be...> - 2014-02-06 09:43:19
|
To everyone here: The actual date of the release is still uncertain because I am not completely done with my planned comprehensive MinGW/MSYS testing yet. However, I have been having good luck with comprehensive testing on Linux, so now (revision 12980) would be a good time to repeat the tests (currently documented in README.release) that a lot of you did for the last release. The plplot_lite epa_build with ENABLE_COMPREHENSIVE_PLPLOT_TEST=ON (and with interactive parts of the test turned off locally to speed up the test) goes through with complete success on the Linux platform showing there are no regressions introduced by the build system changes since the previous good test results for this platform. Note, as indicated by the ENABLE_COMPREHENSIVE_PLPLOT_TEST name, this test is a comprehensive noninteractive one that is done with script/comprehensive_test.sh. This test took roughly half an hour on Linux. On top of that epa_build regression check for the Linux platform, I have successfully completed some critical bits and pieces of the same comprehensivive plplot_lite tests on MinGW/MSYS/Wine that were failing for the last release. That leads me to believe a repeat on that platform of the comprehensive test described above for Linux is likely to succeed. I have therefore initiated such a test ~5 hours ago, and it is still going strong with no run-time errors. If that success continues, then from the time it has taken to do individual parts of the comprehensive test, I think the whole thing will finish roughly 15 (!) hours after the start which is a Wine slowdown of a factor of roughly 30 compared to the equivalent Linux test. As I have remarked before, that slowdown is due to the peculiarly large command startup latency for Wine multiplied by the ~10^5 commands that occur in this comprehensive test. This huge latency slowdown should not occur for any other Windows platform and certainly not for any non-Windows platform. As of revision 12980 I have also updated the epa_build directions in cmake/epa_build/README to be consistent with my latest comprehensive testing experience with epa_build. Therefore, this is a good time for anybody here interested in doing comprehensive testing to follow those instructions. @Andrew: note the degree of parallelism is now kept at -j4 rather than -j8 so some of the X issues you had with large numbers of interactive tests going on simultaneously on one of your platforms might be gone this time. @Arjen: This would be a good time for you to attempt to adapt the directions in the above README file for the MinGW/MSYS/Wine case in order to replicate my current test on your MinGW/MSYS/Microsoft Windows platform. I think the Microsoft Windows command startup latency will be considerably less than the Wine case so the timing should be much reduced compared to the Wine case and roughly the same as the Linux case, i.e., roughly an hour. So if you start on this right away and don't have any trouble figuring out my directions, it is possible you could finish this test before I do. :-) Of course, I am pretty sure this is the first time you have attempted to do such comprehensive tests of PLplot so it is more likely that you will run into some trouble, but I would be more than happy to help you with that if it occurs. For the initial stages of getting this to work, I suggest you first try building just a few of the -DBUILD_THE_BUILDTOOLS=ON projects. But if all goes well (indicating you have set up the required environment variables correctly and your downloaded MinGW and MSYS have been installed correctly) you should be able to build all of them. (Note, this lack of caution is allowed because I have already gotten rid of most/all of the MinGW/MSYS epa_build issues. But, of course, you would want to proceed more cautiously for the Cygwin case where there are likely to still be epa_build issues.) The other deviation from the official instructions, is I suggest you temporily drop the interactive part of the -DBUILD_THE_BUILDTOOLS=OFF -DENABLE_COMPREHENSIVE_PLPLOT_TEST=ON test case (as I am doing for my long MinGW/MSYS/Wine test above). This can be done by locally editing cmake/epa_build/plplot_lite/CMakeLists.txt to replace the first "echo yes" that occurs in that file by "echo no". Anyhow, good luck with your MinGW/MSYS testing. @Everybody: Assuming the comprehensive noninteractive MinGW/MSYS/Wine test described above finishes for me without errors, then the last thing I plan to do for this release cycle is to repeat this comprehensive test both for Linux and MinGW/MSYS/Wine for the interactive test case. In addition, I assume some of my time before the release will also be consumed by attempting to deal with errors that others find through their own testing. For those reasons the actual date of the release is still uncertain, but with luck it might be as early as the middle of next week. But given a choice between fixing some obvious error one of you finds or doing the release regardless to meet some arbitrary deadline, I will do the former. So I look forward to seeing lots of test reports from you guys! :-) 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 __________________________ |
|
From: Alan W. Irwin <irwin@be...> - 2014-02-06 18:26:17
|
On 2014-02-06 01:43-0800 Alan W. Irwin wrote: > On top of that epa_build regression check for the Linux platform, I > have successfully completed some critical bits and pieces of the same > comprehensivive plplot_lite tests on MinGW/MSYS/Wine that were failing > for the last release. That leads me to believe a repeat on that > platform of the comprehensive test described above for Linux is likely > to succeed. I have therefore initiated such a test ~5 hours ago, and > it is still going strong with no run-time errors. Status report: that job continues without errors. It has successfully completed noninteractive comprehensive tests (ctest and the test_noninteractive target in the build tree and the test_noninteractive targets in the installed examples tree for the cmake-based and traditional build systems for that case) for (1) the shared libraries/dynamic devices case, and (2) the shared library/nondynamic devices case. I estimate it should take roughly 4 more hours to complete the job by finishing the noninteractive comprehensive tests for (3) the static libraries/nondynamic devices case. So far, these results look extremely good since I have been able to successfully complete comprehensive tests with this job that have never completed successfully before on MinGW/MSYS. More later. 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 __________________________ |
|
From: Alan W. Irwin <irwin@be...> - 2014-02-07 03:12:00
|
On 2014-02-06 01:43-0800 Alan W. Irwin wrote: > [...] I > have successfully completed some critical bits and pieces of the same > comprehensivive plplot_lite tests on MinGW/MSYS/Wine that were failing > for the last release. That leads me to believe a repeat on that > platform of the comprehensive test described above for Linux is likely > to succeed. I have therefore initiated such a test ~5 hours ago, and > it is still going strong with no run-time errors. If that success > continues, then from the time it has taken to do individual parts of > the comprehensive test, I think the whole thing will finish roughly 15 > (!) hours after the start which is a Wine slowdown of a factor of > roughly 30 compared to the equivalent Linux test. That noninteractive test completed finally without any errors which is a big breakthrough for the MinGW/MSYS/Wine platform. Woohoo! So, Arjen, there should be nothing in our source tree that prevents you from replicating this test on MinGW/MSYS/Microsoft Windows. It did take 17.5 hours on Wine to complete this test, but the computer time required in the MinGW/MSYS/Microsoft Windows case should be much less than that. My next step is to finish up the comprehensive Linux tests I describe in README.release (revision 12981). Then I plan to follow that up by doing an _interactive_ comprehensive test on MinGW/MSYS/Wine to finish out the MinGW/MSYS/Wine test I have described in README.release. That will be the final effort I have planned for this release cycle. 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 __________________________ |
|
From: Arjen Markus <Arjen.Markus@de...> - 2014-02-06 09:49:49
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:irwin@...] > > @Arjen: This would be a good time for you to attempt to adapt the directions in the > above README file for the MinGW/MSYS/Wine case in order to replicate my current > test on your MinGW/MSYS/Microsoft Windows platform. I think the Microsoft > Windows command startup latency will be considerably less than the Wine case so > the timing should be much reduced compared to the Wine case and roughly the > same as the Linux case, i.e., roughly an hour. So if you start on this right away and > don't have any trouble figuring out my directions, it is possible you could finish this > test before I do. :-) Of course, I am pretty sure this is the first time you have > attempted to do such comprehensive tests of PLplot so it is more likely that you will > run into some trouble, but I would be more than happy to help you with that if it > occurs. > > For the initial stages of getting this to work, I suggest you first try building just a few > of the -DBUILD_THE_BUILDTOOLS=ON projects. But if all goes well (indicating you > have set up the required environment variables correctly and your downloaded > MinGW and MSYS have been installed correctly) you should be able to build all of > them. > (Note, this lack of caution is allowed because I have already gotten rid of most/all of > the MinGW/MSYS epa_build issues. But, of course, you would want to proceed > more cautiously for the Cygwin case where there are likely to still be epa_build > issues.) > > The other deviation from the official instructions, is I suggest you temporily drop the > interactive part of the -DBUILD_THE_BUILDTOOLS=OFF - > DENABLE_COMPREHENSIVE_PLPLOT_TEST=ON test case (as I am doing for my > long MinGW/MSYS/Wine test above). This can be done by locally editing > cmake/epa_build/plplot_lite/CMakeLists.txt to replace the first "echo yes" that occurs > in that file by "echo no". > > Anyhow, good luck with your MinGW/MSYS testing. > This sounds like a good plan - I have not had any luck yet with hunting down the [exit] bug under Linux. My plan is to use strace to see whether there are different libraries loaded in the two cases, and whether this could be causing the trouble. However that will be something that requires care and concentration. As I am suffering (almost literally ;)) from a mild case of flu, moving to MinGW/MSYS will probably be more productive. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Arjen Markus <Arjen.Markus@de...> - 2014-02-06 10:41:35
|
Hi Alan, after some initial hiccups (involving two independent but not quite detached installations of MinGW/MSYS) the build is progressing. At least, I think it is. The task manager indicates make.exe is using a lot of processor time, but no files seem to be produced. Also no indication of the compiler(s) being run. I will let it continue for now ... Regards, Arjen > -----Original Message----- > From: Arjen Markus [mailto:Arjen.Markus@...] > Sent: Thursday, February 06, 2014 10:50 AM > To: Alan W. Irwin > Cc: PLplot development list; Andrew Ross > Subject: Re: [Plplot-devel] Still roughly on track for a February 12th release of 5.10.0 > > Hi Alan, > > > > > -----Original Message----- > > From: Alan W. Irwin [mailto:irwin@...] > > > > @Arjen: This would be a good time for you to attempt to adapt the > > directions in the above README file for the MinGW/MSYS/Wine case in > > order to replicate my current test on your MinGW/MSYS/Microsoft > > Windows platform. I think the Microsoft Windows command startup > > latency will be considerably less than the Wine case so the timing > > should be much reduced compared to the Wine case and roughly the same > > as the Linux case, i.e., roughly an hour. So if you start on this > > right away and don't have any trouble figuring out my directions, it > > is possible you could finish this test before I do. :-) Of course, I > > am pretty sure this is the first time you have attempted to do such > > comprehensive tests of PLplot so it is more likely that you will run into some trouble, > but I would be more than happy to help you with that if it occurs. > > > > For the initial stages of getting this to work, I suggest you first > > try building just a few of the -DBUILD_THE_BUILDTOOLS=ON projects. But > > if all goes well (indicating you have set up the required environment > > variables correctly and your downloaded MinGW and MSYS have been > > installed correctly) you should be able to build all of them. > > (Note, this lack of caution is allowed because I have already gotten > > rid of most/all of the MinGW/MSYS epa_build issues. But, of course, > > you would want to proceed more cautiously for the Cygwin case where > > there are likely to still be epa_build > > issues.) > > > > The other deviation from the official instructions, is I suggest you > > temporily drop the interactive part of the -DBUILD_THE_BUILDTOOLS=OFF > > - DENABLE_COMPREHENSIVE_PLPLOT_TEST=ON test case (as I am doing for > my > > long MinGW/MSYS/Wine test above). This can be done by locally editing > > cmake/epa_build/plplot_lite/CMakeLists.txt to replace the first "echo > > yes" that occurs in that file by "echo no". > > > > Anyhow, good luck with your MinGW/MSYS testing. > > > > This sounds like a good plan - I have not had any luck yet with hunting down the [exit] > bug under Linux. My plan is to use strace to see whether there are different libraries > loaded in the two cases, and whether this could be causing the trouble. However that > will be something that requires care and concentration. As I am suffering (almost > literally ;)) from a mild case of flu, moving to MinGW/MSYS will probably be more > productive. > > Regards, > > Arjen > DISCLAIMER: This message is intended exclusively for the addressee(s) and may > contain confidential and privileged information. If you are not the intended recipient > please notify the sender immediately and destroy this message. Unauthorized use, > disclosure or copying of this message is strictly prohibited. The foundation 'Stichting > Deltares', which has its seat at Delft, The Netherlands, Commercial Registration > Number 41146461, is not liable in any way whatsoever for consequences and/or > damages resulting from the improper, incomplete and untimely dispatch, receipt > and/or content of this e-mail. > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications Take advantage of what the > Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@... > https://lists.sourceforge.net/lists/listinfo/plplot-devel DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. Irwin <irwin@be...> - 2014-02-06 11:25:47
|
On 2014-02-06 10:41-0000 Arjen Markus wrote: > Hi Alan, > > after some initial hiccups (involving two independent but not quite detached installations of > MinGW/MSYS) the build is progressing. At least, I think it is. The task manager indicates > make.exe is using a lot of processor time, but no files seem to be produced. Also no indication > of the compiler(s) being run. > > I will let it continue for now ... That sounds like good news. If you are talking about the plplot_lite build (as opposed to one of the buildtool targets available to you with -DBUILD_THE_BUILDTOOLS=ON build), then the comprehensive results show up in epa_build/Source/comprehensive_test_disposeable/ in the build tree. In particular all the VERBOSE *.out files are collected in epa_build/Source/comprehensive_test_disposeable/*/output_tree, (where * is "shared", "nondynamic", and "static" by the time all the comprehensive tests are done). So you should be seeing progress in those output_tree directories, and you can look for warnings and errors in those *.out files with, e.g., grep -i warning \ epa_build/Source/comprehensive_test_disposeable/*/output_tree/*.out \ | less grep -i error \ epa_build/Source/comprehensive_test_disposeable/*/output_tree/*.out \ |less Signing off until after I can get some sleep. 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 __________________________ |
|
From: Arjen Markus <Arjen.Markus@de...> - 2014-02-06 11:35:06
Attachments:
CMakeError.log
CMakeOutput.log
|
Hi Alan, I hope you slept well by the time you read this. Progress is less than satisfactory, I am afraid. The make utility did get stuck while trying to build CMake. I terminated it and then started it in the CMake directory to see if that makes a difference. Well, that continued up to and including the build of the CMake executable. I then restarted make in the top directory but that failed just a bit later. Again somewhere in the CMake build. I have attached the output files from that build step, but it seems likely that the header file "sys/resource.h" is the culprit. It does not exist in MinGW/MSYS (it does in Cygwin). Next step: see if I can build CMake from source. > -----Original Message----- > From: Alan W. Irwin [mailto:irwin@...] > Sent: Thursday, February 06, 2014 12:26 PM > To: Arjen Markus > Cc: PLplot development list > Subject: RE: [Plplot-devel] Still roughly on track for a February 12th release of 5.10.0 > > On 2014-02-06 10:41-0000 Arjen Markus wrote: > > > Hi Alan, > > > > after some initial hiccups (involving two independent but not quite > > detached installations of > > MinGW/MSYS) the build is progressing. At least, I think it is. The > > task manager indicates make.exe is using a lot of processor time, but > > no files seem to be produced. Also no indication of the compiler(s) being run. > > > > I will let it continue for now ... > > That sounds like good news. > > If you are talking about the plplot_lite build (as opposed to one of the buildtool targets > available to you with -DBUILD_THE_BUILDTOOLS=ON build), then the > comprehensive results show up in > epa_build/Source/comprehensive_test_disposeable/ in the build tree. > > In particular all the VERBOSE *.out files are collected in > epa_build/Source/comprehensive_test_disposeable/*/output_tree, (where > * is "shared", "nondynamic", and "static" by the time all the comprehensive tests are > done). So you should be seeing progress in those output_tree directories, and you > can look for warnings and errors in those *.out files with, e.g., > > grep -i warning \ > epa_build/Source/comprehensive_test_disposeable/*/output_tree/*.out \ > | less > > grep -i error \ > epa_build/Source/comprehensive_test_disposeable/*/output_tree/*.out \ > |less > > Signing off until after I can get some sleep. > > 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 > __________________________ DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Arjen Markus <Arjen.Markus@de...> - 2014-02-06 12:08:47
|
Hi Alan, > -----Original Message----- > From: Arjen Markus [mailto:Arjen.Markus@...] > > Next step: see if I can build CMake from source. > That presented no problem. So the procedure in epa_build is overlooking something. Perhaps epa_build should simply use the bootstrap script? That works fine. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. Irwin <irwin@be...> - 2014-02-06 18:10:33
|
On 2014-02-06 12:08-0000 Arjen Markus wrote: > Hi Alan, > >> -----Original Message----- >> From: Arjen Markus [mailto:Arjen.Markus@...] >> >> Next step: see if I can build CMake from source. >> > > That presented no problem. So the procedure in epa_build is overlooking something. Perhaps epa_build should simply use > the bootstrap script? That works fine. But the bootstrap method if done without the --system-curl option produces a weak version of cmake that is unsuitable to use with epa_build, see my discussion of this in cmake/epa_build/README. And when the bootstrap method is used with the --system-curl option, it should fail (see below) for MinGW/MSYS. Actually my directions in cmake/epa_build/README are not correct. I was trying to summarize what I thought should work, rather than my actual buildtools builds (done quite a while ago) which were done in a piece-meal way as below without ever attempting to build cmake on MinGW/MSYS (since the results of that build should fail on that platform and are ignored on that platform in any case). While writing those directions I should have reviewed cmake/epa_build/cmake/CMakeLists.txt. Note that the bootstrap script is the method that is used, but that demands an external curl library with the --system-curl option (which is absolutely necessary to produce a strong cmake that is suitable for use with epa_build.) So that bootstrap script method works on Linux (since curl is installed) but should error out on MinGW/MSYS because curl is unavailable on that platform. Apparently, you only sent me bits and pieces of what build_cmake.out (see below) should have contained. So I cannot figure out what went on. But that doesn't matter since the cmake build is irrelevant on MinGW/MSYS. So just skip running the build_cmake target on MinGW/MSYS. Instead, build the following individual targets for the -DBUILD_THE_BUILDTOOLS=ON case: build_pkg-config build_swig build_iwidgets4.0 build_iwidgets Those together build all the buildtools you are going to need. For example, build_iwidgets4.0 automatically builds its dependencies (Tcl, Tk, and old versions of Itcl and Itk), before actually building Iwidgets 4.0. build_iwidgets is similar, but it uses different (much more modern) Itcl and Itk builds that PLplot is currently not completely compatible with (see http://sourceforge.net/p/plplot/bugs/138/). So for now you won't be using the results of build_iwidgets, but you should run that target anyway to make sure it works (like it does for me) and so that eventually you will be able to investigate bug 138. Let's use the first of the above targets (which is actually the simplest of the bunch) for a test case. Please keep track of the results in the recommended way, e.g., ${BUILD_COMMAND} build_pkg-config >& build_pkg-config.out If that does not work (or you run into trouble with any of the other targets mentioned above, send me the following essential files so I can debug what is going on: 1. The files you indirectly and directly source from bash to define the required environment variables. (i.e., the tailored versions of cmake/epa_build/setup/setup_mingw_msys_wine_toolchain and cmake/epa_build/setup/setup_msys_makefiles that you have created in accordance with the README directions). 2. cmake.out (created when you follow the exact README directions for the -DBUILD_THE_BUILDTOOLS=ON case). 3. CMakeCache.txt 4. build_pkg-config.out (or the corresponding file from the particular above target that did not work). 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 __________________________ |
|
From: Alan W. Irwin <irwin@be...> - 2014-02-07 05:52:58
|
On 2014-02-06 10:10-0800 Alan W. Irwin wrote: > So just skip running the build_cmake target on MinGW/MSYS. In fact, if you svn update to revision 12982, then a build of the cmake software on MinGW/MSYS should no longer be available as an option so that you are forced to do the right thing on that platform which is to use the downloaded binary version from Kitware for all epa_builds. > Instead, build > the following individual targets for the -DBUILD_THE_BUILDTOOLS=ON > case: > > build_pkg-config > build_swig > build_iwidgets4.0 > build_iwidgets > > Those together build all the buildtools you are going to need. For > example, build_iwidgets4.0 automatically builds its dependencies (Tcl, > Tk, and old versions of Itcl and Itk), before actually building > Iwidgets 4.0. build_iwidgets is similar, but it uses different (much > more modern) Itcl and Itk builds that PLplot is currently not > completely compatible with (see > http://sourceforge.net/p/plplot/bugs/138/). So for now you won't be > using the results of build_iwidgets, but you should run that target > anyway to make sure it works (like it does for me) and so that > eventually you will be able to investigate bug 138. > > Let's use the first of the above targets (which is actually the > simplest of the bunch) for a test case. > > Please keep track of the results in the recommended way, e.g., > > ${BUILD_COMMAND} build_pkg-config >& build_pkg-config.out > > If that does not work (or you run into trouble with any of the other > targets mentioned above, send me the following essential files so I > can debug what is going on: > > 1. The files you indirectly and directly source from bash to define the > required environment variables. (i.e., the tailored versions of > cmake/epa_build/setup/setup_mingw_msys_wine_toolchain and > cmake/epa_build/setup/setup_msys_makefiles that you have created in > accordance with the README directions). > > 2. cmake.out (created when you follow the exact README directions for > the -DBUILD_THE_BUILDTOOLS=ON case). > > 3. CMakeCache.txt > > 4. build_pkg-config.out (or the corresponding file from the particular > above target that did not work). Even though the build_all target no longer includes the build_cmake target on the MinGW/MSYS platform, please continue with the above (one buildtool at a time) approach to make sure you run into no issues the first time you do these builds on MinGW/MSYS. Of course, once you show that everything works, the build_all target is much more convenient. 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 __________________________ |
|
From: Arjen Markus <Arjen.Markus@de...> - 2014-02-07 08:41:14
|
Hi Alan, okay, sounds like a plan :). With my head a bit clearer now, I will go ahead and try the targets one by one. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:irwin@...] > Sent: Friday, February 07, 2014 6:53 AM > To: Arjen Markus > Cc: PLplot development list > Subject: Re: [Plplot-devel] Still roughly on track for a February 12th release of 5.10.0 > > On 2014-02-06 10:10-0800 Alan W. Irwin wrote: > > > So just skip running the build_cmake target on MinGW/MSYS. > > In fact, if you svn update to revision 12982, then a build of the cmake software on > MinGW/MSYS should no longer be available as an option so that you are forced to > do the right thing on that platform which is to use the downloaded binary version from > Kitware for all epa_builds. > > > Instead, build > > the following individual targets for the -DBUILD_THE_BUILDTOOLS=ON > > case: > > > > build_pkg-config > > build_swig > > build_iwidgets4.0 > > build_iwidgets > > > > Those together build all the buildtools you are going to need. For > > example, build_iwidgets4.0 automatically builds its dependencies (Tcl, > > Tk, and old versions of Itcl and Itk), before actually building > > Iwidgets 4.0. build_iwidgets is similar, but it uses different (much > > more modern) Itcl and Itk builds that PLplot is currently not > > completely compatible with (see > > http://sourceforge.net/p/plplot/bugs/138/). So for now you won't be > > using the results of build_iwidgets, but you should run that target > > anyway to make sure it works (like it does for me) and so that > > eventually you will be able to investigate bug 138. > > > > Let's use the first of the above targets (which is actually the > > simplest of the bunch) for a test case. > > > > Please keep track of the results in the recommended way, e.g., > > > > ${BUILD_COMMAND} build_pkg-config >& build_pkg-config.out > > > > If that does not work (or you run into trouble with any of the other > > targets mentioned above, send me the following essential files so I > > can debug what is going on: > > > > 1. The files you indirectly and directly source from bash to define > > the required environment variables. (i.e., the tailored versions of > > cmake/epa_build/setup/setup_mingw_msys_wine_toolchain and > > cmake/epa_build/setup/setup_msys_makefiles that you have created in > > accordance with the README directions). > > > > 2. cmake.out (created when you follow the exact README directions for > > the -DBUILD_THE_BUILDTOOLS=ON case). > > > > 3. CMakeCache.txt > > > > 4. build_pkg-config.out (or the corresponding file from the particular > > above target that did not work). > > Even though the build_all target no longer includes the build_cmake target on the > MinGW/MSYS platform, please continue with the above (one buildtool at a time) > approach to make sure you run into no issues the first time you do these builds on > MinGW/MSYS. Of course, once you show that everything works, the build_all target > is much more convenient. > > 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 > __________________________ DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. Irwin <irwin@be...> - 2014-02-08 18:26:40
|
I have just heard off list from Arjen that he is up against a holiday deadline. Furthermore, I have run into a complete showstopper for MSYS2 (which I ascribe to a Wine bug). So since I have no use for the later release date I thought I would need for MSYS2 testing, and Arjen also cannot benefit from that later release date, I propose to revert back to February 12th for the release date (just 4 days from today). Is that fine with everybody? 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 __________________________ |
|
From: Alan W. Irwin <irwin@be...> - 2014-02-10 22:24:03
|
Hi Arjen: Please use the improved epa_build instructions you get with revision 12993. I have replaced the old ENABLE_COMPREHENSIVE_PLPLOT_TEST cmake option with COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE and COMPREHENSIVE_PLPLOT_TEST_NONINTERACTIVE to make it more convenient to split up interactive and noninteractive testing. This morning I finally got around to doing COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE=ON testing for MinGW/MSYS/Wine and I discovered some issues. All but one of those are fixed as of revision 12993. So for example, the test_c_ntk, test_c_wingcc, and test_tclsh_standard_examples targets (all dependencies of the test_interactive target) all work correctly. However, the test_pltcl_standard_examples target (also currently a dependency of the test_interactive target) generates an error with message "wine: Unhandled page fault on read access to 0x00867490 at address 0x867490 (thread 0034)" right near the end of the final page of example 33 (or perhaps just after that final page is completed). So this issue might be similar to http://sourceforge.net/p/plplot/bugs/139/. But there the wish environment failed while the plserver did not show the issue, while for the present case it is pltcl that shows the issue, while tclsh does not. I am now wondering whether this is just a Wine issue or a symptom of a a more general PLplot memory management issue whenever pltcl, plserver, tclsh, or wish exit from the standard examples case. Of course, as with any memory management issue, you sometimes get symptomless (i.e., good) results despite the memory management issue. So this hypothesis would explain why we get both good and bad results on different platforms and depending on whether the standard examples are being run by pltcl, tclsh, plserver, or wish. But, of course, the variety of results we are getting for the standard examples do not completely prove the hypothesis so the hypothesis is just something to keep in mind. >From this bad interactive result for MinGW/MSYS/Wine your priority for this release should be to make sure COMPREHENSIVE_PLPLOT_TEST_NONINTERACTIVE=ON works for the 32-bit Windows case like it currently does for MinGW/MSYS/Wine. Your second priority after that (if you have time before Wednesday) should be to try COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE=ON just to see if the same issue I just discovered on Wine shows up on 32-bit Microsoft Windows as well or whether you can get all the way through the comprehensive interactive tests on that platform. 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 __________________________ |
|
From: Arjen Markus <Arjen.Markus@de...> - 2014-02-11 09:13:02
|
Hi Alan,
I wrote a small test program to determine where the compile errors with SWIG were coming from and to ensure that my MinGW/MSYS installation is indeed 32 bits. The program is this:
/* test-compile.c --
Test a few things with regards to the problems to compile SWIG
under MinGW/MSYS
-DSTAT: compile with the "struct stat" structure
In any case: check the size of a pointer
*/
#include <stdio.h>
#ifdef STAT
#include <sys/stat.h>
#endif
int main( int argc, char *argv[] ) {
#ifdef STAT
struct stat st;
#endif
printf("Size of pointer: %d\n", sizeof(void *));
#ifdef STAT
printf("Size of struct stat: %d\n", sizeof(st));
#endif
}
I tried building this program under various environments with the -DSTAT flag. They all succeeded - no compile errors. The output from the programs was rather varied:
- Cygwin: pointer size 8, struc stat size 128 -- this is a 64-bits environment
- Windows+gcc 4.5.2: pointer size 4, struc stat size 36 -- a 32-bits environment
- Windows+MSVC/C++, 64-bits: pointer size 4, struc stat size 48 -- a 64-bits environment
- MinGW/MSYS+gcc 4.8.1: pointer size 4, struct stat size 48 - definitely a 32-bits environment!
The error messages with SWIG come from the flag -ansi:
$ gcc -o test-compile test-compile.c -DSTAT -ansi
test-compile.c: In function 'main':
test-compile.c:18:17: error: storage size of 'st' isn't known
struct stat st;
^
The real question is: where is the flag -ansi coming from? It appears together with -Wall -pedantic in the make files but I can not find its origins anywhere in PLplot or CMake (I have not checked the CMake executables, assuming all that sort of flags would be contained in the configuration files instead).
Okay, sofar that analysis. Now I will try your receipe.
Regards,
Arjen
> -----Original Message-----
> From: Alan W. Irwin [mailto:irwin@...]
> Sent: Monday, February 10, 2014 11:24 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Still roughly on track for a February 12th release of 5.10.0
>
> Hi Arjen:
>
> Please use the improved epa_build instructions you get with revision 12993. I have
> replaced the old ENABLE_COMPREHENSIVE_PLPLOT_TEST cmake option with
> COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE and
> COMPREHENSIVE_PLPLOT_TEST_NONINTERACTIVE to make it more
> convenient to split up interactive and noninteractive testing.
>
> This morning I finally got around to doing
> COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE=ON testing for
> MinGW/MSYS/Wine and I discovered some issues. All but one of those are fixed as
> of revision 12993. So for example, the test_c_ntk, test_c_wingcc, and
> test_tclsh_standard_examples targets (all dependencies of the test_interactive target)
> all work correctly. However, the test_pltcl_standard_examples target (also currently
> a dependency of the test_interactive target) generates an error with message "wine:
> Unhandled page fault on read access to 0x00867490 at address 0x867490 (thread
> 0034)" right near the end of the final page of example 33 (or perhaps just after that
> final page is completed). So this issue might be similar to
> http://sourceforge.net/p/plplot/bugs/139/. But there the wish environment failed while
> the plserver did not show the issue, while for the present case it is pltcl that shows
> the issue, while tclsh does not.
>
> I am now wondering whether this is just a Wine issue or a symptom of a a more
> general PLplot memory management issue whenever pltcl, plserver, tclsh, or wish
> exit from the standard examples case. Of course, as with any memory management
> issue, you sometimes get symptomless (i.e., good) results despite the memory
> management issue.
> So this hypothesis would explain why we get both good and bad results on different
> platforms and depending on whether the standard examples are being run by pltcl,
> tclsh, plserver, or wish. But, of course, the variety of results we are getting for the
> standard examples do not completely prove the hypothesis so the hypothesis is just
> something to keep in mind.
>
> From this bad interactive result for MinGW/MSYS/Wine your priority for this release
> should be to make sure
> COMPREHENSIVE_PLPLOT_TEST_NONINTERACTIVE=ON works for the 32-bit
> Windows case like it currently does for MinGW/MSYS/Wine. Your second priority
> after that (if you have time before Wednesday) should be to try
> COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE=ON just to see if the same
> issue I just discovered on Wine shows up on 32-bit Microsoft Windows as well or
> whether you can get all the way through the comprehensive interactive tests on that
> platform.
>
> 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
> __________________________
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
|
|
From: Arjen Markus <Arjen.Markus@de...> - 2014-02-11 09:20:22
|
Hi Alan,
I forgot to mention that the flag -ansi does not cause this error message under Cygwin.
Regards,
Arjen
> -----Original Message-----
> From: Arjen Markus [mailto:Arjen.Markus@...]
> Sent: Tuesday, February 11, 2014 10:13 AM
> To: Alan W. Irwin
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Still roughly on track for a February 12th release of 5.10.0
>
> Hi Alan,
>
> I wrote a small test program to determine where the compile errors with SWIG were
> coming from and to ensure that my MinGW/MSYS installation is indeed 32 bits. The
> program is this:
>
> /* test-compile.c --
> Test a few things with regards to the problems to compile SWIG
> under MinGW/MSYS
>
> -DSTAT: compile with the "struct stat" structure
>
> In any case: check the size of a pointer */ #include <stdio.h>
>
> #ifdef STAT
> #include <sys/stat.h>
> #endif
>
> int main( int argc, char *argv[] ) {
>
> #ifdef STAT
> struct stat st;
> #endif
>
> printf("Size of pointer: %d\n", sizeof(void *));
>
> #ifdef STAT
> printf("Size of struct stat: %d\n", sizeof(st)); #endif }
>
>
> I tried building this program under various environments with the -DSTAT flag. They
> all succeeded - no compile errors. The output from the programs was rather varied:
>
> - Cygwin: pointer size 8, struc stat size 128 -- this is a 64-bits environment
> - Windows+gcc 4.5.2: pointer size 4, struc stat size 36 -- a 32-bits environment
> - Windows+MSVC/C++, 64-bits: pointer size 4, struc stat size 48 -- a 64-bits
> environment
> - MinGW/MSYS+gcc 4.8.1: pointer size 4, struct stat size 48 - definitely a 32-bits
> environment!
>
> The error messages with SWIG come from the flag -ansi:
>
> $ gcc -o test-compile test-compile.c -DSTAT -ansi
> test-compile.c: In function 'main':
> test-compile.c:18:17: error: storage size of 'st' isn't known
> struct stat st;
> ^
>
> The real question is: where is the flag -ansi coming from? It appears together with -
> Wall -pedantic in the make files but I can not find its origins anywhere in PLplot or
> CMake (I have not checked the CMake executables, assuming all that sort of flags
> would be contained in the configuration files instead).
>
> Okay, sofar that analysis. Now I will try your receipe.
>
> Regards,
>
> Arjen
>
> > -----Original Message-----
> > From: Alan W. Irwin [mailto:irwin@...]
> > Sent: Monday, February 10, 2014 11:24 PM
> > To: Arjen Markus
> > Cc: PLplot development list
> > Subject: Re: [Plplot-devel] Still roughly on track for a February 12th
> > release of 5.10.0
> >
> > Hi Arjen:
> >
> > Please use the improved epa_build instructions you get with revision
> > 12993. I have replaced the old ENABLE_COMPREHENSIVE_PLPLOT_TEST
> cmake
> > option with COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE and
> > COMPREHENSIVE_PLPLOT_TEST_NONINTERACTIVE to make it more
> convenient to
> > split up interactive and noninteractive testing.
> >
> > This morning I finally got around to doing
> > COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE=ON testing for
> MinGW/MSYS/Wine
> > and I discovered some issues. All but one of those are fixed as of
> > revision 12993. So for example, the test_c_ntk, test_c_wingcc, and
> > test_tclsh_standard_examples targets (all dependencies of the
> > test_interactive target) all work correctly. However, the
> > test_pltcl_standard_examples target (also currently a dependency of the
> test_interactive target) generates an error with message "wine:
> > Unhandled page fault on read access to 0x00867490 at address 0x867490
> > (thread 0034)" right near the end of the final page of example 33 (or
> > perhaps just after that final page is completed). So this issue might
> > be similar to http://sourceforge.net/p/plplot/bugs/139/. But there
> > the wish environment failed while the plserver did not show the issue,
> > while for the present case it is pltcl that shows the issue, while tclsh does not.
> >
> > I am now wondering whether this is just a Wine issue or a symptom of a
> > a more general PLplot memory management issue whenever pltcl,
> > plserver, tclsh, or wish exit from the standard examples case. Of
> > course, as with any memory management issue, you sometimes get
> > symptomless (i.e., good) results despite the memory management issue.
> > So this hypothesis would explain why we get both good and bad results
> > on different platforms and depending on whether the standard examples
> > are being run by pltcl, tclsh, plserver, or wish. But, of course, the
> > variety of results we are getting for the standard examples do not
> > completely prove the hypothesis so the hypothesis is just something to keep in
> mind.
> >
> > From this bad interactive result for MinGW/MSYS/Wine your priority for
> > this release should be to make sure
> > COMPREHENSIVE_PLPLOT_TEST_NONINTERACTIVE=ON works for the 32-bit
> > Windows case like it currently does for MinGW/MSYS/Wine. Your second
> > priority after that (if you have time before Wednesday) should be to
> > try COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE=ON just to see if the
> same
> > issue I just discovered on Wine shows up on 32-bit Microsoft Windows
> > as well or whether you can get all the way through the comprehensive
> > interactive tests on that platform.
> >
> > 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
> > __________________________
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and may
> contain confidential and privileged information. If you are not the intended recipient
> please notify the sender immediately and destroy this message. Unauthorized use,
> disclosure or copying of this message is strictly prohibited. The foundation 'Stichting
> Deltares', which has its seat at Delft, The Netherlands, Commercial Registration
> Number 41146461, is not liable in any way whatsoever for consequences and/or
> damages resulting from the improper, incomplete and untimely dispatch, receipt
> and/or content of this e-mail.
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
|
|
From: Alan W. Irwin <irwin@be...> - 2014-02-11 09:50:54
|
On 2014-02-11 09:12-0000 Arjen Markus wrote: > The error messages with SWIG come from the flag -ansi: > > $ gcc -o test-compile test-compile.c -DSTAT -ansi > test-compile.c: In function 'main': > test-compile.c:18:17: error: storage size of 'st' isn't known > struct stat st; > ^ > > The real question is: where is the flag -ansi coming from? It appears together with -Wall -pedantic in the make files but I can not find its origins anywhere in PLplot or CMake (I have not checked the CMake executables, assuming all that sort of flags would be contained in the configuration files instead). > Remember, although epa_build is configured with CMake, that is just a convenient but rather thin layer over the configure and build done by a project's native build system. In the swig case, that native build system is autotools, and the configuration is done with a "configure" script that is set up by autotools. That script is where the above flags are coming from. However, those flags gave me absolutely no trouble for the swig build on MinGW/MSYS/Wine. I hope that explanation helps. 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 __________________________ |
|
From: Arjen Markus <Arjen.Markus@de...> - 2014-02-11 14:10:23
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:irwin@...] > > Remember, although epa_build is configured with CMake, that is just a convenient > but rather thin layer over the configure and build done by a project's native build > system. In the swig case, that native build system is autotools, and the configuration > is done with a "configure" > script that is set up by autotools. That script is where the above flags are coming > from. However, those flags gave me absolutely no trouble for the swig build on > MinGW/MSYS/Wine. > > I hope that explanation helps. > That does indeed help. I was simply looking in the wrong place. However, if it works for you, then is it possible you have a different version of GCC? Mine is (output from "gcc -v"): Using built-in specs. COLLECT_GCC=c:\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T Thread model: win32 gcc version 4.8.1 (GCC) Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. Irwin <irwin@be...> - 2014-02-11 17:41:53
|
On 2014-02-11 14:10-0000 Arjen Markus wrote: > Hi Alan, > >> -----Original Message----- >> From: Alan W. Irwin [mailto:irwin@...] >> >> Remember, although epa_build is configured with CMake, that is just a convenient >> but rather thin layer over the configure and build done by a project's native build >> system. In the swig case, that native build system is autotools, and the configuration >> is done with a "configure" >> script that is set up by autotools. That script is where the above flags are coming >> from. However, those flags gave me absolutely no trouble for the swig build on >> MinGW/MSYS/Wine. >> >> I hope that explanation helps. >> > > That does indeed help. I was simply looking in the wrong place. > > However, if it works for you, then is it possible you have a different version of GCC? > Mine is (output from "gcc -v"): > > Using built-in specs. > COLLECT_GCC=c:\mingw\bin\gcc.exe > COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe > Target: mingw32 > Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T > Thread model: win32 > gcc version 4.8.1 (GCC) > I used gcc-4.7.2 (see the description of my test in README.release). So that _could_ be a source of a possible difference between us, but that seems fairly unlikely to me. However, in your previous post you did seem able to prove that MinGW was definitely producing 32-bit results for your present environment. And you went on to say > Okay, sofar that analysis. Now I will try your receipe. Does that mean you have gone ahead with the epa_build comprehensive test? If so, what are 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 __________________________ |