> Date: Thu, 21 Apr 2022 16:56:25 -0700
> Cc: maniku...@gmail.com, emacs-orgm...@gnu.org, 54...@debbugs.gnu.org,
> bug-gnulib@gnu.org
> From: Paul Eggert
>
> What appears to be happening here is that the MS-Windows native
> timestamp resolution is 1/64th of a second, and your system's clock is
On 4/21/22 00:57, Arnold Robbins wrote:
As far as my testing indicates, dfa.c doesn't need a patch, it seems
to accept "---" inside brackets for a single minus.
Yes, a brief perusal of the dfa.c source code suggests you're right.
Thanks for looking into this. I tend to agree with you that POS
What appears to be happening here is that the MS-Windows native
timestamp resolution is 1/64th of a second, and your system's clock is
offset by 0.0075 s from an integer boundary. I.e., the timestamps in
increasing order are:
...
1650522862 + 62/64 + 0.0075 = 1650522862.976250
1650522862
> Date: Fri, 22 Apr 2022 00:23:01 +0700
> Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, 54...@debbugs.gnu.org
> From: Max Nikulin
>
> >> Clock resolution generally has a little common with timers.
> >
> > I agree, but that's something you should tell/ask Paul, not myself.
>
> It may be deeper, e.
On 21/04/2022 22:58, Eli Zaretskii wrote:
Date: Thu, 21 Apr 2022 22:30:21 +0700
From: Max Nikulin
Eli Zaretskii, Wed, 20 Apr 2022 22:30:21
I see the time samples change in jumps of 15 msec. Which is expected
on MS-Windows, given the scheduler time tick,
Why do you expect such value?
It is
Eli Zaretskii, Wed, 20 Apr 2022 22:30:21
I see the time samples change in jumps of 15 msec. Which is expected
on MS-Windows, given the scheduler time tick,
Why do you expect such value? Clock resolution generally has a little
common with timers. Does it mean some protection against timing att
> Date: Thu, 21 Apr 2022 22:30:21 +0700
> Cc: bug-gnulib@gnu.org, 54...@debbugs.gnu.org
> From: Max Nikulin
>
> Eli Zaretskii, Wed, 20 Apr 2022 22:30:21
> > I see the time samples change in jumps of 15 msec. Which is expected
> > on MS-Windows, given the scheduler time tick,
>
> Why do you expe
Hi.
Bruno Haible wrote:
> Is there some realistic possibility that the POSIX regex syntax might be
> extended in the future, in such a way that [^0-9---] means something
> different?
That shouldn't happen, as one can point at V7 Unix and Unix awk and
mawk as treating --- as "-" since forever. E
Paul Eggert wrote on 2015-05-25:
> > the regexp is ambiguous
> > and does not conform to POSIX, which says the following about RE
> > bracket expressions: "To use a as the starting range point,
> > it shall either come first in the bracket expression or be specified
> > as a collating symbol; for
Greetings.
Way back in May of 2015, Nelson Beebe submitted the following
bug report for gawk:
> Date: Mon, 25 May 2015 14:21:04 -0600 (MDT)
> From: "Nelson H. F. Beebe"
> To: "Arnold Robbins"
> Cc: be...@math.utah.edu
> Subject: gawk-4.1.3 regexp error
>
> I just ran an old (1996--date) awk pr
Trying to build nano from git on a NetBSD 9.2 virtual machine, I get this:
[...]
gcc -DHAVE_CONFIG_H -I. -I.. -D_NETBSD_SOURCE -D_XOPEN_SOURCE=600
-I/usr/pkg/include/ncursesw -I/usr/pkg/include -I/usr/pkg/include
-Wno-cast-qual
-Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef
-W
> Date: Wed, 20 Apr 2022 17:11:34 -0700
> Cc: maniku...@gmail.com, emacs-orgm...@gnu.org, 54...@debbugs.gnu.org,
> bug-gnulib@gnu.org
> From: Paul Eggert
>
> On 4/20/22 12:30, Eli Zaretskii wrote:
>
> > I see the time samples change in jumps of 15 msec.
>
> Could you give the first part of the
12 matches
Mail list logo
