* bug#14781: coding system changes cause make check to hang in icalendar tests
@ 2013-07-03 19:02 Glenn Morris
2013-07-08 12:08 ` Kenichi Handa
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Glenn Morris @ 2013-07-03 19:02 UTC (permalink / raw)
To: 14781
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#14781: coding system changes cause make check to hang in icalendar tests
2013-07-03 19:02 bug#14781: coding system changes cause make check to hang in icalendar tests Glenn Morris
@ 2013-07-08 12:08 ` Kenichi Handa
2013-07-08 16:52 ` Glenn Morris
2013-07-09 1:46 ` Glenn Morris
2 siblings, 0 replies; 10+ messages in thread
From: Kenichi Handa @ 2013-07-08 12:08 UTC (permalink / raw)
To: Glenn Morris; +Cc: 14781
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14781: coding system changes cause make check to hang in icalendar tests
2013-07-03 19:02 bug#14781: coding system changes cause make check to hang in icalendar tests Glenn Morris
2013-07-08 12:08 ` Kenichi Handa
@ 2013-07-08 16:52 ` Glenn Morris
2013-07-08 20:22 ` Stefan Monnier
2013-07-09 13:47 ` Handa Kenichi
2013-07-09 1:46 ` Glenn Morris
2 siblings, 2 replies; 10+ messages in thread
From: Glenn Morris @ 2013-07-08 16:52 UTC (permalink / raw)
To: Kenichi Handa; +Cc: 14781
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14781: coding system changes cause make check to hang in icalendar tests
2013-07-08 16:52 ` Glenn Morris
@ 2013-07-08 20:22 ` Stefan Monnier
2013-07-09 13:47 ` Handa Kenichi
1 sibling, 0 replies; 10+ messages in thread
From: Stefan Monnier @ 2013-07-08 20:22 UTC (permalink / raw)
To: Glenn Morris; +Cc: 14781
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#14781: coding system changes cause make check to hang in icalendar tests
2013-07-08 16:52 ` Glenn Morris
2013-07-08 20:22 ` Stefan Monnier
@ 2013-07-09 13:47 ` Handa Kenichi
2013-07-09 16:08 ` Glenn Morris
2013-07-09 16:15 ` Glenn Morris
1 sibling, 2 replies; 10+ messages in thread
From: Handa Kenichi @ 2013-07-09 13:47 UTC (permalink / raw)
To: Glenn Morris; +Cc: 14781
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
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#14781: coding system changes cause make check to hang in icalendar tests
2013-07-09 13:47 ` Handa Kenichi
@ 2013-07-09 16:08 ` Glenn Morris
2013-07-09 16:15 ` Glenn Morris
1 sibling, 0 replies; 10+ messages in thread
From: Glenn Morris @ 2013-07-09 16:08 UTC (permalink / raw)
To: Handa Kenichi; +Cc: 14781
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14781: coding system changes cause make check to hang in icalendar tests
2013-07-09 13:47 ` Handa Kenichi
2013-07-09 16:08 ` Glenn Morris
@ 2013-07-09 16:15 ` Glenn Morris
2013-07-10 8:49 ` Stefan Monnier
2013-07-11 13:38 ` Handa Kenichi
1 sibling, 2 replies; 10+ messages in thread
From: Glenn Morris @ 2013-07-09 16:15 UTC (permalink / raw)
To: Handa Kenichi; +Cc: 14781
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! :) )
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14781: coding system changes cause make check to hang in icalendar tests
2013-07-09 16:15 ` Glenn Morris
@ 2013-07-10 8:49 ` Stefan Monnier
2013-07-11 13:38 ` Handa Kenichi
1 sibling, 0 replies; 10+ messages in thread
From: Stefan Monnier @ 2013-07-10 8:49 UTC (permalink / raw)
To: Glenn Morris; +Cc: 14781
>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#14781: coding system changes cause make check to hang in icalendar tests
2013-07-09 16:15 ` Glenn Morris
2013-07-10 8:49 ` Stefan Monnier
@ 2013-07-11 13:38 ` Handa Kenichi
1 sibling, 0 replies; 10+ messages in thread
From: Handa Kenichi @ 2013-07-11 13:38 UTC (permalink / raw)
To: Glenn Morris; +Cc: 14781
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14781: coding system changes cause make check to hang in icalendar tests
2013-07-03 19:02 bug#14781: coding system changes cause make check to hang in icalendar tests Glenn Morris
2013-07-08 12:08 ` Kenichi Handa
2013-07-08 16:52 ` Glenn Morris
@ 2013-07-09 1:46 ` Glenn Morris
2 siblings, 0 replies; 10+ messages in thread
From: Glenn Morris @ 2013-07-09 1:46 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 14781
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).
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-07-11 13:38 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-03 19:02 bug#14781: coding system changes cause make check to hang in icalendar tests Glenn Morris
2013-07-08 12:08 ` Kenichi Handa
2013-07-08 16:52 ` Glenn Morris
2013-07-08 20:22 ` Stefan Monnier
2013-07-09 13:47 ` Handa Kenichi
2013-07-09 16:08 ` Glenn Morris
2013-07-09 16:15 ` Glenn Morris
2013-07-10 8:49 ` Stefan Monnier
2013-07-11 13:38 ` Handa Kenichi
2013-07-09 1:46 ` Glenn Morris
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).