Re: CPAN and META.yml: no_index dir vs directory

[Randy W. Sims]

Andreas J. Koenig wrote:

On Wed, 5 Jul 2006 21:39:06 -0500, Ken Williams <[EMAIL PROTECTED]> said:


  > On Jul 5, 2006, at 7:47 PM, David Golden wrote:

 >> Some potential options:
 >> 
 >> (a) Add "directory" as a synonym to the spec and add "dir" as

 >> something that CPAN sites recognize.
 >> 
 >> (b) Change the spec to "directory" -- if CPAN sites are the only

 >> real user of META.yml no_index, then the pain should be minimal.
 >> 
 >> (c) Change CPAN sites to follow the spec, despite breaking many

 >> distributions' current indexing.


  > Randy Sims keeps some statistics on the META.yml files that exist on
  > CPAN, perhaps he could tell us the relative frequencies of 'dir' vs.
  > 'directory' in the wild?

The page is there, http://thepierianspring.org/perl/meta/, but does
not provide direct statistics so I made up my own.


Now it does. ;)


no_index/dir 13
no_index/directory 1397
private/directory40


My numbers are a bit different since I count only the most recent 
version of each distro rather than every occurrence on CPAN.


Hmm, it looks like there is a strong correspondence between distros 
using 'directory' and distros produced by Module::Install. There goes 
Adam, breaking rules and rebelling against established conventions.


Hehe. Just kidding. I think I like 'directory' better myself anyway.

Randy.

CPAN6 (was: A Semi-Public Version Control Repository for Your CPAN Modules)

[Randy W. Sims]

Sam Vilain wrote:

If you are in Europe in August, you might like to come to YAPC and see
the announcement of cpan6, this concern is included in the design
requirements and making small changes to other's code will be natural
and safe.

http://www.birmingham2006.com/cgi-bin/yapc.pl?act=talk-item&talkid=51


Has there been any public discussion of cpan6? I've only seen vague 
references and wishful posting. Will the design requirements be open to 
public review and comment before it's implemented?


Regards,
Randy.

Re: Testing an FTP module

[Randy W. Sims]

Scott W Gifford wrote:

I just uploaded to CPAN some FTP-related modules
(Net::FTP::AutoReconnect and Net::FTP::RetrHandle).  In one of the
unit tests, I connect to ftp.cpan.org and retreive MIRRORED.BY to make
sure everything works OK.

Just in the last little bit, though, I've noticed that a connection to
ftp.cpan.org is timing out.

So my questions are:

  * Is ftp.cpan.org a reliable way to access CPAN?  Is there a more
reliable way, besides looking and MIRRORED.BY?

  * Is testing by connecting to CPAN an appropriate thing to do?


I would guess not. Certainly not without asking permission.


  * If not, what's a better way to do unit tests for a network
protocol?


Write or bundle a tiny server, or query the user to provide an ftp server?


Thanks for any thoughts!

---ScottG.



Regards,
Randy.

Re: Games::RoundRobin::Schedule or Games::Schedule::RoundRobin

[Randy W. Sims]

Dr Bean wrote:

On Mon, 30 Jan 2006, A. Pagaltzis wrote:


* Dr Bean <[EMAIL PROTECTED]> [2006-01-30 13:30]:

Scoring, however, is perhaps another area that could have its
own module.



However, I think it’s not unnatural in the least to have a
Games::RoundRobin for scheduling and Games::RoundRobin::Scoring
for scoring.


Wouldn't that mean I would be claiming a name that a more
ambitious module had more right to use? libtour models a lot more
of the administration of a tournament, eg it allows for
preliminary rounds and finals, managed programmatically.


If anything, I’d be inclined to suggest
Games::Tournament::RoundRobin instead. You are referring to a
very specific kind of scheduling/scoring, a point which the
::Schedule/::Scoring namespaces don’t really capture,
irrespective of the level at which they appear.


I never really thought about that. I guess the reason I didn't
include 'Tournament' is because I wanted to keep the length of
the name down to 3 levels.

Perhaps I should call it Tournament::RoundRobin::Schedule. Most
of the content of the modules in the Games hierarchy have little
to do with the content of this module.


Generally, names are from generic to specific, so it'd be

Schedule::RoundRobin

 -or-

Algorithm::Schedule::RoundRobin

But that name can apply to many things, such as process scheduling[1]. 
If the algorithm is not generic enough to apply to anything, it needs 
more context (when naming: context on left, detail on right):


Sports::Schedule::RoundRobin

or similar...


1. 


Scheduling can include many things, eg dates and venues, but
timetable scheduling seems to be the name for software that makes
timetables, a similar sort of problem.

--
Dr Bean, Taiwan

Re: Looking for a name for a module

[Randy W. Sims]

David Golden wrote:

José Castro wrote:


 - you give it a set of texts (usually two, but can be more)
 - without knowing the language of each text, the module tells you how
   likely it is that those texts are translations of each other

It would probably be something in the "Text" of "Lingua" namespace, 
and it

would probably include something like "Translations" or "Parallel".



I tend to think of language things in Lingua and text processing in 
Text, so I'd lean towards Lingua.  After that, my first thought was the 
unwieldy:


Lingua::Translation::Identify

or

Lingua::Translation::Compare

I'm not sure if it makes sense to shorten it to the existing 
Lingua::Translate namespace for consistency sake:


Lingua::Translate::Identify
Lingua::Translate::Compare

As I look at this, I lean slightly towards "compare" since it definitely 
compares, but doesn't necessarily "identify".


Often, 'similar' is used in this context, algorithms that compare or 
rate things for equivelance.


Lingua::Text::Similar
Lingua::Translation::Similar

Regards,
Randy.

Re: Module::Build Question: Installing Templates in a user-specifiable directory

[Randy W. Sims]

Shlomi Fish wrote:

Hi all!


Hi Shlomi,

Sorry for the delayed response.

I've written a module using Module::Build and CGI::Application. I'm using 
several Template Toolkit templates all placed in one directory. (placed 
inside the module tree under "./templates/"). I'm setting this template 
directory to the default TT search path using "$self->tt_include_path()".


Now, I'd like to install this module in the path system eventually. The 
templates directory should be installed in someplace like 
"/usr/share/shlomif/myapp/templates", but one that can be over-rided by the 
installer, or calculated from various parameters like $DESTDIR, etc. 


There are a few ways to do this depending on how much flexibility you 
want. Some of this is detailed in Module::Build::Cookbook. The simplest 
method requires enumerating your custom files:


use strict;
use warnings;

# probe for directory for template files
sub tt_inc {
 # detect install path
 return '/var/tmp/templates';
}

use Module::Build;
my $builder = Module::Build->new(
 module_name  => 'Foo',
 license  => 'perl',

 install_path => {
 templates  => tt_inc(),
 },

 templates_files => {
 'templates/Foo.tt' => 'templates/Foo.tt',
 },
);

$builder->add_build_element( 'templates' );

$builder->create_build_script;

__END__

The method add_build_element() tells MB about a "type" of file it should 
know about. The 'install_path' entry in the constructor gives a default 
location where files of that type will be installed on the users system. 
The "${type}_files" entry (i.e. the "templates_files" entry in the 
example above) provides a map from the files location in the build 
directory to it's relative install path.


A slightly more complex version that doesn't require enumerating files 
might look like:


use strict;
use warnings;

use Module::Build 0.2611;

my $build_class = Module::Build->subclass( code => <<'---' );

  sub find_templates_files {
  my $self = shift;

  my %files;
  use File::Find;
  find( sub {
return if -d;
$files{$File::Find::name} = $File::Find::name;
  }, 'templates' );

  return \%files;
  }

---

# probe for directory for template files
sub tt_inc {
 # detect install path
 return '/var/tmp/templates';
}

my $builder = $build_class->new(
module_name  => 'Foo',
license  => 'perl',

install_path => {
  templates => tt_inc(),
},
);

$builder->add_build_element( 'templates' );

$builder->create_build_script;

__END__

In this example the "${type}_files" argument to the constructor is 
replaced by a "find_${type}_files()" method in a custom subclass.


Taking it one more step, you can provide a method, 
"process_${type}_files()" in place of "find_${type}_files()" which 
allows you more flexibility, for example if you wanted to create the 
template files on the fly:


use strict;
use warnings;

use Module::Build 0.2611;

my $build_class = Module::Build->subclass( code => <<'---' );

use File::Path;
use File::Spec;

  sub process_templates_files {
  my $self = shift;

  my $tt_dir  = File::Spec->catdir( $self->blib, 'templates' );
  mkpath( $tt_dir );

  my $tt_file = File::Spec->catfile( $tt_dir, 'foo.tt' );
  open( my $fh, ">$tt_file" ) or die $!;
  print $fh 'baz';
  close( $fh );
  }

---

# probe for directory for template files
sub tt_inc {
 # detect install path
 return '/var/tmp/templates';
}

my $builder = $build_class->new(
module_name  => 'Foo',
license  => 'perl',

install_path => {
  templates => tt_inc(),
},
);

$builder->add_build_element( 'templates' );

$builder->create_build_script;

__END__

In all the examples above the user can override the default install path:

perl Build install --install_path templates=/path/to/templates



I'd also like to have a generate .pm file that reads something like that:

<<<
package Shlomif::MyApp::DefaultConfig;

sub get_templates_dir
{
return "/usr/share/shlomif/myapp/templates";
}

1;


Or a different value in case it was installed somewhere else. This is so web 
scripts that uses this CGI Application will know where to find its templates.


Hmm, MB has some support for creating a custom configuration file. I'm 
not sure if the current release is flexible enough to allow what you 
want; I haven't really played much with that yet myself. The other 
option would be to define a subclass similar to the examples above that 
overrides the 'ACTION_code()' method. Call the super class method at the 
top, then write out your own module into the blib directory.


Regards,
Randy.

Re: Checking for boilerplate

[Randy W. Sims]

Wasn't paying attention when I copied prereqs from Makefile.PL

Randy W. Sims wrote:
4) Since M::S can generate distros with a Build.PL it might be nice if 
it also included one. ;)


# vi:et:sw=4 ts=4
use strict;
use warnings;
use 5.6.1;
use Module::Build;

my $build = Module::Build->new(

module_name  => 'Module::Starter',
license  => 'perl',
dist_author  => [
'Andy Lester <[EMAIL PROTECTED]>',
'Ricardo SIGNES <[EMAIL PROTECTED]>',
],


script_files => [ 'bin/module-starter' ],


build_requires => {
'Test::More'=> 0,
},

requires   => {
'ExtUtils::Command' => 0,
'File::Spec'=> 0,
'Getopt::Long'  => 0,
'Pod::Usage'=> 0,
},


);

$build->create_build_script;
__END__

Re: Checking for boilerplate

[Randy W. Sims]

Ricardo SIGNES wrote:

* Andy Lester <[EMAIL PROTECTED]> [2005-08-22T15:07:47]


RJBS and I are going to put some tests into Module::Starter to check for
boilerplate.  Watch for it tomorrow, maybe tonight.



Just a little while ago I uploaded 1.41_01, which adds:

  * t/boilerplate.t
  * some bug fixes
  * simple email address obfuscation
  * hook for new, improved plugin architecture

The boilerplate check is simple, but should catch the main offenses --
as long as people test before uploading.


I've played with the new version a bit on Debian Linux and Windows. Just 
a few very very minor comments:


1) I'm not a big fan of email obfuscation, though I might be in the 
minority. Most forms are just as easy to parse as a regular email 
address. And obfuscation feels too much like surrendering. Just my 
opinion. But an option might be nice if not too much trouble.


2) I like the boilerplate tests in M::S. It feels like an appropriate 
place since M::S puts it in, it might as well create tests to make sure 
it gets removed. However, I use M::S a lot for creating quick test 
distros, and that sometimes makes the failing tests annoying. But my 
usage is probably unusual in this reguard. It'd be nice if there were an 
option to diable it, but I can easily create a wrapper that "fixes" it 
for my purposes.


3) I goofed on the commandline and typod `module-starter --module Foo 
--mb --version` and scratched my head for a while looking for the 'Foo' 
directory. Should have type 'verbose'. Maybe 'version' could be an 
exclusive option, generating an error in the presence of other options? 
Or I should learn to type better.


4) Since M::S can generate distros with a Build.PL it might be nice if 
it also included one. ;)


# vi:et:sw=4 ts=4
use strict;
use warnings;
use 5.6.1;
use Module::Build;

my $build = Module::Build->new(

module_name  => 'Module::Starter',
license  => 'perl',
dist_author  => [
'Andy Lester <[EMAIL PROTECTED]>',
'Ricardo SIGNES <[EMAIL PROTECTED]>',
],


script_files => [ 'bin/module-starter' ],

requires => {
'Test::More'=> 0,
'ExtUtils::Command' => 0,
'File::Spec'=> 0,
'Getopt::Long'  => 0,
'Pod::Usage'=> 0,
},
);

$build->create_build_script;
__END__


*NOTE you must also add to Makefile.PL

WriteMakefile(
...
PL_FILES=> {}, # don't auto expand 'Build.PL'
);

And, optionally, do a `perl Build.PL` & `perl Build distmeta` to update 
your META.yml file.

Re: Perl6 goes where?

[Randy W. Sims]

Ovid wrote:
> --- Ken Williams <[EMAIL PROTECTED]> wrote:
>
>>On Jul 28, 2005, at 6:26 PM, Randy W. Sims wrote:
>
>
>>That's true.  All the smarts could be centralized in the indexer.
>>
>>But then there's the problem of making sure when someone's browsing
>>CPAN manually (on a regular mirror or on search.cpan.org or wherever)
>
>
>>that they don't accidentally download perl6 modules when they meant
>>to
>>download perl5 modules.  CPAN(PLUS)? may use only the index files,
>>but
>>people's brains don't.
>
>
> Because we still put "require 6" in Build.PL and their "perl Build.PL"
> chokes and they see pretty quickly what's going on (we hope.)  Then at
> least there's a chance of them figuring out how to resolve the problem.
>  So far, putting stuff in the indexer is the best idea I've heard.

Hmm, this could probably be fixed easily also. Either by using a Apache 
handler for directory listings (?not too familiar with web development, 
but isn't that what is used when a directory listing is requested?) or 
by having PAUSE generate/update an index file for each module/author 
directory at the time of submission. If it's a P6 distribution, the 
listing could display a special icon. Not sure how this would affect 
performance of the server...


Might be a good idea to run this whole scenario by Andreas Koenig, and 
then by the folks over on the perl6.language list. There may be valid 
reasons for wanting a seperate server, but I can't think of anything 
off-hand.


Randy.

Re: Perl6 goes where?

[Randy W. Sims]

Ken Williams wrote:


On Jul 28, 2005, at 6:26 PM, Randy W. Sims wrote:

As far as distinguishing, there a lot of talk in the past in the 
context of Apache2 about adding a field ("generation") which serves 
basically the same purpose - It distinguishes between multiple code 
bases intended for different targets.



Personally I really don't like the idea of the "generation" field.  I 
think it's too strict a mechanism for a nebulous notion.


Doh! I guess that was kind of a dumb idea since we already have

requires:
  perl: 6.0

in META.yml which works perfectly well for that.

Re: Perl6 goes where?

[Randy W. Sims]

Ovid wrote:

--- Smylers <[EMAIL PROTECTED]> wrote:



Smartening the CPAN and CPANPLUS modules doesn't help the people
who've
already got them installed are happy using them and haven't
encountered
a reason to upgrade.



Reluctantly agreed.

Is there going to be a CPAN BOF at OSCON to discuss this problem?  The
heat is slowly turning up.




Neither CPAN.pm nor CPANPLUS do a scan of cpan.org, correct? They get 
info from the package list. So, only the indexer needs to be made smart 
- don't catalog perl6 modules in the old package list. CPAN.pm & 
CPANPLUS will happily ignore anything else.


As far as distinguishing, there a lot of talk in the past in the context 
of Apache2 about adding a field ("generation") which serves basically 
the same purpose - It distinguishes between multiple code bases intended 
for different targets.




Randy.

Re: why not SourceForge?

[Randy W. Sims]

Mark Stosberg wrote:

On Thu, Jul 28, 2005 at 09:50:17AM -0400, Buddy Burden wrote:


Brian,



Sourceforget sucks. Don't start using it just because I did. :)


I'd be really curious to hear your opinions on Sourceforge (there may be a
push to force us to start using it here at work).  If you don't think you
could sum it up and briefly and/or think it's too off-topic here, maybe you
could post it somewhere else.  But I'm sure lots of folks could benefit from
your accumulated wisdom. :)



I think one issue is that the only still offer CVS for SCM, while many people
want something else now: Subversion or darcs for example.  ( Although people
have figured out how to publish darcs repos into their SF web space:
http://darcs.net/DarcsWiki/FrequentlyAskedQuestions#head-d5a5bbdfabe810765004987ace054cb5e90e9ab8
 ).

There's also the ads. It's nice to work in ad-free environment whenever possible. 


It's still nice that SourceForge bundles several services that somewhat 
integrated and
ready-to-go.


Their mailing list support sucks really, really bad. Posts are often 
delayed. Arcive messages change id so links eventually expire.


