Re: [tap] JSON TAP Diagnostics?

From a personal perspective, I'm an admirer of JSON and its clarity and simplicity, and also prefer only-one-format. It's hard to negotiate between two formats over the wire and get that right. From a standardization perspective, since JSON is already an RFC, and because IETF reviewers loo

Re: TAP Diagnostics

* Andy Armstrong <[EMAIL PROTECTED]> [2008-08-22 00:35]: > Indeed - but there's a sweet spot somewhere between specifying > too little and specifying too much. It's entirely proper that > there should be a debate about where that sweet spot is - and > parsimony should be a guiding principle - but t

Re: JSON TAP Diagnostics?

* Ricardo SIGNES <[EMAIL PROTECTED]> [2008-08-21 19:00]: > Ovid (and I) would like it to be JSON, pending any better idea > (that we agree is better). FWIW, after some consideration, I find myself drifting toward the JSON camp as well. It’s a slow drift, but I just can’t help disliking YAML for ma

Re: JSON TAP Diagnostics?

* Eric Wilhelm <[EMAIL PROTECTED]> [2008-08-21 18:50]: > Does it have to be just one? Now and forever? It doesn’t have to be *just* one, but it needs to be *at least* one, and specifically at least one that *everyone* supports, so that you can count on having a way to make an emitter and consumer

Re: IETF list? (was Re: JSON TAP Diagnostics?)

On 21 Aug 2008, at 23:37, Michael G Schwern wrote: What IETF list? https://www.ietf.org/mailman/listinfo/tap -- Andy Armstrong, Hexten

IETF list? (was Re: JSON TAP Diagnostics?)

Ovid wrote: > Folks, this really, really needs to go to the IETF list. What IETF list? -- Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!

Re: [tap] TAP Diagnostics

On 21 Aug 2008, at 22:41, chromatic wrote: I've written a handful of TAP producers and consumers myself, as well as software which other people have used in ways I never intended. The more complexity you add to a system to reduce the complexity people have to manage to use your system as yo

Re: TAP Diagnostics

--- On Thu, 21/8/08, chromatic <[EMAIL PROTECTED]> wrote: > I've written a handful of TAP producers and consumers > myself, as well as > software which other people have used in ways I never > intended. The more > complexity you add to a system to reduce the complexity > people have to manage

Re: TAP Diagnostics

On Thursday 21 August 2008 14:29:54 Ovid wrote: > Remember, all of this is OPTIONAL.  If you don't want it, don't use it. I'm not sure that line of thinking works well for standards, OOXML notwithstanding. Acme::Calendar::Mayan might want to define a vigesimal type to encode time intervals; wh

Re: TAP Diagnostics

--- On Thu, 21/8/08, chromatic <[EMAIL PROTECTED]> wrote: > That part is the wad. No, for the most part, it's a simple list of key/value pairs. > (You might find it amusing to note that the SOAP folks > didn't use the > sack/potato/wad metaphor when naming their failure.) SOAP has the problem

Re: TAP Diagnostics

On Aug 21, 2008, at 13:58, chromatic wrote: I wonder why anyone wants a test so complex that its diagnostic requires you to serialize and deserialize objects and/or nested data structures to and from custom TAP producers and consumers, and, if you really need to do that, if you should start

Re: TAP Diagnostics

On Thursday 21 August 2008 13:07:22 Eric Wilhelm wrote: > Well, exactly how are we defining "sack", "potato", and "wad" here, and > how does it have anything to do with what people want? Specifying a serialization format in TAP diagnostics says "Here

Re: TAP Diagnostics

--- On Thu, 21/8/08, Eric Wilhelm <[EMAIL PROTECTED]> wrote: > Well, exactly how are we defining "sack", > "potato", and "wad" here, and > how does it have anything to do with what people want? To be fair, those were chromatic's words, not mine, so I'm not sure exactly what he meant by them and

Re: TAP Diagnostics

# from Ovid # on Thursday 21 August 2008 11:53: >> If TAP goes any further than saying "Yes, you *can* >> stuff a big wad of custom data in this ganky old potato sack >> ... there may be a hole in the bottom ... >> so if there's any other way, we encourage you to do that" ... What would this "any

