Custom Search
|
Date: December 31, 2006
From: Eric Wilhelm <scratchcomputing@xxxxxxxxx>
In-reply-to:
<20061231111449.GB1044@xxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx> <875029960612301813s134fa302hd682ca55582f8553@xxxxxxxxxxxxxx> <20061231111449.GB1044@xxxxxxx>
# from Paul LeoNerd Evans # on Sunday 31 December 2006 03:14 am: >EU::MM can't, but I believe Module::Build can. That said, the > consensus on #perl/Freenode is that the latter isn't really ready > yet, so just use the former. Is it not ready only because the consensus says it is not ready and therefore it is not in use enough to be believed that it is ready? # from Paul LeoNerd Evans # on Sunday 31 December 2006 07:23 am: >but there isn't currently a way to make >ExtUtils::MakeMaker have build-time dependencies that don't turn into >runtime dependencies. I have in fact reported a bug/wishlist/"I'll > patch it if you think this is good" ticket on it: > > http://rt.cpan.org//Ticket/Display.html?id=24159 So, instead of using Module::Build, which has this feature, you're going to wait for it to be added to the "please kill this" installer which doesn't? http://schwern.org/~schwern/talks/MakeMaker_Is_DOOMED/slides/slide001.html Seems to me that it would be in the EU::MM maintainer's best interest to *never* support that feature. Thus, you (and others) would have motivation to use Module::Build and therefore the consensus would change from "not sure" to "works great" (and Schwern will finally get his wish of putting some concrete boots on EU::MM and waving to it as it quickly sinks into the murky depths of the Willamette.) I've been using Module::Build exclusively for at least a year now and the only trouble I've had has been from users running an old CPAN.pm (but that's only because I'm cruel enough to quit including compatibility makefiles specifically because I think it's a good idea for users to upgrade CPAN.pm once a year or so (hey, it's a free upgrade.)) I guess the best way to solve the chicken and egg problem is to make a chicken omelet. If you want a feature, just have a dependency. Same goes for whether or not to use Test::Exception. The installer will get better over time (usually with little or no effort on your part), but writing your own code or workaround to avoid a dependency means you get to maintain that forever. --Eric -- Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. --Alan Kay --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
Date: December 31, 2006
From: "Joshua ben Jore" <twists@xxxxxxxxx>
In-reply-to:
<20061231111449.GB1044@xxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx> <875029960612301813s134fa302hd682ca55582f8553@xxxxxxxxxxxxxx> <20061231111449.GB1044@xxxxxxx>
On 12/31/06, Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx> wrote: \> No it doesn't... This is one of those things about perl - code that
looks like a function call is never checked to see if the function exists until runtime: #!/usr/bin/perl use warnings; use strict; print "Here I have started running now\n"; foobarsplot(); ^-- won't complain until runtime. That's what gave me the motivation to write B::LintSubs, by the way: http://search.cpan.org/~pevans/B-LintSubs-0.02/
Isn't that just a copy of a 5.8-ish perl -MO=B,undefined-subs? The 5.9.something+ versions added support for threaded perls and you might want to copy that too. There's also support for arbitrary plugins so you can write your tests code as a plain plugin and it gets called during the single runloop and you don't have to have a runloop in your tests anymore. Josh
Date: December 31, 2006
From: Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx>
In-reply-to:
<32F64517-1B7F-4A51-BB2A-7852C3CB6DFD@xxxxxxxxxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx> <2DCE933C-DA08-4D26-9A6E-F0D08530B9E3@xxxxxxxxxxxxxx> <20061231164444.GF1044@xxxxxxx> <32F64517-1B7F-4A51-BB2A-7852C3CB6DFD@xxxxxxxxxxxxxx>
On Sun, Dec 31, 2006 at 05:02:39PM +0000, Adrian Howard wrote: > >Well, that's the thing. I had to install it on the test boxes I'm > >currently developing the code on - I didn't want to upload it to PAUSE > >then find that all the automatic test boxes all fail it because of a > >missing Test:: module. > > Then declare it as a dependency :-) Yes.. that was my problem. How to be build-time without run-time. I'll see what comes of my bugreport on EU::MM > >That said, I know Test::More isn't core, yet all my tests use that > >without declaring it, so maybe it would work. > [snip] > > Erm... Test::More has been core since 5.007003 Ah yes. In that case, it just makes this look trickier - given as T::E isn't core, I can't rely it being installed on test boxes. See above. -- Paul "LeoNerd" Evans leonerd@xxxxxxxxxxxxxx ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Date: December 31, 2006
From: Sébastien Aperghis-Tramoni <maddingue@xxxxxxx>
In-reply-to:
<20061231164444.GF1044@xxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx> <2DCE933C-DA08-4D26-9A6E-F0D08530B9E3@xxxxxxxxxxxxxx> <20061231164444.GF1044@xxxxxxx>
Paul LeoNerd Evans wrote:
That said, I know Test::More isn't core, yet all my tests use that without declaring it, so maybe it would work.
Test::More is core, but only since Perl 5.8 (to speak with stable Perl releases). Just remember that, contrary to an unfortunate but popular belief, "the set of core Perl modules" is a moving target. Use Module::CoreList and its command corelist(1) to know which module is core and since when.
-- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Date: December 31, 2006
From: Adrian Howard <adrianh@xxxxxxxxxxxxxx>
In-reply-to:
<20061231164444.GF1044@xxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx> <2DCE933C-DA08-4D26-9A6E-F0D08530B9E3@xxxxxxxxxxxxxx> <20061231164444.GF1044@xxxxxxx>
On 31 Dec 2006, at 16:44, Paul LeoNerd Evans wrote: [snip]
Well, that's the thing. I had to install it on the test boxes I'm currently developing the code on - I didn't want to upload it to PAUSE then find that all the automatic test boxes all fail it because of a missing Test:: module.
Then declare it as a dependency :-)
That said, I know Test::More isn't core, yet all my tests use that without declaring it, so maybe it would work.
[snip] Erm... Test::More has been core since 5.007003 Adrian
Date: December 31, 2006
From: Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx>
In-reply-to:
<2DCE933C-DA08-4D26-9A6E-F0D08530B9E3@xxxxxxxxxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx> <2DCE933C-DA08-4D26-9A6E-F0D08530B9E3@xxxxxxxxxxxxxx>
On Sun, Dec 31, 2006 at 04:21:21PM +0000, Adrian Howard wrote:
> Personally I find reading something like:
>
> lives_and { is $dt->answer, 42 } 'correct answer found';
>
> a lot easier to read and maintain than something like:
>
> my $answer = eval { $dt->answer };
> if ( my $e = $@ ) {
> fail "correct answer found";
> diag "died unexpectedly ($e)";
> } else {
> is $answer, 42, 'correct answer found';
> }
Oh yes, I shall agree with that. It was more a matter of trading off
that advantage against the cost of an extra dependency.
> T::E is also a
> moderately popular module so you will find it already installed in
> lots of places.
Well, that's the thing. I had to install it on the test boxes I'm
currently developing the code on - I didn't want to upload it to PAUSE
then find that all the automatic test boxes all fail it because of a
missing Test:: module.
That said, I know Test::More isn't core, yet all my tests use that
without declaring it, so maybe it would work.
I guess the core problem here is really a lack of build-time dependency
tracking in EU::MM; which I have suggested here:
http://rt.cpan.org//Ticket/Display.html?id=24159
Maybe I might even get around to fixing it...
--
Paul "LeoNerd" Evans
leonerd@xxxxxxxxxxxxxx
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Date: December 31, 2006
From: Adrian Howard <adrianh@xxxxxxxxxxxxxx>
In-reply-to:
<20061231121451.GD1044@xxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx> <20061231035916.GD10523@klangraum
> <5d4beb40612302128s2a379dd4hdca1873a8a9b63a@xxxxxxxxxxxxxx> <20061231114514.GI10523@klangraum
> <20061231121451.GD1044@xxxxxxx>
On 31 Dec 2006, at 12:14, Paul LeoNerd Evans wrote:
On Sun, Dec 31, 2006 at 12:45:14PM +0100, A. Pagaltzis wrote:* David Golden <xdaveg@xxxxxxxxx> [2006-12-31 11:30]:Test::Exception depends on Sub::Uplevel, which overrides CORE::GLOBAL::caller, so there is already some deep magic that I'm not sure should get rolled into Test::More.Ouch. OK, I was thinking of the older implementation that was quite straightforward Perl (though also buggy, according to the Changelog). So much for that.It does use Sub::Uplevel but I can't really see why. It seems only used by way of hiding the internal functions from caller(), perhaps to neatenup error messages or the like...?
[snip]The problem cases that Sub::UpLevel deals with are where the stringified exceptions include stack traces with arguments (e.g. Carp). For an exception of this type doing something like:
throws_ok { foo() } qr/Foo/;
would always pass since "qr/Foo/" would appear as an argument to
throws_ok() in the first stack frame and match the regex.
I can't see why a simple implementation inline in the test script (see some of my other mails) would need to use that, as long as the user was aware of the extra lines.
Should work fine. dies_ok only uses it for the sake of the common code. Adrian
Date: December 31, 2006
From: Adrian Howard <adrianh@xxxxxxxxxxxxxx>
In-reply-to:
<20061231000333.GA1044@xxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx>
On 31 Dec 2006, at 00:03, Paul LeoNerd Evans wrote:
I recently stumbled upon Test::Exception, and wondered if it might makemy test scripts any better.. So far I'm struggling to see any benefit, for quite a lot of cost.
[ some options snipped ]
So, a lot more code, to achieve the same end result... Plus, I'm now inthe situation where if Test::Exception isn't installed, the test won't be run at all.Have I missed something here? Does Test::Exception provide me with somegreater functionallity I haven't yet observed? Or should I just not bother using it?
You are, of course, free to not use it. I won't mind - honest :-)For me the advantages are more intention revealing test code, and reasonably cleanly dealing with some of odd things people do with exceptions.
Personally I find reading something like:
lives_and { is $dt->answer, 42 } 'correct answer found';
a lot easier to read and maintain than something like:
my $answer = eval { $dt->answer };
if ( my $e = $@ ) {
fail "correct answer found";
diag "died unexpectedly ($e)";
} else {
is $answer, 42, 'correct answer found';
}
Personally my approach is to make "functional" test modules (as
opposed to things like Test::Perl::Critic and friends that are really
only of interest to me as a developer) proper dependencies and pull
them in. For me the benefits of having the module to hand outweigh
the disadvantages of adding an extra dependency. T::E is also a
moderately popular module so you will find it already installed in
lots of places.
As ever YMMV.(the other option that's not been mentioned would be to include T::E and its dependencies with the distribution. Not something I'd recommend personally - just mentioned for completeness)
Cheers, Adrian
Date: December 31, 2006
From: Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx>
In-reply-to:
<875029960612310447p6a6ba750k7b4e35176ba0b1d8@xxxxxxxxxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx> <875029960612301813s134fa302hd682ca55582f8553@xxxxxxxxxxxxxx> <20061231111449.GB1044@xxxxxxx> <875029960612310447p6a6ba750k7b4e35176ba0b1d8@xxxxxxxxxxxxxx>
On Sun, Dec 31, 2006 at 12:47:28PM +0000, Fergal Daly wrote: > I use whatever test modules I feel like (for example I always use > Test::NoWarnings) and the same machines test my modules without > problems. The automatic testing tools install whatever deps are > necessary (assuming they're listed as deps in Makefile.PL). Are you > seeing brokenness or are you just expecting it? Well, that's partly the thing. I know they'll install any real deps that are required, but there isn't currently a way to make ExtUtils::MakeMaker have build-time dependencies that don't turn into runtime dependencies. I have in fact reported a bug/wishlist/"I'll patch it if you think this is good" ticket on it: http://rt.cpan.org//Ticket/Display.html?id=24159 but until that's fixed, I'd rather not declare Test::Exception as a runtime dependency of my module. -- Paul "LeoNerd" Evans leonerd@xxxxxxxxxxxxxx ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Date: December 31, 2006
From: "Fergal Daly" <fergal@xxxxxxxxxxxx>
In-reply-to:
<20061231111449.GB1044@xxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx> <875029960612301813s134fa302hd682ca55582f8553@xxxxxxxxxxxxxx> <20061231111449.GB1044@xxxxxxx>
On 31/12/06, Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx> wrote:
On Sun, Dec 31, 2006 at 02:13:47AM +0000, Fergal Daly wrote: > I think the code about should die comlaining about dies_ok() is > unknown. So you need to do even more. No it doesn't... This is one of those things about perl - code that looks like a function call is never checked to see if the function exists until runtime: #!/usr/bin/perl use warnings; use strict; print "Here I have started running now\n"; foobarsplot(); ^-- won't complain until runtime. That's what gave me the motivation to write B::LintSubs, by the way: http://search.cpan.org/~pevans/B-LintSubs-0.02/
I just forgot that SKIP actually doesn't execute the code (I was thinking it just marked the test results as to be ignored).
> Don't you get the same problem with any non-standard test module? Yes; but Test::More seems to be installed as part of whatever the testing core is on various things that automatically test my CPAN modules. I note whenever I upload something, lots of machines around the world manage to automatically test it. I use Test::More everywhere and they can cope.
I use whatever test modules I feel like (for example I always use Test::NoWarnings) and the same machines test my modules without problems. The automatic testing tools install whatever deps are necessary (assuming they're listed as deps in Makefile.PL). Are you seeing brokenness or are you just expecting it? F
> If you alread yhave some CPAN dependencies then adding another for > testing is perfecctly reasonable. It would be nice if the various CPAN > tools could understand the difference between a runtime dependecy and > a test-time one though, EU::MM can't, but I believe Module::Build can. That said, the consensus on #perl/Freenode is that the latter isn't really ready yet, so just use the former. Ho hum.. -- Paul "LeoNerd" Evans leonerd@xxxxxxxxxxxxxx ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFl5upqRXzCRLr5iQRAh+xAKCL/rKxP/QmZc/4lxnFeQyDKxNEqACfZjoU EODl67ZC0bW/jCJvmmUMGIw= =1ffY -----END PGP SIGNATURE-----
Date: December 31, 2006
From: Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx>
In-reply-to:
<20061231114514.GI10523@klangraum
>
References:
<20061231000333.GA1044@xxxxxxx> <20061231035916.GD10523@klangraum
> <5d4beb40612302128s2a379dd4hdca1873a8a9b63a@xxxxxxxxxxxxxx> <20061231114514.GI10523@klangraum
>
On Sun, Dec 31, 2006 at 12:45:14PM +0100, A. Pagaltzis wrote: > * David Golden <xdaveg@xxxxxxxxx> [2006-12-31 11:30]: > > Test::Exception depends on Sub::Uplevel, which overrides > > CORE::GLOBAL::caller, so there is already some deep magic that > > I'm not sure should get rolled into Test::More. > > Ouch. OK, I was thinking of the older implementation that was > quite straightforward Perl (though also buggy, according to the > Changelog). So much for that. It does use Sub::Uplevel but I can't really see why. It seems only used by way of hiding the internal functions from caller(), perhaps to neaten up error messages or the like...? I can't see why a simple implementation inline in the test script (see some of my other mails) would need to use that, as long as the user was aware of the extra lines. -- Paul "LeoNerd" Evans leonerd@xxxxxxxxxxxxxx ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Date: December 31, 2006
From: "A. Pagaltzis" <pagaltzis@xxxxxx>
In-reply-to:
<20061231111449.GB1044@xxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx> <875029960612301813s134fa302hd682ca55582f8553@xxxxxxxxxxxxxx> <20061231111449.GB1044@xxxxxxx>
* Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx> [2006-12-31 12:20]: > On Sun, Dec 31, 2006 at 02:13:47AM +0000, Fergal Daly wrote: > > If you alread yhave some CPAN dependencies then adding > > another for testing is perfecctly reasonable. It would be > > nice if the various CPAN tools could understand the > > difference between a runtime dependecy and a test-time one > > though, > > EU::MM can't, but I believe Module::Build can. That said, the > consensus on #perl/Freenode is that the latter isn't really > ready yet, so just use the former. Ho hum.. I do use M::B, so I can declare the dependencies precisely; then I use M::B::Compat to provide a traditional Makefile.PL, in which the dependencies are of course all mashed together. Ho hum. But hey, my Build.PL’s there for those who aren’t afraid to stray from defaults. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Date: December 31, 2006
From: "A. Pagaltzis" <pagaltzis@xxxxxx>
In-reply-to:
<20061231113432.GC1044@xxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx> <20061231035916.GD10523@klangraum
> <20061231113432.GC1044@xxxxxxx>
* Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx> [2006-12-31 12:35]:
> On Sun, Dec 31, 2006 at 04:59:16AM +0100, A. Pagaltzis wrote:
> > You’re not using enough magic. If you *really* want to make
> > your tests run even if Test::Exception isn’t installed, stick
> > the test in a BEGIN block that conditionally installs a
> > `dies_ok` stub. Something like
> >
> > BEGIN {
> > unless( eval "use Test::Exception; 1" ) {
> > *dies_ok = sub { SKIP: {
> > skip "Need Test::Exception for: $_[1]", 1;
> > } };
> > }
> > }
> >
> > Something like that anyway; untested.
>
> Well, that looks a good start; but maybe we can go one better:
>
> BEGIN {
> unless( eval "use Test::Exception; 1" ) {
> *dies_ok = sub(&$) {
> my ( $code, $msg ) = @_;
> eval { $code->(); 1 } and fail( $msg );
> };
> }
> }
>
> Is this "as good" as T::E's version?
T::E performs quite a bit more magic than what you have there.
I have no idea if it’s actually necessary or just an artifact of
making the code module-packagable.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Date: December 31, 2006
From: "A. Pagaltzis" <pagaltzis@xxxxxx>
In-reply-to:
<5d4beb40612302128s2a379dd4hdca1873a8a9b63a@xxxxxxxxxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx> <20061231035916.GD10523@klangraum
> <5d4beb40612302128s2a379dd4hdca1873a8a9b63a@xxxxxxxxxxxxxx>
* David Golden <xdaveg@xxxxxxxxx> [2006-12-31 11:30]: > Test::Exception depends on Sub::Uplevel, which overrides > CORE::GLOBAL::caller, so there is already some deep magic that > I'm not sure should get rolled into Test::More. Ouch. OK, I was thinking of the older implementation that was quite straightforward Perl (though also buggy, according to the Changelog). So much for that. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Date: December 31, 2006
From: Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx>
In-reply-to:
<20061231035916.GD10523@klangraum
>
References:
<20061231000333.GA1044@xxxxxxx> <20061231035916.GD10523@klangraum
>
On Sun, Dec 31, 2006 at 04:59:16AM +0100, A. Pagaltzis wrote:
> You’re not using enough magic. If you *really* want to make your
> tests run even if Test::Exception isn’t installed, stick the test
> in a BEGIN block that conditionally installs a `dies_ok` stub.
> Something like
>
> BEGIN {
> unless( eval "use Test::Exception; 1" ) {
> *dies_ok = sub { SKIP: {
> skip "Need Test::Exception for: $_[1]", 1;
> } };
> }
> }
>
> Something like that anyway; untested.
Well, that looks a good start; but maybe we can go one better:
BEGIN {
unless( eval "use Test::Exception; 1" ) {
*dies_ok = sub(&$) {
my ( $code, $msg ) = @_;
eval { $code->(); 1 } and fail( $msg );
};
}
}
Is this "as good" as T::E's version?
--
Paul "LeoNerd" Evans
leonerd@xxxxxxxxxxxxxx
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Date: December 31, 2006
From: Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx>
In-reply-to:
<875029960612301813s134fa302hd682ca55582f8553@xxxxxxxxxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx> <875029960612301813s134fa302hd682ca55582f8553@xxxxxxxxxxxxxx>
On Sun, Dec 31, 2006 at 02:13:47AM +0000, Fergal Daly wrote: > I think the code about should die comlaining about dies_ok() is > unknown. So you need to do even more. No it doesn't... This is one of those things about perl - code that looks like a function call is never checked to see if the function exists until runtime: #!/usr/bin/perl use warnings; use strict; print "Here I have started running now\n"; foobarsplot(); ^-- won't complain until runtime. That's what gave me the motivation to write B::LintSubs, by the way: http://search.cpan.org/~pevans/B-LintSubs-0.02/ > Don't you get the same problem with any non-standard test module? Yes; but Test::More seems to be installed as part of whatever the testing core is on various things that automatically test my CPAN modules. I note whenever I upload something, lots of machines around the world manage to automatically test it. I use Test::More everywhere and they can cope. > If you alread yhave some CPAN dependencies then adding another for > testing is perfecctly reasonable. It would be nice if the various CPAN > tools could understand the difference between a runtime dependecy and > a test-time one though, EU::MM can't, but I believe Module::Build can. That said, the consensus on #perl/Freenode is that the latter isn't really ready yet, so just use the former. Ho hum.. -- Paul "LeoNerd" Evans leonerd@xxxxxxxxxxxxxx ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Date: December 31, 2006
From: "Fergal Daly" <fergal@xxxxxxxxxxxx>
In-reply-to:
<20061231000333.GA1044@xxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx>
On 31/12/06, Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx> wrote:
I recently stumbled upon Test::Exception, and wondered if it might make
my test scripts any better.. So far I'm struggling to see any benefit,
for quite a lot of cost.
Without using this module, my tests look like:
eval { code() };
ok( $@, 'An exception is raised' );
(and possibly either of)
like( $@, qr/some string match/, 'Exception type' );
(or)
ok( $@->isa( "Thing" ), 'Exception type' );
(to check the type)
Whereas, if I want to use the module, I have to first note that it isn't
standard install, so I should start the test with something like:
eval { require Test::Exception; import Test::Exception; };
my $can_test_exception = $@ ? 0 : 1;
Then each test that might use it should be:
SKIP: {
skip "No Test::Exception", 1 unless $can_test_exception;
dies_ok( sub { code() },
'An exception is raised' );
}
So, a lot more code, to achieve the same end result... Plus, I'm now in
the situation where if Test::Exception isn't installed, the test won't
be run at all.
I think the code about should die comlaining about dies_ok() is unknown. So you need to do even more.
Have I missed something here? Does Test::Exception provide me with some greater functionallity I haven't yet observed? Or should I just not bother using it?
Don't you get the same problem with any non-standard test module? If you alread yhave some CPAN dependencies then adding another for testing is perfecctly reasonable. It would be nice if the various CPAN tools could understand the difference between a runtime dependecy and a test-time one though, F
Date: December 31, 2006
From: "David Golden" <xdaveg@xxxxxxxxx>
In-reply-to:
<20061231035916.GD10523@klangraum
>
References:
<20061231000333.GA1044@xxxxxxx> <20061231035916.GD10523@klangraum
>
On 12/30/06, A. Pagaltzis <pagaltzis@xxxxxx> wrote:
(Actually, I'd argue that it should be merged into Test::More someday… too cheap in terms of code complexity and at the same time too useful to make people decide whether they want a new dependency just to get it.)
Possibly. Test::Exception depends on Sub::Uplevel, which overrides CORE::GLOBAL::caller, so there is already some deep magic that I'm not sure should get rolled into Test::More. David
Date: December 31, 2006
From: "David Golden" <xdaveg@xxxxxxxxx>
In-reply-to:
<Pine.LNX.4.64.0612301033590.4740@xxxxxxxx>
References:
<Pine.LNX.4.64.0612301033590.4740@xxxxxxxx>
On 12/30/06, Dave Rolsky <autarch@xxxxxxxx> wrote:
So I've been working on this thing for a while. What it does it is similar to parts of Alzabo, but it's new code, so it needs a new name. In the future I plan to write code that uses these modules as part of a OO-RDBMS mapper (yes, I know, another one), so I may have something like Q::Object or Q::Class. So does anyone have any thoughts on a distro name to replace Q?
What makes this different/better than Alazabo? What would make its OORDBMS different/better than others? Whatever that is, it might make sense to look to that for a name. Regards, David Golden
Date: December 31, 2006
From: "A. Pagaltzis" <pagaltzis@xxxxxx>
In-reply-to:
<20061231000333.GA1044@xxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx>
* Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx> [2006-12-31 01:05]:
> Whereas, if I want to use the module, I have to first note that
> it isn't standard install, so I should start the test with
> something like:
>
> eval { require Test::Exception; import Test::Exception; };
> my $can_test_exception = $@ ? 0 : 1;
>
> Then each test that might use it should be:
>
> SKIP: {
> skip "No Test::Exception", 1 unless $can_test_exception;
>
> dies_ok( sub { code() },
> 'An exception is raised' );
> }
You’re not using enough magic. If you *really* want to make your
tests run even if Test::Exception isn’t installed, stick the test
in a BEGIN block that conditionally installs a `dies_ok` stub.
Something like
BEGIN {
unless( eval "use Test::Exception; 1" ) {
*dies_ok = sub { SKIP: {
skip "Need Test::Exception for: $_[1]", 1;
} };
}
}
Something like that anyway; untested.
> So, a lot more code, to achieve the same end result... Plus,
> I'm now in the situation where if Test::Exception isn't
> installed, the test won't be run at all.
Well yes. The same can be said of relying on *any* module
whatsoever; you can always “just” reimplement the functionality
in your code and not have to rely on the module.
You don’t need Test::Exception to test exception-throwing, but if
you need to test a lot of that, then Test::Exception will make
your tests a *whole* lot more readable.
(Actually, I’d argue that it should be merged into Test::More
someday… too cheap in terms of code complexity and at the same
time too useful to make people decide whether they want a new
dependency just to get it.)
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Date: December 31, 2006
From: "Joshua ben Jore" <twists@xxxxxxxxx>
In-reply-to:
<20061231000333.GA1044@xxxxxxx>
References:
<20061231000333.GA1044@xxxxxxx>
On 12/30/06, Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx> wrote:
I recently stumbled upon Test::Exception, and wondered if it might make
my test scripts any better.. So far I'm struggling to see any benefit,
for quite a lot of cost.
Without using this module, my tests look like:
eval { code() };
ok( $@, 'An exception is raised' );
This is a buggy test. $@ can be cleared by destructors firing during
the end of the eval. You must test that the return value of eval is
true to be unambiguously correct.
my $ok = eval { code(); 1 };
my $e = $@;
ok( ! $ok, 'An exception was raised' );
like( $e, qr/.../, 'Exception was ...' );
like( $@, qr/some string match/, 'Exception type' );
You should expect $@ to be cleared during anything that might conceivably call perl code. This includes using any operators other than assignment. That includes comparison and boolean tests.
ok( $@->isa( "Thing" ), 'Exception type' );
Same problem. Copy $@ away before examining it so it won't be overwritten under your feet.
Have I missed something here? Does Test::Exception provide me with some greater functionallity I haven't yet observed? Or should I just not bother using it?
It provides you better verbs so your tests are talking about a task and not required to perform the task. Your tests are still buggy regardless of whether you use Test::Exception. Josh
Date: December 31, 2006
From: Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx>
I recently stumbled upon Test::Exception, and wondered if it might make
my test scripts any better.. So far I'm struggling to see any benefit,
for quite a lot of cost.
Without using this module, my tests look like:
eval { code() };
ok( $@, 'An exception is raised' );
(and possibly either of)
like( $@, qr/some string match/, 'Exception type' );
(or)
ok( $@->isa( "Thing" ), 'Exception type' );
(to check the type)
Whereas, if I want to use the module, I have to first note that it isn't
standard install, so I should start the test with something like:
eval { require Test::Exception; import Test::Exception; };
my $can_test_exception = $@ ? 0 : 1;
Then each test that might use it should be:
SKIP: {
skip "No Test::Exception", 1 unless $can_test_exception;
dies_ok( sub { code() },
'An exception is raised' );
}
So, a lot more code, to achieve the same end result... Plus, I'm now in
the situation where if Test::Exception isn't installed, the test won't
be run at all.
Have I missed something here? Does Test::Exception provide me with some
greater functionallity I haven't yet observed? Or should I just not
bother using it?
--
Paul "LeoNerd" Evans
leonerd@xxxxxxxxxxxxxx
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Date: December 30, 2006
From: Dave Rolsky <autarch@xxxxxxxx>
For now I've been calling it "Q" (for Query), but that's not a very CPAN-friendly name.
There are modules for representing a database schema, so I have Q::Schema, Q::Table, Q::Column, Q::FK, etc.
There are also modules for using those objects to generate SQL, so I have Q::Query, Q::Query::Select, Q::Query::Update, etc.
In the future I plan to write code that uses these modules as part of a OO-RDBMS mapper (yes, I know, another one), so I may have something like Q::Object or Q::Class.
So does anyone have any thoughts on a distro name to replace Q? -dave /*=================================================== VegGuide.Org www.BookIRead.com Your guide to all that's veg. My book blog ===================================================*/
Date: December 28, 2006
From: "A. Pagaltzis" <pagaltzis@xxxxxx>
In-reply-to:
<200612271948.34162.ggrabler@xxxxxxxxx>
References:
<934f64a20612271035j7fe12030j576e02532531bfea@xxxxxxxxxxxxxx> <200612271948.34162.ggrabler@xxxxxxxxx>
* Georg Grabler <ggrabler@xxxxxxxxx> [2006-12-27 19:50]: > i guess this would be included in Bundle::Gnome2. Doubt it. Not exactly a prereq for running GNOME apps or even just a common dependency. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Date: December 27, 2006
From: Georg Grabler <ggrabler@xxxxxxxxx>
In-reply-to:
<934f64a20612271035j7fe12030j576e02532531bfea@xxxxxxxxxxxxxx>
References:
<934f64a20612271035j7fe12030j576e02532531bfea@xxxxxxxxxxxxxx>
Not that i know, i guess this would be included in Bundle::Gnome2. On Wednesday 27 December 2006 19:35, David Nicol wrote: > Has anyone written a perly interface to the gnome planner file format? > It's XML so it's going to be basically a breeze, but I'd rather re-use > someone else's tool if available.
Date: December 27, 2006
From: "David Nicol" <davidnicol@xxxxxxxxx>
Has anyone written a perly interface to the gnome planner file format? It's XML so it's going to be basically a breeze, but I'd rather re-use someone else's tool if available.
Date: December 18, 2006
From: Andy Armstrong <andy@xxxxxxxxxx>
I've just been playing with a Google Co-op search of CPAN: http://www.hexten.net/2006/12/18/search-cpan-with-googleIt certainly doesn't beat search.cpan.org all the time - but for some queries the fact that the Google search goes deeper pays off.
CPAN's big enough that the quality of the search interface is critical - for most people it's the primary interface. I've certainly had cases where the search has missed modules that I've subsequently discovered indirectly - mentioned on a mailing list or in someone else's code.
I imagine it might be politically sensitive to add a Google powered search to search.cpan.org - but I'd certainly have found it useful in the past.
-- Andy Armstrong, hexten.net
Date: December 17, 2006
From: James E Keenan <jkeen_via_google@xxxxxxxxx>
In-reply-to:
<45842E61.3080802@xxxxxxxxx>
References:
<457C86A8.5000701@xxxxxxxxx> <4583160C.2020205@xxxxxxxxxxxx> <458427AF.1050909@xxxxxxxxx> <45842E61.3080802@xxxxxxxxx>
James E Keenan wrote:
CPAN appears to be having some problem accepting uploads right now. You can find v0.06 at http://thenceforward.net/perl/modules/List-RewriteElements/List-RewriteElements-0.06.tar.gz
The CPAN hiccups cleared up after a couple of hours, so you can now get List-RewriteElements's latest version from CPAN.
Date: December 17, 2006
From: Andy Armstrong <andy@xxxxxxxxxx>
In-reply-to:
<458429DB.9080604@xxxxxxxxx>
References:
<457C86A8.5000701@xxxxxxxxx> <4583160C.2020205@xxxxxxxxxxxx> <E2A6130A-288D-438C-BFD9-6380C0260457@xxxxxxxxxx> <458429DB.9080604@xxxxxxxxx>
On 16 Dec 2006, at 17:16, James E Keenan wrote:
So, while List::RewriteElements can certainly be used to transform elements of an array, a module name like 'Array::RewriteElements' would be overly narrow.
Indeed. I was suggesting that List:: was also too narrow for the same reason.
-- Andy Armstrong, hexten.net
Date: December 16, 2006
From: James E Keenan <jkeen_via_google@xxxxxxxxx>
In-reply-to:
<458427AF.1050909@xxxxxxxxx>
References:
<457C86A8.5000701@xxxxxxxxx> <4583160C.2020205@xxxxxxxxxxxx> <458427AF.1050909@xxxxxxxxx>
James E Keenan wrote:
I've just uploaded v0.06 to CPAN.
CPAN appears to be having some problem accepting uploads right now. You can find v0.06 at http://thenceforward.net/perl/modules/List-RewriteElements/List-RewriteElements-0.06.tar.gz
jimk
Date: December 16, 2006
From: James E Keenan <jkeen_via_google@xxxxxxxxx>
In-reply-to:
<E2A6130A-288D-438C-BFD9-6380C0260457@xxxxxxxxxx>
References:
<457C86A8.5000701@xxxxxxxxx> <4583160C.2020205@xxxxxxxxxxxx> <E2A6130A-288D-438C-BFD9-6380C0260457@xxxxxxxxxx>
Andy Armstrong wrote:
On 15 Dec 2006, at 21:39, David Landgren wrote:I vote for Transform. Possibly more Data than List but I wouldn't argue it for long.List:: has the connotation doing things to Perl arrays I think.
In Perl an array is a data structure which can hold a list, where a list is understood as an ordered set of elements.
While an array is the most frequently used way of holding and manipulating a list, it's often just a means to an end. The result of that manipulation may or may not be -- or be represented by -- a Perl array.
In the case of List::RewriteElements, the result of the rewriting of a particular element in a list is immediately printed to STDOUT or to a file. It is not held in an array.
So, while List::RewriteElements can certainly be used to transform elements of an array, a module name like 'Array::RewriteElements' would be overly narrow.
I suspect that people will most frequently use this module to transform data records held in a flat file, in which case we treat the individual records within the file as elements of a list.
jimk
Date: December 16, 2006
From: James E Keenan <jkeen_via_google@xxxxxxxxx>
In-reply-to:
<4583160C.2020205@xxxxxxxxxxxx>
References:
<457C86A8.5000701@xxxxxxxxx> <4583160C.2020205@xxxxxxxxxxxx>
David Landgren wrote:
Question: (?:how)? does your module deal with positional records (that is, fixed width fields)? as opposed to delimited records?
Contradicting my earlier doubts about this, List::RewriteElements does can be used to rewrite elements of fixed-width records.
I've just uploaded v0.06 to CPAN. The FAQ provides an example of such use and t/07_fixed_width.t tests the functionality. Thanks for the suggestion, David!
jimk
Date: December 16, 2006
From: Andy Armstrong <andy@xxxxxxxxxx>
In-reply-to:
<4583160C.2020205@xxxxxxxxxxxx>
References:
<457C86A8.5000701@xxxxxxxxx> <4583160C.2020205@xxxxxxxxxxxx>
On 15 Dec 2006, at 21:39, David Landgren wrote:
I vote for Transform. Possibly more Data than List but I wouldn't argue it for long.
List:: has the connotation doing things to Perl arrays I think. -- Andy Armstrong, hexten.net
Date: December 16, 2006
From: James E Keenan <jkeen_via_google@xxxxxxxxx>
In-reply-to:
<45835947.9020003@xxxxxxxxx>
References:
<457C86A8.5000701@xxxxxxxxx> <4583160C.2020205@xxxxxxxxxxxx> <45835947.9020003@xxxxxxxxx>
James E Keenan wrote:
David Landgren wrote:
Question: (?:how)? does your module deal with positional records (that is, fixed width fields)?It doesn't (at least not yet).
I think I'm wrong.Thinking a bit more about the code, I suspect there's no inherent reason it can't handle fixed-width records.
I'm going to re-read Chapter 7.1 of Dave Cross' "Data Munging with Perl" and see what I can come up with.
jimk
Date: December 16, 2006
From: James E Keenan <jkeen_via_google@xxxxxxxxx>
In-reply-to:
<4583160C.2020205@xxxxxxxxxxxx>
References:
<457C86A8.5000701@xxxxxxxxx> <4583160C.2020205@xxxxxxxxxxxx>
David Landgren wrote:
James E Keenan did write:I am preparing a module for CPAN tentatively titled List::RewriteElements. Given a list of data records, typically in the form of a flat file, optionally containing a header row, I am frequently asked to generate a new file in which each record is transformed according to some rule or deleted according to some criterion. This module makes it easier for me to do so.oooh, me too. I wish you had published this two months ago, because that's all I've been doing recently.
And, oooh, I wish you had gotten back to me two days ago. I finally finished all the tests, docs, etc., and since I hadn't had any other feedback, I went ahead and uploaded it to CPAN under the name List::RewriteElements. http://search.cpan.org/dist/List-RewriteElements/
[snip]Question: (?:how)? does your module deal with positional records (that is, fixed width fields)?
It doesn't (at least not yet -- to quote Andy, "patches welcome"). That's only because I have to deal with delimited records far more than fixed widths.
Perhaps in a future version! Thanks for taking a look at it. jimk
Date: December 15, 2006
From: David Landgren <david@xxxxxxxxxxxx>
In-reply-to:
<457C86A8.5000701@xxxxxxxxx>
References:
<457C86A8.5000701@xxxxxxxxx>
James E Keenan did write:
I am preparing a module for CPAN tentatively titled List::RewriteElements. Given a list of data records, typically in the form of a flat file, optionally containing a header row, I am frequently asked to generate a new file in which each record is transformed according to some rule or deleted according to some criterion. This module makes it easier for me to do so.
oooh, me too. I wish you had published this two months ago, because that's all I've been doing recently.
I have not yet implemented all of the module's functionality (as specified in the documentation), but what is present has high test coverage. I am wondering if people have any better suggestions for a name for the module. I've thought of things like List::Transform, List::TransformRecords, etc.
I vote for Transform. Possibly more Data than List but I wouldn't argue it for long.
Question: (?:how)? does your module deal with positional records (that is, fixed width fields)? as opposed to delimited records?
For instance, I sometimes want to apply a hash lookup to the fourth field of ten, to map values from one system to another.
David -- "It's overkill of course, but you can never have too much overkill."
Date: December 13, 2006
From: Elizabeth Mattijsen <liz@xxxxxxxxxx>
In-reply-to:
<457ED45F.5070407@xxxxxxxxxxxx>
References:
<457ED45F.5070407@xxxxxxxxxxxx>
At 5:10 PM +0100 12/12/06, David Landgren wrote:
I've been playing around with Sieve, a language for filtering incoming messages. It's rather hateful (but that's a topic for another list), and I serendipitiously encountered Mail::Sieve on a CPAN search. So I thought I'd take a look. Except that it's not there.It appears as a registered module, but the author appears to have pulled it (I haven't checked backpan, as I'm not that interested).http://search.cpan.org/~brong/Should the distribution be removed from the module list? Since it doesn't really exist any more. Either that, or search.cpan.org should ignore registered modules for which there is no published module.
FWIW, I have a set of registered modules on CPAN that I pulled from CPAN some time ago already:
NexTrieve NexTrieve::Collection NexTrieve::Collection::Index NexTrieve::DBI NexTrieve::Daemon NexTrieve::Docseq NexTrieve::Document NexTrieve::HTML NexTrieve::Hitlist NexTrieve::Hitlist::Hit NexTrieve::Index NexTrieve::MIME NexTrieve::Mbox NexTrieve::Message NexTrieve::Overview NexTrieve::PDF NexTrieve::Query NexTrieve::Querylog NexTrieve::RFC822 NexTrieve::Replay NexTrieve::Resource NexTrieve::Search NexTrieve::Targz NexTrieve::UTF8 All of these can be unregistered as far as I'm concerned. Liz
Date: December 13, 2006
From: Ken Williams <ken@xxxxxxxxxxxxx>
In-reply-to:
<20061212203009.0d522a52@xxxxxxx>
References:
<457ED45F.5070407@xxxxxxxxxxxx> <73ddeb6c0612120821v534c2080l1ab427358d643ddf@xxxxxxxxxxxxxx> <20061212203009.0d522a52@xxxxxxx>
On Dec 12, 2006, at 2:30 PM, Paul LeoNerd Evans wrote:
all of which I currently use in some active, real-world capacity, and am quite willing to maintain in the future. Should I register all of these?What are the general opinions on registration?
Personally I think it's pretty much useless. You're "registered" as the owner of your namespaces just because you're the first person to upload something to PAUSE that uses them, so nobody can upload something in those namespaces to impersonate you.
-Ken
Date: December 12, 2006
From: Paul LeoNerd Evans <leonerd@xxxxxxxxxxxxxx>
In-reply-to:
<73ddeb6c0612120821v534c2080l1ab427358d643ddf@xxxxxxxxxxxxxx>
References:
<457ED45F.5070407@xxxxxxxxxxxx> <73ddeb6c0612120821v534c2080l1ab427358d643ddf@xxxxxxxxxxxxxx>
On Tue, 12 Dec 2006 14:21:01 -0200 "Adriano Ferreira" <a.r.ferreira@xxxxxxxxx> wrote: > I think registering modules for the ones who care is important. Speaking of which, I tried to register a module once. I filled in the form on PAUSE, and never heard anything about it since. I have quite a few modules so far http://search.cpan.org/~pevans/ all of which I currently use in some active, real-world capacity, and am quite willing to maintain in the future. Should I register all of these? What are the general opinions on registration? -- Paul "LeoNerd" Evans leonerd@xxxxxxxxxxxxxx ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
Date: December 12, 2006
From: "Adriano Ferreira" <a.r.ferreira@xxxxxxxxx>
In-reply-to:
<457ED45F.5070407@xxxxxxxxxxxx>
References:
<457ED45F.5070407@xxxxxxxxxxxx>
On 12/12/06, David Landgren <david@xxxxxxxxxxxx> wrote:
I've been playing around with Sieve, a language for filtering incoming messages. It's rather hateful (but that's a topic for another list), and I serendipitiously encountered Mail::Sieve on a CPAN search. So I thought I'd take a look. Except that it's not there. It appears as a registered module, but the author appears to have pulled it (I haven't checked backpan, as I'm not that interested). http://search.cpan.org/~brong/
According to backpan, this module has never seen the light of day.
http://backpan.perl.org/authors/id/B/BR/BRONG/
This is quite common, much more than we would like it to happen.
Should the distribution be removed from the module list? Since it doesn't really exist any more. Either that, or search.cpan.org should ignore registered modules for which there is no published module.
I think registering modules for the ones who care is important. And there could be an understandable delay between the registration and the first release. But it is just too bad if the registration is all that is done after six months or one year . Maybe the CPAN admins may rule something on this.
Date: December 12, 2006
From: David Landgren <david@xxxxxxxxxxxx>
It appears as a registered module, but the author appears to have pulled it (I haven't checked backpan, as I'm not that interested).
http://search.cpan.org/~brong/Should the distribution be removed from the module list? Since it doesn't really exist any more. Either that, or search.cpan.org should ignore registered modules for which there is no published module.
David --Much of the propaganda that passes for news in our own society is given to immobilising and pacifying people and diverting them from the idea that they can confront power. -- John Pilger
Date: December 10, 2006
From: James E Keenan <jkeen_via_google@xxxxxxxxx>
I have not yet implemented all of the module's functionality (as specified in the documentation), but what is present has high test coverage. I am wondering if people have any better suggestions for a name for the module. I've thought of things like List::Transform, List::TransformRecords, etc.
The POD is below. Should you be interested in the (as yet unfinished) code, you may download it from here: http://thenceforward.net/perl/modules/List-RewriteElements/List-RewriteElements-0.01.tar.gz
NAME
List::RewriteElements - Create a new list by rewriting elements of a
first list
SYNOPSIS
use List::RewriteElements;
Constructor
Simplest case: Input from array, output to STDOUT.
$lre = List::RewriteElements->new( {
list => \@source,
body_rule => sub {
my $record = shift;
$record .= q{additional field};
},
} );
Input from file, output to STDOUT:
$lre = List::RewriteElements->new( {
file => "/path/to/source/file",
body_rule => sub {
my $record = shift;
$record .= q{,additional field};
},
} );
Provide a different rule for the first element in the list:
$lre = List::RewriteElements->new( {
file => "/path/to/source/file",
header_rule => sub {
my $record = shift;
$record .= q{,ADDITIONAL HEADER};
},
body_rule => sub {
my $record = shift;
$record .= q{,additional field};
},
} );
Input from file, output to file:
$lre = List::RewriteElements->new( {
file => "/path/to/source/file",
body_rule => sub {
my $record = shift;
$record .= q{additional field};
},
output_file => "/path/to/output/file",
} );
To name output file, just provide a suffix to filename:
$lre = List::RewriteElements->new( {
file => "/path/to/source/file",
body_rule => sub {
my $record = shift;
$record .= q{additional field};
},
output_suffix => '.out',
} );
Provide criteria to suppress output of header or individual record.
$lre = List::RewriteElements->new( {
file => "/path/to/source/file",
header_suppress => sub {
my $record = shift;
return if $record =~ /$somepattern/;
},
body_suppress => sub {
my $record = shift;
return if $record ne 'somestring';
},
body_rule => sub {
my $record = shift;
$record .= q{additional field};
},
} );
Generate Output
$lre->generate_output();
Report Outp