Re: Failed: PAUSE indexer report RRWO/Set-Light-0.95.tar.gz

[Robert Rothenberg]

Hello,

I used to have co-maint permissions for Set-Light. They seem to have 
gone away.


Any idea what's happened?

Regards,

Robert

On 07/05/2021 13:38, PAUSE wrote:

The following report has been written by the PAUSE namespace indexer.
Please contact modu...@perl.org if there are any open questions.

   User: RRWO ()
   Distribution file: Set-Light-0.95.tar.gz
   Number of files: 32
   *.pm files: 1
   README: Set-Light-0.95/README.md
   META-File: Set-Light-0.95/META.json
   META-Parser: Parse::CPAN::Meta 1.4414
   META-driven index: yes
   Timestamp of file: Fri May  7 12:03:20 2021 UTC
   Time of this run: Fri May  7 12:38:39 2021 UTC

ERROR: Database error occurred during index update


This distribution name will only be indexed when uploaded by users with
permission for the package Set::Light. Either someone else has ownership
over that package name, or this is a brand new distribution and that
package name was neither listed in the 'provides' field in the META file
nor found inside the distribution's modules. Therefore, no modules will
be indexed.

Further details on the indexing attempt follow.


The following packages (grouped by status) have been found in the 
distro:


Status: Permission missing
==

  module : Set::Light
  version: 0.95
  in file: lib/Set/Light.pm
  status : Not indexed because permission missing. Current 
registered

  primary maintainer is TELS. Hint: you can always find the
  legitimate maintainer(s) on PAUSE under "View 
Permissions".


__END__

Re: Algorithm-SkipList

[Robert Rothenberg]

When I log in to PAUSE, it still shows it as owned by ADOPTME.

On 26/02/2021 10:12, Neil Bowers wrote:

Hi John,

TL;DR: I’ve transferred the first-come permissions on 
Algorithm-SkipList to you.


I’m one of the PAUSE admins.

I was surprised to see Algorithm-SkipList marked as owned by
ADOPTME in

PAUSE, which is not the case in MetaCPAN, where it is owned by Robert

Rothenburg (although it is marked for adoption, see

).


As Dan Book pointed out, when you search for a module on CPAN, by 
default you’re shown the release that’s in the CPAN Index. Usually 
that’s the most recent release, but it might not be (for example 
developer releases don’t go in the index, and if the uploader didn’t 
have any indexing permission(s), then it would also not be indexed). 
And the person listed against it is the person who uploaded it.


What is the process for adoption, assuming that RRWO is amenable?


Given it’s marked as ADOPTME, the process is that you ask the PAUSE 
admins, and it’s polite to ask for the blessing of the previous owner 
(and Robert has given that). If the distribution is depended on by a 
lot of other CPAN modules, then we’ll consider whether you’re the 
right person to take it on, or at least that you’re aware that 
releasing a broken version could result in a cascade of failures. If 
you hover over the bars next to the distribution name, you’ll see that 
two distributions depend on this, which isn’t concerning.


So I’ve transferred first-come from ADOPTME to you, for all the 
modules in the distribution. Thanks for taking this on.


Final point: when you submit requests like these, please include your 
PAUSE id. I hope JGAMBLE was the right John Gamble? ;-)


Cheers,
Neil

Re: Algorithm-SkipList

[Robert Rothenberg]

I'm fine with it.

Note there's an unfinished development version on CPAN and a github repo 
at https://github.com/robrwo/Algorithm-SkipList


Robert


On 25/02/2021 06:40, John M. Gamble wrote:
I was surprised to see Algorithm-SkipList marked as owned by ADOPTME 
in PAUSE, which is not the case in MetaCPAN, where it is owned by 
Robert Rothenburg (although it is marked for adoption, see 
).


In any event, I'm marked as co-maintainer. What is the process for 
adoption, assuming that RRWO is amenable?


Thanks,
 --john

Re: What to call a module that rewrites Perl code

[Robert Rothenberg]

Thank you for your comments.

To answer various questions/suggestions/comments:

- It will be for rewriting Perl, exclusively, using PPI, with Perl-centric
rules, so Code is not an appropriate namespace. (I don't think the PPI
namespace is appropriate, since in theory, it could use something else.
Note also Perl::Tidy and Perl::Critic.)

- It will be for modifying actual script/module files, as opposed to
modifying code on the fly, so Filter is not an appropriate namespace.

- Perl::Transform is good name, but I think means the same thing as
Rewrite.  Since the latter is shorter, it wins. (I don't like the way
Perl::XForm looks, and that makes it look like it has something to do
with forms in X-Windows.)

- I'm thinking Perl::Rewrite is the best name, for now, since it rewrites
code using PPI. Bit by bit I will develop it on GitHub
https://github.com/robrwo/Perl-Rewrite - for now it just has some stub
rules, until I flesh out the interface etc.

Regards,
Rob

On Sat, Aug 31, 2013 at 6:11 AM, Robert Rothenberg r...@cpan.org wrote:

 At $work, I've been writing scripts that use PPI to munge massive amounts
 of legacy code. So far simple things like changing die/warn to croak/carp,
 ensuring all modules specify a minimum version number, or changing print
 foo\n so say foo, etc. It seems worthy enough to turn this code into a
 CPAN module.

 My thoughts are that it would use a plugin system for specific tasks, and
 a command-line script that takes plugin names as arguments, so basically
 you'd run the script to apply various tasks to a set of modules or scripts
 in a directory, perhaps using a configuration file for each of the plugins.

 The early version would have simple plugins, but there's no reason why
 more complex plugins couldn't be written (e.g. to translate a non-Moose
 class into something Moose-like), or other things like optimize certain
 kinds of expressions.

 I'm well aware of the limitations of doing this automatically. But the
 idea is to get a script that can do the bulk of the tedious rewriting, so
 that a human can clean up the mistakes. It's meant to be run by intelligent
 people who use things like version control and tests.

 So what should it be called? I'm thinking Perl::Rewrite is the best name.

  Alternatives are:
  - Perl::Refactor - except refactoring has a technical meaning that I
 don't think applies
  - Perl::Modernize - except that one might want a plugin that translates
 newer-style code into older code
  - Perl::Munge - except that it connotes sloppiness
  - Perl::Snorft - no, just kidding I have no idea what that means.
  - ?

 Thanks,
 Rob