Re: TAP Diagnostics

--- On Thu, 21/8/08, chromatic <[EMAIL PROTECTED]> wrote: > If TAP goes any further than saying "Yes, you *can* > stuff a big wad of custom > data in this ganky old potato sack, but it's ugly and > covered in spiders and > there may be a hole in the bottom, so if there's any > other way, we enco

Re: TAP Diagnostics

On Thursday 21 August 2008 11:04:11 Eric Wilhelm wrote: > But this raises the question of: what does it mean for a consumer > to "understand" the diagnostic? How far down into the content > (keys/values) of the diagnostic does the TAP spec want to go? What is > the consumer going to *do* with t

Re: JSON TAP Diagnostics?

On Aug 21, 2008, at 09:57, Ricardo SIGNES wrote: Schwern would like it to be YAML (a superset of JSON), with the phrasing "consumers MUST understand JSON and SHOULD understand YAML." +1 David

Re: TAP Diagnostics

# from Ricardo SIGNES # on Thursday 21 August 2008 09:57: >> Does it have to be just one?  Now and forever? > >Some people want the spec to say that diagnostics (not free-form > additional data blocks) are always readable by any TAP consumer, > which means they need a declared format.  It needs to

Re: JSON TAP Diagnostics?

On 21 Aug 2008, at 17:57, Ricardo SIGNES wrote: Ovid (and I) would like it to be JSON, pending any better idea (that we agree is better). I'm in the JSON camp too. -- Andy Armstrong, Hexten

Re: JSON TAP Diagnostics?

Folks, this really, really needs to go to the IETF list. I mentioned in here because the list wasn't set up yet, but IETF list is the official spot for this and we can avoid spamming people here with this. That being said, on with the show! ... --- On Thu, 21/8/08, Eric Wilhelm <[EMAIL PROTEC

Re: JSON TAP Diagnostics?

* Eric Wilhelm <[EMAIL PROTECTED]> [2008-08-21T12:46:59] > # from Ovid > >1. YAML is prettier. > >2. JSON, unlike YAML, is stable. > > > >Let's not forget that the debated requirement for diagnostics is that > > the generators and consumers speak the same language > > Does it have to be just one

Re: JSON TAP Diagnostics?

# from Ovid # on Thursday 21 August 2008 09:28: >> (2) YAML is better suited for complex serialization than JSON. >1. YAML is prettier. >2. JSON, unlike YAML, is stable. > >Let's not forget that the debated requirement for diagnostics is that > the generators and consumers speak the same langua

Re: JSON TAP Diagnostics?

* Ovid <[EMAIL PROTECTED]> [2008-08-21T12:28:52] > Let's not forget that the debated requirement for diagnostics is that the > generators and consumers speak the same language, not that the *consumer* > emit anything in particular. If you prefer the appearance of YAML to JSON, > have the consumer

Re: JSON TAP Diagnostics?

--- On Thu, 21/8/08, Ricardo SIGNES <[EMAIL PROTECTED]> wrote: > * chromatic <[EMAIL PROTECTED]> [2008-08-20T13:59:14] > > Aren't these two separate concerns, human versus > machine readability? The > > latter rarely respects ambiguity. > > Yes. > > Right now, there seem to be two pro-YAML argu

Re: JSON TAP Diagnostics?

* chromatic <[EMAIL PROTECTED]> [2008-08-20T13:59:14] > Aren't these two separate concerns, human versus machine readability? The > latter rarely respects ambiguity. Yes. Right now, there seem to be two pro-YAML arguments. (1) It's easier to for humans read. Sure. I will admit that. It is e

Re: JSON TAP Diagnostics?

On Mon, Aug 18, 2008 at 03:36:15PM +0200, Aristotle Pagaltzis wrote: > * Michael Peters <[EMAIL PROTECTED]> [2008-08-18 15:30]: > > YAML does support things that JSON does not (types, embedded > > documents, etc) but I've been in doubt that we'd ever need > > those things for TAP anyway. > That

Re: JSON TAP Diagnostics?

