From: Hazen B. <hba...@ma...> - 2009-01-18 22:50:25
|
Hello, Version 5.9.2 of PLplot is now available. Major improvements since 5.9.1 include an extended testing framework which automatically tests plotting results across the multiple languages supported by PLplot. There is now rigorous testing in place for almost all of the common API and this has already allowed us track down a number of bugs. As always, (1) Please refer to our wiki for the latest build and install instructions (http://www.miscdebris.net/plplot_wiki/index.php?title=Main_Page) and (2) Let us know of any problems / bugs that you run across while installing / using PLplot. best, -Hazen |
From: Hazen B. <hba...@ma...> - 2009-05-03 21:56:29
|
Hello, Version 5.9.3 of PLplot is now available. Improvements since 5.9.2 include the addition of a Qt device driver thanks to the efforts of Alban Rochel and the QSAS team. As always: (1) Please refer to our wiki for the latest build and install instructions (http://www.miscdebris.net/plplot_wiki/index.php?title=Main_Page) (2) Let us know of any problems / bugs that you run across while installing / using PLplot. best, -Hazen |
From: Hazen B. <hba...@ma...> - 2009-05-04 00:05:04
|
Marius Schamschula wrote: > Hazen, > > When building plplot 5.9.3 under Mac OS X I get the following error: > > [ 66%] Generating test_dyndrivers_dir/aqt.rc > cd /tmp/plplot-5.9.3/drivers && ./test-drv-info aqt > > /tmp/plplot-5.9.3/drivers/test_dyndrivers_dir/aqt.rc > cd /tmp/plplot-5.9.3/drivers && /usr/local/bin/cmake -E compare_files > /tmp/plplot-5.9.3/drivers/test_dyndrivers_dir/aqt.rc > /tmp/plplot-5.9.3/drivers/aqt.rc > Files "/tmp/plplot-5.9.3/drivers/test_dyndrivers_dir/aqt.rc" to > "/tmp/plplot-5.9.3/drivers/aqt.rc" are different. > make[2]: *** [drivers/test_dyndrivers_dir/aqt.rc] Error 1 > make[2]: Leaving directory `/private/tmp/plplot-5.9.3' > make[1]: *** [drivers/CMakeFiles/test_dyndrivers.dir/all] Error 2 > make[1]: Leaving directory `/private/tmp/plplot-5.9.3' > make: *** [all] Error 2 > > Any ideas? Hm. I see that I have the same problem on my OS-X box. In my case it looks like the second aqt.rc file is missing (the one that is supposed to be in "drivers/" directory). I was able to recover by hand copying the "drivers/test_dyndrivers_dir/aqt.rc" file to "drivers/aqt.rc" and running make again. -Hazen |
From: Alan W. I. <ir...@be...> - 2009-05-04 03:01:18
|
On 2009-05-03 20:04-0400 Hazen Babcock wrote: > Marius Schamschula wrote: >> Hazen, >> >> When building plplot 5.9.3 under Mac OS X I get the following error: >> >> [ 66%] Generating test_dyndrivers_dir/aqt.rc >> cd /tmp/plplot-5.9.3/drivers && ./test-drv-info aqt > >> /tmp/plplot-5.9.3/drivers/test_dyndrivers_dir/aqt.rc >> cd /tmp/plplot-5.9.3/drivers && /usr/local/bin/cmake -E compare_files >> /tmp/plplot-5.9.3/drivers/test_dyndrivers_dir/aqt.rc >> /tmp/plplot-5.9.3/drivers/aqt.rc >> Files "/tmp/plplot-5.9.3/drivers/test_dyndrivers_dir/aqt.rc" to >> "/tmp/plplot-5.9.3/drivers/aqt.rc" are different. >> make[2]: *** [drivers/test_dyndrivers_dir/aqt.rc] Error 1 >> make[2]: Leaving directory `/private/tmp/plplot-5.9.3' >> make[1]: *** [drivers/CMakeFiles/test_dyndrivers.dir/all] Error 2 >> make[1]: Leaving directory `/private/tmp/plplot-5.9.3' >> make: *** [all] Error 2 >> >> Any ideas? > > Hm. I see that I have the same problem on my OS-X box. In my case it > looks like the second aqt.rc file is missing (the one that is supposed > to be in "drivers/" directory). I was able to recover by hand copying > the "drivers/test_dyndrivers_dir/aqt.rc" file to "drivers/aqt.rc" and > running make again. Hi Hazen: It seems we have a "brown-paper-bag" release bug for Mac OS X to quote Linus. Don't feel too bad about this, Hazen. You are in good company here. It happened to me as well for one of my earlier releases, and for many other projects including the Linux kernel (where Linus just wanted to pull a brown bag over his head and hide to reduce the embarrassment factor of a flawed kernel release). See 1.2 in README.release for the background on why *.rc files are handled differently now. The proper fix is to copy aqt.rc to drivers/aqt.rc.in in the source tree (which I assume you did before since otherwise your OS X tests wouldn't have worked at all), but remember to commit that aqt.rc.in file to svn. This is the reason why it is important to use "svn status" to make sure you don't have any uncommitted files when you are testing the svn version. I double-checked and don't see any other missing *.rc.in files there for any device that we still use. It appears Mac OS X users of 5.9.3 are going to have to patch their systems for the entirety of the 5.9.3 release cycle. To reduce that user pain as much as possible, I suggest that release cycle should be shortened as much as possible. Thus, Hazen, once you are happy with your Mac OS X tests, I suggest you do a full 5.9.4 release today (Sunday) or tomorrow remembering to repeat all the version-specific stuff in README.Release_Manager_Cookbook for 5.9.4. Meanwhile, every other developer should refrain from commits to give Hazen a clear field to deal with this simple, but nevertheless embarrassing 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); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@de...> - 2009-05-08 07:38:58
|
On 2009-05-05 09:47, Werner Smekal wrote: > Hi Arjen, >> >> I do not know whether I will be able to solve the Fortran issue on >> Windows before this weekend - it would involve building static AND >> dynamic libraries at the same time. I do not quite know how to do >> that. > > why that? As long as the names are not the same (which is the case for > cygwin I think, but not for bare windows), you could just use > > add_library( f77shared SHARED ...) > add_library( f77static STATIC ...) > > I think you still need to name the targets different, but then set the > output name to the expected one with: > > set_target_properties( f77static PROPERTIES OUTPUT_NAME f77correct > CLEAN_DIRECT_OUTPUT 1) > > the CLEAN_DIRECT_OUTPUT 1 is also needed, look here: > > http://www.mail-archive.com/cm...@cm.../msg04743.html > http://www.mail-archive.com/cm...@cm.../msg04746.html > Hi Werner, I have been able to implement the correct logic for this issue. Here are a few notes: - If you build with dynamic libraries on Windows using Cygwin, MinGW or MSYS, then an additional _static_ library is made, which contains the plparseopts routine. This ensures that the Fortran run-time library correctly passes all the arguments. - I made changes in several files to ensure that this works properly - the check for the functionality of command-line arguments is now done for both FORTRAN 77 and Fortran 95. - In the post-release phase I intend to change the test to a more "semantic" one, but that is more involved than I had time for now. Separate issues regarding the present state: - I have a problem with example x20f for Fortran 95 with one single compiler (the "tdm" release of gfortran under MinGW). It fails to read the temporary file created for the header of the picture file. Really odd. (The F77 version works fine with that same compiler) - If I do not set the path to include my winbash installation, the build sometimes fails at the point where pkgIndex.tcl is handled (only MinGW). Not sure how - I have not been able to trace the error in the makefiles yet (the error message is non-informative) - Testing the Tcl examples remains an issue - I need to set TCL_LIBRARY before running the tests. Something to look into after 5.9.4. - Tk is recognised under Cygwin, but the build fails because of a few UNIX/Linux-specific functions that are not available under Cygwin. Regards, Arjen Regards, Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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: Andrew R. <and...@us...> - 2009-05-08 18:24:34
|
On Fri, May 08, 2009 at 09:38:45AM +0200, Arjen Markus wrote: > On 2009-05-05 09:47, Werner Smekal wrote: > > Hi Arjen, > >> > >> I do not know whether I will be able to solve the Fortran issue on > >> Windows before this weekend - it would involve building static AND > >> dynamic libraries at the same time. I do not quite know how to do > >> that. > > > > why that? As long as the names are not the same (which is the case for > > cygwin I think, but not for bare windows), you could just use > > > > add_library( f77shared SHARED ...) > > add_library( f77static STATIC ...) > > > > I think you still need to name the targets different, but then set the > > output name to the expected one with: > > > > set_target_properties( f77static PROPERTIES OUTPUT_NAME f77correct > > CLEAN_DIRECT_OUTPUT 1) > > > > the CLEAN_DIRECT_OUTPUT 1 is also needed, look here: > > > > http://www.mail-archive.com/cm...@cm.../msg04743.html > > http://www.mail-archive.com/cm...@cm.../msg04746.html > > > > Hi Werner, > > I have been able to implement the correct logic for this issue. > Here are a few notes: > > - If you build with dynamic libraries on Windows using Cygwin, MinGW or > MSYS, then an additional _static_ library is made, which contains > the plparseopts routine. This ensures that the Fortran run-time > library correctly passes all the arguments. > > - I made changes in several files to ensure that this works properly - > the check for the functionality of command-line arguments is now > done for both FORTRAN 77 and Fortran 95. > > - In the post-release phase I intend to change the test to a more > "semantic" one, but that is more involved than I had time for now. > > Separate issues regarding the present state: > > - I have a problem with example x20f for Fortran 95 with one single > compiler (the "tdm" release of gfortran under MinGW). It fails to > read the temporary file created for the header of the picture file. > Really odd. (The F77 version works fine with that same compiler) > > - If I do not set the path to include my winbash installation, the > build sometimes fails at the point where pkgIndex.tcl is handled > (only MinGW). Not sure how - I have not been able to trace the error > in the makefiles yet (the error message is non-informative) > > - Testing the Tcl examples remains an issue - I need to set TCL_LIBRARY > before running the tests. Something to look into after 5.9.4. > > - Tk is recognised under Cygwin, but the build fails because of a > few UNIX/Linux-specific functions that are not available under Cygwin. The tk code is currently written in a unix-specific manner. The tk driver makes use of fifo pipes / sockets to communicate which may not be available on other platforms? Also the plframe code in bindings/tk uses the xwin driver, so as is it probably won't work on windows. This has not been widely used or supported in recent years so no-one has ever tried to make it (or at least parts of it) compatible with other operating systems. Perhaps it would be better to disable the tk code in cmake unless you are on a unix platform? Andrew |
From: Hazen B. <hba...@ma...> - 2009-05-04 13:17:03
|
Alan W. Irwin wrote: > On 2009-05-03 20:04-0400 Hazen Babcock wrote: > >> Marius Schamschula wrote: >>> Hazen, >>> >>> When building plplot 5.9.3 under Mac OS X I get the following error: >>> >>> [ 66%] Generating test_dyndrivers_dir/aqt.rc >>> cd /tmp/plplot-5.9.3/drivers && ./test-drv-info aqt > >>> /tmp/plplot-5.9.3/drivers/test_dyndrivers_dir/aqt.rc >>> cd /tmp/plplot-5.9.3/drivers && /usr/local/bin/cmake -E compare_files >>> /tmp/plplot-5.9.3/drivers/test_dyndrivers_dir/aqt.rc >>> /tmp/plplot-5.9.3/drivers/aqt.rc >>> Files "/tmp/plplot-5.9.3/drivers/test_dyndrivers_dir/aqt.rc" to >>> "/tmp/plplot-5.9.3/drivers/aqt.rc" are different. >>> make[2]: *** [drivers/test_dyndrivers_dir/aqt.rc] Error 1 >>> make[2]: Leaving directory `/private/tmp/plplot-5.9.3' >>> make[1]: *** [drivers/CMakeFiles/test_dyndrivers.dir/all] Error 2 >>> make[1]: Leaving directory `/private/tmp/plplot-5.9.3' >>> make: *** [all] Error 2 >>> >>> Any ideas? >> >> Hm. I see that I have the same problem on my OS-X box. In my case it >> looks like the second aqt.rc file is missing (the one that is supposed >> to be in "drivers/" directory). I was able to recover by hand copying >> the "drivers/test_dyndrivers_dir/aqt.rc" file to "drivers/aqt.rc" and >> running make again. > > Hi Hazen: > > It seems we have a "brown-paper-bag" release bug for Mac OS X to quote > Linus. Don't feel too bad about this, Hazen. You are in good company > here. > It happened to me as well for one of my earlier releases, and for many > other > projects including the Linux kernel (where Linus just wanted to pull a > brown > bag over his head and hide to reduce the embarrassment factor of a flawed > kernel release). > > See 1.2 in README.release for the background on why *.rc files are handled > differently now. The proper fix is to copy aqt.rc to drivers/aqt.rc.in in > the source tree (which I assume you did before since otherwise your OS X > tests wouldn't have worked at all), but remember to commit that aqt.rc.in > file to svn. This is the reason why it is important to use "svn status" to > make sure you don't have any uncommitted files when you are testing the svn > version. I double-checked and don't see any other missing *.rc.in files > there for any device that we still use. > > It appears Mac OS X users of 5.9.3 are going to have to patch their systems > for the entirety of the 5.9.3 release cycle. To reduce that user pain as > much as possible, I suggest that release cycle should be shortened as much > as possible. Thus, Hazen, once you are happy with your Mac OS X tests, I > suggest you do a full 5.9.4 release today (Sunday) or tomorrow remembering > to repeat all the version-specific stuff in README.Release_Manager_Cookbook > for 5.9.4. > > Meanwhile, every other developer should refrain from commits to give > Hazen a > clear field to deal with this simple, but nevertheless embarrassing issue. Well I hope someone will step up and fix the example 32 problem I mentioned. -Hazen |
From: Alan W. I. <ir...@be...> - 2009-05-04 17:20:29
|
On 2009-05-04 09:16-0400 Hazen Babcock wrote: > Alan W. Irwin wrote: >> Hi Hazen: >> [...]It appears Mac OS X users of 5.9.3 are going to have to patch their systems >> for the entirety of the 5.9.3 release cycle. To reduce that user pain as >> much as possible, I suggest that release cycle should be shortened as much >> as possible. Thus, Hazen, once you are happy with your Mac OS X tests, I >> suggest you do a full 5.9.4 release today (Sunday) or tomorrow remembering >> to repeat all the version-specific stuff in README.Release_Manager_Cookbook >> for 5.9.4. >> >> Meanwhile, every other developer should refrain from commits to give Hazen >> a >> clear field to deal with this simple, but nevertheless embarrassing issue. > > Well I hope someone will step up and fix the example 32 problem I mentioned. That example is a special one which is still being developed/considered. >From the commit message for examples/c/x32c.c "For now this is built automatically, but not included in the test suite or propagated to other languages. Please leave this way until it has been discussed further on plplot-devel." Therefore, you should ignore this example for at least this bug-fix release or patch. I have just mentioned the possibility of a patch instead of a formal release because I think speed is essential. So if you don't have time to do a formal 5.9.4 release today (with especial care taken to get the version numbers and everything that depends on them like the website updated consistently) we could propagate a macosx patch to 5.9.3 (called, e.g., plplot-5.9.3.macosx.patch which should be largely self-explanatory) instead. If you prefer the patch approach, I would need you to first create a tested aqt.rc.in file and commit it. After that I could do everything else, i.e., generate the patch, propagate it to SF, make the associated announcement, etc. This approach adds a patch file that macosx users have to download and apply so it is probably not as good as a formal 5.9.4 release. However, a formal 5.9.4 release takes more time, and if you are tired or rushed there are some possibilities for screwing up the version numbers in an inconsistent way unless you religiously follow README.Release_Manager_Cookbook. Let me know which approach you want to 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); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2009-05-04 17:43:45
|
On Mon, May 04, 2009 at 10:20:04AM -0700, Alan Irwin wrote: > On 2009-05-04 09:16-0400 Hazen Babcock wrote: > > > Alan W. Irwin wrote: > >> Hi Hazen: > >> [...]It appears Mac OS X users of 5.9.3 are going to have to patch their systems > >> for the entirety of the 5.9.3 release cycle. To reduce that user pain as > >> much as possible, I suggest that release cycle should be shortened as much > >> as possible. Thus, Hazen, once you are happy with your Mac OS X tests, I > >> suggest you do a full 5.9.4 release today (Sunday) or tomorrow remembering > >> to repeat all the version-specific stuff in README.Release_Manager_Cookbook > >> for 5.9.4. > >> > >> Meanwhile, every other developer should refrain from commits to give Hazen > >> a > >> clear field to deal with this simple, but nevertheless embarrassing issue. > > > > Well I hope someone will step up and fix the example 32 problem I mentioned. > > That example is a special one which is still being developed/considered. > >From the commit message for examples/c/x32c.c > > "For now this is built automatically, but not included in the test suite > or propagated to other languages. Please leave this way until it has > been discussed further on plplot-devel." > > Therefore, you should ignore this example for at least this bug-fix release > or patch. > > I have just mentioned the possibility of a patch instead of a formal release > because I think speed is essential. So if you don't have time to do a > formal 5.9.4 release today (with especial care taken to get the version > numbers and everything that depends on them like the website updated > consistently) we could propagate a macosx patch to 5.9.3 (called, e.g., > plplot-5.9.3.macosx.patch which should be largely self-explanatory) instead. > > If you prefer the patch approach, I would need you to first create a tested > aqt.rc.in file and commit it. After that I could do everything else, i.e., > generate the patch, propagate it to SF, make the associated announcement, > etc. This approach adds a patch file that macosx users have to download and > apply so it is probably not as good as a formal 5.9.4 release. However, a > formal 5.9.4 release takes more time, and if you are tired or rushed there > are some possibilities for screwing up the version numbers in an > inconsistent way unless you religiously follow > README.Release_Manager_Cookbook. > > Let me know which approach you want to do. Maybe a patch now and a short release cycle? There are a number of outstanding issues (e.g. the qt visibility issue, pngcairo segfaults when repeatedly calling plinit / plend ) which might merit a fairly speed next release. Andrew |
From: Hazen B. <hba...@ma...> - 2009-05-04 20:57:33
|
Alan W. Irwin wrote: > On 2009-05-04 09:16-0400 Hazen Babcock wrote: > >> Well I hope someone will step up and fix the example 32 problem I mentioned. > > That example is a special one which is still being developed/considered. >>From the commit message for examples/c/x32c.c > > "For now this is built automatically, but not included in the test suite > or propagated to other languages. Please leave this way until it has > been discussed further on plplot-devel." Ok, but... It has already made its way into www/examples.php with the commit message "Ensure example 32 is propagated to the website. Note currently C-only.". Should it be yanked back out? > Therefore, you should ignore this example for at least this bug-fix release > or patch. > > I have just mentioned the possibility of a patch instead of a formal release > because I think speed is essential. So if you don't have time to do a > formal 5.9.4 release today (with especial care taken to get the version > numbers and everything that depends on them like the website updated > consistently) we could propagate a macosx patch to 5.9.3 (called, e.g., > plplot-5.9.3.macosx.patch which should be largely self-explanatory) instead. I could do another release this weekend. Based on the reports from Orion, it sounds like we have some other things to cleanup anyway. Perhaps a news item? Or a post to both mailing lists? The "cp" fix seems about as easy as a patch. I don't have access to an OS-X box at the moment anyway, so the soonest anything is going to happen is tonight or tomorrow morning. -Hazen |
From: Alan W. I. <ir...@be...> - 2009-05-04 23:21:18
|
On 2009-05-04 16:57-0400 Hazen Babcock wrote: > Alan W. Irwin wrote: >> On 2009-05-04 09:16-0400 Hazen Babcock wrote: >> >>> Well I hope someone will step up and fix the example 32 problem I >>> mentioned. >> >> That example is a special one which is still being developed/considered. >>> From the commit message for examples/c/x32c.c >> >> "For now this is built automatically, but not included in the test suite or >> propagated to other languages. Please leave this way until it has been >> discussed further on plplot-devel." > > Ok, but... It has already made its way into www/examples.php with the commit > message "Ensure example 32 is propagated to the website. Note currently > C-only.". Should it be yanked back out? Sorry I missed the fact this issue makes for a slightly broken website (as can be seen at http://plplot.sourceforge.net/examples.php). I will fix that website issue before next weekend's release (see comment below) which will give a result that is consistent with Andrew's expressed desire to have example 32 on the website, but not ctested or propagated to other languages (yet). > I could do another release this weekend. Based on the reports from Orion, it > sounds like we have some other things to cleanup anyway. Perhaps a news item? > Or a post to both mailing lists? The "cp" fix seems about as easy as a patch. Ok, you have convinced me. Let's go for 5.9.4 next weekend with a news item and plplot-general note about the "cp" fix for 5.9.3. I will take responsibility for most of the issues that have come up recently (e.g., those mentioned by Orion, Hez's remaining patch, etc.), and I assume you will take responsibility for the missing aqt.rc.in file. Note, Werner has already committed some additional D examples. Also note I am going to try really hard to get the planned libqsastime stuff done by Thursday which should allow 1-2 days for testing of that change before the 5.9.4 release. Of course, Werner's added examples and my libqsastime work will make 5.9.4 more than just a bug fix release which has its advantages and disadvantages. However, I have some time constraints coming up so if I don't finish off libqsastime now, it might be delayed quite a while. 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); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2009-05-05 00:42:52
|
On 2009-05-04 16:20-0700 Alan W. Irwin wrote: >> Ok, but... It has already made its way into www/examples.php with the commit >> message "Ensure example 32 is propagated to the website. Note currently >> C-only.". Should it be yanked back out? > > Sorry I missed the fact this issue makes for a slightly broken website (as > can be seen at http://plplot.sourceforge.net/examples.php). I will fix that > website issue [...]. Done, revision 9900. My local version of the website looks good now for example 32. I haven't bothered to upload it to SF. 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); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hazen B. <hba...@ma...> - 2009-05-04 23:32:20
|
That didn't take long... If you are trying to compile 5.9.3 on OS-X with the Aquaterm driver and you get something like the following message: > > [ 66%] Generating test_dyndrivers_dir/aqt.rc > cd /tmp/plplot-5.9.3/drivers && ./test-drv-info aqt > > /tmp/plplot-5.9.3/drivers/test_dyndrivers_dir/aqt.rc > cd /tmp/plplot-5.9.3/drivers && /usr/local/bin/cmake -E compare_files > /tmp/plplot-5.9.3/drivers/test_dyndrivers_dir/aqt.rc > /tmp/plplot-5.9.3/drivers/aqt.rc > Files "/tmp/plplot-5.9.3/drivers/test_dyndrivers_dir/aqt.rc" to > "/tmp/plplot-5.9.3/drivers/aqt.rc" are different. > make[2]: *** [drivers/test_dyndrivers_dir/aqt.rc] Error 1 > make[2]: Leaving directory `/private/tmp/plplot-5.9.3' > make[1]: *** [drivers/CMakeFiles/test_dyndrivers.dir/all] Error 2 > make[1]: Leaving directory `/private/tmp/plplot-5.9.3' > make: *** [all] Error 2 The solution is to copy the missing aqt.rc file from "drivers/test_dyndrivers_dir/" to "drivers/" and then run make again. We plan to fix this problem (and a few others) with a 5.9.4 release of PLplot, which will created this weekend (likely Sunday the 10th). best, -Hazen |
From: Hazen B. <hba...@ma...> - 2009-05-05 21:48:13
|
Alan W. Irwin wrote: > On 2009-05-04 16:57-0400 Hazen Babcock wrote: > >> I could do another release this weekend. Based on the reports from >> Orion, it sounds like we have some other things to cleanup anyway. >> Perhaps a news item? Or a post to both mailing lists? The "cp" fix >> seems about as easy as a patch. > > Ok, you have convinced me. Let's go for 5.9.4 next weekend with a news > item > and plplot-general note about the "cp" fix for 5.9.3. I managed to add the news item today. For some reason I could not Yesterday, perhaps because my quota is 1 item per week :). I'll most likely do the release Sunday afternoon EST. Thank you Werner for providing the missing aqt.rc.in file. -Hazen |
From: Hazen B. <hba...@ma...> - 2009-09-06 22:03:44
|
Hello, Version 5.9.5 of PLplot is now available. Improvements since 5.9.4 include a PyQt interface based on our new Qt device driver, Color palette support to simplify changing PLplot's default colors and off-screen rendering for the xcairo driver for improved rendering speed. As always: (1) Please refer to our wiki for the latest build and install instructions. (http://www.miscdebris.net/plplot_wiki/index.php?title=Main_Page) (2) Let us know of any problems / bugs that you come across while installing / using PLplot. -Hazen |
From: Alan W. I. <ir...@be...> - 2009-05-05 07:13:55
|
On 2009-05-04 16:20-0700 Alan W. Irwin wrote: > I will take responsibility for most of the issues that have come up recently > (e.g., those mentioned by Orion, Hez's remaining patch, etc.) As of revision 9914 I have dealt with a whole bunch of these little irritating bugs and done the corresponding install-tree testing. That's all the bug fixing I plan to do for 5.9.4. > and I assume > you will take responsibility for the missing aqt.rc.in file. Other than that release critical aqt.rc.in issue, there are two other recently discovered PLplot issues that I am aware of. Neither is release critical, but it would be nice if somebody got one or both of them fixed for 5.9.4. * The plserver (but not pltcl) issue with 'invalid command name "plrandd"' generated by example 17 that I recently discovered for both the -DENABLE_DYNDRIVERS=OFF and -DBUILD_SHARED_LIBS=OFF cases. Somebody with Tk expertise will have to deal with this really strange result. * The plend1/plend issue. plend is not very different from plend1 so hopefully someone can figure this out in short order. > > Note, Werner has already committed some additional D examples. Also note I > am going to try really hard to get the planned libqsastime stuff done by > Thursday which should allow 1-2 days for testing of that change before the > 5.9.4 release. Of course, Werner's added examples and my libqsastime work > will make 5.9.4 more than just a bug fix release which has its advantages > and disadvantages. However, I have some time constraints coming up so if I > don't finish off libqsastime now, it might be delayed quite a while. I note Werner is still working on implementing more D examples for 5.9.4 (good), and I hope to finish the libqsastime ToDo list by Thursday now that I have finished the minor bug fixes that I was taking responsibility for. 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); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@de...> - 2009-05-05 07:18:03
|
On 2009-05-05 09:13, Alan W. Irwin wrote: > On 2009-05-04 16:20-0700 Alan W. Irwin wrote: > > > * The plserver (but not pltcl) issue with 'invalid command name "plrandd"' > generated by example 17 that I recently discovered for both the > -DENABLE_DYNDRIVERS=OFF and -DBUILD_SHARED_LIBS=OFF cases. Somebody with Tk > expertise will have to deal with this really strange result. > I will have a look at that, if nobody else solves it first. I do not know whether I will be able to solve the Fortran issue on Windows before this weekend - it would involve building static AND dynamic libraries at the same time. I do not quite know how to do that. Regards, Arjen Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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: Werner S. <sm...@ia...> - 2009-05-05 07:48:24
|
Hi Arjen, > > I do not know whether I will be able to solve the Fortran issue on > Windows before this weekend - it would involve building static AND > dynamic libraries at the same time. I do not quite know how to do > that. why that? As long as the names are not the same (which is the case for cygwin I think, but not for bare windows), you could just use add_library( f77shared SHARED ...) add_library( f77static STATIC ...) I think you still need to name the targets different, but then set the output name to the expected one with: set_target_properties( f77static PROPERTIES OUTPUT_NAME f77correct CLEAN_DIRECT_OUTPUT 1) the CLEAN_DIRECT_OUTPUT 1 is also needed, look here: http://www.mail-archive.com/cm...@cm.../msg04743.html http://www.mail-archive.com/cm...@cm.../msg04746.html Maybe this is of any help to you. Regards, Werner > > Regards, > > Arjen > > > Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of > TNO and parts of Rijkswaterstaat have joined forces in a new > independent institute for delta technology, Deltares. Deltares > combines knowledge and experience in the field of water, soil and > the subsurface. We provide innovative solutions to make living in > deltas, coastal areas and river basins safe, clean and sustainable. > > > > 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. > > > > > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! > Your > production scanning environment may not be a perfect world - but > thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW > KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Arjen M. <arj...@de...> - 2009-05-05 08:31:33
|
On 2009-05-05 09:47, Werner Smekal wrote: > Hi Arjen, >> >> I do not know whether I will be able to solve the Fortran issue on >> Windows before this weekend - it would involve building static AND >> dynamic libraries at the same time. I do not quite know how to do >> that. > > why that? As long as the names are not the same (which is the case for > cygwin I think, but not for bare windows), you could just use > > add_library( f77shared SHARED ...) > add_library( f77static STATIC ...) > > I think you still need to name the targets different, but then set the > output name to the expected one with: > > set_target_properties( f77static PROPERTIES OUTPUT_NAME f77correct > CLEAN_DIRECT_OUTPUT 1) > > the CLEAN_DIRECT_OUTPUT 1 is also needed, look here: > > http://www.mail-archive.com/cm...@cm.../msg04743.html > http://www.mail-archive.com/cm...@cm.../msg04746.html > > Maybe this is of any help to you. > Hi Werner, this will certainly be of help! I was unaware of this way of selecting the type of build (I examined the CMakeLists.txt file but did not see this) Regards, Arjen Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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 M. <arj...@de...> - 2009-05-07 06:50:30
|
On 2009-05-05 09:47, Werner Smekal wrote: > Hi Arjen, >> >> I do not know whether I will be able to solve the Fortran issue on >> Windows before this weekend - it would involve building static AND >> dynamic libraries at the same time. I do not quite know how to do >> that. > > why that? As long as the names are not the same (which is the case for > cygwin I think, but not for bare windows), you could just use > > add_library( f77shared SHARED ...) > add_library( f77static STATIC ...) > > I think you still need to name the targets different, but then set the > output name to the expected one with: > > set_target_properties( f77static PROPERTIES OUTPUT_NAME f77correct > CLEAN_DIRECT_OUTPUT 1) > > the CLEAN_DIRECT_OUTPUT 1 is also needed, look here: > > http://www.mail-archive.com/cm...@cm.../msg04743.html > http://www.mail-archive.com/cm...@cm.../msg04746.html > Hi Werner, I am definitely making progress with this issue. I create a static library from the file configurable.f for WIN32 platforms only and apart from the ordering of the libraries, it works. It would be nicer to limit this to the platforms that really need it - write a separate test for it, I suppose - but I will use the heuristic that it is needed for Windows with Cygwin or MinGW/MSYS only. This is easy to do and will cover all known cases. I will worry about a better way after the 5.9.4 release. Regards, Arjen Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 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. |