What to call a module that rewrites Perl code

[Robert Rothenberg]

At $work, I've been writing scripts that use PPI to munge massive amounts
of legacy code. So far simple things like changing die/warn to croak/carp,
ensuring all modules specify a minimum version number, or changing print
foo\n so say foo, etc. It seems worthy enough to turn this code into a
CPAN module.

My thoughts are that it would use a plugin system for specific tasks, and a
command-line script that takes plugin names as arguments, so basically
you'd run the script to apply various tasks to a set of modules or scripts
in a directory, perhaps using a configuration file for each of the plugins.

The early version would have simple plugins, but there's no reason why more
complex plugins couldn't be written (e.g. to translate a non-Moose  class
into something Moose-like), or other things like optimize certain kinds of
expressions.

I'm well aware of the limitations of doing this automatically. But the idea
is to get a script that can do the bulk of the tedious rewriting, so that a
human can clean up the mistakes. It's meant to be run by intelligent people
who use things like version control and tests.

So what should it be called? I'm thinking Perl::Rewrite is the best name.

 Alternatives are:
 - Perl::Refactor - except refactoring has a technical meaning that I
don't think applies
 - Perl::Modernize - except that one might want a plugin that translates
newer-style code into older code
 - Perl::Munge - except that it connotes sloppiness
 - Perl::Snorft - no, just kidding I have no idea what that means.
 - ?

Thanks,
Rob

Idea for a module: Test::Prereq::MiniCPAN

[Robert Rothenberg]

This module would be based on Test::Prereq, but instead of looking in a
Makefile.PL, it would look in a Mini-CPAN (based on the CPAN, CPANPLUS
configuration) and see if the module was specified in the 02packages list.

Re: Need suggestions for a module name

[Robert Rothenberg]

In case you are interested, a prototype is on GitHub at
https://github.com/robrwo/File-Temp-Trace

On Sun, Jun 19, 2011 at 12:51 AM, Bill Ward b...@wards.net wrote:
 Oh, I thought it was just about generating the filename using the
 module/subroutine name. *that* should be in File::Temp, and maybe the other
 features you describe should be in a new module?

 On Sat, Jun 18, 2011 at 6:44 PM, Robert Rothenberg r...@cpan.org wrote:

 It has a different interface, necessarily. File::Temp only manages single
 temp files or directories in isolation, whereas my module manages a set of
 them with logs about how they were created.

 On 18 Jun 2011 23:44, Bill Ward b...@wards.net wrote:
  It's not really that high level or specialized. It's just a matter of
  updating how the file name is generated. I could easily see it going
  either
  way. If you do go with a separate module, the interface should be the
  same
  (with whatever added options needed to add the new features) as
  File::Temp,
  for reduced confusion.
 
  On Sat, Jun 18, 2011 at 5:36 PM, Robert Rothenberg r...@cpan.org
  wrote:
 
  The module makes use of File::Temp, but the interface is different,
  and I don't think it makes sense to add specialised high-level
  functionality to a low-level module.
 
 
  On Sat, Jun 18, 2011 at 4:42 PM, Bob Parker b...@perldevgeek.com
  wrote:
  
  
   -Original Message-
   From: Robert Rothenberg r...@fastmail.net
   Reply-To: Robert Rothenberg at CPAN r...@cpan.org
   Date: Thu, 16 Jun 2011 21:23:50 +0100
   To: Perl Module Authors List module-authors@perl.org
   Subject: Need suggestions for a module name
  
  While debugging a project that generated a lot of temporary files, I
   came
  upon a nifty idea: rather than name the temporary files the usual
   random
  strings, why not have the files named by the method/function that
   created
  them, e.g. instead of something like /tmp/Hf6254d85.txt, why not call
   it
  /tmp/Some_Package_Name/text_analysing_function-Hf6254d85.txt.
  
  Anyhow, I think this might be something worth uploading to CPAN.
  
  So what should it be called?
  
  I was thinking of something like File::Temp::Smart, for lack of a
   better
  name. But I am open to better ideas.
  
  Suggestions?
  
  Rob
  
   Rob, rather than creating a brand new module for this, perhaps you
   could
   work with Tim Jenness to add this functionality to the existing
  File::Temp
   module as a non-default exported function and/or OO interface method?
   It
   seems like it would be useful enough that it would be fairly common
   for
   folks to use, once they realize what it is, so why make them install
   yet
   another module (assuming he agrees, of course).
  
   Obviously it could be done using the existing template functions, but
   to
   do it automatically with an option to use directories or just the
   file
   name would certainly save a lot of time  code rewriting, at least
   IMHO.
  I
   know I've done it at least 3 or 4 times, as recently as 3 weeks ago.
  
   Just a thought,
  
   Bob
  
  
  
 
 
 
 
  --
  Check out my LEGO blog at http://www.brickpile.com/
  View my photos at http://flickr.com/photos/billward/
  Follow me at http://twitter.com/williamward



 --
 Check out my LEGO blog at http://www.brickpile.com/
 View my photos at http://flickr.com/photos/billward/
 Follow me at http://twitter.com/williamward

Re: Need suggestions for a module name

[Robert Rothenberg]

Thank you for the suggestions.

Like Nadim Khemir, I also think that adding an option so that there is also
a log file that gives a stack trace associated with each temp file is useful.

The prototype uses attributes to flag a subroutine as not used in naming,
e.g. if you have a method create_temp_file() that is called by other
methods, you want those other methods instead.


So I am thinking that File::Temp::Devel or File::Temp::Trace may be a better
name, since it will be of most use to developers.

Regards,
Rob

On 16/06/11 21:23 Robert Rothenberg wrote:
 While debugging a project that generated a lot of temporary files, I came
 upon a nifty idea: rather than name the temporary files the usual random
 strings, why not have the files named by the method/function that created
 them, e.g. instead of something like /tmp/Hf6254d85.txt, why not call it
 /tmp/Some_Package_Name/text_analysing_function-Hf6254d85.txt.
 
 Anyhow, I think this might be something worth uploading to CPAN.
 
 So what should it be called?
 
 I was thinking of something like File::Temp::Smart, for lack of a better
 name. But I am open to better ideas.
 
 Suggestions?
 
 Rob

