Andrew Hampe wrote:
The Basic CPAN concern: --bail_on_fail flag (2008.02.10 )
Problem description:
when a cpan session is looking for more than one distribution/module
there needs to be a way to 'flag' that the session must fail and stop
if there is an error loading any
Ovid wrote:
Crap. Can we just forget I sent that to Perl QA instead of the Grant
Committee?
/me puts on his sunglasses.
/me pulls out a black device.
Now if everyone on perl-qa will please look this way...
*FLASH!*
--
You are wicked and wrong to have broken inside and peeked at the
Ian Malpass wrote:
I got a failure message from CPAN testers for Pod::Extract::URI for
5.11.0 patch 33001 on Linux 2.6.22-3-amd64
(x86_64-linux-thread-multi-ld)[0]
The failures were where I was testing to see if an arrayref of qr//
patterns was the array I was expecting. is_deeply() has
Ovid wrote:
What should parallel tests do if a BAIL_OUT is encountered? I think
all parallel tests currently running should be allowed to finish so
they can attempt to cleanup, but no more tests should be started. Does
this sound reasonable?
It's not entirely clear if bail out means kill the
Ovid wrote:
Test::Harness used to be very limited. We couldn't do a lot with it,
but when we started testing, most of us didn't do a lot with it. As we
understood more about testing, we understood better many things we
wanted. As a result, Schwern posted a great plan for rewriting
Gabor Szabo wrote:
I know I am a bit late to the party but what about Test::Anything ?
Rapidly drifting towards Test::Anything::Protocol.
--
But there's no sense crying over every mistake.
You just keep on trying till you run out of cake.
-- Jonathan Coulton, Still Alive
Matisse Enzer wrote:
On Jan 12, 2008, at 10:24 PM, Michael G Schwern wrote:
Matisse Enzer wrote:
I just want to be able to run a test suite with a switch that makes the
entire test run stop after the first failure is reported.
Ok, it's nice to want things, but why do you want
Michael Peters wrote:
Michael G Schwern wrote:
Ok, why do you want to stop it as fast as possible when a failure occurs?
I have a 45 minute test suite and I want to work on the first failure as soon
as
possible. I also have multiple desktops and am doing other things in another
desktop
Adam Kennedy wrote:
This shouldn't be any more complicated than -g (where g in my case
stands for goat as in feinting goat)
Ok, I'll bite. Why a goat and why is it feinting?
--
...they shared one last kiss that left a bitter yet sweet taste in her
mouth--kind of like throwing up after
Ovid wrote:
I'll go fix that diagnostic thing now. Unfortunately, I think I'll
have to violate encapsulation :(
If you know how to fix it let me know, because other than enumerating each
testing module you might use and lex-wrapping all the functions they export,
I'm not sure how to do it.
The whole idea of halting on first failure was introduced to me by some XUnit
folks. Their rationale was not to avoid spewing output, they had no such
problem since it's all done via a GUI, but that once one failure has happened
the failing code might hose the environment and all following
Ovid wrote:
--- Michael G Schwern [EMAIL PROTECTED] wrote:
The whole idea of halting on first failure was introduced to me by
some XUnit
folks ... As any field scientist knows, there's no such thing as
uncontaminated data.
As any tester knows, a one size fits all suit often doesn't fit
Aristotle Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2008-01-12 12:00]:
Ovid wrote:
I'll go fix that diagnostic thing now. Unfortunately, I
think I'll have to violate encapsulation :(
If you know how to fix it let me know, because other than
enumerating each testing module you
Ovid wrote:
So we can preserve diagnostics, but we need help in cleaning up those
damned line numbers. Hook::LexWrap didn't have the magic I thought it
would.
ok() is now inside a wrapper so you're one level further down then it thinks.
Just add one to $Level and then take it back off again
Paul Johnson wrote:
This is something that I too have asked for in the past. I've even
hacked up my own stuff to do it, though obviously not as elegantly as
you or Geoff. Here's my use case.
I have a bunch of tests that generally pass. I hack something
fundamental and run my tests.
Ovid wrote:
My first attempt at determining the most popular testing modules left
out Test.pm. Whoops! I've fixed that.
Out of almost 60,000 test programs, it turns out Test.pm is used 8,937
times. Now that I have a file which lists how many times each test
module is used, I can start
Matisse Enzer wrote:
I just want to be able to run a test suite with a switch that makes the
entire test run stop after the first failure is reported.
Ok, it's nice to want things, but why do you want it?
--
100. Claymore mines are not filled with yummy candy, and it is wrong
to tell
Ovid wrote:
I've posted a trimmed down version of the custom 'Test::More' we use
here:
http://use.perl.org/~Ovid/journal/35363
I can't recall who was asking about this, but you can now do this:
use Our::Test::More 'no_plan', 'fail';
If 'fail' is included in the import list, the
Salve J Nilsen wrote:
Oslo.pm is planning a Perl QA Workshop/Hackathon in Oslo, Saturday
April 4th to Monday April 7th, 2008.
FWIW, if I can get sponsored, I'm going with bells on.
Just to make things more interesting, IEEE will have a conference on
software testing nearby (in Lillehammer,
demerphq wrote:
So we are told the way to mark a module as development is to use an
underbar in the version number:
$VERSION= 1.23_01;
but this will produce warnings if you assert a required version
number, as the version isn't numeric.
We talked about this recently on [EMAIL PROTECTED]
demerphq wrote:
Just a heads up that I patched the core version of Test::Builder to
use more reliable and robust methods for detecting regexps in test
cases. This makes them robust to changes in the internals and also
prevents Test::Builder from getting confused if someone uses blessed
nadim khemir wrote:
print 'hi' or carp q{can't print!} ;
I'm not even going to wade into the layers of neurosis demonstrated in this
post, but if you want to throw an error use croak().
--
...they shared one last kiss that left a bitter yet sweet taste in her
mouth--kind of like throwing up
Eric Wilhelm wrote:
# from Aristotle Pagaltzis
# on Wednesday 02 January 2008 16:47:
looking for (and diffusing) mines
That sounds like a novel approach! Or do you mean “defusing”? :-)
Yeah :-D Diffuse is probably what they do when you find them the less
careful way!
I guess the
Gabor Szabo wrote:
Is there a place with definition of what a VERSION value can be ?
Anything which compares sanely as a number plus the X.YY_ZZ alpha convention
(which MM converts to a number). I guess that's never stated explicitly. I'd
welcome a section on $VERSION in
Gabor Szabo wrote:
might be slightly unrelated to QAsorry
In the future, MakeMaker issues go to [EMAIL PROTECTED]
After installing JOSHUA/Net-Telnet-Cisco-1.10.tar.gz
if I run perl Makefile.PL on an unrelated Makefile.PL that
requires 'Net::Telnet::Cisco' = '1.10'
I get a
David Golden wrote:
On Dec 23, 2007 2:37 AM, Michael G Schwern [EMAIL PROTECTED] wrote:
[1] It can be argued that bleadperl testers should probably not email
authors,
and maybe they aren't I can't tell from these archives, but at least the work
is useful. CPAN::Reporter could change
Michael G Schwern wrote:
David Golden wrote:
On Dec 23, 2007 2:37 AM, Michael G Schwern [EMAIL PROTECTED] wrote:
[1] It can be argued that bleadperl testers should probably not email
authors,
and maybe they aren't I can't tell from these archives, but at least the
work
is useful. CPAN
chromatic wrote:
On Saturday 22 December 2007 16:48:29 Michael G Schwern wrote:
The I installed to a directory with a space in the path is an example of
CPAN Testers working as expected. It found and highlighted an annoying bug
that the rest of us either ignore or work around.
CPAN Testers
chromatic wrote:
I just went through a sampling of fail reports for my stuff. There was one
legitimate packaging bug, and a couple of legitimate errors due to updates to
Perl. About 35% of the other reports are these.
I love the Illegal seek error message:
Michael Peters wrote:
David Golden wrote:
On Dec 20, 2007 1:19 PM, Dave Rolsky [EMAIL PROTECTED] wrote:
It's generally
pretty rare that the failure report includes enough information for me to
do anything about it, so without an engaged party on the other end, it
really is just noise.
With
Andy Armstrong wrote:
On 21 Dec 2007, at 00:11, Michael G Schwern wrote:
This could be accomplished silently with some environment variables.
TAP_PARSER_ARCHIVE_DIR=/path/to/somewhere
It's called PERL_TEST_HARNESS_DUMP_TAP and it already exists.
Well there you go.
Though might I suggest
Andy Armstrong wrote:
On 19 Dec 2007, at 03:13, Michael G Schwern wrote:
Anyhow, what's clear is there is a problem with IO::AIO. It hasn't been
addressed properly by the author. While it's frustrating to get a
constant
stream of your shit is broke, his shit is indeed broke
chromatic wrote:
On Tuesday 18 December 2007 17:27:24 Andy Armstrong wrote:
Someone (MLEHMANN) doesn't like smoking... That was a test report
generated by CPAN::Reporter.
It hadn't previously occurred to me that test reports might cause
offence...
Didn't you get a whole slew of them a
Andreas J. Koenig wrote:
On Sat, 15 Dec 2007 01:34:37 -0800, Michael G Schwern [EMAIL
PROTECTED] said:
See above. Once the bug is reported there is no justification to keep
the test around. In this case I prefer a skip over a removal because
the test apparently once was useful
nadim khemir wrote:
On Saturday 15 December 2007 20.53.30 Michael Peters wrote:
The uploaded file
TAP-Harness-Archive-0.03.tar.gz
...
Nice. Now, what do we do with it?
You RTFM.
http://search.cpan.org/perldoc/TAP::Harness::Archive
--
If at first you don't succeed--you fail.
Andreas J. Koenig wrote:
On Fri, 14 Dec 2007 15:49:32 -0800, Michael G Schwern [EMAIL
PROTECTED] said:
We would seem to be agreeing. If the goal of the test suite is not to
protect
against spoofing, and if it doesn't accomplish that anyway, why put a
signature check
Adrian Howard wrote:
On 11 Dec 2007, at 05:12, Michael G Schwern wrote:
Adam Kennedy posed me a stumper on #toolchain tonight. In short,
having a
test which checks your signature doesn't appear to be an actual
deterrent to
tampering. The man-in-the-middle can just delete the test
Andreas J. Koenig wrote:
On Mon, 10 Dec 2007 21:12:51 -0800, Michael G Schwern [EMAIL
PROTECTED] said:
Adam Kennedy posed me a stumper on #toolchain tonight. In short, having a
test which checks your signature doesn't appear to be an actual deterrent
to
tampering. The man
Edwardson, Tony wrote:
Anyone written any CPAN modules for which the testing coverage needs to be
improved ?
Want someone else to sort this out for you ?
...
Any takers ?
http://search.cpan.org/dist/ExtUtils-MakeMaker
Repository here:
http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMaker
Ovid wrote:
Test results currently look something like this:
t/foo.t. ok
t/bar.t. ok
t/baz.t. 23/?
# Failed test at t/baz.t line 9
# Looks like you failed 2 tests out of 23
t/baz.t. Dubious, test ...
Why do
Eric Wilhelm wrote:
Since we're on the subject of CPAN::Reporter, TAP::Harness, Test::More,
and TODO wrt failure vs. no-noise vs. report-back vs. await-dependency
and the binaryism of failure and etc...
Perhaps a general sort of MAYBE namespace in TAP would be a nice
addition.
Is this a
A. Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2007-12-05 04:30]:
Why do they care if the plan is output at the beginning or end?
How does this stricture improve the quality of the test?
It improves the resulting TAP stream, if not the test itself.
What's improved about the plan
Eric Wilhelm wrote:
# from Michael G Schwern
# on Wednesday 05 December 2007 05:47:
Perhaps a general sort of MAYBE namespace in TAP would be a nice
addition.
Is this a joke? I hope it's a joke.
Do I look like I'm joking? :-|
As it is, we're talking about detecting/reporting a 3rd
Eric Wilhelm wrote:
Give me something concrete, not just it's better. I'm going to
keep drilling through the BS until I either hit bottom or punch
through.
It allows you to apply the policy all tests have a plan at the test
level. Yes, policy often sounds like BS.
By historical
A. Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2007-12-05 15:00]:
I'm going to keep drilling through the BS until I either hit
bottom or punch through.
Yeah, we’re all spouting bullshit. Gee, some tone you’re setting.
Sorry, I forgot the :)
That I'm pushing so hard to get
Fergal Daly wrote:
The importance of the test has not changed. Only the worth of the
failure report has changed.
This could be solved by having another classification of test, the
not my fault test used as follows
BLAME: {
$foo_broken = test_Foo(); # might just be a version check or
Ovid wrote:
Side note: those features I really want control over in
Test::Harness
are the plan() and ok() methods. There's no clean way for me to do
that. Just look at the constructor:
my $Test = Test::Builder-new;
sub new {
my($class) = shift;
$Test ||= $class-create;
A. Pagaltzis wrote:
Yes, so this should be allowed:
pass();
plan 'no_plan';
pass();
Whereas this should not:
pass();
plan tests = 2;
pass();
Umm, why not? That's exactly what I was proposing and it would result in...
ok 1
ok 2
1..2
Smylers wrote:
It also makes it technically possible to allow the test to change
it's plan mid-stream
Without some hypothetical future version of TAP this is only possible
if you have run tests before declaring a plan at all, because
otherwise the plan will already have been output as the
A. Pagaltzis wrote:
That would work. Of course once you have that, you don’t need to
allow assertions to run without a plan, since one can always say
use Test::More tests = variable = 0;
pass();
plan add_tests = 2;
pass();
instead of
use Test::More;
pass();
Geoffrey Young wrote:
Andy Armstrong wrote:
On 4 Dec 2007, at 15:22, Geoffrey Young wrote:
it would be nice if this were enforced on the TAP-digestion side and not
from the TAP-emitter side - the coupling of TAP rules within the
TAP-emitter is what lead to my trouble in the first place.
A
Andreas J. Koenig wrote:
Bug in CPAN::Reporter and/or Test::Harness and/or CPAN.pm?
http://www.nntp.perl.org/group/perl.cpan.testers/796974
http://www.nntp.perl.org/group/perl.cpan.testers/825449
All tests fail but Test::Harness reports NOTESTS and CPAN::Reporter
concludes UNKNOWN and
This this whole discussion has unhinged a bit from reality, maybe you can give
some concrete examples of the problems you're talking about? You obviously
have some specific breakdowns in mind.
Fergal Daly wrote:
Modules do not have a binary state of working or not working. They're
composed
Geoffrey Young wrote:
I guess what I thought you were getting at was a natural decoupling of
comparison functions with the planning without all the hackery involved
to get that sepraration working now. so I was suggesting that the
decoupling go further than just no_plan, and that yeah, rock
Eric Wilhelm wrote:
A. Pagaltzis wrote:
...
which would still be an error. That way a mistake in a test
script won’t lead to Test::More silently converting an up-front
plan declarations into trailing ones.
Which brings us back to the original question: why should that be an
error?
It's
::Harness (aka Test::Harness 3) has fairly easy ways to control how
TODO tests are interpreted.
** It could be made easier, especially WRT controlling make test
** CPAN::Reporter could be made aware of TODO passes.
Fergal Daly wrote:
On 05/12/2007, Michael G Schwern [EMAIL PROTECTED] wrote
So I read two primary statements here.
1) Anything unexpected is suspicious. This includes unexpected success.
2) Anything unexpected should be reported back to the author.
The first is controversial, and leads to the conclusion that TODO passes
should fail.
The second is not controversial,
use Test::More;
pass();
plan tests = 2;
pass();
Why shouldn't this work? Currently you get a You tried to run a test without
a plan error, but what is it really protecting the test author from?
Historically, there was a clear technical reason. It used to be that
David Golden wrote:
Michael G Schwern [EMAIL PROTECTED] wrote:
It also makes it technically possible to allow the test to change it's plan
mid-stream, though the consequences and interface for that do require some
thought.
With some sugar, that could actually be quite handy for something
Eric Wilhelm wrote:
# from David Golden
# on Monday 03 December 2007 19:55:
With some sugar, that could actually be quite handy for something like
test blocks. E.g.:
{
plan add = 2;
ok( 1, wibble );
ok(1, wobble );
}
or maybe make the block a sub
block {
subplan 2;
Fergal Daly wrote:
One of the supposed benefits of using TODO is that you will notice
when the external module has been fixed. That's reasonable but I don't
see a need to inflict the confusion of unexpectedly passing tests on
all your users to achieve this.
Maybe we should just change the
Fergal Daly wrote:
As long as you're releasing a new version, why would you not upgrade your
module's dependency to use the version that works?
Your module either is or isn't usable with version X of Foo.
If it is usable then you would not change your dependency before or
after the bug in
Eric Wilhelm wrote:
# from Michael G Schwern
# on Thursday 29 November 2007 19:00:
Otherwise, what's important to people?
Could it be made fork-safe?
http://search.cpan.org/src/TJENNESS/File-Temp-0.19/t/fork.t
Possibly that involves blocking, or IPC with delayed output, or a
plan
Andy Armstrong wrote:
On 30 Nov 2007, at 03:00, Michael G Schwern wrote:
Otherwise, what's important to people? I know there's a lot of
suggestions
about increasing the flexibility of planning. Also the oft requested
I'm
done running tests sentinel for a safer no_plan. Most of the time
As threatened, here's Test::Fork for easier writing of forked tests.
http://pobox.com/~schwern/src/Test-Fork-0.01_01.tar.gz
use Test::More tests = 4;
use Test::Fork;
fork_ok(2, sub{
pass(Child);
pass(Child again);
});
Michael G Schwern wrote:
Otherwise, what's important to people?
Here's something that's important to me. I'd like to make it easier for
people to patch my modules. A bunch of people already have write access to my
repository, and I've taken care to ensure that most all the outstanding items
Andy Armstrong wrote:
Will the sky fall and babies cry if we go with '--'? I would hope not.
It closes off the conventional method of passing in files that look like
switches. So yes, that hunk of sky will fall.
Let's have a quick show of hands and move on, eh?
[ ] --
[X] something else
Andy Armstrong wrote:
I'd like
# Run all tests
$ prove --state=save -rb t/*.t
# Re-run failures from above
$ prove --state=fail -rbv
# Re-run failures and remember failures
$ prove --state=save,fail -rbv
Using the third form repeatedly would run only the test programs that
failed
Andy Armstrong wrote:
Why so verbose?
Aristotle's '::' suggestion is my favourite. It's syntactically clean.
It's visually distinct from other switches - so you can easily see that
something special is happing. It's short.
And without context it's totally void of meaning. Someone hit it on
chromatic, I think, in that big prove argument, pointed out that Test::More
side-stepped the whole shove all functionality into one interface problem by
creating Test::Builder. TAP::Parser and prove should go in the same direction.
Over and above simply being a way to build new test libraries,
Looking at the tickets for Test::More I see it's mostly down to wishlist items
and unimportant things.
http://rt.cpan.org/Public/Dist/Display.html?Name=Test-Simple
I can identify only two real important bugs, as far as I'm concerned. The
first has to do with overloading. cmp_ok() doesn't DTRT
Andy Armstrong wrote:
On 30 Nov 2007, at 01:32, Michael G Schwern wrote:
The absurdity of :: becomes more clear because you can apply the same
arguments to any switch of prove. Let's use ++ instead of '--color'
because
its syntactically clean and visually distinct. Or ;; for --merge
A. Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2007-11-30 02:35]:
Let's use ++ instead of '--color' because its syntactically
clean and visually distinct. Or ;; for --merge.
Except there’s no good precedent for sentinel values whereas
there are clear precedents for switches
Andy Armstrong wrote:
It is done :)
http://hexten.net/tapx/r867/Test-Harness-3.04.tar.gz
or
svn co http://svn.hexten.net/tapx/trunk
=head2 Arguments to Tests
It is possible to supply arguments to tests. To do so separate them from
prove's own arguments with '--'. For example
Andy Armstrong wrote:
On 29 Nov 2007, at 02:17, Michael G Schwern wrote:
Why isn't this just:
prove -v t/mytest.t --test_args='--url http://example.com'
It's clear, it's unambiguous, it allows -- to mean what it's supposed
to mean.
I agree re the semantics of '--' - but I'd rather
Eric Wilhelm wrote:
# from Michael G Schwern
# on Wednesday 28 November 2007 20:11:
There's the additional problem that it restricts the test arguments to
only be allowed at the end of the prove command line. This means
switch ordering is important, which will lead to problems
As interesting / important as all this might be or might not be, it has
nothing to do with quality assurance. Take it elsewhere. Perhaps Groklaw,
they might actually have some legal knowledge.
And please don't replace the argument with an argument about how this is
somehow related to QA.
Matisse Enzer wrote:
I am looking for a way to run a fully-automated CPAN build (using
CPAN::Shell) of a local Perl module and its dependencies, but, I need to
make REMOVE some directories from the compiled-in @INC during the build
process.
While it is not documented, you can override what
Gabor Szabo wrote:
I would suggest for those who are really interested in OPS (Old Perl Support)
to run the tests of the module(s) on OP and report them to CPAN Testers.
That way we'll be able to fetch the
latest version passing its test on OP for every module on any specific OP
right from
Slaven Rezic wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
Why make this change now? I've always been frustrated at being hamstrung
from
using new features of perl. The Perl Survey results is what pushed me over
the edge. [1] Only 6% of the respondents say they used 5.5.x
Andy Armstrong wrote:
I've added logic that produces output like this:
13:54] andy $ prove t/sample-tests/skipall t/sample-tests/
skipall_nomsg t/sample-tests/simple
t/sample-tests/skipall..skipped: rope
t/sample-tests/skipall_nomsgskipped: (no reason given)
brian d foy wrote:
Fair enough. Can you make a list of the last versions of all of those
that should work with Perl5.005? I suppose that's the current list
right now.
Pretty much. If anyone wants to put in the effort to make such a list they
can, knock yourself out.
--
...they shared one
nadim khemir wrote:
I spend a rather large amount of time writing and running tests. There are a
few things that could be better. I either don't know how or it may not
possible. I thought we could share some of questions and ideas that can make
working with tests more pleasent. This should
This is an announcement that my modules will no longer try to be backwards
compatible with 5.5.x. This includes ExtUtils::MakeMaker and Test::More.
Toolchain modules will now target 5.6.0. Modules not part of the build
toolchain will be moving up to 5.8.0.
This doesn't mean I'm going to go
chromatic wrote:
This is a specific sort of failure, and as far as I'm concerned it is an
improperly configured machine. I'm not going to include a redundant
Makefile.PL just to support people who don't upgrade their tools. It's
no different than not supporting perl 5.005.
I believe Eric is
demerphq wrote:
On 10/19/07, A. Pagaltzis [EMAIL PROTECTED] wrote:
* demerphq [EMAIL PROTECTED] [2007-10-19 18:50]:
How does one use this then? Where is it documented?
http://module-build.sourceforge.net/META-spec-blead.html#configure_requires
So how do i use this with MakeMaker?
Step One:
Eric Wilhelm wrote:
/usr/local/sbin/mbBuild is:
#!/bin/sh
./Build $@
^^
That should be $@ or else it will get confused by spaces.
On a related note, that sort of thing is generally useful for those of us who
find typing ./Build just a little more annoying than make. I have
Hi, you're getting this mail because your CPAN distribution makes use of
Test::Harness::Straps (or you're subscribed to perl-qa).
Test::Harness version 3 will not include Test::Harness::Straps. It was an
experiment, it didn't work out. Sorry. Current users of Straps are
encouraged to instead
Eric Wilhelm wrote:
# from Michael G Schwern
# on Monday 15 October 2007 18:00:
We're not going to retroactively remove it from the 2.x series. 3.0
and beyond will not have straps.
To clarify further, upgrading from TH 2 to TH 3 will not break Straps.
not break in what sense? From my
Geoffrey Young wrote:
Honestly, just convert to TAP::Parser. Straps has no future.
Apache-Test subclasses Straps to override _command_line() and provide
php as the test caller (so you can run t/foo.php with php instead of perl).
unfortunately for us, the magic required for this to work
chromatic wrote:
On Tuesday 16 October 2007 05:18:40 Michael G Schwern wrote:
Honestly, just convert to TAP::Parser. Straps has no future.
It has a zombie future. You can't remove it for TEN YEARS because it's in
the
core and people with government contracts rely on it.
Page one
Andy Armstrong wrote:
On 16 Oct 2007, at 20:04, Michael G Schwern wrote:
If somebody REALLY cares they can gut it to use TAP::Parser so it gets
future
bug and feature fixes. But that's like putting rocket engines on a
blimp.
To be honest when I started working on Test::Harness 2.xx
Andy Lester wrote:
On Fri, Oct 05, 2007 at 11:22:57AM -0500, brian d foy ([EMAIL PROTECTED])
wrote:
Do you mean that Test::Harness 3.0 won't have it but it will still be
there in earlier releases, or that you're going to remove any trace of
it from CPAN so it looks like it never existed?
Greg Sabino Mullane wrote:
On Fri, 2007-09-28 at 17:09 -0700, Michael G Schwern wrote:
It's also nice to see how far along we are with a running
tally, when I check back in on the running tests.
How do you accomplish that?
Not sure what you mean. Toggle back to the terminal window
Greg Sabino Mullane wrote:
Michael G Schwern asks:
What's wrong with no_plan? Why go through backflips to
automate counting the tests when you can just not count
them? Seems needlessly officious.
I seldom run the whole test suite at once, but only parts I care about
at the moment, so
Greg Sabino Mullane wrote:
I just released Bucardo, a multi-master replication system for Postgres.
It has a fairly intense test suite, and I was developing it, I ended up
writing Yet Another Test Counter. At some point, I decided to turn it
into a proper module. Here's the POD page:
Zaven Boni wrote:
Hello list,
My team at Data Domain (NASDAQ: DDUP), the leader in de-duplicating
storage systems, is looking for an engineer with solid Perl skills as
well as a system performance measurement and tuning background. We are
part of the development team which builds the DDOS
Graham TerMarsch wrote:
As a dumb alternative... what about explicitly listing M::B as a build
dependency? Would that trigger CPANPLUS into installing it and then
restarting the build?
I don't know what CPANPLUS does with build_requires. It'll probably balk
about missing
Graham TerMarsch wrote:
On Wednesday 26 September 2007 3:41 pm, David Golden wrote:
I don't think Module::Build can be a build_requires. I think it has to
be a configure_requires. (Not that support is widespread yet.)
On 9/26/07, Michael G Schwern [EMAIL PROTECTED] wrote:
Graham TerMarsch
Salve J Nilsen wrote:
- Set up some kind of syndication feed [RSS, Atom] [somewhere sensible]
where one can read which distributions currently have a pre-release
status. The feed might be called NEED TESTING or something like that.
Make this feed visible on central Perl-related websites
301 - 400 of 1466 matches
Mail list logo
