pcp
[Top] [All Lists]

Re: pmtime clients (was Re: [pcp] Simple fix needed, not docs? (was Re:

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: pmtime clients (was Re: [pcp] Simple fix needed, not docs? (was Re: RFC2: fetchgroup api))
From: Marko Myllynen <myllynen@xxxxxxxxxx>
Date: Mon, 7 Dec 2015 23:43:52 +0200
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1144153752.37210672.1449521359962.JavaMail.zimbra@xxxxxxxxxx>
Organization: Red Hat
References: <20151201145903.GB31003@xxxxxxxxxx> <1224565686.32458903.1449038493129.JavaMail.zimbra@xxxxxxxxxx> <20151203001437.GA2531@xxxxxxxxxx> <37369073.33594680.1449118672756.JavaMail.zimbra@xxxxxxxxxx> <20151203141450.GB2531@xxxxxxxxxx> <447344479.34949675.1449195913043.JavaMail.zimbra@xxxxxxxxxx> <56652F54.7070004@xxxxxxxxxx> <1144153752.37210672.1449521359962.JavaMail.zimbra@xxxxxxxxxx>
Reply-to: myllynen@xxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
Hi,

On 2015-12-07 22:49, Nathan Scott wrote:
> ----- Original Message -----
>> [...]
>> how is this -g switch supposed to work by the way? I tested the fixed
>> pmstat -g and also pmval -g and pmdumptext -g. pmstat -g / pmval -g give
>> me a pop-up window complaining "pmtime: invalid option -- 'h'",
> 
> You'll need a pmtime(1) binary built from git master installed.

thanks, pmval/pmstat -g/-p both work ok then.

>> pmdumptext -g seems to be a no-op? -p works as expected with
>> pmstat/pmval but does nothing with pmdumptext.
> 
> OK, I'll check out pmdumptext today, but possibly similar root cause.

Turns out it's been mentioned in the past:

http://www.pcp.io/pipermail/pcp/2009-November/000692.html

>> I was mainly checking whether this would be something to consider in the
>> context of pmrep but honestly I don't see this functionality very
>> useful. Also not sure how much client side coding that would be needed,
>> enabling -g/-p via Python PMAPI didn't seem to be enough.
> 
> You need a bit of client side logic, yep - a callback function or two and
> usually special-case handling for gui-mode inside the fetch loop.  See pmval
> code around opts.guiflag and the pmTimeControls data structure.
> 
> I've found it to be handy in the past for scanning around quickly in large
> archives using pmval - so, yep, could make sense for pmrep.

Hmm, ok, -g is available and would still free up -p for this just in
case we want to do this in the future. I was planning to do one (or two)
cmd line switch renames anyway so perhaps I'll include this as well.

Thanks,

-- 
Marko Myllynen

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