pcp
[Top] [All Lists]

Re: performance co-pilot

To: Michael Werner <mtw@xxxxxxxxxxxxxx>
Subject: Re: performance co-pilot
From: Martin Hicks <mort@xxxxxxx>
Date: Wed, 13 May 2009 11:57:44 -0500
Cc: pcp@xxxxxxxxxxx
In-reply-to: <4B59A019-4FFB-4011-B2C8-FAB1FA610268@xxxxxxxxxxxxxx>
References: <C8A14028-6322-4B8A-B85C-2EF898C5CEFB@xxxxxxxxxxxxxx> <20090513120735.GH14353@xxxxxxxxxxxxxxxxxxxxxxxxx> <4B59A019-4FFB-4011-B2C8-FAB1FA610268@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.17 (2007-11-01)
CCing the PCP list...

On Wed, May 13, 2009 at 12:21:49PM -0400, Michael Werner wrote:
>
> It's way over 40k. Can you put the review copy up on the
> oss ftp drop?

Yeah, send me a copy and I'll stick it on oss.

> Currently, this is structured as a typical standalone python
> extension, built and installed via distutils. It is not dovetailed
> into the sgi sources or the build, install, or pkg process.
>
> Should it be dovetailled in? And, how and where?

I suppose it could do either...we could have it as a separate package to
build and install.  Maybe that is the best way, as it would avoid having
to install python bits to compile PCP.

> A couple dependancy issues come immediately to mind.
>
> *) my extension uses the ctypes facilities, meaning python 2.5
> is required - or a lesser version plus a separate ctypes extension

Okay.  The .deb or .rpm and build system can test for this, I'm sure.

> *) many appliances or embedded systems, which one might
> want to monitor, are likely to not have python at all.

A lot of embedded systems don't have perl either, so it's up to the
writer of the PMDA to decide which wrapper set to write their PMDA in...

mh

>
> - mtw
>
> On May 13, 2009, at 8:07 AM, Martin Hicks wrote:
>
>>
>> On Tue, May 12, 2009 at 06:41:36PM -0400, Michael Werner wrote:
>>> Hi Martin,
>>>
>>> I've made some python wrappers for PCP. Who should I talk
>>> with about getting them posted on oss?
>>
>> Hi,
>>
>> You should definitely post them to the mailing list.  This will get the
>> experts involved and will allow us to review the code.
>>
>> If they're really big (the mailing list may have a 40kB limit) then
>> split the patch up or post it to a website.
>>
>> ...don't compress (zip, gzip) the patches you mail out.  That makes it
>> easier to review in-line in a response.
>>
>> Sounds excellent Michael.  I'm a fan of python, so I'd like to see your
>> wrappers in the tree.
>>
>> mh

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