* Michael G Schwern <[EMAIL PROTECTED]> [2008-08-18T12:26:54] > YAML types can be little more than local tags which only have meaning to that > particular document. > > name: !customer Evil Business Guy Made Of Butter Yeah, that's neat and everything, but there aren't any Perl implementations

Re: JSON TAP Diagnostics?

* Ovid <[EMAIL PROTECTED]> [2008-08-18T11:17:25] > Oh, definitely agreed. I cannot assert that non-Perl implementations of JSON > are any better, but JSON is simple enough that I'm pretty damned sure they > are. However, YAML is so problematic that I *CAN* state that non-Perl > versions are often

Re: JSON TAP Diagnostics?

* David Golden <[EMAIL PROTECTED]> [2008-08-18T09:27:57] > What's the latest consensus on the "best" pure-perl JSON module? And > ditto for JSON via XS? JSON and JSON::XS, most likely. Certainly JSON::XS. -- rjbs

Re: JSON TAP Diagnostics?

* Ovid <[EMAIL PROTECTED]> [2008-08-18T06:50:00] > JSON is fairly well implemented and new implementations are trivial. This is > not true for YAML. Trying to define a minimum standard of YAML for extended > TAP is a quagmire. With JSON, we can punt and just point to a fairly > well-established

Re: JSON TAP Diagnostics?

# from Michael G Schwern # on Monday 18 August 2008 16:55: >>>  The stuff we all agree on and is in wide use.  Extension >>> discussion should be >>> orthogonal so as not to stall the standardization process. >> >> That's the stance I took in Copenhagen last week.  I was unanimously >> voted down.

Re: JSON TAP Diagnostics?

* Andy Armstrong <[EMAIL PROTECTED]> [2008-08-18 17:35]: > I prefer JSON aesthetically apart from any technical > considerations. I don't actually find YAML all that > readable. To programmers' eyes JSON looks more like > code - presumably because it is :) YAML requires less quoting and backslas

Re: JSON TAP Diagnostics?

Ovid wrote: > --- On Tue, 19/8/08, Michael G Schwern <[EMAIL PROTECTED]> wrote: > >> I think we should start the process by specifying TAP >> version 12 aka core TAP. >> The stuff we all agree on and is in wide use. Extension >> discussion should be >> orthogonal so as not to stall the standardi

Re: JSON TAP Diagnostics?

--- On Tue, 19/8/08, Michael G Schwern <[EMAIL PROTECTED]> wrote: > I think we should start the process by specifying TAP > version 12 aka core TAP. > The stuff we all agree on and is in wide use. Extension > discussion should be > orthogonal so as not to stall the standardization process. That

Re: JSON TAP Diagnostics?

Ovid wrote: > --- On Mon, 18/8/08, Michael G Schwern <[EMAIL PROTECTED]> wrote: > >> YAML has several important things that JSON is lacking. > > Without going into detail, I'll just say that you raise some valid points. I > agree with some and not with others, but we should defer this discussi

Re: JSON TAP Diagnostics?

--- On Mon, 18/8/08, Michael G Schwern <[EMAIL PROTECTED]> wrote: > YAML has several important things that JSON is lacking. Without going into detail, I'll just say that you raise some valid points. I agree with some and not with others, but we should defer this discussion until the IETF list

Re: JSON TAP Diagnostics?

On Aug 18, 2008, at 07:03, Ovid wrote: Those are certainly important issues, but JSON will make some of them trivial. The YAML types, embedded documents and the "one format to rule them all" concept is precisely what makes it unsuitable for TAP. That's a damned shame because if there was

Re: jpeg TAP Diagnostics?

# from Ovid # on Monday 18 August 2008 03:50: >JSON is fairly well implemented and new implementations are trivial. >  This is not true for YAML.  Trying to define a minimum standard of > YAML for extended TAP is a quagmire.  With JSON, we can punt and just > point to a fairly well-established JSO

Re: JSON TAP Diagnostics?

Ovid wrote: > One issue which arose at YAPC::EU was the problem with machine-readable TAP > diagnostics. > Since they're not yet implemented, we can change them. The problem we wound up with was > that we have two things to specify: core TAP and extended TAP. Core TAP is s

