texexec --timeout=NN should return nonzero code on timeout
Here is what has come up from the regression testing. [I'll send them one issue/email.] If a texexec job runs out of time (--timeout=NN), the exit code should be nonzero. Right now it's zero; which, I just realized, had slightly confused the error handling by the regression-testing. Here's an example using one of the problematic files in the test repo. [Send the output to a file because it's grows to 14MB.] This command texexec --nonstopmode --timeout=10 tex/context/base/unic-002.tex/test-001.tex exits with error code 0, but this one texexec --nonstopmode tex/context/base/unic-002.tex/test-001.tex exits with error code 1. Maybe if it times out it should exit with its own code (who knows, maybe 23?). [I'm testing the above with 2007.01.23] So I wrote a short Python script (utils/run-it.py in the repo) to handle maximum time and maximum filesize, which the Makefile now uses to wrap the texexec call. -Sanjoy `A nation of slaves is always prepared to applaud the clemency of their master who, in the abuse of absolute power, does not proceed to the last extremes of injustice and oppression.' (Gibbon)
Sanjoy Mahajan wrote:
Here is what has come up from the regression testing. [I'll send them one issue/email.]
If a texexec job runs out of time (--timeout=NN), the exit code should be nonzero. Right now it's zero; which, I just realized, had slightly confused the error handling by the regression-testing.
def timedrun(delay, &block) delay = delay.to_i rescue 0 if delay > 0 then begin report("job started with timeout '#{delay}'") timeout(delay) do yield block end rescue TimeoutError report("job aborted due to timeout '#{delay}'") setvariable('error','timeout') rescue report("job aborted due to error") setvariable('error','fatal error') else report("job finished within timeout '#{delay}'") end else yield block end end should do that (in base/tex.rb)
Here's an example using one of the problematic files in the test repo. [Send the output to a file because it's grows to 14MB.] This command
texexec --nonstopmode --timeout=10 tex/context/base/unic-002.tex/test-001.tex
exits with error code 0, but this one
texexec --nonstopmode tex/context/base/unic-002.tex/test-001.tex
exits with error code 1. Maybe if it times out it should exit with its own code (who knows, maybe 23?).
[I'm testing the above with 2007.01.23]
So I wrote a short Python script (utils/run-it.py in the repo) to handle maximum time and maximum filesize, which the Makefile now uses to wrap the texexec call.
-Sanjoy
`A nation of slaves is always prepared to applaud the clemency of their master who, in the abuse of absolute power, does not proceed to the last extremes of injustice and oppression.' (Gibbon) _______________________________________________ dev-context mailing list dev-context@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-context
-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
If a texexec job runs out of time (--timeout=NN), the exit code should be nonzero. Right now it's zero; which, I just realized, had slightly confused the error handling by the regression-testing. [snip] should do that (in base/tex.rb)
Thanks, I just tested it and it works (exit code is now 1). So that change fixes the issue for the future. It won't solve the issue during regression testing, because the regression tests use the entire context tree as of a certain date (a tex version of chroot). That includes using the ruby scripts from that version. That's why I made the run-it.py wrapper despite knowing that you would fix the texexec return code :-) I thought about the pros and cons of running the latest texexec using the old macros, which would mean not needing the run-it.py wrapper. I don't think it's worth it. A document is produced by the whole system of scripts + ConTeXt macros (+ pdftex, but it cannot so easily be downgraded/upgraded automatically...). So we should test the whole system (i.e. including the old scripts) rather than just the macros. -Sanjoy `Not all those who wander are lost.' (J.R.R. Tolkien)
Sanjoy Mahajan wrote:
It won't solve the issue during regression testing, because the regression tests use the entire context tree as of a certain date (a tex version of chroot). That includes using the ruby scripts from that version. That's why I made the run-it.py wrapper despite knowing that you would fix the texexec return code :-)
sure, makes much sense
I thought about the pros and cons of running the latest texexec using the old macros, which would mean not needing the run-it.py wrapper. I don't think it's worth it. A document is produced by the whole system of scripts + ConTeXt macros (+ pdftex, but it cannot so easily be downgraded/upgraded automatically...). So we should test the whole system (i.e. including the old scripts) rather than just the macros.
no, wrappers make sense Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (2)
-
Hans Hagen -
Sanjoy Mahajan