bug#14781: coding system changes cause make check to hang in icalendar tests

bug#14781: coding system changes cause make check to hang in icalendar tests

[Glenn Morris]

Package: emacs
Severity: important
Version: 24.3.50

Current trunk, GNU/Linux, make check is broken by recent changes related
to coding systems (I suspect):

make check
...
Converting iCalendar...done
   passed  122/331  icalendar-import-with-uid
Preparing iCalendar...
Preparing iCalendar...done
Reading iCalendar...
Reading iCalendar...done
Converting iCalendar...
Converting iCalendar...done
Saving file /tmp/icalendar-test-diary13327GoO...
Wrote /tmp/icalendar-test-diary13327GoO
Converting iCalendar...done
Preparing iCalendar...
Preparing iCalendar...done
Reading iCalendar...
Reading iCalendar...done
Converting iCalendar...
Converting iCalendar...done
Saving file /tmp/icalendar-test-diary13327TyU...
Wrote /tmp/icalendar-test-diary13327TyU
Converting iCalendar...done
Preparing iCalendar...
Preparing iCalendar...done
Reading iCalendar...
Reading iCalendar...done
Converting iCalendar...
Converting iCalendar...done
Saving file /tmp/icalendar-test-diary13327g8a...
Wrote /tmp/icalendar-test-diary13327g8a
Converting iCalendar...done
Preparing iCalendar...
Preparing iCalendar...done
Reading iCalendar...
Reading iCalendar...done
Converting iCalendar...
Converting iCalendar...done
Saving file /tmp/icalendar-test-diary13327tGh...
Wrote /tmp/icalendar-test-diary13327tGh
Converting iCalendar...done
Preparing iCalendar...
Preparing iCalendar...done
Reading iCalendar...
Reading iCalendar...done
Converting iCalendar...
Converting iCalendar...done
Saving file /tmp/icalendar-test-diary133276Qn...
Select coding system (default chinese-iso-8bit): 

...hangs waiting for input.

bug#14781: coding system changes cause make check to hang in icalendar tests

[Kenichi Handa]

In article <6zju35ux8.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:

> Current trunk, GNU/Linux, make check is broken by recent changes related
> to coding systems (I suspect):

> make check
> ...
> Converting iCalendar...done
>    passed  122/331  icalendar-import-with-uid
[...]
> Saving file /tmp/icalendar-test-diary133276Qn...
> Select coding system (default chinese-iso-8bit): 

> ...hangs waiting for input.

I've just committed a fix to the trunk.  Actually, the
culprit was test/automated/decoder-tests.el which changes
priorities of coding systems.  I didn't know that all tests
under test/automated are executed in a single Emacs session,
and thus they must be side-effect free.  Isn't it better to
execute each test file in its own Emacs session?

---
Kenichi Handa
handa@gnu.org

bug#14781: coding system changes cause make check to hang in icalendar tests

[Glenn Morris]

Kenichi Handa wrote:

> I've just committed a fix to the trunk.

Thanks.

>  Actually, the culprit was test/automated/decoder-tests.el which
> changes priorities of coding systems. I didn't know that all tests
> under test/automated are executed in a single Emacs session, and thus
> they must be side-effect free.

I think they should all be side-effect free (as much as possible)
anyway. Someone might well want to run an individual test in an existing
Emacs session, without that session getting messed up.

> Isn't it better to execute each test file in its own Emacs session?

I don't know. Running them all in one is the only way to get the final
number of tests run / passed / failed to be accurate. Running them in
separate Emacs's would allow them to run in parallel, which would be
faster, but might be confusing?

bug#14781: coding system changes cause make check to hang in icalendar tests

[Stefan Monnier]

> number of tests run / passed / failed to be accurate. Running them in
> separate Emacs's would allow them to run in parallel, which would be
> faster, but might be confusing?

The time to run each test tends to be small, so the overhead of starting
a separate Emacs session for each one may dwarf the potential speed up
from parallel execution, unless you have hundreds of cores.


        Stefan

bug#14781: coding system changes cause make check to hang in icalendar tests

[Glenn Morris]

Stefan Monnier wrote:

>> number of tests run / passed / failed to be accurate. Running them in
>> separate Emacs's would allow them to run in parallel, which would be
>> faster, but might be confusing?
>
> The time to run each test tends to be small, so the overhead of starting
> a separate Emacs session for each one may dwarf the potential speed up
> from parallel execution, unless you have hundreds of cores.

I was meaning one Emacs per file, not per test.
I get about a factor of 2 speed-up on 4 cores this way.
The main issue holding it back is the wildly varying length of time that
each test file takes (the file-notify ones are slow for me).

