IRC channel logs
2025-09-07.log
back to list of logs
<tianshu>Is there a way to quit all debug levels(back to the top level)? <dsmith>tianshu, That sure would be nice, but I don't think there is. <rlb>oops, missing a space. <rlb>i.e. " (unless (null? args) (display " " trs-port) (write args trs-port)) <rlb>And thanks -- I'll probably go with something like that soon. <rlb>i.e. that causes rafill to be called with three args, not two. <dsmith>rlb, Here is an argument for letting all the *.tests run: In the summary that's printed at the end, there are listed the number of FAIL, XPASS, and ERROR, none of which will ever be printed if make stops on those. <dsmith>Note that the make *does* still halt on an error, but does print the summary and also exit status of main is 2 <dsmith>Note that the make *does* still halt on an error, and prints the summary and also make has an exit status of 2 <rlb>I'll have to remember/undrstand things a bit better to be sure, but does that mean that if you aren't running under the test harness, you'll never know there was a problem? <rlb>i.e. if the reason you know is because you have a trs-port and something watching that log (automake's driver). <rlb>When you don't, you'll still exit 0, but nothing will know there was really a problem. <rlb>(But I might be misunderstanding -- just glanced.) <rlb>OK, so normally, when no test protocol is in use an exit status of 0 means success, 77, skipped, 99 hard error, and anything else a failure, but since we're running under the parallel test harness/protocol, I think that doesn't apply? Looking to see if then, maybe any non-zero exit is a hard error, which would explain the case you've described. <rlb>If that's right, I suppose we could decide to exit 0 whenever we have a trs-port, though that's adding more semantics to --trs-port than I'd originally intended. <rlb>s/--trs-port/--trs-file/ <rlb>dsmith: I guess a key question might be whether we should try (if possible) to distinguish "hard errors", i.e. would it be appropriate to just halt if say the test code itself is broken (as in the original case here), or would you still want it to keep going? <rlb>dsmith: ...so I think the idea makes sense, but may need a bit more percolation, unless we just want to say that --trs-file implies '"always" exit 0" or something (cf. --flag-unresolved). <tianshu>dsmith: that's the weird. so how people deals with these debug levels, just ignore them? <identity>tianshu: if you are not going to use the debugger, just ,q before they get a chance to pile up <dsmith>rlb, Yes, a "hard error" (a broken test harness) ought to stop immediately IMHO. <dsmith>Heh: "The exact meaning of “hard error” is highly dependent from the test protocols or conventions in use." <rlb>wait, in the case you hit, it was ending up with 'error in guile-test? <dsmith>Well, I don't know what happned when I hit the backtrace (the unhandled . args) <rlb>So maybe we have two guile-test modes, one is with the parallel test harness, where we only want it to exit nonzero for "real" crashes, and the other is without that, where we want nonzero for any failures, and bonus points for 99 for "real" crashes (making it nicer with non-parallel-test-harness cases). <rlb>If so, then the question becomes how we want to shoehorn that into guile-test args. <rlb>(might also want a top-level "catch" for main that redirect anything that makes it to the top level to an exit 99 for the second mode) <dsmith>rlb, Good questions. Eeach *.test file is started as a separate process under make. It's test-suite/guile-test that potentiall returns the exit that halt make. <dsmith>I don't know how/what generates that summary. <rlb>The summary comes at the end via the test harness -- it compiles all the trs files. <dsmith>Hmmm. Looks like it's some in-line awk scripts in the Makefile