CVS has been faily reliable though; no complaints. They are in the 
proceess of adding Subversion support. YEA!


Ads haven't really bothered me, but then I'm pay subscribtion dues to 
support sf.net, so most ads are removed - I think.


Support has been quick and helpful.

Hmm, I guess mailing list problems are the only really offensive thing I 
can think of, atm.


Randy.

Re: Request for Comments - Tree::Node module?

[Randy W. Sims]

Flavio S. Glock wrote:

Randy W. Sims wrote:


Note: you must compile Perl and all modules with the same compiler (or C
runtime library).



I compiled the DateTime module with MingW and CPAN Perl 5.8.7, and the
DLL worked with Activestate 5.8.3 (I just copied it to the "auto"
subdirectory)
Is this just luck, or was it supposed to work?


It should work. MinGW uses the same msvcrt(?) C runtime library that 
Microsft C 6. uses. The only time you run into trouble is when you mix 
libraries. Eg. the C runtime library provides several services to linked 
code: it handles I/O, and it handles memory allocation/deallocation. The 
problems arise when part of the program (say an XS extension) allocates 
a chunk of memory using one runtime and then hands over a reference to 
another part of the program (say perl) which then tries to deallocate 
the memory using a different runtime. Instead of perl deallocating the 
memory from the pool it was allocated in, it is trying to deallocate it 
from a different pool, resulting in undefined behaviour, possibly 
deallocating a block of unrelated memory that's being used. Same with 
I/O. Since much I/O is buffered, you can see strange behaviour, like 
things output to the screen in apparently random order, or worse.


In general, it's not the compiler that matters, just the libraries. You 
cannot mix runtime libraries (well, you can if you're carefull, but not 
generally).


As long as you compile extensions that use the same version of the same 
C runtime library, you should be safe.


Randy.

Re: CPAN testers emails

[Randy W. Sims]

Ken Williams wrote:
Am I supposed to be getting emails from cpan-testers every once in a 
while?  I think I used to get Cc'd on them, but it occurred to me I 
haven't actually gotten one in like a bajillion (about 2) years.  I 
upload new modules to CPAN about once or twice a week or something.


They're not automatically cc'd to the module author; testers must do it 
manually. The best thing to do is subscribe to the cpan-testers mailing 
list[1] and set up a filter to delete all but the ones you want to see 
(i.e. Subject =~ /Module-Build/). Or you can just browse 
testers.cpan.org[2].


I used to keep up with certain modules by mailing list, but haven't in a 
while. It works well, but there is a lot of traffic on the list.


1. 
2. 

Re: Request for Comments - Tree::Node module?

[Randy W. Sims]

imacat wrote:

On Wed, 29 Jun 2005 09:42:32 -0500 (CDT)
Randy Kobes <[EMAIL PROTECTED]> wrote:


requests for making up ppm packages. Alternatively, there
are free C compilers for Windows, including Visual C++ 7,
for people willing to build their own perl.



Could you tell me where to obtain it?  Thank you.



MinGW GCC   
Borland C   
Microsoft C 

Note: you must compile Perl and all modules with the same compiler (or C 
runtime library).

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

[Randy W. Sims]

Barbie wrote:

From: "Jos I. Boumans" <[EMAIL PROTECTED]>


Why the need for such an immensive framework? to be able to probe for
any type of file/function on any type of OS is not going to be trivial.



To look for every possibility yes that would be emmense. However, I wasn't
expecting to go that far. There are a few cross-platform ways of looking for
libraries and apps, as has been indicated by have_library() and the like. By
refering to Module::Install, I meant the check module would be part of the
distribution, and be called within Makefile.PL/Build.PL before calls to the
appropriate build mechanism.


Although a long way from being done, there is a spec for a small 
scripting language[1] that has been discussed and mostly agreed on, at 
least experimentally, for describing requirements on modules, external 
libs, header files, programs, OS, perl features (threading, large file), 
etc. The plan is to include it as part of the META.yml spec and to write 
a module[2] that reads, writes, and validates the requirements described 
in the META.yml file. With a way to describe all requirements in 
META.yml and a module to validate it it would be possible for CPANPLUS 
to grab the META.yml, validate it, and then decide whether to download 
the actual module. ???


The tentative plan is to put the generic lib, include, program, compiler 
detection code in the Probe::* namespace so other modules like 
ExtUtils::CBuilder can also access the functionality.


This is all tentative and apparently a good ways off; mostly because I'm 
very slow.


Randy.

1. 
2. 

Re: Getopt::Long wishes

[Randy W. Sims]

A. Pagaltzis wrote:

* Johan Vromans <[EMAIL PROTECTED]> [2005-06-17 17:20]:


I can make this information available, if users would be
interested.



Access to structured data is always nicer than implementing and
re-implemeting a parser for its serialized form.

So if it doesn’t take too much effort, it would be nice to have.
I might even need this at some point  [...]


Being in the middle of writting option processing code[1] I'd like to 
throw a few ideas and comments out into the void...


First, order of commandline arguments does matter. The code I'm writting 
depends on this in several ways. First, it reads options from a rcfile 
much like the format used for svn, cvs, etc.


~/.modulebuildrc
* --verbose
install --uninst --noverbose

Command line options are parsed (passed thru to G::Long). Unless an 
option is present to disable rcfile processing, we process the rcfile. 
In the rcfile we have global options ('*'), and action specific options. 
When processing the rcfile we pass in to G::Long the options in a 
specific order: @global_rc_options, @action_specific_rc_options, 
@commandline_options. Notice in the example that globally the option 
--verbose is passed in, then only when executing the 'install' action 
verbosity is turned off. Finally, the commandline can be used to 
override any of these. If order didn't matter, there would be no way to 
override the defaults from the rcfile.


Another case is setting include directories. We want include directories 
searched in the order they appear on the commandline ('include-dirs=s@')


./Build --include-dirs /special/place --include-dirs /usr/include

A different order would cause problems if two different headers with the 
same name happen to exist in both locations.



I do wish Getopt::Long provided for more custom processing by providing 
incremental parsing: while ( $parser->next ) {...}. I also wish it 
accepted a string or argv like array and only used @ARGV as a default 
(and passed a reference to the option array to custom subs). Also, it'd 
be a bit more OO to provide the option to store parsed options 
internally, instead of storing the results in external variables.


I think there were more things I wished for when writing that module, 
but I'm too tired to think what they were right now.


Randy.

1. 

Re: RFC - a module to generate README from POD

[Randy W. Sims]

Robert Rothenberg wrote:
I'm rather tired of manually editing README files before each release, 
and do not like using a straight pod2text either, since it contains a 
lot of superfluous information.
>
So I'm thinking about writing a module which parses the POD, 
automatically includes the non-core requirements and installation 
instructions, but recognizes special commands on what to include/exclude.

I would like to use POD syntax in a way that deviates from the standard 
a wee bit:

=begin readmeinclude in README as POD
=begin readme podsame as above
=begin readme plain  include in README as plaintext
=for readme commands commands for the README parser,
 some examples:
=for readme stop stop including POD in readme
=for readme continue continue including readme
=for readme include plain file
=for readme include pod file
 include a plaintext or pod file
=for readme include plain file mark
=for readme include pod file mark
 include a text file until "mark" occurs?
=for readme requirements insert a =head1 REQUIREMENTS section
 which parses the META.yml for non-core
 requirements
=for readme install  inserts a =head1 INSTALLATION section
 which can tell if there's Makefile.PL,
 Build.PL or both; also parses the
 build_requires section of META.yml and
 notes these
I'm still thinking about the include file semantics.  I like to include 
changes since the last version in my READMEs and the simplest way to do 
that is to include a file until some string occurs (so I could put a 
mark between each version).

(I would add a =for readme history command, but I don't think anyone has 
a standardised revision file scheme.)

Anyhow, comments would be appreciated!
I think it would be more generally usefull if it were automatic. You can 
easily subclass Pod::Text to grab just sections you are interested in. 
You can use ExtUtils::Manifest to read the manifest. Then for each 
module file, use Module::Info to get dependencies. (See Devel::Required 
for another approach that unfortunately only works with MakeMaker.)

I'm not sure the primary method of generating it should be POD markup. 
It's too much work ;)

Randy.

Re: Probing requirements

[Randy W. Sims]

_brian_d_foy wrote:
In article <[EMAIL PROTECTED]>, Randy W. Sims
<[EMAIL PROTECTED]> wrote:


Probe::OS - Gather info on the operating system
Probe::Libs
Probe::Progs
Probe::FileSys - maybe incorporate ideas Schwern posted on p5p recently, 

Perhaps we can put this under a namespace like Config:: ?
I have no strong feelings about the namespace. The idea of Probe:: came 
from a document that used to be at:

<http://cplan.kwiki.org/index.cgi?MinutesAccordingToAutrijus>
It vaguely described something along the lines of what we're discussing. 
But that page disappeared a good while back and nothing has shown up in 
that namespace. So...

I didn't like the Probe name too much at first, but it's kinda grown on 
me; seems very perlish. I've come to think of Config::* as a place for 
static configuration information such as the compiler used to compiler 
perl, $Config{cc}. Probe would deal with more dynamic configuration 
gathering type stuff. For example, Probe::Compiler might determine what 
compiler(s) are installed, launch the compiler or compile a snippet to 
determine the version of the compiler and the version of the C lib, 
default include paths, and various other characteristics.

But, as I said, I'm not strongly attached to any particular namespace. 
And it will probably be a while before I get to it.

Randy.

Probing requirements (was: Re: Some ideas)

[Randy W. Sims]

Robert Rothenberg wrote:
I'm all for something like this, though I prefer "requires_libraries" 
instead. (Listing libraries distinct from applications is a grey area, 
so best to put them under one term.)

Come to think of it, why not "recommends_libraries" too?
What is needed is some standard set of library and application names.
Implementing platform-independent logic to find these libraries is 
another matter.

Here's an idea. A module namespace called Config::Libraries, such as
  Config::Libraries->info('libgd')
which returns a hash of relevant information about the library. Some of 
the hash keys would be standardized, such as one to return a path to 
where the library or application is installed, another to return the 
version.  (It would return undef if the library was not installed.)

This information would be read from an adequate text configuration file 
format (YAML or IniFile).

There should be another interface to update the config file easily, 
along with a command-line script to do this.

Library installation utilities can use this script, or users can use it 
to manually update the config as needed.

The module would have some messy installation procedure that sets up an 
initial script. Ideally it should have Platform-specific parts inside 
generic wrapper methods.  There might be a separate installation file 
for each application that uses these methods to configure itself: this 
way adding a new library to the utility is a matter of adding script.

Pseudo-library names could be given to special capabilities that some 
systems do not have.

The downside is controlling the library namespace. Whoever controls the 
Config::Libraries module would have the de facto control, which is 
probably good enough for the time being.

That said, who has time to work on such a project? I've got my hands 
full already.
Eventually there will likely be a series of modules in Probe::* to deal 
with this sort of stuff. If no one else is interested I guess I'll 
eventually get around to it. The functionality is needed for 
Module::Build, specifically for either the proposed fields to the META 
spec or dEx[1] which is intended as an alternative solution to many of 
the proposed fields in the META spec.

There will be things like:
Probe::OS - Gather info on the operating system
Probe::Libs
Probe::Progs
Probe::FileSys - maybe incorporate ideas Schwern posted on p5p recently, 
detecting sensitivity, preservability of case, etc
Probe::Locations - where to install parts of apps, config files, data files
Probe::Apache
etc.

(IIUC, this namespace was once proposed for this use, but noone has 
developed it.)

At least this is what I'm thinking at the moment. It's subject to 
change. And this is a long way into the future. Lots of stuff to be done 
first.

1. 

Re: RFC: some thoughts about daemons and related modules

[Randy W. Sims]

Baltasar Cevc wrote:
One possibility would certainly be to "generalize" Net::Daemon
to something like a App::Daemon or Proc::Daemon (the latter
exists, but has only a limited functionality, concentrates just
on the "real daemonizing" and does not take care about PID etc.)
or something in that direction.
Have you checked with the author of that module to see if he/she is 
interested in extending the module? Perhaps a collaboration? Or maybe 
you can inherit from it, and extend it yourself?

Randy.

Re: better SEE ALSO sections

[Randy W. Sims]

Andrew Savige wrote:
Shamless plug: since you are a relative newbie, you might find
this article:
http://www.perlmonks.org/?node_id=418891
an interesting read, especially the section "Testability and Test Suite".
Also check out the perl-qa mailing list for all kinds of testing & 
quality issues.

Re: Name for GStreamer bindings

[Randy W. Sims]

Torsten Schoenfeld wrote:
On Fri, 2005-02-25 at 09:43 +0100, A. Pagaltzis wrote:

 use constant Gst=>'Multimedia::Gstreamer';
 Gst->new();
I just realized that this won't work.  I don't just need Gst to
be an alias for Media::GStreamer, I need Gst::* to be an alias
for Media::GStreamer::*.  That also seems to rule out the
aliased.pm approach.
Why? Sure, you need many constants, not just one, but does that
matter?

No, not really.  It seems a bit cumbersome, but I guess it would work.

Something that doesn't seem to have come up in debate here is
that the distribution and main module namespace need not dictate
the package names for classes. You could well stick everything in
Gst:: even though your modules are called Media::GStreamer(::.*)?.

This sounds very evil, but might actually work!  This would solve the
problem in a pretty elegant way:  No top-level CPAN pollution, but a
usable namespace.

Is this a bad idea even if it's clearly documentent?

That's the question.  What do others think?
I'd consider it a very bad practice. Imagine if many authors started 
doing the same. There could be unpredictable collisions all over the 
place. It defeats the CPAN scheme for ensuring unique namespaces.

I still don't see the problem of using a proper namespace. Arguments of 
length are not compelling. What's wrong with a descriptive name? The 
name Gst means nothing to most people. It's fortunate that not all 
authors have the view that modules interfaced to external libs get their 
own TLN. There are some bad examples out there, but for each there is a 
good counter example, eg XML::LibXML.

Randy.

Re: Name for GStreamer bindings

[Randy W. Sims]

Torsten Schoenfeld wrote:
Aloha,
GStreamer is a powerful and pretty popular media framework.  GNOME
already uses it extensively, and KDE just started to.  It's based on
GLib and uses its object oriented C API style.  The objects have names
like GstQueue or GstElement.
For similar objects like GtkWindow or GnomeIconList in other libraries,
us Gtk2-Perl people tend to directly map them to namespaces:
Gtk2::Window and Gnome2::IconList.  For smaller libraries like libwnck
or librsvg, on the other hand, we try not to pollute the top-level
namespace: Gnome2::Wnck::Screen, Gnome2::Rsvg::Handle, etc.
For GStreamer, I would tend towards using Gst as a namespace.  It
matches the C objects' names.  It's short to type, which is not
unimportant since it's not like the typical Perl OO module where the
full package name only appears once when using the constructor -- the
GStreamer bindings contain a lot of objects with their own constructors,
many of which almost all programs will use.  It's not directly
GNOME-related.  And lastly, Gst has a precedent: the Python bindings
also use this namespace.
On the con side, there's of course the introduction of a new top-level
namespace.  One that is an abbreviation and not easily recognizable.
So, if you were to write Perl bindings for GStreamer, what namespace
would you use?
Multimedia::GStreamer
I don't see any advantage of using Gst over GStreamer as a name, they 
both describe the same thing and GStreamer is a tad more helpfull (to 
google a description). Then Gnome part as mentioned seems irrelevant. 
Glib is possibly usefull info, but probably better conveyed via 
documentation as an implementation issue. It might be nice to "say" 
somethnig about what it does: plugin, pipeline... I can't think of a 
better word.

Multimedia::Pipeline::GStreamer ???
Randy.

Re: URLs to Modules

[Randy W. Sims]

Andrew Savige wrote:
--- Ovid wrote: 

Perhaps this is a silly question that I should know the answer to, but
is there a "canonical" url I can list for a module and always have that
point to the latest version?  Right now, my choices seem to be:
 http://search.cpan.org/~$AUTHOR/$MODULE-$VERSION/
Or the awful search URL which returns too many results:
 http://search.cpan.org/search?query=${MODULE}&mode=module
I really feel like I should know this (grr ...)

From the late Iain Truskett's use.perl journal
http://use.perl.org/~koschei/journal/13493
---
Given a dist: DateTime::Format::HTTP 

These are all the same page: 

http://search.cpan.org/dist/DateTime-Format-HTTP 
http://search.cpan.org/author/SPOON/DateTime-Format-HTTP 
http://search.cpan.org/~spoon/DateTime-Format-HTTP 
http://search.cpan.org/~spoon/DateTime-Format-HTTP-0.34 

And to go straight to the module's docs: 

http://search.cpan.org/perldoc?DateTime::Format::HTTP
---
Further to Iain's list above, this seems to be an alternative
way to go to the module docs:
http://search.cpan.org/dist/DateTime-Format-HTTP/lib/DateTime/Format/HTTP.pm
If anyone knows of any others, please let us know. 
In addition to those listed...
Modules by author:
  http://search.cpan.org/~ovid/
  http://search.cpan.org/author/OVID/
