A few people have asked how I do my CPAN scans. I keep a minicpan handy and
have a little script called grep_cpan which reads the index file, unpacks
each distribution, does a find | grep and then cleans up. It allows you to
search for a given pattern in a given set of files.
# search
Steffen Mueller wrote:
{
name='no_test_pl',
error=q{This distribution contains a file called 'test.pl' in
its main distribution directory. This indicates that it uses the old
style of creating test suites. Nowadays, tests belong into one or more
*.t files in the t/
Shlomi Fish wrote:
Hi all!
See http://xrl.us/sw5o for a recipe for integrating make runtest and make
distruntest targets into a Makefile.PL-generated Makefile that makes use of
Test::Manifest.
I needed that when working on XML::RSS, so I wrote it.
What has me scratching my head here
demerphq wrote:
On 11/1/06, Michael G Schwern [EMAIL PROTECTED] wrote:
This distribution uses 'test.pl' for its tests. The output of
'test.pl' is not parsed. When
make test is run by automated installers (for example, the CPAN
shell) your tests will
always appear to have passed no matter
Chris Dolan wrote:
It's not an EU::MM bug -- it's a new M::B feature.
What should you do? You're not going to like this answer:
Don't use recursive test directories. :-)
Or send in a patch.
http://rt.cpan.org/Ticket/Display.html?id=22767
Christopher H. Laco wrote:
Files that declare: --- #YAML:1.0 should pass the 1.0 spec
Files that declare: --- #YAML:1.1 should pass the 1.2 spec
err...
Files that declare: --- #YAML:1.2 should pass the 1.2 spec
I know what I meant. :-)
I thought that was the version of YAML they're
Thomas Klausner wrote:
Hmm, I tried to do that (I usually use Module::Build):
~$ module-starter --module=FooTest --author='foo' --email='[EMAIL PROTECTED]'
Created starter directories and files
~$ cd FooTest/
~/FooTest$ perl Makefile.PL
Checking if your kit is complete...
Warning: the
A. Pagaltzis wrote:
* Thomas Klausner [EMAIL PROTECTED] [2006-11-03 15:25]:
metayml_conforms_spec currently very much busts the CPANTS
game. I'm checking if the files comply to META.yml spec 1.2.
Most don't, because they seem to use 1.0
Should I switch to 1.0-checking?
Is there something
Steffen Mueller wrote:
Hi perl-qa,
there's been a lot of discussion about CPANTS metrics in the recent past.
How about a mandatory or optional metric for modules registered with the
modules list? Why is that a sign of (q|kw)alit(y|ee)? Because it means
the author has the blessing of the
http://schwern.org/~schwern/src/Test-Simple-0.64_03.tar.gz
or a CPAN near you
This is a release candidate for 0.65. If your module relies on Test::More or
Test::Builder please try it out, I don't want to hear any moaning after the
release.
0.64_03 Sun Nov 5 13:09:55 EST 2006
- Tests
Andy Lester wrote:
On Nov 5, 2006, at 12:26 PM, Steffen Mueller wrote:
I am not talking about 01...
But of course, we can agree to disagree on this even for 03...
Either way, doesn't matter. It's an arbitrary distinction. Also, many
module authors don't even bother submitting their
David Golden wrote:
I have to second this. There really shouldn't be separate conforms
to 1.0 and conforms to 1.2 metrics and so on. What happens as the
spec evolves? Unless the spec is broken, encouraging specific latest
spec compliant is just churn and Kwalitee breaks if there's ever a
http://pobox.com/~schwern/src/Test-Simple-0.65.tar.gz
or
a CPAN near you!
This is just 0.64_03 in a new wrapper.
0.65 Fri Nov 10 10:26:51 CST 2006
0.64_03 Sun Nov 5 13:09:55 EST 2006
- Tests will no longer warn when run against an alpha version of
Test::Harness [rt.cpan.org #20501]
A. Pagaltzis wrote:
* Philippe Bruhat (BooK) [EMAIL PROTECTED] [2006-11-10 19:50]:
The French often type LICENCE for LICENSE, so it might be
good to update the checking code to look for that too. I've got
one of my distributions with that typo.
Uhm, that’s proper English spelling. “License”
Gabor Szabo wrote:
Recently I was asked how to determine which modules are available
for an old version of perl (5.004 or similar).
I asked about this on PerlMonks
http://www.perlmonks.org/?node_id=586506
That resulted in this page:
http://www.szabgab.com/cpantested/
Based on the
Shlomi Fish wrote:
Hi all!
The wiki has been spammed:
http://qa.yi.org/index.php?title=TAP%3A%3AHarnessdiff=1744oldid=1611
And there isn't any contact information on the wiki anywhere. You can find
the
porocedures to battle it here:
I've turned on the SpamBlacklist extension (it was installed but I forgot to
turn it on) and hooked it up to the MediaWiki blocklist. That should take care
of things.
Chris Dolan wrote:
That can't be right. Negation does not contribute to complexity.
Instead, I believe it is the for loop and the exit points that are
increasing your count. Consider rewriting the for as ifs and gotos:
sub complexity_of_six {
my $bar = shift;
my $total
Paul Johnson wrote:
1. Find some nice way expressing what is uncoverable. For subroutines
this is easy. For statements it is not hard. For branches it is
tricky and for conditions I'm somewhat stumped. The current
method I use is based on implementation details.
What's
Ovid wrote:
However, if you use the '-s' switch to shuffle your tests and bailout
is not first, then some tests will run until the BAIL_OUT is hit. This
seems to violate the principle that tests should be able to run in any
order without dependencies.
It doesn't violate the principle since
Ovid wrote:
Some of the limitations of TAPx::Parser are due to how Test::Builder
works. One thing which isn't making it into 'runtests' is the -Q
switch. I have a -q which doesn't print test failures while tests are
running, but as you can see, one of my 'stress tests' caused a problem:
Ovid wrote:
--- Michael G Schwern [EMAIL PROTECTED] wrote:
TAPx-Parser $ /usr/bin/perl -Ilib bin/runtests -qm tbad/
tbad/060-aggregator..ok
tbad/badtestsFAILED tests 1, 2, 4, 5, 7, 8, 10, 11, 13,
14,
16, 17, 19, 20, 22, 23, 25, 26, 28, 29, 31, 32, 34, 35, 37, 38, 40,
41
Adam Kennedy wrote:
Lately I find myself cheating a bit on the test naming as well, by just
calling the testing package t::lib::Test.
That saves me one entire line :)
Relying on . being in @INC makes my feet itch.
Adam Kennedy wrote:
Personally, I've always wanted a per-file bail_out as well, that can
just abort the current test script, rather than the entire testing process.
Schwern? :)
die.
Randal L. Schwartz wrote:
Michael == Michael G Schwern [EMAIL PROTECTED] writes:
Michael Adam Kennedy wrote:
Lately I find myself cheating a bit on the test naming as well, by just
calling the testing package t::lib::Test.
That saves me one entire line :)
Michael Relying on . being
chromatic wrote:
(I know; it's not exactly what you were asking. I just wanted to get that in
a public mailing list so I could call that the Star Trek: Generations
fallacy. You steal a spaceship, which flies through space, to fly through
space to a planet, flying through space, where a
[EMAIL PROTECTED] wrote:
1. To test the code, you need to change it.
2. Before changing the code, you should test it.
How do we resolve these two opposites ? We change as little as
possible.
*snip*
A lot of my more recent thoughts about testing and development have
come from a wonderful
Ovid wrote:
http://search.cpan.org/dist/Test-Harness/lib/Test/Harness/TAP.pod implies
that if I want to skip all tests, I need something like this format:
1..0 # SKIP why not?
I've also noticed that all of the Test::Harness tests which exercise this
behavior use '1..0', even though this
James E Keenan wrote:
What with all the activity on this list in the last week (TAPx::Parser
about to morph into Test::Harness), it's all been more than I can keep
up with.
I would like to suggest that one or more or the hackerati who are
working on all these revisions to our core testing
Andy Armstrong wrote:
On 27 Jan 2007, at 19:10, Andy Armstrong wrote:
I've just committed a patch against ExtUtils::MakeMaker 6.31 that
makes test_harness use TAPx::Harness instead of Test::Harness if the
env variable PERL_EUMM_USE_TAPX is set to a true value and
TAPx::Harness is installed.
Andy Armstrong wrote:
I've just committed a patch against ExtUtils::MakeMaker 6.31 that makes
test_harness use TAPx::Harness instead of Test::Harness if the env
variable PERL_EUMM_USE_TAPX is set to a true value and TAPx::Harness is
installed.
EUMM Patch:
Andy Armstrong wrote:
Sure - I'm open to suggestions. Do you mean something like this?:
$ export PERL_EUMM_HARNESS_CLASS=TAPx::Harness::Compatible
$ make test
That's one way, though I'd rather it be a Makefile.PL argument. [1]
The way I was thinking was to make it easier for users to write
Adam Kennedy wrote:
I for one would rather it wasn't.
Remembering that NOBODY ever passes Makefile.PL params manually, you
need every build system capable of supporting those params, and ever
CPAN client to be capable of passing them.
An environment variable is a direct line from the
Nadim Khemir wrote:
The bad guys:
# Check that something died
dies_ok { $foo-method1 } 'expecting to die';
Am I the only one who got this to pass, to find out later that what cause the
error had nothing to do with the message I displayed. Checking that something
dies is _not_ good
Christopher H. Laco wrote:
I offer this word of warning. If you have too many tests, or many
longly-named tests, win32 will in all likelyhood barf with a command
line too long error.
I had this problem in Handel (too many tests..it's a good problem to
have really), and even after updating
Maybe somebody would like to, ya know, provide a patch for an open ticket or
something?
http://rt.cpan.org/Public/Bug/Display.html?id=22767
cmp_ok() is changing, with regard to overloaded objects, to be as close to the
behavior of the actual comparison as I can get it. is() and is_deeply() will
remain the same as they have a fuzzier idea of equality. I'm still working on
the implementation.
As of 0.60_01 cmp_ok() has
[EMAIL PROTECTED] wrote:
On Tue, Feb 13, 2007 at 09:20:29AM -0800, chromatic wrote:
On Tuesday 13 February 2007 08:24, Ovid wrote:
Really? :)
java.lang.NullPointerException
Oh please, everyone knows Java doesn't have pointers!
Of course it does. They may not be accessible to the
David Cantrell wrote:
On Thu, Feb 15, 2007 at 11:48:57AM +, Adrian Howard wrote:
Probably being stupid... but if you can point me towards the
difference between
http://www.nntp.perl.org/group/perl.cpan.testers/2007/02/msg415380.html
and
Ovid wrote:
In the Test::More docs, for diagnostics, it reads:
NOTE The exact formatting of the diagnostic output is still
changing, but it is guaranteed that whatever you throw at it
it won't interfere with the test.
Given that this issue has bitten people more than once, can I
Nicholas Clark wrote:
On Fri, Feb 16, 2007 at 09:17:00AM +1100, Adam Kennedy wrote:
This comes from the OMGYOUBROKECPAN! diagnostics formatting change in
0.60_01.
Can we use that as the official name for this sort of error?
Because the other alternative would be Doing a Schwern and I I'm
Ovid wrote:
The idea is, in this scope, we'd convert the 'get_ok' and
'content_like' methods to *not* be tests for the current scope. This
allows us to use our tests as test fixtures rather than duplicate this
logic.
I think this is a horribly clumsy idea, but the above is a simplified
chromatic wrote:
On Saturday 24 February 2007 06:47, Eric Hacker wrote:
Is it OK to have the return value from a test be something more than
just true when a test passes? Thus the test might be used as a right
value in the test script.
Seems like, in general, the semi-predicate problem.
Joshua ben Jore wrote:
On 2/25/07, Yuval Kogman [EMAIL PROTECTED] wrote:
Is there a function that is to this as overload::StrVal is to
stringification?
Wouldn't that just be CORE::ref $obj ?
Mark Fowler wrote:
On 24 Feb 2007, at 22:58, Michael G Schwern wrote:
Just make sure whatever you return evaluates according to the test
pass/fail
and not its value and you should be fine. You can return a little
wrapper
object like...
Or you could just return a reference to an array
Yuval Kogman wrote:
Likewise with ref in boolean context, I almost never want the object
to be able to lie to me.
But if it has to work hard to lie, then does it matter?
Yeah, I'm with Yuval here. There seem to be a cold war going on here wrt
identifying an object.
In the beginning we used
Eric Wilhelm wrote:
# from Michael G Schwern
# on Monday 26 February 2007 01:50 pm:
And then someone defined a $SIG{__DIE__} so now its C{ local
$SIG{__DIE__}; eval { $obj-isa($class) } }
No. If that $SIG{__DIE__} doesn't check $^S, then it's just
delete($SIG{__DIE__}) and you're back
Eric Wilhelm wrote:
Also this:
eval { delete $SIG{__DIE__}; $obj-isa($class) }
is no shorter than this:
eval { local $SIG{__DIE__}; $obj-isa($class) }
To be clear (since I must not be funny enough), the delete() bit was a
joke. This is much shorter than both:
eval
chromatic wrote:
On Monday 26 February 2007 21:20, Michael G Schwern wrote:
Case in point... my tests started suddenly warning about UNIVERSAL::isa
called as a function in Class::DBI. After spending a bunch of time trying
to figure out what the hell was going on and if Redhat introduced some
Eric Wilhelm wrote:
There's nothing vigilante about writing code that assumes other code
will behave properly. If I were going to put something on CPAN that
messed with __DIE__ hooks, it would only be an audit module.
Oh good.
I will, however,
refuse to say local $SIG{__DIE__} inside
chromatic wrote:
On Tuesday 27 February 2007 13:42, Michael G Schwern wrote:
This handily solves your stated purpose of warning the user about
MockObjects not being used because of UNIVERSAL::isa mistakes WITHOUT
warning the user about EVERY mistaken use of UNIVERSAL::isa.
$ perldoc
Rafael Garcia-Suarez wrote:
On 26/02/07, chromatic [EMAIL PROTECTED] wrote:
Please reconsider autobox.
I second this request.
autobox in on CPAN and works. Moreover, the intent of the work on
lexical pragmas was to enable people to write their own pragmas and
put them on CPAN. (*) So
Fergal Daly wrote:
sub isa {
my ($obj, $class) = @_;
# do correct isa stuff
warn my warning if (exists $care_about{$class}) or (exists
$care_about{ref $obj});
Consider what if $obj is a subclass of the class you care about? That
should probably get checked, too, as it too overrides
A. Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2007-02-27 06:25]:
$SIG{__DIE__} = sub {
# We don't want to muck with death in an eval, but $^S isn't
# totally reliable. 5.005_03 and 5.6.1 both do the wrong thing
# with it. Instead, we use caller. This also means
Its not UNIVERSAL::require, its UNIVERSAL (which UNIVERSAL::require must
unfortunately load).
use UNIVERSAL;
use HTML::TokeParser qw(wibble);
HTML::TokeParser defines nor inherits any import routine. When there's no
import, any arguments to use are ignored and any calls to Class-import
Florian Scharinger wrote:
Hi,
I'm trying to get MakeMaker to create a Makefile for me which should do
the following, but I fail in one part:
* Put my Perl modules to $prefix/sbin
Uhh, Perl modules in sbin? You sure?
* Put my Perl script to $prefix/sbin as well
* Put some binary
Adam Kennedy wrote:
IT SHOULD NOT BE THIS COMPLICATED TO IDENTIFY THE HERITAGE OF AN OBJECT!
use Params::Util '_INSTANCE';
if ( _INSTANCE($obj, 'Whatever') ) {
}
Oh good, depend on another module to implement a basic language feature.
(I appreciate your suggestion but I'm LAMENTING
chromatic wrote:
On Thursday 01 March 2007 17:46, Adam Kennedy wrote:
Actually, isn't UNIVERSAL::can($x, 'can') still valid? I seem to
remember that at one point it was considered the only valid use of
UNVERSAL::can directly.
That's the only case I can think of too.
Hmm, that's a clever
Eirik Berg Hanssen wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
chromatic wrote:
On Thursday 01 March 2007 17:46, Adam Kennedy wrote:
Actually, isn't UNIVERSAL::can($x, 'can') still valid? I seem to
remember that at one point it was considered the only valid use of
UNVERSAL::can
Joshua ben Jore wrote:
Does defined( Scalar::Util::blessed )have cooties? Its the only
predicate you've ever had that actually works.
It requires depending on an XS module if you want compatibility pre-5.8.1.
I have to worry about stuff like that.
David Cantrell wrote:
Has anyone done any perl fuzz-testing - that is, written something that
generates valid but silly code in an attempt to find errors in the
interpreter or in a module?
It seems like a worthwhile thing to do, but I'm struggling to imagine
what it would look like,
Really hard. I've been trying to fix Test::Builder's behavior with abnormal
overloaded objects. This started with DateTime which can stringify and
compare but not numify. This revealed that cmp_ok() isn't testing
overloaded objects correctly, it always stringifies or numifies before
Eric Wilhelm wrote:
At the bottom of a test file:
{my $finish = 1; END {$finish or die \n unplanned exit}};
Yeah, you have to remember to put it at the end of the file, but it may
be easier than counting tests. Thoughts? Maybe an 'until_done'
directive and 'tests_done' function? Ways
Andy Lester wrote:
On Mar 3, 2007, at 8:15 PM, Eric Wilhelm wrote:
Yeah, you have to remember to put it at the end of the file, but it may
be easier than counting tests.
Good Lord do I get frustrated at the handwringing over test counting.
Look, it's simple. You write your tests. You run
Graham Barr wrote:
What I think brian is saying, and I agree, is that he does not want
to have to say don't send me mail N times. Where N is between 1
and, um I don't know. Haw many tools will there ever be that want
to send mail back to the author and what will their names be ?
So as well as
Ovid wrote:
Sounds like a replacement for Test::Builder not just Test::More.
Well, I guess it would be a replacement for Test::Builder and various
testing modules. It would be rather important to try and make it work
with existing test modules, though. Not sure how workable that would
be
Ovid wrote:
This would also be a nice development path for TAP 2.0.
Minor nit... please please please use integer version numbers. Please.
http://perl-qa.yi.org/index.php/TAP_version
Andy Armstrong wrote:
On 7 Mar 2007, at 16:26, Eric Hacker wrote:
[snip]
The first digit can be a grouping by success/failure.
Yes, I see where you're going with this :)
So then if I'm not too far off base with the above, then to use
something different than HTTP::Status type codes would be
demerphq wrote:
If you want to say Temporary Redirect don't say 307 say Temporary
Redirect! If you want to put lots of information into one value, like
categorization, use a hash! { type = Redirect, permanent = 0 }
Numeric response codes have the advantage that they are language agnostic.
Michael G Schwern wrote:
Stop. Stop stop stop! Stop right there.
Umm, people might not realize that I tend to be a bit over dramatic and
didn't actually mean to shut down the discussion.
Ovid wrote:
@EXPORT = (
@Test::More::EXPORT,
@Test::Differences::EXPORT,
@Test::Exception::EXPORT,
);
Don't forget @EXPORT_OK
Before I go completely off the handle, I'm going to say this once. Lately
there's been a tremendous amount of discussions about the same old crap over
and over again every few months. The same seemingly good but actually
flawed ideas are proposed, the same arguments are raised and the same
There's a lot of noise and very little signal about TAP lately. Absolutely
no real TAP extensions have been implemented. The TAP document remains in
exactly the same form it was 9 months ago.
http://search.cpan.org/~petdance/TAP-1.00/TAP.pm
We're spinning our wheels and going nowhere.
I'm
chromatic wrote:
On Friday 09 March 2007 14:50, Michael G Schwern wrote:
We can leverage any existing status system we want. HTTP status. Exit
status. Throw them all in! Don't find TAP's existing statuses rich
enough? Add your own extension keys! A particular status code not make
David Golden wrote:
Maybe you want to post the wiki address to remind people? ;-)
Doesn't Google know everything by now?
Ok, http://perl-qa.yi.org/index.php/Main_Page
Julien Beasley wrote:
Well at my last job, we had hundreds of test files.. and most of them were
really fast because we wanted to keep the total time to a minimum. Even
then, it took over five minutes to run all of our tests, and that was
getting to be Too Long. So I could definitely see in a
Eric Wilhelm wrote:
I think that should always be the case. While I don't forsee needing to
do it differently, I think it's safe to assume: if we ever need to
break that for some reason, then it's a newer version of TAP.
Taking that logic a step further, I vote YAGNI on the complete
Andy Armstrong wrote:
On 9 Mar 2007, at 23:17, Michael G Schwern wrote:
*) A TAP version
http://perl-qa.yi.org/index.php/TAP_version
Before we add any TAP extensions we need a way to identify what
version of
TAP we're outputting. Discuss and implement.
Done. The supported syntax
I've done a bit or work on the Wiki. The TAP proposals have been grouped
into ones that are considered worth implementing, ones that are still ideas
and ones that have been rejected / supplanted. Don't like the decisions I
made? Edit it, its a wiki.
I've also written out a proposal for the
Sam Vilain wrote:
Try this (after installing cogito):
cg-clone git://git.catalyst.net.nz/perl.git#restorical
git-log -p t/TEST
Thanks, but that only gets me up to August of 1996. Where's the rest?
Fergal Daly wrote:
Did group 1 produce 2 tests and group 2 produce 3 or was it the other
way around?
Why is that important to know?
Worse,
ok 1
ok 2
ok 3
...
ok 1001
1..1000
where did my extra test come from?
That's something the TAP producer can tell us, right now. No TAP
A. Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2007-03-11 12:55]:
Why does this need a TAP mod? Why not let the producer handle
it?
Because then all you can do is a global trailing plan which is
only half a step up from no plan?
Yep. And why is that a problem
Michael G Schwern wrote:
The attached proof-of-concept implements it. I had to poke at the guts of
TB to do it, there's no way to extend the plan without printing the plan, so
it would need a minor TB patch. But its very straight forward.
Figured out a way to not have to do that. Just
Sam Vilain wrote:
Ah right, I assumed you'd just be interested in the pre-perforce stuff -
I could get it from Perforce but that would require access to the repo.
And, of course, using Perforce. *yuck* The repo browser unfortunately
only goes back 50 revisions.
that above download is
Sam Vilain wrote:
If you grab the p4-perl branch, that's pretty much (sans importing
bugs) blead;
cg-branch-add p4-perl git://git.catalyst.net.nz/perl.git#p4-perl
cg-fetch p4-perl
cg-switch p4-perl
cg-switch: refusing to switch to a remote branch - see README for lengthy
Fergal Daly wrote:
On 11/03/07, Michael G Schwern [EMAIL PROTECTED] wrote:
Fergal Daly wrote:
You're suggesting that each call to extend the plan verifies that the
previous plan has been executed fully? That does not allow nesting.
Yes, nesting is what this proposal does which cannot
Michael G Schwern wrote:
Subroutines? I don't know if I follow. Do you mean...
sub foo {
extend(2);
pass();
bar();
pass();
}
sub bar {
extend(3);
pass();
pass();
pass();
}
I believe that can be made to work without a TAP extension. Its the
producer which
12!
I went back through all the changes to t/TEST and lib/Test/Harness.pm in
Perl using Sam's git repository and dug out all the extensions to TAP over
the years.
See http://perl-qa.yi.org/index.php/TAP_version for details.
Fergal Daly wrote:
Remember, the TAP producer is not the instigator of the conversation.
The consumer is - it runs the scripts, it requests something to
produce TAP. The consumer is the the client.
Oh but that's not necessarily true. As pointed out there are plenty of
situations where A) the
So, we seem to have drifted from the topic of test groups over to this topic
of future proofing against broken versions and TAP producer / parser version
negotiation. I have a simple solution for this.
If all we do is argue about TAP extensions and never actually produce one we
will never have
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.org 23509]
- Minor improvement to TB's filehandle detection in the case of
chromatic wrote:
On Tuesday 13 March 2007 23:15, Michael G Schwern wrote:
The simplest solution, and one which unblocks Test::Harness 3.0 because
TAP::Parser breaks compatibility in its current state, is to remove the
syncing feature.
If only there were a way, perhaps in Test::Builder
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 problems on
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, let
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 have two
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 indented
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
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
I believe I now know how to move towards no longer using STDERR for failure
information display AND keep compatibility with existing test scripts, even
those not written using Test::Builder or Test.pm AND not require
Test::Builder, Test.pm and TH not be upgraded in lock step AND not introduce
Yitzchak Scott-Thoennes wrote:
Michael G Schwern wrote:
print TAP version 15\n;
print 1..1\n;
print # Information\n;
print not ok 1\n;
print ! Failure\n;
I'd really not like to see meaningful punctuation.
I'm going to say its if a line starts with a ! just
901 - 1000 of 1466 matches
Mail list logo