Re: Need suggestions for a module name

[Robert Rothenberg]

The module makes use of File::Temp, but the interface is different,
and I don't think it makes sense to add specialised high-level
functionality to a low-level module.


On Sat, Jun 18, 2011 at 4:42 PM, Bob Parker b...@perldevgeek.com wrote:


 -Original Message-
 From: Robert Rothenberg r...@fastmail.net
 Reply-To: Robert Rothenberg at CPAN r...@cpan.org
 Date: Thu, 16 Jun 2011 21:23:50 +0100
 To: Perl Module Authors List module-authors@perl.org
 Subject: Need suggestions for a module name

While debugging a project that generated a lot of temporary files, I came
upon a nifty idea: rather than name the temporary files the usual random
strings, why not have the files named by the method/function that created
them, e.g. instead of something like /tmp/Hf6254d85.txt, why not call it
/tmp/Some_Package_Name/text_analysing_function-Hf6254d85.txt.

Anyhow, I think this might be something worth uploading to CPAN.

So what should it be called?

I was thinking of something like File::Temp::Smart, for lack of a better
name. But I am open to better ideas.

Suggestions?

Rob

 Rob, rather than creating a brand new module for this, perhaps you could
 work with Tim Jenness to add this functionality to the existing File::Temp
 module as a non-default exported function and/or OO interface method? It
 seems like it would be useful enough that it would be fairly common for
 folks to use, once they realize what it is, so why make them install yet
 another module (assuming he agrees, of course).

 Obviously it could be done using the existing template functions, but to
 do it automatically with an option to use directories or just the file
 name would certainly save a lot of time  code rewriting, at least IMHO. I
 know I've done it at least 3 or 4 times, as recently as 3 weeks ago.

 Just a thought,

 Bob

Re: Need suggestions for a module name

[Robert Rothenberg]

It has a different interface, necessarily. File::Temp only manages single
temp files or directories in isolation, whereas my module manages a set of
them with logs about how they were created.
On 18 Jun 2011 23:44, Bill Ward b...@wards.net wrote:
 It's not really that high level or specialized. It's just a matter of
 updating how the file name is generated. I could easily see it going
either
 way. If you do go with a separate module, the interface should be the same
 (with whatever added options needed to add the new features) as
File::Temp,
 for reduced confusion.

 On Sat, Jun 18, 2011 at 5:36 PM, Robert Rothenberg r...@cpan.org wrote:

 The module makes use of File::Temp, but the interface is different,
 and I don't think it makes sense to add specialised high-level
 functionality to a low-level module.


 On Sat, Jun 18, 2011 at 4:42 PM, Bob Parker b...@perldevgeek.com wrote:
 
 
  -Original Message-
  From: Robert Rothenberg r...@fastmail.net
  Reply-To: Robert Rothenberg at CPAN r...@cpan.org
  Date: Thu, 16 Jun 2011 21:23:50 +0100
  To: Perl Module Authors List module-authors@perl.org
  Subject: Need suggestions for a module name
 
 While debugging a project that generated a lot of temporary files, I
came
 upon a nifty idea: rather than name the temporary files the usual
random
 strings, why not have the files named by the method/function that
created
 them, e.g. instead of something like /tmp/Hf6254d85.txt, why not call
it
 /tmp/Some_Package_Name/text_analysing_function-Hf6254d85.txt.
 
 Anyhow, I think this might be something worth uploading to CPAN.
 
 So what should it be called?
 
 I was thinking of something like File::Temp::Smart, for lack of a
better
 name. But I am open to better ideas.
 
 Suggestions?
 
 Rob
 
  Rob, rather than creating a brand new module for this, perhaps you
could
  work with Tim Jenness to add this functionality to the existing
 File::Temp
  module as a non-default exported function and/or OO interface method?
It
  seems like it would be useful enough that it would be fairly common for
  folks to use, once they realize what it is, so why make them install
yet
  another module (assuming he agrees, of course).
 
  Obviously it could be done using the existing template functions, but
to
  do it automatically with an option to use directories or just the file
  name would certainly save a lot of time  code rewriting, at least
IMHO.
 I
  know I've done it at least 3 or 4 times, as recently as 3 weeks ago.
 
  Just a thought,
 
  Bob
 
 
 




 --
 Check out my LEGO blog at http://www.brickpile.com/
 View my photos at http://flickr.com/photos/billward/
 Follow me at http://twitter.com/williamward

Need suggestions for a module name

[Robert Rothenberg]

While debugging a project that generated a lot of temporary files, I came
upon a nifty idea: rather than name the temporary files the usual random
strings, why not have the files named by the method/function that created
them, e.g. instead of something like /tmp/Hf6254d85.txt, why not call it
/tmp/Some_Package_Name/text_analysing_function-Hf6254d85.txt.

Anyhow, I think this might be something worth uploading to CPAN.

So what should it be called?

I was thinking of something like File::Temp::Smart, for lack of a better
name. But I am open to better ideas.

Suggestions?

Rob

Mozilla::Profile

[Robert Rothenberg]

I would like to split off Mozilla::ProfileIni from the Mozilla-Backup 
distribution and include it with Mozilla::Prefs::Simple, make use of some 
other modules (e.g. *::Mork ones) for a package which queries and 
manipulates Mozilla profiles.


I don't see anything controversial about the namespace, but for to please 
the namespace-reservation process, and mentioning the topic here.


Any issues with the namespace?

Rob

Re: Mozilla::Profile

[Robert Rothenberg]

On 05/01/08 22:47 Guy Hulbert wrote:

On Sat, 2008-01-05 at 19:56 +, Robert Rothenberg wrote:
I would like to split off Mozilla::ProfileIni from the Mozilla-Backup 
distribution and ...


