Andy Armstrong wrote:
> ( I'm going to be calling the YAML diagnostic syntax YAMLish and I
> reckon this !!!! proposal should be called bang+ :)
I'm calling it the logging proposal for lack of anything better. The bangs
are now gone.
>> Yeah, brevity. Pretty much. And human readability. YAML is pretty
>> good and
>> all but some text prefixed with some bangs is always going to be
>> easier to read.
>
> OK, well it wouldn't be too hard to modify the YAMLish reader / writer
> to handle this syntax too.
You mentioned that one wiki, too, and it confused me. What does the YAML
reader have to do with the bang syntax? Are you proposing something like:
not ok 1
---
!!!! Failed test in foo.t line 23.
got: this
exepected: that
...
That's something I'd very, very much like to avoid. It means TAP parsers now
have to write their own customized YAML parsers and we lose the benefits of
using an established syntax.
> But I have to say I'm not 100% convinced. Weighing the (arguable)
> readability advantage against the use of an established format (which is
> still pretty readable) I think I come down on the YAML side. Of course
> that might be because I've spent the last couple of days writing the
> YAMLish reader / writer :)
Its not either / or. They're complimentary. Most test failure diagnostics
are going to be structured and use structured YAML diagnostics. But sometimes
you just need to print a line of text. And outputting a full blown YAML
document for that is visual overkill. For that there's the logging syntax.
> The general problem being that we don't know whether a YAML block is
> associated with a test or is just a disassociated comment?
Yes, which is something that's probably going to have to be fixed as I can see
a reason to want structured diagnostics not associated with a test. I think
you mentioned that, too.
> From the producer side I'm hoping to be able to come up with a clean way
> of marshalling all the diagnostics associated with a particular test and
> then outputting them as a single YAML document presumably either just
> before the next test or at the end of the test run in the case of the
> last test.
Oh, that's easy.
is( 23, 42, { foo => "bar", name => "is 23 42?" });
If the "name" argument is a hash ref we interpret it instead as extra
diagnostics.
>> *psst* Remember to indent
>>
>> not ok 1
>> ---
>> message: WHOA! The fabric of the universe just broke down!
>> severity: fatal
>> ...
>
> I must have missed the rationale for indenting the YAML. What's that about?
Several reasons. Its easier for the human to still see the "ok" and "not ok"
lines around all that YAML so you can still do eyeball parsing.
not ok 1
---
got: this
expected: that
...
not ok 2
---
got: up
expected: down
...
vs
not ok 1
---
got: this
expected: that
...
not ok 2
---
got: up
expected: down
...
It prevents confusion with existing parsers.
$ cat ~/tmp/foo.t
#!/usr/bin/perl -w
print <<"END";
1..1
ok 1
---
ok: 1
...
END
$ prove ~/tmp/foo.t
/Users/schwern/tmp/foo....FAILED test 2
Failed 1/1 tests, 0.00% okay
It prevents any existing TAP producer which might be dumping YAML to STDOUT
from being parsed.
Finally it allows the ... to be accidentally omitted without the YAML parser
swallowing up all the remaining tests. Sort of a fail-safe.
not ok 1
---
got: this
expected: that
ok 2
The TAP parser simply starts at /^\s+---\s*$/ and ends at either /^\s+...\s*$/
or the next test line. This means the TAP parser needs no knowledge of YAML,
just the start and end of document delimiters. It also allows the TAP parser
to pass a complete document to the YAML parser, the YAML parser does not have
to stream. Means you can use most off-the-shelf YAML parsers.
I've been wondering why you're doing all the work altering YAML::Tiny into a
stream parser. It should not be necessary and it means TAP::Parser has to
maintain its own YAML parser.
