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%)
outputtin
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
Da
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 o
Update of bug #33724 (project findutils):
Status:None => Wont Fix
Assigned to: jay => berny
Open/Closed:Open => Closed
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 and
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 MOUNTE
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
GNU
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, ( 0
> 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 prec
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 4f97df4.
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.
No
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
> 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.
O
13 matches
Mail list logo
