Re: Testing for valid path names in CPAN distributions
On Sun, Aug 17, 2003 at 01:54:42PM +1000, Andrew Savige wrote: Running variants of: tar tzf perl-5.8.0.tar.gz | perl -lne'print if tr|-_./a-zA-Z0-9||c' suggests only [-_./a-zA-Z0-9] are valid characters in a path name. Then I noticed 'perldoc perlport' lists the portable filename characters as defined by ANSI C and various other restrictions. What is the length limit of each path name component? What is the length limit of file extensions? I heard YAML changed from .yaml to .yml, for instance, yet Perl itself has many files with long extensions -- runtime.porting, for example. 8.3 filesystems can handle long filenames, they just truncate them. All that matters is that they don't truncate to the same thing, a common problem with the perl*.pod man pages. It'd be nice to have a standard test for valid portable path names. Does such a test exist? I noticed Archive::Any has is_impolite() and is_naughty() but didn't see any checks for basic path name validity. BTW, is Archive::Any a dead camel? Its just resting. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ That you be hanged by the neck, but not until you are dead, but that you be taken down again, and whilst you are yet alive, your bowels be taken out and burnt before your face; and that afterwards your head be severed from your body and your body be divided into quarters. And may God Almighty have mercy on your soul.
Scrutinizing CPAN distributions (was Testing for valid path names...)
Though this started as an innocent question, I think it would be nice to have a module/script to scrutinize a CPAN distribution. 1) Archive nit-picker. Archive::Any's is_impolite/is_naughty is a start. Also test for: good cross-platform file names (my original question); good Changes, README, t/ directory etc.. 2) POD tester. Use Test::Pod/Pod::Coverage, say, on all POD in a distribution. 3) Static Perl code analyser. I suppose PerlTidy, Module::Info, B::Lint may be helpful. Any others? 4) Test suite analyser. How good is the test suite? Use perhaps Devel::Cover to determine how much of the code is covered by the distribution's test suite. 5) Signature checker. 6) Prerequisite checker. 7) Version checker. Anything else? Does such a module/script already exist? I'm an enthusiastic admirer of Schwern's CPANTS kwalitee vision and aware of Module::CPANTS but unsure about the current state of play. Tips on other stuff I should look at are welcome. /-\ http://search.yahoo.com.au - Yahoo! Search - Looking for more? Try the new Yahoo! Search
Re: Scrutinizing CPAN distributions (was Testing for valid path names...)
On Mon, Aug 18, 2003 at 11:25:14PM +1000, Andrew Savige wrote: Four completely normal peeps there. ;-) Judging by the popularity of cricket and golf statistics, I think there are a lot of lurkers too. So in a few years time we'll have people quoting Wisden's CPAN almanac? Yes, bioperl now including the entire human genome as a prereq has added a new sharp upwards spike to CPAN's mean prereq size/module size ratio. We've not seen anything like this since Meta added a dependency on the entire Linux 2.7.15 source tree back on April 2nd 2005 :-) Nicholas Clark
RE: Scrutinizing CPAN distributions (Commenting Styles)
Since we're on the topic of scrutinizing CPAN distributions I would like to contribute something that I do not like in some of the distributions that I have come across. I don't know if it has been brought up on this thread yet but here it goes: 1) I do not like in-module POD as it is hard to tell the difference between code and pod when you are scrolling throught the module. I personally think POD should go at the end and comments should be added in-module and definetly before sub routines. 2) I found that commenting blocks of code with what it does in a general sense is good when users want to know what something does, namely a subrountine. I think it is beneficial to have black box commenting for your subroutines and then commenting in line to further describe the code that you wrote. If you would like clerification on these two comments I can give some samples. -Original Message- From: Nicholas Clark [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 9:36 AM To: [EMAIL PROTECTED] Subject: Re: Scrutinizing CPAN distributions (was Testing for valid path names...) On Mon, Aug 18, 2003 at 11:25:14PM +1000, Andrew Savige wrote: Four completely normal peeps there. ;-) Judging by the popularity of cricket and golf statistics, I think there are a lot of lurkers too. So in a few years time we'll have people quoting Wisden's CPAN almanac? Yes, bioperl now including the entire human genome as a prereq has added a new sharp upwards spike to CPAN's mean prereq size/module size ratio. We've not seen anything like this since Meta added a dependency on the entire Linux 2.7.15 source tree back on April 2nd 2005 :-) Nicholas Clark
Re: Scrutinizing CPAN distributions (was Testing for valid path names...)
On Mon, Aug 18, 2003 at 10:11:23PM +1000, Iain Truskett wrote: Strictly speaking, the FChangeLog is a log of changes, usually extracted straight from version control software (e.g. C svn log ChangeLog ). The FChanges file is more a user-oriented description of the net effect of the individual changes. Says who? -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ It's Airplane Glue sniffing time!
RE: Scrutinizing CPAN distributions (Commenting Styles)
SNIP Personal and asthetic style nits cannot be part of any code analysis that claims to be non-partisan or even wishes to exist. It will make the analysis worthless since nobody will agree on what you feel is good style. Stick to choices that don't rely on asthetics. Consider that the very style you hold up as bad in #1 many people find very good and actually teach (I'm one of them). Ironicly, the style you don't like in #1 is the very style you promote in #2. Replace 'black box commenting' with POD documentation and you have in-module POD. Plus the benefits of not duplicating your documentation of the module in the comments and the POD docs. I guess your beef is there's no visually distinctive line of # running down the left side of the screen to distinguish it from the code when you use POD. Might I suggest a good syntax highlighting editor? I guess mostly the syntax highlighting is the biggest concern. I use emacs and that does syntax highlighting for perl files. Is there any IDE out there that highlights POD differently than code? If that was the case then I probably wouldn't have a problem with in-module POD. I guess when it comes down to it it's readability and the ability to distinguish comments from code. :-p -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ The key, my friend, is hash browns. http://www.goats.com/archive/980402.html
Re: Scrutinizing CPAN distributions (Commenting Styles)
* Potozniak, Andrew ([EMAIL PROTECTED]) [19 Aug 2003 00:28]: [...] I guess mostly the syntax highlighting is the biggest concern. I use emacs and that does syntax highlighting for perl files. Surely it highlights pod distinctively? Is there any IDE out there that highlights POD differently than code? If you class vim as an IDE, then sure. And as I've overridden vim's default colouring for comments with things like green, POD and comments are very easy to see. If that was the case then I probably wouldn't have a problem with in-module POD. I guess when it comes down to it it's readability and the ability to distinguish comments from code. My only criticism of inline POD is when the docs far outweigh the code and don't really follow the code order and the code order wouldn't be good to change. This amounts to precisely one of my modules. And in that case there's not much code in the module itself that is part of a public API while the public API is sufficiently complex to warrant reams of docs. cheers, -- Iain.
Phalanx and testing distributions
Some of this distribution testing could likely get incorporated into the Phalanx project, if I get it announced today like I'd like to do... Phalanx = beefing up test suites of Perl and the top 100 CPAN modules to make a good test bed for Ponie xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Scrutinizing CPAN distributions (Commenting Styles)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Potozniak, Andrew acp7 at citmail.buffalo.edu [2003-08-18 10:27]: Might I suggest a good syntax highlighting editor? I guess mostly the syntax highlighting is the biggest concern. I use emacs and that does syntax highlighting for perl files. Is there any IDE out there that highlights POD differently than code? vim Does the Right Thing. Screenshots available upon request. ;) (darren) - -- Wise people think all they say; fools say all they think. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: This message is digitally signed and can be verified for authenticity. iD8DBQE/QOZYzsinjrVhZaoRAkkfAJ94WkrxHo5zrLHEWeezu+06PEduPACeKFxZ LDfZcdu5ejGKG2sqa4FVz64= =Nn31 -END PGP SIGNATURE-
Re: Scrutinizing CPAN distributions (Commenting Styles)
On Mon, 18 Aug 2003, Michael G Schwern wrote:
Personal and asthetic style nits cannot be part of any code analysis that
claims to be non-partisan or even wishes to exist. It will make the analysis
worthless since nobody will agree on what you feel is good style. Stick
to choices that don't rely on asthetics.
This having been said, it might make sense to provide some kind of
infomation on this kind of thing, even if it's not a measurement of
kwalitee. For example, I think it'd be interesting to find out what
percentage of people stick pod at the end and which inline. It fits in
the same catagory of 'how many people use Test::More'. 'how many
people use the 'our' keyword' Not necessarly an indication of kwalitee,
but a useful metric overall.
Oh crap, that sounds like me volentering for something doesn't it?
Botheration. I'll liase with that Orange Lover and find out what this
kind of thing involves.
Mark.
--
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, [EMAIL PROTECTED], http://twoshortplanks.com/};
Re: Scrutinizing CPAN distributions (was Testing for valid path names...)
Hi!
On Mon, Aug 18, 2003 at 11:25:14PM +1000, Andrew Savige wrote:
It doesn't have to eval the whole of CPAN to be useful.
I see the mythical Module::Scrutinize as perhaps a little orthogonal
to Module::CPANTS, as something that may help individual CPAN authors
produce a higher quality product, running their CPAN module through it
pointing out things that might be improved. It may also be handy to
Just yesterday I was thinking of something like validator.cpan.org (parallel
to validator.w3.org):
Upload a dist and let it be checked by a future version of Module::CPANTS.
You should get back a report and/or a kwalitee rating. If the kwalitee is
too low, improve your distribution (where improve means: code the module so
that it gets a high kwalitee). The hard part of this validation service is
definitly deciding how to calculate kwalitee.
6) Prerequisite checker.
What would you check, exactly?
That the prerequisites in Makefile.PL/Build.PL/META.yml match the code.
The current of Module::CPANTS includes a field called 'requires_module',
which is basically prereq_pm. There's another field called 'uses' that
contains all the modules used. (this is generated by parsing the code using
a Parse::RecDescent based parser called Module::Extractuse (written by me
(end-of-plug)).
I didn't found the time to match those two data fields after dropping Core
modules and modules provided by the distribution itself. But I'm planning to
do it.
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Scrutinizing CPAN distributions (was Testing for valid path names...)
Op een zonnige zomerdag (Monday 18 August 2003 21:48), schreef Thomas Klausner: Hi! Just yesterday I was thinking of something like validator.cpan.org (parallel to validator.w3.org): Upload a dist and let it be checked by a future version of Module::CPANTS. You should get back a report and/or a kwalitee rating. If the kwalitee is too low, improve your distribution (where improve means: code the module so that it gets a high kwalitee). The hard part of this validation service is definitly deciding how to calculate kwalitee. Perhaps the way Web Content Accessebility Guidelines is setup, is a better way to get this off to a start. I like the way Bobby (http://bobby.cast.org) checks and reports your (non)use of the guidelines. IMO it is better to have guidelines than laws carved in stone. There are already a lot of good guidelines discussed in the thread and most of them can be checked for or an indication can be given to module authors as to how to follow the guideline. Good luck, Abe -- Rafael Actually you're thinking aloud, here ? Yes? No? Maybe? -- Jarkko Hietaniemi on p5p @ 2003-02-17
Re: Scrutinizing CPAN distributions (Commenting Styles)
On Mon, Aug 18, 2003 at 10:27:18AM -0400, Potozniak, Andrew wrote: I guess mostly the syntax highlighting is the biggest concern. I use emacs and that does syntax highlighting for perl files. Is there any IDE out there that highlights POD differently than code? emacs cperl-mode will do it. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ purl Hey Schwern! honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk!
Re: Scrutinizing CPAN distributions (was Testing for valid path names...)
On Mon, Aug 18, 2003 at 09:48:57PM +0200, Thomas Klausner wrote: Just yesterday I was thinking of something like validator.cpan.org (parallel to validator.w3.org): Upload a dist and let it be checked by a future version of Module::CPANTS. That's actually kind of a neat idea. It makes me think how cool it would be if Module::CPANTS installed a script which would do the same thing...from the command line. It would be a handy development tool, much like warnings and strict. Just as you can program in Perl without warnings and strict, it sure is useful to use them. If such a script existed the CPAN author could just type: kwalitee MyModule.tar.gz , and get the straight poop, as it were. The wonderful thing about Perl is that it gives you so much flexibility, but as we all know this is a double edged sword. The strict and warnings pragmas are there to encourage good practice (not to tell you how to live your life), and a kwalitee metric would do similar things for module authors. Preeching to the Kwire //Ed
Re: Scrutinizing CPAN distributions (Commenting Styles)
I guess mostly the syntax highlighting is the biggest concern. I use emacs and that does syntax highlighting for perl files. Is there any IDE out there that highlights POD differently than code? If that was the case then I probably wouldn't have a problem with in-module POD. I guess when it comes down to it it's readability and the ability to distinguish comments from code. Emacs does. iirc cperl-mode has proper (i.e. different) highlighting for POD, and if you want to do it right, you can use mmm-mode to mix cperl mode and pod mode. -R
