That is very true. That is why I'd volunteer to patch the major
modules in a backwards-compatible way.
Incidentally, this is also being commented on here:
http://use.perl.org/~jonswar/journal/34366
and the name Log::Abstract was suggested, which I like a lot more, so
I'm leaning towards
meanings, so I think that could be confusing. I
think Log::Any is better.
On 9/7/07, Jonathan Swartz <[EMAIL PROTECTED]> wrote:
That is very true. That is why I'd volunteer to patch the major
modules in a backwards-compatible way.
Incidentally, this is also being commented on here:
> Looks good to me, although I'm not sure how you're going to go from a string
> argument to Log::Any::import() to creating a lexical in the calling packing
> and then snagging a reference to it. Evil PAD manipulation? Source
> filters? Or will you simply use a package global instead? (That'd
> And I'd certainly be miffed if I wanted to pick up a module and
> found it forced me to use Log::Dispatch when the rest of my app
> is already using Log4perl.
Right. It isn't so much about convincing module owners, as Leon
suggested; it's dealing with all the existing applications out there
that
At various places around our system we want to clean up files older
than x, and sometimes prune empty directories. Naturally we have to be
careful doing this lest we accidentally blow away far too many of the
wrong files.
I'm thinking about a Perl module and accompanying script with this
an up old files and prune empty
directories
File::Find can be used to write such a script, but doesn't by itself
address this issue.
On Tue, Jun 30, 2009 at 6:15 PM, Dana Hudes wrote:
File::Find::Perl
--Original Message--
From: Jonathan Swartz
To: module-authors@perl.org
Sent:
erry® smartphone with Nextel Direct Connect
From: Jonathan Swartz
Date: Wed, 1 Jul 2009 22:13:20 -0700
To:
Subject: Re: module/script to clean up old files and prune empty
directories
My points about "find ... | xargs rm -f" apply as well to a simple
File::Find. Namely, it doesn&#x
Is there still a point to registering module namespaces on PAUSE?
The form (https://pause.perl.org/pause/authenquery?ACTION=apply_mod)
is still active, but it says that registering is for "maintaining the
Modules List" which has not been maintained for several years.
I've seen the small dis
On Aug 17, 2009, at 8:02 AM, Ricardo Signes wrote:
* Jonathan Swartz [2009-08-17T10:48:24]
Is there still a point to registering module namespaces on PAUSE?
In my opinion, no.
The only benefit to the list is that first-time authors think it's
important,
so they talk to the admins
"--alldeps"
@INC:
/usr/local/lib/perl5/5.8.8/i686-linux
/usr/local/lib/perl5/5.8.8
/usr/local/lib/perl5/site_perl/5.8.8/i686-linux
/usr/local/lib/perl5/site_perl/5.8.8
/usr/local/lib/perl5/site_perl
.
-
use inc::Module::Install;
name
What's a good policy for setting $VERSION in the non-"main" modules of
a distribution?
e.g. I've got Server-Control-0.08, and Server::Control contains
our $VERSION = '0.08';
but none of the other modules in the distribution (e.g.
Server::Control::Apache) contain a $VERSION. I can see at
On Sep 30, 2009, at 7:44 PM, James E Keenan wrote:
Jonathan Swartz wrote:
I'm having a strange first-time problem building my new Server-
Control distribution from CPAN on Fedora.
To reproduce this, I first run this reset script to remove Server-
Control from my .cpan and system:
On Dec 3, 2009, at 1:42 AM, Jonathan Rockway wrote:
> Catalyst is the standard Perl web framework [1], and is neither non-
perl nor
> has "very strict security". It also runs on Windows (Strawberry or
> ActiveState), and does not require Apache. (Apache still exists!?)
[2]
Ah, the arrogan
I'm getting tired of writing chains like
use Cwd qw(realpath);
use File::Basename;
use File::Path;
use File::Slurp;
use File::Spec::Functions;
use File::Temp;
whenever I write a script that deals with files. Especially since my
cycle is "run script, insert missing use line, run script, insert
I'm thinking about a module/script to unify a bunch of code tidiers and
validators in a single place. With a single command, e.g.
% tidyall
you could apply the appropriate tidiers and validators to files in your project
(e.g. your git directory hierarchy). It would tidy each file as needed a
Yeah, Any::Tidy seemed to suggest to me "use the best of available tidiers".
I'm leaning now towards Devel::TidyAll, with tidyall being the name of the
script.
On Apr 30, 2012, at 11:17 AM, David Nicol wrote:
> On Sun, Apr 29, 2012 at 7:56 AM, Jonathan Swartz wrot
16 matches
Mail list logo
