Re: Getting Cruft off of CPANTS
Hi!
On Sat, Sep 23, 2006 at 03:30:06PM -0600, Randy J. Ray wrote:
I asked this once before, but rather than getting an answer, someone just
did it. There are some modules that I've deleted completely from CPAN; one
was because I renamed the top-level of the namespace (per conversation with
Adam Kennedy), and the other because someone else has a much better module
for the task (I've dropped Devel::Coverage in favor of using and maybe one
day contributing to Devel::Cover).
Should there be a clearer way for module authors to communicate this? Does
CPANTS recognize when modules disappear?
Until some months ago CPANTS had a bug (caused by bugs in the tools
used..) that prevented some dists from beeing deleted.
In your case (Devel::Coverage) the reason was that there was no new
CPANTS run since you deleted the dist from CPAN.
I did a new run, and now it's gone...
Over the last few months, CPANTS has been a great resource for me in finding
shortcomings in my distributions. Test suites and CPAN testers do their
parts, and CPANTS helps keep the bundling sane.
Nice to hear :-)
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Test::Simple: 'make test' fail with 'lock can only be used on shared values'
Hi all, I have troubles building Test-Simple-0.64 on a standard SL3 machine: perl Makefile.PL make make test several threading related tests fail, e.g.: - t/threads.Thread 1 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. Thread 2 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. Thread 3 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. Thread 4 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. Thread 5 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 1352. # Looks like your test died before it could output anything. t/threads.dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1-6 Failed 6/6 tests, 0.00% okay - Same for the tests diag, overload_threads and sort_bug. I tried to find solutions for this prob on many newsgroups, google, etc, however just found a couple of similar reports, but no solutions. Please find perl information below, I would appreciate it very much if somebody could help me here, since it's a complete show stopper for my project currently. Regards, Florian. -bash-2.05b$ perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.21-20.elsmp, archname=i386-linux-thread-multi uname='linux noswad.fnal.gov 2.4.21-20.elsmp #1 smp thu sep 2 16:47:25 cdt 2004 i686 i686 i386 gnulinux ' config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2 -g -pipe -march=i386 -mcpu=i686', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='3.2.3 20030502 (Red Hat Linux 3.2.3-52)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: MAINT18379 Built under linux Compiled at Dec 21 2005 09:27:13 @INC: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 .
Re: Test::Simple: 'make test' fail with 'lock can only be used on shared values'
On Monday 25 September 2006 02:41, Florian Scharinger wrote: I have troubles building Test-Simple-0.64 on a standard SL3 machine: perl Makefile.PL make make test several threading related tests fail, e.g.: - t/threads.Thread 1 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. Thread 2 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. Thread 3 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. Thread 4 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. Thread 5 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 1352. # Looks like your test died before it could output anything. t/threads.dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1-6 Failed 6/6 tests, 0.00% okay - Same for the tests diag, overload_threads and sort_bug. I tried to find solutions for this prob on many newsgroups, google, etc, however just found a couple of similar reports, but no solutions. Please find perl information below, I would appreciate it very much if somebody could help me here, since it's a complete show stopper for my project currently. -bash-2.05b$ perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: usethreads=define use5005threads=undef useithreads=define usemultiplicity=define Schwern may have to confirm, but I believe that threads were so broken in 5.8.0 that he decided not to support them with Test::Builder at all. Is there a possibility for you to upgrade to 5.8.8 (or at least 5.8.1)? -- c
Re: Test::Simple: 'make test' fail with 'lock can only be used on shared values'
From: Florian Scharinger I have troubles building Test-Simple-0.64 on a standard SL3 machine: snip several threading related tests fail, e.g.: snip -bash-2.05b$ perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: From the Test::Simple Changes file for 0.64_01: * 5.8.0 threads are no longer supported. There's too many bugs. 5.8.0 is an extremely buggy release and anything thread-related for that release cannot be trusted. Sorry for the bad news. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Test::Simple: 'make test' fail with 'lock can only be used on shared values'
Thx for the quick replies (also to Ovid). I'll see if we can upgrade to = 5.8.1, let's see. Florian. On Mon, 25 Sep 2006, chromatic wrote: On Monday 25 September 2006 02:41, Florian Scharinger wrote: I have troubles building Test-Simple-0.64 on a standard SL3 machine: perl Makefile.PL make make test several threading related tests fail, e.g.: - t/threads.Thread 1 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. Thread 2 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. Thread 3 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. Thread 4 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. Thread 5 terminated abnormally: lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 394. lock can only be used on shared values at /home/florian/tmp/Test-Simple-0.64/blib/lib/Test/Builder.pm line 1352. # Looks like your test died before it could output anything. t/threads.dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1-6 Failed 6/6 tests, 0.00% okay - Same for the tests diag, overload_threads and sort_bug. I tried to find solutions for this prob on many newsgroups, google, etc, however just found a couple of similar reports, but no solutions. Please find perl information below, I would appreciate it very much if somebody could help me here, since it's a complete show stopper for my project currently. -bash-2.05b$ perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: usethreads=define use5005threads=undef useithreads=define usemultiplicity=define Schwern may have to confirm, but I believe that threads were so broken in 5.8.0 that he decided not to support them with Test::Builder at all. Is there a possibility for you to upgrade to 5.8.8 (or at least 5.8.1)? -- c
Re: What should be captured in automated test reports?
On 9/25/06, Gabor Szabo [EMAIL PROTECTED] wrote: I think the above (and maybe the rest of the details) should be included in the success reports as well. Sometimes there seem to be two reports from the same source a failure and then a success. It would be very useful to be able to see what has changed in the system that let the tests pass. Even without the duplicates this might help understand what is a good vs. bad environment for the module. Just for reference, CPAN::Reporter always includes the same information in the report, regardless of success or failure. The only thing that changes is the intro message (Congratulations! Tests were successful or Unfortunately, problems were found). Regards, David Golden
Re: Testing for test labels
Chris Dolan wrote: On Sep 24, 2006, at 5:42 PM, Christopher H. Laco wrote: Ok, I'll play your game. :-) http://perlcritic.tigris.org/svn/perlcritic/trunk/Perl-Critic/lib/Perl/Critic/Policy/Testing/ [Assuming I'm not silly] Empty! Rev. 667 -=Chris D'oh! SVN commits work better if you svn add first... Fixed, should work now. :-) Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf Been there. Done That. I wonder if there's a config option anywhere to have svn commit bark loudly if there are non-added files. signature.asc Description: OpenPGP digital signature
prove vs. inc
While trying to install the latest PPI from svn, I noticed that running 'dmake test' passed, and 'prove -b t/' failed. As more and more people use Module::Install, it seems more and more transient build/test related modules are being stuffed in the inc/ directory. Given the talk about installers being installers (dmake) and testers being testers (prove), what is the correct behavior in this situation? Should the tests be skipping when these modules aren't found, and stop assuming I'm doing a 'make test' instead of a 'prove'? Should prove -l or -b look for an inc/ directory as well? And who should get this nice shiny new RT of mine? :-) -=Chris C:\PPI-1.118prove -b t/ t\01_compile.ok t\02_api.Can't locate Test/ClassAPI.pm in @INC (@INC contains: blib\arch blib\lib C:/strawberry- perl/perl/lib C:/strawberry-perl/perl/site/lib .) at t\02_api.t line 19. BEGIN failed--compilation aborted at t\02_api.t line 19. t\02_api.dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 1-2192 Failed 2192/2192 tests, 0.00% okay t\03_empiric.ok t\04_element.ok t\05_lexer_practical.ok t\06_round_trip..ok t\07_token...ok t\08_regression..ok t\09_normal..ok t\10_statement...ok t\11_utilok t\12_locationok t\13_dataok t\14_charsetsok 11/11 skipped: Unicode-incompatible locale in use t\15_transform...ok t\16_xml_compatibility...ok t\17_storableok t\18_cache...Can't locate File/Remove.pm in @INC (@INC contains: blib\arch blib\lib C:/strawberry-pe rl/perl/lib C:/strawberry-perl/perl/site/lib .) at t\18_cache.t line 14. BEGIN failed--compilation aborted at t\18_cache.t line 14. t\18_cache...dubious Test returned status 2 (wstat 512, 0x200) t\19_selftesting.Can't locate Class/Inspector.pm in @INC (@INC contains: blib\arch blib\lib C:/strawberr y-perl/perl/lib C:/strawberry-perl/perl/site/lib .) at t\19_selftesting.t line 16. BEGIN failed--compilation aborted at t\19_selftesting.t line 16. t\19_selftesting.dubious Test returned status 2 (wstat 512, 0x200) t\20_tokenizer_regressionok t\21_exhaustive..ok t\22_readonlyok t\23_fileok t\99_author..skipped all skipped: Author tests not required for installation t\99_pod.skipped all skipped: Test::Pod 1.00 required for testing POD t\ppi_elementok t\ppi_node...ok t\ppi_normal.ok t\ppi_statement_variable.ok t\ppi_token__quoteengine_fullok t\ppi_token_quoteok t\ppi_token_quote_double.ok t\ppi_token_quote_interpolateok t\ppi_token_quote_literalok t\ppi_token_quote_single.ok Failed TestStat Wstat Total Fail Failed List of Failed --- t\02_api.t2 512 2192 4384 200.00% 1-2192 t\18_cache.t 2 512?? ?? % ?? t\19_selftesting.t2 512?? ?? % ?? 2 tests and 11 subtests skipped. Failed 3/35 test scripts, 91.43% okay. 2192/5924 subtests failed, 63.00% okay. C:\PPI-1.118 signature.asc Description: OpenPGP digital signature
How should CPAN Testers treat failing builds?
Two tickets on CPAN::Reporter have prompted the question of the role of CPAN Testers in capturing build failures versus test failures -- i.e. failures in Makefile.PL/Build.PL or in make/Build. * http://rt.cpan.org/Public/Bug/Display.html?id=21691 * http://rt.cpan.org/Public/Bug/Display.html?id=21566 Right now, CPAN::Reporter only wraps the test action in CPAN.pm and CPAN.pm doesn't even run tests if the make process wasn't successful. It wouldn't be terribly hard to add support to capture the earlier stages, but I'm not sure if CPAN Testers is the right place to capture it and, if so, how it should be coded. If failures happen before tests are run, should that be counted as an NA -- meaning that tests could not be run on that platform? Generally, I've seen that to mean that prerequisites could not be satisfied. Or should there be a new failure category BUILDFAIL (or WONTBUILD) that distinguishes these cases? Or something else entirely Before I hack something into CPAN::Reporter and CPAN.pm, I'd like to get some community consensus, particularly from those involved in CPAN Testers. Regards, David Golden P.S. As a side note, Chorny (from win32.perl.org and #win32) mentioned that he's looking into HTTP transport for Test::Reporter -- that will be a nice upgrade for getting reports from behind ISP firewalls.
Re: OT: cross-platform path handling
BTW, my Directory::Scratch module is meant to solve this problem. At the top of your program you: use Directory::Scratch YourOS and all path names passed to the module are interpreted as though they're from YourOS, even when running on some other OS. This means that you can use UNIX path names in your tests, and they'll work everywhere Path::Class does. (Of course, you can use Win32/VMS/MacOS paths, also; but UNIX is the default.) The version of D::S on CPAN right now is kind of embarrassing (got a few patches and applied them even though I felt uneasy about them), but I'll have a fixed version up tonight. So don't try the module yet -- I'll send another note to the list when I'm happy with it :) Regards, Jonathan Rockway (Disclaimer: nothing is broken in the current version, but it does assume that you're using your native OS's paths. So if you don't care about cross-platform usability, go ahead and use it now. In addition, the tests are kind of icky, as are some of the features. YMMV. :) A. Pagaltzis wrote: * David Golden [EMAIL PROTECTED] [2006-09-18 12:30]: Many of the test failures can be attributed to: * non-portable path expectations Btw, is there a chance of Path::Class becoming core? It is *so* *much* better than File::Find, File::Basename, File::Spec and the rest of the entourage it’s not even funny. And it’s also sane, as opposed to IO::All. Regards,
[ANNOUNCE] smolder 1.00
Smolder 1.00 has finally been tagged and released. Available at http://sourceforge.net/projects/smolder Smolder is a Open Source Perl smoke test aggregator used primarily to collect the results of automated test runs and distribute those to users. An introduction is given in my slides from the Pittsburgh Perl Workshop - http://plusthree.com/~mpeters/smolder_presentation.pdf Enjoy -- Michael Peters Developer Plus Three, LP
Re: Testing for test labels
Chris Dolan wrote:
On Sep 24, 2006, at 5:42 PM, Christopher H. Laco wrote:
Ok, I'll play your game. :-)
http://perlcritic.tigris.org/svn/perlcritic/trunk/Perl-Critic/lib/Perl/Critic/Policy/Testing/
[Assuming I'm not silly] Empty! Rev. 667
-=Chris
D'oh! SVN commits work better if you svn add first... Fixed, should
work now. :-)
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Now, for part 2. :-)
What's the sanest way to test t/*.t files without also testing
everything in t/lib ?
If I'm already using all_critic_ok(), I can't just call critic_ok() on
all the t/*.t files because a plan has already been set.
Would it be possible to have all_critic_ok also take globs:
all_critic_ok('blib', 't/*.t')
-=Chris
signature.asc
Description: OpenPGP digital signature
Re: Testing for test labels
On Sep 25, 2006, at 8:16 PM, Christopher H. Laco wrote:
Now, for part 2. :-)
What's the sanest way to test t/*.t files without also testing
everything in t/lib ?
If I'm already using all_critic_ok(), I can't just call critic_ok() on
all the t/*.t files because a plan has already been set.
Would it be possible to have all_critic_ok also take globs:
all_critic_ok('blib', 't/*.t')
-=Chris
Here's what I would do:
use Test::More;
use Test::Perl::Critic qw(critic_ok);
use File::Slurp qw(read_dir);
use Perl::Critic::Utils qw(all_perl_files);
my @files = all_perl_files('blib'), grep {m/\.t\z/} read_dir('t');
plan tests = scalar @files;
for my $file (@files) {
critic_ok( $file, $file );
}
Of course, you could easily replace that use of File::Slurp with
opendir,readdir,closedir.
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: Bug in prove or Test::Class?
On 22 Sep 2006, at 09:11, Ovid wrote:
I don't have time to track this down, but I've noticed the
following when I run my Test::Class tests through prove:
[snip]
As you may notice, you see the diagnostics from the TODO failures.
As Schwern has noted repeatedly:
The user should not see the diagnostics from that TODO failure.
[snip]
I've not been able to reproduce this, e.g.:
#! /usr/bin/perl
# spoon.t
use strict;
use warnings;
{ package My::Test;
use base qw( Test::Class );
use Test::More;
sub there_is_no_spoon : Test {
local $TODO = perceive true nature of reality;
is bless( {}, 'Spoon' ) , undef;
}
}
Test::Class-runtests;
% prove t/spoon.t
t/spoonok 77 ms
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.05 cusr + 0.01 csys = 0.06
CPU)
So I'd be interested in a test case.
[snip]
And is there any way that displaying the diagnostics from TODO
failures can break things (such as making it difficult to install
modules)?
[snip]
I can only think of it causing problems for testing test modules that
output todo tests - where you might be capturing the output from
STDERR explicitly - moderately uncommon I would think.
Adrian
