Re: build_requires, the xt and build_prereq_matches_use

Hi! On Thu, Feb 19, 2009 at 10:04:58AM -0500, David Golden wrote: > That's absurd. The Kwalitee analyzer shouldn't look in xt. Period. I agree partly (it can look, but should not add any dependencies), but I'm very unlikely to find some time to fix this in the next weeks (http://use.perl.or

Re: prove is lying to me

Andy Lester wrote: > On Feb 19, 2009, at 2:24 PM, Michael G Schwern wrote: > >> Andy Lester wrote: >>> Second point: Should tests 3 and 6 pass? Being unnumbered? >> >> Yes, that's by design (or at least happy historical accident). > > But "ok 0" should certainly fail, right? Yeah, that's just a

Re: Make TAP::Harness Output Failures Diagnostics?

- Original Message > From: Michael G Schwern > > The current behaviour also means that prove's --merge switch hides > > diagnostics: > > Remember Ovid and I going at it like Godzilla and Rodan over merging STDOUT > and STDERR when TH3 was being put together? Yup. This has bitten me t

Re: Make TAP::Harness Output Failures Diagnostics?

On Feb 19, 2009, at 1:16 PM, Michael G Schwern wrote: What prove is referring to in -1 is suppressing its own messages about test failure, not TAP comments. Ah, okay. What you want is a .5 (didn't we figure out in BASIC that you don't closely space your numeric sequences?) which is "show

Re: Have Harness Run App With No Files?

On Feb 19, 2009, at 1:29 PM, David E. Wheeler wrote: TAP::Harness->new({ verbosity => $opts->{verbose} || $ENV{TEST_VERBOSE}, timer => $opts->{timer}, color => $opts->{color}, exec => ['psql', '-c'], })->runtests('SELECT * FROM tap.runtest()'); However, TAP::Parser only wan

Re: build_requires, the xt and build_prereq_matches_use

On Thu, Feb 19, 2009 at 4:49 PM, Marc Lucksch wrote: > Sorry, that previous post sounded way to agressive, this is probably because > I'm not english speaker (Worst in my class and proud of it) and my Don't worry, I was not offended. > Yes, but I kind of want to deliver the best module I can pro

Re: prove is lying to me

On Feb 19, 2009, at 2:24 PM, Michael G Schwern wrote: Andy Lester wrote: Second point: Should tests 3 and 6 pass? Being unnumbered? Yes, that's by design (or at least happy historical accident). But "ok 0" should certainly fail, right? xoa -- Andy Lester => a...@petdance.com => www.pet

Re: build_requires, the xt and build_prereq_matches_use

Sorry, that previous post sounded way to agressive, this is probably because I'm not english speaker (Worst in my class and proud of it) and my "diplomatic english" suffers from this shortcoming. This is aggravated by my try to cut back on smilies lately. Again sorry for that. I just tried to e

Re: Test skip()'ing weirdness

Michael G Schwern wrote: Skipped tests can sometimes be turned on by the user. For example... $ prove -l t/is_deeply_with_threads.t t/is_deeply_with_threadsskipped: many perls have broken threads. Enable with AUTHOR_TESTING. this is exactly what i do in these skips, check for an envvar

Re: done_testing()

David E. Wheeler wrote: > On Feb 19, 2009, at 12:12 PM, Michael G Schwern wrote: > >>> I’m not talking about pass/fail, I’m talking about finding out >>> about subplans, from the consumer end. >> >> As TAP has no formal means to express that, and I'm not waiting for a TAP >> extension, any TAP rea

Re: Have Harness Run App With No Files?

On Jan 26, 2009, at 10:54 PM, David E. Wheeler wrote: TAP::Harness->new({ verbosity => $opts->{verbose} || $ENV{TEST_VERBOSE}, timer => $opts->{timer}, color => $opts->{color}, exec => ['psql', '-c' 'SELECT * FROM tap.runtest()'], })->runtests(); The issue with this is

Re: build_requires, the xt and build_prereq_matches_use

