Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
David Cantrell wrote: brian d foy wrote: <[EMAIL PROTECTED]> wrote: Hopefully it will be something like: $I::don't::bother::to::write::portable::code=1; ;-) Seriously though, I would expect things in Win32::* to only work on Windows, things in Linux::* only to work on linux, and so on for many other sections (including Mac::* where I have some modules). Portable code isn't always the goal. I want my code to be more like File::Spec, which provides a common interface to a load of platform-specific modules. That has very good coverage of bizarro OSes, and I think we'd all agree that it's an excellent example of a nice portable module. It doesn't work on RISC OS though. I suppose that this is less that RISC OS is so truly bizzare that it defies anyone to come up with platform-specific File::Spec code for it, and more a gentle nudge on your part for someone to find the tuits to do so? David -- "It's overkill of course, but you can never have too much overkill."
Re: [Module::Build] [RFC] author tests
Tyler MacDonald writes: > Chris Dolan <[EMAIL PROTECTED]> wrote: > > [lots of author test examples, including:] > > > * versionsync.t - Checks that the $VERSION is the same in all bin/* > > and *.pm files. This test is pointless after release, since it's > > already been tested before release > > * pod-coverage.t - Checks POD completeness. This test is pointless > > after release, since it's already been tested before release > > ... since there's absolutely no value in these types of tests for > anybody else except the module author, there's no real point in having > a convention, just stick 'em anywhere that the make/buildfiles will > ignore them. That premise is untrue. Some module authors sync the version numbers of all files (like Chris apparently does); some prefer only to bump the version number in a file if that particular file has changed. If I'm sending a patch to a module author I sometimes try to make it be a complete patch for the distro -- including the code, the docs, updating the change-log, and so on. And hopefully I'd run the tests before submitting the patch. So the inclusion of versionsync.t would clue me in that Chris wanted all the version numbers changing, and I could do that in the patch, thereby reducing the work Chris has to do to accept my patch and increasing the chance of me getting the feature I wanted included. Or perhaps as a user of a module I think the docs could do with a little improvement. Before submitting a patch it'd be useful to run pod-coverage.t to check that I haven't missed anything or made matters worse. Remember that this is software with the source available -- so there isn't a strict author v user distinction: any user can suddenly elect to modify the code and become an author (even if only for modifying a private version). Smylers
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
Moin, On Friday 03 February 2006 11:04, David Landgren wrote: > David Cantrell wrote: > > brian d foy wrote: > >> <[EMAIL PROTECTED]> wrote: > >>> Hopefully it will be something like: > >>> $I::don't::bother::to::write::portable::code=1; > >>> ;-) [snip] > > > > I want my code to be more like File::Spec, which provides a common > > interface to a load of platform-specific modules. That has very good > > coverage of bizarro OSes, and I think we'd all agree that it's an > > excellent example of a nice portable module. > > > > It doesn't work on RISC OS though. > > I suppose that this is less that RISC OS is so truly bizzare that it > defies anyone to come up with platform-specific File::Spec code for it, > and more a gentle nudge on your part for someone to find the tuits to > do so? Problaby just because the last guy running RISC OS has died 4 years ago. SCNR :-) Best wishes, Tels -- Signed on Fri Feb 3 11:29:15 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. This email violates EU patent EP0394160: [ ## 66% ] pgpIKJpnslcrl.pgp Description: PGP signature
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
On Fri, Feb 03, 2006 at 11:30:13AM +0100, Tels wrote: > Problaby just because the last guy running RISC OS has died 4 years ago. > SCNR :-) Well, the list is *slightly* more active than that: http://www.nntp.perl.org/group/perl.riscos Nicholas Clark
Re: TODO test paradox: better TODO test management?
* demerphq <[EMAIL PROTECTED]> [2006-02-01T03:26:55]
> And I think you've conveniently sidestepped my main point which is
> that TODO tests passing are errors. Consider you have two TODO tests,
> both of which depend on a common set of functionality. Both should
> pass or both should fail.
I just don't agree. I prefer the current model.
I defend your right to disagree, however, and support it with this idea:
strict_todo {
frobulate_ok("someone implemented frobulate()!!");
};
sub strict_todo(&) {
local $Test::Builder::OPPOSITE_WORLD = 1;
$_[0]->();
}
...where OPPOSITE_WORLD causes ok to be not ok, not ok to be ok, and cucumbers
to taste better pickled.
(I wouldn't exactly implement it that way, but you get the idea, and I bet that
a patch to provide test result reversal would not be unwelcome.)
--
rjbs
pgp3u61k8JOSm.pgp
Description: PGP signature