Any file in a specific dist:
  http://search.cpan.org/src/OVID/aliased-0.11/t/10aliased.t
or any directory in a specific dist:
  http://search.cpan.org/src/OVID/aliased-0.11/t/
A specific dist:
  http://search.cpan.org/dist/aliased-0.11/
I use /dist/ all the time, but rarely use /author/ and /src/ directly.
Randy.

search.cpan.org slowdown

[Randy W. Sims]

Why is search.cpan.org so slow the last few weeks? The search interface 
and urls like  take forever to load. 
I feel like I'm connected with an old 600 baud modem. www.cpan.org, etc 
seem fine.

Randy.

Re: When Did a Module Become Core?

[Randy W. Sims]

James Keenan wrote:
What is the simplest way to determine for a given CPAN module (a) 
whether it is part of the Perl core; (b) when it became part of the core 
(i.e., which version of Perl); and (c) which version is considered core?

Re: Subclassing a mailer

[Randy W. Sims]

Scott R. Godin wrote:
For a project I'm on, I'm pondering whether or not to subclass one of 
the various Mail::* implementations out there, with an eye for 
Mail::Mailer.

Does anyone have any recommendations in this regard? gotchas & things I 
should watch out for ? pointers? examples? :)

I don't understand why you want to subclass Mail::Mailer. You haven't 
given us enough information. Are you looking to add some functionality 
not present in any of the mailers? What kind of functionality?

Randy.

Re: MakeMaker META.yml and license

[Randy W. Sims]

Gabor Szabo wrote:
Hi,
does anyone know how to add the license field to the META.yml
file when using Makefile.PL ?
I know how to do it from Build.PL and as far as I know MakeMake
does not yet support it out of the box. Is there a workaround ?
Workarounds are discussed in the thread beginning at 


Does anyone know when will MM support it ?
Not sure when Michael's gonna get it in there, but Marcus has a patch in 
RT for it: 

Re: Module naming advice

[Randy W. Sims]

David Wheeler wrote:
On Jan 4, 2005, at 2:47 PM, Bruce J Keeler wrote:
I've always felt that this one should have a lowercase name, since it's
rather pragma-ish.  Are pragmas allowed outside of the core Perl
distribution?  Maybe it should be submitted as a core pragma, actually.
It's a really lightweight beast, and very useful.  Would certainly get
my vote.

I agree that it should be lowercased; yes, there are modules on CPAN 
that look like pragmas (such as only). I personally would prefer, 
however, that the name tell me that it's doing something more than 
loading a class; "class" and "module" don't do that. Here are some other 
options:

* alias (too close to "Aliased"?)
* nickname
* moniker
* pseudonym
* aka
* anonym
* handle (not a file handle, though, might be confusing)
* label
* term
* shortcut
I kind of like "aka", actually. But nickname, moniker, and shortcut are 
all good, too.
There is Package::Alias[1]. Does the same thing, but I haven't used it.
I like the idea of it being a pragma; 'aka' seems kinda perlish.
It'd be nice if this was supported in perl, so it would be possible to 
alias entire namespaces

use aka 'Apache2::Apache::' as 'Apache::';  # ;-)
Which would all all modules in the first namespace to be addressed as if 
they were in the second, including munging %INC so it does the right thing.

1. 

Re: CPAN Testers and PREREQ_PM doesn't work very well!!!!!!

[Randy W. Sims]

Sébastien Aperghis-Tramoni wrote:
cpansmoke is being re-added for 0.050_04.
What is missing now is people using/testing CPANPLUS 0.50_xx to help
Jos find and crush bugs.
Yeah, a more productive place to discuss this might be the 
cpanplus-devel list:


and/or the perl-qa list:

New Module Idea: Starbuck's Async Message Protocol

[Randy W. Sims]

I've just been inspired:

Starbuck's is finally getting the recognition they deserve as a great 
impetus and source of stimulation for the software engineer.

I'll have a venti Chai Latte with a squirt of peppermint, and a script 
to cleanup all the week-old rss feeds from my Thunderbird mailbox, please.

Randy.

Re: [rfc] File::Corruption

[Randy W. Sims]

Joshua Hoblitt wrote:
On Sun, 17 Oct 2004, Christopher Hicks wrote:

On Sun, 17 Oct 2004, Joshua Hoblitt wrote:
is the namespace appropriate?
I'd rather see it called something like "File::DetectCorruption" or 
something that makes it clear that your module isn't here to corrupt 
files.

That seems like a little too much typing for my tastes.  "File::Corruption",
"File::CheckSum" or the like sounds better to me. 
File::Check
File::Verify
File::Validate
???

Re: cpan-testers rant

[Randy W. Sims]

David Coppit wrote:
Can someone please tell me how to convince cpan-tester's automated testing
to:
- Not test unless required modules are installed. (Of *course* it fails if
  you don't have a required module installed.)
- Send me the output of "make test TEST_VERBOSE=1" instead of the useless
  general testing report. (Test X failed, but you'll have to guess why!)
- Make sure they're using the right lib version (5.8.5) for their perl
  version (5.6.1)
I haven't followed the cpan-tester list for a while, but it used to be 
if you posted a reply to the list and the address of the tester that you 
would get help in finding the problem. You might also take a look at 
. They run automated builds on several 
architectures and post the results and logs.

Randy.

Re: Let's eliminate the Module List

[Randy W. Sims]

On 8/24/2004 9:28 AM, Simon Cozens wrote:
[EMAIL PROTECTED] (Randy W. Sims) writes:
hmm, are you going to generate multiple indexes? It might be
interesting if we could search over the various fields provided by
META.yml[1]

I am only going to generate one index, but this is because Plucene indexes are
better than you think they are. :)
Plucene allows me to index "documents" with multiple fields, like so:
  type: module
  name: Email::Simple
  category: email
  author: SIMON
  description: ...
  synopsis: ...
  depends: 
  rating: ...
In fact, I can just index META.yml plus the documentation pretty much as is
and get the data in the right fields. There's a lot more fields you can (and I
will add) of course, such as when the module was released, the license, and so
on.
Very cool. You're right. I was thinking of the old-fashioned type text 
indexes. I've been doing a little reading on P/Lucene, and it's very 
exciting.

Oooh, I think I like it
I think I like what I’m feelin’
Even though it’s such a surprise
But you know
Oooh, I think I really like it
I think I like what I feel
And changes really open your eyes
  - Boston, lyrics to "I think I like it"
When you have such an index, to find all the good email handling modules,
search for "category:email rating:4-5". Or "email author:SIMON", it comes to
the same thing. :)
Is that a bug? ;-)
Browsing is just searching metadata.

Re: Let's eliminate the Module List

[Randy W. Sims]

Simon Cozens wrote:
[EMAIL PROTECTED] (Randy W. Sims) writes:
I still think sourceforge-like hierchical catagories (Topics) in META.yml
would make for good light-weight search and improved by-catagory browsing

I disagree quite violently with this, but I'm not going to implement searching
and indexing in a way that precludes it. I think that the world moved from
browse to search some time in the mid 90s (hell, we're even being encouraged
to search rather than browse email these days) and that this is because
browsing is useful if your search engine isn't good enough.
Ok. I'm not sure I completely agree, but I will conceed that a good 
search engine can accomplish simiar goals.

Even so, I
recognise that everyone who comes to working on CPAN metadata has their own
conceptual axe to grind, so I'll just index whatever the heck is in META.yml
and let everone else sort out the details.
hmm, are you going to generate multiple indexes? It might be interesting 
if we could search over the various fields provided by META.yml[1]. For 
example, you might do a search for the term "process list" where the 
field Platform == MSWin32, or a module author might do a search where 
term is "*" (any) and field Requires ==  to get 
a list of modules that depend on her module.

I'm not sure how widely usefull that would be, but it seems worth 
considering. However, some of the potentially usefull fields are 
currently not in use.[2]

1. Current and proposed spec at <http://module-build.sourceforge.net/>
2. Somewhat old data, but the fields in use should still be accurate. 
<http://www.thepierianspring.org/meta.stats> The script to generate it 
is at <http://www.thepierianspring.org/meta_stats.pl.html>

Re: Let's eliminate the Module List

[Randy W. Sims]

Johan Vromans wrote:
Andy Lester <[EMAIL PROTECTED]> writes:

I've already pulled the minicpan (a la Randal's mini mirror)

Can't we make this an official tool? It is very handy!
(If Randal is okay, I'll volunteer to toolize/cpanize it).
Very usefull. I've made great use of it for gathering stats about 
META.yml usage and Module::Build vs MakeMaker, etc.

Note however that it needs a slight tweak. I was very... erm, suprised 
when I ran it on one of my Windows machines, and it downloaded the 
MINICPAN and then proceeded to delete everything it downloaded. I've 
been meaning to submit a patch, but forgot about it. IIRC, just needs to 
File::Spec->canonpath() all paths before comparing. I don't have it in 
front of me now, but I'll try to check and submit a patch later today.

Randy.

Re: Namespace for EUI related modules

[Randy W. Sims]

Suresh Govindachar wrote:
By the way, if you know of a script to fill out
https://pause.perl.org/pause/authenquery?ACTION=apply_mod
please point me to it.  If there is no such script, I will
be attempting to write one (using WWW::Mechanize?) -- I
trust there is no danger of me messing things up on PAUSE by
doing so.
Please don't do that. I don't see the need; you only fill it out once 
for a module. It will introduce the potential for abuse, flooding the 
system. IMO, It's a really bad idea.

Randy.

Re: Which namespace for a build system?

[Randy W. Sims]

[ Actually, I'm going ahead and CC'ing the list because I'm going to 
suggest something that others will probably disagree with ;-) ]

Nadim Khemir wrote:

-Original Message-
Is this a build system for perl modules or a generic build 
system? Is it 
an application or a library? Is the documentation available; 
I'd like to 
learn more about it.

It' a generic build system aimed at replacing gmake, cons and the like. I'ts
a meta-build system, a nice name to tell that it is not complete :-). 
I'm going to suggest that it is reasonable for an "application" of this 
sort to have its own namespace. It has a very specific use, and it is 
not generally applicable to other perl apps.

I don't like the name PBS. Probably because, if you mention it anywhere 
in the U.S., people the of the "Public Broadcasting Corp", a publicly 
funded educational TV broadcasting network.

PBS is a set of modules that let you build a build system. Since it's
written in perl, you can add your own libraries and even have your own
syntax if you wish to but the "plain" syntax is perl and it looks rather
good and easy.
The best doc to start with is the presentation I gave at "perl nordic
workshop" the slides are on their site.
In the unix perpetual tradition, the documentation is the code. Seriously,
the documentation that is available is very old and very confusing. It was
my goal to re-document the system this summer but I simply didn't. As there
are only 2 or 3 users for the system and I know them, we haven't had the
necessity to document more (the system is easy to understand as it is rule
based). I want to release the system to see if there are other are
interrested and in that case I will write a proper documentation.
I can just about guarantee that it is not going to be used without some 
documentation. I suggest it is useless to post it without docs, and 
possibly a couple of samples.

PBS is  reseach project that turned wellbut I still want to do some research
(like iontegration between CM and build systems)
One advantage of PBS is that it is quite fun to use and build debugging is
one of the base for the program.
Hey, that's two ;-)

Re: Let's eliminate the Module List

[Randy W. Sims]

Andy Lester wrote:
On Mon, Aug 23, 2004 at 10:43:38PM +0100, Nicholas Clark ([EMAIL PROTECTED]) wrote:
There is nothing stopping anyone on this list prototyping their own
improved substitute for search.cpan.org. (although it helps if you have
a public facing webserver if you want to show it to others).
Yet no-one does.

I'm working on it.  I've already pulled the minicpan (a la Randal's mini
mirror) and I'm working on the Template Toolkit-fu to make reasonable
pages.
If anyone's interested in helping out, let me know.
Looks like you and Simon should collaborate. Is it possible or realistic 
for it to have pluggable search & browse engines. I still think 
sourceforge-like hierchical catagories (Topics) in META.yml would make 
for good light-weight search and improved by-catagory browsing (modules 
can list multiple catagories). There may be other usefull info in 
META.yml like OS Platform and requirements, etc that could be used in 
advanced searches. Also, some info might be pulled from cpanratings.

Web development is not my area, but I've been trying to remedy that. 
I've been trying to setup a local cpanratings to play with and hopefully 
do some work on, but it's going slow right now. When I do get up to 
speed, I'd be willing to do some work...

Randy.

Re: name for singlethreaded web server framework module

[Randy W. Sims]

david nicol wrote:
I am writing a module that provides HTTP interface using select,
for simple web applications without a web-server, and without
POE or other modules.
Configuration will be by mapping paths to coderefs.
Planning to call this cute beastie HTTP::Server::Selecting.
Comments?
I'm not sure how descriptive "Selecting" is. Maybe HTTP::Server::Simple 
or HTTP::Server::Synchronous ?

Randy.

Re: Which namespace for a build system?

[Randy W. Sims]

khemir nadim wrote:
I'm going to polute witha new top level namespace! PBS::
Don't anyone have any idea of where we should put this type of modules?
Is this a build system for perl modules or a generic build system? Is it 
an application or a library? Is the documentation available; I'd like to 
learn more about it.

Randy.
Devel::
Devel::Build::
Build::
App::BuildSystem
I'd appreciate some input.
Cheers, Nadim.

Re: Let's eliminate the Module List

[Randy W. Sims]

Christopher Hicks wrote:
On Thu, 19 Aug 2004, Hugh S. Myers wrote:
2. Push hard on the notion of adding a keywords item to the 'standard' 
for pod documentation.

What should those keywords be?  Who decides?  I'm personally much more 
interested in seeing a dmoz-ish hierarchy so related modules can be 
easily found and compared.

I agree[1]. A static list of catagories like DMOZ or SourceForge uses 
would provide for improved, more consistent searches and an improved 
by-catagory browsing catalog. Catagories could be added to META.yml for 
easy indexing by . Fixed catagories make it more likely 
that similar modules will be found together both when browsing 
by-catagory and when searching. And you eliminate the abuses of keywords.

1. 

Re: Let's eliminate the Module List

[Randy W. Sims]

On 8/18/2004 5:54 PM, Andy Lester wrote:
I propose eliminating the Long Module List.
This proposal has come up several times on module-authors. IIRC, all the 
regulars are in agreement with the proposal; I don't think anyone dissented.

