Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
Greetings, On Mon, Jun 20, 2005 at 11:06:49AM +0100, Orton, Yves wrote: -) Structured access to the option settings -) Option to pass in something other @ARGV to the arg-processing code. Id be curious what you mean by the first, I mean the ability to query Getopt::Long, either by an object method in OO mode or through functions, for a list of recognized options their types (e.g., whether int, bool, string or no arg; their linkage, etc.) and Im confused why the obvious solution to the second is not good enough. local @[EMAIL PROTECTED]; Goes a long way you know. It does, and it works, and it is a stylistic thing perhaps, but although global variables can be made to work, the modern phenomenon of function arguments are very popular. Mx.
Re: RFC: Getopt::Modern
On Sat, Jun 18, 2005 at 10:44:21AM +0200, Johan Vromans wrote: The problem that I see is legacy. Many users expect the left-to-right behaviour, and will get confused if some tools act differently. I don't think that's merely legacy; the majority of those on this list who have expressed a preference have said they prefer it that way. Mx.
Class::MethodMaker wrong version listed on CPAN
Hi, Users who try to install Class::MethodMaker via CPAN get 1.12 by default, even though 2.00 (and 2.02...) have been out for some time. I cannot see why this is: if anybody has an idea, I'd be much obliged to know how I can fix this. Cheers, Mx.
Re: pageranking perl modules
On Fri, Feb 20, 2004 at 01:22:56AM -0500, 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: David, This is a splendid thing: thank you very much. A third ranking that I would consider very interesting, and I guess others too, would be a CPAN top 10 with any modules in the current stable perl (5.8.2?) exlcuded: So File::Spec, Data::Dumper, Storable I think, Test::Harness removed. Mx.
Re: [Class::MultiList] Need feedback for first distribution
Hello Ruslan, On Wed, Jan 21, 2004 at 01:59:35PM +0300, Ruslan U. Zakirov wrote: I realy realy sorry, I've forgot to attach file :( Was tired a lot. A quick glance over prompts my first question: what does this module provide that other Class generating modules, e.g., Class::MethodMaker, Class::MakeMethods, Class::Struct, do not? Mx.
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
On Mon, Jan 19, 2004 at 11:03:05AM -0600, Chris Josephes wrote: Why would that be? I mean, the odds are if you're dealing with a non-core Perl module, you're going to need to know the name if you want to download it in the first place. If you use a module long enough, you'll get used to how it's called. It's not those I use every day that are the issue; it's those I use bi-monthly. I can easily remember to look up Net::FTP for an ftp client, but com::bluesville::smegma:algenon::net::ftp? It'd take me three goes to type it right even if i could remember the name. Mx.
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
On Mon, Jan 19, 2004 at 11:05:31AM -0600, Chris Josephes wrote: Version numbering is an authorship issue. If I took over module Widget from author XYZ, I'd probably use higher version numbers than author X used to signify a newer release. To be sure, I'd also include POD documentation identifying my version of Widget to be a replacement for the version from author XYZ. If I'm looking for a module to do a job, I use search.cpan, and check by name; then, for likely candidates, I check out the README. I don't have time to read the POD too; I've got a job to do. Version numbering works great for linear systems, which generally occur only with single authorship. If you do your own version of Term::ProgressBar, and call it 3.00, and someone else does too, they will probably call it... 3.00. Boom! Mx.
Re: Possible module for 'safer' signal handling....
On Sun, Jan 11, 2004 at 10:15:20PM -0500, Lincoln A. Baxter wrote: On dbi-users... I responded to Tim Bunce's most helpful suggestions as follows... He suggested Sys::SigAction as name. Since the module is all about wrapping up system (POSIX) sigaction() calls, I like it! Lincoln, A slow reply to the thread in general: yes please. This module would be very handy, coding up an esoteric distinction between 5.8 5.6 that would take me at least the nine months you took to find, and probably more. This module wpould be a splendid thing. All power to your coding elbow. Mx.
Re: Version Numbers
On Thu, Jan 08, 2004 at 07:46:04PM -0800, David Wheeler wrote: Hi All, What's the consensus on the version numbers to give to different modules in a CPAN distribution? I've traditionally only incremented the main module in a distribution and any modules that have been changed since the last release. But this means that I have modules in a single distribution with different version numbers. Other CPAN authors have omitted version numbers from all but the module that names the distribution. Still others have made all of the modules in a single distribution have the same version number. So, what do people like or prefer, and why? Is there a consensus on this? If so, what is it? I can't comment on consensus, but I think that for clients of the module, what they really want to know is the module number as found on CPAN. Even if inidividual files have not changed, as they're part of one package, they likely interoperate and so their behaviour will change anyway. To achieve this, I export $VERSION from the main module (the one named in Makefile.PL to retrieve the version from), and import it in the remaining modules. It'll break if the module is installed by hand in parts, but then I figure that if you do that, you're on your own anyway. For the rest of the time, it works nicely to ensure that I don't get caught out by forgetting to update the numbers in individual files. Mx.
Re: Simple multi-level tie
On Tue, Jan 06, 2004 at 01:00:36PM -0600, david nicol wrote: that works too. The first time I worked with dbm files, it was with an implementation that produced both a .pag and a .dir file for a database, so there was no one data file to lock. If I just use Copendbm and let Perl select an implementation, I don't know what the file name is going to be. It could be foo, it could be foo.db, it could be both foo.dir and foo.pag. So if I use foo.advisory_lock for the advisotyr lock, I'm safe regardless of implementation. I'm also safe from the implementation needing the flock bits if it uses them. I don't know that they do, but I also don't know that they don't. Also what would happen if you got your lockfile open syntax wrong and accidentally clobbered your data? So I consider using a separate advisory file a best practice. I have never done a performance comparison, but owuld be curious to see one. A splendid explanation. Thanks for that. Consider me convinced :-) Mx.
Re: How to indicate a dependency in my module
On Mon, Nov 10, 2003 at 03:49:54PM -0500, Randy W. Sims wrote:
It would be nice to see functionality like this incorporated into a
Module::Build::Configure package (or similar) along with other configure
type routines common in current Makefile.PLs. Routines that find if libs
or executables are installed, find appropriate install paths for
installing perl programs that don't belong in the perl tree, etc.
If anyone cares, I have an ExtUtils::MakeMaker wrapper (a single module that's
distributed but not installed with any package) that:
-) If a module is missing, tells you what package to find it in (it's not
always obvious to find, say, Net::FTP in libnet before you're familiar with
libnet)
-) Handles optional modules, i.e., if it's missing, doesn't die, but does
issue a message to the user.
-) Can check for executables, too, with versions (by telling it how to look up
version numbers for that module).
I've attached it for your edification. Constructive criticisms welcome.
Mx.# (X)Emacs mode: -*- cperl -*-
use 5.005;
use strict;
=head1 NAME
make - tools for making makefiles with.
=head1 SYNOPSIS
use constant MOD_REQS =
[
{ name= 'Pod::Usage',
version = '1.12', },
{ name= 'IPC::Run',
package = 'IPC-Run',
version = '0.44', },
{ name = 'DBI::Wrap',
package = 'DBI-Wrap',
version = '1.00',
optional = 1, },
];
use constant EXEC_REQS =
[
{ name= 'blastpgp',
version = '1.50',
vopt= '--version', },
{ name= 'mkprofile', },
{ name= 'mp3id',
version = '0.4',
vopt= '--help',
vexpect = 255, },
];
use constant NAME = 'Module-Name';
use constant VERSION_FROM = catfile (qw( lib Module Name.pm ));
use constant AUTHOR = 'Martyn J. Pearce [EMAIL PROTECTED]';
use constant ABSTRACT = 'This module makes chocolate biscuits';
use make.pm
=head1 DESCRIPTION
This package provides methods and initialization to build standard perl
modules.
The plan is, you define the requirements, and let the module take care of the
rest.
The requirements you must define are:
=over 4
=item MOD_REQS
An arrayref of hashrefs. Each hashref represents a required Perl module, and
has the following keys:
=over 4
=item name
BMandatory Name of the module used. The presence of this module is checked,
and an exception is raised if it does not exist.
=item package
BOptional Name of the package in which the module is to be found. If not
defined, the package is assumed to be present in core Perl.
Modules that have been in core Perl since 5.005 need not be listed; the core
perl default is for modules such as CPod::Usage which have been added to
the core since 5.005.
=item version
BOptional If supplied, the version of the module is checked against this
number, and an exception raised if the version found is lower than that
requested.
=item optional
BOptional If true, then failure to locate the package (or a suitable
version) is not an error, but will generate a warning message.
=item message
If supplied, then this message will be given to the user in case of failure.
=back
=item EXEC_REQS
=over 4
=item name
Name of the executable used. The presence of this executable is checked, and
an exception is raised if it does not exist (in the PATH).
=item package
BOptional Name of the package in which the executable is to be found.
=item version
BOptional If supplied, the version of the module is checked against this
number, and an exception raised if the version found is lower than that
requested.
If supplied, the Lvopt key must also be supplied.
=item vopt
BOptional This is used only if the Cversion key is also used. This is the
option that is passed to the executable to ask for its version number. It may
be the empty string if no option is used (but must be defined if Cversion is
defined).
=item vexpect
BOptional This is used only if the Cversion key is also used. This is the
exit code to expect from the program when polling for its version number.
Defaults to 0. This is the exit code (value of C$? in the shell) to use,
Inot the value of the Cwait call.
=item optional
BOptional If true, then failure to locate the package (or a suitable
version) is not an error, but will generate a warning message.
=item message
If supplied, then this message will be given to the user in case of failure.
=back
=item NAME
The module name. It must conform to the established standard; in particular,
it must Bnot contain colon characters. The usual process, when providing a
single-package module (e.g., to provide CMIME::Base64), is to replace the
C:: occurences with hyphens (hence, CMIME-Base64).
=item VERSION_FROM
The module from which to establish the version number. This module must have
a line of the form C$VERSION = '0.01';. Declarative prefixes (.e.g, Cour)
are fine; Cour is the usual one, since C$VERSION
Re: Another sticky module naming issue
On Wed, Aug 20, 2003 at 09:59:43PM +0100, Sam Vilain wrote: Hi all, Any ideas for a better name for this module? NAME Defer - Defer execution of code until it is accessed DESCRIPTION This module implements `magic variables' that are only calculated when they are accessed. This can be extremely useful for defering things like connecting to a database, or performing computationally expensive operations. This seems on first inspection to be a form of Memoize, but providing access via variables (presumably tied, and therefore less efficient) than via functions. Memoize is part of the Perl core as of 5.8.0 . Have I missed something? Mx.
Re: Filesys::DiskFree
On Tue, Jun 03, 2003 at 04:18:05PM -0700, William R Ward wrote: We use Filesys::Df and it works great on both Solaris Linux. What problems have you had with it? Simply that it doesn't compile on FreeBSD. But you're right, it seems to work a treat on Linux (our Solaris boxes are currently borked); so I'll estimate what's needed to port to FreeBSD, and if that's feasible (and the maintainer amenable), I'll look to use that instead. Cheers for the pointer! Mx.
Filesys::DiskFree
Fellow Module Authors, I've looked through the available disk-free modules, for an OS-neutral one (at least, Solaris, Linux FreeBSD to start...), and been disappointed with the outcome. Filesys::DiskFree seems closest to my needs (not least, it compiles), but doesn't work on modern Solaris with unhelpful df output. I sent a patch to the listed address for ABarclay, but have had no response. I would like to apply to take over maintenance of this module. To whom do I send the relevant mail / what form do I fill in to achieve this? If I'm missing an appproriate module for doing this with, please let me know. Mx.
Re: Filesys::DiskFree
Greetings Mark, On Fri, May 30, 2003 at 10:25:52AM -0500, Mark Stosberg wrote: Martyn, For starters, there's this: http://www.cpan.org/misc/cpan-faq.html#How_maintain_module Thanks for the pointer --- that's dead handy. FTR, I attempted to contact Alan over 3 months ago by email and have had no reply. This document doesn't answer the question ...if all else fails, then what?. That is, I'm still unclear how namespace authority is transferred, or if it is enforced at all. This is true :-( . I'm sure that someone out there knows, and we can perhaps get this added; although it's probably not *that* frequently asked... Mx.
Re: Filesys::DiskFree
On Fri, May 30, 2003 at 08:39:26AM -0800, Arthur Corliss wrote: Speaking of disk space modules, etc., I've been thinking of trying to find a place to put some os-independent code that accomplishes much the same thing, but includes LVM data (like unallocated blocks assigned to a volume group, member logical drives, logical drive to physical drive(s) maps, etc.). I've already written all of this for AIX (4.3.3/5L), and will be adding IRIX (XVM) support soon. My first impression is that this would go under Parse::LVM since it parses the output of standard system commands. Should there instead be a Filesys::LVM::* or LVM::* tree for this kind of functionality? I would certainly look for that kind of thing in Filesys:: . I fear it would get lost in LVM (and the acronym doesn't mean much without the Filesys:: context), and though it may choose to receive its information by parsing a command, that's implementation --- not purpose. Filesys::LVM sounds splendid to me. And please do upload it --- this sounds like a very good module to have around! Mx.
Re: RFC - vCard and vCalendar - parse generate
On Fri, Jan 03, 2003 at 10:49:15AM -0500, Jay Lawrence wrote: I have the basics of a v* file parser/generator underway. This stemmed from my initial need to parse vCard files (because Apple's Address Book can't print and I needed my xmas card labels! *** ) and ultimately vCalendar files. These modules will also be able to write v(Calendar|Card|\w+) files back out as the need/demand arises. I am aware of Net::ICal which works with [iv]Calendar files - however given its dependance on other modules (Class::MakeMethods or MethodMaker?) and a few other reasons I have elected not to use it. Jay, This is something that seems good to me. However, I'm somewhat perturbed at your mention of reliance on a another module as a reason against using something. I'm biased; I'm the maintainer of Class::MethodMaker. However, given that you're promoting code reuse by offering your module(s) uo to CPAN, why simultaneously denigrate it by implicitly speaking against the use of other modules? Mx.
Re: New module; Exec-RSE?
On Sat, Nov 30, 2002 at 04:22:11PM +1100, Ken Williams wrote: I suggest something like GetOpt::Unified or GetOpt::Common or something. But don't take a really good namespace unless you plan on maintaining it. ;-) Fair point :-) I warm to Getopt::StdResource, and Getopt::Plus. Any votes out there? Mx.
New module; Exec-RSE?
Dear module authors, I hgave a new module to upload, but am more than a little unsire about the appropriate name. The module is a set of Resources for Standard Executables. It's a bit like GetOptions on steroids; indeed, it is a large user of Getopt::Long, Pod::Usage, and Log::Info. It provides a way for executables to quickly and easily set up option handling, with a number of standard options, which also provide self-documentation (e.g., --help, --man options), and options for controlling the output (via Log::Info). The Getopt::Long is configured, and the calling sequence for arguments is controlled in one place. In this way, all executables using this module perform in a standard way, documentation (e.g. for options) is kept in one place (I was frustated duplicating it), description for general option-handling semantics is kept in one place, etc. This module is not mere theory; it has been used extensively successfully at my place of work for some time now. So, as a starting strawman, I propose Exec::, since it is for executables, RSE, as in Resources for Standard Executables. Hence, Exec-RSE. Does anybody have a better suggestion? Mx.
Re: OO and procedural Interface
On Fri, Oct 04, 2002 at 06:21:00AM +, David Cumming wrote: Is there a standard approach to making a module support both 00 and procedural interfaces? Any ideas? I just want to create $self if there isn't one. $self should inherit all the default properties made by new. There are two standard approaches: (1) don't, and (2) give them different names. The CGI module is an awkward case because of the long legacy of backwards-compatibility. Any attempt at dwimmery in this case will likely cause pain suffering. Consider, if you will, any method whose arguments are other instances of the same class (e.g., copy_from). Then, auto-detecting OO mode vs. procedural becomes a lot more involved. Typically, attempts at this lead to clients becoming confused by accidentally invoking OO mode when they meant procedural, or vice-versa. Consider, perhaps, writing one package, either procedural or OO, and a second which is a wrapper around the first implementing the other paradigm. Mx.
Re: repost: RFC: CPAN::Grab
On Thu, Mar 21, 2002 at 01:16:10AM -0500, Ilya Zakharevich wrote: 1) The PREREQ_PM facility informs the user of missing modules, but not where to find them. Not every module (in the Perl sense) comes in a module (in the CPAN sense) of the same name. Why should it? PREREQ_PM specifies Distribution depends on PM-files PAUSE indexer specifies PM-file is contained in a distribution CPAN.pm uses both pieces of info to do what it should. What I am missing? a) That not all modules exist on CPAN. (some are specific to a company, some on sourceforge or similar). b) That some package names may exist in multiple modules. c) That whilst Perl supports CPAN, it's not mandatory (nor should it be). We should, however, support those who won't/can't use it. 2) There is no handling of required executables. Is not a problem as far as the executable comes with a (dummy?) module. Not all modules are written in perl. I have a module that uses the par command, for example. Mx.
Re: repost: RFC: CPAN::Grab
On Fri, Mar 08, 2002 at 09:41:29AM -0500, Jay Lawrence wrote: From: Sam Vilain [EMAIL PROTECTED] You can specify package dependancies with MakeMaker, including version numbers of required packages. Surely that is enough information to build up necessary depends: relationships? The *only* beef I have about PREREQ_PM is that it usees the prereq modules to see if they are there are installed. This unfortunately does not work in certain situations, I have two issues: 1) The PREREQ_PM facility informs the user of missing modules, but not where to find them. Not every module (in the Perl sense) comes in a module (in the CPAN sense) of the same name. 2) There is no handling of required executables. Mx.
