On 8/16/22 12:59, Bruno Haible wrote:
Since this contradicts what you debugged on mingw, I ran the test 1
times on native Windows. Result:
- on 32-bit mingw, no failure.
- on 64-bit mingw, around 30 failures (or around 10 failures with Paul's
newest patch). That is, a probability o
Paul Eggert wrote:
> Emacs 'configure' deliberately suppresses MinGW's clock_gettime.
Ah, this explains why Eli saw the problem in Emacs in a deterministic
manner, whereas I see it only with 0.3% probability in my tests on 64-bit
mingw.
> I installed
> into Gnulib the attached patch, which I hop
Eli Zaretskii wrote:
> Emacs has a with-temp-file macro, which generates a temporary file
> name, executes the body of the macro with a variable bound to the file
> name, then deletes the file. Very handy for writing test suites.
Since, even with Paul's newest patch, gen_tempname on 64-bit mingw
Eli Zaretskii wrote:
> Looking at your test program, I see that you generate the seconds file
> name without deleting the first one. When a file by the first
> generated name already exists, gen_tempname will indeed generate a
> different name. But in the scenario I described, Emacs creates one
>
On 8/16/22 10:47, Eli Zaretskii wrote:
(Why are you talking about MS-DOS?)
I mistakenly thought it was an MS-DOS problem because tempname.c
ordinarily would use clock_gettime on MinGW. I didn't know Emacs
'configure' deliberately suppresses MinGW's clock_gettime.
Thanks, but why not use
> From: Bruno Haible
> Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, la...@gnus.org,
> 57...@debbugs.gnu.org, jporterb...@gmail.com
> Date: Tue, 16 Aug 2022 19:29:33 +0200
>
> > The buffer which visited that file still exists, and still records the
> > name of the file, yes. And then, when the pr
> Date: Tue, 16 Aug 2022 10:30:54 -0700
> Cc: bug-gnulib@gnu.org, la...@gnus.org, 57...@debbugs.gnu.org,
> jporterb...@gmail.com, br...@clisp.org
> From: Paul Eggert
>
> On 8/16/22 10:04, Eli Zaretskii wrote:
> > That "finite number" of 62^6 sounds pretty close to infinity to me!
>
> It's only
> Date: Tue, 16 Aug 2022 10:25:57 -0700
> Cc: bug-gnulib@gnu.org, la...@gnus.org, 57...@debbugs.gnu.org,
> jporterb...@gmail.com
> From: Paul Eggert
>
> On 8/16/22 09:25, Eli Zaretskii wrote:
> > why does this work differently on
> > different platforms?
>
> Platforms that lack clock_gettime an
> Cc: jporterb...@gmail.com, la...@gnus.org, bug-gnulib@gnu.org,
> 57...@debbugs.gnu.org, br...@clisp.org
> Date: Tue, 16 Aug 2022 20:04:49 +0300
> From: Eli Zaretskii
>
> Therefore, if there's no intention to fix this in Gnulib, I'm going to
> update the documentation of make-temp-file so that
On 8/16/22 10:04, Eli Zaretskii wrote:
That "finite number" of 62^6 sounds pretty close to infinity to me!
It's only 57 billion or so. That's not infinity, considering all the
Emacs sessions out there. If Emacs's success grows, almost surely
someone will run into this unlikely bug. Since we h
Thanks for the explanations, Eli.
Eli Zaretskii wrote:
> > Maybe the problem is that the file gets deleted too early, when some parts
> > of Emacs still reference it?
>
> The buffer which visited that file still exists, and still records the
> name of the file, yes. And then, when the program wr
On 8/16/22 09:25, Eli Zaretskii wrote:
why does this work differently on
different platforms?
Platforms that lack clock_gettime and CLOCK_MONOTONIC fall back on a
deterministic algorithm. Presumably MS-DOS one of the few such
platforms, which is why the problem is observed only on MS-DOS.
H
> Date: Tue, 16 Aug 2022 09:54:25 -0700
> Cc: bug-gnulib@gnu.org, la...@gnus.org, 57...@debbugs.gnu.org,
> jporterb...@gmail.com, Bruno Haible
> From: Paul Eggert
>
> On 8/16/22 09:25, Eli Zaretskii wrote:
> > The programmer didn't
> > expect that because it is natural to expect each call to a
On 8/16/22 09:25, Eli Zaretskii wrote:
The programmer didn't
expect that because it is natural to expect each call to a function
that creates a temporary file to create a file under a new name, not
reuse the same name.
Regardless of whether the programmer expects a random name or a
predictable
> From: Bruno Haible
> Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, la...@gnus.org,
> 57...@debbugs.gnu.org, jporterb...@gmail.com
> Date: Tue, 16 Aug 2022 16:40:16 +0200
>
> Eli Zaretskii wrote:
> > Looking at your test program, I see that you generate the seconds file
> > name without deleting
I discovered use of DISTCHECK_CONFIGURE_FLAGS in Makefile.am for several
projects, but that's a user-variable and AM_DISTCHECK_CONFIGURE_FLAGS
should be used.
/Simon
From dec7194206fc1ec7db0a94472d8ece58025040c6 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Tue, 16 Aug 2022 17:26:56 +0200
Eli Zaretskii wrote:
> Looking at your test program, I see that you generate the seconds file
> name without deleting the first one. When a file by the first
> generated name already exists, gen_tempname will indeed generate a
> different name. But in the scenario I described, Emacs creates one
>
Updated patch below.
Meanwhile, I'll disable the public-submodule-commit test in the projects
I work on -- I don't think it is appropriate to run it on every 'make
check' invocation. Disable it by putting this in cfg.mk:
submodule-checks =
gl_public_submodule_commit =
/Simon
diff --git a/top/m
> From: Bruno Haible
> Cc: la...@gnus.org, 57...@debbugs.gnu.org, jporterb...@gmail.com
> Date: Tue, 16 Aug 2022 15:35:17 +0200
>
> Eli Zaretskii wrote:
> > The problem is that callers of
> > make-temp-file reasonably expect it to return a new name every call.
> > And evidently, it does that on G
Eli Zaretskii wrote:
> The problem is that callers of
> make-temp-file reasonably expect it to return a new name every call.
> And evidently, it does that on GNU/Linux (not sure how, given that the
> tempname.c code is supposed to be in glibc?). So if there's no
> intention to change gen_tempname
> Date: Mon, 15 Aug 2022 13:55:35 -0700
> Cc: la...@gnus.org, 57...@debbugs.gnu.org, Jim Porter
> , Gnulib bugs
> From: Paul Eggert
>
> On 8/15/22 11:58, Eli Zaretskii wrote:
>
> > Ah, okay. It's a (mis)feature of Gnulib's gen_tempname function
> > (which is the guts of make-temp-file) in its
Hi
Fetching the gnulib submodule takes quite some time, so I'd like to use
a shallow checkout instead. However I get an error:
jas@latte:~/src/gsasl-small$ make check
GEN public-submodule-commit
fatal: run_command returned non-zero status for gnulib
.
maint.mk: found non-public submodule
22 matches
Mail list logo