bug#14781: coding system changes cause make check to hang in icalendar tests

[Handa Kenichi]

In article <dmr4f96lki.fsf@fencepost.gnu.org>, Glenn Morris
<rgm@gnu.org> writes:

> >  Actually, the culprit was test/automated/decoder-tests.el which
> > changes priorities of coding systems. I didn't know that all tests
> > under test/automated are executed in a single Emacs session, and
> > thus
> > they must be side-effect free.

> I think they should all be side-effect free (as much as possible)
> anyway. Someone might well want to run an individual test in an
> existing
> Emacs session, without that session getting messed up.

I generally agree that keeping a test code site-effect free
is a good thing, and it makes testing a test code easier.
But, sometimes achieving side-effect free is difficult, and
in such a case, I think we don't have to spend much effort
on it.  The main purpose of test is to find bugs.

> > Isn't it better to execute each test file in its own Emacs session?

> I don't know. Running them all in one is the only way to get the final
> number of tests run / passed / failed to be accurate.

Here's a rough idea to do that in test/automated/Makefile.in.

TEST_RESULTS = $(patsubst %.el, %.dat, $(wildcard *.el))

.SUFFIXES: .dat .el 

.el.dat:
        @$(emacs) -f ert-run-tests-batch-and-exit-with-report $< $@

check: $(TEST_RESULTS)
        @$(emacs) -f ert-summarize-test-report $(TEST_RESULTS)

Note that ert-run-tests-batch-and-exit-with-report and
ert-report-test-results are not yet implemented.

> Running them in
> separate Emacs's would allow them to run in parallel, which would be
> faster, but might be confusing?

The faster the better, but I think the speed is not that
important here.  The merit of the above method is that we
can run a single test file just by "make XXXX.dat".

---
Kenichi Handa
handa@gnu.org

bug#14781: coding system changes cause make check to hang in icalendar tests

[Glenn Morris]

Handa Kenichi wrote:

> The merit of the above method is that we can run a single test file
> just by "make XXXX.dat".

You can do that now with not too much effort.

emacs -batch -l ./man-tests.el -f ert-run-tests-batch-and-exit

bug#14781: coding system changes cause make check to hang in icalendar tests

[Glenn Morris]

Handa Kenichi wrote:

> TEST_RESULTS = $(patsubst %.el, %.dat, $(wildcard *.el))

Not portable?
(Though TBH I don't know why we don't just require GNU make and make our
lives easier. But that's a separate issue! :) )

bug#14781: coding system changes cause make check to hang in icalendar tests

[Stefan Monnier]

>> TEST_RESULTS = $(patsubst %.el, %.dat, $(wildcard *.el))
> Not portable?
> (Though TBH I don't know why we don't just require GNU make and make our
> lives easier. But that's a separate issue! :) )

Indeed I think we should use GNUmakefile in `test'.  I already made
that change in the `elpa' branch.

I'm not sure about requiring GNU Make to build Emacs out of a tarball,
but for "side operations" it should not be a problem.

        Stefan

bug#14781: coding system changes cause make check to hang in icalendar tests

[Handa Kenichi]

In article <3ea9lvemla.fsf@fencepost.gnu.org>, Glenn Morris
<rgm@gnu.org> writes:
> Handa Kenichi wrote:
> > TEST_RESULTS = $(patsubst %.el, %.dat, $(wildcard *.el))

> Not portable?
> (Though TBH I don't know why we don't just require GNU make and make
> our
> lives easier. But that's a separate issue! :) )

If portability matters, we can ask the configure script to
generate a proper values:

TEST_RESULTS = %TEST_RESULTS%

> > The merit of the above method is that we can run a single test file
> > just by "make XXXX.dat".

> You can do that now with not too much effort.

> emacs -batch -l ./man-tests.el -f ert-run-tests-batch-and-exit

Not that simple. We must do:

EMACSLOADPATH=../../lisp:. LC_ALL=C ../../src/emacs -batch --no-site-file --no-site-lisp -l ./man-tests.el -f ert-run-tests-batch-and-exit

In article <jwvbo6akdj2.fsf-monnier+emacs@gnu.org>, Stefan Monnier
<monnier@IRO.UMontreal.CA> writes:

> Indeed I think we should use GNUmakefile in `test'.  I already made
> that change in the `elpa' branch.

> I'm not sure about requiring GNU Make to build Emacs out of a tarball,
> but for "side operations" it should not be a problem.

I fully agree.

---
Kenichi Handa
handa@gnu.org