Re: timevar: 3/3: use clock_gettime to get wall clock time

On macOS, I get an unexpected result for wall clock. Execution times (seconds) CPU user CPU systemwall clock reader 0,017 ( 4%) 0,002 (13%) 0,00 ( 0%) LALR(1) 0,002 ( 0%) 0,000 ( 1%) 0,031250 ( 6%)

Re: timevar: 2/3: improve the output format

I have used the format you suggested to display the times. I’m not sure we should specify the resolution, it kinda of is displayed by the figures themselves, but I’ll do whatever you suggest Bruno. However, see 3/3 before. commit 17bf1247ef4a64e6400df5206bbe570889ef252f Author: Akim Demaille

Re: timevar: 1/3: expect that getrusage is available

Waiting for approval before pushing. commit 65b74a02c39450878ac1c41b870e1188c4a0429e Author: Akim Demaille Date: Thu Oct 11 17:54:35 2018 +0200 timevar: expect that getrusage is available Don't keep both times and getrusage as backend: both are guaranteed by gnulib, a single

[bug #33724] Find command is changing the access time of directory

Update of bug #33724 (project findutils): Status:None => Wont Fix Assigned to: jay => berny Open/Closed:Open => Closed

Re: windows platform test

Hi Assaf, > Is there an agreed-upon #define for mingw/windows which is not cygwin? > > I've seen >#ifdef _WIN32 && ! defined CYGWIN This is syntactically malformed and also tests the wrong symbols. The correct test is #if defined _WIN32 && ! defined __CYGWIN__ > But it seems clumsy

Re: mountlist: platform comments

Hello Bruno, On 11/10/18 03:31 PM, Bruno Haible wrote: The platform comments in mountlist.c and ls-mntd-fs.m4 are not very informative any more. E.g. What is "BSD4.4" nowadays? Why is "Solaris" not mentioned? Here's what I found by compiling a testdir on today's platforms and looking for

mountlist: platform comments

Hi, The platform comments in mountlist.c and ls-mntd-fs.m4 are not very informative any more. E.g. What is "BSD4.4" nowadays? Why is "Solaris" not mentioned? Here's what I found by compiling a testdir on today's platforms and looking for MOUNTED_ in config.h. Linux MOUNTED_GETMNTENT1

Re: timevar: further work

The results with getrusage are indeed much more precise. This is with times. $ ./_build/7s/tests/bison --trace=time ~/Downloads/Z280/asm1a.y asm1a2.y: avertissement: 33 conflits par décalage/réduction [-Wconflicts-sr] Execution times (seconds) reader: 0,0100 ( 2%) usr 0, (

Re: timevar: further work

> Le 11 oct. 2018 à 20:05, Bruno Haible a écrit : > > Hi Akim, > >> Ok. But since really, this tool is not for high quality profile, >> but just to get cost estimates, I did not aim at that level of >> precision. ... >> Also, I don’t think it makes sense to have more than 2 digits >> of

getprogname: support for 32-bit programs on HP-UX

2018-10-11 Bruno Haible getprogname: Add support for 32-bit programs on HP-UX. * lib/getprogname.c (getprogname) [HP-UX]: If pstat_getproc fails, try the similar functions 32-bit programs on 64-bit HP-UX. diff --git a/lib/getprogname.c b/lib/getprogname.c index

Re: timevar: further work

Hi Akim, > Ok. But since really, this tool is not for high quality profile, > but just to get cost estimates, I did not aim at that level of > precision. ... > Also, I don’t think it makes sense to have more than 2 digits > of precision: we are very likely to be within noise already > with 2.

getprogname: improvement on HP-UX

On HP-UX (hppa 64-bit), the test-xalloc-die.sh test fails: *** - Thu Oct 11 15:47:41 2018 --- err2Thu Oct 11 15:55:06 2018 *** *** 1 ! test-xalloc-die: memory exhausted --- 1 ! test-xalloc-di: memory exhausted FAIL test-xalloc-die.sh (exit status: 1) The reason is

Re: timevar: further work

> Le 10 oct. 2018 à 23:50, Bruno Haible a écrit : > > Just make sure that the user understands that the wall clock timings > have microsecond resolution wheras the user+system time values have > a lower resolutions. Since they are in the same line of output, it's > not obvious to understand.