pcp
[Top] [All Lists]

pcp updates: python getopts code, exception handling fixes

To: PCP Mailing List <pcp@xxxxxxxxxxx>
Subject: pcp updates: python getopts code, exception handling fixes
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Wed, 2 Apr 2014 02:32:47 -0400 (EDT)
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1030455667.5826994.1396419881620.JavaMail.zimbra@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: K3MUHItI5xcHUHVFDp/5P3dfwHLRRg==
Thread-topic: pcp updates: python getopts code, exception handling fixes
Changes committed to git://oss.sgi.com/pcp/pcp.git dev

 qa/739                         |   57 ++
 qa/739.out                     |  115 +++++
 qa/741                         |   42 ++
 qa/741.out                     |   23 +
 qa/group                       |    2 
 qa/src/GNUlocaldefs            |    1 
 qa/src/test_pcp_getopts.python |  113 +++++
 qa/src/test_pcp_options.python |   94 ++++
 src/libpcp/src/getopt.c        |    9 
 src/python/pcp/pmapi.py        |  295 +++++++++++++-
 src/python/pmapi.c             |  818 ++++++++++++++++++++++++++++++++++++++++-
 11 files changed, 1529 insertions(+), 40 deletions(-)

commit 15be6ce0f478aefe5dcdd9ce138f3801fc373fd7
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date:   Wed Apr 2 17:22:15 2014 +1100

    Improvements to the python pmErr exception class
    
    The interaction between the pmLookupName PMAPI wrapper
    and the exception class was not quite right.  Firstly,
    the test-for-failure in the lookup wrapper came after
    the test-for-not-the-same-number-of-PMIDs-passed-in,
    rendering the error case unreachable.  Secondly, the
    value passed into the exception handler (which *must*
    be an error code) was the positive return value, for
    the case where some, but not all, names resolve.
    
    This meant the error-symbol dictionary lookup would
    fail and neither an error message nor the list of
    names which didn't resolve would be generated.
    
    Finally, when a pmContext constructor stalls (eg for
    faraway connections) and is interrupted (eg killed),
    the destructor is called with a partially-initialised
    object.  It then attempts to call pmDestroyContext(3)
    on an uninitialised context, and badness results.
    
    These bugs were found while testing some new python
    monitor tools, automated regression testing will be
    added shortly using those new tools as the vehicle.

commit 59b5cd0a1c48ad071e405dccd496a31142a5281a
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date:   Wed Apr 2 17:05:34 2014 +1100

    Small improvements to the core getopt handling in libpcp
    
    Do not pass EOF into option override() methods, its not an
    actual option, hence no need to ever override - busy work.
    
    Make the -V,--version output match usual output convention.
    
    Switch over to using the thread-safe pmGetContextHostName_r
    variant.
    
    Allow pmUsageMessage() to be used to flush the version output
    too, instead of making callers deal with that case specially.
    Used in the python APIs, in particular, to simplify things.

commit 10d67282c58093b7cffdbfda3b76df9cbd0b5f47
Author: Nathan Scott <nathans@xxxxxxxxxx>
Date:   Tue Apr 1 17:47:26 2014 +1100

    Initial Python script support for auto-command-line-parsing
    
    Support for long options and automatic PCP option parsing on
    the command lines of python monitor tools.  A new pmOptions
    class is added to the pmapi python module, and a classmethod
    on the pmContext class allows it to be injected into the new
    context creation process.
    
    Two test scripts are also added to exercise the python APIs,
    exercised via new tests qa/739 and qa/741.  The former looks
    at specifics of the pmOptions class, the latter ensures that
    this new class interfaces correctly with the PMAPI pmContext
    creation mechanism.

<Prev in Thread] Current Thread [Next in Thread>
  • pcp updates: python getopts code, exception handling fixes, Nathan Scott <=