Re: [Ganglia-developers] [RFT] gmond: drop C/C++ references as asupported language for building DSO metrics
On 7/4/2008 at 12:58 AM, in message [EMAIL PROTECTED], Carlo Marcelo Arenas Belon [EMAIL PROTECTED] wrote: On Thu, Jul 03, 2008 at 10:42:06AM -0700, Bernard Li wrote: -1 I agree with Brad on this. Not sure what to make of no one replying to the code on this thread, after all this is a developer mailing list and I would expect all debate to be made in a technical basis. The technical reason for not accepting this proposal at this time is the risk of destabilizing the 3.1 branch before releasing 3.1.1 without solving any real issue. The goal right now is to stabilize the 3.1 branch so that we can release 3.1.1. Adding support for a C++ compiler is closer to being an enhancement similar to adding support for perl or ruby, than it is a bug fix. I have no problem at this point with the backport proposal and patches for adding support for a C++ compiler except for the fact that they touch a significant amount of code and have a much greater potential for destabilizing the 3.1 branch than they do for fixing a real issue. For the 3.1.1 release, this is simply a matter of documentation and noting that the unsupported C++ portion of the language label C/C++ is a known issue that will be resolved in the next release. So C++ support is incomplete C++ support doesn't exist in the 3.1 branch at all. we should document this and keep going. Instead, we should fix this and keep going, a starting point to add that support has been implemented in trunk for a couple of days, and will be posting it for review/testing for backport to 3.1 I would agree if the patch didn't touch so much code in relation to the issue that it is trying to solve. There is no need to have C++ compiler support in Ganglia 3.1.1. Once we release 3.1.1, we can risk destabilizing the branch briefly while we add C++ compiler support and move toward a release of 3.1.2. Let's do what is necessary to get 3.1.1 out the door and then worry about enhancing Ganglia to support more languages or compilers. There is a lot of needed functionality in Ganglia 3.1 that has been waiting around for a long time. Let's not delay it any more than we have to for functionality that to my knowledge, is not needed yet by anybody. As I mentioned in a previous email thread, this is Open Source. Release early, release often. There is nothing that says that we can't release a stable 3.1.1 with current functionality and then a month later release 3.1.2 with new functionality that includes support for a C++ compiler. It really comes down to weighing current stable functionality against known issues. IMO, releasing the current stable functionality of 3.1.1 far out-weights the risk of destabilizing the 3.1 branch just to add support for a C++ compiler. We are going on another month now. Let's get 3.1.1 out the door and move on. Brad - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [RFT] gmond: drop C/C++ references as asupported language for building DSO metrics
On 7/7/2008 at 2:37 PM, in message [EMAIL PROTECTED], Carlo Marcelo Arenas Belon [EMAIL PROTECTED] wrote: On Mon, Jul 07, 2008 at 12:31:13PM -0600, Brad Nicholes wrote: On 7/4/2008 at 12:58 AM, in message [EMAIL PROTECTED], Carlo Marcelo Arenas Belon [EMAIL PROTECTED] wrote: On Thu, Jul 03, 2008 at 10:42:06AM -0700, Bernard Li wrote: -1 I agree with Brad on this. Not sure what to make of no one replying to the code on this thread, after all this is a developer mailing list and I would expect all debate to be made in a technical basis. The technical reason for not accepting this proposal at this time is the risk of destabilizing the 3.1 branch before releasing 3.1.1 without solving any real issue. This thread code (which has been long removed from the conversation) was mainly documentation changes and code removal in 1 line of code which has no chance of destabilizing anything. I agree with you that the alternative (which is all we had left after this one has been rejected) has a risk of destabilizing the 3.1 branch, and that is why it was delayed for next release originally with an intermediate solution posted in the interim. OK, let's go back and rehash. There were two proposals, 1) Removing the /C++ portion of the language label C/C++. The technical reason for rejecting this is basically that it doesn't solve anything yet adds more confusion to the configuration of a module in the next release. The exact same code path would be followed by gmond for either a C or a C++ module, therefore combining both languages into a single language label makes things less confusing for the user. Especially since it would be very difficult for a user to distinguish between a compiled C DSO and a C++ DSO. Both C and C++ would both produce a DSO module that would need to be loaded by apr_dso_load(). Both types of module would interface with gmond in exactly the same way. However if we apply this patch for 3.1.1, it would then require a code change for 3.1.2 when the second patch is applied. 2) Make all of the changes to the source code both in gmond, module headers and modules to support the C++ compi ler. The technical reason for not accepting this patch has already been discussed on this thread. The goal right now is to stabilize the 3.1 branch so that we can release 3.1.1. Adding support for a C++ compiler is closer to being an enhancement similar to adding support for perl or ruby, than it is a bug fix. Agree, just wanted to clarify though that the added support is not for a compiler but for a language. In the line of compiler support, Sun Studio 12 support was added by me to trunk long ago as an alternative to GCC in OpenSolaris but as I agree with you on the need to keep 3.1 stable for release wasn't even proposed to backport yet. As it is now, you can use the C gmond modular interface (which was labeled C/C++) to write C modules or Objective C modules but C++ is not supported yet. Correct. This can easily be noted in the README as a known issue that will be fixed in 3.1.2 when the C++ backport proposal (#2) is accepted in the 3.1 branch. In the meantime (which is a very short time), C++ is not supported for developing a gmond module. When the C++ backport proposal is accepted into 3.1.2 and 3.1.2 is released, the language label C/C++ will be fully supported and make complete sense to the user as well as the developer. For the 3.1.1 release, this is simply a matter of documentation and noting that the unsupported C++ portion of the language label C/C++ is a known issue that will be resolved in the next release. There are 2 parts of it which seem to be confusing most : 1) the documentation and use of C/C++ as a label for DSO modules is incorrect because technically speaking the interface exported by gm_metric.h is a C interface which can be used to build DSO modules in almost anything that can compile to it, including using it directly by C, Objective C or C++ (once the support is committed) source modules and because those other languages are mostly C compatible at the source level. Ok, but the user doesn't care. Basically to the user, the language that was used to produce the DSO doesn't matter. To gmond, the language that was used to produce the DSO doesn't matter. So all we really need to do is give it a label. The easiest label to give it that will be understood by both users and developers is C/C++. This label also makes sense when you are talking in terms of alternate languages when referring to Python, perl, ruby, etc. modules. 2) the documentation and use of C/C++ is misleading because C++ can't be used with it yet (until support is committed). the solution you propose only mitigates 2; the last patch I proposed mitigates both. Absolutely, however the last patch is too destabilizing for 3.1.1. So rather than applying a label change to 3.1.1 which would have to be
Re: [Ganglia-developers] [RFT] gmond: drop C/C++ references as asupported language for building DSO metrics
On Thu, Jul 03, 2008 at 10:42:06AM -0700, Bernard Li wrote: -1 I agree with Brad on this. Not sure what to make of no one replying to the code on this thread, after all this is a developer mailing list and I would expect all debate to be made in a technical basis. So C++ support is incomplete C++ support doesn't exist in the 3.1 branch at all. we should document this and keep going. Instead, we should fix this and keep going, a starting point to add that support has been implemented in trunk for a couple of days, and will be posting it for review/testing for backport to 3.1 Carlo - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [RFT] gmond: drop C/C++ references as asupported language for building DSO metrics
On 7/2/2008 at 5:22 PM, in message [EMAIL PROTECTED], Carlo Marcelo Arenas Belon [EMAIL PROTECTED] wrote: The following proposed patch for stable 3.1, removes all references to C/C++ as a supported language for building DSO metrics as it was meaningless and only relevant when used with scripted metric modules. It simplifies the code by making language an optional parameter and includes feedback from Brad into the documentation. Contains changes from r1490 and r1500 Carlo --- -1 The more I look at this, the more I would rather that the changes be reverted and we just leave it alone. AFAICT, the only issue here is whether the /C++ portion of the language label C/C++ is misleading enough to cause a developer to waste a significant amount of time attempting to write a module in C++ only to find out that it can't be done today. Since this language label only appears as an optional parameter to the language directive in a module block as well as being referenced in the module configuration documentation of Gmond, I seriously doubt that these references are going to cause any developer serious heartache in the short term. There have already been patches committed to trunk to support the development of a C++ module and these patches have already been proposed for backport in the next minor revision. So all we are really talking about is a very slight misuse of the label C/C++ between the actual release of 3.1.1 and 3.1.2 which will probably only s pan just a few months at the most. Also to my knowledge, I am the only one that has ever written a C/C++ class module (so far) and since I am completely aware that developing a module in C++ is not supported yet, I don't believe that we are misleading many developers in anyway. There was an issue raised on the mailing list where a developer was attempting to compile a C language module with a C++ compiler, but the obvious solution was to switch to the correct compiler, not change code and documentation. At the very worst, the choice of the term 'language' as a directive name is really the issue. As I explained before, gmond only supports one interface and that is C/C++ (yes, C++ is not fully supported today, but will be very soon). All gmond needs to know is if it should handle the module loading or not. The term 'language' was chosen because it seemed like the easiest way to communicate to an administrator what kind of value was expected for this directive. We could have used one of the terms 'Class', 'ModuleClass' or 'ModuleType' rather than 'Language' to accomplish the same thing. It really doesn't matter what the term ultimately is, we just needed some way to inform not only gmond but also every other module interface plugin which module configuration blocks each plugin needs to handle. At the very most, I would consider changing the configuration directive term from 'language' to 'ModuleClass' or 'ModuleType', but that is really all that might need to be done to resolve the issue. As it stands, the term 'Language' is probably good enough and whether the language label is C/C++ rather than C, really doesn't matter. Especially after we release 3.1.2. For now I would suggest that we revert the changes and add one sentence to the documentation that simply states that C++ is not fully support yet, but will be very soon. Brad - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] [RFT] gmond: drop C/C++ references as asupported language for building DSO metrics
-1 I agree with Brad on this. So C++ support is incomplete, we should document this and keep going. Regards, Bernard On Thu, Jul 3, 2008 at 9:47 AM, Brad Nicholes [EMAIL PROTECTED] wrote: On 7/2/2008 at 5:22 PM, in message [EMAIL PROTECTED], Carlo Marcelo Arenas Belon [EMAIL PROTECTED] wrote: The following proposed patch for stable 3.1, removes all references to C/C++ as a supported language for building DSO metrics as it was meaningless and only relevant when used with scripted metric modules. It simplifies the code by making language an optional parameter and includes feedback from Brad into the documentation. Contains changes from r1490 and r1500 Carlo --- -1 The more I look at this, the more I would rather that the changes be reverted and we just leave it alone. AFAICT, the only issue here is whether the /C++ portion of the language label C/C++ is misleading enough to cause a developer to waste a significant amount of time attempting to write a module in C++ only to find out that it can't be done today. Since this language label only appears as an optional parameter to the language directive in a module block as well as being referenced in the module configuration documentation of Gmond, I seriously doubt that these references are going to cause any developer serious heartache in the short term. There have already been patches committed to trunk to support the development of a C++ module and these patches have already been proposed for backport in the next minor revision. So all we are really talking about is a very slight misuse of the label C/C++ between the actual release of 3.1.1 and 3.1.2 which will probably only s pan just a few months at the most. Also to my knowledge, I am the only one that has ever written a C/C++ class module (so far) and since I am completely aware that developing a module in C++ is not supported yet, I don't believe that we are misleading many developers in anyway. There was an issue raised on the mailing list where a developer was attempting to compile a C language module with a C++ compiler, but the obvious solution was to switch to the correct compiler, not change code and documentation. At the very worst, the choice of the term 'language' as a directive name is really the issue. As I explained before, gmond only supports one interface and that is C/C++ (yes, C++ is not fully supported today, but will be very soon). All gmond needs to know is if it should handle the module loading or not. The term 'language' was chosen because it seemed like the easiest way to communicate to an administrator what kind of value was expected for this directive. We could have used one of the terms 'Class', 'ModuleClass' or 'ModuleType' rather than 'Language' to accomplish the same thing. It really doesn't matter what the term ultimately is, we just needed some way to inform not only gmond but also every other module interface plugin which module configuration blocks each plugin needs to handle. At the very most, I would consider changing the configuration directive term from 'language' to 'ModuleClass' or 'ModuleType', but that is really all that might need to be done to resolve the issue. As it stands, the term 'Language' is probably good enough and whether the language label is C/C++ rather than C, really doesn't matter. Especially after we release 3.1.2. For now I would suggest that we revert the changes and add one sentence to the documentation that simply states that C++ is not fully support yet, but will be very soon. Brad - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