Re: JSON TAP Diagnostics?

On 18 Aug 2008, at 11:50, Ovid wrote: Thoughts? +1 I prefer JSON aesthetically apart from any technical considerations. I don't actually find YAML all that readable. To programmers' eyes JSON looks more like code - presumably because it is :) -- Andy Armstrong, Hexten

Re: JSON TAP Diagnostics?

--- On Mon, 18/8/08, Dominique Quatravaux <[EMAIL PROTECTED]> wrote: > > YAML::Tiny seems to do everything that JSON does, so I > must now eat crow (nom, nom, nom, gag). > > Well, hope you found it tasty, but JSON is still a > reasonable > alternative to consider if non-Perl implementations are >

Re: JSON TAP Diagnostics?

On Mon, Aug 18, 2008 at 4:12 PM, Ovid <[EMAIL PROTECTED]> wrote: > YAML::Tiny seems to do everything that JSON does, so I must now eat crow > (nom, nom, nom, gag). Well, hope you found it tasty, but JSON is still a reasonable alternative to consider if non-Perl implementations are better than YAM

Re: JSON TAP Diagnostics?

--- On Mon, 18/8/08, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote: > > And for those who would argue for YAML::Tiny as our > spec, it > > already has limitations that hit us at the BBC. > > In what way, and why would that be relevant to TAP? Would > JSON not have those same limitations? I was a

Re: JSON TAP Diagnostics?

--- On Mon, 18/8/08, Michael Peters <[EMAIL PROTECTED]> wrote: > ++ > There are some other things to work out though, like how do > we decide > that a JSON doc has begun (YAML has the nice --- thing), > etc. YAML does > support things that JSON does not (types, embedded > documents, etc) but >

Re: JSON TAP Diagnostics?

On Mon, Aug 18, 2008 at 9:31 AM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote: > Are we still considering human readability a goal for TAP? That For basic TAP, I think it should be a goal. For "extended" TAP, I think the goal is more about machine-readable output so that diagnostics can be collec

Re: JSON TAP Diagnostics?

* Michael Peters <[EMAIL PROTECTED]> [2008-08-18 15:30]: > YAML does support things that JSON does not (types, embedded > documents, etc) but I've been in doubt that we'd ever need > those things for TAP anyway. That would be useful if any of the YAML producers were capable of serialising tricky d

Re: JSON TAP Diagnostics?

* Ovid <[EMAIL PROTECTED]> [2008-08-18 12:55]: > First of all, read that thoroughly. That should take you a few > days. I know, right? When I mention that I always that the YAML spec is much more complex than the XML spec and the XML Namespaces spec put together. (Despite the XML and Namespaces sp

Re: JSON TAP Diagnostics?

Ovid wrote: Thoughts? ++ There are some other things to work out though, like how do we decide that a JSON doc has begun (YAML has the nice --- thing), etc. YAML does support things that JSON does not (types, embedded documents, etc) but I've been in doubt that we'd ever need those things f

Re: JSON TAP Diagnostics?

On Mon, Aug 18, 2008 at 6:50 AM, Ovid <[EMAIL PROTECTED]> wrote: > Thoughts? Likewise, agreed. What's the latest consensus on the "best" pure-perl JSON module? And ditto for JSON via XS? David

Re: JSON TAP Diagnostics?

On Mon, Aug 18, 2008 at 03:50:00AM -0700, Ovid wrote: > Thoughts? Agreement. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net

JSON TAP Diagnostics?

Hi all, One issue which arose at YAPC::EU was the problem with machine-readable TAP diagnostics. Since they're not yet implemented, we can change them. The problem we wound up with was that we have two things to specify: core TAP and extended TAP. Core TAP is simple (well, uh, mostly)

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

A. Pagaltzis wrote: > * Michael G Schwern <[EMAIL PROTECTED]> [2007-09-07 14:40]: >> I'm down with changing it to MUST for TAP meta and MAY for >> diagnostics. > > Works for me. Done. -- Stabbing you in the face for your own good.

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-07 14:40]: > I'm down with changing it to MUST for TAP meta and MAY for > diagnostics. Works for me. Regards, -- Aristotle Pagaltzis //

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