The one bit of value that I see in this process is where Graham looks
at submissions that people have sent in and, if something seems like
it's duplicate effort, tries to redirect the author to reduce the
duplication. (http://www.nntp.perl.org/group/perl.modules/34207)
Unfortunately, that requires the author to submit a proposal for
inclusion, and since fewer than half of the authors submit the modules,
it's hardly a complete filter.
I welcome your thoughts.  How can we capture the good part of the module
list (the human filtering), and remove the obsoleted infrastructure?
I made a suggestion regarding this before that I thought provided a fair 
solution , but 
no one commented. Basically, upon submission of a new module, a notice 
would be auto-posted to some list. If no one replies to that posting 
within some time frame, the module is automatically accepted. If anyone 
does reply, then it requires moderator approval. The moderator(s) isn't 
required to do anything other than monitor the discussion and act 
according to the concesus reached in the discussion. The list members do 
what is currently done on a voluntary basis on module-authors; that is, 
they make name suggestions, discuss prior art, etc.

Re: Where do people learn how to document a module?

[Randy W. Sims]

Hugh S. Myers wrote:
Good suggestions all. OTOH---I can't help but think that it wouldn't hurt to
have a few more documentation tools, for both old and new authors. I'm
working on a script using B::Deparse that will when done at least generate a
skeleton document framework for subs and globals.
Pod::Coverage might be usefull. I think it provides a way to list all 
undocumented subs which in the case of the script you're talking about 
would be all non-private subs. Using it would guarantee that the pod 
generated by your script would rate as 100% covered.

Randy.

Re: Namespace for Z-machine parse/translate module

[Randy W. Sims]

Amir Karger wrote:
--- "Randy W. Sims" <[EMAIL PROTECTED]> wrote:

Amir Karger wrote:
* Games::Zmachine - well, Z-machine isn't technically just for
games.  I say "technically" because the most "useful" Z-machine
program I've seen is a Befunge interpreter.  But this module is
really doing more munging than gaming.
This is the namespace I'd expect to find it in, but since I'm not
clear on the "translating" part, I don't know if that should be the
complete name.

Let me explain. No, there's too much. Let me sum up.
This is not an interpreter, where you run "foo zork1.z3" and get to
play
Zork. Games::Rezrov does that. What my program does is take
Z-machine commands like (in a simplified Z assembly language):
1220add 3 top_of_stack -> local1
1225jg local1 global1a ?branch
1230call sub_foo local1 2
.branch
1235print_paddr 2a3b
and translates them to:
L1220: $local[1] = 3 + pop @stack;
L1225: goto L1250 if $local[1] > global_var(26);
L1230: z_call(1476, $local[1], 2);
# print " You are likely to be eaten by a grue."
# (I don't put a literal print in there because the text
# at that address can change (within limits)!)
L1250: output_text(decode_text(2a3b));

This is why I was not so inclined to make this a Games:: module. As I
mentioned in the original post, there have been some non-games written
in Z-code. But I think a more compelling reason is that this module is
parsing and translating. To me, those are more Language-y than Game-y
things.  

On the other hand, I guess you can make the argument that the
end result is a playable game.  And people aren't really coding in
Z-code for anything but fun at this point.
Okay, I think I understand a little better now. This isn't really a 
Zmachine. This module deals with Zcode, transling it. So, I think I 
would use Zcode in preference to Zmachine in the name. I'm about 50/50 
on the names Games::Zcode vs. Language::Zcode. They both make sense from 
a certain perspective: I would be more likely to look for it in 
Games::*, but it seems to fit more with the other modules in Language::*.

Regards,
Randy.

Re: Mail::Vacation abondoned?

[Randy W. Sims]

Adam Monsen wrote:
(this was originally posted in comp.lang.perl.modules, but received no response)
I need a vacation autoresponder that can (at least) be used within
~/.procmailrc.
I'll write one unless someone knows of a useful one. Features I need:
* doesn't respond to mailing lists
* doesn't send to the same email more than once in a user-configurable
time period
* simple, useful interface
(any other suggestions?)
I'd like to take over the Mail::Vacation namespace and fill it with
some code that works. The tests fail, it won't install, and I tried to
contact the author 10 days ago and haven't heard back.
Would someone please advise me on this? Would there be a better
mailing list to try, module-authors possibly?
If getting ownership of the namespace is just hassle, I could
certainly create a new one. I am just trying to proceed thoughtfully.
How about abstracting it to a general autoreply module; It's applicable 
to a lot of situations other than vacation. (Mail::AutoReply) Filtering 
based on header fields is a must, primarily for the reason you mention 
above, but also as a general autoreply users might want to selectively 
respond to messages meeting certain criteria.

Another idea that comes to mind is letting it monitor remote mail (POP3) 
or run as a proxy in addition to running as a filter, although that 
might arguably be left to other modules so users can assemble them 
anyway they wish depending on the functionality desired???

Just some ideas,
Randy.

Re: Namespace for Z-machine parse/translate module

[Randy W. Sims]

Amir Karger wrote:
[Warnocked on cpl.modules]
I've written a module that parses Z-machine files[1] and translates
them
into executable Perl scripts.  In the future, it'll be translating to
other languages: first on the list is PIR.  I'd like to CPAN-ify it,
and wanted to ask about namespace.
That's interesting. Are the scripts then independent of the module?
* Games::Zmachine - well, Z-machine isn't technically just for games.
  I say "technically" because the most "useful" Z-machine program I've
  seen is a Befunge interpreter.  But this module is really doing more
  munging than gaming.
This is the namespace I'd expect to find it in, but since I'm not clear 
on the "translating" part, I don't know if that should be the complete name.

[1]For those unfamiliar with the Z-machine
Long live Zork!
FYI, there are lots of Zgames over at  and the 
original Zork at .

Re: modularization module

[Randy W. Sims]

Baltasar Cevc wrote:
Hi, everybody!
I've started to write a modular user administration
tool sometime ago. During this process, I've also
started two modules facilitating the creation of
such a modular program.
The program modules are realized as Perl classes,
each of them being a child of one of the two
modules I mentioned at the beginning.
The other of the two modules serves as some kind of
"control center" for the application, providing
information about modules, functions to find and
(un)load them etc.
I wonder if that would be something useful I
should post to CPAN... and if it is - what would be
an appropriate name. Currently they are named modularzier and
modularizer::module.
Module names on CPAN must be camel cased. All lowercase names are 
reserved for pragma. This should probably go in the Module::* namespace.

Randy.

Re: module name for Wily (a text editor) interface client?

[Randy W. Sims]

Sam Holden wrote:
I asked this in comp.lang.perl.modules and was pointed here, so
here I am.
Firstly, wily[1] is a (mostly) workalike of Acme[2] an editor
under plan9.
Wily provides only basic functionality with a very different but very
small interface (with lots of mousing, meaning many people will *hate*
it). It doesn't for example have a means of doing search-and-replace
(though everyone who uses wily will have an external program that adds
that to it in some way).
It does however, allow external programs to interface to it (and
possibly add some of the missing functionality). The module I've written
implements that interface and allows perl to communicate with wily.
Basically it allows a perl script to interact with wily the way
LISP code might interact with emacs (I think anyway, not being an
emacs user).
I can't work out a namespace for the module on CPAN. In fact I can't
even work out a category ("Commercial Software Interfaces" is close, but
wily isn't commercial...)
Namespace wise, Text::Wily was suggested on comp.lang.perl.modules, but
the module itself has almost nothing to do with text - it interfaces to
a text editor which I think is a very different thing.
Acme::Wily is another option, but that's subverting the meaning of the
Acme namespace and putting it somewhere that makes it harder to find.
I'd suggest something like: App::API::Wily
Randy.

Re: Ratings and Reviews ne Modules

[Randy W. Sims]

Sorry for the delay. I haven't abandoned this; it's just been a long 
week, and there are some issues here that I've thought of that I'm 
unresolved on, but I'll bring that back up another time...

Eric Wilhelm wrote:
# The following was supposedly scribed by
# Randy W. Sims
# on Saturday 24 July 2004 03:06 pm:

If it does get added, does it get added to all the 
documentation pages or just the main documentation page?

Could you give an example of what is 'main'?  I mean the page with the 
rendered version of the pod.  On my tour, I clicked the bigger-bolder link 
above the search-result entry 
(http://search.cpan.org/~lds/CGI.pm-3.05/CGI.pm) not the 
smaller-seemingly-less-important one below it 
(http://search.cpan.org/~lds/CGI.pm-3.05/).
If you look at the page linked to by the "less-important" url, you'll 
see links to all the pod docs for that module. I was asking if you 
intended that the ratings be added the headers of all of that modules docs.

To me, the former contains information which will let me make an informed 
decision about the module (e.g. the programmer's reference to the API which 
it provides) while the latter gives lots of links, ratings, test results, and 
related stuff, but only tells me this about the module in question: "Simple 
Common Gateway Interface Class" and I have already seen that exact 
information in the search-result entry.
The latter links to all of the modules docs, the README, META.yml, etc. 
for all versions of that module. It's provides a junction point that 
leads to all info on that module. This is always the first place I go. I 
look at the README first, then the main pod. Then I can look at the 
META.yml if I need to check out dependencies, etc. before installing.

One other thing to consider: if ratings are added to the search results 
page, eg. <http://search.cpan.org/search?query=CGI>, then placing them 
on the documentation page is duplicating info that has already been made 
available.

I would also like to see a simple yes/no count in addition to the
rating/reviews.  If you have a list of "35 people use this::module" and
"700 said 'use this::other::module instead'", that helps raise awareness
about the other module, and allows you to make a decision more quickly
based on the experiences of others.
Are you referring to the amazon.com-ish "N persons recommend X instead
of (or in addition to) Y" type recommendations? I'm not sure CPAN is
worth the added complexity. I don't think the target audience is big
enough to justify a lot of "extra" features; the ratings should be
enough, but I could be wrong...

[snip]
I'm not sure right now how useful it would be or how many others would find it 
useful, but yes the N,X,Y is along the lines of what I mean.  The reason that 
I mention it is simply that I had the idea that it might be useful in 
selecting modules (yes, it's a popularity contest and should be ignored in 
favor of an informed decision based on reading the manpage, but we can't 
ignore information that isn't there.)

I'm sort of groping for something to 'season' the average-rating.  Since I am 
suggesting that the average rating be displayed at the top of the manpage, I 
thought I should provide an idea which would allow it to mean more than 5/5 
(e.g. one person rated it 5/5:  'big whoop'.)
agreed. I think where ever "average" ratings are displayed it should 
include the number of reviewers, eg "this module rated 4.5 stars by N 
reviewers".

I think '600 people said "it's useful"' may be more helpful than one mediocre 
review.  60 raving reviews would tend to bend your decision more, but it's 
easier to get 600 people to say 'ok' than it is to get 60 to say 
'this-is-great-and-here-is-why'.

I'm worried about some of the items that are on the list. Some that seem 
obvious like adding ratings to the search results on Search I'm not sure 
about any more. If ratings are used to compare modules (as opposed to 
judging each according to its merrits), some modules might be 
overlooked, especially new modules. Are ratings usefull? I won't argue 
that reviews are usefull. And ratings provide a summary of reviews, so 
are helpfull in that respect. But can ratings be harmfull? ...

Randy.

Re: Ratings and Reviews ne Modules

[Randy W. Sims]

[Did I not reply to list in my previous message?]
Eric Wilhelm wrote:
# The following was supposedly scribed by
# Randy W. Sims
# on Thursday 22 July 2004 10:45 pm:

- Module Version: 3.05
+ Module Version: 3.05   Source  
The ratings are one click away on the dist page.

Yes, but as I said on the 'tour', I don't want or need to click there unless 
I'm trying to download the tarball.  And, since I use the command-line CPAN 
to do the install, I don't need to download the tarball from my browser.  So, 
I almost *never* see that page.


Lincoln D. Stein >  CGI.pm-3.05 >  CGI
^^ click ^^
^^ here  ^^
Module Version: 3.05   Source

My point in putting the star-bar here --^ is that it makes the ratings 
visible.

This accomplishes two things:
  1.  makes ratings more useful (e.g. while I'm reading the manpage (which is 
what drives the decision as to whether it is what I'm looking for) I can see 
the rating (and maybe I should also see a count of how many have rated it.))

  2.  raises awareness about ratings (oh!  there are ratings?), thus getting 
more people to rate/review modules.
I think one of the best ways to raise awareness is to add the ratings to 
the search results from Search. I'm still not sure that I agree about 
putting it on the documentation page, but I have added it to the 
outline. If it does get added, does it get added to all the 
documentation pages or just the main documentation page?

If ratings are good for anything, they are going to be taken with a grain of 
salt.  A 5-star rating vs a 0-star rating is not going to swing me away from 
my own judgement.  They simply give me something else to consider.

I would also like to see a simple yes/no count in addition to the 
rating/reviews.  If you have a list of "35 people use this::module" and "700 
said 'use this::other::module instead'", that helps raise awareness about the 
other module, and allows you to make a decision more quickly based on the 
experiences of others.
Are you referring to the amazon.com-ish "N persons recommend X instead 
of (or in addition to) Y" type recommendations? I'm not sure CPAN is 
worth the added complexity. I don't think the target audience is big 
enough to justify a lot of "extra" features; the ratings should be 
enough, but I could be wrong...

Maybe we need to start prioritizing and weeding out the list at this point?
I hope others are interested in helping to implement these improvements. 
I'm going to try, but I have two obstacles: 1) the usuall problem--time, 
and 2) this is not my area of expertise. I have no experience with CGI, 
setting up Apache, etc. It's an area I've never really gotten into, but 
I hope to use this as an opportunity to learn a little.

Regards,
Randy.

Re: Reviewing reviewers

[Randy W. Sims]

On 7/22/2004 11:41 PM, Eric Wilhelm wrote:
# The following was supposedly scribed by
# Randy W. Sims
# on Thursday 22 July 2004 07:56 pm:

  A) Abuse
 Authors abusing the system for political statements, to sabatoge
 authors of similars modules, etc.
1) The usuall solution is a Karma type system. Number of reviews
   contributed by a reviewer. Thumbs up/down for individual reviews
   by a reviewer ("Helpfulness ratings"). Thresholds on Karma that
   automatically invoke a moderator.

Okay, so if I go on a bashing-fest and then you come through and thumbs-down 
all of my reviews, I'll go through and thumbs-down your reviews too and then 
bash on your modules if I haven't made it there already.  Does that trigger a 
karma threshold of some sort?  Seems that it would be hard to detect.

How about peer-review of peer-review:
If I say that your review was bad, I think the next step is for you to defend 
your review (unless it has previously gotten a thumbs-up, in which case I 
must support my thumbs-down with a critique of your review.)

There may be a somewhat recursive process of attack and rebuttal here, but the 
point is that a mean review is likely not going to be defended, and even if 
it had received a spurious thumbs-up, a critical dismissal of said mean 
review is likely to be supported rather than dismissed (thus giving weight to 
the dismissal and counting further towards the thumbs-down.)

Recursion to level 3-or-so (pi) of the attack-rebuttal tree may invoke a 
moderator (or just a chanting, blood-lusting crowd/mob.)

Additional weight can be given to reviewers who have posted many reviews and 
received many thumbs-up, etc.  But, the idea behind the tree is that it 
localizes the debate to the review in question (rather than risk weighting 
solely on what may have been karma generated by a flaming disagreement about 
a completely different module's merits.)

Absolute dead-beats can still be identified by their failure to provide a 
rebuttal or continually reaching level pi() with nonsensical or null 
arguments.
I don't think anything this complicated or involved is needed. Neither 
am I convinced that the Karma solution is the best or a complete 
solution. However, This is pretty much the system that Amazon.com uses 
and it works pretty well IMO. Also, for this to get into back and forth 
arguments/bashing, the reviewers would have to attempt to track all of 
their reviews. The system would not provide an easy way to do that-there 
is no legitimate need for such a feature since the system is about 
reviews not reviewers. That's not to say it's not possible, but it's not 
easy either. I think that will discourage a large percentage of abuse, 
and high percentages is the best you can shoot for.

Regards,
Randy.

Re: Ratings and Reviews ne Modules

[Randy W. Sims]

On 7/22/2004 5:50 PM, Randy W. Sims wrote:
We just need to organize and do it.
1st crack at organizing ideas/suggestions made in this thread and in 
Ask's TODO list. Comments/Omissions?

Also available at <http://www.thepierianspring.org/perl/cpan-ratings.notes>
--
I) CPAN Ratings
  A) Abuse
 Authors abusing the system for political statements, to sabatoge
 authors of similars modules, etc.
1) The usuall solution is a Karma type system. Number of reviews
   contributed by a reviewer. Thumbs up/down for individual reviews
   by a reviewer ("Helpfulness ratings"). Thresholds on Karma that
   automatically invoke a moderator.
2) See also item I.C.1.
  B) All Reviews Pages (per module):
1) Header with average rating and other summary information.
  C) All Reviews Pages (per reviewer):
1) Header with reviewer information. (Obfuscated email address
   for one thing; try to keep people accountable).
  D) Searching
1) If the number of reviews per module gets large, sorting on
   rating/date/version may be useful.
2) Search results should include direct link to all reviews.
3) Search results should include "average rating". (average per
   version?  overall average?)
4) Allow direct search for reviews. I.E. don't send user off to
   CPAN Search, but do try to use it behind the scenes.
  E) Browsing for modules (?)
1) By module/author.
  F) Author's Administrative interface
1) Edit review? - Original author only.
2) "Delete this review" - Original author only.
  G) "Top rated modules list" - Would this encourage abuse?
  H) RSS Feeds
1) RSS feed of sitewide "recent reviews"
2) Include rating numbers in the RSS feeds
3) Subscribe to reviews of certain distributions
   (preferably by author)
4) Reviews of modules by a certain author (for CPANID.rss feeds)
   [RWS: Same as above?]
  I) Ratings
1) If a reviewer reviews two or more versions of a module, how are
   the averages calculated?
2) Expand set of rated attributes?
3) Let 'Overall' rating be calculated based on other specific
   attributes or let there be some additional type of 'overall' that
   is calulated, and let it be used in summaries--to _encourage_ a
   more balanced review (and discourage abuses).
  J) Other
1) Reviews in other languages (with filters etc).
2) Parse Embperl-2.0b9 correctly.
3) Include the other rating numbers on [some page].
II) Misc:
  A) "Module Pages"
 Usage tips & experiences not directly related to reviews. Doesn't
 have to be organized around modules; it can be organized around
 topics (ala emacswiki). Linked to from CPAN Ratings? CPAN Search?
  B) Best of breed reviews.
 A single comparative review written on several similar
 modules. How would this show up in a search? Does this belong
 with CPAN Ratings?
III) Search CPAN:
  A) make /d/CGI.pm work
 Bug seemingly in Search CPAN for CPAN.pm (others?) possibly due
 to '.pm' being part of name. This appears on the module dist page
 for links to CPAN Testers & CPAN Ratings as 404 errors.
  B) Sorting
 Search results by relevance/rating.
  C) Searching
1) Improve searching with Keywords (META.yml)

Re: Ratings and Reviews ne Modules

[Randy W. Sims]

[BCC]
On 7/22/2004 4:05 PM, Eric Wilhelm wrote:
# The following was supposedly scribed by
# Ken Williams
# on Thursday 22 July 2004 01:50 pm:

I was sort of hoping this idea would just die on its own, but now it
looks like people are actually getting ready to do it.  

I'm going to jump on the bandwagon with Ken on this one.

In my opinion 
this is a bad idea.  I don't want a bunch of reviews all over CPAN
disguising themselves as modules.

When the discussion started, it was about the ratings and reviews system which 
is already available on CPAN (though little-used.)

I suggested why it was little-used, but that seems to have fallen by the 
wayside.
Agreed. Reviews as modules is not the best solution. CPAN does one thing 
and does it well. Adding reviews as modules is likely to cause more 
problems that it solves.

