Sebastien Vauban
wxhgmqzgw...@spammotel.com writes:
I don't understand why once there are 192 tests, once 130. I thought that the
second figure was the total number of tests, hence should be stable over the
test runs?
The number of available tests depend on the Babel languages that are
Nicolas Goaziou n.goaz...@gmail.com writes:
I cannot reproduce any of them, interactively or in batch mode[1].
This is the invocation (to be run in bash, like make would do):
TMPDIR=/tmp/tmp-orgtest /usr/local/bin/emacs -batch -Q \
-L lisp/ -L testing/ -L contrib/lisp \
--eval '(defconst
Hello,
Achim Gratz strom...@nexgo.de writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
I cannot reproduce any of them, interactively or in batch mode[1].
This is the invocation (to be run in bash, like make would do):
TMPDIR=/tmp/tmp-orgtest /usr/local/bin/emacs -batch -Q \
-L lisp/ -L
Nicolas Goaziou n.goaz...@gmail.com writes:
[...]
2 unexpected results:
FAILED test-org-export/export-scope
FAILED test-org-footnote/normalize-outside-org
With your command, I was able to reproduce the first one (along with 24
unexpected results), for which I have pushed a fix. I
Achim Gratz strom...@nexgo.de writes:
Well, that is likely because you run the test on uncompiled source,
while I am running it on compiled orgmode... maybe one of these pesky
byte-compiler warnings shouldn't have been ignored. I can't reproduce
the 24 unexpected results, but they probably
Nicolas Goaziou n.goaz...@gmail.com writes:
So, indeed, the second failing test appears. It should pass now (at
least it does even on my compiled Org installation).
I confirm the fix, thank you very much.
I think the others come from a file-error (Opening output file).
I can see now why
Achim Gratz strom...@nexgo.de writes:
It all works now when adding testing/ to the load path. I'll add
this to the default configuration in my Makefile fork.
I've improved the test invocation in my Makefile fork. It now starts
from a clean Emacs invocation withoutsite startup and loads the
Two test failures in current HEAD:
--8---cut here---start-8---
Test test-org-footnote/normalize-outside-org backtrace:
org-footnote-in-valid-context-p()
org-footnote-at-reference-p()
byte-code(\20\304\202 \305\n\306#\204\307\310\311\\21\20
Hello,
Achim Gratz strom...@nexgo.de writes:
Two test failures in current HEAD:
I cannot reproduce any of them, interactively or in batch mode[1].
I'm not sure where they could come from.
Regards,
[1] Though, I have 8 unexpected failures there, but not related to
those described here.
--
Hello Achim,
Achim Gratz wrote:
Two test failures in current HEAD:
Test test-org-footnote/normalize-outside-org backtrace:
org-footnote-in-valid-context-p()
[...]
normal-top-level()
Test test-org-footnote/normalize-outside-org condition:
(void-variable
Hello,
Achim Gratz strom...@nexgo.de writes:
There's another patch by Nicolas that added a few test, one of which
seems broken:
This should be fixed now. Thank you for reporting it.
Regards,
--
Nicolas Goaziou
Nicolas Goaziou n.goaz...@gmail.com writes:
This should be fixed now. Thank you for reporting it.
I confirm the fix, testing is clean again, thank you very much.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptation for Waldorf microQ V2.22R2:
Eric Schulte eric.schu...@gmx.com writes:
[...]
Thanks for your latest round of patches. It all works now when adding
testing/ to the load path. I'll add this to the default configuration
in my Makefile fork. There's another patch by Nicolas that added a few
test, one of which seems broken:
Moving forward on this point, many of the existing tests explicitly
`require' new Org-mode functionality (mainly language support for
testing code blocks execution). I do not think that tests should ever
be activating new packages changing a users global environment.
For this reason I have just
Eric Schulte eric.schu...@gmx.com writes:
Moving forward on this point, many of the existing tests explicitly
`require' new Org-mode functionality (mainly language support for
testing code blocks execution). I do not think that tests should ever
be activating new packages changing a users
Achim Gratz strom...@nexgo.de writes:
Eric Schulte eric.schu...@gmx.com writes:
Moving forward on this point, many of the existing tests explicitly
`require' new Org-mode functionality (mainly language support for
testing code blocks execution). I do not think that tests should ever
be
Eric Schulte eric.schu...@gmx.com writes:
My guess is that when I removed require statements for org-html and
org-ascii from from test-org-html and test-org-exp, they removed some
functionality not loaded by default in the test scripts. These should
probably be added into the Makefile.
Tests for experimental org features (e.g. from contrib/ ) should expect
to fail when the user has not configured their inclusion into the
current setup. In other words, things like (require org-element)
should not break the test run, but instead just note that this test has
failed expectedly and
18 matches
Mail list logo
