Re: fetching module version from the command line
On Thu, Jul 13, 2006 at 02:29:38PM +0300, Gabor Szabo wrote: On 7/13/06, Fergal Daly [EMAIL PROTECTED] wrote: I could change it so that it tries to figure out whether it's being used for real or not and disable the END block code but that's stress and hassle. As a module author, as far as I'm concerned, if MakeMaker can figure out my version then my job is done, So the only thing that would be correct is to search @INC for the .pm file and then grep it with the same regex MakeMaker uses. That wouldn't be correct for modules that aren't the one that determine the distribution version, since other modules won't necessarily follow the one-line rule.
Re: [#59132406] perl.perl6.users MIA
On Tue, May 30, 2006 at 11:14:05PM -0700, Conrad Schneiker wrote: From: Google Help [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 30, 2006 9:31 AM [...] Thank you for your note. We've forwarded your request to our newsgroups administrator for review. Please be aware that we can only archive newsgroups that are widely distributed to Usenet. We appreciate your taking the time to write us. Regards, The Google Team Original Message Follows: From: [EMAIL PROTECTED] Subject: perl.perl6.users MIA Date: Thu, 25 May 2006 06:07:11 - When is perl.perl6.users going to start showing up with the other active perl.perl6.* groups? http://www.nntp.perl.org/group/perl.perl6.users IssueType: Bug Language: en GroupsLocale: en FYI. Best regards, Conrad Schneiker Google's stated policy is not to single out authoritative news servers for hierarchies like perl.*. Instead, they rely on enough news admins adding particular groups to allow the news to make it to whatever servers they do actually follow. And even then, they are selective about what groups they will publish. If they actually stick to this policy, the term brainless oiks comes to mind.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sun, Apr 23, 2006 at 11:01:17AM +0200, Marcus Holland-Moritz wrote:
The only thing worth mentioning is that with perl 5.003,
the following happens:
[EMAIL PROTECTED] $ perl5.003 Makefile.PL
Can't locate ExtUtils/Command.pm in @INC at Makefile.PL line 4.
BEGIN failed--compilation aborted at Makefile.PL line 4.
Yes, run-time require VERSION is almost always the wrong thing to do.
I'd suggest the following change:
--- Makefile.PL.orig2006-04-23 10:58:31.0 +0200
+++ Makefile.PL 2006-04-23 10:58:50.0 +0200
@@ -1,4 +1,4 @@
-require 5.004_05;
+BEGIN { require 5.004_05 }
use 5.004_05; would be better.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sun, Apr 23, 2006 at 11:34:12AM +0200, Marcus Holland-Moritz wrote:
On 2006-04-23, at 02:26:54 -0700, Yitzchak Scott-Thoennes wrote:
On Sun, Apr 23, 2006 at 11:01:17AM +0200, Marcus Holland-Moritz wrote:
The only thing worth mentioning is that with perl 5.003,
the following happens:
[EMAIL PROTECTED] $ perl5.003 Makefile.PL
Can't locate ExtUtils/Command.pm in @INC at Makefile.PL line 4.
BEGIN failed--compilation aborted at Makefile.PL line 4.
Yes, run-time require VERSION is almost always the wrong thing to do.
I'd suggest the following change:
--- Makefile.PL.orig2006-04-23 10:58:31.0 +0200
+++ Makefile.PL 2006-04-23 10:58:50.0 +0200
@@ -1,4 +1,4 @@
-require 5.004_05;
+BEGIN { require 5.004_05 }
use 5.004_05; would be better.
No, it wouldn't.
[EMAIL PROTECTED] $ head -n 5 Makefile.PL
use 5.004_05;
use ExtUtils::MakeMaker;
use ExtUtils::Command qw( touch rm_f );
[EMAIL PROTECTED] $ perl5.003 Makefile.PL
syntax error at Makefile.PL line 1, near use 5.004_05
Execution of Makefile.PL aborted due to compilation errors.
Which version is this? perlfunc for perl 5.003_07 claims use VERSION
works.
Re: Show-stopping Bug in Module::Install and the Havoc it Created
On Mon, Apr 03, 2006 at 10:32:12PM +1000, Adam Kennedy wrote: Yitzchak Scott-Thoennes wrote: On Sat, Mar 11, 2006 at 10:20:29AM +0100, Tels wrote: B when it breaks, end-users cannot fix the problem for themselves, they need to bug the author and he has to release a new version. (Good luck with that with sparsely maintained modules...) Last time this happened to me, I just replaced the bundled version with a newer one. No need to bug the author (though I did verify that others already had). (Since then, I've heard (but haven't confirmed) that just installing a newer MI and running Makefile.PL in the broken dist will do this automatically. Is this correct?) No, although if you delete the inc directory entirely, the Makefile.PL should latch onto the system version and go into author mode, which for the purposes of installation is almost entirely the same. Right, I meant to say deleting inc in there. HOWEVER, that requires that they NOT be using a custom extension, and than the commands used in the Makefile.PL match those in the current version of Module::Install. Good to know, thanks. The command list isn't entirely frozen yet, so while it may work, there's some risks. Once the commands have frozen, this will be a lot safer to do. Assuming someone doing this has whatever is then the newest Module::Install, are there still command list issues?
Re: Show-stopping Bug in Module::Install and the Havoc it Created
On Sat, Mar 11, 2006 at 10:20:29AM +0100, Tels wrote: B when it breaks, end-users cannot fix the problem for themselves, they need to bug the author and he has to release a new version. (Good luck with that with sparsely maintained modules...) Last time this happened to me, I just replaced the bundled version with a newer one. No need to bug the author (though I did verify that others already had). (Since then, I've heard (but haven't confirmed) that just installing a newer MI and running Makefile.PL in the broken dist will do this automatically. Is this correct?)
Where did I see this use of plan()?
I remember working with some module that had tests something like:
use Test::More;
plan tests = numtests();
...
is($foo, $bar, 'foo is bar');
sub numtests { 13 }
So that when you added a new test to the bottom, the number to modify
was right there also. Ring a bell with anyone?
Re: Request for Comments: Package testing results analysis, result codes
On Mon, Feb 20, 2006 at 11:36:27AM +, Barbie wrote:
12. System is incompatible with the package.
Linux::, Win32::, Mac:: modules. Irreconcilable differences.
Not sure how you would cover this, but point 12 seems to possibly fit.
POSIX.pm is created for the platform it's installed on. A recent package
I was testing, File::Flock (which is why I can't install PITA) attempted
to use the macro EWOULDBLOCK. Windows doesn't support this, and there
doesn't seem to be a suitable way to detect this properly.
use POSIX EWOULDBLOCK; $ok = eval { EWOULDBLOCK(); 1 }; print $ok
Re: Test Script Best-Practices
On Tue, Jan 24, 2006 at 10:25:44PM -0500, David Golden wrote: Jeffrey Thalhammer wrote: * Should a test script have a shebang? What should it be? Any flags on that? I often see -t in a shebang. One downside of the shebang, though, is that it's not particularly portable. As chromatic said, with prove it's not really necessary. (prove -t) -T or -t in a shebang tells Test::Harness or perl's TEST that perl needs to be run with that switch for the tests to test what they are supposed to test.
Re: SKIP blocks and the debugger
On Mon, Jan 09, 2006 at 07:06:08PM +1100, Kirrily Robert wrote:
Does anyone else find that SKIP: { } blocks bugger up the debugger?
I'll be happily bouncing on the n key to get to round about the
vicinity of the failing test, and then blam, it sees a skipped test
and just fast-forwards to the end.
Yup. I assume n just puts a breakpoint on the next statement, but
skip() bypasses said statement. Use a c nnn where nnn is the line
number of the statement after the skip block.
Re: How to test an overloaded @{} operator?
On Sun, Oct 02, 2005 at 01:42:05PM +0200, Torsten Schoenfeld wrote:
On Fri, 2005-09-30 at 14:40 -0700, chromatic wrote:
Does doing it in two steps work? Instead of:
is_deeply ($obj-get ('some_flags'), ['value-one', 'value-two']);
perhaps:
my @flags = @{ $obj-get( 'some_flags' ) };
is_deeply( [EMAIL PROTECTED], [ 'value-one', 'value-two' ] );
Yep, that works. As Schwern said, this is probably the only workable
solution. Looks like I'll have to change quite a few tests to use this.
If you have quite a few tests to change, you may want to just do:
is_deeply( [EMAIL PROTECTED] $obj-get( 'some_flags' ) }, [ 'value-one',
'value-two' ] );
Re: Test::Exception and XS code
On Mon, Aug 15, 2005 at 05:58:23PM +0200, S?bastien Aperghis-Tramoni wrote:
use strict;
use Test::More tests = 2;
use Test::Exception;
use Net::Pcap;
throws_ok(
sub { Net::Pcap::lookupdev() },
'/^Usage: Net::Pcap::lookupdev\(err\)/',
calling lookupdev() with no argument
);
throws_ok
{ Net::Pcap::lookupdev() }
'/^Usage: Net::Pcap::lookupdev\(err\)/',
calling lookupdev() with no argument
;
Now, if I move the use Test::Exception inside an eval-string and
execute the new script:
$ perl -W exception.pl
1..2
ok 1 - calling lookupdev() with no argument
Usage: Net::Pcap::lookupdev(err) at exception.pl line 13.
# Looks like you planned 2 tests but only ran 1.
# Looks like your test died just after 1.
Aha! The first test, which uses the normal form of throws_ok() passes,
but the second one, which uses the grep-like form, fails.
The throw_ok { ... } syntax only works because the throw_ok sub exists
and has a prototype that specifies a subref is expected; if you don't
load Test::Exception by the time the throw_ok call is compiled, it
is parsed as an indirect object call of the throw_ok method on the
object or class returned by the {} block:
$ perl -MO=Deparse,-p -we'throws_ok { Net::Pcap::lookupdev() } /^Usage:
Net::Pcap::lookupdev\(err\)/, calling lookupdev() with no argument'
BEGIN { $^W = 1; }
do {
Net::Pcap::lookupdev()
}-throws_ok('/^Usage: Net::Pcap::lookupdev(err)/', 'calling lookupdev() with no
argument');
-e syntax OK
which is perfectly valid perl, but unlikely to do what you want.
Re: [ANNOUNCE] Test::Symlink
On Tue, Jul 05, 2005 at 04:52:34PM -0700, Michael G Schwern wrote: I think you're using export_to_level() wrong. $self should really be $class for starters. And the way you're using it symlink_ok() always gets exported even if the user says use Test::Symlink (). You should be passing it: For use Test::Symlink (), no import is even called.
Re: what slow could be in Compress::Zlib? (was RE: 5.004_xx in the wild?)
On Mon, Jul 04, 2005 at 02:19:16PM +0100, Paul Marquess wrote: Whilst I'm here, when I do get around to posting a beta on CPAN, I'd prefer it doesn't get used in anger until it has bedded-in. If I give the module a version number like 2.000_00, will the CPAN shell ignore it? This is often done incorrectly. See Lperlmodstyle/Version numbering for the correct WTDI: $VERSION = 2.000_00;# let EU::MM and co. see the _ $XS_VERSION = $VERSION; # XS_VERSION has to be an actual string $VERSION = eval $VERSION; # but VERSION has to be a number Just doing $VERSION = 2.000_00 doesn't get the _ into the actual distribution version, and just doing $VERSION = 2.000_00 makes use Compress::Zlib 1.0; give a warning (because it does: 1.0 = 2.000_00 internally, and _ doesn't work in numified strings). But if you are doing a beta leading up to a 2.000 release, it should be numbered 2.000, e.g. 1.990_01. Nothing wrong with a 2.000_01 beta in preparation for a release 2.010 or whatever, though.
Re: Fwd: [EMAIL PROTECTED]: Re: fixing is_deeply]
On Sat, Jul 02, 2005 at 12:24:12AM -0700, chromatic wrote: On Sat, 2005-07-02 at 08:55 +0200, demerphq wrote: The entire basis of computer science is based around the idea that if you do the same operation to two items that are the same the end result is the same. Without this there is no predictability. No program could ever be expected to run the same way twice. Throw in some sort of external state and you have exactly that. Perhaps the name of is_deeply() is misleading, but I don't understand why the argument about whether container identity should matter to the function is so important. I expect the following test to pass: my $a = \1; my $b = \1; is_deeply( $a, $b ); Should it not? The values are the same, as are the types of the containers, but the containers are different. It should, but is_deeply( [\1, \1], [(\1) x 2] ) should fail.
Re: Fwd: [EMAIL PROTECTED]: Re: fixing is_deeply]
On Sun, Jul 03, 2005 at 01:53:45PM +0200, demerphq wrote: Actually about the only thing that seems to be really hard is doing comparison of blessed regexes with overloaded stringification. For that you need XS if you want it to work always. Now there's a sick idea. If blessed regexes with overloaded stringification actually work (that is, the actual regex is accessible to some part of the perl code), perhaps you could fix perl to use the stringification instead? Then you wouldn't have to worry about it :)
Re: Fwd: [EMAIL PROTECTED]: Re: fixing is_deeply]
On Fri, Jul 01, 2005 at 07:11:26AM +, Smylers wrote: To me 'deeply' implies recursing as deep as the data structure goes, not that there's a special rule for the top-level that's treated differently from the others. Nobody is saying is_deeply shouldn't be deep. If I understand correctly, is_deeply($a,$b) on a deep structure can still return ok if $a and $b have no references in common; it's not the specific value of the references that needs to match, it's the patterns of which parts within each of $a and $b have duplicate references, and whether those patterns match between the two. Another way of looking at it is that Schwern is saying is_deeply returns ok if the leaf values and overall structures match so long as no changes are made, while Yves is saying is_deeply should return not ok if the same change made to both ends up with different leaf values or overall structure.
Re: [EMAIL PROTECTED]: Re: fixing is_deeply]
On Fri, Jul 01, 2005 at 05:57:51PM +0200, demerphq wrote: On 7/1/05, David Landgren [EMAIL PROTECTED] wrote: demerphq wrote: it is important that this is debated outside of just the perl-qa list (its not that high traffic or visibility IMO) so I have taken the liberty of starting a thread on Perlmonks about this. It is at http://perlmonks.org/index.pl?node_id=471639. Ohh, that'll make schwern happy :) Heh. One day hopefully Schwern will get over his apparent prejudice about the place. Though at first, I had the same thought as David, I don't think Schwern really has shown a prejudice against perlmonks. He just doesn't like (with good reason) bug reports going there instead of to the module author.
Re: Fwd: [EMAIL PROTECTED]: Re: fixing is_deeply]
On Thu, Jun 30, 2005 at 05:09:39PM -0700, Michael G Schwern wrote: So, I conclude that is_deeply()'s behavior is ok and something like Test::Deep should be enhanced with an option to deal with this problem. So, am I correct in understanding that is_deeply will only notice value differences, if all the reference types are the same? And Yves's proposal is that patterns of which references are dups must also match? And that you feel an option to do it the latter way would belong in Test::Deep?
Re: Kwalitee and has_test_*
On Fri, Apr 01, 2005 at 09:00:17PM +0200, Thomas Klausner wrote: Well, kwalitee != quality. Currently, kwalitee basically only says how well-formed a distribution is. For my definition of well-formed :-) But I'm always open to suggestion etc. Since you ask... An important part of kwalitee to me is that Makefile.PL / Build.PL run successfully with stdin redirected to /dev/null (that is, that any user interaction be optional). Another is that a bug-reporting address or mechanism (e.g. clp.modules or cpan RT) be listed in the README or pod.
Re: Why a scoreboard?
On Sat, Apr 02, 2005 at 10:43:57AM -0500, Ricardo SIGNES wrote: * David A. Golden [EMAIL PROTECTED] [2005-04-02T05:27:18] Andy Lester wrote: Why is there a scoreboard? Why do we care about rankings? Why is it necessary to compare one measure to another? What purpose is being served? Why is there XP on perlmonks? Or Karma on Slashdot? Or for that matter, why do we grade students' exams (particularly, why do we often grade them on a curve)? This is not a good analogy to Kwalitee, because XP and Karma are primarily awarded by humans who can make judgements based on reason. I think you are thinking of Reputation (which a node has), not XP (which a user has). In point of fact, XP can be awarded for logging on daily, for voting on other people's nodes, or even for cash contributions, not just for others' votes on one's own nodes.
Re: Test::META
On Mon, Mar 28, 2005 at 08:35:34PM -0800, Michael G Schwern wrote: Whether things that are required for *testing* belong in build_requires really depends on whether you view testing as an integral part of the build process. This is something that is likely to depend on the *builder*, not the module author, which is, in my mind, the only argument (and a good one) for a separate test_requires. The distinction between build_recommends and and a possible test_recommends is more ambiguous. I agree with this, however I don't really see the ambiguity about test_recommends. ambiguous was the wrong word to use, sorry. I just meant that the argument for separating out test_requires is a lot stronger than for test_recommends; I'd like to see them both, but I had the impression public opinion was weighted against them, so I was trying to argue for the more important one.
Re: Test::META
On Mon, Mar 28, 2005 at 03:10:52PM -0800, Michael G Schwern wrote: On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote: That's another gripe of mine about M::B and create_makefile_pl. It puts the requires AND build_requires in the PREREQ_PM in the Makefile.PL, which I won't want; nor do I think it right for everyone. There is no build_requires or recommends equivalent in MakeMaker, nor will there be, Too bad. Seems to me it would make sense to have MakeMaker support adding the tags to META.yml. Don't see what other MakeMaker change would be needed. Maybe that presupposes something else that I see as very desirable: META.yml being (re)generated by Makefile.PL at build time, and CPAN* looking in META.yml instead of Makefile for prereqs. so putting it into PREREQ_PM is the best thing to do. That's what every MakeMaker-based module on CPAN does after all. Its better than just dropping it and having the build fail. Take Test::More for example. It's usually a build_requires and the other Test* things like Test::Strict, Apache::Test, etc are in recommends. Test probably won't run with Test::More, but skipping a few subtests based on recommends is ok. But I don't think build_requires should be a PREREQ_PM requirement at all. *scratch head* but if you don't have the modules necessary to BUILD the module (as opposed to those necessary to run it)... how are you going to build it? The distinction between PREREQ_PM and build_requires only becomes meaningful for binary (that is to say, pre-built) distributions. Such distributions should be able to rely on PREREQ_PM to indicate what other (binary) distributions are required. Whether things that are required for *testing* belong in build_requires really depends on whether you view testing as an integral part of the build process. This is something that is likely to depend on the *builder*, not the module author, which is, in my mind, the only argument (and a good one) for a separate test_requires. The distinction between build_recommends and and a possible test_recommends is more ambiguous.
Re: testing non-modules
On Sun, Mar 06, 2005 at 10:32:26AM -0800, Michael G Schwern wrote:
#!/usr/bin/perl -w
use Getopt::Long;
my %Opts;
GetOptions(\%Opts, test);
sub main {
return if $Opts{test};
...the program using the functions below...
}
main();
sub some_function { ... }
sub some_other_function { ... }
I'd make that just:
sub main {
...the program using the functions below...
}
main() unless caller;
sub some_function { ... }
sub some_other_function { ... }
Re: Hoplites: Watch for each
On Tue, Nov 04, 2003 at 07:18:34AM +0530, Abhijit Menon-Sen [EMAIL PROTECTED] wrote:
At 2003-11-03 21:35:22 +, [EMAIL PROTECTED] wrote:
Just wondering, is keys() optimized for void context?
Yes. From doop.c:Perl_do_kv:
OP *
Perl_do_kv(pTHX)
{ ...
keys = hv;
(void)hv_iterinit(keys);/* always reset iterator regardless */
if (gimme == G_VOID)
RETURN;
But be aware that it is also optimized for scalar context only if the
hash isn't tied.