So how
about working with those people to fix whatever you think is broken
about them before polluting CPAN with all this non-code?

Let's take a tour...
searching for something...
  http://search.cpan.org/search?query=CGI&mode=all
we click through...
  http://search.cpan.org/~lds/CGI.pm-3.05/CGI.pm
NO RATINGS ON THAT PAGE!  So, we click the 'up'-like link...
  http://search.cpan.org/~lds/CGI.pm-3.05/
ok, now we see the ratings, click-through to get reviews...
  http://cpanratings.perl.org/d/CGI.pm
Or do we?  I get a 404.  Not much use.
That's a bug. You'll notice the same bug if you click on the CPAN 
Testers link. Is this a bug in ? CPAN.pm is one of the 
few if not only module that has a name which includes the extension.

To continue the tour, let's hop over to some module which does have reviews...
  http://cpanratings.perl.org/
Alright, pick one at random...
  http://cpanratings.perl.org/d/YAML
Finally, here we are at a page with reviews.  Frankly, I've never seen one of 
these before, and I can't say that this one really does me a huge amount of 
good.  I'm much better served by reading the documentation (which should 
speak for the quality of the module on it's own.)  However, the 1-5 star 
rating DOES provide a nice at-a-glance view of others' opinions.

So, we have ratings, and we have reviews.  What's wrong?
If anything, the ratings should be shown in the header of the documentation 
page:  http://search.cpan.org/~lds/CGI.pm-3.05/CGI.pm and possibly even in a 
column of the search results (now, THAT would be really useful), instead of 
3-clicks into my search.  And, clicking on the bar-o-stars should be a link 
to the reviews (which should, of course, work.)  It is worth noting that I 
(and likely many others) rarely make it to the third click.  Rather,  I skim 
the documentation, and from there I'm off to a terminal where I type "perl 
-MCPAN -e shell" and install the module.

There's more to be done to make it easier to rate and review modules (and one 
should be able to rate without reviewing for a simple thumbs-up (though 
3-or-less stars may require explanation...))

But, the first thing to do is to MAKE THE RATINGS VISIBLE.  That won't be 
accomplished by creating a new website (except as a trial 'fork' of the main 
one) and it won't be accomplished by pretending that Ratings::foo is a 
module.

Yes, this is long, and SORRY FOR SHOUTING.  I'm just trying to emphasize the 
important bits for those that are skimming.

There have been others with mostly the same opinions throughout this 
discussion, so we basically just need the source for search.cpan.org and 
somebody to write a patch, right?
Ask posted with information about where to find the source for CPAN 
Ratings, and invited patches. Maybe if we could come up with a list of 
requirements as a start (not implementation or solutions, just 
requirements), we could then look them over as a group and figure out 
which ones are real problems that we need to fix. Then we prioritize 
them, figure out how to solve each, and start writing and submitting 
patches. Note there is also an (outdated) TODO list on the "About" page 
on CPAN Ratings, right next to the links for the source.

This doesn't solve all the issues with , but it will be 
a place to start. And starting seems a good thing to do. This discussion 
has arisen in a dozen or so different threads over the last few months, 
so it is definately a problem ripe for solving. We just need to organize 
and do it.

Regards,
Randy.

Re: [Module::Build] requires_one_of

[Randy W. Sims]

David Wheeler wrote:
Even less parsing:
>   ...
  db_driver => [qw(mysql pg)],
Yeah, I thought about that when I saw one of your previous posts. My 
hesitation to adopt it is that the only way to infer the OR relationship 
is by the value being of type ARRAY, which means that future additions 
to the spec might be limited. Also, what if we wanted to add an XOR 
operator?

As a string, you have the flexibility of allowing more complex 
expressions if they are ever needed, for example an IF operator... Not 
that I think there is a need for either an XOR or IF operator, but I 
like to keep things open.

Randy.

Re: [Module::Build] requires_one_of

[Randy W. Sims]

David Wheeler wrote:
Even less parsing:
>   ...
  db_driver => [qw(mysql pg)],
Yeah, I thought about that when I saw one of your previous posts. My 
hesitation to adopt it is that the only way to infer the OR relationship 
is by the value being of type ARRAY, which means that future additions 
to the spec might be limited. Also, what if we wanted to add an XOR 
operator?

As a string, you have the flexibility of allowing more complex 
expressions if they are ever needed, for example an IF operator... Not 
that I think there is a need for either an XOR or IF operator, but I 
like to keep things open.

Randy.

Re: [Module::Build] requires_one_of

[Randy W. Sims]

Ken Williams wrote:
On Jul 18, 2004, at 10:08 AM, David Wheeler wrote:
On Jul 17, 2004, at 8:57 PM, David Wheeler wrote:
Agreed. I'm racking my brains (and the brains of those around me), 
but I'm not coming up with anything. I like finding the right 
language for things, though, so I'll have to think about it...

Hrm, I kind of like Smylers' suggested term, "abstract". Maybe 
abstract_requires in Module::Build?

Sorry I haven't had a lot of time to chime in - we had the baby niece & 
nephew over the weekend.

Unfortunately "abstract" is already taken  in the META.yml: it's a short 
descriptive phrase of the module.

Regarding the concept-formerly-known-as "virtual packages", I think I'd 
like them to tie into the "features" concept more.  I think perhaps it's 
time to write that boolean requirement specification stuff, and then we 
can use that both in the "normal" requirement specs and the requirement 
specs for a declared feature.

The idea would look something like this:
  in the Build.PL --
 features => {
  # Old-style requirement spec
  'yaml_support' => {
 description => "Can read & write YAML 
files",
 requires => { 'YAML' => 0.13 },
 recommends => { 'YAML' => 0.49 },
},
  # New-style requirement mini-language spec
  'dbi_support' => {
 description => "Can read & write 
databases",
 requires => q{
  DBI >= 1.0 ,
  (DBD::mysql >= 1.5 || DBD::Postgres)
 },
},

This method will require a complete expression parser, which is 
admittably easy to implement. It just seems a little more error prone. 
Also, expressions can be arbitrarily complex which can make it more 
difficult to write expressions in a human readable format (David's 
example hints at that complexity). That's why I liked extending the 
existing format: less parsing for humans and machines.

features => {
  ...
  dbi_support => {
description => "Can read & write databases",
requires => {
  DBI >= 1.0,
  db_driver => q{ [mysql] || [pg] },
  [mysql] => {
DBD::mysql => 1.5,
DataTime::Format::mysql => 0
  },
  [pg] => {
DBD::Pg => 0,
DataTime::Format::Pg => 0
  },
},
},
This way most of the parsing is already done; Most all the terms are 
already broken down into indivisible fields. It's more human readable 
(IMO), though, perhaps a little more verbose. The macros help diffuse 
the complexity of expressions.

Randy.

Re: [Module::Build] requires_one_of

[Randy W. Sims]

A. Pagaltzis wrote:
I am getting the feeling you haven't understood what I am talking
about, and you are also proposing something as "virtual packages"
that is completely different from how "virtual packages" actually
work, at least in Debian.
The key points are:
1. Virtual packages exist in the repository only.
2. Provision of a virtual package by any real one is decided by
   the real package's author, by claiming (via package metadata)
   to provide this package.
erm, I think the confusion is my fault. In my original message I wrote 
two paragraphs about virtual packages. In the first I was describing the 
way Debian works. In the second, and what we have mostly been refering 
to in this discussion, I was describing a way we could have something 
similar in concept to Debian's virtual packages. The difference being 
that the psueudo virtual package (there's something wierd about that 
term) is entirely contained within the META.yml file. In function, it's 
really more of a macro than a virtual package, but unfortunately, I 
clouded the matter by using the same term. If you look again at my 
example META.yml entry:

requires:
  db_driver: [postgresql] || [mysql]
  [postgresql]:
DBD::Pg: 0
DataTime::Format::Pg: 0
  [mysql]:
DBD::mysql: 0
DataTime::Format::mysql: 0
In this case I was calling "db_driver" a virtual package because it 
represents a requirement, but is not an actual module; It represents a 
requirement that may be satisfied by any of the two modules listed. It 
serves the same basic purpose as Debian's as in Debians system, but it 
is implemented differently in that it is defined on a per package basis.

Re: [Module::Build] requires_one_of

[Randy W. Sims]

David Wheeler wrote:
On Jul 17, 2004, at 10:12 AM, Randy W. Sims wrote:
Also, if there were a single module that all tools used to check 
requirements, it could include builtin macros for common "virtual" 
packages: DBD, DBM, Archiver, Encryption, ...

Hrmm, yes, that would be nice, too. Did you just volunteer to write it? :-)
Well, there's a rough start on one at 
<http://www.thepierianspring.org/CPAN-Metadata-0.00_02.tar.gz> that I 
started several months ago, but haven't had time to finish (I haven't 
been very productive at anything for the last couple months :-( ). 
Amoung other things it takes all the version checking code out of 
Module::Build so that it can be used by other modules. I'll try to take 
a look at getting polished off if it seems like a good idea to everyone.

Randy.

Re: [Module::Build] requires_one_of

[Randy W. Sims]

On 7/17/2004 12:25 PM, David Wheeler wrote:
On Jul 16, 2004, at 7:48 PM, Randy W. Sims wrote:
It looks like maybe we could use 'virtual' packages like I mentioned 
below to solve this:

Erm, that should have been:
YAML:
requires:
  db_driver: [postgresql] || [mysql]
  [postgresql]:
DBD::Pg: 0
DataTime::Format::Pg: 0
  [mysql]:
DBD::mysql: 0
DataTime::Format::mysql: 0
Keys in brackets (that is legal YAML isn't it?) are not evaluated until 
they are encountered in the value part of an expression who's key is not 
also a macro.

Square brackets denote virtual packages or macros. This should solve 
all the issues you mention as far as YAML goes. The Build.PL file is 
much more flexible; we can express these dependencies in many ways. 
There is not much of an issue there.

Yes, that works for me.
Note that there is an implication for CPAN.pm and CPANPLUS. When a 
requirement with an OR condition is encountered they will have to either 
prompt the user for a selection or select the first option as a default. 
I'm not sure if there are any other compatability problems as I'm not 
real familiar with their implementation. But the author's should 
probably be consulted before making a final decision.

Also, if there were a single module that all tools used to check 
requirements, it could include builtin macros for common "virtual" 
packages: DBD, DBM, Archiver, Encryption, ...

Randy.

Re: Cpan Ratings

[Randy W. Sims]

On 7/17/2004 11:36 AM, James Keenan wrote:
Pardon my ignorance, but ...
What is the 'default phone-home behavior' in the Makefile.PL's about 
which Randal was complaining?

Is it the author's 'Perlish' coding style, in which he places 
statement-ending semicolons at the start of the line?  Or something else?
First, let me say that I did not intend for any names to come up, nor 
did intend my previous message as any type of specific accusation. I was 
only pointing out an example of percieved misuse that I had stumbled 
across a while back, and that I thought was relevant to this discussion.

For anyone who wants to see the Makefile.PLs in question they can still 
be found on some mirrors by googling for, say, 'CGI-Builder-1.24'. 
Currently, I find them at .

There are two separate issues here. The first, whether this author did 
violated some implicit moral code in the way he/she wrote the 
Makefile.PL. This issue only matters in that if it was something really 
wrong, then the reviewer might be justified in doing what he did. The 
behavior in question is that the Makefile.Pl will check to see if LWP is 
installed, and if it is try to contact the author's website to see if 
there is a more recent version of the module and if so to notify the 
user. I guess the main "problem" with this is that it does so without 
giving the user a choice.

I don't agree with this behaviour. As an option it would be acceptable. 
Note that there is a module on CPAN that also polls for modules across 
the internet: ExtUtils::AutoInstall. The major difference, as it relates 
to this discussion, is that it polls CPAN, a known and trusted site. 
However, I don't think this justifies the reviewers actions.

And that is the second issue, the one relevant to this discussion: Was 
this a misuse of CPAN Ratings?

Randy.

Re: META.yml keywords

[Randy W. Sims]

On 7/16/2004 8:54 AM, Ken Williams wrote:
On Jul 14, 2004, at 2:11 PM, Randy W. Sims wrote:
The spec doesn't currently provide for keywords. I do think it would 
be a good idea, BUT I think it needs to be done in a way to avoid abuse.

I think maybe it would be better to put keywords right in the pod for 
the module, so they become part of the documentation too.  This is 
similar to the way they often appear in academic papers, right after the 
abstract - and people often find it useful for pinpointing the subject 
matter.
Is it usefull to have in the pod? It seems like meta information to me; 
i.e. it seems like it would only be usefull to indexers. I am concerned 
that META.yml might become a huge document if everything gets put in 
there, but I think if we agree that it would be usefull to have 
keywords/catagories, then the best place is in META.yml. This also has 
the benefit that you can have a lightweight indexer that only has to 
look in one place.

Randy.

Re: META.yml keywords

[Randy W. Sims]

On 7/14/2004 3:44 PM, Mark Stosberg wrote:
On Wed, Jul 14, 2004 at 03:11:11PM -0400, Randy W. Sims wrote:
Fergal Daly wrote:

Does META.yaml have a place for keyowrds?
The spec doesn't currently provide for keywords. I do think it would be 
a good idea, BUT I think it needs to be done in a way to avoid abuse. 
I'd hate to see META.yml files grow by the kb as authors add every 
conceivable keyword they can think of and try to manipulate the search. 

The search algorithm could pay attention to the first X keywords and
ignore the rest. Or at least, it could heavily weight the first few.
I think this is part of how search engines prevent the same kind of
above of the meta-tag keyword system. You can put as many keywords as
you want into the list, but I think the search engines only really care
about the first few.
That seems a reasonable approach to overcoming the abuse problem. There 
is, however, another advantage to the catagory approach: Searching would 
likely be more consistent. It would help authors to place their modules 
so that they can be found with similar modules. It would also help 
ensure that users looking for a particular type module will get back a 
result set that is likely to contain all/most of the modules of that type.

I would prefer something like this over the "choosing from the fix list"
idea.
Having free-form tags is a feature I like on: http://del.icio.us/
It allows new classifications to spontaneously appear.
I will conceed that there are definate advantages to the keyword approach.
Randy.

Re: [Module::Build] requires_one_of

[Randy W. Sims]

David Wheeler wrote:
Moving the conversation over to module-authors...
On Jul 16, 2004, at 11:52 AM, Randy W. Sims wrote:
David Wheeler wrote:
On Jul 9, 2004, at 3:00 PM, David Wheeler wrote:
Yes, but what about applications that require one among a list of 
modules? I'm thinking of things like DBIx::SearchBuilder, which 
requires one of several DBDs, and various XML modules, which require 
one among a list of parsers. In a case such as that, I don't know 
what to do about META.yml.

Maybe there should be a way to specify that there is a requirement 
for one among a list of modules? Or even that there one of several 
groups of modules is required? Something like this:

requires_one_of {
dbd => {
DBD::Pg => {
DBD::Pg => 0,
DateTime::Format::Pg => 0,
},
DBD::mysql => {
DBD::mysql => 0,
DateTime::Format::mysql => 0
}
},
parser => {
XML::Parser => 0,
XML::LibXML => 0,
}
}
Here either XML::Parser or XML::LibXML is required, and either 
DBD::Pg and DateTime::Format::Pg or DBD::mysql and 
DateTime::Format::mysql. These could also be represented in YML, of 
course.
Should I resend this proposal to the module authors list?

I think one of Ken's original ideas (and one that I like really like) 
is to provide a flexible language for describing dependencies, 
including situations like you describe above. IIRC, the idea was to 
provide a way of saying things like:

DBD::Pg > 0 || DBD::mysql > 0

That's not bad, although it doesn't help to specify collections of 
related modules like my proposal does.
I missed the part about collections. See below.
> Also, AFAIK, the current
Module::Build syntax for version number requirements doesn't support 
this, and isn't likely too, it seems to me, since module names are not 
included in the version spec string. They're only the hash keys.
It looks like maybe we could use 'virtual' packages like I mentioned 
below to solve this:

YAML:
requires:
  [db_driver]: postgresql || mysql
  [postgresql]:
DBD::Pg: > 0
DataTime::Format::Pg: > 0
  [mysql]:
DBD::mysql: > 0
DataTime::Format::mysql: > 0
Square brackets denote virtual packages or macros. This should solve all 
the issues you mention as far as YAML goes. The Build.PL file is much 
more flexible; we can express these dependencies in many ways. There is 
not much of an issue there.

I guess one other thing that needs to be considered is: allowing other 
modules to make use of this. I think one of the things we wanted to 
allow is for the actual package being installed to access some of the 
same functionality in order to allow/disallow some functionality. For 
example, some modules will run in an enhanced mode if a module is 
present. It would be nice if we could provide this type of dependency 
checking in a central place. I believe that this is where a module like 
CPAN::Metadata comes in, but I think Ken had some other ideas. But a 
more complex specification like above certainly seems to argue for 
providing an interface for determining whether those dependencies are 
satisfied.


Debian's package manager does something different. A package can 
belong to a 'virtual package'. For example there is a virtual package 
for email-client. Any package that belongs to the virtual package 
email-client would satisfy the dependency of another package that 
depends on the that virtual package.

Hrm. That's not a bad idea. Not sure how that'd work with CPAN, though. 
Bundles are the closest thing, and even with the successful installation 
of a bundle doesn't mean that all of the modules it includes have been 
successfully installed.

While I like debian's approach, I'm not sure it can easily be 
retrofitted onto the current system. One way in which it might be 
possible is to introduce macros such that you can define 'virtual 
packages' in the META.yml file and the packages that satisfy it. Then 
use that macro in the requirements. Of course, the thing that makes 
Debians system nice is that you do not have to change the package that 
has a requirement on a virtual package when a new package that also 
fits the requirement is introduced. But that would require a database 
of all CPAN modules.

Yes, which there is, in the module list, but it's pretty limited at this 
point. I kind of like this idea, too, but I'm not sure how well it will 
work. The advantage to my proposal, on the other hand, is that it's 
fully self-contained in the META.yml.

module-authors might be able to come up with some other alternatives.

Moved there now. Thanks for the feedback.
Regards,
David

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

[Randy W. Sims]

Robert Rothenberg wrote:
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.
A while back I started on a module to read, write, & validate the 
META.yml file according to the spec. I'm not sure if it's usefull or 
relevant, but it can be found at 
.

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? Like I said, I haven't really 
investigated myself, so I'm just asking.

Is that a good name for it?
I think some of the modules that perform this task are in the Module::* 
namespace. That's shorter and seems more appropriate.

Randy.
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

META.yml keywords (was: Re: Finding prior art Perl modules)

[Randy W. Sims]

Fergal Daly wrote:
Does META.yaml have a place for keyowrds?
The spec doesn't currently provide for keywords. I do think it would be 
a good idea, BUT I think it needs to be done in a way to avoid abuse. 
I'd hate to see META.yml files grow by the kb as authors add every 
conceivable keyword they can think of and try to manipulate the search. 
As limiting and as clumsy as it seems, I think that if keywords are 
added then it should be from a limited set of keywords, i.e. more of a 
classification scheme, really, where modules can appear under multiple 
classifications.

Randy.

Re: Future of the "Module List"

[Randy W. Sims]

On 7/14/2004 5:51 PM, Tim Bunce wrote:
On Wed, Jul 14, 2004 at 12:40:03PM -0500, Dave Rolsky wrote:
On Wed, 14 Jul 2004, A. Pagaltzis wrote:

* Dave Rolsky <[EMAIL PROTECTED]> [2004-07-14 19:26]:
Some of them _are_ registered, but that document you're
referring to hasn't been regenerated since 2002/08/27!  I wish
the CPAN folks would just remove it if it won't be generated
regularly.
Does anyone else here think that the list should probably just be
done away with entirely?

The _file_ should go, yes. The concept of registering modules is different.

Given the fact that most authors seem to not register their stuff, the
[EMAIL PROTECTED] list is slow as heck, and that the web pages never get
regenerated, yes.

Those are all fixable. Volunteers?
The real issues are bigger and deeper. I've appended a couple of emails.
Tim.
On Mon, Feb 16, 2004 at 10:37:12AM +1300, Sam Vilain wrote:
On Mon, 16 Feb 2004 01:32, Tim Bunce wrote;
 > I'd like to see a summary of what those "needs of the community"
 > are.  (Maybe I missed it as I've not been following as closely as
 > I'd have liked. In which case a link to an archived summary would
 > be great.)
 > It's very important to be clear about what the problems actually
 > are.
I don't really want to argue this side of things, I think that the
problems pretty much speak for themselves.  But I hate unspoken
consensus, so let me suggest a few from my perspective; this applies
to the combined Perl 5 modules list / using search.cpan.org:

I'll play devils advocate here and point out some alternative remedies
for the problems. By doing so I'm _not_ trying to detract for your
suggestion, which I like, I'm just trying to show how existing mechanisms
could be improved incrementally.

 a) searching for modules for a particular task takes a long time and
unless you get your key words right, you might not find it at
all.  Refer the recent Mail::SendEasy thread.

Calls for a richer set of categories and cross-links of some kind.
(Editorial content alone is basically just more words to a search engine.)
Are we talking about the same thing:  ?
 b) it is very difficult to find good reviews weighing the pros and
