Re: Eliminating STDERR without any disruption.

2007-03-16 Thread Eric Wilhelm
# from A. Pagaltzis # on Friday 16 March 2007 06:08 am: >* Michael G Schwern <[EMAIL PROTECTED]> [2007-03-16 11:55]: >> fatal !!! >> fail !! >> warn ! >> notice >> pass !!! >> info !! >> debug ! > >The most bangs I can count instantly by looking at them is four. I would say anyth

Re: Eliminating STDERR without any disruption.

2007-03-16 Thread A. Pagaltzis
* Michael G Schwern <[EMAIL PROTECTED]> [2007-03-17 01:35]: > Its really not clear what levels !?, ?, X!!X and @ would mean, > or even that they're log messages, without looking it up. I suppose that’s true, although that situation is not really different from the bangs. * Michael G Schwern <[EMA

Re: Eliminating STDERR without any disruption.

2007-03-16 Thread Michael G Schwern
I've put up what seem to be the exiting criticisms of this syntax here: http://perl-qa.yi.org/index.php/TAP_logging_syntax#Criticisms It seems to all be a consequence of mapping numbers (of bangs) to meaning, something I usually rant about avoiding. So some way to put a string label into the prot

Re: Eliminating STDERR without any disruption.

2007-03-16 Thread Michael G Schwern
A. Pagaltzis wrote: > The most bangs I can count instantly by looking at them is four. > For five bangs and up, all I see is “lots of bangs.” I have to > count character by character to tell them apart. Visually, > I can’t distinguish `fatal` from `fail` at all. Another problem > is that I’d never

Re: Eliminating STDERR without any disruption.

2007-03-16 Thread A. Pagaltzis
* Michael G Schwern <[EMAIL PROTECTED]> [2007-03-16 11:55]: > fatal !!! > > > fail !! > > > warn ! > > > notice > > > pass !!! > > > info !! > > > debug ! The most bangs I can count instantly by looking at them is four. For five bangs and up, all I see is “lots of bang

Beating up ideas, not people.

2007-03-16 Thread Michael G Schwern
Lately I've been hammering hard on every TAP proposal asking why this, why not that, why do you think this, what about that, is this really going to be a problem, isn't that situation a little far fetched, not that's not going to work because... and I get really excited and ruthless about beating u

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Andy Armstrong
On 16 Mar 2007, at 11:36, Andy Armstrong wrote: Seems reasonable. [snip] And now I've caught up with the rest of the debate... -- Andy Armstrong, hexten.net

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Andy Armstrong
On 16 Mar 2007, at 10:07, Ovid wrote: Indent the YAML and put it on the next line: not ok 2 'some name' # TODO or not TODO --- some: YAML ... I'm going to say it again just to annoy Michael: not ok 2 'blah' # TODO ## --- ## some: YAML ok 3 -- Andy Armstrong, hexten.net

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Andy Armstrong
On 16 Mar 2007, at 09:59, Michael G Schwern wrote: Or someone can make a convincing argument that the streaming case isn't that important and we can just put the --- on the next line. Well you rarely have to wait /that/ long for something else to come along... -- Andy Armstrong, hexten.ne

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Andy Armstrong
On 16 Mar 2007, at 08:08, Ovid wrote: How do you mark that as a TODO test? not ok 2 # TODO don't know what $foo is #--- Anyone see a problem with that? It's certainly starting to look as if # is a bit over-overloaded. Looks messy if nothing else. -- Andy Armstrong, hexten.net

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Andy Armstrong
On 16 Mar 2007, at 04:34, Michael G Schwern wrote: 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

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Michael G Schwern
Eric Wilhelm wrote: > # from Michael G Schwern > # on Friday 16 March 2007 02:59 am: > >> I chose #--- because 1) its backwards compatible as long as you ignore >> unknown directives and 2) it allows TAP to stream. Otherwise its >> pretty damn inelegant. We could say that a name ending in --- >>

Re: Eliminating STDERR without any disruption.

