myllynen wrote:
> [...]
> likewise on both, looks like with this a couple of hundred lines of code
> from pmrep could be replaced with fetchgroup Python PMAPI calls.
Yeah, will work on python bindings shortly.
> In addition to some minor comments I had on IRC already, perhaps you
> could comment these a bit higher level items on the list as well:
>
> - did you consider allowing NULL for out_type to signal native type?
That would not make much sense to me. The application knows which
pmAtomValue subfield it will look at in the result. Since the
information as to data type is at some level fixed at compile time,
the same data type ID might as well be passed to the fetchgroup API.
For general purpose printing, just use PM_TYPE_STRING; the fetchgroup
widgetry will convert numeric data.
> - how would you use the API with non-leaf PMNS nodes?
These particular functions are not suitable for that, because they
expect the caller to specify a specific locations / conversions for
the outputs. That makes sense if the app knows what it wants.
For purposes like pminfo or pmrep, a helper function could do a PMNS
traversal, and within the callback dynamically allocate
pmAtomValues/strdup-names to hold results and call pmExtendFetchGroup*
on the leaf nodes. Maybe it's specialized & simple enough -not- to
put it into libpcp.
- FChE
|