Yes, this is quite an interesting problem in the general case: in order to pop-up context sensitive help on the possible argument parameters, there would first have to be (a) dataflow analysis to determine that the parameter was being passed though to the FileMetric reduction function, and then (b) real-time inspection of the FileMetric data for that project and date to determine what metric names were available! I don't think even Ajax makes that simple. Maybe we have to wait for Web 3.0. :-)
For now, a Chart documentation string might say something like the following: "The metricName parameter indicates a label that will be passed to the FileMetric reduction function. All FileMetric sensor data support the following three labels: sourceLines, commentLines, and totalLines, although other metric names may be available depending upon the sensor used to generate the data. To determine the complete set of metric names available, you can consult either the sensor documentation associated with your FileMetric data, or inspect the FileMetric data itself using the Sensor Data Links command in the Extras page." Quite long-winded, I know, but it hopefully gets the point across. Cheers, Philip ----- Original Message ----- From: "(Cedric) Qin ZHANG" <[EMAIL PROTECTED]> Date: Tuesday, September 26, 2006 10:35 am Subject: Re: [HACKYSTAT-DEV-L] Telemetry parameters To: [email protected] > 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 > >>>> >
