>>> On 7/2/2008 at 4:59 PM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > On Wed, Jul 02, 2008 at 12:26:18PM -0600, Brad Nicholes wrote: >> >>> On 7/2/2008 at 12:16 PM, in message <[EMAIL PROTECTED]>, Carlo >> Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: >> > On Wed, Jul 02, 2008 at 11:11:08AM -0600, Brad Nicholes wrote: >> >> >>> On 7/2/2008 at 5:12 AM, in message <[EMAIL PROTECTED]>, Carlo >> > Marcelo >> >> Arenas Belon <[EMAIL PROTECTED]> wrote: >> >> > The following proposed patch for stable 3.1, removes all references to >> >> > C++ >> >> > as a supported language for building DSO metrics as it was reportedly >> >> > not >> >> > working. >> >> > >> >> > The changes required to get mod_example.c to compile using the GNU C++ >> >> > compiler (which are rather intrusive) are already committed in trunk and >> >> > proposed for integration for the next release. >> >> > >> >> > Contains changes from r1490. >> >> > >> >> > Carlo >> >> > --- >> >> >> >> Even though the language label of "C/C++" might be a little misleading >> >> for >> > now, it is still a more meaningful language label than "c". >> > >> > I would argue otherwise, as "c" semantics will be more meaningful to an >> > "Objective C" or "C#" interface than "C/C++", and they all might be > possible >> > in the long run. >> > >> > Indeed I would even argue that "C/C++" is too limiting because any other >> > compiled language that is able to use "c" semantics might be represented >> > here >> > as well. >> > >> The only reason why the labels are "C/C++", "Python", etc. rather than >> "Compiled", "Scripted" is because I wanted to leave a little flexibility >> incase there is some special handling of certain class of modules in the >> future. > > I always assumed (as explained in the comments in the code) it was so the > right > module interface could be selected, and will be definitely important as soon > as other language interfaces like "perl", "lua" or "visual basic" start > getting added. >
This is true to a certain extent. Gmond doesn't choose which language interface module handles which modules. It is the interface module itself that chooses which language types it will handle. This leave the language or module class designation up to the interface module developer themselves without gmond having to know anything about it. In reality, gmond only support one module interface and that is C/C++. Therefore for consistency, gmond itself enforces the C/C++ language designation. The python module interface only supports a "python" language type and it enforces that. But there is nothing that says that mod_basic couldn't support several variations of the basic language and it might choose to implement different language types to support that. That module would simply decide what the language type designation it wants to use in order to make sure that the appropriate modules are handled. >> This configuration directive is only meant to roughly identify the module >> class, not to uniquely identify the language it was developed in. > > the documentation was probably misleading with so many references to the > the "C" language then. > >> If there is no real reason to make the end user jump through any extra > hoops, >> then let's not do it. By the same token, if there really isn't any reason >> to make the code more complex (even if it is only slightly more complex), >> then let's not do it. > > agree committed an added fix in r1500, will update the proposal including > it. > >> >> If we change to a language label of "c" now and then more fully support >> >> C++ >> > later (which it looks like will happen in the next minor revision), we will >> > have to add another language label. >> > >> > or just an alias to the current one, which is just 1 extra strcasecmp call. >> >> Again, why even add an extra strcasecmp when it is completely unnecessary. > > agree, and an extra unneeded strcasecmp removed as well in r1500 > The only reason to leave the strcasecmp for C/C++ is for consistency. Although it will work (and should work) by assuming that if there isn't a language directive that C/C++ is the default, the inconsistency is that all module configurations should include and understand the language directive except for C/C++ which must not include a language directive. As the code was before, the language directive was optional for C/C++ but at least it understood the directive if it existed. So that all module configuration syntax remains consistent, C/C++ modules should also understand the language directive as well even though it is optional. 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