cons of similar modules; they exist, but are scattered.
CPAN ratings was a nice idea, but has too many "First Post!"
style reviews to be useful in its current form IMHO.

Argues for moderation of reviews and a minimum review length.
A "was this review helpful" mechanism would also help to bring
better reviews to the top.  Also the search.cpan.org should not
just show the overall rating, it should show the underlying three
individual ratings (docs, interface, ease of use).
This is definately a trouble area. Not long ago I was exploring the 
cpanratings site and discovered the unhelpful "rampage" by one 
particular reviewer . Maybe breaking 
the reviews into catagories would be helpful? Rate: installation, 
interface, robustness, overall, etc.

 c) it is nearly impossible to tell which modules are the wisest
choices from a community size point of view; using modules that
are more likely to fall out of maintenance is easy to do.

Argues for more stats. I think useful *relative* download stats
could be extracted from a sample of CPAN sites. Also search.cpan.org
could provide relative page-*view* stats for modules.
Narrow the interface for CPAN such that all viewing takes place on a 
single server where it can be monitored, and all download requests are 
distributed to mirror sites (ala sf.net).

As for the best of the best, I still believe there is a lot of merrit in 
the list built from dependencies idea.

 d) some great modules are not registered (I am referring of course
to such masterpieces as Pixie, Heritable::Types, Maptastic :),
Spiffy, Autodia, Want ... and those are just the ones missing
in my bag of tricks)

Argues for fixing the registration process.

This is why I am mailing you to ask: what's going on?  Why is such
an outdated module list being published in an authoritative location,
and where can I get an up-to-date list?

Module List *document* was maintained by hand.  When managment of
the Module List *data* was automated there was a desire to automate
maintainance of the document but the document had a slightly richer
structure than the data. That small hurdle meant automation never
happened and the document was left unmaintained.
Around the same time search.cpan.org became functional so the
document had less relevance and busy people had other things to do.
I'll happily conceed that the *document* isn't important these days.
But I feel strongly that the *principle* (of moderated naming and
categorization) is.
The main pieces currently missing are:
1. Automated handling of module registration. [Where has that got to?]
2. Better integration of registration data into search.cpan.org
   So registration details are includes in search results, for example.
3. A 'fast path' process to register many 

Re: New module: Regexp::Trie

[Randy W. Sims]

On 7/14/2004 5:29 PM, David Landgren wrote:
Hello,
I gave a talk at the French Perl Workshop in June about some work I was 
doing to produce really large (i.e. length($re) > 5) regular 
expressions for Postfix access maps. (Postfix can be compiled with the 
PCRE library). A number of people expressed interest in the approach and 
wondered if and when it would be available as a module on CPAN.

The idea is that sometimes you have a large set of regular expressions 
(e.g. 2000), and you want to test whether a string matches any of them. 
You don't particularly care *which* expression matches, the fact that 
one matches is sufficient. Brute forcing it with a loop is not very 
efficient. Concatenating them with | is not efficient either, if a large 
subset of the expressions share a common prefix.

I know about Jarkko's Regex::PreSuf and another module whose name 
escapes me this instant, but they both suffer from the limitation of not 
being metacharacter-aware. For instance:

use Regex::PreSuf;
print presuf(qw(a\d+foo a\D+123));
produces:
a\\(?:D\+123|d\+foo)
The module I'm developing works with variable length tokens, and thus 
deals with the above correctly:

use Regexp::Trie;
my $rt = Regexp::Trie->new;
$rt->add( qw/a \\d+ f o o/ );
$rt->add( qw/a \\D+ 1 2 3/ );
print $rt->re;
produces:
a(?:\D+123|\d+foo)
(modulo me getting the backslashes escaped correctly here -- the 
algorithm does the right thing).

The above example contains (IMO) too much make-work code, so I'm 
planning on distributing a number of helper packages as well, which will 
take care of the general cases. I'm thinking of something like

my $rt = Regexp::Trie->new(
Regexp::Trie::Lex::simple(qw( a\\d+foo a \\D+123 ))
);
print $rt->re;
I.e., the Regexp::Trie::Lex::* namespace, whose packages simply have to 
return an object that contains an 'add' method. The Regexp::Trie::new 
constructor will simply take the returned object and call its 'add' 
method until exhaustion, and fill up its own internal structure.

As another example, I have a set of regexps that should never contain a 
bare . (dot) metachar. To do so is an error. Writing a seperate lexer 
package for this allows such error-checking to take place.

I spoke with Nicholas Clark about the item in the latest perltodo, 
specifically:


=head2 common suffices/prefices in regexps (trie optimization)
Currently, the user has to optimize C and C into
C and C<[fg]oo> by hand; this could be done automatically.

This is apparently a non-trivial undertaking to do in core and he 
suggested I pursue the release of this module regardless (I'm targetting 
5.005_03 as a baseline anyway).

If I haven't put you to sleep by now, I have the following questions:
1. Has this been done before (i.e. shoot me now and put me out of my 
misery).
I haven't seen anything, but I haven't really looked either. I do see it 
as being a usefull module though.

2. Is Regexp::Trie a good name? (I fall into the "regexp is spelt with a 
p" camp, but if Regex is preferred that's fine by me. I can never 
remember which, if either, is deprecated).
Definately in the Regexp::* namespace. Trie?
3. Is the lexer namespace a good idea? Or is there a better way do to 
this? I'm open to any design suggestions on this issue since nothing is 
written yet.
What about Japhy's new Regexp::Parser ?
Thanks for reading this far,
David Landgren

Re: META.yml keywords

[Randy W. Sims]

darren chamberlain wrote:
Is anyone generating META.yaml files by hand?  I thought they were all
generated (and regenerated) by Module::Build/MakeMaker?  How would that
work in the case of keywords?
I haven't updated it in a while*, but 
 shows in the "META.yml 
generated_by" section (partially duplicated below) that a few people 
are. This is done in by indicating to M::B/MM(?) that you want to handle 
the META.yml manually or by overriding the targets that generate the 
META.yml file.

META.yml generated_by:
:
  25
  Convert::Binary::C Makefile.PL 1
  Hand 1
  Kostas Pentikousis 1
  Mattia Barbon, by hand 2
  Tie::Hash::Indexed Makefile.PL 1
  hand 1
  hand!1
* Anyone wanting to update it can find the script at 

Re: META.yml keywords

[Randy W. Sims]

Matthew Sachs wrote:
On Jul 14, 2004, at 12:11, Randy W. Sims wrote:
Fergal Daly wrote:
Does META.yaml have a place for keyowrds?

As limiting and as clumsy as it seems, I think that if keywords are 
added then it should be from a limited set of keywords, i.e. more of a 
classification scheme, really, where modules can appear under multiple 
classifications.

Keywords are necessarily specific to the domain of the module, so I 
don't think that any global entity can designate an appropriate fixed 
set.  For instance, my module Net::OSCAR implements the protocol used by 
AOL Instant Messenger, so I'd give it keywords ["OSCAR", "AIM", "IM", 
"AOL Instant Messenger", "instant messenger", "instant messaging", "chat"].
Classification for a module would probably be something like:
Net :: Protocol
Communications :: Chat :: AOL Instant Messenger
(That last comes from sf.net's topic system)
With the classification above AND a good one line synopsis of the module 
(which is already part of META.yml) most, if not all, of your keywords 
are covered.

Randy.

META.yml keywords (was: Re: Finding prior art Perl modules)

[Randy W. Sims]

Fergal Daly wrote:
Does META.yaml have a place for keyowrds?
The spec doesn't currently provide for keywords. I do think it would be 
a good idea, BUT I think it needs to be done in a way to avoid abuse. 
I'd hate to see META.yml files grow by the kb as authors add every 
conceivable keyword they can think of and try to manipulate the search. 
As limiting and as clumsy as it seems, I think that if keywords are 
added then it should be from a limited set of keywords, i.e. more of a 
classification scheme, really, where modules can appear under multiple 
classifications.

Randy.

Re: new module: Time::Seconds::GroupedBy

[Randy W. Sims]

On 7/13/2004 8:01 PM, Bruno Negrão wrote:
Oh, what a sadness. Indeed i never saw the DateTime project before.
But still my module is far easier to use than DateTime::Format::Duration.
Do you believe it is worth to publish it in Time::Seconds::GroupBy?
Not sadness, experience. Actually this was an exercise on the perl QotW 
(Quiz of the Week) mailing list[1]. So you are not the only one to write 
this code and then throw it away :-) It does seem this task is 
adequately provided for by at least 2 other modules, so...

Regards,
Randy.
1. 

Re: ANNOUNCE: WWW::Map 0.01

[Randy W. Sims]

Dave Rolsky wrote:
On Fri, 10 Jul 2004, Scott W Gifford wrote:

Right now I'm leaning towards either keeping WWW::Map or going with
WWW::MapService.  I think the former is actually reasonably clear given
the WWW namespace, which is all about interacting with web stuff, not
generating HTML or anything like that.
I like WWW::StreetMap, since that's exactly what they are, and is
short and unambiguous.  I don't think WWW::MapService is much better
than WWW:Map, but then again I don't think WWW::Map is that bad.  :)

Calling it StreetMap would definitively remove the possibility of making
links that aren't to actual addresses, which as someone pointed out, is
possible with at least MapQuest.  You can plug in "Minneapolis, MN" and
it'll give you a map of the area.
I'm not sure it does. I've worked alot with mapping software (mostly 
DeLorme StreeAtlas and MapQuest), and I always think of a street 
map/atlas as a tool to _locate_ or _find_ any type _place_ or _location_ 
 whether it by address, by place name, by postal code, by coordinates, 
etc. You might also (if you haven't already) consider possible 
extensions such as routing directions.

Randy.

Re: Perl's Sacrifice Stone

[Randy W. Sims]

khemir nadim wrote:
Hi,
I started a vonlontary review on Perl Monks. I don't know if it's the best
place but since they have reviews I thought it would be a good place to
start with (and I couldn't think of a better place). It hasn't given any
result so far :-) . If some of you would be nice enough to review the module
I put there or put a module that they want to be reviewed, that might start
things up.
Hmm, we have:
1) Simon's code review ladder: 


2) Ask's CPAN Ratings: 
3) Perl Monks' Reviews: 
Each has a slightly different focus, but there is some overlap. A part 
of me wonders if they should be at least loosely linked together instead 
of remaining 3 independant but related review tools for authors & users; 
maybe one review site with two faces, one to help module users find 
modules and the other to help module authors improve their modules.

Randy.

Re: not-so-plain documentation

[Randy W. Sims]

On 6/24/2004 11:11 PM, Eric Wilhelm wrote:
Hi everybody!
I'm going to be documenting a system of (30+) programs with is mostly scripts, 
rather than modules.  I know you can just put pod text in your scripts, but 
I'd like to also integrate the usage messages into the pods (or get them from 
the pods.)

I've seen pod2usage() and this would work, but most of these scripts have some 
defaults set for variables that can be changed with the GetOptions flags and 
I'd like to show these defaults at least in the help message.

Example:
my $rounding = 0.01;
GetOptions(
'round=f' => \$rounding,
'help'   => sub {usage()},
);
sub usage {
print "usage:  $0 \n";
print "options:  --round(default  $rounding)\n";
}
END
Since the strings printed by usage() in this case are generated on the fly, 
the values which have already been set are available to be printed.  With 
pod2usage() and perldoc, this is not the case.  Is there any way to make this 
work without having to maintain duplicate information?

Preferably, something that would try to do() the file up to a certain point, 
gather the variables and perform a substitution (maybe on a tag like 
v<$rounding>.)
Yeah, I alway thought that was a weakness of the core pod modules. 
Fortunately, it's easy to subclass them to do what you want. You'll want 
to subclass Pod::Text, override the proper method to add a new escape 
sequence (say $), then maybe override the constructor to 
take a hash with the values for the variables or possibly something more 
elaborate like evaling the variable name in the caller's context.

I've done similary on several occasions and it is fairly trivial. If you 
have trouble, I can probably dig up an example.

Randy.

Re: New module: CGI::Tooltip

[Randy W. Sims]

Becky Alcorn wrote:
The javascript library that we're using only works in browsers as far as we
know, and as far as our development goes we think of this kind of
functionality as a natural extension of what the CGI module does for us.
It seems that there is some overlap between the Javascript, HTML and CGI
namespaces.  The suggestions we have so far are:
CGI::Tooltip
HTML::Tooltip
Javascript::Tooltip::HTML
There is even a HTML::Widget and a HTML::Widgets namespace which might apply
also (although which would you use?).
I like HTML::Tooltip. That would be the first place I would look. It has 
nothing to do with CGI and Javascript is an implementation detail. 
HTML::Tooltip describes the module perfectly IMHO.

Randy.

Re: Duplicated modules

[Randy W. Sims]

A. Pagaltzis wrote:
* Randy W. Sims <[EMAIL PROTECTED]> [2004-05-14 01:40]:
It would be much nicer if it was readable as a nntp or at least
a mailing list; I've always found http-based discussion boardss
awkward to navigate and difficult to figure out what I have and
haven't read.  Wonder why this hasn't been done?

