The root is in the "pMap", where you can dump anything. Cheers, -Cedric
Aaron Akihisa Kagawa wrote:
Note that Aaron's problem will only partially go away, since in
FileMetricReducer the valid metric types are dependent on the
actual
FileMetrics data sent. In other words, if the FileMetric has a
"sourceLines" entry in the pMap, then "sourceLines" is a valid
metric type.
Right. That was part of my point. It isn't obvious that is happening. but, I have no idea on how to make that more obvious.
thanks, Aaron
----- Original Message -----
From: "(Cedric) Qin ZHANG" <[EMAIL PROTECTED]>
Date: Tuesday, September 26, 2006 10:12 am
Subject: Re: [HACKYSTAT-DEV-L] Telemetry parameters
To: [email protected]
It wouldn't be hard to print out documentation string. A Jira issue
is
created:
http://hackydev.ics.hawaii.edu:8080/browse/HACK-807
Note that Aaron's problem will only partially go away, since in
FileMetricReducer the valid metric types are dependent on the
actual
FileMetrics data sent. In other words, if the FileMetric has a
"sourceLines" entry in the pMap, then "sourceLines" is a valid
metric type.
However, in general, printing out the doc string is a good idea.
By the way, it's really cold here.
Cheers,
Cedric
Philip Johnson wrote:
It occurs to me that there is a very simple solution to this
problem:
have the telemetry parser print out the documentation string
associated wih the chart (or the report) when there is any kind
of
failure associated with chart (or report) invocation.
If the doc string was printed out as part of the error message,
then
the Chart developer could provide documentation about not only
what
the chart does, but what parameters it takes, _and_ what are
currently
legal values for each of those parameters (i.e. what the
streams/reduction functions accept as strings.).
If that were available, then I think a lot, but not all, of the
current usability problems with chart/report parameter values
would go
away.
The fundamental problem with this approach is that if the
reduction
functions/streams are changed in some way, then it is important
to
check for a ripple effect in the chart/report documentation
strings,
so that they continue to document the actual legal parameters.
In the long run, one could imagine a "smart" data flow analysis
mechanism for telemetry that can infer the potential values that
an
argument to a chart definition takes based on the way it is used
within the definition. This, however, would be a Lot Of Work. I
propose we go with the two line solution first. :-)
Cedric: how hard would it be to start printing out the
documentation
string associated with a chart or report when it is invoked and
an
error occurs? Two lines of code?
Cheers,
Philip
--On Monday, September 25, 2006 12:07 PM -1000 Aaron Akihisa
Kagawa
<[EMAIL PROTECTED]> wrote:
Hey Guys,
I've been trying some telemetry things and I realized that the
telemetry>> parameters are not very obvious. For example, the
FileMetric-Chart. I
tried things like "SLOC", "LOC", etc. I had no idea that the valid
parameter was "sourceLines" (I suppose I should have known).
Furthermore, I wasn't provided any feedback that "SLOC" or "LOC"
weren't>> correct. Anyway, I found "sourceLines" in the SCLC data.
Anyway, I know that the telemetry language makes these
parameters as
general as possible, but i think at the same time it makes it
harder to
use.
thanks, Aaron