# from Michael G Schwern # on Friday 07 September 2007 05:38 am: >I'm down with changing it to MUST for TAP meta and MAY for > diagnostics. +1 -- If the above message is encrypted and you have lost your pgp key, please send a self-addressed, stamped lead box to the address below. --

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

A. Pagaltzis wrote: > SHOULD is costly and should be avoided in favour of MUST or MAY > wherever possible – we had this discussion we had frequently in > the Atom WG. Over time, given enough implementations, any given > SHOULD tends to be treated as either a MAY or a MUST anyway. > > That reasonin

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

--- "A. Pagaltzis" <[EMAIL PROTECTED]> wrote: > That reasoning leads me to conclude that we can reduce the cost > of this SHOULD over time by making it no formal requirement at > all for app data and a MUST for TAP metainformation right off the > bat. And if we go down this road, we can halt this

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-07 06:40]: > We're not prohibiting other formats, just establishing a > baseline. I think we specifically want to prohibit other formats in TAP metainformation. For app data, we could advise authors to use the same format, but I don’t think > It's

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

A. Pagaltzis wrote: > I don’t think you’re overly conservative when it comes to app > data, but I agree with Ovid that this is bad separation of > concerns. How dates in app data are handled should be up to the > app to define. I think we should restrict this proposal solely to > datetimes in TAP m

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

Ovid wrote: > Whoa! I missed a memo and now I'm confused. I did think that a lot of > this fuss over the date YAML meta information in TAP was going on a > bit, but small details can be important. However, date YAML diagnostic > information (we need formal names to distinguish between those two)

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-06 23:40]: > For example, let's say you're testing some Biblical software > and want to make sure you got your dates right. > > not ok 1 - age of the Earth > > found: -050-02-12 > wanted: -4004

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

le as possible > > to generate as well as consume, without limiting expressiveness > > unnecessarily. > > Yep, we're on the same page. > > To make it clear, the use case for TAP datetimes includes both the > TAP meta > information AND use in the TAP diagnostics to desc

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

> unnecessarily. Yep, we're on the same page. To make it clear, the use case for TAP datetimes includes both the TAP meta information AND use in the TAP diagnostics to describe testing data. For example, let's say you're testing some Biblical software and want to make sure you got

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

Michael Peters wrote: > Ovid wrote: > >> Thanks for reminding me. Another bit of meta-information that should >> be optionally supported in the TAP YAML output is "duration". If one's >> comparing the behavior of a test suite over time, some might find it >> beneficial to know that they've added

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

Ovid wrote: > Thanks for reminding me. Another bit of meta-information that should > be optionally supported in the TAP YAML output is "duration". If one's > comparing the behavior of a test suite over time, some might find it > beneficial to know that they've added 10% more tests but increased

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

--- "A. Pagaltzis" <[EMAIL PROTECTED]> wrote: > The question is, do we need that flexibility? As far as I can > tell, datetimes in TAP would almost always denote instants in > time, not durations nor long-duration recurring events, and it > will always be easy to come up with the current month and

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-04 23:35]: > A. Pagaltzis wrote: > > Actually ISO 8601 gives many more options than RFC 3339, > > which is why the latter was written in the first place. See > > 5.3 (“Rarely Used Options”) in RFC 3339. > > That's why I'm inclined to go with one bas

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

Andy Armstrong wrote: > On 4 Sep 2007, at 22:41, Ovid wrote: >>> What do you think of this? >>> http://testanything.org/wiki/index.php/TAP_datetime >> >> Works for me. > > Yup, looks fine. Maybe we should start noting this on the wiki? Sign proposals with a (Mediawiki signature). http://te

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

On 4 Sep 2007, at 22:41, Ovid wrote: What do you think of this? http://testanything.org/wiki/index.php/TAP_datetime Works for me. Yup, looks fine. -- Andy Armstrong, hexten.net

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

--- Michael G Schwern <[EMAIL PROTECTED]> wrote: > What do you think of this? > http://testanything.org/wiki/index.php/TAP_datetime Works for me. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog -

TAP datetime (was Re: Current state of TAP::Diagnostics)

