pcp
[Top] [All Lists]

Re: [pcp] Few doc issues

To: pcp@xxxxxxxxxxx
Subject: Re: [pcp] Few doc issues
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Mon, 22 Feb 2016 14:25:23 +1100
Cc: marko Myllynen <myllynen@xxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5652E148.1090806@xxxxxxxxxx>
References: <5652E148.1090806@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
On 23/11/15 20:50, Marko Myllynen wrote:

Sorry Marko, it has taken a few months to get to this ...


I see -O described in PCPIntro(1) as expected but pmprobe(1) and
pminfo(1) also discuss an -O related timezone issue which is not
described in PCPIntro(1), pmval(1), or pmdumptext(1). If the issue is a
general one, could the discussion perhaps moved to PCPIntro(1)? (While
at it, perhaps it could also be clarified a bit, I had to read it twice
to get a hang of it.)

I've culled the text from pmprobe(1) and pminfo(1) and revamped the text and inserted it into PCPIntro(1).

Also, in few clients I see this kind of code used in preparation for a
pmSetMode(1) call:
...
I don't think merely by reading the current pmSetMode(1) a client
developer could instantly see something like this would be needed. As
per the best cargo-cult practices I already started to use something
similar in pmrep but might still be nice to have few words about this in
pmSetMode(1)?

Fair point ... 1. this code is ugly and 2. the pmSetMode(1) verbage gives no clue how to use PM_XTB_SET().

I've reworked pmSetMode(1) to try and explain better and give a less convoluted example.

Lemme know if these changes help once my commits percolate back to the main tree.

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