I was thinking about uploading an INI module myself.  So this post
prodded me to run a search on Cpan ... there appear to be at least 60
different ones and I looked at a few of them.  Of course, none of the
ones I found works the same way as mine would work ...


Um, a slight misunderstanding. I'd use one of the existing INI modules to 
read the profiles.ini, but the hard part is finding where the various 
Mozilla profiles are stored.  Things relating to Mozilla profiles, such as 
whether they are locked, user preferences, etc. go beyond reading an INI module.


Rob

Idea: Test::Bundle module

[Robert Rothenberg]

I'm thinking that an alternative to N/A or UNKNOWN test reports for
Bundle::* modules is to have a Test::Bundle module which does some
rudimentary tests on a bundle:

 - check that NAME, SYNOPSIS, CONTENTS, DESCRIPTION and AUTHOR
   sections are present
 - check that all of the modules listed in the CONTENTS section
   exist on CPAN

I'm assuming tests on the Pod would be done separately.

The only issue with this is that CPAN will run the tests, which for some may
be redundant (particularly with checking that contents exist).

Comments?

Rob

Re: I think we can just scrap CPAN Ratings altogether

[Robert Rothenberg]

I quite like CPAN Ratings, and find that most of the ratings are useful.
That there is some junk in there is no reason to kill it off.

An improvement would be to turn it into a forum, maybe merge with CPAN
forums but keeping reviews separate from technical support questions. (Bad
reviews such as how do I compile module X can be moved into technical
support forums too.)  Reviews that are voted as useless can be culled by
moderators.

Rob

A. Pagaltzis wrote:

 This sort of thing is lunacy. What's the point of MODULE REVIEWS
 if they're going to be turned into crusade vehicles?
 
 I am writing to this list instead of responding in a no-rating
 review over there precisely because that would be abuse of the
 system – of course, that means the visibility of my response is
 much smaller than that of Adam's ill-considered vigilantism.

Re: Module::Signature issues

[Robert Rothenberg]

Even so, there are problems.  How many users know to change their
keyservers? (I wasn't aware of a need to do this until I ran across this
problem.)

When it cannot find the key, the software James is using (CPAN or CPANPLUS)
reports it as

 gpg: Total number processed: 0
 gpg: Can't check signature: public key not found
 =3D=3D BAD/TAMPERED signature detected! =3D=3D

rather than saying unable to check signature, it says BAD/TAMPERED
signature detected.  That's wrong.

CPANPLUS reports this as a failure to CPAN Testers, which is annoying. (I
believe this will be fixed in a later version, though.)

Audrey mentioned (on CPAN Ratings) some bugs with regards to end-of-line
issues were fixed in the latest version.  I'm sure there are some
workarounds to use a different keyserver by default to handle the subkey
problem.

So I might (re)start signing modules when these issues are fixed.

But I think in the long term, the trust issue should be taken care of.
I've not heard any feedback on this yet.

Darren Chamberlain wrote:

 Robert said he's signing his modules with a subkey, and the MIT key
 sever (IIRC) does not support subkeys.  If you use a different
 keyserver, you'll find the key:
 
   $ grep ^keyserver ~/.gnupg/gpg.conf
   keyserver hkp://subkeys.pgp.net
 
   $ gpg --search 0xBB72D9C5
   Keys 1-2 of 2 for 0xBB72D9C5
   (1) Robert Rothenberg (CPAN) rrwo[at]cpan.org
   1024 bit DSA key 5DB01E18, created 2005-11-09
   (2) Robert Rothenberg robrwo[at]gmail.com
   1024 bit DSA key 5DB01E18, created 2005-11-09
 
 The main key ID is 5DB01E18.  If you grabbed this key from the MIT
 keyserver, you could probably verify the signature on Pod::Readme
 0.08, assuming the MIT keyserver passed through the subkeys
 unmolested.

Re: Module::Signature issues

[Robert Rothenberg]

I'm reminder of one other issue: there are Windows vs Unix end-of-line
issues that it sometimes chokes on.

I've just re-released Pod::Readme without a signature, because the signature
problems are choking up Module::Build users.

On 05/07/2006 05:10 AM James E Keenan wrote:

 I don't claim to understand the security issues well.  I just know that
 on my laptop I'm never successful in installing Module::Build,
 PathTools, etc., with the cpan shell.

Re: Module::Signature issues

[Robert Rothenberg]

On 05/07/2006 02:34 PM Ken Williams wrote:

 I've just re-released Pod::Readme without a signature, because the
 signature problems are choking up Module::Build users.
 
 Module::Build doesn't do anything with signatures - all it knows how to
 do is generate a signature file when building a distribution.  I'd
 suspect that the failures have more to do with the version of CPAN or
 CPANPLUS users have.  Or if it's M::B in some way I don't understand, do
 you have any error output?

It's CPAN/CPANPLUS, but M::B users are installing P::R

Re: Naming advice: parse info out of Build.PL/Makefile.PL

[Robert Rothenberg]

I think the Module::* namespace is the preferred namespace for things that
analyze packages.

FYI, there already is a Module::MakefilePL::Parse with a similar function,
though it doesn't use PPI. (I've not updated it in a long time, since I've
put the project that used it on the back burner ;)

Perhaps Module::MakefilePL::Parse::PPI and Module::BuildPL::Parse::PPI?

Rob

Version number preferences

[Robert Rothenberg]

I prefer the three-number style version numbering (e.g. 1.2.3) but due to
problems with older versions of Perl I've gotten into the habit of using
decimal style numbering.

I'm thinking of releasing my next package on CPAN using the three-number
style, but I'm concerned about compatibility.

I've noticed many module authors still release new modules using the older
style.  Is this also out of habit, or preference?

I'm looking for arguments for and against using the three-number version.
Has anyone written anything on that already?

Module name - File::Trash::FreeDesktop

[Robert Rothenberg (CPAN)]

I am unsure what to name a module that implements the freedesktop.org Trash
standard.

Freedesktop::Trash seems to be the obvious name, but there's nothing in the
Freedesktop top-level namespace.

X11::Trash might make more sense, but it doesn't use anything X11-specfic.
It could just as well be used in a console-only environment.