A. Pagaltzis wrote: > * Michael G Schwern <[EMAIL PROTECTED]> [2007-09-02 09:32]: >> What you're thinking of is RFC3339 which is more describing a >> state of affairs on the Internet then anything else. > > Actually RFC 3339 date and time formats are best practice at the > IETF/IESG. I got RC 333

Re: Current state of TAP::Diagnostics

On 1 Sep 2007, at 18:36, Ovid wrote: [snip] How about something more direct: harness_supports_tap_diagnostics(); I thought about something more verbose, but I confess that I like to avoid longer function names. They irritate people. Still, maybe it's worth it in this case. [snip] ++ for l

Re: Current state of TAP::Diagnostics

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-02 09:31]: > YAML has data types. > http://en.wikipedia.org/wiki/YAML#Data_Types > > Both implicit > > - 3 # integer > - "3" # string > - 123.0 # float > > And explicit > > - !!float 123 # float > - !!str 1

Re: Current state of TAP::Diagnostics

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-02 09:32]: > What you're thinking of is RFC3339 which is more describing a > state of affairs on the Internet then anything else. Actually RFC 3339 date and time formats are best practice at the IETF/IESG. > At best it can be *omitted* (not replace

Re: Current state of TAP::Diagnostics

On 9/2/07, Andy Armstrong <[EMAIL PROTECTED]> wrote: > On 1 Sep 2007, at 19:14, Eric Wilhelm wrote: > >> my $data = 3; > >> my $data = "3"; > > > > YAML::Tiny? > > I don't believe that makes the distinction either. Data::Dump::Streamer specifically does not make a distinction as it just caused

Re: Current state of TAP::Diagnostics

On 1 Sep 2007, at 19:14, Eric Wilhelm wrote: my $data = 3; my $data = "3"; YAML::Tiny? I don't believe that makes the distinction either. -- Andy Armstrong, hexten.net

Re: Current state of TAP::Diagnostics

--- Michael G Schwern <[EMAIL PROTECTED]> wrote: > Or are you asking about the guts of Test::Builder? I haven't planned > it out much but I'm thinking something like... > > # Get the Test::Builder::Diagnostics object. > my $diagnostics = $tb->diagnostics_object; Schwern, It sounds

Re: Current state of TAP::Diagnostics

Fergal Daly wrote: > I'm assuming here that test modules will provide these diagnostics in > a similar way to the old style, something like: > > my $TB = Test::Builder->new() > > sub my_test { > blah(); > $TB->ok(); > if ($TB->can("verbose_diag") { > $TB->verbose_diag({...}); > } else

Re: Current state of TAP::Diagnostics

On 02/09/07, Michael G Schwern <[EMAIL PROTECTED]> wrote: > Fergal Daly wrote: > It goes out via the normal TAP stream with all the "ok" and "not ok". That > is, STDOUT. > > Or are you asking about the guts of Test::Builder? I haven't planned it out > much but I'm thinking something like... > >

Re: Current state of TAP::Diagnostics

