On Mar 15, 2007, at 12:38 AM, chromatic wrote:
I think diagnostics have to go into the TAP stream at some point.
I think expecting a harness to merge STDOUT and STDERR when it runs
a test
file is prone to errors.
I agree with both of these, and I do think it'll cause problems, but
if we
On Wednesday 14 March 2007 18:27, A. Pagaltzis wrote:
> * chromatic <[EMAIL PROTECTED]> [2007-03-14 18:50]:
> > I think my point eluded everyone. Let me be very clear.
> Not me, but I’m not surprised that so many people missed it.
> After all, you did try to make it in as condescendingly
> conv
On Wednesday 14 March 2007 17:02, Michael G Schwern wrote:
> I forgot, I'm on a mailing list. Thou shalt not let any inaccuracy, no
> matter how minor or totally inconsequential to the point being made, go
> uncorrected.
I generally consider it good debating technique to characterize the opposin
* chromatic <[EMAIL PROTECTED]> [2007-03-14 18:50]:
> I think my point eluded everyone. Let me be very clear.
Not me, but I’m not surprised that so many people missed it.
After all, you did try to make it in as condescendingly
convoluted a way as possible. I don’t think your sarcasm was
called fo
On Wednesday 14 March 2007 15:05, Michael G Schwern wrote:
> chromatic wrote:
> > I think my point eluded everyone. Let me be very clear.
> >
> > MAKE diag() PRINT TO STDOUT NOT STDERR.
>
> Deja vu all over again. We had this discussion months ago when TAP::Parser
> tried EXACTLY this, at the t
Nicholas Clark wrote:
> Does anything spring to mind as to the cause?
Might be the changes to Test::Builder->is_fh.
--- local/Test-Simple/lib/Test/Builder.pm (revision 27379)
+++ local/Test-Simple/lib/Test/Builder.pm (revision 27380)
@@ -1321,11 +1321,10 @@
return 1 if ref \$may
Let me make something clear, I don't have a solution to this problem. I'm
just finally getting a grip on what the problem actually is. The last week
has shaken lose use cases and conditions I hadn't thought about before and the
TAP diagnostic syntax proposal does not cover.
What I do know is tha
chromatic wrote:
> On Wednesday 14 March 2007 09:41, Geoffrey Young wrote:
>
>>> There ought to be a way to capture diagnostic information in the TAP
>>> stream because it's useful for diagnosing problems.
>
>> so, to chromatic's point, I can't help but feel like solving the quoted
>> issue would
Erk. Fails big time on 5.005_03
(Sorry, only just had reason to want to build 5.005_03)
On Tue, Mar 13, 2007 at 05:34:48PM -0700, Michael G Schwern wrote:
> 0.68 Tue Mar 13 17:27:26 PDT 2007
> Bug fixes
> * If your code has a $SIG{__DIE__} handler in some cases functions like
> use
On 14 Mar 2007, at 19:24, Yitzchak Scott-Thoennes wrote:
A way to request verbose output without the merging.
I'm wondering whether merging should be a separate option. I feel
slightly uneasy about having the harness behave so differently as a
result of setting the verbose flag. Normally -v
> On 14 Mar 2007, at 07:29, chromatic wrote:
>> The problem is that there's no way to tell that that information
>> sent to
>> Test::Builder->diag() is diagnostic information for the tests
>> because once it
>> goes out on STDERR, it could be anything.
>
> So we seem to have two reasonably sensible
David Cantrell wrote:
> Michael G Schwern wrote:
>
>> First thing is breaks, and probably most important: No warnings.
>
> Any test suite that blithely ignores warnings is BROKEN.
>
> There are two types of warning. First, those which you deliberately
> spit out, like "use of foo() is deprecated,
On Wednesday 14 March 2007 09:41, Geoffrey Young wrote:
> > There ought to be a way to capture diagnostic information in the TAP
> > stream because it's useful for diagnosing problems.
> so, to chromatic's point, I can't help but feel like solving the quoted
> issue would go a long way toward red
Ricardo SIGNES wrote:
> * Michael G Schwern <[EMAIL PROTECTED]> [2007-03-09T18:17:57]
>> *) TAP diagnostic format
>> http://perl-qa.yi.org/index.php/TAP_diagnostic_syntax
>>
>> There is no way to output diagnostics in TAP. The stuff Test::More spits
>> out to STDERR are unparsable comments indent
Ovid wrote:
David Cantrell <[EMAIL PROTECTED]> wrote:
Fergal Daly wrote:
use Test::NoWarnings;
I like to use Fewer::Annoying::Dependencies.
Same here, but Test::NoWarnings is hardly annoying.
Sure, on its own. But then there's lots of other modules which, on
their own, aren't annoying. B
> There ought to be a way to capture diagnostic information in the TAP stream
> because it's useful for diagnosing problems.
I feel like I'm talking to myself when I say this (since I've said this
before) but I'll say it again just, well, because :)
the implicit idea that STDERR generally goes
On 14 Mar 2007, at 16:04, Ricardo SIGNES wrote:
* Michael G Schwern <[EMAIL PROTECTED]> [2007-03-09T18:17:57]
*) TAP diagnostic format
http://perl-qa.yi.org/index.php/TAP_diagnostic_syntax
There is no way to output diagnostics in TAP. The stuff
Test::More spits
out to STDERR are unparsabl
On 14 Mar 2007, at 15:45, Michael G Schwern wrote:
But we can go ahead with TH 3 now using Ovid's plan without
worrying about that.
OK. Unless anyone jumps in first I'll implement it when I get some
time from Friday onwards.
--
Andy Armstrong, hexten.net
* Michael G Schwern <[EMAIL PROTECTED]> [2007-03-09T18:17:57]
> *) TAP diagnostic format
> http://perl-qa.yi.org/index.php/TAP_diagnostic_syntax
>
> There is no way to output diagnostics in TAP. The stuff Test::More spits
> out to STDERR are unparsable comments indented for humans. Its not TAP.
Andy Armstrong wrote:
> On 14 Mar 2007, at 07:29, chromatic wrote:
>> The problem is that there's no way to tell that that information
>> sent to
>> Test::Builder->diag() is diagnostic information for the tests
>> because once it
>> goes out on STDERR, it could be anything.
>
> So we seem to h
Ovid wrote:
> The latter is virtually impossible to read but it's a fairly common
> complaint. But I think that provides us with our answer. The streams
> only need to be in synch when runtests (or prove) is in VERBOSE mode.
> There is no information lost and everyone's happy, yes? Otherwise, l
Rafael Garcia-Suarez wrote:
> On 14/03/07, Steve Peters <[EMAIL PROTECTED]> wrote:
>> I've just updated bleadperl to the Test-Simple-0.68 and ran into
>> problems.
>> The problem is that there is a hard-coded path that has been added to
>> t/fail-more.t. Fortunately, it doesn't seem to cause probl
On 14/03/07, Steve Peters <[EMAIL PROTECTED]> wrote:
I've just updated bleadperl to the Test-Simple-0.68 and ran into problems.
The problem is that there is a hard-coded path that has been added to
t/fail-more.t. Fortunately, it doesn't seem to cause problems on Win32,
but VMS may be effected.
On Tue, Mar 13, 2007 at 05:34:48PM -0700, Michael G Schwern wrote:
> 0.68 Tue Mar 13 17:27:26 PDT 2007
> Bug fixes
> * If your code has a $SIG{__DIE__} handler in some cases functions like
> use_ok(), require_ok(), can_ok() and isa_ok() could trigger that
> handler. [rt.cpan.or
On 14 Mar 2007, at 11:54, Ovid wrote:
Rather than repeat the entire post here, there is a conceptual problem
with setup methods in Test::Class. I'm just not sure if the
conceptual
problem is mine or Test::Class's :)
http://www.perlmonks.org/?node_id=604787
Rather than repeat my entire re
Rather than repeat the entire post here, there is a conceptual problem
with setup methods in Test::Class. I'm just not sure if the conceptual
problem is mine or Test::Class's :)
http://www.perlmonks.org/?node_id=604787
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Per
On 14/03/07, David Cantrell <[EMAIL PROTECTED]> wrote:
Fergal Daly wrote:
> use Test::NoWarnings;
I like to use Fewer::Annoying::Dependencies.
I like fewer bugs. I guess we'll just have to agree to differ,
F
--- David Cantrell <[EMAIL PROTECTED]> wrote:
> Fergal Daly wrote:
>
> > use Test::NoWarnings;
>
> I like to use Fewer::Annoying::Dependencies.
Same here, but Test::NoWarnings is hardly annoying. More than once
that module has revealed bugs that we've managed to miss in
development. In fact,
Fergal Daly wrote:
use Test::NoWarnings;
I like to use Fewer::Annoying::Dependencies.
--
David Cantrell
On 14 Mar 2007, at 07:29, chromatic wrote:
The problem is that there's no way to tell that that information
sent to
Test::Builder->diag() is diagnostic information for the tests
because once it
goes out on STDERR, it could be anything.
So we seem to have two reasonably sensible options on t
On 14/03/07, David Cantrell <[EMAIL PROTECTED]> wrote:
Michael G Schwern wrote:
> First thing is breaks, and probably most important: No warnings.
Any test suite that blithely ignores warnings is BROKEN.
There are two types of warning. First, those which you deliberately
spit out, like "use
Michael G Schwern wrote:
First thing is breaks, and probably most important: No warnings.
Any test suite that blithely ignores warnings is BROKEN.
There are two types of warning. First, those which you deliberately
spit out, like "use of foo() is deprecated, please use bar() instead".
You
# from chromatic
# on Wednesday 14 March 2007 01:47 am:
>They don't have to interfere with the TAP stream unless they call
>Test::Builder->diag(),
Yep. We need to flow everything from stderr through asap. However, I
don't think we should be trying to do *anything* with it (except maybe
archi
So I stepped back for a bit and thought about the the problem people
wanted solved. They don't want this:
ok 1 - test 1
not ok 2 - test 2
# Failed test 'test 2'
# at t/foo.t line 12.
# got: '3'
# expected: '4'
not ok 3 - whee!
# Failed test 'whee!'
# at t/fo
chromatic wrote:
> On Wednesday 14 March 2007 01:37, Smylers wrote:
>
>> chromatic writes:
>
>> > There ought to be a way to capture diagnostic information in the TAP
>> > stream because it's useful for diagnosing problems.
>
>> Does that help with the case where it's an 'ordinary' Perl-generated
>
On Wednesday 14 March 2007 01:37, Smylers wrote:
> chromatic writes:
> > There ought to be a way to capture diagnostic information in the TAP
> > stream because it's useful for diagnosing problems.
> Does that help with the case where it's an 'ordinary' Perl-generated
> warning ("Use of uninitia
chromatic writes:
> There ought to be a way to capture diagnostic information in the TAP
> stream because it's useful for diagnosing problems.
Does that help with the case where it's an 'ordinary' Perl-generated
warning ("Use of uninitialized value" and the like), which runtests is
also swallowin
Michael G Schwern writes:
> ... TAP::Parser guarantees that STDOUT and STDERR will be in sync,
> something Test::Harness does not guarantee.
>
> First thing is breaks, and probably most important: No warnings.
That caught me by surprise this week. runtests was showing a failure I
didn't unders
38 matches
Mail list logo