File::Trash is inappropriate, since it doesn't do anything for Windows or
Mac trashcans.

I don't want to use Linux in the name since FreeDesktop isn't Linux-specfic,
or even Unix-specific. (If somebody really wanted, they could use this
easily on Windows or Macs.)

File::Trash::FreeDesktop seems the best name to me.

Comments? Flames?

Rob

Mozilla::Backup Perl package in need of a new maintainer

[Robert Rothenberg (CPAN)]

I am looking for somebody to take over maintenance of the Perl package
Mozilla::Backup, which is useful for reading information about and backing
up or restoring the profiles of various Mozilla-based applications.

It really needs to have the profile-handling code broken off into a separate
module. I don't have the time to update or maintain it.

The latest release on CPAN is at http://search.cpan.org/dist/Mozilla-Backup/
although there's also a SourceForge project at http://mozilla-backup.sf.net/
with some newer (though not necessarily working) code on CVS.

(If you take over maintenance, you might consider moving the project from
SourceForge to MozDev at http://www.mozdev.org/)

Regards,
Rob

Win32 modules in search of maintainers

[Robert Rothenberg]

FYI,

I've given up on using Windows (hooray! boo! yawn) for a while, and so 
have a few Win32 modules which I will be unable to maintain for the 
foreseeable future:


  Log::Dispatch::Win32EventLog
  Win32::EventLog::Carp
  File::HomeDir::Win32

If you or anyone you know would care to take over maintenance of any of 
these modules, please contact me.


(Actually, Log::Dispatch::Win32EventLog is owned by Arthur Bergman who 
is CC'd in this message.  So if you care to take over that module, 
please contact him directly.)


Regards,
Rob

Re: Checking for boilerplate

[Robert Rothenberg]

Perhaps a Test::Boilerplate module is in order, which can be used by 
Module::Starter, Module::Release, CPANTS, PAUSE, and any other place 
that somebody deems it necessary.


That was my original idea anyhow.

Re: RFC - Test::Stupid module

[Robert Rothenberg]

What do you think about Module::Starter also building, by default, a
test file that checks for the boilerplate text?


Now *that* is a great idea!

Re: RFC - Test::Stupid module

[Robert Rothenberg]

The problem is that authors use boilerplates. With Module::Starter there 
are lots of modules with abstracts The great new [modulename]. No 
matter what wiz-bang new module starter system somebody comes up with, 
there will be some kind of boilerplate text.  Unless maybe it asks you 
to write the documentation before you write the module.  (Fine for some 
developers, but not everyone.)


I do think this is appropriate for something that Module::Build to use 
before building distributions.  This is the most natural place for such 
tests, and if it's run as part of the Build dist process, then one 
doesn't need to worry about forgetting to run it.


Of course there should be options to override it (either by explicitly 
telling it to ignore files or setting some option to disable it).


The purpose of it isn't to stop the author from building a distribution, 
but to warn the author before uploading it.


If the utility is used by PAUSE or CPANTS, that might be good too.

RFC - Test::Stupid module

[Robert Rothenberg]

I'm rather annoyed by the spate of CPAN uploads which have defaults from 
h2xs or Module::Install that are not edited, things like Perl extension 
for blah blah blah or A. U. Thor.  In other words, stupid mistakes.


So I've been toying ideas for a module which checks for files which 
match regexps of known defaults.  Maybe also check that the ChangeLog 
has a version which matches the VERSION in the POD (since authors often 
forget to update it).


There will be a simple script for authors to run so that it checks for 
these things.


I'm actually thinking of calling it something more polite like 
Test::Defaults but then there is something pleasantly twisted about 
encouraging authors to run a script called amistupid before uploading 
a distribution.


Perhaps a Module::Build utility could run this script before building a 
distribution and giving a warning.


Disclaimer: I've made these kinds of stupid mistakes in the past, so 
this is not a slight on any particular author or the quality of her/his 
work.


Comments/suggestions would be helpful.

Re: RFC - Test::Stupid module

[Robert Rothenberg]

I don't think patches to Module::Starter or similar packages will help. 
 The problem isn't with the starter utilities, it's what comes out the 
other end when distributions are built. (So an eventual patch for 
Module::Build, perhaps?)


Anyhow, when a prototype is ready I'll post an announcement. Probably 
the final name will be something like Test::ForBoilerPlates.


Rob

Request for Comments - Tree::Node module?

[Robert Rothenberg]

In rewriting the node class for Algorithm::SkipList in C, it occurred to 
me that the node class would be useful for other tree and linked-list 
modules which require a key/value pair and some pointers to child nodes.


Because it's written in C, it uses less memory than a hash variable 
(which is what makes it worthwihile to use some kind of tree class).


Does this seem worthwhile?

Regards,
Rob

Re: Fw: Failing Reports due to 3rd Party Software...

[Robert Rothenberg]

On 17/06/2005 09:14 Michael G Schwern wrote:


This is all a bit of a ramble.  Could we have an executive summary as to
the point particularly in relation to MakeMaker, CPANPLUS and module authors
in general?


CPANPLUS issues FAIL reports when there is no C compiler, which irks
module authors who feel such reports make their module look bad.

Some feel that CPANPLUS should detect this and not send a report, others 
feel it should send a report, but with a different grade: NA or some new 
grade such as UNGRADED, since there are advantages to testing what a 
Build will do if there is no C compiler.


Another idea is to ExtUtils::MakeMaker or Module::Build to refuse to try 
and build a module if a C compiler is required (and update CPANPLUS to 
detect this).  This seems connected to the larger issue of NA reports 
when libraries or applications are missing.


I'm of the opinion that people who pay attention to test reports when 
deciding whether to use a module should be saavy enough to interpret 
them, but I'm probably wrong. Maybe a FAQ is needed for the testers web 
site that explains how to do this?


My own take is that these fails should be sent out anyway, but as NA 
reports.  Too many grade types can get confusing, but it should be 
feasible to analyze failure reports automatically to classify them:

 * Perl version too low
 * Unsupported operating system
 * Missing required libraries or applications
 * Missing compiler, linker or other utility needed for build
 * Other error during build

In other words, the meaning of NA should be it wasn't able to 
successfully build the software and get to the testing phase.


Rob

ANNOUNCE - Pod::Readme

[Robert Rothenberg]

An initial version of Pod::Readme has been uploaded to CPAN. It can be 
found at http://search.cpan.org/~rrwo/Pod-Readme-0.01/

This version does not yet have meaningful tests (*gasp*) and does not 
automatically generate a REQUIREMENTS or INSTALLATION section.

Feedback and suggestions would be appreciated.
Rob

Idea for a module - Test::Log::Dispatch

[Robert Rothenberg]

I have a class whose constructor accepts a Log::Dispatch object to send 
log-messages to.

I would like to write some tests for the logging behavior. I have in 
mind a specialised subclass of Log::Dispatch::Output which also has test 
methods.

Before I do any more work on this module, is there already something 
like this? (I know there are modules to test warnings and output, but 
I'm looking for something specifically that will hook onto Log::Dispatch 
and maybe Log::Log4perl.)

The way this module would work is something like:
  use Test::Log::Dispatch;
  use Log::Dispatch;
  # log_tester is a reference to a singleton Log::Dispatch::Output
  # class that collects log messages.
  my $log = Log::Dispatch-new()-add(log_tester);
  my $obj = Some::Class-new( log = $log );
  # Do stuff that one would expect generates log messages
  log_ok( { level = 'warn', message = 'ouch' },
ouch warning);
The test takes a hash of log parameters to check against the last log 
event. If one of them fails, the test fails.

An issue is what kind of interface to implement.  I'm thinking aside 
from log_ok to have log_like() for testing Regexps.

I'm trying to think about the semantics to differentiate between 
checking if an event has occurred at all vs. checking the last event.

Comments/suggestions appreciated.
Thanks,
Rob

Re: How to force tests to issue NA reports?

[Robert Rothenberg]

Same here.
On 08/04/2005 20:02 Ken Williams wrote:
On Apr 8, 2005, at 12:32 PM, Michael G Schwern wrote:
die NA: $reason;
Since, at the moment, we're having trouble putting together a system to
cover the possible reasons for an NA report let the module author 
figure it
out.  Its simple and minimal.

I like it.

Re: Should DSLIP codes be updated?

[Robert Rothenberg]

On 29/03/2005 22:14 Andy Lester wrote:
Mea culpa.  I'll rephrase.
Or thrown away entirely, along with the rest of the archaic idea of
module registration.
The time has come to recognize that CPAN is an unregulated free-for-all,
and that the existing way of trying to wrap our heads around its
contents hasn't scaled and needs to go away.  The good parts (knowing
who is authoritative for a module) need to get pulled out, and put into
a new system.
I'm sympathetic to the idea, but some of the information in DSLIP is 
useful and shouldn't be thrown away (such as how supported, 
alpha/beta/mature, and license). What isn't in META.yml should go there.

