From: Andrew R. <and...@us...> - 2011-12-03 09:01:14
|
I have just committed a fairly large update to change the 2d arrays in our API from const PLFLT ** to const PLFLT * const *. Gcc warns about the use of const PLFLT ** because it only guarantees that the data is constant not the array of pointers to the data. It is therefore trivial to change the data by changing the pointers which is not what is intended. Both the pointer array and the data need to be marked const. This is quite intrusive, but it seems to work ok for me. Please check. It is strictly an API change however existing code should still compile fine (possibly with warnings depending on the gcc settings). This does not remove all warnings - just shifts them (more later). It does however make the API and the examples clean which I think is more important for users. The const PLFLT * const * is a bit unwieldy however, so I propose making a new typedef (something like PLFLT_2D_CONST) to tidy up the code. Andrew |
From: Alan W. I. <ir...@be...> - 2011-12-03 17:51:39
|
On 2011-12-03 09:01-0000 Andrew Ross wrote: > > I have just committed a fairly large update to change the 2d arrays in > our API from const PLFLT ** to const PLFLT * const *. Gcc warns about > the use of const PLFLT ** because it only guarantees that the data is > constant not the array of pointers to the data. It is therefore trivial > to change the data by changing the pointers which is not what is > intended. Both the pointer array and the data need to be marked const. > > This is quite intrusive, but it seems to work ok for me. Please check. > It is strictly an API change however existing code should still > compile fine (possibly with warnings depending on the gcc settings). > > This does not remove all warnings - just shifts them (more later). It > does however make the API and the examples clean which I think is > more important for users. > > The const PLFLT * const * is a bit unwieldy however, so I propose > making a new typedef (something like PLFLT_2D_CONST) to tidy up > the code. Assuming PLFLT is #defined like we have done, is "PLFLT * const *" something all c99-compliant compilers should understand or is that just a gcc extension? Even if the answer to that question is all c99-compliant compilers should understand it, it is possible their c99 implementations are buggy. Therefore, I think using a PLFLT_2D_CONST typedef (which we could #define differently for any major non-compliant compilers) might be a good idea from cross-platform point of view as well. For what it is worth, revision 12095 passes a limited test (just test_noninteractive in the build tree) on my Debian stable platform (gcc (Debian 4.4.5-8) 4.4.5). Furthermore, for that test using CXXFLAGS=-O3 -fvisibility=hidden CFLAGS=-O3 -fvisibility=hidden FFLAGS=-O3 there were no compiler warnings at all. That good result surprised me because there used to be tonnes of Java warnings and a sprinkling of C warnings. I don't know whether the Java warnings disappeared due to your efforts, but in any case we have come a long way in getting our code cleaned up thanks to your much appreciated efforts. 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: Andrew R. <and...@us...> - 2011-12-04 09:16:06
|
On Sat, Dec 03, 2011 at 09:51:29AM -0800, Alan Irwin wrote: > On 2011-12-03 09:01-0000 Andrew Ross wrote: > > > > > I have just committed a fairly large update to change the 2d arrays in > > our API from const PLFLT ** to const PLFLT * const *. Gcc warns about > > the use of const PLFLT ** because it only guarantees that the data is > > constant not the array of pointers to the data. It is therefore trivial > > to change the data by changing the pointers which is not what is > > intended. Both the pointer array and the data need to be marked const. > > > > This is quite intrusive, but it seems to work ok for me. Please check. > > It is strictly an API change however existing code should still > > compile fine (possibly with warnings depending on the gcc settings). > > > > This does not remove all warnings - just shifts them (more later). It > > does however make the API and the examples clean which I think is > > more important for users. > > > > The const PLFLT * const * is a bit unwieldy however, so I propose > > making a new typedef (something like PLFLT_2D_CONST) to tidy up > > the code. > > Assuming PLFLT is #defined like we have done, is "PLFLT * const *" > something all c99-compliant compilers should understand or is that > just a gcc extension? Even if the answer to that question is all > c99-compliant compilers should understand it, it is possible their c99 > implementations are buggy. Therefore, I think using a PLFLT_2D_CONST > typedef (which we could #define differently for any major > non-compliant compilers) might be a good idea from cross-platform > point of view as well. This should be a standard feature. Of course, whether all compilers support it or not is another matter. I suspect they do. > For what it is worth, revision 12095 passes a limited test > (just test_noninteractive in the build tree) on my Debian stable platform > (gcc (Debian 4.4.5-8) 4.4.5). Furthermore, for that test using > > CXXFLAGS=-O3 -fvisibility=hidden > CFLAGS=-O3 -fvisibility=hidden > FFLAGS=-O3 > > there were no compiler warnings at all. That good result surprised me > because there used to be tonnes of Java warnings and a sprinkling of C > warnings. I don't know whether the Java warnings disappeared due to > your efforts, but in any case we have come a long way in getting our > code cleaned up thanks to your much appreciated efforts. That is good to know. I've been testing again with all the warning flags on. The new version of gcc (4.6) in debian unstable includes even more warnings. Usefully it also now includes details of which warning flags triggered the message. Incidentally, for testing with debian unstable I'm using pbuilder. It provides a clean chroot environment, primarily for building Debian packages, but you can also log in to test normal compiles etc. The big advantage over virtual machine approaches is that it is much lighter weight and quicker. Alan, you might want to look at this too. Andrew |
From: Alan W. I. <ir...@be...> - 2011-12-04 20:32:39
|
On 2011-12-04 09:15-0000 Andrew Ross wrote: > Incidentally, for testing with debian unstable I'm using pbuilder. It > provides a clean chroot environment, primarily for building Debian > packages, but you can also log in to test normal compiles etc. The > big advantage over virtual machine approaches is that it is much > lighter weight and quicker. Alan, you might want to look at this too. Hi Andrew: pbuilder (documented, by the way, at http://pbuilder.alioth.debian.org/) sounds very useful for quickly switching back and forth between various Debian platforms, but I only have time to test one Debian platform. For now that is squeeze = stable, but I plan to move to wheezy = testing in the next several months. At that time I will preview wheezy using the live CD approach. Creating such CD's should be straightforward with the live-build package. I used the live-helper ancestor of that package to help preview Debian squeeze before I installed it. That package was a bit rough around the edges, but I did get it to work, and I presume live-build implements a much smoother experience for building live CD's of Debian. The live CD idea would also allow access to multiple Debian platforms (similar to multi-booting), but obviously pbuilder would be more convenient for that purpose for those who have the time to test multiple Debian/Ubuntu platforms at once. Live CD previews of Debian and Ubuntu upgrades are especially important right now because of the continued volatility of the X stack especially for those with Intel hardware. My 4-year-old hardware has Intel g33 integrated graphics which works well with the old X stack for Debian squeeze, but I am not sure that will be the case for the new X stack for Debian wheezy because the Intel open-source graphics group stopped release testing g33 two years ago. They still claim that the new X stack _should_ work with that hardware but a certain amount of fear, uncertainty, and doubt about that has been introduced by their lack of release testing, and you know how paranoid I am about the completeness of release testing in any case. :-) If previewing wheezy with a live CD shows there are issues with the new X stack for Intel g33 graphics hardware, my backup plan is to buy a cheap ATI video card, but my hope is that complication will not be necessary. By the way, one of my motivations for moving to wheezy fairly soon is I am hoping that _much_ newer kernel will solve the start-up latency and associated total system slowdown that make testing PLplot on the latest wine such a major hassle for me on Debian squeeze. (My working hypothesis for the cause of these issues is the wine developers have tuned wine for modern Linux kernel capabilities that are just not as well implemented or maybe not even present for the old kernel that you get for Debian squeeze.) I am also looking forward to using the much more mature KDE-4.x desktop that is available on wheezy, later Qt4, later pango/cairo stack, etc. 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. I. <ir...@be...> - 2011-12-06 03:05:53
|
On 2011-12-04 12:32-0800 Alan W. Irwin wrote: > Live CD previews of Debian and Ubuntu upgrades are especially > important right now because of the continued volatility of the X stack > especially for those with Intel hardware. My 4-year-old hardware has > Intel g33 integrated graphics which works well with the old X stack > for Debian squeeze, but I am not sure that will be the case for the > new X stack for Debian wheezy because the Intel open-source graphics > group stopped release testing g33 two years ago. They still claim > that the new X stack _should_ work with that hardware but a certain > amount of fear, uncertainty, and doubt about that has been introduced > by their lack of release testing, and you know how paranoid I am > about the completeness of release testing in any case. :-) Hmm. I was being too tough on Intel, see http://intellinuxgraphics.org/2011Q4.html. They did drop release testing of g33 for quite a while up to and including the first quarterly release this year. Apparently there was no second quarterly release, but g33 testing has been reinstated for their last two quarterly releases this year, and the versions of the components (kernel, mesa, libdrm, libva, X server, and X intel driver) of the Intel graphics stack mentioned at the above URL have already mostly made it into Debian testing. That makes me feel a lot better about the chances that my g33 graphics will work properly with the X stack for Debian testing. 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: Andrew R. <and...@us...> - 2011-12-08 19:48:21
|
On Sun, Dec 04, 2011 at 12:32:31PM -0800, Alan Irwin wrote: > On 2011-12-04 09:15-0000 Andrew Ross wrote: > > > Incidentally, for testing with debian unstable I'm using pbuilder. It > > provides a clean chroot environment, primarily for building Debian > > packages, but you can also log in to test normal compiles etc. The > > big advantage over virtual machine approaches is that it is much > > lighter weight and quicker. Alan, you might want to look at this too. > > Hi Andrew: > > pbuilder (documented, by the way, at http://pbuilder.alioth.debian.org/) > sounds very useful for quickly switching back and forth > between various Debian platforms, but I only have time to test one > Debian platform. > > For now that is squeeze = stable, but I plan to move to wheezy = > testing in the next several months. At that time I will preview > wheezy using the live CD approach. Creating such CD's should be > straightforward with the live-build package. I used the live-helper > ancestor of that package to help preview Debian squeeze before I > installed it. That package was a bit rough around the edges, but I did > get it to work, and I presume live-build implements a much smoother > experience for building live CD's of Debian. The live CD idea would > also allow access to multiple Debian platforms (similar to > multi-booting), but obviously pbuilder would be more convenient for > that purpose for those who have the time to test multiple > Debian/Ubuntu platforms at once. > > Live CD previews of Debian and Ubuntu upgrades are especially > important right now because of the continued volatility of the X stack > especially for those with Intel hardware. My 4-year-old hardware has > Intel g33 integrated graphics which works well with the old X stack > for Debian squeeze, but I am not sure that will be the case for the > new X stack for Debian wheezy because the Intel open-source graphics > group stopped release testing g33 two years ago. They still claim > that the new X stack _should_ work with that hardware but a certain > amount of fear, uncertainty, and doubt about that has been introduced > by their lack of release testing, and you know how paranoid I am > about the completeness of release testing in any case. :-) > > If previewing wheezy with a live CD shows there are issues with the > new X stack for Intel g33 graphics hardware, my backup plan is to buy > a cheap ATI video card, but my hope is that complication will not be > necessary. > > By the way, one of my motivations for moving to wheezy fairly soon is > I am hoping that _much_ newer kernel will solve the start-up latency > and associated total system slowdown that make testing PLplot on the > latest wine such a major hassle for me on Debian squeeze. (My working > hypothesis for the cause of these issues is the wine developers have > tuned wine for modern Linux kernel capabilities that are just not as > well implemented or maybe not even present for the old kernel that you > get for Debian squeeze.) I am also looking forward to using the much > more mature KDE-4.x desktop that is available on wheezy, later Qt4, > later pango/cairo stack, etc. Alan, I realise you haven't much time for testing on top of your already extensive testing, but others might find pbuilder useful too. For me it is a relatively painless way of testing the latest versions of libraries etc without having to risk an unstable system or download and compile myself. Andrew |