Moin,
On Friday 07 April 2006 02:55, Adam Kennedy wrote:
> > I use 5.8.0 as minimum, but for unicode I think it should be 5.8.1 -
> > but I am unsure. COuld you give a reason for why specifically 5.8.3?
>
> Actually, in consultation with Audrey and other $experts,
> Perl::MinimumVersion applies a
On Thursday 06 April 2006 17:53, Adam Kennedy wrote:
> UNIVERSAL::isa/can when called as a function does a very specific thing,
> and one that is often misunderstood.
... and never correct, in the face of proxy objects, blessed objects,
overloading, and ties.
> And if you were able to distingui
I use 5.8.0 as minimum, but for unicode I think it should be 5.8.1 - but I
am unsure. COuld you give a reason for why specifically 5.8.3?
Actually, in consultation with Audrey and other $experts,
Perl::MinimumVersion applies a 5.8.4 minimum whenever it sees any
mention of Unicode.
I believe
chromatic wrote:
On Wednesday 05 April 2006 14:09, Adam Kennedy wrote:
And now in return, we have new modules that changes the way EVERYBODY
else's code works, and changes the meaning of that code instead, so
Test::MockObject gets less spurious bug reports.
You mischaracterize the situation.
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
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
On Wednesday 05 April 2006 14:09, Adam Kennedy wrote:
> And now in return, we have new modules that changes the way EVERYBODY
> else's code works, and changes the meaning of that code instead, so
> Test::MockObject gets less spurious bug reports.
You mischaracterize the situation.
There is no po
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 of
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:
> > >>There is also the point that supporting ancient Perls means you
> > >>can't use all the
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,
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 tho
* 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 leas
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 fi
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
* "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 tes
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
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
> l
chromatic wrote:
On Tuesday 04 April 2006 21:57, Adam Kennedy wrote:
Seeing as the worst support cases are about 10 years in a variety of
countries and situations, I think that is what we should be aiming for
for highly used CPAN modules.
Which last time I checked is now 5.005.something
So I
On 4/4/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> I want to see File::HomeDir ultimately in there, because there's a
> number of things that use $ENV{HOME} and implement their own special
> case logic.
If it presents a platform independent way to find a home dir then I
agree with you.
> You wa
On 4/4/06, David Landgren <[EMAIL PROTECTED]> wrote:
> demerphq wrote:
> There are also some mistakes, like Switch, but once a module goes in, it
> can never be removed. That's the main reason why people are so leery
> these days of adding new stuff to the core, in case they get it wrong.
Thats an
On Tue, 4 Apr 2006 19:27:57 -0400, Ricardo SIGNES
<[EMAIL PROTECTED]> wrote:
> * "H.Merijn Brand" <[EMAIL PROTECTED]> [2006-04-04T10:40:39]
> > And then still people make more of the same. Take Getopt::Long. A perfect
> > and
> > very functional module. Full of features, matured, and actively mai
On Tuesday 04 April 2006 21:57, Adam Kennedy wrote:
> Seeing as the worst support cases are about 10 years in a variety of
> countries and situations, I think that is what we should be aiming for
> for highly used CPAN modules.
>
> Which last time I checked is now 5.005.something
>
> So I aim ther
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 etc.
This to me is the biggest problem. After 6 years, is it
Ricardo SIGNES wrote:
* "H.Merijn Brand" <[EMAIL PROTECTED]> [2006-04-04T10:40:39]
And then still people make more of the same. Take Getopt::Long. A perfect and
very functional module. Full of features, matured, and actively maintained.
Now go look at CPAN, and see how many people either do not
* "H.Merijn Brand" <[EMAIL PROTECTED]> [2006-04-04T10:40:39]
> And then still people make more of the same. Take Getopt::Long. A perfect and
> very functional module. Full of features, matured, and actively maintained.
> Now go look at CPAN, and see how many people either do not like it or find
> o
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 etc.
This to me is the biggest problem. After 6 years, is it finally okay for
Moin,
On Tuesday 04 April 2006 01:50, Tyler MacDonald 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
Moin,
On Tuesday 04 April 2006 18:30, Adam Kennedy wrote:
> > Who was it who was working on the global CPAN dependency graph, to
> > figure out what module was dependent on what? Whatever became of
> > that? I think hard numbers that stand on their own merits are about
> > the only way to get new
Moin,
On Tuesday 04 April 2006 01:35, Sébastien Aperghis-Tramoni wrote:
> 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 a
Who was it who was working on the global CPAN dependency graph, to
figure out what module was dependent on what? Whatever became of that? I
think hard numbers that stand on their own merits are about the only way
to get new stuff into core. Let the early adopters try out non-CPAN
low-level mo
On Tue, 04 Apr 2006 16:20:09 +0200, David Landgren <[EMAIL PROTECTED]> wrote:
> demerphq wrote:
> > 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 c
demerphq wrote:
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
o
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
regular basis.
When I hear or read that, I always wonder if the author realised that
"core modules" is something dependant on the Perl distribution version.
demerphq wrote:
> 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 b
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
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
Adam Kennedy wrote:
While the code for the distribution might be able to die like this,
the INSTALLER should fail in a way that is detectable and automatable.
If the Cd warnings.pm module can't be found, it crashes
(specifically, dies) and say it can't find warnings. But the problem
isn't th
demerphq wrote:
On 4/2/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
demerphq wrote:
On 4/1/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> Similarly
if somebody has an error in their Build.PL or Makefile.PL are you
going to say that the "installer" doesnt work?
Yes, absolutely.
So you would f
On 4/2/06, demerphq <[EMAIL PROTECTED]> wrote:
> On 4/2/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> > demerphq wrote:
> > > On 4/1/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> > >> > Similarly
> > >>> if somebody has an error in their Build.PL or Makefile.PL are you
> > >>> going to say that th
On 4/2/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> demerphq wrote:
> > On 4/1/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> >> > Similarly
> >>> if somebody has an error in their Build.PL or Makefile.PL are you
> >>> going to say that the "installer" doesnt work?
> >> Yes, absolutely.
> >
> > So
chromatic wrote:
On Saturday 01 April 2006 03:41, demerphq wrote:
So you would file a bug with ExtUtils::MakeMaker or Module::Build when
the pre-build script that accompanies a script has a syntax error in
it?
Don't forget with every distribution that marked that distribution as a
dependency
demerphq wrote:
On 4/1/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> Similarly
if somebody has an error in their Build.PL or Makefile.PL are you
going to say that the "installer" doesnt work?
Yes, absolutely.
So you would file a bug with ExtUtils::MakeMaker or Module::Build when
the pre-bui
On Mar 31, 2006, at 11:02 AM, Adam Kennedy wrote:
Most end users don't see the "build" stage as being somehow
distinct, all they want to do is "install a module".
I agree 100% with that, and urge others to keep that in mind.
---
Matisse
On Saturday 01 April 2006 03:41, demerphq wrote:
> So you would file a bug with ExtUtils::MakeMaker or Module::Build when
> the pre-build script that accompanies a script has a syntax error in
> it?
Don't forget with every distribution that marked that distribution as a
dependency.
-- c
Moin,
On Saturday 01 April 2006 14:13, demerphq wrote:
> On 4/1/06, demerphq <[EMAIL PROTECTED]> wrote:
> > On 4/1/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> > > > Similarly
> > > >
> > > > if somebody has an error in their Build.PL or Makefile.PL are you
> > > > going to say that the "install
On 4/1/06, demerphq <[EMAIL PROTECTED]> wrote:
> On 4/1/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> > > Similarly
> > > if somebody has an error in their Build.PL or Makefile.PL are you
> > > going to say that the "installer" doesnt work?
> >
> > Yes, absolutely.
>
> So you would file a bug with
On 4/1/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> > Similarly
> > if somebody has an error in their Build.PL or Makefile.PL are you
> > going to say that the "installer" doesnt work?
>
> Yes, absolutely.
So you would file a bug with ExtUtils::MakeMaker or Module::Build when
the pre-build scrip
> Similarly
if somebody has an error in their Build.PL or Makefile.PL are you
going to say that the "installer" doesnt work?
Yes, absolutely.
Adam K
On 3/31/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> demerphq wrote:
> > So it seems to be that you have four (five?) phases:
> >
> > Pre-Build
> > Build
> > Test
> > Install
> > (Post Install Test?)
> >
> > Something like dieing on a use warnings statement in the makefile or
> > whatever to
demerphq wrote:
On 3/31/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
If an installer can't INSTALL under battle conditions, it is failing
it's primary missing.
Personally I think its worth being a touch more specific with your language.
I dont see Module::Build's job to be to "install". I see
On 3/31/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> If an installer can't INSTALL under battle conditions, it is failing
> it's primary missing.
Personally I think its worth being a touch more specific with your language.
I dont see Module::Build's job to be to "install". I see its job as
being
ugh, sorry, WAY too early in the morning.
If the installer needs a module in order to run, it has nothing to fall
back on to supply that module for it. Any surrounding client doing a
recursive installation can't fix it, unless what it can do when the
installer runs and says that the distributi
Randy W. Sims wrote:
Adam Kennedy wrote:
>> There are a number of ways to do this. The most simple is:
>>
>> use strict;
>> use warnings;
>>
>> use File::HomeDir;
>> my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo' );
>
>
> Not that I wish to be a pedant about this, but
58 matches
Mail list logo