Other things such as interface style could be determined automatically, 
though it may take hints from developers.  I'm not sure if it really 
matters if a module uses embedded Java, Perl6, Lisp, or whatever so long 
as it works.

What's more important is how to indicate what external programs or 
libraries a module uses.  (As a CPAN Tester this is the biggest bugbear!)

Support information is a little more nuanced, and I'm not sure how that 
should be handled.

Rob

Module::Phalanx100

[Robert Rothenberg]

FYI, I've uploaded Module::Phalanx100 to CPAN in to
  $CPAN/authors/id/R/RR/RRWO/Module-Phalanx100-0.01.tar.gz
It simply contains a list of the Phalanx distributions from the project 
web site at http://qa.perl.org/phalanx/.

It's provided so that anyone who needs a consistent list can use it 
rather than importing a new list.

(Of course the module will beed to be updated when a new Phalanx 100 
list is updated.)

Regards,
Rob

Re: Module Class::Stringify?

[Robert Rothenberg]

I'd have to double-check the overload documentation again, but I don't think 
overload derives cmp from string conversion, so you have to check for cmp as well.

It doesn't seem to work.  I think because the method isn't named '', it's 
just how it's set up with overload. (I have not delved into the internals of 
overload.)

This is simpler:
  sub is_string_like {
return 1 unless ref($_[0]);
return eval {
  ($_[0])  (($_[0] cmp $_[0])==0);
};
  }
I'm of the impression that Class::Stringify is a dead issue.  Maybe just 
modifying overload to derive cmp.


On 14/11/2004 13:29 Tim Bunce wrote:
This all seems overkill. Isn't something like this (untested) enough?:
sub is_string_like {
return 1 unless ref $_[0]; # returns 1 for undef
return UNIVERSAL::can($_[0], '');
}
Tim.

Module Class::Stringify?

[Robert Rothenberg]

I've noticed that when authors validate string values as inputs, they often 
check that the value is not a reference.

The problem is that it disallows objects that are overloaded to behave like 
strings.

It's relatively easy to check that an object behaves like a string, and I have 
some code for testing this (below, for your amusement).

But it's not just a matter of getting module authors to change how they check 
for strings, but also making it easier for module authors to stringify their 
classes so they behave like strings for comparisons and sorting.

So I have an idea for a module called Class::Stringify that would do the 
following as a base class for a module:
(1) if the class doesn't have the stringification operator overloaded, die
since it's the bare minimum
(2) if the class doesn't have the cmp operator overloaded, define it using
the stringification operator:  $a cmp $b
(3) if the class doesn't have the eq, ne, le, lt, ge, gt operators overloaded,
define them using the cmp operator

There are some variations on this where a class might have lt (or gt) and eq 
(or ne) defined which can be used to define cmp and the others.  And I'm 
guessing that with some thought I could come up with a smart way to define the 
 operations that need to be defined.

The rationale for such a module is to (1) encourage authors to test things for 
stringiness rather than assume a string is not a reference when strings are 
required, so that their software becomes much more powerful and (2) assist 
other authors to make their objects behave like strings where appropriate.