For NNTP, it has. One to run on your own[1] and one available
publically[2].
Oh, sweet; This is great! Thanks for the pointer. It would be nice if it 
had greater retention; maybe it could move to nntp.perl.org where there 
would be more space...

Thanks,
Randy.

Re: Duplicated modules

[Randy W. Sims]

On 5/13/2004 7:19 PM, IvorW wrote:

- Original Message - 
From: "Jose Alves de Castro" <[EMAIL PROTECTED]>
To: "IvorW" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: 13 May 2004 11:23
Subject: Re: Duplicated modules



Having said that, are we just reinventing Perlmonks?
That, I do not know... :-|


Ah, you do not know of the monastery. Check out http://perlmonks.org, 
which is a thriving on-line community and discussion forum, which is
completely searchable.

Perlmonks is not everybody's cup of tea (sorry, please excuse the UK idiom),
but everyone must admit that the site has an extensive linked set of
documentation, which includes numerous tutorials and FAQs which can be
used as reference, even when not actively participating in the site.
It would be much nicer if it was readable as a nntp or at least a 
mailing list; I've always found http-based discussion boardss awkward to 
navigate and difficult to figure out what I have and haven't read. 
Wonder why this hasn't been done?

Randy.

Re: Font::FNT

[Randy W. Sims]

Steffen Goeldner wrote:
Hi, I'm about to release the module

  Font::FNT

to load, manipulate and save Windows raster fonts (.FNT files).

Is this namespace ok?
Looks right to me.

Re: Module::Starter released

[Randy W. Sims]

Andy Lester wrote:
I've just released Module::Starter 0.02, meant as a replacement for h2xs.
I just reinstalled Debian on my laptop with the default perl (5.6.1). 
The following are the modules required and "requested" for 
Module::Starter and its dependents. Not complaining or making any 
judgement, just thought it interesting.

Archive-Tar-1.08
Devel-CoreStack-1.3
Devel-Symdump-2.03
ExtUtils-CBuilder-0.02
ExtUtils-ParseXS-2.08
Module-Build-0.24
Pod-Coverage-0.13
Pod-Escapes-1.03
Pod-Simple-2.05
Test-Builder-Tester-0.09
Test-Harness-2.40
Test-Pod-1.12
Test-Pod-Coverage-0.08
Test-Simple-0.47
YAML-0.35

Re: Module::Starter released

[Randy W. Sims]

Andy Lester wrote:
I've just released Module::Starter 0.02, meant as a replacement for h2xs.

I think h2xs is very out of date as far as current best practices for
modules.  It's also very intimidating for people who just want to create
a module, and have no need for all the compiler hoohah that h2xs throws
at you.  Module::Starter is meant to make things much eaiser.
Attached is a patch with preliminary support for Module::Build support. 
I added a 'builder' option for specifing whether to use M::B or 
MakeMaker; default is still MakeMaker. I also added a 'license' option 
as M::B likes to have it and the next version of MakeMaker will also 
support it (for META.yml) although it is not in the current snapshot.

One thing that may be desirable is to add options for Build.PL and 
Makefile.PL to co-exist, using one of Module::Build's compatability modes.

Another addition would be to allow module-starter to write a module for 
an already created project. For example, if you create a project 
'module-starter --module='Foo::Bar'', and later, you decide you need 
another module to add to the existing project. 'module-starter 
--module-only --module='Foo::Bar::Baz''.

Randy.
diff -urN Module-Starter-0.02-orig/Starter.pm Module-Starter-0.02/Starter.pm
--- Module-Starter-0.02-orig/Starter.pm Sun Apr  4 23:32:12 2004
+++ Module-Starter-0.02/Starter.pm  Mon Apr  5 19:44:32 2004
@@ -45,12 +45,15 @@
 
 =item * $email
 
+=item * $license
+
 =back
 
 =cut
 
 our $verbose = 0;
 our $force = 0;
+our $license = undef;
 our $author = "Module Author";
 our $email = "[EMAIL PROTECTED]";
 
@@ -63,6 +66,7 @@
 dir => $dirname,
 modules => [ module names ],
 distro => $distroname,
+builder => 'Module::Build', # Defaults to ExtUtils::MakeMaker
 
 =cut
 
@@ -78,6 +82,10 @@
 die "Must specify an author\n" unless $author;
 die "Must specify an email address\n" unless $email;
 
+unless ( defined($license) ) {
+warn "Defaulting to 'perl' license type\n";
+$license = 'perl';
+}
 
 my $distro = $args{distro};
 if ( not defined $distro ) {
@@ -93,7 +101,13 @@
 
 push @files, create_t( $basedir, @modules );
 push @files, create_cvsignore( $basedir, $distro );
-push @files, create_Makefile_PL( $basedir, $distro, $modules[0] );
+
+if ( $args{builder} eq 'Module::Build' ) {
+push @files, create_Build_PL( $basedir, $distro, $modules[0] );
+} else {
+push @files, create_Makefile_PL( $basedir, $distro, $modules[0] );
+}
+
 push @files, create_Changes( $basedir, $distro );
 push @files, "MANIFEST";
 push @files, 'META.yml # Will be created by "make dist"';
@@ -172,7 +186,7 @@
 my $module_file = File::Spec->catfile( @dirparts,  $filepart );
 
 open( my $fh, ">", $module_file ) or die "Can't create $module_file: $!\n";
-print $fh _module_guts( $module );
+print $fh &_module_guts( $module );
 close $fh;
 print "Created $module_file\n" if $verbose;
 
@@ -301,6 +315,49 @@
 print "Created $fname\n" if $verbose;
 
 return "Makefile.PL";
+}
+
+=head2 create_Build_PL( $basedir, $distro, $main_module )
+
+Creates a Build.PL for the given module distro.
+
+=cut
+
+sub create_Build_PL {
+my $basedir = shift;
+my $distro = shift;
+my $main_module = shift;
+
+my @parts = split( /::/, $main_module );
+my $pm = pop @parts;
+my $main_pm_file = File::Spec->catfile( "lib", @parts, "${pm}.pm" );
+
+my $fname = File::Spec->catfile( $basedir, "Build.PL" );
+open( my $fh, ">", $fname ) or die "Can't create $fname: $!\n";
+
+print $fh <<"HERE";
+use strict;
+use warnings;
+use Module::Build;
+
+my \$builder = Module::Build->new(
+module_name => '$main_module',
+license => '$license',
+dist_author => '$author <$email>',
+dist_version_from   => '$main_pm_file',
+requires => {
+'Test::More' => 0,
+},
+add_to_cleanup  => [ '$distro-*' ],
+);
+
+\$builder->create_build_script();
+HERE
+
+close $fh;
+print "Created $fname\n" if $verbose;
+
+return "Build.PL";
 }
 
 =head2 create_Changes( $basedir, $distro )
diff -urN Module-Starter-0.02-orig/bin/module-starter 
Module-Starter-0.02/bin/module-starter
--- Module-Starter-0.02-orig/bin/module-starter Sun Apr  4 23:17:02 2004
+++ Module-Starter-0.02/bin/module-starter  Mon Apr  5 19:41:07 2004
@@ -15,21 +15,29 @@
 my $distro;
 my $dir;
 
+my $builder = 'ExtUtils::MakeMaker';
+
 GetOptions(
 "distro=s" =>   \$distro,
 "module=s" =>   [EMAIL PROTECTED],
+"builder=s" =>  \$builder,
 
 "author=s" =>   \$Module::Starter::author,
 "email=s" =>\$Module::Starter::email,
+"license=s" =>  \$Module::Starter::license,
 force =>\$Module::Starter::force,
 verbose =>  \$Module::Starter::verbose,
 version =>  sub { print "module-starter v$Module::Starter::VERSION\n"; exit 
1; },
 help => sub { pod2usage(1); },
 ) or pod2usag

Re: Module::Starter released

[Randy W. Sims]

Andy Lester wrote:
I've just released Module::Starter 0.02, meant as a replacement for h2xs.
I just reinstalled Debian on my laptop with the default perl (5.6.1). 
The following are the modules required and "requested" for 
Module::Starter and its dependents. Not complaining or making any 
judgement, just thought it interesting.

Archive-Tar-1.08
Devel-CoreStack-1.3
Devel-Symdump-2.03
ExtUtils-CBuilder-0.02
ExtUtils-ParseXS-2.08
Module-Build-0.24
Pod-Coverage-0.13
Pod-Escapes-1.03
Pod-Simple-2.05
Test-Builder-Tester-0.09
Test-Harness-2.40
Test-Pod-1.12
Test-Pod-Coverage-0.08
Test-Simple-0.47
YAML-0.35

Re: NAME field

[Randy W. Sims]

Hans Oesterholt-Dijkema wrote:
Good point. Any suggestions?

With this module it's possible to have 1 Conf frontend using one
of the provided backends: String, File, SQL, INI for now, but
later probably Win32::Registry, maybe Wx::Config.
I wasn't really concerned about namespaces when I wrote this.
I like modules with short names.
Anyway It would be:

   Config
   Config::String
   Config::File
   Config::SQL
   Config::INI
   (...)

   Config::Win32::Registry
   Config::wxConfig
etc.
Sorry, Config is a core module (see perldoc Config). Look at other 
modules that do what you want:

Browse by catagory:

Browse by module name:

Search for keywords:

Those are just examples, you may find more with different search 
keywords, etc.

There are a lot of modules out there that handle config "files". 
Research what is available. If possible use or enhance an existing 
module. If you really believe you have a unique module, the above 
research will help suggest an appropriate name.

I'm not trying to discourage you, but there is already a lot of 
repitition and "junk" on CPAN. It's an authors responsibility to do the 
research before tossing another module on the heap.

My suggestion for a name (if you find that your module offers something 
unique) would be Config::, where  hints that it's 
a front end to multiple output formats, maybe Multi

Regards,
Randy.

Re: NAME field

[Randy W. Sims]

On 4/1/2004 5:25 AM, Hans Oesterholt-Dijkema wrote:

Dear All,

I'm just wondering. I've uploaded a few modules last days,
of which:
   Conf-0.06
   Conf-SQL-0.05
   Conf-INI-0.03
Why? There are already several namespaces where configuration type 
modules are located, primarily Config::*. Why do you feel the need to 
place your modules in a different namespace?

Randy.

Re: Reshaping the modules list: a starting point, help remove the bias.

[Randy W. Sims]

On 02/24/04 13:51, Smylers wrote:
Sam Vilain writes:


I've performed an initial re-work of the modules list.  Please look
over the sections of the list that you are most in touch with and
provide feedback.
After this stage, I'll try and fit the modules from the existing lists
and the Phalanx project into it one by one, and see how I get on.


Obviously this is a moving target; it won't be possible to change the
list once now and then stick to it forever more: as modules are written
the categories inevitably will have to adapt.  In general it's much
easier to see as new modules come along where to create (or split)
categories; that also prevents premature over-splitting, to make a
theoretical distinction between modules that are never written.
In other words, try going through your next step of taking the Phalanx
and existing list and putting the modules there into categories --
that'll show how well the categories work in practice much better than
people reading though it here will be able to do.
Presumably modules are allowed to be in multiple categories if they
happen to do something that pertains to them?  (If not the whole thing
is very likely to be doomed -- people will think differently about
classification, and indeed how to navigate the tree, and having to pick
only a single category will lead to many people not finding what they
were looking for.)
Related to this, are categories allowed to make multiple appearances?
This is the only sane way to deal with categories that have multiple
inheritence -- DMoz (Google Directory) does this with some kind of
'symbolic link', where among a particular's category's subcategories are
links to elsewhere in the tree.  For example some people might think of
web interfaces being under 'interfaces', so put a link there.
Again this helps reduce disputes, and avoids the fruitless search for
One True Hierarchy.

Networking - raw communication, including IPC:


You have 5 categories that all start "Networking -", which suggests they
collectively are really another level of hierarchy.

Networking - providing services:

  - Server and Daemon Utilities - Web Services Frameworks:
 - Apache:
 - OpenFrame
 - etc, submissions welcome :)
  - Web Services Components:
 - Lots of the Apache sections from above could be moved here
  - Authentication, Security and Encryption:
 - Authentication Systems
 - Encryption algorithm implementations
 - Security interfaces


It isn't clear to me exactly what these are (except for the 'Apache'
stuff), and where CGI-related modules would go, including the 'bigger'
run-an-entire site modules such as HTML::Mason, CGI::Application, and
the wiki things.
There are also many modules which exist to provide an interface to a
particular website (banks, URL-shortners, search engines).
Smylers


I haven't read all of the previous thread, but I would think a catagory 
scheme like SourceForge.net would be descriptive & flexible enough to 
provide a better long-term solution. To provide usefull information, the 
description tags don't neccessarily have to be hierarchical.

Regards,
Randy.

Re: pageranking perl modules

[Randy W. Sims]

On 02/20/04 01:22, David Manura wrote:
Since there has been some discussion recently on improving 
search.cpan.org search results, here's an initial attempt to apply the 
Google-inspired PageRank algorithm on Perl modules when interpreting 
module dependencies as links:

  http://www.math2.org/david/perlrank

The top rated modules are provided below:
[SNIP]

This seems like a good approach; I'd be interested in seeing more of this.

I think what would improve the relevency the most is a better data set.  
The CPAN data set was generated from the 'prereq' keys in the 
Module::CPANTS::asHash module, and this is only a rough representatation 
of the linking structure.  It would have been better to download all the 
CPAN modules and do source code analysis directly on them.
I use Randal Schwartz' minicpan script 
 to gather 
statistics about metadata, to list distributions with nested Makefiles, 
multiple XS files, etc. (ex. 
)

The only problem is that Randal's script sometimes grabs more than just 
the most recent version of some modules which can skew statistics somewhat.

Randy.

Re: Event::IO::Listener/Linear modules proposal

[Randy W. Sims]

On 1/3/2004 11:22 PM, David Robins wrote:
I have two modules that make use of the Event.pm module that would be more 
generally useful that I'd like to contribute to CPAN:

Event::IO::Linear - aggregates received data into 'lines'; handles timeouts; 
buffers writes.  Works with either Unix or Internet sockets (and presumably 
anything else based on IO::Socket).  I'm open for new names for this one as I 
realize 'linear' doesn't have a whole lot to do with lines in the perl sense 
:>.
Well, perl can read a file line by line where line is defined by the 
_record_ seperator. So maybe it should have 'Record' in the name?

Event::IO::Listener - simple server object that spawns new connections.

Code is at: http://davidrobins.net/code/EventIO.tar.gz (not in "CPAN 
distribution" format yet).

Re: Licenses for Perl Distributions As Displayed on search.cpan.org

[Randy W. Sims]

On 12/23/2003 8:21 PM, James E Keenan wrote:

I recently used the "Feedback" section on search.cpan.org to ask the 
following question:


