----- Original Message ---- > From: chromatic <[EMAIL PROTECTED]> > > On Monday 03 July 2006 09:12, Ovid wrote: > > I am tempted, but there are some problems with parsing TAP output as it > > currently stands. I can write a grammar for it, but the grammar can easily > > produce some output which doesn't make sense.
> Isn't this the syntactic/semantic problem common to all grammars? No, this is a different issue. There are some problems that I'm not worrying about simply because they can't readily be solved, but there are others which are caused by either ambiguity in the spec or lack of any official declaration as to what to do. Currently, the way that Test::Harness::TAP reads, I should properly discard anything which is not a plan, test or diagnostic output. However, test failure output and programmer supplied diagnostic output need to be disambiguated or diagnostic information is unreliable. I've started hacking on TAP::Parser now and it turns out to be a thorny issue. To make it easier, I'm relying on the following quote fom the POD: Any output line that is not a plan, a test line or a diagnostic is incorrect. How a harness handles the incorrect line is undefined. Test::Harness silently ignores incorrect lines, but will become more stringent in the future. In other words, that means that any diag() or test failure messages will automatically be grouped together. This behavior is incorrect as different things need to be different. All you have to do is write "diag 'read() failed'" to potentially confuse someone reading the output. Also, it's ambiguous from the documentation whether or not whitespace is allowed before the qr/(?:not )ok.*\n/. I think it's implied that no leading whitespace is allowed but that could be incorrect. Also, regarding directives, the POD shows both "# skip" and "# SKIP". I assume only the latter was intended, but I bet that will break things. Also, with discussion of upgrades to TAP in the future, unless there's a guarantee that all upgrades will be backwards compatible to the current implementation, we need version numbers in the output. Again, I've not heard any response to this. More that one person has expressed interest in a TAP::Parser and all we need is for those officially supporting/maintaining TAP to say "make it so". Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