Obvious questions:
(1) Is there such a module already? I'd rather not waste my time
(2) Better namespace?
(3) Comments/criticisms/suggestions?
Reference: some code for testing if an argument is string-like:
sub is_string_like {
  return 1,
unless (defined $_[0]  ref $_[0]);
  # We don't evaluate whether the . and .= operators are
  # supported, since for many applications that use strings, the
  # comparison operators are the most important.
  eval {
($_[0])
   (($_[0] cmp $_[0])==0)
   ($_[0] eq $_[0])
   (!($_[0] ne $_[0]))
   (!($_[0] le $_[0]))
   (!($_[0] ge $_[0]))
   (!($_[0] lt $_[0]))
   (!($_[0] gt $_[0]))
  } and return 1;
  # Testing for behavior related to copy constructors is another issue
  # to be determined
  return;
}

Re: Module Class::Stringify?

[Robert Rothenberg]

In reading the overload manpage again, I realized that it attempts to define 
 the comparison operators based on cmp operator if they are not there.  (Or 
is supposed to, though some of my tests on the subroutine below show that it 
fails if not all of the comparisons are defined.)

On 14/11/2004 09:21 Robert Rothenberg wrote:
So I have an idea for a module called Class::Stringify that would do 
the following as a base class for a module:
(1) if the class doesn't have the stringification operator overloaded, die
since it's the bare minimum
(2) if the class doesn't have the cmp operator overloaded, define it using
the stringification operator:  $a cmp $b
(3) if the class doesn't have the eq, ne, le, lt, ge, gt operators 
overloaded,
define them using the cmp operator

There are some variations on this where a class might have lt (or gt) 
and eq (or ne) defined which can be used to define cmp and the others.  
And I'm guessing that with some thought I could come up with a smart way 
to define the  operations that need to be defined.

Renaming module - Algorithm::SkipList

[Robert Rothenberg]

I have a module called List::SkipList which has been on CPAN for quite a 
while.  I'm thinking of renaming it to Algorithm::SkipList, which seems more 
appropriate (and nobody said yeah or nay to my request for the List::SkipList 
namespace on [EMAIL PROTECTED]).

Does anyone consider that an inapropriate name?
FYI, I will be providing a List::SkipList distribution with that which will 
use Algorithm::SkipList as a bad but provide warnings about using a deprecated 
module name.

Re: Renaming module - Algorithm::SkipList

[Robert Rothenberg]

As per various comments:
I agree with Ken (hence why I suggested the namespace). Most data structures 
have corresponding algorithms.  There is already an Algorithm namespace, but 
no Datastructure namespace.

Data seems to be full of random things, usually related to debugging, data 
persistence or presentation.

List isn't good because it impliesthat it deals with Perl lists.
I thought about putting it in the Tree space, since tecnically a skip list is 
a redundant tree, and people looking for tree algorithms might find skip lists 
useful... but unless they know what a skip list is and are already looking for 
it, I'd be accused of spamming the namespace.  So that's not a good idea. 
(And most of the Tree modules probably belong in Algorithm anyway).

Rob
On 7/31/2004 11:05 AM Ken Williams wrote:
On Jul 30, 2004, at 1:35 PM, Robert Rothenberg wrote:

I have a module called List::SkipList which has been on CPAN for quite 
a while.  I'm thinking of renaming it to Algorithm::SkipList, which 
seems more appropriate (and nobody said yeah or nay to my request for 
the List::SkipList namespace on [EMAIL PROTECTED]).

Does anyone consider that an inapropriate name?

That's exactly the right name.
I think the comments about data structure vs. algorithm are misplaced 
- a skiplist (as you know) is both a data structure and an algorithm, 
either without the other would be a bit silly.

 -Ken

Re: Module name: WWW-ISBNReference

[Robert Rothenberg]

I am working on a module that can query isbnreference.org for information 
about a particular book.
have you thought about working with Ed Summers to put that into
Business::ISBN ?
I have joined the isbnsearch-devel list that maintains the software for 
isbnreference and have brought up the idea on that list.

I don't think it's appropriate to merge with Business::ISBN, which just deals 
with ISBN data.  The isbnsearch system is a distributed, open-source 
isbn-lookup system for bibliographic data.

It accomplishes the same thing as Net::Amazon only using public domain data.

Design philosophy (was Re: Module name: WWW-ISBNReference)

[Robert Rothenberg]

Looking at the docs and source forge page, Business::ISBN seems to just deal 
with ISBN information. Have I missed something?

Which I think is fine: I rather like the philosophy that a tool should do just 
one thing (or maybe a few closely-related things) really well.  It's just a 
matter of plugging in the tools one needs.

I'd not be happy if I wanted to use Business::ISBN with Net::Amazon or one of 
the WWW::Scraper::ISBN modules or something else, but had extra stuff related 
to ISBNSearch (using LWP, and maybe Net::Z3950) and MARC format processing and 
a lot of bibliographic information that has nothing to do with ISBNs, except 
that it's a key to search for this information.

One of my pet-peeves with many CPAN modules is that they try to be everything 
for everybody, which means they make it harder for developers to customize to 
their needs.  So they write yet another module to do X


On 7/25/2004 2:26 AM brian d foy wrote:
On Sun, 25 Jul 2004, Robert Rothenberg wrote:
I don't think it's appropriate to merge with Business::ISBN, which 
just deals with ISBN data.  The isbnsearch system is a distributed, 
open-source isbn-lookup system for bibliographic data.
 
Business::ISBN does much more than that.  Why not put all the ISBN stuff 
in one place?

Module name: WWW-ISBNReference

[Robert Rothenberg]

I am working on a module that can query isbnreference.org for information 
about a particular book.

isbnreference.org is an open-source ISBN lookup service.
As far as I know, there is no Perl module which uses isbnreference.org, 
although there are modules to support the Library of Congress Net::Z3950 
protocol that isbnreference.org uses.

Script to find Module Dependency Test Results...

[Robert Rothenberg]

I have a prototype Perl script that will determine the dependencies of a given 
CPAN distribution, and then check CPAN Testers for any failure reports of that 
distro or dependent distros for a given platform.

