On 4/4/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
* demerphq [EMAIL PROTECTED] [2006-04-04 08:05]:
Personally i think the core is too big argument is a
red-herring given that bandwidth is as cheap as it is these
days. Adding a couple of modules to core would increase the
rsynch time by
Tels wrote:
On Tuesday 04 April 2006 01:35, Sébastien Aperghis-Tramoni wrote:
My current $work is to write a Perl program that must execute on about
1200 Linux servers, with Perl versions ranging from 5.004 to 5.8. I
can't upgrade Perl on these because they have different kernel / glibc
/ gcc
Ricardo SIGNES wrote:
Could you elaborate on this? As stated, it seems pretty ludicrous to me. It
reads like this:
[snip]
This can be further distilled to:
There's more than one way to do it, but most of them will get you dirty
looks.
I'd go further. I firmly believe that
demerphq wrote:
On 4/4/06, David Landgren [EMAIL PROTECTED] wrote:
I don't think bandwidth is the argument.
I was under the impression it was.
Believe it or not, there are programmers who still use modems. This is
usually because they live in the third world, such as Pennsylvania or
David Cantrell writes:
rsnapshot (for example) has its own code for traversing a directory
tree, its own cut-down Memoize, and probably a few others that I've
not found yet.
That said, I don't want to see those things go into the core, because
I'm in the the core is too big already camp.
On Tue, Apr 04, 2006 at 11:27:07AM +0200, Sébastien Aperghis-Tramoni wrote:
I don't think that the problem of core is too big is a matter of disk
size, but more a matter of number of modules. P5Porters time is a scarce
ressource, and they already lack the time to do all the work they'd
like
On Wed, 5 Apr 2006 14:20:15 +0100, Nicholas Clark [EMAIL PROTECTED] wrote:
On Tue, Apr 04, 2006 at 11:27:07AM +0200, Sébastien Aperghis-Tramoni wrote:
I don't think that the problem of core is too big is a matter of disk
size, but more a matter of number of modules. P5Porters time is a
* H.Merijn Brand [EMAIL PROTECTED] [2006-04-05T02:39:20]
I'll just mention two things, both very different
A. CORE modules are tested on all supported architectures, while CPAN modules
do not give that guarantee. The smoke system still causes all possible
combinations to be tested on
Smylers wrote:
David Cantrell writes:
rsnapshot (for example) has its own code for traversing a directory
tree, its own cut-down Memoize, and probably a few others that I've
not found yet.
That said, I don't want to see those things go into the core, because
I'm in the the core is too big
Smylers wrote:
David Cantrell writes:
rsnapshot (for example) has its own code for traversing a directory
tree, its own cut-down Memoize, and probably a few others that I've
not found yet.
That said, I don't want to see those things go into the core, because
I'm in the the core is too big
On 4/5/06, Ricardo SIGNES [EMAIL PROTECTED] wrote:
That said, I don't dispute the point that it can be wildly obnoxious when
Something::Trivial requires DBD::MySQL and Data::Dump::Streamer when it
could
use neither -- or at least rely on AnyDBM and Data::Dumper. It will just
meant
that
On Apr 5, 2006, at 9:06 AM, David Landgren wrote:
perl -MModule::CoreList -le 'print Module::CoreList-first_release
($_) for @ARGV' File::Find Memoize
5
5.007003
(um, that can no doubt be golfed, but you get the picture).
Yes, it can:
% corelist File::Find Memoize
File::Find was first
On Wednesday 05 April 2006 02:02, Adam Kennedy wrote:
But it's also why UNIVERSAL::isa/can and people adding higher-version
dependencies below their existing lower-dependency modules is bad.
The code used to work just fine, and now it doesn't.
This is a strange definition of work just fine,
* demerphq [EMAIL PROTECTED] [2006-04-05T10:23:45]
On 4/5/06, Ricardo SIGNES [EMAIL PROTECTED] wrote:
That said, I don't dispute the point that it can be wildly obnoxious when
Something::Trivial requires DBD::MySQL and Data::Dump::Streamer when it
could use neither -- or at least rely on
Moin,
On Wednesday 05 April 2006 06:43, Adam Kennedy wrote:
Ricardo SIGNES wrote:
* H.Merijn Brand [EMAIL PROTECTED] [2006-04-04T10:40:39]
[sniplots]
But there's very little point in using Exporter::Lite because 100 other
modules use Exporter in any given program.
So even though
Moin,
On Wednesday 05 April 2006 06:57, Adam Kennedy wrote:
chromatic wrote:
On Tuesday 04 April 2006 10:32, Tels wrote:
There is also the point that supporting ancient Perls means you
can't use all the new, wonderfull features that were added to later
versions of Perl, like our, warnings
chromatic wrote:
On Wednesday 05 April 2006 02:02, Adam Kennedy wrote:
But it's also why UNIVERSAL::isa/can and people adding higher-version
dependencies below their existing lower-dependency modules is bad.
The code used to work just fine, and now it doesn't.
This is a strange definition
Moin,
On Wednesday 05 April 2006 20:46, H.Merijn Brand wrote:
On Wed, 5 Apr 2006 18:30:33 +0200, Tels [EMAIL PROTECTED]
wrote:
Moin,
On Wednesday 05 April 2006 06:57, Adam Kennedy wrote:
chromatic wrote:
On Tuesday 04 April 2006 10:32, Tels wrote:
[snip]
I'm trying to figure
demerphq wrote:
On 4/4/06, Adam Kennedy [EMAIL PROTECTED] wrote:
Module::Build wants to go in, but because they use YAML for the data
file, we add Ingy's YAML.pm, who then decides he wants to use Test::Base
for everything he does, so that slips in undernearth, and of course
Test::Base is based
H.Merijn Brand wrote:
demerphq wrote:
Also, there is a tension in the community relating to this issue that
i dont think we will see any resolution of soon.
Many module authors set a design objective of making their modules
dependent only on core modules. This is a comment that I see on a
20 matches
Mail list logo