2007-03-16 Thread Michael G Schwern
Adrian Howard wrote: > Maybe use the levels from Log4J, Log::Log4perl, et al? > > fatal > error > warn > info > debug Ok, maybe take that and tailor it more to testing. Here it is in order of severity. The recommended display level would be "warn". fatal !!! There's an error in the TAP pr

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Eric Wilhelm
# from Michael G Schwern # on Friday 16 March 2007 02:59 am: >I chose #--- because 1) its backwards compatible as long as you ignore > unknown directives and 2) it allows TAP to stream.  Otherwise its > pretty damn inelegant.  We could say that a name ending in --- > indicates a forthcoming TAP st

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Michael G Schwern
Mark Fowler wrote: > > On 16 Mar 2007, at 02:52, Michael G Schwern wrote: > >> That should be this: >> >> 1..5 >> ok 1 >> ok 2 #--- >> - >> fnurk: skib >> ponk: gleeb >> - >> bar: krup >> foo: plink >> ... >> ok 3 > > Isn't that putting schematically important info in the comment (the --

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Michael G Schwern
Ovid wrote: > That's still pretty ad-hoc and breaks as soon as we encounter: > > is $delimiter, $dashes, > '... we should have the correct delimiter: ---'; The diagnostic block ends at the next test, no matter what, so you just get an empty diagnostic block. ok 23 ... we should have

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Mark Fowler
On 16 Mar 2007, at 02:52, Michael G Schwern wrote: That should be this: 1..5 ok 1 ok 2 #--- - fnurk: skib ponk: gleeb - bar: krup foo: plink ... ok 3 Isn't that putting schematically important info in the comment (the -- of the #). I know we already do it for TODO, but I thought t

Re: Eliminating STDERR without any disruption.

2007-03-16 Thread Adrian Howard
On 16 Mar 2007, at 07:53, Michael G Schwern wrote: [snip] I don't know if we need all 8 levels used in syslog. I'm not sure where the distinction comes between "Emergency", "Alert", "Critical" and "Error" when it comes to testing. But its a good start. Some undefined levels we can defin

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Michael G Schwern
Ovid wrote: >>> How do you mark that as a TODO test? >>> >>> not ok 2 # TODO don't know what $foo is #--- >>> >>> Anyone see a problem with that? >> not ok 2 #--- >> line: 17 >> code: ok $foo; >> directive: TODO >> reason: don't know what $foo is >> ... >> >> Although that l

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Ovid
--- Michael G Schwern <[EMAIL PROTECTED]> wrote: > I chose #--- because 1) its backwards compatible as long as you > ignore unknown > directives and 2) it allows TAP to stream. Otherwise its pretty damn > inelegant. We could say that a name ending in --- indicates a > forthcoming TAP > stream...

ANN: Test-Run-Plugin-AlternateInterpreters

2007-03-16 Thread Shlomi Fish
Test-Run-Plugin-AlternateInterpreters version 0.0101 was uploaded to the CPAN today: http://search.cpan.org/dist/Test-Run-Plugin-AlternateInterpreters/ This is a plugin for Test-Run and an accompanying Test-Run-CmdLine plugin that enable one to specify alternate interpreters for running the tes

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Ovid
--- Michael G Schwern <[EMAIL PROTECTED]> wrote: > Ovid wrote: > > So we have this: > > > > not ok 2 #--- > > - > > line: 17 > > test: ok $foo; > > ... > > Why do you keep putting everything in an array? Doesn't have to be an array. That was a "Hungry Man TAP Dinner Serving Sugge

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Michael G Schwern
Ovid wrote: > So we have this: > > not ok 2 #--- > - > line: 17 > test: ok $foo; > ... Why do you keep putting everything in an array? > How do you mark that as a TODO test? > > not ok 2 # TODO don't know what $foo is #--- > > Anyone see a problem with that? not ok 2 #---

Re: [tapx-dev] TAP::Parser, structured diagnostics

2007-03-16 Thread Ovid
--- Michael G Schwern <[EMAIL PROTECTED]> wrote: > That should be this: > > 1..5 > ok 1 > ok 2 #--- > - > fnurk: skib > ponk: gleeb > - > bar: krup > foo: plink > ... > ok 3 So we have this: not ok 2 #--- - line: 17 test: ok $foo; ... How do you mark that as a TODO test?