Andy Armstrong wrote: > On 16 Mar 2007, at 02:52, Michael G Schwern wrote: >> The reason being that the parser should know if there's diagnostics >> forthcoming for the current test. This allows a TAP displayer to >> display the >> complete information for a test without having to wait, possibly a >> long time, >> for the next test line. > > It only has to wait for end-of-YAML - which it'd have to wait for > anyway before it could display anything. So as soon as it sees the > '...' it outputs the decoded YAML.
The problem is not knowing when the YAML ends, its knowing if there's any forthcoming at all. Consider if we go with your plan. print "not ok 1\n"; print <<'END'; --- you're fucked: so fucking fucked ... END print "not ok 2\n"; sleep 1000; # simulating a long test print "ok 3\n"; Consider that we're a GUI TAP displayer. When a test fails we want to pop up a little balloon saying what failed and why, so we want to know what failed and why before we do that. We read the first line and see that test 1 failed, maybe there's some diagnostics forthcoming? We read the next line and see the ---. Ah ha, diagnostics. Ok, we read until the ... and then display our popup with all the failure information. We read the next line and see test 2 failed. Maybe there's some diagnostics forthcoming so we go to read the next line... and block for 1000 seconds. Finally we see test 3 passed. Now we know there's no diagnostics forthcoming so we can display that test 2 failed, but 1000 seconds delayed. That's the situation I'm trying to avoid, I'd like TAP to stream without needing any sort of look-ahead. So the marker indicating "there diagnostics forthcoming about this test" goes on the same line as the test itself. The parser can know just by reading one line if there's anything forthcoming or if it has all the information its going to get. I chose "#---" since most existing TAP parsers should ignore it, backwards compatible. The particulars of the syntax are debatable but it has to stream.
