Anyway, i just wanted to add this because I dont think that you can
take it for granted that all perl5porters believe the core module set
should be as restricted as possible. I dont. I believe that the core
should contain out of the box enough support for the various platforms
that perl runs on th
On 4/4/06, Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> wrote:
> (*) Yes, I know that the core Perl distribution includes many modules,
> but ask any P5Porter and he'll answer you that the core is over-crowed
> and that all core modules that can be made dual-life should be released
> on the CPAN.
On 4/4/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> wrote:
> > >OTOH, who still runs pre-5.8.x code deserves what they get.
> > >
> > >There are horrible bugs in older Perls, and I don't know why people
> > >still
> > >insist using insecure, buggy
Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> wrote:
> >OTOH, who still runs pre-5.8.x code deserves what they get.
> >
> >There are horrible bugs in older Perls, and I don't know why people
> >still
> >insist using insecure, buggy and feature-lacking code like 5.6. or even
> >gasp 5.004. Just th
Tels wrote:
Moin,
Hello Tels,
OTOH, who still runs pre-5.8.x code deserves what they get.
There are horrible bugs in older Perls, and I don't know why people
still
insist using insecure, buggy and feature-lacking code like 5.6. or even
gasp 5.004. Just think "Unicode support", "hash rando
Yitzchak Scott-Thoennes wrote:
I remember working with some module that had tests something like:
use Test::More;
plan tests => numtests();
...
is($foo, $bar, 'foo is bar');
sub numtests { 13 }
So that when you added a new test to the bottom, the number to modify
was right there a
Yitzchak Scott-Thoennes wrote:
I remember working with some module that had tests something like:
use Test::More;
plan tests => numtests();
...
is($foo, $bar, 'foo is bar');
sub numtests { 13 }
So that when you added a new test to the bottom, the number to modify
was right there a
I know, now people will come out of the wood and say that they have that
old system, and no, they can't upgrade Perl etc, never touch a running
system etc yadda yadda. But what the heck do you then try to upgrade
modules on said system when you didn't want to "touch the system"?
To quote pos
Moin,
On Sunday 02 April 2006 16:37, Sébastien Aperghis-Tramoni wrote:
> Adam Kennedy wrote:
[snip]
> This is a little harder with Module::Build as it has a few dependencies
> that ask 5.005 or 5.6, although in some cases incorrectly. I send
> patches so modules like File::Temp or ExtUtils::Consta
Yitzchak Scott-Thoennes wrote:
On Sat, Mar 11, 2006 at 10:20:29AM +0100, Tels wrote:
B when it breaks, end-users cannot fix the problem for themselves, they
need to bug the author and he has to release a new version. (Good luck
with that with sparsely maintained modules...)
Last time this hap
I remember working with some module that had tests something like:
use Test::More;
plan tests => numtests();
...
is($foo, $bar, 'foo is bar');
sub numtests { 13 }
So that when you added a new test to the bottom, the number to modify
was right there also. Ring a bell with anyone?
On Sat, Mar 11, 2006 at 10:20:29AM +0100, Tels wrote:
> B when it breaks, end-users cannot fix the problem for themselves, they
> need to bug the author and he has to release a new version. (Good luck
> with that with sparsely maintained modules...)
Last time this happened to me, I just replaced
Luke Closs <[EMAIL PROTECTED]> writes:
> On Sat, Apr 01, 2006 at 04:04:42PM -0800, Jeffrey Thalhammer wrote:
> What makes pairing good is the increased attention to code as it
> comes out. The pair discusses the implementation, which not only
> finds lots of simple bugs very early, it also:
>
> -
13 matches
Mail list logo