On 18 Mar 2007, at 00:36, Michael G Schwern wrote:
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
...
No - just expressing myself badly. What I meant was more like 'we
could plug this syntax in in the same way that we do the YAMLish
reader / writer'.
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.
Yes. Sorry for the confusion.
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.
Ah. Penny drops. Thanks.
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.
That's OK in the simple case but you might want to see if the test
failed and then do some work to build the diagnostic data. So you'd
have to optionally be able to
is ( 23, 42 );
my $info = { foo => "bar", name => "is 23 42?" };
details( $info );
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.
[snip good reasons]
OK, I'll make it work like that. Sorry I haven't been paying more
attention :)
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 think it's worthwhile to define the subset of YAML that we expect
to see. If you just say it's YAML then potentially you're requiring
the baggage of a hugely complex parser.
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.
That's not the only reason. YAML::Tiny is more about reading and
writing config files than safely round-tripping arbitrary data
structures. So, for example, it doesn't handle unprintable characters
in hash keys correctly. I could fix that and also
Write doesn't quote unprintables correctly (fix supplied)
http://rt.cpan.org/Public/Bug/Display.html?id=25509
but by then it starts to look more sensible to implement our own well
defined subset of YAML that's designed for safe round tripping of
whatever data is thrown at it.
--
Andy Armstrong, hexten.net
