|
Posted by David Tiberio on October 23, 2004, 8:30 pm
Please log in for more thread options
I just uploaded my first perl module, Logfile::Access. Makes parsing
access logs very easy.
http://cpan.org/modules/by-authors/id/D/DT/DTIBERIO/Logfile-Access-1.23.tar.gz
|
|
Posted by Jim Keenan on October 24, 2004, 4:22 pm
Please log in for more thread options
David Tiberio wrote:
> I just uploaded my first perl module, Logfile::Access. Makes parsing
> access logs very easy.
>
> http://cpan.org/modules/by-authors/id/D/DT/DTIBERIO/Logfile-Access-1.23.tar.gz
Since it was only a couple of years ago that I was a novice CPAN
contributor, I don't want to discourage your efforts. However, I think
you should take note of the following:
1. Your module has no tests other than the one test offered by default
by the 'h2xs' program. Consequently, a potential user has no way to
determine whether the methods provided by your module do what the
documentation claims they do.
2. Access.pm requires three other CPAN modules: URI, URI::Escape and
Locale::Country. As far as I can tell, the first two of these are not
Perl 'core' distributions, i.e., they are not distributed with Perl 5.8,
so a user must install them for her/himself. In that case, they need to
be listed in your Makefile.PL at the point where you simply have:
'PREREQ_PM' => {}, # e.g., Module::Name => 1.1
This will guarantee that anyone using the 'cpan' utility to
automatically install Logfile::Access from CPAN will get the URI
distribtion installed if it's not already present.
3. Similarly, you could have listed yourself in Makefile.PL as the
module's author here:
(To be fair, it appears that the AUTHOR key is a somewhat recent
addition to the model Makefile.PL suggested by 'h2xs'. My own
distributions were created long enough ago that 'h2xs' was not
prompting module-authors to include an AUTHOR line.)
4. Yesterday I responded to a question on this newsgroup titled "how do
I package a CPAN module?" from a poster describing himself as 'none'.
The question concerned using 'h2xs' to package a module for CPAN -- a
module described by the anonymous poster as his first CPAN distribution,
Logfile::Access. It would have been better Netiquette for you (a) to
have posted that question using a more descriptive handle than 'none'
and (b) to have acknowledged that you read my response and heeded its
advice. You will find that you will get more help in your future
efforts if you acknowledge the help you get from others.
That being said, you appear to have put considerable effort into the
code of your module. Have you checked out other CPAN modules such as
Regexp::Common to see if some of their functionality can be imported
into yours?
Jim Keenan
|
|
Posted by David Tiberio on October 25, 2004, 1:09 am
Please log in for more thread options Hi Jim!
Thankyou for the advice. I added test routines that test out virtually
every function except 3 or 4. It helped me locate a few bugs which I
do not understand. The new version, 1.30, will be on cpan shortly:
http://cpan.org/modules/by-authors/id/D/DT/DTIBERIO/
I do not understand why URI->path() does not seem to return the
correct path.
For some reason my tld() routine does not pass the second test
properly. I am not sure why.
|
|
Posted by Jim Keenan on October 26, 2004, 1:28 am
Please log in for more thread options David Tiberio wrote:
> Hi Jim!
>
> Thankyou for the advice. I added test routines that test out virtually
> every function except 3 or 4. It helped me locate a few bugs which I
> do not understand. The new version, 1.30, will be on cpan shortly:
>
> http://cpan.org/modules/by-authors/id/D/DT/DTIBERIO/
>
> I do not understand why URI->path() does not seem to return the
> correct path.
>
> For some reason my tld() routine does not pass the second test
> properly. I am not sure why.
Well, that's why it's important to test before you hang your code out on
CPAN for all the world to see. At the very least, you should write
one test for each publicly callable subroutine or method in a module.
If you have not already done so, read:
perldoc Test::Tutorial # core with Perl 5.8+
then go on to read the docs for Test::Simple and Test::More.
jimk
|
|
Posted by Jim Keenan on October 26, 2004, 1:47 am
Please log in for more thread options David Tiberio wrote:
> Hi Jim!
>
> Thankyou for the advice. I added test routines that test out virtually
> every function except 3 or 4. It helped me locate a few bugs which I
> do not understand. The new version, 1.30, will be on cpan shortly:
>
> http://cpan.org/modules/by-authors/id/D/DT/DTIBERIO/
>
> I do not understand why URI->path() does not seem to return the
> correct path.
You have syntax errors in your Makefile.PL, starting with element
PREREQ_PM. The errors are such that they generate warnings, but do not
cause Makefile.PL to fail to compile. But their impact is felt down the
road.
For an example of a correctly specified PREREQ_PM, see, e.g.,
http://search.cpan.org/src/PETDANCE/WWW-Mechanize-1.04/Makefile.PL
This is the output I got from running the cpan utility and calling 'test
Logfile::Access':
CPAN.pm: Going to build D/DT/DTIBERIO/Logfile-Access-1.30.tar.gz
Checking if your kit is complete...
Looks good
Writing Makefile for Logfile::Access
Argument "URI::Escape" isn't numeric in numeric eq (==) at
/usr/local/lib/perl5/5.8.4/CPAN.pm line 4623.
cp Access.pm blib/lib/Logfile/Access.pm
Manifying blib/man3/Logfile::Access.3
/usr/bin/make -- OK
Running make test
Argument "URI::Escape" isn't numeric in numeric eq (==) at
/usr/local/lib/perl5/5.8.4/CPAN.pm line 4623.
PERL_DL_NONLAZY=1 /usr/local/bin/perl "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/1....unable to open /etc/httpd/conf/mime.types
t/1....NOK 21# Failed test (t/1.t at line 42)
Use of uninitialized value in string eq at t/1.t line 43.
t/1....NOK 22# Failed test (t/1.t at line 43)
t/1....NOK 35# Failed test (t/1.t at line 59)
t/1....NOK 53# Failed test (t/1.t at line 80)
Use of uninitialized value in string eq at t/1.t line 81.
# Failed test (t/1.t at line 81)
# Looks like you failed 5 tests of 62.
t/1....dubious
Test returned status 5 (wstat 1280, 0x500)
DIED. FAILED tests 21-22, 35, 53-54
Failed 5/62 tests, 91.94% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/1.t 5 1280 62 5 8.06% 21-22 35 53-54
Failed 1/1 test scripts, 0.00% okay. 5/62 subtests failed, 91.94% okay.
make: *** [test_dynamic] Error 2
/usr/bin/make test -- NOT OK
The docs to the Test::* modules I mentioned in the previous post will
tell you how to interpret this data. Then it's up to you to go to the
failure points cited in each test and diagnose the problems.
jimk
|
| Similar Threads | Posted | | help with module naming: filehandle-tie for size-limited/rotating logfile | March 18, 2007, 5:44 am |
| Access a c++ module from Perl | October 24, 2005, 6:21 pm |
| Module to use for win32 registry access? | April 4, 2007, 8:32 pm |
| Do Win32::ODBC module support Chinese characters when used with MS Access? | September 15, 2004, 10:33 pm |
| Logfile::Rotate error, | May 3, 2006, 11:29 pm |
| Simulation logfile parser problem | March 1, 2005, 1:29 am |
| Perl under MS IIS with access to MySQL | June 19, 2005, 11:24 pm |
| Microsoft Access & Win32::Ole | October 28, 2005, 4:03 pm |
| Access DOM using JavaScript::SpiderMonkey | January 16, 2006, 12:37 pm |
| pure-perl access to mySQL | June 14, 2005, 8:38 am |
|
XML Sitemap