pcp
[Top] [All Lists]

Re: pcp-programmers-guide.xml

To: Stan Cox <scox@xxxxxxxxxx>
Subject: Re: pcp-programmers-guide.xml
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Mon, 10 Feb 2014 00:47:44 -0500 (EST)
Cc: PCP Mailing List <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <52F50F51.1020504@xxxxxxxxxx>
References: <52F50F51.1020504@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: dZPZGCqiD6zkbWI2T/v/ljNHKpjyjg==
Thread-topic: pcp-programmers-guide.xml

----- Original Message -----
> Here is my latest round:

Looks good.  Here's a few more refinements ...

- c -> C (language name, so uppercase probably best)
- the C synopsis for pmDupContext was accidentally removed?
- pmNameID vs pmNameInDom -> different style (str vs "string")
- pmWhichZone() - same issue
- actually, lots with this inconsistency
- pmAddProfile vs pmDelProfile use "Python" vs "Python Bindings"
- pmSetMode, same issue
- actually, lots with this inconsistency - were you moving to
  the latter or the former?  either seems fine, pick one.
- "mode is defined in the c_api.PM_MODE* constants defined in
  by importing cpmapi." reads oddly ... too many "defined in"
  occurrences?
- the code snippets in this section (eg 3.8.6.*) use the phrase
  "code snippets" - could change those to "C code snippets"?

In most/all places the return code listed as, eg: 
  int status = pmUseZone(int tz_handle)
The "tz_handle" name is in italics, but "status" is not - maybe
it should be too?  *shrug*

We should add words to pmDestroyContext and pmNewContext stating
that these are not ever called directly from python code, rather
they are implicitly called when an context object is created and
destroyed.

Oh, pmLookupText and pmLookupInDomText appear to be missing their
python counterparts?

3.8.7 missing python bindings (WIP?) - these are in "import pmgui"
I think (hmmm, we seem to have no direct tests - but, pmcollectl
and pmatop both use 'em so maybe we've got coverage there)

3.8.8.1 pmGetArchiveLabel returns a loglabel (ctypes struct), as
is described for C API - not an int.

3.8.8.2 pmGetArchiveEnd returns ctypes timeval pointer, not int.

3.8.10.1 pmGetConfig starts to use a different whitespace style
to everything preceding (and to C synopsis), also lacks str type
information for call parameter

3.8.10.2. pmErrStr missing return type str?  or did you prefer
the other convention (i think str is nice & clear, FWIW, but it
adds redundant info given the double quotes ... *shrug*).  Same
whitespace quirk as getconfig.

3.8.10.11. pmPrintValue missing whitespace in pmResultpmresult.
FILE* here is a (py native) PyFile, according to the code?

3.8.10.12. pmflush is same in python, not camel-cased

3.8.10.13. pmprintf missing python wrapper - same call convention
(varargs) from a look at the code.

3.8.10.16. pmParseMetricSpec has whitespace/comma issues in the
return values for python.

3.9.1 - pmgenmap rejig in C example - excellent, thanks!  :)

3.9.2, 3.9.3 - nice, matching py examples - good stuff.
There is a python pmtimevalSleep like used by the C API, btw.
It'd be good to use that, as the common-arg-parsing stuff I'm
looking at will use a timeval like in C (via -t auto-parsing)

Example 3.23. C code has:
    char *host = "localhost";
Hmm, don't let Dave & Frank see that - could you tweak that to
"local:" while you're in there?  thx.

Re the python exception handling - er, wow - its that easy?  :]
Can you really import a module within an exception handler?
(I have no idea)
Also, should the "print freemem" be earlier on?  It kinda reads
like we execute that after the exception handler, too, which I
would expect to explode with an uninitialised variable?


Good going!! - its a tough slog working on these books - the
pain is all coming back to me now.  :)

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>