I would like to work with other people to turn this into something of use to 
the community, at the very least a module but ideally something that could be 
integrated with one of the CPAN-related web sites.  (I'm also starting 
graduate school in the fall and looking for people to take this idea and run 
with it, as I won't have as much time.)

For an example of what this does, if I ask it to search for dependencies for 
the disto 'Pixie', it tells me the following:

Pixie-2.06:
  DBIx-AnyDBD-2.01: {}
  Data-UUID-0.11: {}
  Test-Class-0.03:
Test-Differences-0.47:
  Text-Diff-0.35:
Algorithm-Diff-1.15: {}
Test-Exception-0.15:
  Sub-Uplevel-0.09: {}
  Test-Tester-0.09: {}
Test-Tester-0.09: {}
for Windows machines, it also tells me this:
Algorithm-Diff-1.15: []
DBIx-AnyDBD-2.01:
  - action: FAIL
distversion: DBIx-AnyDBD-2.01
id: 79987
platform: MSWin32-x86-multi-thread
report_url: |-
  http://nntp.x.perl.org/group/perl.cpan.testers/79987
version: 2.01
Data-UUID-0.11:
  - action: FAIL
distversion: Data-UUID-0.11
id: 145033
platform: MSWin32-x86-multi-thread
report_url: |-
  http://nntp.x.perl.org/group/perl.cpan.testers/145033
version: 0.11
  - action: FAIL
distversion: Data-UUID-0.11
id: 146960
platform: MSWin32-x86-multi-thread
report_url: |-
  http://nntp.x.perl.org/group/perl.cpan.testers/146960
version: 0.11
Pixie-2.06: ~
Sub-Uplevel-0.09: []
Test-Class-0.03:
  - action: FAIL
distversion: Test-Class-0.03
id: 144608
platform: MSWin32-x86-multi-thread
report_url: |-
  http://nntp.x.perl.org/group/perl.cpan.testers/144608
version: 0.03
Test-Differences-0.47: []
Test-Exception-0.15: []
Test-Tester-0.09: []
Text-Diff-0.35: []
In other words, there are no test reports for Windows users of Pixie, but 
that's likely because they can't get several distros that Pixie requires to 
work on Windows (Test-Class, DBIx-AnyDBD-2.01, and Data-UUID-0.11).

This information would be of use to various quality-assurance types, as well 
as the module author.  It's probably of use to module users too.

Re: [Module::Build] requires_one_of

[Robert Rothenberg]

On 7/18/2004 5:14 AM Smylers wrote:
 [...]
Rather than the dependent app (or module) having a list alternatives
that are known to work, it could instead depend on some 'abstract'
package.  Other distros are then able to say that they 'provide' that
abstract package.  So if another module is writtent that has equivalent
functionality and the same interface then it just needs to label itself
as 'provide'-ing that 'abstract' package, and the dependent app will
just work with it.
That requires the other distro authors to modify their packages.  If they 
don't, then the feature can't be used.

Take modules which interface with the serial port, for example. There's 
Win32::SerialPort (which hasn't been updated in years), and there's 
Device::SerialPort.  One is for Windows, the other for Unix and imitates the 
Windows interface.

So a module which needs the serial port requires either Win32::SerialPort or 
Device::SerialPort.

My only way around it for some of the GPS::* modules I wrote was to say it 
'recommends' both modules, which it really doesn't.

I could put a dynamic config in the Build.PL but that causes the Makefile.PL 
and META.yml to reflect the platform that the dist was built on.  Not good.

It makes more sense to say 'requires_one_of'.  Changes would only have to be 
made to the modules that handle builds and installation.  Nobody else needs 
change their distros unless they want to use that feature.

That nicely puts control of whether a distro provides certain
functionality in control of each distro's author; the knowledge is in
the system as a whole, and no one person has to keep an exhaustive list
up to date.
What one person needs to keep an exhaustive list?  An exhaustive list of what?
Expecting hundreds of CPAN authors to change their distros, and to have groups 
of them agree on abstract interfaces to provide, is not practical.

Also, David has an app that depends on something Pg-or-mysql-like;
suppose I do too, as do several other people.  When another
Pg-or-mysql-providing module appears it doesn't make sense for every
single one of us app authors to have to note this, tweak our install
settings, and upload a new version to Cpan; that's lots of duplicated
and redundant effort.
The choice as to whether to support another feature is up to a module author. 
 If you don't want to put the extra work in, don't.  Other authors would.

The obvious flaw in my proposal for this particular instance is that Pg
and mysql don't provide identical interfaces, so I'm guessing that David
hasn't written code that just happens to work with either of them but
has conditions in it specifically to deal with their differences.   To
make a 'provides' feature work, those differences would have to be
abstracted out elsewhere. ...

Module name? CPAN::Distribution::Depends

[Robert Rothenberg]

I am working on a module that when given a CPAN distribution, it will 
determine what modules that distribution depends on by scanning the META.yml 
file or if that one is not present, the Makefile.PL file.

Is that a good name for it?
It differs from existing modules in that it merely parses the Makefile.PL file 
rather than try to compile or run it and look for what modules it requests. 
For most modules on CPAN, it is quite adequate.

(The parsing module is actually Module::MakefilePL::Parse--which is already on 
CPAN, although that may not be the best name...)

The purpose of this is for a larger project that checks testing results from 
CPAN Testers for a module and specific platforms.  The lack of test results 
for some platforms is sometimes because needed modules do not work on specific 
platforms.  This information would be useful to module authors.

Thanks,
Rob

Re: Module name? CPAN::Distribution::Depends

[Robert Rothenberg]

On 7/16/2004 5:04 AM Randy W. Sims wrote:
I haven't really looked in detail, but I do know that there are a lot of 
modules that do this using various approaches. Are you sure you have 
looked at them all and that none are similar enough to use or extend 
instead of creating another module? 
I'm pretty sure I have looked at all the modules, and tried most of them (some 
do not work on Windows).  Again, they use a different technique

I think some of the modules that perform this task are in the Module::* 
namespace. That's shorter and seems more appropriate.
Maybe Module::ParseDeps (since there is already a Module::ScanDeps).
Module::* still seems like a misnomer, since really what I'm working on are 
distributions, but there is no Dist::, Distro:: or Distribution:: namespace 
and I'm not about to create it.

Rob