I've noticed that the CPAN interface for modules now includes a
space for the module's "License" -- but that few modules have any
entry here (e.g., http://search.cpan.org/~jkeenan/List-Compare-
0.22/ http://search.cpan.org/~lds/CGI.pm-3.01/
http://search.cpan.org/~dconway/Parse-RecDescent-1.94/ ).
Is this because when we use h2xs to set up the skeleton of a
distribution, nothing special is done for License?
Or is it because MakeMaker doesn't yet do anything for special
for License in the way that it does for, say, YAML?
What should I do to get something that will show up in License?
Or should I not (yet) bother?


Graham Barr picked up my query and was kind of enough to respond 
quickly, as follows:


The license details are taken from the META.yml file. Both
MakeMaker, Module::Build and Module::Install can all generate
META.yml files. If they all support all fields, I do no know.
Graham.


Per consultation with people on this list, in my two CPAN distributions 
I have allowed MakeMaker (v6.16) to automatically generate the META.yml 
file, and I have not made any edits in that file once generated.  The 
file thus generated contains no License information and, if I understand 
Graham correctly, that means no License info is going to show up on the 
search.cpan.org main page for each distribution.

Is there anything I could do to generate the License info?  Perhaps more 
to the point, at this point in the development of META.yml, _should_ I 
do anything about this?  (I'm not losing any sleep over this.  It's just 
that I'm always puzzled when I see "License:  Unknown" on my distros' 
main pages, when I've included the standard language about "same terms 
as Perl itself" in the POD.)

jimk
The latest snapshot of MakeMaker does have support for a LICENSE 
parameter in your Makefile.PL. You could also set the NO_META flag in 
Makefile.PL and then manually edit the META.yml file (I dislike this 
option). Or, you can do the Right Think and make the switch to 
Module::Build :-)

Regards,
Randy.

Re: Simple multi-level tie

[Randy W. Sims]

On 12/18/2003 12:25 AM, Andrew Sterling Hanenkamp wrote:

"Wrapping hashes with arbitrary inflate/deflate methods."

This is a tool that adds syntactic sugar to hashes. I developed it for
the purpose of making complicated storage in hashes tied to DBM files
nicer. It doesn't matter if you use CGI::query_string, Storable,
join/split, pack/unpack, or even just use this to do some kind of wacky
filtering, this tool isn't a marshalling tool, it is a syntax helper.
What I want to know is, is Tie::HashWrapper a good name? If you don't
like that name, what might you call it? HashWrapper sounds kind of dorky
to me, but that's what first came to mind and I didn't want to spend all
day trying to name it, I wanted to play code monkey.
It's a horrible name. Sorry. :-)

The name needs to say what it is or what it's for, not how it's done. 
Some people hate the Tie namespace (I'm one of them), but it has become 
"standard" for tied modules. So:

Tie::MLDBM::Any_* (something)
 or
Tie::MLDBM::Custom_* (something)
where * says something about having custom marshalling methods. 
(Store|Marshall|Format|Dump|Load|Stow|...)

Regards,
Randy.

Re: BTRIEVE::*

[Randy W. Sims]

On 12/5/2003 1:05 PM, Tim Bunce wrote:

Are you volunteering?
Since I opened my big mouth, I guess I am. <:o

Now what exactly was I volunteering for again?

Tim.

On Thu, Dec 04, 2003 at 07:39:04PM -0500, Randy W. Sims wrote:

On 12/4/2003 3:50 PM, Tim Bunce wrote:


On Thu, Dec 04, 2003 at 11:42:07AM +0100, Steffen Goeldner wrote:


Randy W. Sims wrote:



Maybe DBMS::BTrieve::???
That looks good!


But that's a new namespace. The horse has well and truly bolted on
the db module namespace issue.  They're all over the place.
I think reusing an existing namespace is better than creating yet
another one.
I don't know (or can't remember) how the BTRIEVE::SAVE module got
into the module list, but since it is that's the right place for
new  BTrieve modules.
Tim.

I missed that namespace. In fact, browsing 
<http://www.cpan.org/modules/by-module/> I notice that things are 
/really/ getting out of hand. Maybe we need some CPAN police, volunteers 
for each of the domains listed at 
<http://www.cpan.org/modules/by-category/>, that must explicitly 
authorize new modules in that domain.

Then we can have a Great CPAN Migration effort to herd some of the 
strays into the proper namespace. If there was just an easy procedure 
for migrating packages without the compatibility concerns...

Randy.





--
A little learning is a dang'rous thing;
Drink deep, or taste not the Pierian spring;
There shallow draughts intoxicate the brain;
And drinking largely sobers us again.
- Alexander Pope

Re: BTRIEVE::*

[Randy W. Sims]

On 12/4/2003 3:50 PM, Tim Bunce wrote:

On Thu, Dec 04, 2003 at 11:42:07AM +0100, Steffen Goeldner wrote:

Randy W. Sims wrote:


Maybe DBMS::BTrieve::???
That looks good!


But that's a new namespace. The horse has well and truly bolted on
the db module namespace issue.  They're all over the place.
I think reusing an existing namespace is better than creating yet
another one.
I don't know (or can't remember) how the BTRIEVE::SAVE module got
into the module list, but since it is that's the right place for
new  BTrieve modules.
Tim.

I missed that namespace. In fact, browsing 
<http://www.cpan.org/modules/by-module/> I notice that things are 
/really/ getting out of hand. Maybe we need some CPAN police, volunteers 
for each of the domains listed at 
<http://www.cpan.org/modules/by-category/>, that must explicitly 
authorize new modules in that domain.

Then we can have a Great CPAN Migration effort to herd some of the 
strays into the proper namespace. If there was just an easy procedure 
for migrating packages without the compatibility concerns...

Randy.

Re: Fwd: How to put a path into a module during build time?

[Randy W. Sims]

On 12/4/2003 12:40 AM, [EMAIL PROTECTED] wrote:

Andrew Savige replied to me offlist with a good solution.
Taking a hint from lib/Net/Config.pm
my $file = __FILE__;
my $ref;
$file =~ s/Config.pm/libnet.cfg/;
That is definately a more elegant solution. I only have two problems 
with it:

1) I did not think of it. ;) I let myself get boxed in by the question. 
(Must think outside the box. Time for another read of "Conceptual 
Blockbusting" ).

2) The purpose of a Mailing List is NOT for people to post questions and 
get answers. The purpose of a Mailing List is for people to post 
questions and *everyone* to learn from the answers. --Andrew, please 
share with all of us next time. =)

Regards,
Randy.
Thank you all for your help!

This may be a good question to stick in a FAQ or some documentation
somewhere. This solution isn't specific to MakeMaker, and I can't say if
MakeMaker is the right place for this question, but the MakeMaker docs
were the first place I looked to find this answer, so who knows.
Thanks again,
--
Josh I.

Fwd: How to put a path into a module during build time?

[Randy W. Sims]

Forwarding to the MakeMaker ML because that seems a better place to get 
an answer. This suggests a more general question that might belong in 
the MakeMaker FAQ: What make variables are usefull to authors in 
Makefile.PL?

On 12/3/2003 11:26 PM, [EMAIL PROTECTED] wrote:

I've looked through my O'Reilly bookshelf, google'd, RTFM's, and I haven't
found the *right* way to do this, and I'm not even sure this is the right
place to be asking this. Anyway...
I have a perl module that needs to have access to a group of .png files
that ship with it. So, I made an /images directory under MyModuleName/
directory, and put them in there, and they get installed in the perl lib
directory just fine.
Now, my module needs to be able to find those, and use them, and I don't
know what the right way to do that is.
I've found a way to do it, but it seems like an ugly kludge to me. I put
the text "SRC_IMAGES" in my perl module where I needed to know the
directory the images where in, and added a PM_FILTER to the Makefile.PL
like this:
'PM_FILTER' => 'perl -pe "s!SRC_IMAGES!$(INSTALLSITELIB)/$(FULLEXT)!g"'
The module has a way to override this default directory, so my tests just
override the default directory with "MyModuleName/images" so that it uses
the images from the distribution directory during testing.
This will work as long as the module get's installed into
the $(INSTALLSITELIB) directory (which even works when you specify
PREFIX=/some/dir). But I can't imagine that this is the right way to do
something like this. I'm also concerned that it could get installed
somewhere else on some perl installations, but I don't know.
For those interested, the module is Authen::Captcha.

Any ideas?
--
Josh I.


--
A little learning is a dang'rous thing;
Drink deep, or taste not the Pierian spring;
There shallow draughts intoxicate the brain;
And drinking largely sobers us again.
- Alexander Pope

Re: when an object gets possessed by an evil spirit

[Randy W. Sims]

On 12/3/2003 8:27 PM, Stas Bekman wrote:

Randy W. Sims wrote:
I'm a C++ guy, so this kinda makes me think of auto_ptr<>'s and their 
reset method except that doesn't actually copy... actually this sounds 
more like a copy constructor; what about copy_construct() ??? 


Thanks, Randy.

I haven't done C++ for a long time, but if I remember correctly 
copy_construct() is invoked on the existing object and it doesn't modify 
the original, but returns a new object. Here the situation is different: 
Perl has already invoked its copy_constructor and gave you the resulting 
object, so all is left is to copy the C struct and modify the passed 
object's IV slot. So this is sort of a copy_construct on the guts of the 
object...

So it's more like a deepcopy_reconstructor()? Yea, I don't know a nice 
way to say that.

But then I like possess also since it has that connotation of 
something magic and scarry going on... better double check those docs 
before invoking a possession.

thesaurus says possess: bedevil, diabolize. ;)


let's call it scary_function() then ;)

% perldoc -f possess
  possess SPIRIT
  this function is NOOP before midnight, but after the midnight
  will make your code do scary things, altering the TIMTOWTDI to
  TIASWTDI (as in There Is A Scary Way To Do It). You must be at
  least 16 years old to use this function.
;)

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com



--
A little learning is a dang'rous thing;
Drink deep, or taste not the Pierian spring;
There shallow draughts intoxicate the brain;
And drinking largely sobers us again.
- Alexander Pope

Re: BTRIEVE::*

[Randy W. Sims]

On 12/3/2003 11:12 AM, Steffen Goeldner wrote:

Hi, I'm about to release two modules:

  BTRIEVE::XS
  BTRIEVE::API
The first, BTRIEVE::XS, is a simple XS wrapper module for
Btrieve's single function API. I.e., you can call Btrieve's
C function BTRCALL() in perl as BTRIEVE::XS::Call().
The second, BTRIEVE::API, provides methods for common
Btrieve operations (on top of BTRIEVE::XS):
I agree with Nicholas, about putting it in another namespace. Maybe 
DBMS::BTrieve::??? Also the names shouldn't really reflect the 
implementation, so XS is out. And every module has an API.

I don't see any reason why this all couldn't be in a single module (with 
an XS part and a perl part), and name it something like 
DBMS::BTrieve::Direct to indicate that it communicates directly with 
BTrieve and doesn't use DBD or ODBC, etc.

Regards,
Randy.

Re: when an object gets possessed by an evil spirit

[Randy W. Sims]

On 12/3/2003 3:06 PM, Stas Bekman wrote:
Obviously there is a solution to this problem. Enter the magic CLONE 
function called when a new thread is spawned (perl_clone is called). If 
a package defines this function, perl will call it. When CLONE is called 
Perl has already cloned $y. So what you need to do is to go and change 
$y's guts to point to a new C struct, initialized from the original C 
struct. But without changing $y, i.e. it's external appearance must not 
change. Only the IV slot needs to be changed. So here is where my 
question comes into the picture. How to call that method that will 
substitute the IV slot without changing the object. It's going to be 
used by many XS modules so we'd better choose a good name for it so we 
can all talk about the same method.

I chose the name 'possess' as if the object 'being possessed by some 
evil spirit'. Remember that the external object must stay the same 
(since it lives in the user's space, e.g. script and we can't touch it).

Liz wrote a module Thread::Bless which provides a framework for this 
issue, and she called this method 'fixup'.

Now that hopefully you understand the problem and what the method is 
trying to achieve, Liz and I are trying to get more ideas from you.
I'm a C++ guy, so this kinda makes me think of auto_ptr<>'s and their 
reset method except that doesn't actually copy... actually this sounds 
more like a copy constructor; what about copy_construct() ??? But then I 
 like possess also since it has that connotation of something magic and 
scarry going on... better double check those docs before invoking a 
possession.

thesaurus says possess: bedevil, diabolize. ;)

Regards,
Randy.

Re: ExtUtils::MakeMaker or Module::Build

[Randy W. Sims]

Orton, Yves wrote:
But as we start to put this together we run across 
Module::Build.  In

the past I have always used ExtUtils::MakaMaker.  Is there 
a preference

(if one were starting from scratch), to using one over the other?


Personally my feeling is that Module::Build isn't mature enough for release
ready code.
The fact that without manual intervention what it produces isnt compatible
with CPAN is IMO a serious argument against using it, and poses serious
questions in my mind about its suitability in 5.10.  Luckily it will be a
long time before 5.10 is released, so Ken has lots of time to get it right.
BTW, it shouldnt be seen that I am critical of Kens efforts, I actually
think his project is quite a good idea and will eventually be an excellent
replacement for older tools. But IMO it is not production worthy code at the
current time.
I dont know the logic behind using Build.pl instead of makefile.pl, but the
fact that it doesnt create the later by defualt (or so I have been told) is
in my eyes a serious mistake that will greatly reduce its overall uptake in
the market.  And for those people releasing code without a Makefile.pl, I
wonder at the point of putting such things on CPAN. (Others such as Randal
Schwartz have said the same thing)
Module::Build has a compatibility feature that does in fact produce a 
Makefile.PL file for distribution. In addition, you can have both a 
Build.PL and a MakeMaker Makefile.PL if you want to go that route.

Another serious issue with Module::Build is that for the last ages on Win32
it doesnt. Have a look at the transaction report of trying to install it
(using itself) from CPAN.  It doesnt play nicely with CPAN's prerequisite
system, (a Makefile.pl program would have caused CPAN to autoload these
prerequisites on my system by default) and fails build.
Module::Build has worked on Windows since version 0.16 (it also now 
works on Cygwin as of 0.21); I ported it. Unfortunately the latest 
release (0.21) had some Windows bugs that I didn't catch before it was 
released. Despite this last release, I have found it to be very stable.

There are nearly 200 distinct distributions on CPAN that now use 
Module::Build. And the number continues to inch upward. M::B is 
scheduled to appear in perl 5.10 and ultimately to replace MakeMaker, 
see perldelta. M::B doesn't require a make tool, so on 
platforms that do not include easy access to make, users can still build
and 

install pure perl modules.


I agree that the makeless make is a worthy objective, and Kens efforts are
to be applauded. But IMO currently its a bit of a waste that these modules
use it and are on CPAN. First off this means that they are unavailable to
Win32 users, a group that make up the majority of the Perl user base
(whatever the *nixens think). And for those that havent bothered including
Makefile.pl's and only Build.pl's, well that code wont install cleanly from
the cpan shell.
Anyway,
thats my take on using Module::Build.
Yves

I believe current releases of CPAN(PLUS)? do natively support Build.PL 
files, but I don't use either of them. (I prefer manual installs).

I'm not arguing; I just wanted to clarify a few points. ;) Module::Build 
is a long way from being complete, but I think it's further along than 
you think, and it's catching on relatively fast.

BTW, If you want to see who and what is using Build.PL, I generated a 
report a while back at 


Regards,
Randy.

Re: ExtUtils::MakeMaker or Module::Build

[Randy W. Sims]

On 11/19/2003 11:34 PM, Lincoln A. Baxter wrote:

Hi,

I and several others are starting to put together a collection of
modules.  The will be an architecture for implementing a
data/application integration server.  More on that later when we have a
more complete description we can post.
But as we start to put this together we run across Module::Build.  In
the past I have always used ExtUtils::MakaMaker.  Is there a preference
(if one were starting from scratch), to using one over the other?
Obiously h2xs assumes MakeMaker, but that does not mean I could not
at this relatively early point (at the beginning of putting it
together), switch to Module::Build or Module::Build::Compat.
Are there opinions either way? or a consensus on the future directions?
I don't want to start a religious war, I just way to hear some opinions,
and try to understand (beyond the arguments in Module::Build's pod)
which is currently preferred and why.
Lincoln

There are nearly 200 distinct distributions on CPAN that now use 
Module::Build. And the number continues to inch upward. M::B is 
scheduled to appear in perl 5.10 and ultimately to replace MakeMaker, 
see perldelta. M::B doesn't require a make tool, so on platforms that do 
not include easy access to make, users can still build and install pure 
perl modules.

M::B is still very young. There are some things it does not do well yet, 
and something it does not do at all, but Ken is doing a great job on it, 
and it is steadily moving forward.

BTW, I'm an M::B groupie. I hang out on the module-build mailing list, 
so I'm a bit biased.

Regards,
Randy.

Re: [Module::Build] (RFC) META.yml Specification Update

[Randy W. Sims]

And here it is in pod format.

=head1 NAME

Module::Build::META-spec - Specification for F

=head1 SYNOPSIS

 --- #YAML:1.0
 name: Module-Build
 version: 0.20
 license: perl
 distribution_type: module
 requires:
   Config: 0
   Cwd: 0
   Data::Dumper: 0
   ExtUtils::Install: 0
   File::Basename: 0
   File::Compare: 0
   File::Copy: 0
   File::Find: 0
   File::Path: 0
   File::Spec: 0
   IO::File: 0
   perl: 5.005_03
 recommends:
   Archive::Tar: 1.00
   ExtUtils::Install: 0.3
   ExtUtils::ParseXS: 2.02
   Pod::Text: 0
   YAML: 0.35
 build_requires:
   Test: 0
 generated_by: Module::Build version 0.20

=head1 DESCRIPTION

This document describes version 1.1 of the F specification.

The F file describes important properties of contributed
Perl distributions such as the ones found on CPAN.  It is typically
created by tools like Module::Build and ExtUtils::MakeMaker.

The fields in the F file are meant to be helpful for people
maintaining module collections (like CPAN), for people writing
installation tools (like CPAN.pm or CPANPLUS), or just for people who
want to know some stuff about a distribution before downloading it and
starting to install it.

=head1 FORMAT

F files are written in the YAML format (see
L).

See the following links to learn why we chose YAML instead of, say,
XML or Data::Dumper:

=over 4

=item *

Module::Build design plans

L

=item *

Not keen on YAML

L

=item *

META Concerns

L

=back

=head1 HEADER

The first line of a F file should be a valid YAML document
header like C<"--- #YAML:1.0">.

=head1 FIELDS

The rest of the F file is one big YAML mapping whose keys
are described here.

=head2 name

Example:

  name: Module-Build

The name of the distribution.  Often created by taking the "main
module" in the distribution and changing "::" to "-".  Sometimes it's
completely different, however, as in the case of the libww-perl
distribution (see L).

=head2 version

Example:

  version: 0.16

The version of the distribution to which the F file refers.

=head2 abstract

Example:

  abstract: Build and install Perl modules.

A short description of the purpose of the distribution.

=head2 license

Example:

  license: perl

The license under which this distribution may be used and
redistributed.  See L for the list of valid options.

=head2 distribution_type

Example:

  distribution_type: module

What kind of stuff is contained in this distribution.  Most things on
CPAN are Cs (which can also mean a collection of modules), but
some things are C