--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Oh, I see what it is. Funny, I just fixed this exact problem in
> aliased.pm.
> http://rt.cpan.org/Public/Bug/Display.html?id=25293
>
> Its base.pm.
>
> local $SIG{__DIE__};
> eval "require $base";
>
> Test::Builder::Mo
# from Michael G Schwern
# on Wednesday 28 March 2007 08:31 pm:
>Its base.pm.
>
> local $SIG{__DIE__};
> eval "require $base";
>
>Test::Builder::Module is loaded which loads Test::Builder which
> instantiates a __DIE__ handler which is localized and thrown out.
Hey, that is
Kirrily Robert wrote:
> What I want to know is, should I just bin it? Or might it, in fact, be
> useful to someone somehow? Or is it just bad form to completely delete
> CPAN modules? I guess I could update it with a new version that says
> "Don't use me."
You could just put out a CPAN-Test-Rep
Chris Dolan wrote:
> On Mar 28, 2007, at 8:18 AM, Ovid wrote:
>
>> The second test dies but this is ignored. Change My::Test::More to
>> Test::More and the failure is correctly reported. What did I miss in
>> My::Test::More?
>
> If you add a "print $SIG{__DIE__}" before the first "ok", you'll s
On Mar 28, 2007, at 8:18 AM, Ovid wrote:
The second test dies but this is ignored. Change My::Test::More to
Test::More and the failure is correctly reported. What did I miss in
My::Test::More?
If you add a "print $SIG{__DIE__}" before the first "ok", you'll see
that with Test::More it's a
Were I you, I'd probably just post an annocpan and/or cpanratings
comment recommending an alternative. Uploading a new version would
probably be OK. However, that would alter the last upload date to
2007. I often use the date of last upload as a clue when searching
for CPAN modules. *
On Mar 28, 2007, at 9:17 PM, Kirrily Robert wrote:
In September 2001, apparently all aglow in the excitement of all the
talk that was going on about testing and whatnot, I wrote a module
called CPAN::Test::Reporter.
(http://search.cpan.org/~skud/CPAN-Test-Reporter-0.02/) Looking at
it,
I have
In September 2001, apparently all aglow in the excitement of all the
talk that was going on about testing and whatnot, I wrote a module
called CPAN::Test::Reporter.
(http://search.cpan.org/~skud/CPAN-Test-Reporter-0.02/) Looking at it,
I have no idea what I was thinking or why I thought it was nec
Andy Armstrong wrote:
>> That really requires me to collect all the data for this table and
>> then send it to diag. I think I would prefer to output it line by line
>> as the test runs, maybe with other calls in betwwen:
> [snip]
>
> Well of course there's nothing to stop anyone writing code that
Ovid wrote:
> The second test dies but this is ignored. Change My::Test::More to
> Test::More and the failure is correctly reported. What did I miss in
> My::Test::More?
I'm not sure. The __DIE__ handler isn't being triggered to detect that you
died. Might be a Perl bug.
Test::Builder needs t
I finally got a chance to follow Schwern's advice and
fix this problem. Look for version 0.14 on a CPAN
mirror near you shortly.
Thanks for letting me know about it.
Phil
--- Julien Beasley <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've found that using Test::Files in a test script
> changes the ou
On 28 Mar 2007, at 18:33, Gabor Szabo wrote:
On 3/28/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 28 Mar 2007, at 17:40, Andy Armstrong wrote:
> you'll probably do something like this:
>
> annotate( { dump => [EMAIL PROTECTED] } );
Actually there'll be another level below dump:
annotat
On 3/28/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 28 Mar 2007, at 17:40, Andy Armstrong wrote:
> you'll probably do something like this:
>
> annotate( { dump => [EMAIL PROTECTED] } );
Actually there'll be another level below dump:
annotate { dump => {'IP Table' => [EMAIL PROTECTED] }
On 28 Mar 2007, at 17:40, Andy Armstrong wrote:
you'll probably do something like this:
annotate( { dump => [EMAIL PROTECTED] } );
Actually there'll be another level below dump:
annotate { dump => {'IP Table' => [EMAIL PROTECTED] } };
--
Andy Armstrong, hexten.net
On 28 Mar 2007, at 16:32, Gabor Szabo wrote:
The output then can be in YAMLish or whatever but I would like to have
a parser that can generate HTML or whatever tables from this data.
Something like this:
---
| Name | IP
| Foo | 10.1.1.1
---
Sorry, that was half written only...
In line with the discussion of TAP I would like to show a use case I
would like to be able to handle. I would like to be able to report
certain information in table format
in (or instead of) the diag call.
So my test code would look something like this:
my $
In line with the discussion of TAP I would like to show a use case I
would like to be able to handle. I would like to be able to report
certain information in table format
in (or instead of) the diag call.
So my test code would look something like this:
create_table({
title => "Machines",
Here's the minimal test case:
use lib 't/lib';
use My::Test::More 'no_plan';
sub foo {
die 'some problem' if @_;
return 1;
}
ok foo(), 'this lives';
ok foo(1), 'this dies';
And My::Test::More (a stripped down version of
http://use.perl.org/~Ovid/journal/32614):
packa
Michael G Schwern wrote:
Another route is to go the "lite" software route. Instead of testing with
Apache and PostgreSQL, test with HTTP::Server::Simple and SQLite. Easier to
install and configure. The downside is you're not testing against your real
production environment so something still
On 3/27/07, Kirrily Robert <[EMAIL PROTECTED]> wrote:
The problem is that all the developer sandbox websites run on one server
that's groaning under the strain. It's in the process of being replaced
but we're not there yet. The upshot of this is that on a good day, the
web tests take ages to ru
20 matches
Mail list logo
