----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
>
> I am not sure there is an "ideal" way. There are pros and cons, but
> more on this topic below.
> ...
*nod*
>
> There are problems with the inline method ....
>
*nod*
> There are actually enough problems already in getting this right, so
> I'm
> going to try an initial implementation with pmRegisterDerived() and
> pmLoadDerivedConfig() in the API. I'll skip the $PCP_DERIVED_CONFIG
> stuff for the moment, and just use -d derived_config_file at the
> command
> line for a few apps to get pmLoadDerivedConfig() called see how it
> all goes.
Good plan.
> The "problems" encountered so far are ...
>
> + cannot use flex/lex or yacc/bison for parsing expressions due to
> ugly
> symbol space pollution in libpcp that will likely kill any
> application
> that uses flex/lex or yacc/bison (so pmlogger, pmie, pmlc, dbpmda,
> pmlogextract, hotproc PMDA) ... sigh
> + need one set of data structures _per_ context, and some syntax and
> semantic checks must be deferred from parse time to the time
> pmNewContext has been called successfully
> + tricky semantics around some aggregate functions
> + do we need constants in the expressions? if so, they may need to
> be dimensioned.
One other thing I should've mentioned, tho its only peripherally related.
I have been considering QtScript (http://en.wikipedia.org/wiki/QtScript)
in the next iteration of pcp-gui, as this gives those tools a high level
language for implementing the derived metrics stuff for the Qt metrics
class tools (pmdumptext, pmchart, ... pmgadgets/pmview later) amongst a
number of other things (gui scripting). I'm just mentioning this so you
can keep it in the back of your mind while doing this... (perhaps what we
want here is an API for plugging in metric evaluators, rather than a new
mini-language - thinking of your first point above). Not 100% clear on
that though.
cheers.
--
Nathan
|