> 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 >
