Emacs master, w32/w64

Emacs master, w32/w64

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

At the moment, when I ran tests on emacs master build with msys2 on w64,
filenotify-tests take forever long : 15mn on a core i7. I have the feeling
something is wrong with read_event / timeouts. I don't remember something
like this was happening before.

Any idea where to look for to fix this ?

Best regards,

Fabrice

[-- Attachment #2: Type: text/html, Size: 464 bytes --]

Re: Emacs master, w32/w64

[Michael Albinus]

Fabrice Popineau <fabrice.popineau@gmail.com> writes:

> At the moment, when I ran tests on emacs master build with msys2 on
> w64, 
> filenotify-tests take forever long : 15mn on a core i7. I have the
> feeling something is wrong with read_event / timeouts. I don't
> remember something like this was happening before.
>
> Any idea where to look for to fix this ?

Modify n in `file-notify-test06-many-events' to be a smaller number, or
disable that test entirely. It is expected that this test runs for a
while. However, when I have tried this last time (some weeks ago), I
don't remember that all tests in filenotify.el took 15mn. 

Looking into `file-notify--test-timeout', the timeout for "w32notify" is
much larger than the other timeouts. Likely it was me who has declared
this long timeout, but I don't remember the details. It could be a sign
that we have there problems, indeed.

> Best regards,
>
> Fabrice

Best regards, Michael.

Re: Emacs master, w32/w64

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

2015-12-21 22:42 GMT+01:00 Michael Albinus <michael.albinus@gmx.de>:

> Fabrice Popineau <fabrice.popineau@gmail.com> writes:
>
> > At the moment, when I ran tests on emacs master build with msys2 on
> > w64,
> > filenotify-tests take forever long : 15mn on a core i7. I have the
> > feeling something is wrong with read_event / timeouts. I don't
> > remember something like this was happening before.
> >
> > Any idea where to look for to fix this ?
>
> Modify n in `file-notify-test06-many-events' to be a smaller number, or
> disable that test entirely. It is expected that this test runs for a
> while. However, when I have tried this last time (some weeks ago), I
> don't remember that all tests in filenotify.el took 15mn.
>
> Looking into `file-notify--test-timeout', the timeout for "w32notify" is
> much larger than the other timeouts. Likely it was me who has declared
> this long timeout, but I don't remember the details. It could be a sign
> that we have there problems, indeed.
>
>
Thanks for the quick answer. I can see that now.

However :

- both `file-notify-test02-events' and `file-notify-test06-many-events'
fail (with nil instead of the expected value)
- I have the feeling that the read-event calls do not timeout in 0.1s as
expected. When I run file-notify-test02-events
  in edebug mode, read-event does not return in less than 5-10s. I don't
know it is meaningful however.

I'll try to investigate, but I'm not familiar at all with the way all of
this is working.

Fabrice


> > Best regards,
> >
> > Fabrice
>
> Best regards, Michael.
>

[-- Attachment #2: Type: text/html, Size: 2568 bytes --]

Re: Emacs master, w32/w64

[Michael Albinus]

Fabrice Popineau <fabrice.popineau@gmail.com> writes:

> - both `file-notify-test02-events' and
> `file-notify-test06-many-events' fail (with nil instead of the
> expected value)

This is a hint that both test cases did run into their timeouts. It
might be also explain, why it takes so much time for you.

> - I have the feeling that the read-event calls do not timeout in 0.1s
> as expected. When I run file-notify-test02-events 
> in edebug mode, read-event does not return in less than 5-10s. I don't
> know it is meaningful however.

I have no idea how `read-event' behaves on Windows, sorry.

> I'll try to investigate, but I'm not familiar at all with the way all
> of this is working.

> Fabrice

Best regards, Michael.

Re: Emacs master, w32/w64

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Mon, 21 Dec 2015 22:22:22 +0100
> 
> At the moment, when I ran tests on emacs master build with msys2 on w64, 
> filenotify-tests take forever long : 15mn on a core i7. I have the feeling
> something is wrong with read_event / timeouts. I don't remember something like
> this was happening before.

I see no such issue on the emacs-25 branch.  The master branch gets
much less attention these days, and also has a few bugs corrected on
the emacs-25 branch that wasn't yet merged to master.  I suggest that
you switch to tracking emacs-25 for a while, which will also help us
stabilize it faster.

If you see the problem on the emacs-25 branch, please report the
details, and we will investigate with much higher urgency.

Thanks.

Re: Emacs master, w32/w64

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> I see no such issue on the emacs-25 branch.  The master branch gets
> much less attention these days, and also has a few bugs corrected on
> the emacs-25 branch that wasn't yet merged to master.  I suggest that
> you switch to tracking emacs-25 for a while, which will also help us
> stabilize it faster.

In general this is right, but in this special case the master branch is
different. Due to the work on kqueue there are changes in filenotify.el
and filenotify-tests.el, which are not present in the emacs-25
branch. So I propose to trace *this* problem in the master branch.

> Thanks.

Best regards, Michael.

Re: Emacs master, w32/w64

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Fabrice Popineau <fabrice.popineau@gmail.com>,  emacs-devel@gnu.org
> Date: Tue, 22 Dec 2015 11:03:26 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I see no such issue on the emacs-25 branch.  The master branch gets
> > much less attention these days, and also has a few bugs corrected on
> > the emacs-25 branch that wasn't yet merged to master.  I suggest that
> > you switch to tracking emacs-25 for a while, which will also help us
> > stabilize it faster.
> 
> In general this is right, but in this special case the master branch is
> different. Due to the work on kqueue there are changes in filenotify.el
> and filenotify-tests.el, which are not present in the emacs-25
> branch. So I propose to trace *this* problem in the master branch.

People who track master should know that it's currently subtly broken.
The undo changes that didn't receive the fixes they have on the
release branch can corrupt buffers and strings, and that can create
all kinds of weirdo problems that look like bugs somewhere else.
Until we resume merging from emacs-25 to master, I'm afraid looking
for problems on master might sometimes we waste of people's time.

If someone _really_ wants to work on master, I'd suggest them to start
a new local branch and merge emacs-25 to it, before doing any serious
work.