Re: Testing print failures
nadim khemir wrote:
> As for the layers of neurosis, the only anxiety is the one created by your
> own
> delusions. I see only a test like an other.
If we had infinite time and attention, yes. But we don't. And time spent
checking the return value of print and writing a complicated test for if it
fails is time that could be better spent elsewhere. I discussed this issue of
Opportunity Cost in testing last month.
http://www.nntp.perl.org/group/perl.qa/2007/12/msg9918.html
But it gets down even further. All tests are not equal. Good tests are not
about making perlcritic happy or achieving 100% test coverage or satisfying
some conviction about testing first.
Good tests catch bugs.
I don't see this test catching a real bug. Do you?
Given that the potential for these tests to catch a real bug is very low and
the work you're putting into it is very high that means the cost/benefit ratio
sucks. Your time would be better spent doing something else.
Furthermore, the infrastructure to deal with it is likely to complicate your
code. [1] Ironically, this will lead to more bugs thus defeating the whole
point of the exercise in the first place.
[1] If you REALLY want to check the return value of print and do something
useful with it, don't scatter "or die" all over the place. Hide the
complexity behind another layer of abstraction.
sub _print {
print @_ or die "...";
}
sub _print_fh {
my $fh = shift;
print {$fh} @_;
}
--
Eric: "Would you want to maintain a 5000 line Perl program?"
dha: "Why would you write a 5000 line program?"
Re: Testing print failures
On Jan 6, 2008, at 5:10 AM, Michael G Schwern wrote: nadim khemir wrote: As for the layers of neurosis, the only anxiety is the one created by your own delusions. I see only a test like an other. If we had infinite time and attention, yes. But we don't. And time spent checking the return value of print and writing a complicated test for if it fails is time that could be better spent elsewhere. I discussed this issue of Opportunity Cost in testing last month. http://www.nntp.perl.org/group/perl.qa/2007/12/msg9918.html [snip] I agree with Schwern. I wrote that Perl::Critic policy, but I deliberately made it a low severity policy and I turned print() off by default. The main reason I wrote that policy was because PBP recommended checking return values of non-throwing built-ins. One of the main arguments for checking return values is close(), which most people don't check but which can catch important failures (pipe errors, full disks, etc) In truth, I rarely use print() any more except the occasional CSTDERR "debug msg...">. I frequently use Catalyst and/or File::Slurp, so most of the output of my code is wrapped for me. Chris
Dev version numbers, warnings, XS and MakeMaker dont play nicely together.
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.
So the standard response is to do
$VERSION= eval $VERSION;
on the next line. This means that MakeMaker sees "1.23_01" but Perl
internal code for doing version checks sees "1.2301". This is all fine
and dandy with pure perl modules.
BUT, if the module is "bog standard" and uses XS this is a recipe for
a fatal error. XS_BOOT_VERSIONCHECK will compare "1.23_01" to "1.2301"
and decide that they are different versions and die.
The solution I came up with was to add
XS_VERSION=> eval MM->parse_version("Filename"),
to the WriteMakefile() call in the Makefile.PL.
But to me this is unsatisfactory. It means either duplicating code
because there is normally something like:
VERSION_FROM => "DB_File.pm"
or something like it in the WriteMakefile() arguments. Even if you use
a variable so that you end up with
$file= "DB_File.pm";
WriteMakefile(
XS_VERSION=> eval MM->parse_version($file),
VERSION_FROM => $file,
...
);
you are still duplicating effort, essentially parsing the version
twice, no biggie really in terms of CPU cycles, but somewhat
distasteful nevertheless.
I thought of fixing XS_BOOT_VERSIONCHECK so that when there is a
mismatch it checks for an underbar and then evals the string first,
but this didnt seem either fun (its C code after all) or really all
that great a solution since on older perls it wouldnt help at all.
About the best thing I can think of is making it so that the version
checked in XS_BOOT_VERSIONCHECK is ALWAYS numeric. IOW, MakeMaker
should do the eval trick itself. I think that this would work out,
but im not sure of the ramifications. (its late).
Anyway, i welcome any thoughts anyone might have on this.
Ive cross posted this because I think this is as much a Perl core dev
issue as it is a Quality Assurance issue as well as a MakeMaker issue.
I apologise if this irritates anyone.
Cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Fixed Test::Builders "regexp" detection code.
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 qr//'s. Cheers, yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Dev version numbers, warnings, XS and MakeMaker dont play nicely together.
demerphq wrote: >$VERSION= "1.23_01"; I've not seen that form, but $VERSION = 1.23_01; which of course doesn't put the underscore in the string value. This still delimits the subrevision portion, but without forcing anything else to handle the delimiter. >but this will produce warnings if you assert a required version >number, as the version isn't numeric. I've found a similar problem when attempting to include underscores in dependency version numbers in Makefile.PL. Now I never use underscores in version numbers in any context, because it's the only way to completely eliminate that class of problems. I don't think the underscore is essential; the bare number has all the right semantics, and a module author's numbering convention is generally clear from the Changes file. For my own modules I use three digits for each part of the version number, like the perl core, rather than the usual two for modules. This has the side effect of making the version number structure clearer. "1.023001" isn't difficult to tease apart. >$VERSION= eval $VERSION; Dumb approach. Now you have two different values for $VERSION depending on how much of the code gets executed (read: depending on who's looking). It's a recipe for trouble, as in the case you note with XS. >BUT, if the module is "bog standard" and uses XS this is a recipe for >a fatal error. XS_BOOT_VERSIONCHECK will compare "1.23_01" to "1.2301" >and decide that they are different versions and die. Presumably XS_BOOT_VERSIONCHECK should be stripping out underscores, and trailing zeroes too, to just compare the numerical values. Even if it operates purely on strings, this transformation is not difficult to do implicitly during the comparison. -zefram
Re: Dev version numbers, warnings, XS and MakeMaker dont play nicely together.
# from demerphq
# on Sunday 06 January 2008 16:54:
>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.
Does *any* code besides pause actually decide that "this is an alpha"?
I think that's the $dist =~ /\d\.\d+_\d/ bit around line 1474 in
mldistwatch. $dist = $self->{DIST} though and I'm getting lost in the
BIGLOOP bit of checkfornew() as to whether that's looking at the
extracted $VERSION, the META.yml $VERSION, or the bit in the filename.
(Hmm, I guess line 1487's "$dist =~ /\.pm..." implies filename.)
So, if all of the alpha-y magic is just in the filename, what would
happen if "make dist" had an "alpha" option which injected "TRIAL" into
the filename? Would that appropriately tickle the other half of that
if() at line 1474?
Or a flag in META.yml?
Then we can do away with all of the underscores?
--Eric
--
perl -e 'srand; print join(" ",sort({rand() < 0.5}
qw(sometimes it is important to be consistent)));'
---
http://scratchcomputing.com
---
Re: Dev version numbers, warnings, XS and MakeMaker dont play nicely together.
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] Specifically how much the convention sucks and replacing it with META.yml info. http://www.nntp.perl.org/group/perl.module.build/2007/12/msg1151.html -- Life is like a sewer - what you get out of it depends on what you put into it. - Tom Lehrer
Re: Fixed Test::Builders "regexp" detection code.
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 > qr//'s. Thanks. For future reference, patches to dual core modules should please go upstream to the CPAN version's bug tracker. The bug tracker for Test::Builder is here. http://rt.cpan.org/NoAuth/Bugs.html?Dist=Test-Simple or here [EMAIL PROTECTED] -- Stabbing you in the face so you don't have to.
Re: Dev version numbers, warnings, XS and MakeMaker dont play nicely together.
On Sun, January 6, 2008 4:54 pm, 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. > > So the standard response is to do > > $VERSION= eval $VERSION; > > on the next line. This means that MakeMaker sees "1.23_01" but Perl > internal code for doing version checks sees "1.2301". This is all fine and > dandy with pure perl modules. > > BUT, if the module is "bog standard" and uses XS this is a recipe for > a fatal error. XS_BOOT_VERSIONCHECK will compare "1.23_01" to "1.2301" and > decide that they are different versions and die. See perlmodstyle: > If you want to release a 'beta' or 'alpha' version of a module but > don't want CPAN.pm to list it as most recent use an '_' after the > regular version number followed by at least 2 digits, eg. 1.20_01. If > you do this, the following idiom is recommended: > > $VERSION = "1.12_01"; > $XS_VERSION = $VERSION; # only needed if you have XS code > $VERSION = eval $VERSION;