It seems like I started too many discussions at once (again), like I always do. Sorry for that. Michael G Schwern schrieb: [snip] but I'm also quite happy with encouraging the idea that > testing *is* part of the build process. Really no argument there. Though I agree the lack of build_re

Re: Make TAP::Harness Output Failures Diagnostics?

David E. Wheeler wrote: > Hrm. Reading the documentation: > > =item * C > > Set the verbosity level: > > 1 verbosePrint individual test results to STDOUT. > 0 normal > -1 quiet Suppress some test output (mostly failures > while tests a

Re: Make TAP::Harness Output Failures Diagnostics?

On Feb 19, 2009, at 10:07 AM, David E. Wheeler wrote: As a way of dealing with the immediate need, I'd love to see a way to just tell TAP::Harness to emit all diagnostics, whether failure diagnostics or freeform output, as you say. It should be off by default, as you pointed out in the firs

Re: build_requires, the xt and build_prereq_matches_use

Marc Lucksch wrote: > If you are pedantic about this, you could even argue that testing itself is > _not_ > a requirement for the whole build process. (Just don't run make test) It compiles, ship it! I've argued for test_requires and test_recommends in the past, but I'm also quite happy with enc

Re: done_testing()

On Feb 19, 2009, at 12:12 PM, Michael G Schwern wrote: I’m not talking about pass/fail, I’m talking about finding out about subplans, from the consumer end. As TAP has no formal means to express that, and I'm not waiting for a TAP extension, any TAP reader will need extra logic to figure tha

Re: prove is lying to me

Andy Lester wrote: > Second point: Should tests 3 and 6 pass? Being unnumbered? Yes, that's by design (or at least happy historical accident). It allows you to run a bunch of tests where you can't guarantee the order or coordinate the counter. For example, testing anything that forks (threads c

Re: done_testing()

Aristotle Pagaltzis wrote: > * Michael G Schwern [2009-02-19 08:40]: >> it doesn't require any extra TAP reader logic to determine pass >> or fail. > > I’m not talking about pass/fail, I’m talking about finding out > about subplans, from the consumer end. As TAP has no formal means to express th

Re: Test skip()'ing weirdness

chromatic wrote: > On Thursday 19 February 2009 04:05:37 Ovid wrote: > >> Properly, if we want to report SKIPs for each test (presumably with >> numbers), then we want to report failing TODOs with each test for >> consistency's sake. > > I don't like that. You can already get this behavior with

Re: Make TAP::Harness Output Failures Diagnostics?

Andy Armstrong wrote: > On 18 Feb 2009, at 22:44, Michael G Schwern wrote: >> The thing which most takes advantage of this is TODO tests. They send >> their >> failure diagnostics to STDOUT so the user is not spammed with passing >> test >> information. > > I didn't know that... > > The current

Re: configure_requires and new META.yml keys

On Thu, Feb 19, 2009 at 2:05 PM, Eric Wilhelm wrote: > We do not currently have a plan for how to handle this. It would likely > involve some mechanism of requiring compliance to a minimum version of > the META spec. An old loader cannot know that it is too old. When we > do define some sort of

Re: prove is lying to me

On Thu, 2009-02-19 at 12:44 -0600, Andy Lester wrote: > The prove -v is lying to me about what the TAP was. That violates > what was my intent in adding -v originally. I don't want to have to > run the program manually to get the raw TAP. Already fixed in SVN. > [snip]The test number is 0,

Re: configure_requires and new META.yml keys

# from David Golden # on Thursday 19 February 2009 05:10: >There was some consideration >last year of breaking out build/test/install requires further but >there was no consensus for it.  One of the issues is that it >introduces yet another round of CPAN/CPANPLUS upgrades, so in your >example, you

Re: Test skip()'ing weirdness

On Thursday 19 February 2009 04:05:37 Ovid wrote: > Properly, if we want to report SKIPs for each test (presumably with > numbers), then we want to report failing TODOs with each test for > consistency's sake. I don't like that. You can already get this behavior with the --directives flag from

prove is lying to me

First point: I think it's Very Bad that prove is fudging my TAP. I know that Schwern brought this up yesterday, but I have to add my voice to the chorus. uniqua:~/rakudo : perl foo.pl 1..11 ok 1 ok 2 ok ok 4 ok 5 ok ok 7 ok 8 ok 9 ok 10 ok 11 uniqua:~/rakudo : prove -v foo.pl [12:39:24] foo

Re: Make TAP::Harness Output Failures Diagnostics?

On Feb 19, 2009, at 3:55 AM, Andy Armstrong wrote: One proposed solution is the TAP logging syntax, but it wasn't discussed at the TAP summit in Oslo last year. It's status is in limbo. http://testanything.org/wiki/index.php/TAP_logging_syntax OK - let's move on that then. That could take a

Re: build_requires, the xt and build_prereq_matches_use

On Thu, Feb 19, 2009 at 9:35 AM, Marc Lucksch wrote: > And what about the optional Test::NoWarnings? > If it isn't in build_requires, I get bad kwalitee, if its there, the module > will be installed without being really needed. If I hide it with trickery > from being detected, I will fail the *use

Re: build_requires, the xt and build_prereq_matches_use

David Golden schrieb: On Thu, Feb 19, 2009 at 7:43 AM, Marc Lucksch wrote: So there are two ways to solve this: Either remove them from the Kwalitee indicator (which would be bad). This is the right answer. Things required for xt should not be in build_requires as they do not impact the bui

Re: build_requires, the xt and build_prereq_matches_use

On Thu, Feb 19, 2009 at 7:43 AM, Marc Lucksch wrote: > So there are two ways to solve this: > > Either remove them from the Kwalitee indicator (which would be bad). This is the right answer. Things required for xt should not be in build_requires as they do not impact the build/test/install cycle

build_requires, the xt and build_prereq_matches_use

I have a small problem with the semantics here, I have made some modules, all of which use Test::Pod, Test::Pod::Coverate, Test::YAML::Meta and Test::NoWarnings. For the experimental Kwalitee indicator *build_prereq_matches_use* to be true, I had to add them to the build_requires part of the Me

Re: done_testing()

* Michael G Schwern [2009-02-19 08:40]: > it doesn't require any extra TAP reader logic to determine pass > or fail. I’m not talking about pass/fail, I’m talking about finding out about subplans, from the consumer end. Regards, -- Aristotle Pagaltzis //

Re: TAP::Data or TAPx::Data?

Aristotle Pagaltzis writes: > * nadim khemir [2009-02-11 18:35]: >> TAP::DOM maybe. > > ++, in case it still matters. (Catching up to old mail.) Done. :-) Steffen -- Steffen Schwigon

Re: Test skip()'ing weirdness

- Original Message > From: Ovid > I've also verified this problem on 3.01 (since it advertises better skip > parsing), so it looks like the series 3 TH has been doing this all the while. > > I'll try to fix this if I get some tuits. In thinking about this more, it may not be as si

Re: Test skip()'ing weirdness

- Original Message > From: Pedro Figueiredo Reformatting: Test::Harness 2.56: 1/1 skipped: meh All tests successful, 1 subtest skipped. Test::Harness 2.64: 1/1 skipped: various reasons All tests successful, 1 subtest skipped. Test::Harness 3.14: All tests

Re: Make TAP::Harness Output Failures Diagnostics?

On 18 Feb 2009, at 22:44, Michael G Schwern wrote: The thing which most takes advantage of this is TODO tests. They send their failure diagnostics to STDOUT so the user is not spammed with passing test information. I didn't know that... The current behaviour also means that prove's --merg

Re: Make TAP::Harness Output Failures Diagnostics?

On 18 Feb 2009, at 22:11, David E. Wheeler wrote: Of course if I use -v, it passes `verbosity => 1` to TAP::Harness, but I'd love to be able to see the failure diagnostics without having to see all of the passing test TAP output, too. Is there some way to get TAP::Harness to pass through dia