Phalanx / CPANTS / Kwalitee

2003-10-13 Thread Thomas Klausner 
Hi!

CPANTS and Phalanx both care about Kwalitee. So I thought it might be a good
idea to come up with one more or less complete list of Kwalitee-hints that
both projects can use.

A lot of the hints listed at http://qa.perl.org/phalanx/kwalitee.html are
rather vague, which is OK for Phalanx, as it is run by humans.

But CPANTS needs a hard, computable list of hints.

Anyway, here is what the dev-version of CPANTS currently cosiders as
kwalitee-hints: 

* distname includes version
* extracts nicely
* does not include symlinks (which some OS cannot handle)
* no strange permissions (files undeleteable by owner, eg)
* contains files:
  * Makefile.PL or Build.PL or configure
  * README
  * MANIFEST
  * t/* or test.pl
  * one *.pm in top-level OR lib/

Hints that were in Leon's last release, but which I didn't port up to now:
* POD errors
* POD/Code ratio (what would be a good measurement?)
* testers results
* number of releases

Some ideas:
* wheater PREREQ_PM matches used modules (hard!)
* AUTHOR != 'R.U. Thor'
* Description
* ratings
* a lot of code analysis (to be done without running the code!!)

Obviously, this list is far from complete, which is why I request some
feedback on more hints for Kwalitee from all of you!


-- 
#!/usr/bin/perl   http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}

Re: Phalanx / CPANTS / Kwalitee

2003-10-13 Thread Michael G Schwern 
On Mon, Oct 13, 2003 at 10:28:29AM +0200, Thomas Klausner wrote:
 * contains files:
   * Makefile.PL or Build.PL or configure

configure?

   * README

Personally, I find READMEs useless duplication.  Even more so now that
search.cpan.org works so well.

   * t/* or test.pl

test.pl is not a good thing.  It doesn't get parsed by make test.  It just
runs and spits the output to the screen.  If a test fails, make test will
still succeed.  Still, its better than nothing at all.

   * one *.pm in top-level OR lib/

Or Module/*.pm.  Seems a little dubious anyway, there are POD-only modules.


 Some ideas:
 * wheater PREREQ_PM matches used modules (hard!)

Nearly impossible since:

require Foo::Bar if $some_condition;

Otherwise Module::Info-modules_used() can handle it.


-- 
Michael G Schwern[EMAIL PROTECTED]  http://www.pobox.com/~schwern/
AY!  The ground beef, she is burning my groin!
http://sluggy.com/d/990105.html

Re: Phalanx / CPANTS / Kwalitee

2003-10-13 Thread Tels 
-BEGIN PGP SIGNED MESSAGE-

Moin,

On Monday 13 October 2003 11:57, Michael G Schwern wrote:
 On Mon, Oct 13, 2003 at 10:28:29AM +0200, Thomas Klausner wrote:
  * contains files:
* Makefile.PL or Build.PL or configure

 configure?

* README

 Personally, I find READMEs useless duplication.  Even more so now that
 search.cpan.org works so well.

You have never maintained a big project, were the *brief* introduction in 
README is 8 pages, accompanied by an INSTALL file with another 15, not to 
speak of the $three-digit-figure pages of userland documenatation :) In that 
case a README is a lifesaver, because it is, if ever, the only thing someone 
reads :)

(That was a joke about you personally. :-)

I find that a short intro in the README (if it isn't immidiately replicated in 
the .pod, where it does _not_ belong if there are more than on .pm files) is 
very usefull. Unfortunately, not every project has a README, or a useless one 
(like just a boilerplate or something like this). The README should explain 
the goals and target of the package, contact points etc etc..

I agree that merely having one doesn't say much, but if it is lacking, that  
certainly shows the authors attitude...


* t/* or test.pl

 test.pl is not a good thing.  It doesn't get parsed by make test.  It
 just runs and spits the output to the screen.  If a test fails, make test
 will still succeed.  Still, its better than nothing at all.

If there are t/* _and_ test.pl this probably should be marked as bad. 
test.pl is usually old cruft still lingering around :)

* one *.pm in top-level OR lib/

 Or Module/*.pm.  Seems a little dubious anyway, there are POD-only modules.

And what about doc/Somedoc.pod files?

Just my 0.02Eurocent,

Tels
- -- 
 Signed on Mon Oct 13 18:51:43 2003 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 Now, admittedly, it's critical software. This is the 'let's go kill
 people' software. -- Mark A. Welsh III

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.

iQEVAwUBP4rYKHcLPEOTuEwVAQG6mwf+Ke2wRst2S3FEUtb+x0SgTsbNtuJGc3e8
71nycuArl2eXhRYyyk7yZm73AxPWdE6cyOcSg94Y0MtD2t58OMDiRUksomLRtMBC
TD441s1Wmx3HrxYqTGLHLeuDmJjVbsCnFJkr8Vfc/cPbp0u+yDFo5ZtaF1QhIWXQ
djAMTWLjgaYk9OfxswiTj1YohQIGzzqTaHlQalvU4GyHYz0enAT71YGyHF/ZEYz6
d5BsvdMFLIobx/zvyWYKMkdd5hv45oL621L2S+I0tKevZzbWe9MNmGB1MvWFb7hy
WlH/7wVT7qq3QHlo4O8fzoVMU1zFfGBoff7uLeL8rh7vEPuLs3L2ow==
=uqva
-END PGP SIGNATURE-

Re: Phalanx / CPANTS / Kwalitee

2003-10-13 Thread Rafael Garcia-Suarez 
Thomas Klausner wrote in perl.qa :
 
 Hints that were in Leon's last release, but which I didn't port up to now:
 * POD errors
 * POD/Code ratio (what would be a good measurement?)

use Pod::Coverage ?

 * testers results
 * number of releases

Re: Phalanx / CPANTS / Kwalitee

2003-10-13 Thread Michael G Schwern 
On Mon, Oct 13, 2003 at 06:51:43PM +0200, Tels wrote:
 * t/* or test.pl
 
  test.pl is not a good thing.  It doesn't get parsed by make test.  It
  just runs and spits the output to the screen.  If a test fails, make test
  will still succeed.  Still, its better than nothing at all.
 
 If there are t/* _and_ test.pl this probably should be marked as bad. 
 test.pl is usually old cruft still lingering around :)

No, t/* and test.pl is ok.  test.pl is basically just a program that gets
run at make test time.  DBI and the DBD::* modules use test.pl to display
benchmarking information.


-- 
Michael G Schwern[EMAIL PROTECTED]  http://www.pobox.com/~schwern/
I know you get this a lot, but what's an unholy fairy like you doing in a
mosque like this?

Devel::Cover bug in ActiveState Perl for *Linux*

2003-10-13 Thread Ovid 
After much research, I've managed to reduce a Devel::Cover bug down to a one-liner 
which only
fails on one box.  This box is unique because it's ActiveState Perl for Linux (not my 
choice!). 
However, that might be a red herring.  My 'perl -V' is below the test case.  Does 
anyone have a
similar setup which they can check this against?

--

$ perl -MDevel::Cover -e 'local *{foo} = sub {}'
Devel::Cover 0.26: Collecting coverage data for branch, condition, statement, 
subroutine and time.
Pod coverage is unvailable.  Please install Pod::Coverage from CPAN.
Selecting packages matching:
Ignoring packages matching:
Ignoring packages in:
.
/dp/usr/cxp/perl/lib
/usr/local/lib/perl5/site_perl
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1/i686-linux-multi
Can't locate object method find_cv via package B::SPECIAL (perhaps you forgot to 
load
B::SPECIAL?) at 
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1/i686-linux-multi/B.pm line 213.
END failed--call queue aborted.

--
And the Perl -V 
--

$ perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
  Platform:
osname=linux, osvers=2.4.9-e.3, archname=i686-linux-multi
uname='linux bulkmailer 2.4.9-e.3 #1 fri may 3 17:02:43 edt 2002 i686 unknown '
config_args='-d -O -Dinstallstyle=lib/perl5 
-Dprefix=/usr/local/stow/perl-5.6.1-a633
-Uinstallusrbinperl -Dd_dosuid=define -Dotherlibdirs=/usr/local/lib/perl5/site_perl
-Dusemultiplicity'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=define
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
  Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.2 2.96-108.1)', 
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, usemymalloc=n, prototype=define
  Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
  Locally applied patches:
ActivePerl Build 633
  Built under linux
  Compiled at Mar 24 2003 17:43:39
  %ENV:
PERL5LIB=/dp/usr/cxp/perl/lib
  @INC:
/dp/usr/cxp/perl/lib/i686-linux-multi
/dp/usr/cxp/perl/lib
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux-multi
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl

--

Any ideas on where to look next?

Cheers,
Ovid

=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid   http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl  http://users.easystreet.com/ovid/cgi_course/

__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: Phalanx / CPANTS / Kwalitee

2003-10-13 Thread Tels 
-BEGIN PGP SIGNED MESSAGE-

Moin,

On Monday 13 October 2003 10:28, Thomas Klausner wrote:
 Hi!
 * POD/Code ratio (what would be a good measurement?)

No. Some _very_ complex code takes little documentation like:

=head2 sub delete_first_n_entries($N)

Deletes the first N entries from the list.

That pretty much sums it up and any more documentation probably only confuses.
However, the method in question could easily be 10 pages long. (Look at the
code in Math::BigInt::Calc.pm, for instance. Basically, _mul() multiplies two
numbers - and it is _huge_.

There are other issues, like the doc in the pod is usually for the code and
the userland doc. However, in certain cases you also have userland doc (like:
how to use the thing) and code doc (what does sub XYZ do?) seperated.
Should these be rn together? But the an included XYZ guid for dummies would
skew the numbers (It suggest much doc, but the code maybe not documented at
all) etc.

I donät think sensible results can be done by comparing pod to code size. It
is similiar silly like counting line numbers. (does the fact that I
optimized 2 pages code away mean I wrote -128 lines of code this week? :)

 Obviously, this list is far from complete, which is why I request some
 feedback on more hints for Kwalitee from all of you!

Unfortunately, it is had for me to come up with good, machine-implementable
rules..

Probably something like:

*.pm file has more than 1000 lines of code = bad

:-)

Best wishes,

Tels

- --
 Signed on Mon Oct 13 19:40:43 2003 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 Call me Justin, Justin Case.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.

iQEVAwUBP4rk2ncLPEOTuEwVAQE5mwf9EqbcU2Fb1FD57uv2u8mwruF4CytE7tKl
dkRePVBOvuOFOQ8EEu2LO0uTjPDlbA9+Ko5EFQtoN+1HWAKqsR0MlfIcZx1TeXiw
67K6xxwPI3Z5O6qnZKGrqkDymxg1NlO9HfYYI9nPah2WXgixXk48ynytEdsa0QDY
vunBMwbILON486Nz9ieKUAvk39fPezQq9Dsicl0IKj03f6F4Tvc7cbo4yToeiY9s
YuZevJPG5bSVl2pBQoGoRvA5HaSdW9twvy2s6BLekx7hD3CpdSYX5+9jK5CG3eov
HWqMkoEHLwk1fhAyQFbRKo3VdJCKjPvM3QT0waHuLnalX3RKQmwdjA==
=lmnE
-END PGP SIGNATURE-

Re: Devel::Cover bug in ActiveState Perl for *Linux*

2003-10-13 Thread Ovid 
FYI:  I've managed to replicate this error on another ActiveState Perl linux box.  The 
Perl -V
information is the same, but the module list is quite a bit smaller.  The only common 
element that
I can find is ActiveState.

Cheers,
Ovid

=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid   http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl  http://users.easystreet.com/ovid/cgi_course/

__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: Devel::Cover bug in ActiveState Perl for *Linux*

2003-10-13 Thread Paul Johnson 
On Mon, Oct 13, 2003 at 01:49:58PM -0700, Ovid wrote:

 After much research, I've managed to reduce a Devel::Cover bug down to
 a one-liner which only fails on one box.  This box is unique because
 it's ActiveState Perl for Linux (not my choice!).  However, that might
 be a red herring.  My 'perl -V' is below the test case.  Does anyone
 have a similar setup which they can check this against?

I think the key is that it is perl version 5.6.1.  I can reproduce the
problem on a stock 5.6.1 on linux (well, hacked just enough to get it to
build).

Is there any chance that we can just say it is a bug in 5.6.1 that has
been fixed?  I think that is actually the case.  Devel::Cover uses the B
modules which were still a little immature in 5.6.1.  The test works (in
that the bug does not show) for 5.8.0, 5.8.1, maintperl and bleadperl.

Actually, I wonder whether 5.6.1 should be supported or not.  It
generally works, but then you get cases like this.  The results are also
different between different versions of perl, and often it is 5.6.1 and
the rest.  But this is a problem which will only get worse.

In any case, thanks a lot for tracking this down.  I'm sure it wasn't
trivial.

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Re: Devel::Cover bug in ActiveState Perl for *Linux*

2003-10-13 Thread Ovid 
--- Paul Johnson [EMAIL PROTECTED] wrote:
 I think the key is that it is perl version 5.6.1.  I can reproduce the
 problem on a stock 5.6.1 on linux (well, hacked just enough to get it to
 build).

Hmmm ... I saw this *after* my second ActiveState email.

 Actually, I wonder whether 5.6.1 should be supported or not.

I think that 5.6.1 is widespread enough that you might lose much of your intended 
audience if it's
not supported.  I know that I currently have a project at work that involves code 
coverage stats,
but this is part of our plan to migrate to 5.8.1.  We don't *need* this information, 
but it would
be very helpful.

 In any case, thanks a lot for tracking this down.  I'm sure it wasn't
 trivial.

Not a problem.  Devel::Cover has been part of my plan for fixing some serious problems 
at work. 
I've been hoping to use to help us figure out how much old code we have so we can 
delete it and
start refactoring from a cleaner code base.

I'll dig some more and see if I can come up with a workaround.

Cheers,
Ovid

=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid   http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl  http://users.easystreet.com/ovid/cgi_course/

__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com