| To: | Nathan Scott <nathans@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [pcp] qa/859 and python problem in fetchgroup wrapper? |
| From: | Ken McDonell <kenj@xxxxxxxxxxxxxxxx> |
| Date: | Thu, 17 Mar 2016 11:33:26 +1100 |
| Cc: | PCP <pcp@xxxxxxxxxxx>, "Goodwin, Mark" <mgoodwin@xxxxxxxxxx> |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <2006381259.32031610.1458169244700.JavaMail.zimbra@xxxxxxxxxx> |
| References: | <56E9CD24.4050501@xxxxxxxxxxxxxxxx> <9566995.32026348.1458166426505.JavaMail.zimbra@xxxxxxxxxx> <56E9E306.9070108@xxxxxxxxxxxxxxxx> <2006381259.32031610.1458169244700.JavaMail.zimbra@xxxxxxxxxx> |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
On 17/03/16 10:00, Nathan Scott wrote: ... Nothing clean - have a look at pmUnits which deals with HAVE_BITFIELDS_LTOR. We could add a symbol like HAVE_32BIT_USEC (or some better name) and expose that in python-land, then hook it up via the c_api like pmUnits does. Would need it to come all the way from configure.ac I guess. Well before doing that ... I changed tv_sec from c_long to c_int and PRESTO! qa/859 and qa/842 BOTH pass. Now back to configure.ac to sort out how to get this right on all platforms.Note that struct timeval and struct timespec both have a woeful track record in terms of portability ... which is why we have so much pain internally translating from whatever the external API defines into something we can reliably use internally. ... Sigh. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [pcp] qa/842 failing on Mac OS X ... wrong values from pmiostat, Ken McDonell |
|---|---|
| Next by Date: | pcp updates: python struct timeval fix & qa, Ken McDonell |
| Previous by Thread: | Re: [pcp] qa/859 and python problem in fetchgroup wrapper?, Nathan Scott |
| Next by Thread: | qa/709 failing on Mac OS X - pmcollectl, Ken McDonell |
| Indexes: | [Date] [Thread] [Top] [All Lists] |