From: Dmitri G. <gri...@gm...> - 2009-06-19 04:33:58
|
Hello all, plplot.h includes plConfig.h which defines some HAVE_* macros. These macros could conflict with user's code, for example: // autoconf- or cmake-generated config.h #include "config.h" #include <plplot.h> In this case plplot could be using user's configuration or interfere with user's code. If the values of macros wouldn't match (even "#define FOO" vs. "#define FOO 1") gcc would print a warning. I tried to look more closely at plplot.h to find out how it uses HAVE_* macros. There are two uses: 1. if HAVE_STDINT_H, then PLUINT and other types are defined with the help from stdint.h, otherwise plplot.h does some guessing. Instead of this we could use CheckTypeSize [1] in cmake to find a type of appropriate size. 2. if there are some standard functions missing (isinf(), isnan() etc) then plplot.h does some workarounds. But this code (macros, in fact) could be moved in a separate header file, user doesn't need it. I would write a patch myself, but I don't know much about cmake. [1] http://www.cmake.org/cmake/help/cmake2.6docs.html#module:CheckTypeSize Regards, Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gri...@gm...>*/ |
From: Geoffrey F. <Geo...@at...> - 2009-06-19 05:23:49
|
I can confirm that use of PLplot together with the Python C API, produces many many warnings, some of them traceable to the HAVE_* business. I plan to try to clean this up sometime soon. Dmitri Gribenko writes: > Hello all, > > plplot.h includes plConfig.h which defines some HAVE_* macros. These > macros could conflict with user's code, for example: > > // autoconf- or cmake-generated config.h > #include "config.h" > #include <plplot.h> > > In this case plplot could be using user's configuration or interfere > with user's code. If the values of macros wouldn't match (even > "#define FOO" vs. "#define FOO 1") gcc would print a warning. > > I tried to look more closely at plplot.h to find out how it uses > HAVE_* macros. There are two uses: > > 1. if HAVE_STDINT_H, then PLUINT and other types are defined with the > help from stdint.h, otherwise plplot.h does some guessing. Instead of > this we could use CheckTypeSize [1] in cmake to find a type of > appropriate size. > > 2. if there are some standard functions missing (isinf(), isnan() etc) > then plplot.h does some workarounds. But this code (macros, in fact) > could be moved in a separate header file, user doesn't need it. > > I would write a patch myself, but I don't know much about cmake. > > [1] http://www.cmake.org/cmake/help/cmake2.6docs.html#module:CheckTypeSize > > Regards, > Dmitri > > -- > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gri...@gm...>*/ > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Andrew R. <and...@us...> - 2009-06-23 08:29:25
|
I am aware of this. I posted a proposal to fix this some weeks back for comment, but got no feedback. To my mind. 1) plplot is broken in making some of these things visible to users. 2) python is also broken for the same reason. Technically this is akin to an API change since some of these symbols have been visible for a long time (pre cmake I think) and so some users might rely on then. This is what I wanted feedback on. Andrew On Fri, Jun 19, 2009 at 12:23:45AM -0500, Geoffrey Furnish wrote: > I can confirm that use of PLplot together with the Python C API, produces > many many warnings, some of them traceable to the HAVE_* business. I plan to > try to clean this up sometime soon. > > Dmitri Gribenko writes: > > Hello all, > > > > plplot.h includes plConfig.h which defines some HAVE_* macros. These > > macros could conflict with user's code, for example: > > > > // autoconf- or cmake-generated config.h > > #include "config.h" > > #include <plplot.h> > > > > In this case plplot could be using user's configuration or interfere > > with user's code. If the values of macros wouldn't match (even > > "#define FOO" vs. "#define FOO 1") gcc would print a warning. > > > > I tried to look more closely at plplot.h to find out how it uses > > HAVE_* macros. There are two uses: > > > > 1. if HAVE_STDINT_H, then PLUINT and other types are defined with the > > help from stdint.h, otherwise plplot.h does some guessing. Instead of > > this we could use CheckTypeSize [1] in cmake to find a type of > > appropriate size. > > > > 2. if there are some standard functions missing (isinf(), isnan() etc) > > then plplot.h does some workarounds. But this code (macros, in fact) > > could be moved in a separate header file, user doesn't need it. > > > > I would write a patch myself, but I don't know much about cmake. > > > > [1] http://www.cmake.org/cmake/help/cmake2.6docs.html#module:CheckTypeSize > > > > Regards, > > Dmitri > > > > -- > > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if > > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gri...@gm...>*/ > > > > ------------------------------------------------------------------------------ > > Crystal Reports - New Free Runtime and 30 Day Trial > > Check out the new simplified licensing option that enables unlimited > > royalty-free distribution of the report engine for externally facing > > server and web deployment. > > http://p.sf.net/sfu/businessobjects > > _______________________________________________ > > Plplot-devel mailing list > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-devel > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Dmitri G. <gri...@gm...> - 2009-06-23 11:32:02
|
On Tue, Jun 23, 2009 at 11:28 AM, Andrew Ross<and...@us...> wrote: > Technically this is akin to an API change since some of these symbols > have been visible for a long time (pre cmake I think) and so some > users might rely on then. This is what I wanted feedback on. We could still install plConfig.h but remove all references to it from user-visible headers. Thus users who rely on it could include it themselves. Also, it would be better to hide all internal declarations altogether. It could be easily done like this: in all sources we define a macro, say IN_PLPLOT_CORE and check for it in all headers. All internal stuff in headers should be guarded #if IN_PLPLOT_CODE ... #endif. The macro can be defined on the command-line of compiler, -DIN_PLPLOT_CORE=1, so only modifications to headers is necessary. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gri...@gm...>*/ |
From: Andrew R. <and...@us...> - 2009-06-23 13:23:59
|
On Tue, Jun 23, 2009 at 02:31:08PM +0300, Dmitri Gribenko wrote: > On Tue, Jun 23, 2009 at 11:28 AM, Andrew > Ross<and...@us...> wrote: > > Technically this is akin to an API change since some of these symbols > > have been visible for a long time (pre cmake I think) and so some > > users might rely on then. This is what I wanted feedback on. > > We could still install plConfig.h but remove all references to it from > user-visible headers. Thus users who rely on it could include it > themselves. > > Also, it would be better to hide all internal declarations altogether. > It could be easily done like this: in all sources we define a macro, > say IN_PLPLOT_CORE and check for it in all headers. All internal > stuff in headers should be guarded #if IN_PLPLOT_CODE ... #endif. The > macro can be defined on the command-line of compiler, > -DIN_PLPLOT_CORE=1, so only modifications to headers is necessary. This still doesn't get round the problem of python leaking these declarations. For that we would have to rename the declarations to something like PLPLOT_HAVE_ISINF. Andrew |
From: Geoffrey F. <Geo...@at...> - 2009-06-26 03:29:20
|
Andrew Ross writes: > I am aware of this. I posted a proposal to fix this some weeks back > for comment, but got no feedback. To my mind. Sorry I missed that. > 1) plplot is broken in making some of these things visible to users. > 2) python is also broken for the same reason. Emphatically agree on both points. > Technically this is akin to an API change since some of these symbols > have been visible for a long time (pre cmake I think) and so some > users might rely on then. This is what I wanted feedback on. Mmmm. I'm a big fan of backward compatibility, but I feel stronger about advertised features than about unadvertised misfeatures. To me, this HAVE_* stuff, leaking out into the global namespace, by both PLplot and Python, is a very annoying misfeature in both systems. I have scads of warnigs coming out in every compile from this. > On Fri, Jun 19, 2009 at 12:23:45AM -0500, Geoffrey Furnish wrote: > > I can confirm that use of PLplot together with the Python C API, > > produces many many warnings, some of them traceable to the HAVE_* > > business. I plan to try to clean this up sometime soon. Andrew Ross writes: > On Tue, Jun 23, 2009 at 02:31:08PM +0300, Dmitri Gribenko wrote: > > On Tue, Jun 23, 2009 at 11:28 AM, Andrew > > Ross<and...@us...> wrote: > > > Technically this is akin to an API change since some of these symbols > > > have been visible for a long time (pre cmake I think) and so some > > > users might rely on then. This is what I wanted feedback on. > > > > We could still install plConfig.h but remove all references to it from > > user-visible headers. Thus users who rely on it could include it > > themselves. > > > > Also, it would be better to hide all internal declarations altogether. > > It could be easily done like this: in all sources we define a macro, say > > IN_PLPLOT_CORE and check for it in all headers. All internal stuff in > > headers should be guarded #if IN_PLPLOT_CODE ... #endif. The macro can > > be defined on the command-line of compiler, -DIN_PLPLOT_CORE=1, so only > > modifications to headers is necessary. > > This still doesn't get round the problem of python leaking these > declarations. For that we would have to rename the declarations to > something like PLPLOT_HAVE_ISINF. Yes, that's a good idea. I'm also trying to work up to just sending in a patch for Python, but I haven't gotten to it yet. Even so, that would only at best show up in some future Python, and I'll spend years dealing with the warnings flowing out of 2.6.x. So, I see considerable merit in what you're proposing. |
From: Maurice L. <mj...@br...> - 2009-06-28 20:36:02
|
I agree the HAVE_* macros are a problem wrt the global namespace. Some of the example programs use them, however, which needs to be taken into account. I like the idea of just making them more plplot-specific (as has been done for PL_HAVE_USLEEP). -- Maurice LeBrun |