Fergal Daly wrote: >> diagnostic( { >> found => $found, # can be stand-alone >> wanted => $wanted, # must always be present with 'found' >> display => $display, # optional human-readable presentation >> extra => $extra, # anything else. Useful for custom harnesses >>

Re: Current state of TAP::Diagnostics

demerphq wrote: > On 9/2/07, Michael G Schwern <[EMAIL PROTECTED]> wrote: >> The first is a single ISO 8601 datetime. The latter is an ISO 8601 date and >> an ISO 8601 time separated by a space. Two data fields instead of one. So >> it's all kosher, we just have to specify that's what we're doin

Re: Current state of TAP::Diagnostics

u maintain > Test::Simple. If we get this working, how would you feel about a patch > to Test::Simple that makes this automatically incorporated into new > test suites which upgrade Test::Simple? The obvious problem is that > this would create a dependency on TAP::Diagnostics (which I&

Re: Current state of TAP::Diagnostics

On 9/2/07, Michael G Schwern <[EMAIL PROTECTED]> wrote: > The first is a single ISO 8601 datetime. The latter is an ISO 8601 date and > an ISO 8601 time separated by a space. Two data fields instead of one. So > it's all kosher, we just have to specify that's what we're doing. > > tapdat

Re: Current state of TAP::Diagnostics

Ovid wrote: > --- Michael G Schwern <[EMAIL PROTECTED]> wrote: > >> As Test::More cannot have any dependencies, I'd rather incorporate >> TAP diagnostic functionality directly into Test::Builder. Besides, >> spitting out some YAML isn't hard. > > It turns out to be a fair bit harder than it appe

Re: Current state of TAP::Diagnostics

Ovid wrote: > --- Eric Wilhelm <[EMAIL PROTECTED]> wrote: > >> I'm not sure the YAML spec distinguishes between string and number >> when >> the string is a number. >> >> $ perl -e 'use YAML; warn YAML::Dump([3,"3"]);' >> --- >> - 3 >> - 3 >> $ perl -e 'use YAML::Syck; warn YAML::Syck::

Re: Current state of TAP::Diagnostics

On 9/1/07, Ovid <[EMAIL PROTECTED]> wrote: > --- Eric Wilhelm <[EMAIL PROTECTED]> wrote: > > > I'm not sure the YAML spec distinguishes between string and number > > when > > the string is a number. > > > > $ perl -e 'use YAML; warn YAML::Dump([3,"3"]);' > > --- > > - 3 > > - 3 > > $ perl

Re: Current state of TAP::Diagnostics

# from Ovid # on Saturday 01 September 2007 11:51 am: >Ah, crud. Is this because YAML doesn't quote things without > whitespace? Or because it is representing numbers as text? > That really seems like a serious limitation to me. Why? > Can I > really keep a straight face and tell a C program

Re: Current state of TAP::Diagnostics

--- Eric Wilhelm <[EMAIL PROTECTED]> wrote: > I'm not sure the YAML spec distinguishes between string and number > when > the string is a number. > > $ perl -e 'use YAML; warn YAML::Dump([3,"3"]);' > --- > - 3 > - 3 > $ perl -e 'use YAML::Syck; warn YAML::Syck::Dump([3,"3"]);' > ---

Re: Current state of TAP::Diagnostics

# from Ovid # on Saturday 01 September 2007 11:22 am: >Except that we cribbed much of our YAML code from YAML tiny and it > gets this wrong, too: > >  $ perl -MYAML::Tiny=Dump -le 'print Dump([3,"3"])' >  --- >  - 3 >  - 3 I'm not sure the YAML spec distinguishes between string and number when t

Re: Current state of TAP::Diagnostics

--- Eric Wilhelm <[EMAIL PROTECTED]> wrote: > # from Ovid > # on Saturday 01 September 2007 10:36 am: > > >> As Test::More cannot have any dependencies, I'd rather incorporate > >> TAP diagnostic functionality directly into Test::Builder. > Besides, > >> spitting out some YAML isn't hard. > > >

Re: Current state of TAP::Diagnostics

# from Ovid # on Saturday 01 September 2007 10:36 am: >> As Test::More cannot have any dependencies, I'd rather incorporate >> TAP diagnostic functionality directly into Test::Builder.  Besides, >> spitting out some YAML isn't hard. > >It turns out to be a fair bit harder than it appears to be on

Re: Current state of TAP::Diagnostics

--- Michael G Schwern <[EMAIL PROTECTED]> wrote: > As Test::More cannot have any dependencies, I'd rather incorporate > TAP diagnostic functionality directly into Test::Builder. Besides, > spitting out some YAML isn't hard. It turns out to be a fair bit harder than it appears to be on the surfac

Re: Current state of TAP::Diagnostics

em is that > this would create a dependency on TAP::Diagnostics (which I'm hoping > will have no non-core dependencies and work on Perl back to 5.005.) It > could also be included with Test::Simple as Test::Diagnostics, if you > prefer. As Test::More cannot have any depend

Current state of TAP::Diagnostics

ch to Test::Simple that makes this automatically incorporated into new test suites which upgrade Test::Simple? The obvious problem is that this would create a dependency on TAP::Diagnostics (which I'm hoping will have no non-core dependencies and work on Perl back to 5.005.) It could also be inc