Module requirements (was: Module::Build and installing in non-standard locations)
Randy W. Sims
>> 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 only so people keep it in
> mind...
>
> This installer will crash with a non-useful error message if someone
> tries to install of < 5.006, and has an implicit undeclared (still
> unresolvable I believe) dependency on File::HomeDir.
How is this different from a Makefile.PL or any other perl script with a
C<use> statement. If the C<use>d module can't be found, it says it can't
be found. It doesn't crash.
Sure, the dependency should be listed in META.yml. And, there is a way
to that so that CPAN.pm and other tools can see the dependency before
running the Build.PL: You simply list it in C<requres> argument to the
constructor. But this was just a simplified example to illustrate a
different point...
> (I'll shut up about the whole implicit undeclared unresolvable
> dependency on Module::Build for a while, given it's now in the core and
> I've had a good long chat about the issue with Tony.)
Again, how is this different from MakeMaker's Makefile.PL which, strange
enough, requires MakeMaker to be present?
> So if you use warnings in your Build.PL you should always do it as
>
> use 5.006;
> use strict;
> use warnings;
I agree, this is true of any script, not just Build.PL.
> As for how to ensure File::HomeDir is installed before you actually know
> what you dependencies are, well I dunno, but this problem is going to
> keep coming back and haunting us till MB supports bundling of some kind.
Bundling is *a* solution to *some* problems *some* of the time. From
what I understand there's a pretty good module out there that helps with
that ;). But I'm not yet convinced that it should be the default method
for every distribution. Authors should have a choice. For people who
want to bundle Module::Build it's simple to do by hand, and it's been
done by authors who decided that was best for their distribution.
Regards,
Randy.
Adam Kennedy
> 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 only so people keep it in
> > mind...
> >
> > This installer will crash with a non-useful error message if someone
> > tries to install of < 5.006, and has an implicit undeclared (still
> > unresolvable I believe) dependency on File::HomeDir.
>
> How is this different from a Makefile.PL or any other perl script with a
> C<use> statement. If the C<use>d module can't be found, it says it can't
> be found. It doesn't crash.
There is no difference at all when it comes to Makefile.PL.
The problem is specific to installers. In an installer, you don't yet
know if any piece of code is SUPPOSED to run, as well as not know if it
will run.
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 C<use>d warnings.pm module can't be found, it crashes
(specifically, dies) and say it can't find warnings. But the problem
isn't that it doesn't have warnings. The problem is that it doesn't have
Perl 5.006.
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 distribution itself needs dependencies.
If the installer doesn't look after itself, then we are back to the
situation where you are installing RT, and half way though 3000 lines of
output something goes BLART NO WARNINGS.PM, INSTALL FAILED and then
prints another 1000 lines of output, and no reasonable end users has any
idea whatsoever what caused the problem, or how to fix it.
If an installer can't INSTALL under battle conditions, it is failing
it's primary missing.
Adam K
Adam Kennedy
> 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 distribution itself needs dependencies.
This should be
"Any surrounding client doing a recursive installation can't fix it,
UNLIKE the way it can when the installer completes and tells the client
what needs to be installed".
> If an installer can't INSTALL under battle conditions, it is failing
> it's primary missing.
missing -> mission.
Adam K
Demerphq
> 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 to "build". It should, and does leave the job of "installing" to
ExtUtils::Install. And that makes sense to me.
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 me constitutes a pre-build failure, not an install
failure.
<aside>
I've actually often wondered why there isnt a fifth stage, that being
a post-install test. IOW, it would be nice if you there was an easy
way to run the test suite against the installed packages.
</aside>
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Adam Kennedy
> On 3/31/06, Adam Kennedy <cp...@ali.as> 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 to "build". It should, and does leave the job of "installing" to
> ExtUtils::Install. And that makes sense to me.
>
> 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 me constitutes a pre-build failure, not an install
> failure.
I'd consider that to be just a case of semantics.
I could well argue it doesn't "build" either, it $smaller_divisions_again.
From a top level tasks perspective, Module::Build has two primary roles.
1. Package the module into a distribution.
2. Install the distribution onto a system
Those 4(5) steps are all part of the "install" task.
Most end users don't see the "build" stage as being somehow distinct,
all they want to do is "install a module".
Adam K
A. Pagaltzis
> Something like dieing on a use warnings statement in the
> makefile or whatever to me constitutes a pre-build failure, not
> an install failure.
`s/installer/build script/gi` on Adam’s post and his points still
stand. The whatever-it’s-called whose job it is to generate the
dependency information must take care to never abort and always
produce some useful information, else there’s nothing useful to
do for the whatever-it’s-called whose job it is to take this
information and act on it.
Gtk2-Perl had this problem, where the `Makefile.PL` in Gtk2
depends on the code generation stuff in the Glib distribution,
and both that and the `Makefile.PL` in Glib depend on
ExtUtils::PkgConfig and ExtUtils::Depend. Because of this, it
used to be that saying `cpan -i Gtk2` would fail unless you
manually installed the modules in the right order. Now there is
some hackery to avoid bombing out completely uselessly, but you
still end up having to re-run the command a few times until it
actually succeeds.
I think the way to address this would be for `Makefile.PL` or
equiv. to be able to tell the shell that it couldn’t actually
complete because it requires some missing dependencies, so that
the shell can then go and fetch/build/install those dependencies
and then re-run the `Makefile.PL`. Then the hackery used by the
Gtk2-Perl suite would actually work correctly, without the user
having to re-run commands manually in order to unwind the build
dependency tree.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Demerphq
> > 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 me constitutes a pre-build failure, not an install
> > failure.
>
> I'd consider that to be just a case of semantics.
>
> I could well argue it doesn't "build" either, it $smaller_divisions_again.
>
> From a top level tasks perspective, Module::Build has two primary roles.
>
> 1. Package the module into a distribution.
> 2. Install the distribution onto a system
>
> Those 4(5) steps are all part of the "install" task.
>
> Most end users don't see the "build" stage as being somehow distinct,
> all they want to do is "install a module".
If you zoom out far enough there is only one objective: make the code
work. Which to me just demonstrates that that level of zoom is
useless. Likewise we can zoom in really far and get into even smaller
divisions. But at that point you are going to find that many modules
dont do anything in some or all of those divisions so its arguable
that such a fine grain isnt _generally_ useful either. Wheras the
levels i just outlined covers pretty well every distribution (that
comes with tests) out there.
And i think most users of CPAN are very comfortable with these stages
and also see them as distinct. They map pretty well exactly onto the
standard mantra:
1. perl Makefile.PL (prebuild)
2. make (build)
3. make test (test)
4. make install (install)
Anyway, I think that PPM is an "installer" by your definition, but I
dont think that either ExtUtils::MakeMaker or Module::Build are.
Module::Build actually does not know how to install anything. It
leaves it totally up to ExtUtils::Install. Likewise
ExtUtils::MakeMaker doesnt know how to install anything, as it also
leaves it up to ExtUtils::Install. Just like neither know how to test
anything, they leave that up to Test::Harness and friends. If TH
starts acting strangely are you going to send bug reports to the
Module::Build guys about how their "installer" doesnt work? Similarly
if somebody has an error in their Build.PL or Makefile.PL are you
going to say that the "installer" doesnt work?
Anyway, i personally find over-abstraction (its all just installation)
and under-abstraction (there are a million steps to go through) just
lead to confusion and misunderstanding which I think is less than
desirable.
Adam Kennedy
> 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
Adam Kennedy
I guess the problem is that in Makefile.PL strictly speaking you're not
_really_ meant to be doing any building of stuff.
That's supposed to be what you do in make.
So one solution to your problem might be to add something that defers
that part until make.
For example...erm... take a --make flag in the Makefile.PL that tells it
to go off and do the generation of things, and then if not passed
--make, run the normal stuff, but add an entry into the appropriate
place so that a Makefile rule is added to trigger that callback.
Adam K
A. Pagaltzis
> I guess the problem is that in Makefile.PL strictly speaking
> you're not _really_ meant to be doing any building of stuff.
>
> That's supposed to be what you do in make.
>
> So one solution to your problem might be to add something that
> defers that part until make.
Of course, the problem is hacking EU::MM etc such that it
actually works, which is a lot more effort than cheating and
doing it in `Makefile.PL`.
> For example...erm... take a --make flag in the Makefile.PL that
> tells it to go off and do the generation of things, and then if
> not passed --make, run the normal stuff, but add an entry into
> the appropriate place so that a Makefile rule is added to
> trigger that callback.
Or port to M::B and quit worrying…
I wonder though if there aren’t cases where you *will* need some
sort of dependency for the build script generator to run at all;
maybe stuff dealing with dependencies not natively supported by
the CPAN shell in question, or something. Being able to reinvoke
the dependency resolver in the shell would be the only clean
solution in such cases.
Adam Kennedy
> * Adam Kennedy <ad...@cpan.org> [2006-04-01 04:10]:
>> I guess the problem is that in Makefile.PL strictly speaking
>> you're not _really_ meant to be doing any building of stuff.
>>
>> That's supposed to be what you do in make.
>>
>> So one solution to your problem might be to add something that
>> defers that part until make.
>
> Of course, the problem is hacking EU::MM etc such that it
> actually works, which is a lot more effort than cheating and
> doing it in `Makefile.PL`.
>
>> For example...erm... take a --make flag in the Makefile.PL that
>> tells it to go off and do the generation of things, and then if
>> not passed --make, run the normal stuff, but add an entry into
>> the appropriate place so that a Makefile rule is added to
>> trigger that callback.
>
> Or port to M::B and quit worrying…
*cringe*
Except that brings other problems...
Adam K
Demerphq
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?
Lets hope you wouldnt be surprised when they file said bug report in
/dev/nul....
Demerphq
> On 4/1/06, Adam Kennedy <ad...@cpan.org> 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 script that accompanies a script has a syntax error in
> it?
>
> Lets hope you wouldnt be surprised when they file said bug report in
> /dev/nul....
That was meant to have a smiley face after it.
:-)
Seriously tho, how can such a situation be the installers fault?
Tels
Easy, Makefile.PL, M::B or whatever are all parts of the install process.
It's just that different parties are responsibe for different parts.
(Just think how my Makefile.PLs broke because there was a change in
YAML.)
You just complain to the person most likely to fix the problem.
Best wishes,
Tels
--
Signed on Sat Apr 1 18:28:01 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"A bus station is where a bus stops. A train station is where a train
stops. On my desk I have a work station." -- Unknown
Chromatic
> 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
Matisse Enzer
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 Enzer <mat...@matisse.net>
http://www.matisse.net/ - http://www.eigenstate.net/
Adam Kennedy
> On 4/1/06, Adam Kennedy <ad...@cpan.org> 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 script that accompanies a script has a syntax error in
> it?
No, you'd file it against the distribution that contained the
Makefile.PL or Build.PL.
Just because they implement the installer using a particular library,
doesn't mean you blame the library for their mistakes.
Adam K
Adam Kennedy
That's a far hazier situation and you know it :)
It's only a bug in the dependent module if it's fixed in the parent
module, and the dependent one doesn't update the dependency to point to
the new version.
Adam K
Demerphq
> demerphq wrote:
> > On 4/1/06, Adam Kennedy <ad...@cpan.org> 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 script that accompanies a script has a syntax error in
> > it?
>
> No, you'd file it against the distribution that contained the
> Makefile.PL or Build.PL.
Ah so, you've changed your position somewhat then eh? I guess you dont
think its a bug in the installer anymore? I mean if its a bug in the
installer why would you report the matter to the distribution author?
> Just because they implement the installer using a particular library,
> doesn't mean you blame the library for their mistakes.
You mean just because something fails duing installation doesnt mean
its a problem with the installer?
:-)
Cheers,
Demerphq
Which says to me that being clear about which phase of the build
process something fails _is_ actually useful. As thats how you decide
who to file your bug with. :-)
Adam Kennedy
> On 4/2/06, Adam Kennedy <cp...@ali.as> wrote:
>> demerphq wrote:
>>> On 4/1/06, Adam Kennedy <ad...@cpan.org> 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 script that accompanies a script has a syntax error in
>>> it?
>> No, you'd file it against the distribution that contained the
>> Makefile.PL or Build.PL.
>
> Ah so, you've changed your position somewhat then eh? I guess you dont
> think its a bug in the installer anymore? I mean if its a bug in the
> installer why would you report the matter to the distribution author?
Not at all, I'm probably just using a different terminology.
Makefile.PL is the installer.
Build.PL is the installer.
ExtUtils::MakeMaker and Module::Build are modules used to write installers.
If there's a bug in the installer, it's the author who wrote the
installer's fault and you file a bug against the distribution.
If there's a bug in the module used to write the installer, you file it
against the library.
This all makes sense if you ignore internals.
>> Just because they implement the installer using a particular library,
>> doesn't mean you blame the library for their mistakes.
>
> You mean just because something fails duing installation doesnt mean
> its a problem with the installer?
If something fails during installation, then initial blame lies with the
distribution. If you can determine that the source of the bug is the
library that the installer is using, and the problem applies to ALL
installers using that library, then you pass blame up the line.
If you ignore internals and look at this problem in terms of
responsibility, this all makes perfect sense.
It's the responsibility of a Makefile.PL to install a distribution, or
to explain why the distribution cannot be installed.
In some of these cases, the surrounding CPAN client can resolve these
unmet dependencies and continue with the install.
If a module uses a dependency and the dependency is fatally broken,
responsibility still sits with the module, if not for the bug itself,
then for choosing to use a broken module instead of one that isn't broken.
When you choose your dependencies, you also choose to inherit their baggage.
Where a specific line of code is wrong, or how some internal algorithm
works are implementation issues deriving from how you handle
responsibility and the choices you make.
Adam K
madd...@free.fr
> 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 C<use>d warnings.pm module can't be found, it crashes
> (specifically, dies) and say it can't find warnings. But the problem
> isn't that it doesn't have warnings. The problem is that it doesn't
> have Perl 5.006.
>
> 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 distribution itself needs
> dependencies.
To be honest, I don't understand why you're all having such discussions
about using or not modules. The advantage of Perl is that it's a
dynamic language, where you can use eval() to dynamically load a module
and an avoid horrible death which can let end users in awe.
For example, I have an eval 'use ExtUtils::MakeMaker::Coverage' in most
of my Makefile.PL in order to have the textcover target where all
required modules are installed. Granted, this won't work for lexical
pragmas like "warnings", but to be honest, I don't see the value of
showing useless warnings to the end user.
> If an installer can't INSTALL under battle conditions, it is failing
> it's primary missing.
General rule of thumb: check with Module::CoreList which modules are in
the core, and since when, then decide which Perl version you want to
target, and eval-use all the modules that are not in the core of this
version. Also apply to platform-specific modules (like Win32::*).
Simple and works well; you can write Makefile.PL that work with old
Perl versions.
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::Constant work with
5.004 (and maybe earlier) but their author haven't yet released updated
versions. With these patches (and if the test suites of some of these
are fixed), several modules can probably work on 5.004 or earlier with
little to no changes.
Sébastien Aperghis-Tramoni
-- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
Close the world, txEn eht nepO
Tels
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::Constant work with
> 5.004 (and maybe earlier) but their author haven't yet released updated
> versions. With these patches (and if the test suites of some of these
> are fixed), several modules can probably work on 5.004 or earlier with
> little to no changes.
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 randomization", "memory
leaks".
Using these older Perls means you basically show the hard-working
Perl5-Porters that you don't care for their work in improving Perl.
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"?
Best wishes,
Tels
--
Signed on Mon Apr 3 18:28:11 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"I'm not a vegetarian, but I eat animals who are" -- Groucho Marx
Adam Kennedy
> 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 possibly the smartest thing I've ever heard Donald Rumsfeld say
(although he put it somewhat confusingly)
"There are known knowns. These are things we know that we know. There
are known unknowns. That is to say, there are things that we know we
don't know. But there are also unknown unknowns. There are things we
don't know we don't know."
While you might not see why, let me tell you from the number of bug
emails I've received about these sorts of issues, I _know_ there are
scenarios we don't know about where this stuff is important.
I just don't know what they are :)
Adam K
madd...@free.fr
> 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 randomization", "memory
> leaks".
You forget that there's more than one way to use Perl :-)
When Perl is used for sysadmin tasks, most of the features you listed
(and I could add "threads support", "new IO implementation", "signals
handling", "subroutines attributes") are of no to little use because
such Perl scripts are run for executing tasks that do not require
advanced Perl features like those just listed. Remember that on Unix
systems, Perl is like Bash, Sed and Awk, only more powerful (even if
it's by one or two orders). Do you replace your /bin/sh on your Solaris
with the latest Bash just because it has very new and cool features?
Usually you can't. Mainly because it could break things, and has little
to no added value.
> Using these older Perls means you basically show the hard-working
> Perl5-Porters that you don't care for their work in improving Perl.
But the Perl interpreter (which is what the P5Porters are working on)
and the Perl modules are mostly disconnected (*). Where would be the
interest to use an interpreted language if it were tied to a specific
version of the interpreter? Most Perl code out there don't require
recent features.
To continue with my previous analogy, there are also many people that
work hard on the Linux kernel, the GNU system, and all the different
parts that compose a GNU/Linux distribution, but when a server is in
production, you can't upgrade it at your wish.
(*) 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.
> 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"?
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 versions. But that's not a problem because I don't need to
upgrade Perl or the modules on said systems, just to put the modules I
need in a directory and "use lib /that/directory". Of course I need to
use modules that work with 5.004, or patch them so they work with
5.004, but you could be surprised to see how little some of the patches
are. Can be as simple as removing "require 5.6" (as for File::Temp).
Most of the patches I've sent were less than 10 lines of differences.
Tyler MacDonald
> >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 randomization", "memory
> >leaks".
FWIW I've heard at least one valid argument for sticking with 5.6,
and that actually is unicode support. :-)
Apparently, in 5.6 regular expressions don't have full unicode
support. But in 5.8 the regexp unicode stuff is expensive. And to make
matters worse, if anything in any package that you import uses unicode, the
new, slower unicode regular expression algorithm is applied to *everything*
and there's no easy way to turn that off.
This is just a nasty rumour I'm sure, but I've heard it multiple
times from multiple people. I like to stay on the cutting edge and if my
regexps are too slow, I'll find some other way to do it. :-)
Cheers,
Tyler
Demerphq
I dont believe that this is correct.
The regex engine uses UTF8 logic if the pattern is UTF8 or if the
string is UTF8.
If both are ascii then it uses ascii logic only.
Demerphq
> (*) 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.
I dont agree with this. Or rather, I dont agree that the core is
over-crowded. I do agree that as many modules should be dual-lifed as
possible however, but that is just so you can upgrade without
upgrading perl.
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 what a second or
two? It would suck up a couple of extra K, something like 1% of what
most of use for our web-browser cache. So the size argument IMO doesnt
hold water.
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
regular basis.
IMO this objecitve is in direct contradiction of the purported P5P
objective of not adding stuff to the core and just makes omissions
from the core even more critical.
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 that when people write code based only on core
modules they can do a good job without reinventing wheels or code
duplication.
Long term i think the community needs to sort out this problem because
I dont think there is consensus on it, and I think that a lot of
people only look at the issue from their own individual point of view.
If somebody is concerned about the overall quality of perl and CPAN I
think a more holisitic point of view is required.
Adam Kennedy
> 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 that when people write code based only on core
> modules they can do a good job without reinventing wheels or code
> duplication.
The trouble is that Perl is run SO many places, doing so many things,
over so many platforms, across so many decades (now 2) :) that "do a
good job" is enormously difficult to define.
It varies so much, that you end up slurping in module after module until
the "core" is an enormous JDK-like mass of code.
So the core contains those modules that people at various points have
felt we absolutely can't live without or (unfortunately) the commit had
the relevant "pull" to add without reprisals.
And everyone always wants to add more, constantly.
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.
You want to add ExtUtils::Installer once it works, so
ExtUtils::MakeMaker can use it.
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 on Spiffy, so Spiffy needs to go in the core (which
isn't what actually happened, but could have)
It goes on and on and on, and eventually it's impossible to make the
core build and smoke cleanly on any platform, because not all of these
packages work everywhere all the time on all platforms.
The core is expected to work everywhere, just look at the number of
File::Spec subfiles now. The work involved to deal with full(ish)
platform support is enormous.
Which is why although I'd secretly like to put File::HomeDir in tomorrow
and deal with problems later, I'm not going to say a damned thing until
I'm sure it's completly bug free and working on as many platforms as
possible, before I even think of broaching the idea.
On the other hand, if you have a specific problem domain you want to
address, it's perfectly acceptable to build a distribution that contains
all the extra things you need for that problem domain, without the need
to impose the extra bloat on the core.
Adam K
madd...@free.fr
> On 4/4/06, Sébastien Aperghis-Tramoni <madd...@free.fr> 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.
>
> I dont agree with this. Or rather, I dont agree that the core is
> over-crowded. I do agree that as many modules should be dual-lifed as
> possible however, but that is just so you can upgrade without
> upgrading perl.
Yes, and if some of these modules can be made to work on older Perl as
well with one- or two-lines patches, isn't it even better? :-)
> 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 what a second or
> two? It would suck up a couple of extra K, something like 1% of what
> most of use for our web-browser cache. So the size argument IMO doesnt
> hold water.
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 to do just on the interpreter. Making core modules dual-life is
a way to handle these to someone else who has spare time and who doesn't
need to have deep XS or Perl guts knowledge. At least I think that's
the reason, otherwise why was I accepted as the maintainer of two
such modules (XSLoader and Sys::Syslog)?
> 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
> 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.
For example a module as important as Test::More was included in the
core in 5.7, which really means 5.8.
Maybe the problem is that, like Abigail pointed it in P5P, there were
fewer Perl releases in the past years, and more precisely we're at the
same branches (5.8 / 5.9) since a long time, therefore reducing the cycle
of potential inclusion of new modules.
> IMO this objecitve is in direct contradiction of the purported P5P
> objective of not adding stuff to the core and just makes omissions
> from the core even more critical.
>
> 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 that when people write code based only on core
> modules they can do a good job without reinventing wheels or code
> duplication.
In a sense, my opinion does not really matter here: the facts are that
many P5Porters in general, and the Pumpkings in particular, dislike
adding new modules to the core, on the basis that installing modules
from the CPAN is easy. You're more active on P5P than I am, so I don't
have to recall you all the discussions that preceded the inclusion of
CPANPLUS and Module::Build, and how making them work everywhere doesn't
look an easy task.
But note that I don't necessarily disagree with you: I would welcome
a Perl distribution that offer more modules, but when I need to write
a portable program, that must run on older Perl, the new features in
the core can't be used anyway.
--
Sébastien Aperghis-Tramoni
Close the world, txEn eht nepO.
Adam Kennedy
>>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.
> For example a module as important as Test::More was included in the
> core in 5.7, which really means 5.8.
This isn't an issue.
Any distribution is going to have a Perl version dependency.
So for any given distribution $d with Perl version dependency
$d->minver, it needs to keep $d->deps as a subset of
$perl[$d->minver]->modules.
This is what 99% of authors mean by that phrase.
And generally the bugs only occur when they misread their minimum
version, or don't put an explicit minimum (and so never bother to check).
Adam K
David Landgren
> On 4/4/06, Sébastien Aperghis-Tramoni <madd...@free.fr> 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.
>
> I dont agree with this. Or rather, I dont agree that the core is
> over-crowded. I do agree that as many modules should be dual-lifed as
> possible however, but that is just so you can upgrade without
> upgrading perl.
There are some crappy modules in the core, though. I mean, look at
C<Search::Dict>. I'm never likely to use that in a million years.
(partly because the documentation doesn't help me understand what it
buys me).
Or C<Text::Soundex>. I know what it does, but its purpose is so
specialised (and in this international age, woefully parochial) that it
hardly deserves core status. It's just that it's been in there forever.
In another universe it would be on CPAN only. Possibly with some sort of
plug-in architecture to let you switch in Metaphone and other
algorithms. Then it might be a bit more useful.
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.
> 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
I don't think bandwidth is the argument.
> of modules to core would increase the rsynch time by what a second or
> two? It would suck up a couple of extra K, something like 1% of what
> most of use for our web-browser cache. So the size argument IMO doesnt
> hold water.
There is the multiplier effect of having that new K stored on all the
mirrors to keep in mind.
> 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
> regular basis.
As long as the core modules are there on the basis that they serve as
building blocks to build other modules, I don't see any problem with
that. The trouble is that all the cool tools are evolving so rapidly
that putting them into core would really cramp their style.
> IMO this objecitve is in direct contradiction of the purported P5P
> objective of not adding stuff to the core and just makes omissions
> from the core even more critical.
I'm curious, what's critically lacking?
> 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 that when people write code based only on core
> modules they can do a good job without reinventing wheels or code
> duplication.
What wheels are being reinvented, or what code is being duplicated? I
think the core problem-space isn't too bad.
I'm not sure that there are many intermediate level modules left out
there that can be applied to generic module development. I'm not sure
that I want to drink the Class::* kool-aid.
> Long term i think the community needs to sort out this problem because
> I dont think there is consensus on it, and I think that a lot of
> people only look at the issue from their own individual point of view.
> If somebody is concerned about the overall quality of perl and CPAN I
> think a more holisitic point of view is required.
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 modules. Then after a while, see what floats to the top.
David
--
"It's overkill of course, but you can never have too much overkill."
H.Merijn Brand
> demerphq wrote:
> > On 4/4/06, Sébastien Aperghis-Tramoni <madd...@free.fr> 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.
> >
> > I dont agree with this. Or rather, I dont agree that the core is
> > over-crowded. I do agree that as many modules should be dual-lifed as
> > possible however, but that is just so you can upgrade without
> > upgrading perl.
>
> There are some crappy modules in the core, though. I mean, look at
> C<Search::Dict>.
Never heard of it :)
> I'm never likely to use that in a million years. (partly because the
> documentation doesn't help me understand what it buys me).
>
> Or C<Text::Soundex>. I know what it does, but its purpose is so
> specialised (and in this international age, woefully parochial) that it
> hardly deserves core status. It's just that it's been in there forever.
> In another universe it would be on CPAN only. Possibly with some sort of
> plug-in architecture to let you switch in Metaphone and other
> algorithms. Then it might be a bit more useful.
I *do* use Text::Soundex, and Text::Metaphone together to find user typoes in
databases, but I wouldn't mind if the first was not in CORE. But I have never
used CGI before, and have no plans to do so in the future, and would not cry
if it were taken out. But there is this policy that once a module is in core,
it is very unlikely that it will be removed. A very good candidate for
removal would be Switch, as it causes more pain than pleasure.
> 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.
As I said. I fully agree.
> > 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
>
> I don't think bandwidth is the argument.
>
> > of modules to core would increase the rsynch time by what a second or
> > two? It would suck up a couple of extra K, something like 1% of what
> > most of use for our web-browser cache. So the size argument IMO doesnt
> > hold water.
>
> There is the multiplier effect of having that new K stored on all the
> mirrors to keep in mind.
>
> > 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
> > regular basis.
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
other reasons to write their own.
The problems arise when authors of big modules start prefering non-core
versions of good core modules. IMHO something like that should give you a
(very) negative score on CPANTS.
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0, AIX 4.3 & 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
Adam Kennedy
> 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 modules. Then after a while, see what floats to the top.
There's a couple of people working on this in dribs and drabs, me included.
With the new DBIx::Loader module coming out soon, and having SQLite
support, I'm planning on merging Data::Package::SQLite with DBIx::Class
so you can point a class at a SQLite URI and it will just sort of
download and unfold itself into a full CDBI-like interface to the data.
And with that, we get much much easier access to the datasets generated
by CPANTs, CPAN Testers, and a few other things.
Which makes dependency graphs and such much much more trivial, and more
likely to be available from something you just grab from CPAN.
(and once I get my CPAN SQLite index, you get CDBI-like access to the
index too, like JSAN has)
Adam K
Tels
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 stuff into core. Let the early adopters try
> > out non-CPAN low-level modules. Then after a while, see what floats
> > to the top.
I was, but it is atm very hard to get simple things queried from the
CPANTS (or CPAN or whatever) database.
There is a package list, but it only includes author/file info, no
dependencies, license etc.
There is also CPANTS database, which includes the stuff, but is outdated
(e.g. from 2005-12-05)
I thought about writing my own stuff, but I am completely overloaded with
other work atm.
It would be cool to generated whatever graphs/stats from CPAN easily,
though. And if you have easily dependency information, you could even
easily build an auto-bundler, that throws you a .tar.gz containing the
module and every nec. dependency in one go.
best wishes,
tels
--
Signed on Tue Apr 4 18:54:00 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"A Thaum is the basic unit of magical strength. It has been universally
established as the amount of magic needed to create one small white
pigeon or three normal-sized billiard balls." -- Terry Pratchett
Tels
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 and feature-lacking code like 5.6. or
> > even gasp 5.004. Just think "Unicode support", "hash randomization",
> > "memory leaks".
>
> You forget that there's more than one way to use Perl :-)
:)
> When Perl is used for sysadmin tasks, most of the features you listed
> (and I could add "threads support", "new IO implementation", "signals
> handling", "subroutines attributes") are of no to little use because
> such Perl scripts are run for executing tasks that do not require
> advanced Perl features like those just listed. Remember that on Unix
> systems, Perl is like Bash, Sed and Awk, only more powerful (even if
> it's by one or two orders). Do you replace your /bin/sh on your Solaris
> with the latest Bash just because it has very new and cool features?
> Usually you can't. Mainly because it could break things, and has little
> to no added value.
On workstations, poeple (e.g me, collegues, family etc) tend to install a
new system every 2..3 years because the old(er) linux versions are
usually lacking in feature (like, say, no unicode support, no support for
modern hardware, buggy software, etc etc).
OTOH, I have server systems running for like 3 years (or until the
hardware burns down) because "it works". (Usually, after a few years you
upgrade the system anyway, because the definition of "works" changed
sufficiently, or the environment causes the machine to no longer "work"
with others).
In the former case I am not interested in running older perls, in the
latter case I am not updating any module or software on the server unless
its definitely broken, because updating lets say File::Temp would risk
breaking the system, and users of the machine in question don't like
downtimes.
Now, there is definitely a difference between very "basic" modules that
should run on 5.004, like File::Temp or whatever, and "fancy" stuff you
don't want to run on such old systems, like say Graph::Easy, though.
But for instance, I am totally at a loss why Version.pm needs to support
5.004 - I mean, if you are running such an ancient machine, why put a new
Version.pm on it and risk breaking stuff?
Likewise, why using BigInt on 5.004? The bugs in overload.pm alone would
probably make your head spin.
I think the worst case is that the testsuite runs ok, so you think it
works, but it then breaks in many and subtle ways, exactly when you need
it most.
More below:
You $work is what I call a "special case". It is certainly not the generic
case (at least for my userbase), and I don't think that authors should
have to care for such special needs (unless they want :-D.
The biggest problem you face IMHO is that the module might "work" in
testing, but not in praxis. Dont think CPAN testers even do 5.6 anymore,
and I do not havy anything older than 5.8.3 at my disposal. This means
anything I release is _seriously_ undertested on older Perls.
If you'd send me such a patch, I'd gladly add it, but I would still not be
able to make guaranties, and the next version might easily break on
$OldPerl again.
For instance, silly example, the regexp engine blows the stack on anything
except bleed. It will work in testing (duh!), it might even work on the
server, but as soon as a user supplies sufficiently bad enough input
data, it blows. The only way to avoid that is to upgrade your Perl/Kernel
whatever. So while your patch seemingly makes the code work, the
definition of "works" is, well, broad :)
If you are sure you never get bad data, fine. If you can't be sure,
upgrading kernel, glib and Perl etc might be nec.
Anyway, I don't say that older support is not possible, but I think that
the work should be done by whoever needs it (e.g. the few crazy people
running such old stuff), and not by the author (who is overworked
anyway). 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.
Best wishes,
Tels
PS: Just a woeful tale from today: Want to show someone the wonderfull SVG
I made today. Installed latest Firefox especially for that. It breaks and
renders garbage. Turns out that the user in question *was* running Win98,
and there is a problem rendering text in SVG on that system. (Don't even
ask about unicode - luckily I didn't include a chinese character just for
laughs).
Now there are three options:
* ask the user to upgrade the OS
* live with it not working.
* fix firefox, svg rendering lib and win98 unicode support. Will be done
by about 2078.
The user response will be "Well, Win98 works for me, why should I
upgrade?". And then later "But why can't I see the nice SVG?" Which makes
me bash my had into the wall...
--
Signed on Tue Apr 4 19:08:06 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"Now, _you_ behave!"
Tels
Which is fine if you live in ASCII land. Herr Müller paying € 150 to Mr. ☺
唐鳳☻ might not share your view. :)
OTOH, since the introduction of 5.6, hardware has gotten faster and
cheaper, so the slower, but actually working Unicode processing in 5.8
might something you actually want :D
Best wishes,
Tels
--
Signed on Tue Apr 4 19:33:08 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"Ivonna Humpalot"
Chromatic
> 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 me
to use such exotic features as lexical warnings and lexical filehandles, just
to satisfy someone who refuses to upgrade an eight year old installation of
Perl?
Are there such people who absolutely want to use the latest code I wrote
without actually upgrading their systems?
I'm trying to figure out why I've been sending patches to p5p for about five
years now if people complain when I take advantage of the bugs they fix. At
some point, it would be nice if people were to use software released this
millennium.
-- c
A. Pagaltzis
> 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 what a second or two? It would suck up a couple
> of extra K, something like 1% of what most of use for our
> web-browser cache. So the size argument IMO doesnt hold water.
bandwidth and storage are more expensive still than you’d think.
But the real issue isn’t bandwidth, it’s testing and support.
Perl runs on several dozen families of operating systems. Adding
modules to the core means you must – you MUST – make a reasonable
effort to ensure that they run on each and every Perl port.
Is it any wonder that people say core is too big?
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Chromatic
> Is it any wonder that people say core is too big?
Want more heresy?
If the core contained more modules, there'd be even less possibility of
getting managed hosts or hostile system administrators in really picky
environments to install or update modules -- even dual-lived ones.
If the core contained only the minimum necessary modules to update and install
modules, would these reluctant groups finally come up with a way to update
and install useful software released within the past couple of years?
If not, or if not entirely, would that be enough competitive pressure to make
something like PAR or bundles actually usable as a general solution even for
people with only FTP access to their managed servers?
-- c
Ricardo SIGNES
> 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
> other reasons to write their own.
>
> The problems arise when authors of big modules start prefering non-core
> versions of good core modules. IMHO something like that should give you a
> (very) negative score on CPANTS.
Could you elaborate on this? As stated, it seems pretty ludicrous to me. It
reads like this:
You should not use module B that is like module A, if A is in the core
distribution. This is true regardless of the fact that B may be better
optimized for your current needs, planned needs, programming style.
This can be further distilled to:
There's more than one way to do it, but most of them will get you dirty
looks.
--
rjbs
Adam Kennedy
This can vary of course, for example using Params::Util might be ok
instead of Params::Validate.
And I state that as a fact, because I wrote Params::Util and... well...
so there.
But there's very little point in using Exporter::Lite because 100 other
modules use Exporter in any given program.
So even though Exporter::Lite is lite'r than Exporter, the use of
Exporter is zero, while Exporter::Lite means loading another module, and
adds another dependency.
And because dependencies are recursive, you inherit it's baggage.
If one dep doesn't work on VMS, now your program doesn't.
And the more dependencies, especially if you are using more than one
module that does the same thing just because of stylistic differences,
then it means more problems.
It's not till you hit something like Ricardo's exporter, which does some
very novel and interesting extra things, that you reach the threshold.
It's mostly the same, but if you need the extra parts, then it might be
worth the extra dependency.
Adam K
Adam Kennedy
> 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 me
> to use such exotic features as lexical warnings and lexical filehandles, just
> to satisfy someone who refuses to upgrade an eight year old installation of
> Perl?
The answer is "it depends".
I'll have a more definative answer once we get the dependency graph
stuff sorted out.
But as a stopgap answer, I offer the following.
Yes you can, as long as nobody else uses your module.
If you write something for 5.8.4, and then over time dozens of other
modules that use yours are all 5.005, then it might be worth looking at
doing some back-porting, because you've become the weakest link.
That said, to some degree they made that situation themself.
On the other hand, if YOU were adding a module as a new dependency of
something you already have that needs 5.005, and 100 other 5.005 things
already use, then you just broke 5.005 support on them all.
So I'd say on CPAN 5.005 is it's something you expect others to use, 5.6
for general things if you want, 5.8.4 is you need unicode (or whatever
other special cases apply) and if people start using you and you are
getting in the way, consider dropping.
And once we get CPAN and CPANTs graph modules set up, I have an
algorithm in mind that should be able to give us a list of the
Backcompatibility Weakest Links, the modules that are prevent other
modules below them from working on the versions they say they can.
> Are there such people who absolutely want to use the latest code I wrote
> without actually upgrading their systems?
>
> I'm trying to figure out why I've been sending patches to p5p for about five
> years now if people complain when I take advantage of the bugs they fix. At
> some point, it would be nice if people were to use software released this
> millennium.
Ever written software for government?
It's routine to be required to offer a 10 year support period.
This comes up more often that you might think.
And so as my gold standard for back-compatability, I use 10 years. A
decade is a nice round number.
If it's something that isn't very core'y, I use a secondary support
period of 5 years.
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 there.
Adam K
Chromatic
> 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 there.
"Should" is nice and all, but until you start paying my invoices for the
special $40 an hour for free software support (and not a one-time fee, 'cuz
maintenance costs, but it's a much better deal than my usual consulting
rate), it's just an opinion out there in the luminous aether somewhere and
I'll go on quite happily giving people useful software because I enjoy it
until I stop enjoying it. You're totally welcome to file bugs based on your
dependency graph about what I should and shouldn't do.
I'll cheerfully file them under "Not fun. Don't care. You get both pieces if
it breaks." I get paid directly for approximately exactly zero of my CPAN
coding. Thus if it's not fun, I don't do it.
Supporting ancient software from the last millennium and coding with both
hands tied behind my back to support Perl 5.005 and to work around all of its
infelicities and bugs that I've helped to fix isn't fun... unless there's
cash involved or someone else doing the work in such a way that I don't have
to deal with the un-fun.
I write software to make my life easier. If I can't use that software to make
my life easier because people who are using that work I've done for free
complain, well then what's my motivation?
Could I write a test suite without Test::More? Yep. I've done it before.
Could I write my own mock objects by hand without Test::MockObject or
Test::MockObject extends? Absolutely. Do I know how to deal without lexical
warnings or lexical filehandles or to use signals safely? Yep. Doesn't mean
I want to go back to the bad old days.
There have been what, a dozen stable releases of Perl since the last 5.005
release? If someone can't update to a newer release less than 8% of the
time, that's all sorts of auto-face-stabby badness and not so much fun for
me, and frankly TV and video games seem like more fun hobbies with less
frustration, 'cuz I'm pretty sure I'm absolutely NOT getting any decent
feedback from such a situation.
Is there a business in supporting "classic" software in certain situations?
Perhaps. That baby's not cute enough for anyone but its mother to love it
though, in my opinion.
Now if I've mistakenly claimed that a distribution requires Perl 5.6 as a
minimum (which most of mine do, I believe) and it works further back, that's
fine -- I'm happy to loosen that requirement. I have no desire to rule out
the utility of my code in situations where it works without increasing my
blood pressure.
(Now if someone were to make warnings.pm a dual-lived module and put in a
pre-5.6 compatibility mode, great! I don't mind marking a dependency on that
so that my code works in more places. It's just when backwards compatibility
become a millstone around my neck that I want to smash things and generally
not spend time around my computer.)
I don't think I'm so odd a developer in all this.
-- c
H.Merijn Brand
<rjbs-p...@lists.manxome.org> wrote:
> * "H.Merijn Brand" <h.m....@xs4all.nl> [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
> > other reasons to write their own.
> >
> > The problems arise when authors of big modules start prefering non-core
> > versions of good core modules. IMHO something like that should give you a
> > (very) negative score on CPANTS.
>
> Could you elaborate on this? As stated, it seems pretty ludicrous to me. It
> reads like this:
>
> You should not use module B that is like module A, if A is in the core
> distribution. This is true regardless of the fact that B may be better
> optimized for your current needs, planned needs, programming style.
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 various architectures in various
configurations.
I don't say that CPAN module authors didn't test their module on as many
architectures as available to the author, but even if the author has, say,
4 architectures, it is very unlikely that all of these architectures have
32bit and 64bit builds, threaded and non-threaded builds and even multiple
versions of perl available.
B. Let's just name YAML. Up until 0.38 it was not to difficult to install a
module that is very useful, but now in 0.58, it uses a different test
suite, that needs Spiffy, that needs ......
For me that was the drop. No more YAML. If just for the test suite of a
module I have to install half of CPAN and I'm not going to use that for
anything else, while there is a perfectly good and widely used and actively
maintained Test::More available, this is just plain insane.
My opinion only.
> This can be further distilled to:
>
> There's more than one way to do it, but most of them will get you dirty
> looks.
Maybe, but authors might need to keep above statements in mind when adding
new dependencies.
Demerphq
> 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 argument that carries some weight, and one i havent seen
articulated before.
> > 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
>
> I don't think bandwidth is the argument.
I was under the impression it was.
> > of modules to core would increase the rsynch time by what a second or
> > two? It would suck up a couple of extra K, something like 1% of what
> > most of use for our web-browser cache. So the size argument IMO doesnt
> > hold water.
>
> There is the multiplier effect of having that new K stored on all the
> mirrors to keep in mind.
HD space isnt much more expensive than bandwidth, and we mirror all of
CPAN everywhere so I dont really think its a good argument.
> > 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
> > regular basis.
>
> As long as the core modules are there on the basis that they serve as
> building blocks to build other modules, I don't see any problem with
> that. The trouble is that all the cool tools are evolving so rapidly
> that putting them into core would really cramp their style.
Yes I agree. Building block modules are one thing application like
modules are another.
> > IMO this objecitve is in direct contradiction of the purported P5P
> > objective of not adding stuff to the core and just makes omissions
> > from the core even more critical.
>
> I'm curious, what's critically lacking?
Win32 API support is the one that im focusing on. But id be
sympathetic to similar requirements for other platforms.
> > 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 that when people write code based only on core
> > modules they can do a good job without reinventing wheels or code
> > duplication.
>
> What wheels are being reinvented, or what code is being duplicated? I
> think the core problem-space isn't too bad.
>
> I'm not sure that there are many intermediate level modules left out
> there that can be applied to generic module development. I'm not sure
> that I want to drink the Class::* kool-aid.
All the modules reinventing Win32 workarounds that could be obtained
via exposing internal functionality in Perl, or by allowing access to
the API through a proper Perl/XS layer (like the Win32API modules).
Also, all the code that does stuff like
if (eval "use Win32API::File; 1") { .... } else { #its a broken win32
build, aka "core" }
ends up being a maintenance nightmare.
File::Temp, ExtUtils::Install, File::Spec, are all good example of
modules that could be drammatically improved on Win32 by having access
to the Win32API in core.
> > Long term i think the community needs to sort out this problem because
> > I dont think there is consensus on it, and I think that a lot of
> > people only look at the issue from their own individual point of view.
> > If somebody is concerned about the overall quality of perl and CPAN I
> > think a more holisitic point of view is required.
>
> 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 modules. Then after a while, see what floats to the top.
What do you mean by "hard numbers"?
Im doubtful that any such dependency graph would be helpful with
something like Win32API type stuff. Wheras if the modules were core I
could imaging that a lot of things would end up using them. But thats
the thing, you cant rely on them being there unless you use
ActiveState, and if you are a *nix programmer trying to work around
some UNIX/Win32 cognitive mismatch youll never even know that there
are easy ways to do so, IFF you have access to the API.
So from my point of view providing proper Win32 API access in core is
the way to get _non_ win32 developers to produce robust code on that
OS. I dont expect some developer with no Win32 experience to try to
debug a problem, but if Win32API were in core then at least you could
point them at the POD and say "the solution is there, and its in
core". It means that us Win32 developers could maintain an
abstraction layer in Core so that non-win32 developers could use it
with confidence that a) it will work, and b) it will be available.
Demerphq
> * demerphq <deme...@gmail.com> [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 what a second or two? It would suck up a couple
> > of extra K, something like 1% of what most of use for our
> > web-browser cache. So the size argument IMO doesnt hold water.
>
> bandwidth and storage are more expensive still than you'd think.
>
> But the real issue isn't bandwidth, it's testing and support.
> Perl runs on several dozen families of operating systems. Adding
> modules to the core means you must – you MUST – make a reasonable
> effort to ensure that they run on each and every Perl port.
Not if they are platform specific "glue" code. IMO such code _belongs_
in the core as thats the place where its going to get the best
maintenance.
Demerphq
> 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 want to add ExtUtils::Installer once it works, so
> ExtUtils::MakeMaker can use it.
Well, actually ExtUtils::Installer is not that much more than a
figment of my and Randys imagination, so I certainly havent thought
about adding it to core. But if adding it to core meant signifigant
improvements in CPAN and Module::Build's ability to install then I
would say it should go in. Thats a big hypothetical tho.
> 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 on Spiffy, so Spiffy needs to go in the core (which
> isn't what actually happened, but could have)
Actually I thought the decision was that YAML wasnt going in and that
the MB team would roll their own writer?
Anyway, MB to me underscores the issue nicely. Its a big module. Its
getting added to core. Win32API::File is a fraction of the size and
performs essential tasks that you cant do without it (including
upgrading certain key dual-lifed core modules). Both ExtUtils and MB
would benefit from it. File::Temp would benefit from it. Yet for some
reason Win32API::File cant be added. Whereas Module::Build, for all
its superiority over ExtUtils::, does basically the same thing yet its
getting added.
Going back to your example. Spiffy from what i can tell is more or
less along the line of a development luxury item. IMO luxury items
dont really belong in core. Something that uses a luxury item also
doesnt belong in core.
But infrastructure code that is essential on its platform, or code
that provides a abstraction layer over platform dependent quirks IMO
does belong in the core.
As an example I see DDS as a luxury item. For all its superiority over
DD I dont really think it belongs in core. But it contains code that I
see as infrastructure so as time permits im trying to make patches to
migrate that functionality alone to core.
OTOH, something like File::HomeDir, assuming it presents a platform
independent way to deal with the issue of "home directories" sounds to
me like it _should_ be in core. Then people will actually use it
instead of rolling their own every time they need to. Then programs
wouldnt do stupid things on my computer because i dont have an
ENV{HOME} set in my environment.
> It goes on and on and on, and eventually it's impossible to make the
> core build and smoke cleanly on any platform, because not all of these
> packages work everywhere all the time on all platforms.
As long as the modules involved are the type I mean then I dont see the problem.
To clarify: Platform specific infrastructure code, or platform
independent abstraction code belongs in core.
> The core is expected to work everywhere, just look at the number of
> File::Spec subfiles now. The work involved to deal with full(ish)
> platform support is enormous.
My view is the core doesnt actually work everywhere because its
missing essential tools on at least one of those platforms.
> Which is why although I'd secretly like to put File::HomeDir in tomorrow
> and deal with problems later, I'm not going to say a damned thing until
> I'm sure it's completly bug free and working on as many platforms as
> possible, before I even think of broaching the idea.
>
> On the other hand, if you have a specific problem domain you want to
> address, it's perfectly acceptable to build a distribution that contains
> all the extra things you need for that problem domain, without the need
> to impose the extra bloat on the core.
Well my experience is that putting platform specific modules in a
platform specific distribution does not lead to those modules being
widely used by abstraction type code. A common excuse for not doing
so is that adding the use of those modules creates dependency on
modules out of core.
Whereas from what ive seen its much easier to get people to use the
code that is in the core distribution. IE, adding support from
Win32API::File or Win32::TieRegistry is problematic whereas adding
support from Win32.pm is not.
Cheers,
Adam Kennedy
When you are writing new things, that's totally fine.
When I bought into using Test::MockObject, I bought into taking your
baggage along with it quite happily.
And I've happily submitted the various bugs I've found, and if I could
work out exactly how MockObject worked I'd probably have submitted
patches too.
But let me just make it clear I consider there to be two major cases here.
Firstly, you add something new and it doesn't break anything.
Secondly, you add something new and it breaks things.
It's much like democracy or other forms of pluralism. I completely and
utterly defend your right to swing your boot, unless it hits my ass.
Which is why Test::MockObject, despite it's various temporary bugs, is
an overwhelmingly positive thing, and a 5.6 dep is just fine.
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.
I don't claim you do the version thing of course, but it's something
that people often do accidentally without realizing it. And it doesn't
make it hurt any less.
As long as we don't break things that used to work, we should be able to
swing our boots as much as we like.
Adam K
David Cantrell
> 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 versions.
> You $work is what I call a "special case". It is certainly not the generic
> case (at least for my userbase), and I don't think that authors should
> have to care for such special needs (unless they want :-D.
Actually that's a very common situation. The scale may not be, but the
situation most certainly is.
In addition, there are lots of people who have older perls on their
machines - because that's what $OSvendor installed - and are not perl
programmers. If they want to install some random perl application they
will assume that the application is broken if one of its dependencies
doesn't work on their version of perl. If you're lucky, they might read
the error and determine that the module and not the application (or the
language!) is broken, but I'd not put money on them bothering to do that.
--
David Cantrell
David Cantrell
> 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 "there's more than one way to do
it and almost all of them are wrong".
--
David Cantrell
David Cantrell
> On 4/4/06, David Landgren <da...@landgren.net> 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
Scotland.
> HD space isnt much more expensive than bandwidth, and we mirror all of
> CPAN everywhere so I dont really think its a good argument.
Which "we" mirrors CPAN everywhere? I know that I certainly don't keep
CPAN mirrors everywhere I'm likely to program because I don't have the
disk space and have better things to do with the bandwidth. We don't
even keep a full CPAN mirror at work.
>>demerphq wrote:
>>>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.
Application authors even more so.
If you're installing a module, it's reasonable to assume that you know
how to use the CPAN - after all, that's where you got the blasted thing
from in the first place. But if you're installing an application, you
probably downloaded a tarball from sourceforget or something like that,
and it's quite likely that you've never even *heard* of CPAN.
>>What wheels are being reinvented, or what code is being duplicated? I
>>think the core problem-space isn't too bad.
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.
--
David Cantrell
Smylers
> 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.
Um, surely File::Find and Memoize are already in the core?
Smylers
Nicholas Clark
> 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 to do just on the interpreter. Making core modules dual-life is
> a way to handle these to someone else who has spare time and who doesn't
> need to have deep XS or Perl guts knowledge. At least I think that's
> the reason, otherwise why was I accepted as the maintainer of two
> such modules (XSLoader and Sys::Syslog)?
Well, I think it's that reason too. :-)
Yes, to me, "size" is maintainance liability, not disk space or bandwidth.
Putting things in core is a pain. Keeping them there is a pain. I remember
the "fun" of getting Storable sufficiently portable that it could go into
the core. Trying to work around strange issues thrown up by certain AIX
compilers in certain configurations...
Nicholas Clark
H.Merijn Brand
Which reminds me ...
Will the new volunteer to maintain README.aix please stand up?
It's almost no time involved, but fun in working with AIX is a pre, which
rules the current maintainer (me) out.
Ricardo SIGNES
> 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 various architectures in various
> configurations.
Absolutely; this, I cede.
> B. Let's just name YAML. Up until 0.38 it was not to difficult to install a
> module that is very useful, but now in 0.58, it uses a different test
> suite, that needs Spiffy, that needs ......
Ugh, yeah, but you're picking a very specific and specifically troubled
distribution. You also didn't mention (maybe you've been spared learning) that
YAML used to export :all but now doesn't.
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 fewer people want to use that trivial module because it takes longer to
install and is less well-tested by virtue of its dependencies.
> My opinion only.
I don't think your opinion, as stated, is insane. I think it's better to vote
with your installer, though, and avoid using those modules that have more
dependencies than you think is right. I think that Kwalitee is an over-rated
concept, but not useless -- but weirder things keep getting proposed to make it
even less useful. I think "too many non-core deps" would be a nail in its
coffin as a global metric.
--
rjbs
David Cantrell
Ooh.
But Module::CoreList says that Memoize isn't in 5.6, therefore I can't
rely on it.
File::Find - erm, well yes, it's been in since forever, but it has the
world's shittiest interface - in fact, I consider it to be too painful
to use. File::Find::Rule is a much better replacement which hides all
that nastiness.
--
David Cantrell
David Landgren
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).
Executive summary: File::Find has always been there, Memoize, since 5.8.
David
--
"It's overkill of course, but you can never have too much overkill."
Demerphq
> 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 fewer people want to use that trivial module because it takes longer to
> install and is less well-tested by virtue of its dependencies.
Interesting example. What module do you mean? I wasnt aware that there
were very many modules that have dependencies on DDS. OTOH, if it has
to do with proper serilization (of closures, or cyclic data
structures) then Data::Dumper just wont cut it.
Chris Dolan
> 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 released with perl 5
Memoize was first released with perl 5.007003
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Chromatic
> 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", as before UNIVERSAL::isa and
UNIVERSAL::can, I had to deal with way too many bug reports of other people's
code breaking mine. In other words, it didn't work.
For example, Template::Toolkit may *never* work with Test::MockObject because
the author refuses to ask the author of CGI.pm to fix a bug in the latter
module, despite apparently knowing about it for several years and apparently
preferring to break my code instead.
I'm not going to release knowingly broken code, just so my broken code can run
brokenly on really old versions of Perl. What good is that?
-- c
Ricardo SIGNES
I was making a random example of something that used something it probably
didn't need, and that used something that might be emulable by core modules.
--
rjbs
Tels
On Wednesday 05 April 2006 06:43, Adam Kennedy wrote:
> Ricardo SIGNES wrote:
> > * "H.Merijn Brand" <h.m....@xs4all.nl> [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 Exporter::Lite is lite'r than Exporter, the use of
> Exporter is zero, while Exporter::Lite means loading another module,
> and adds another dependency.
>
> And because dependencies are recursive, you inherit it's baggage.
>
> If one dep doesn't work on VMS, now your program doesn't.
>
> And the more dependencies, especially if you are using more than one
> module that does the same thing just because of stylistic differences,
> then it means more problems.
>
> It's not till you hit something like Ricardo's exporter, which does
> some very novel and interesting extra things, that you reach the
> threshold.
>
> It's mostly the same, but if you need the extra parts, then it might be
> worth the extra dependency.
Which is why Graph::Easy will include about 50 lines reinventing
Heap::Binary - it removes the last dependency, uses less memory, is
faster, and it avoids with me dealing with the only other option,
Heap::Simple, because Heap::Simple comes in two flavours, Perl and XS and
_you_ have to choose which to make the dependency, meaning the user
doesn't get a choise other than "needs suddenly a compiler, but is
faster" or "needs still no compiler, but is not much faster than
Heap::Binary".
Anyway, I think that we all agree in principle, but everyone has different
thresholds.
best wishes,
Tels
--
Signed on Wed Apr 5 18:31:08 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"My wife is just a slow brain, running up the bill.." -- Often misheard
song lyrics #149
Tels
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 etc.
> >
> > This to me is the biggest problem. After 6 years, is it finally okay
> > for me to use such exotic features as lexical warnings and lexical
> > filehandles, just to satisfy someone who refuses to upgrade an eight
> > year old installation of Perl?
[snip]
> > I'm trying to figure out why I've been sending patches to p5p for
> > about five years now if people complain when I take advantage of the
> > bugs they fix. At some point, it would be nice if people were to use
> > software released this millennium.
>
> Ever written software for government?
Yes. And I don't know which parts of the mystical government you speak
off, but people everywhere are pretty pissed of when they have to work
with 10 year old software.
Hell, there are problems getting hardware that still runs that old stuff.
> It's routine to be required to offer a 10 year support period.
Yes, but that does not mean that you need to upgrade the installation with
"the-latest-foo-bar-from-cpan-which-just-breaks-on-5.004". You just keep
the system as it is and patch when breakage really occurs. :)
> This comes up more often that you might think.
>
> And so as my gold standard for back-compatability, I use 10 years. A
> decade is a nice round number.
Ugh - but at least we don't have 16 fingers :)
> If it's something that isn't very core'y, I use a secondary support
> period of 5 years.
>
> 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 there.
I wont :)
best wishes,
Tels
--
Signed on Wed Apr 5 18:21:33 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"My glasses, my glasses. I cannot see without my glasses." - "My
glasses, my glasses. I cannot be seen without my glasses."
H.Merijn Brand
> 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 etc.
> > >
> > > This to me is the biggest problem. After 6 years, is it finally okay
> > > for me to use such exotic features as lexical warnings and lexical
> > > filehandles, just to satisfy someone who refuses to upgrade an eight
> > > year old installation of Perl?
> [snip]
> > > I'm trying to figure out why I've been sending patches to p5p for
> > > about five years now if people complain when I take advantage of the
> > > bugs they fix. At some point, it would be nice if people were to use
> > > software released this millennium.
> >
> > Ever written software for government?
>
> Yes. And I don't know which parts of the mystical government you speak
> off, but people everywhere are pretty pissed of when they have to work
> with 10 year old software.
We *only* have local government as customers, and they get *my* perl,
installed in *our* tree. Of course my perl includes defined-or :)
> Hell, there are problems getting hardware that still runs that old stuff.
:)
One customer ran production on a system so old that they didn't dare to
reboot it, because they were affraid it was not going to boot again. OK, that
was 6 years ago, but still, government is a strange customer.
> > It's routine to be required to offer a 10 year support period.
>
> Yes, but that does not mean that you need to upgrade the installation with
> "the-latest-foo-bar-from-cpan-which-just-breaks-on-5.004". You just keep
> the system as it is and patch when breakage really occurs. :)
I don't care if their default perl breaks down. That would be their fault. As
long as they don't break mine. Perl has the advantage of not being tied to
"this product *must* be installed in /usr (and yes, we *do* have a third
party that still sets that requirement for their product), symlinks to the
rescue.
> > This comes up more often that you might think.
> >
> > And so as my gold standard for back-compatability, I use 10 years. A
> > decade is a nice round number.
>
> Ugh - but at least we don't have 16 fingers :)
5.8.3 is the minimum to accept for me, and it should have defined-or
> > If it's something that isn't very core'y, I use a secondary support
> > period of 5 years.
> >
> > 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 there.
>
> I wont :)
me neither
> best wishes,
Adam Kennedy
> 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", as before UNIVERSAL::isa and
> UNIVERSAL::can, I had to deal with way too many bug reports of other people's
> code breaking mine. In other words, it didn't work.
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.
UNIVERSAL::isa and UNIVERSAL::can remain a good idea implemented without
sufficient hubris.
As I've mentioned a few times, a much better option would have been
something like warnings::isacan, to warn about bad calls, but which when
the few of us that NEED to use as a function, knowing exactly what we
mean by using it that way, don't have it magically and forcibly and
mistakenly converted to a method.
And to make matters worse, now there's a warning suppression option, so
they now just magically change the way the code works, potentially
breaking it without warning.
> For example, Template::Toolkit may *never* work with Test::MockObject because
> the author refuses to ask the author of CGI.pm to fix a bug in the latter
> module, despite apparently knowing about it for several years and apparently
> preferring to break my code instead.
Turnabout is not fair play when it comes to bugs.
> I'm not going to release knowingly broken code, just so my broken code can run
> brokenly on really old versions of Perl. What good is that?
I wasn't aware Test::MockObject was fundamentall broken. As far as I was
aware it does the right thing. And if someone uses UNIVERSAL::isa the
wrong way, that's their problem to fix.
And as for the version issue, you should do what you like there, because
you introduced it as a new module. Just make sure the version dependency
is explicit.
Adam K
Chromatic
> 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 possible way that Test::MockObject or Test::MockObject::Extends
could work if someone were to call UNIVERSAL::can() or UNIVERSAL::isa() as a
function on an instance of either class.
By using both modules, I can detect nearly all incorrect uses, work around
them, and warn that the broken code will probably not work correctly and
needs exploration.
How is that not valuable for users of my code?
(I do grant that getting this code right is difficult and my core perl bug
remains unfixed, but I have an idea.)
> And to make matters worse, now there's a warning suppression option, so
> they now just magically change the way the code works, potentially
> breaking it without warning.
The code was already broken. It was *impossible* for Test::MockObject or
Test::MockObject::Extends to work in certain cases. Using UNIVERSAL::isa and
UNIVERSAL::can makes it possible to detect those situations and work around
them, if possible, but at least warn about them.
For people who don't care about the warnings, they have the option of
disabling them.
I welcome legitimate bug reports and test cases to both modules and try to fix
them when possible.
I don't really see the point of warning about a usage but not correcting it.
(Isn't it Python's shell that, when you type Ctrl-d, says "Type 'exit' to
exit."? What's the point in that? I want to exit, you know I want to exit,
and I don't care if you warn -- but don't make me read your mind.
Interactive shells should not be parser-hampered text adventures.)
> > For example, Template::Toolkit may *never* work with Test::MockObject
> > because the author refuses to ask the author of CGI.pm to fix a bug in
> > the latter module, despite apparently knowing about it for several years
> > and apparently preferring to break my code instead.
>
> Turnabout is not fair play when it comes to bugs.
I fail to understand. Should I not fix bugs because someone might rely on the
broken behavior?
Template::Toolkit has a bug. Chris Dolan reported it. I confirmed that it's
TT's problem. Andy won't fix it. I will do all I can to work around it in
Test::MockObject, but I can't fix it without forking Template::Toolkit. The
best I can do is put up in big flashing neon letters, "Hey, there's a bug in
this other code and my code will never work correctly here. Beware."
Again, being explicit when possible when things won't work seems like a big
benefit to users. (Besides, I assume heavily that people won't use
Test::MockObject much outside of tests, where they ought to be able to debug,
well, bugs.)
-- c
Tels
On Wednesday 05 April 2006 20:46, H.Merijn Brand wrote:
> On Wed, 5 Apr 2006 18:30:33 +0200, Tels <nospam...@bloodgate.com>
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 out why I've been sending patches to p5p for
> > > > about five years now if people complain when I take advantage of
> > > > the bugs they fix. At some point, it would be nice if people
> > > > were to use software released this millennium.
> > > Ever written software for government?
> >
> > Yes. And I don't know which parts of the mystical government you
> > speak off, but people everywhere are pretty pissed of when they have
> > to work with 10 year old software.
>
> We *only* have local government as customers, and they get *my* perl,
> installed in *our* tree. Of course my perl includes defined-or :)
:o)
> > Hell, there are problems getting hardware that still runs that old
> > stuff.
> >
> :)
>
> One customer ran production on a system so old that they didn't dare to
> reboot it, because they were affraid it was not going to boot again.
> OK, that was 6 years ago, but still, government is a strange customer.
You will laugh, but the most common hardware failure occurs due to
power-down/power-up cycles. Systems run happy for months, even years,
shut them down, let them cool, boot them up, and the HD, power supply or
mainboard is dead.
That's why you use a lot and big UPS.
Government indeed is strange. Some parts of it can't buy ink for the
printer, let alone a new HD, others blow a million on a new data center.
Usually, both parts sit in the same building :-P
> > > It's routine to be required to offer a 10 year support period.
> > Yes, but that does not mean that you need to upgrade the installation
> > with "the-latest-foo-bar-from-cpan-which-just-breaks-on-5.004". You
> > just keep the system as it is and patch when breakage really occurs.
> > :)
>
> I don't care if their default perl breaks down. That would be their
> fault. As long as they don't break mine. Perl has the advantage of not
> being tied to "this product *must* be installed in /usr (and yes, we
> *do* have a third party that still sets that requirement for their
> product), symlinks to the rescue.
Yeah, but if you install your own Perl, then the modules you use can work
with it, hence there is no requirement for Foo-Bar to actually run under
5.004. That was my main point :D
It's like saying that $LatestGame must run under Win95, just because there
are a few people who insist that they use it.
I hate upgrade cycles as much as everyone else, but even more annoying are
people stuck in the last decade :D
> > > This comes up more often that you might think.
> > >
> > > And so as my gold standard for back-compatability, I use 10 years.
> > > A decade is a nice round number.
> >
> > Ugh - but at least we don't have 16 fingers :)
>
> 5.8.3 is the minimum to accept for me, and it should have defined-or
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?
best wishes,
Tels
--
Signed on Wed Apr 5 23:17:38 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"helft den armen vögeln" -- gegen kleinschreibung
Randy W. Sims
> On 4/4/06, Adam Kennedy <ad...@cpan.org> 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 on Spiffy, so Spiffy needs to go in the core (which
>> isn't what actually happened, but could have)
>
> Actually I thought the decision was that YAML wasnt going in and that
> the MB team would roll their own writer?
Already done by Stephen Adkins, from Changes for 0.27_10:
- We now include our own YAML.pm work-alike that we can use when the
real YAML isn't installed. We might soon even start using it when
YAML is installed, because the YAML API and dependency chain have
been changing in unfavorable ways lately. [Stephen Adkins]
This is the version that is currently in blead perl, so this dependency
problem is resolved.
Randy.
Randy W. Sims
>> 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.
>>>
>>> "dependent only on core modules". This is a comment that I see on a
>>> regular basis.
Yep, that's ridiculous. I used to see these questions a lot back when I
was answering mails on the beginner groups. People wanting to do things
that have already been done and widely tested, but everyone wants to
write their own in order to "reduce dependencies".
Reinventing the wheel is a good learning exercise, but after that it is
a waste of time. At the same time they don't want to require their users
to download 50 modules to use their application, so reducing
dependencies is good to some extent. There is no clear line though,
about how many dependencies are too many and which are trivial.
Different applications of various sizes and complexities will have
different boundaries. Authors have to balance convenience to themselves
and to their users, leaning more toward users of course.
> 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
> other reasons to write their own.
This underlying behavior is one of my biggest pet peeves with the perl
community. Too many people want to go out and write their own version of
modules instead of contributing to the work others began. Diversity is a
good thing, but to me, it's embarrassing that the perl community can't
work together to provide modules. Instead everyone has to reinvent the
same thing over and over, staking their own claim. How big would the
pride of the perl community, CPAN, be if all the redundancy were
removed? (Okay, so it'd still be big, but not as big.)
And, yes, I'm a contributing developer of Module::Build which is an
alternative to an existing module with the same function, MakeMaker. So
I do believe that sometimes it is valuable to re-evaluate existing
modules and try to improve them or replace them when necessary. All
things in moderation. With due deliberation.
On the subject of the modules in core, again despite being a developer
of module that was just placed in core, I'm a hardcore minimalist. *I*
believe that Perl should have only enough to install and manage modules
and to work as evenly as possible across all architectures it supports.
Then maybe have extra bundles such as a developer bundle with debugging
and profiling related modules (not needed by people who just want to run
perl applications); a basic bundle with low level authoring stuff like
basic data structures & algorithms: sets, ties, etc (not useful for all
applications, but fundamental enough to be semi-standardized); a
network/internet bundle, etc. Things like File handling and IPC should
probably remain in core as they contribute to cross-platform development.
Randy.
Demerphq
> This underlying behavior is one of my biggest pet peeves with the perl
> community. Too many people want to go out and write their own version of
> modules instead of contributing to the work others began. Diversity is a
> good thing, but to me, it's embarrassing that the perl community can't
> work together to provide modules. Instead everyone has to reinvent the
> same thing over and over, staking their own claim. How big would the
> pride of the perl community, CPAN, be if all the redundancy were
> removed? (Okay, so it'd still be big, but not as big.)
Well seing as I am responsible for one of these modules ill say that I
didnt mine as a seperate project because I knew that my objectives
were not particularly compatible with Data::Dumper. DD in my opinion
has a broken interface, (The Data method in particular). And it has
specialized constraints on modifying it, like all patches must be
two-fold, one in perl and one in C, or like patches musn't impact
speed particularly.
Anyway, the point is that sometimes it makes sense to reinvent wheels.
> On the subject of the modules in core, again despite being a developer
> of module that was just placed in core, I'm a hardcore minimalist. *I*
> believe that Perl should have only enough to install and manage modules
> and to work as evenly as possible across all architectures it supports.
> Then maybe have extra bundles such as a developer bundle with debugging
> and profiling related modules (not needed by people who just want to run
> perl applications); a basic bundle with low level authoring stuff like
> basic data structures & algorithms: sets, ties, etc (not useful for all
> applications, but fundamental enough to be semi-standardized); a
> network/internet bundle, etc. Things like File handling and IPC should
> probably remain in core as they contribute to cross-platform development.
I agree with this, particularly the last sentence. IMO that is the
type of code that exactly should be in core.
David Golden
> Yep, that's ridiculous. I used to see these questions a lot back when I
> was answering mails on the beginner groups. People wanting to do things
> that have already been done and widely tested, but everyone wants to
> write their own in order to "reduce dependencies".
>
> Reinventing the wheel is a good learning exercise, but after that it is
> a waste of time. At the same time they don't want to require their users
> to download 50 modules to use their application, so reducing
> dependencies is good to some extent. There is no clear line though,
> about how many dependencies are too many and which are trivial.
> Different applications of various sizes and complexities will have
> different boundaries. Authors have to balance convenience to themselves
> and to their users, leaning more toward users of course.
Dependencies also increase maintenance complexity. Since most module
authors are contributing as volunteers, minimizing maintenance demands
is an important consideration. "Core" modules have the advantage of
extensive testing and scrutiny. If I find Whizz::Bang that meets my
needs, I may not want to use it if I'm not sure that (a) it's well
tested or (b) it's well maintained.
There are situations where I may prefer to reimplement something, even
if I might create a new buggy implementation, so as not to make the
quality and maintainability of my code dependent on something I'm not
confident in. At the least, I know that I'll be responsive to my own
bugs -- which, judging from the length of some bug reports on RT, isn't
always the case for Whizz::Bang.
> This underlying behavior is one of my biggest pet peeves with the perl
> community. Too many people want to go out and write their own version of
> modules instead of contributing to the work others began. Diversity is a
I suspect that many of these are API driven. Programming should be fun
and using an API that doesn't "fit" isn't fun. As a result people go
write their own stuff that they feel is easier/faster to use. This is
the flip side of impatience and hubris. E.g. CPAN search found 510
"Simple", 82 "Easy" and 80 "Fast" modules -- not to mention the 49
"Getopt" modules. I don't think that sort of thing is going to change.
David
A. Pagaltzis
>> This underlying behavior is one of my biggest pet peeves with
>> the perl community. Too many people want to go out and write
>> their own version of modules instead of contributing to the
>> work others began.
>
> should be fun and using an API that doesn't "fit" isn't fun.
> As a result people go write their own stuff that they feel is
> easier/faster to use. This is the flip side of impatience and
> hubris. E.g. CPAN search found 510 "Simple", 82 "Easy" and 80
> "Fast" modules -- not to mention the 49 "Getopt" modules. I
> don't think that sort of thing is going to change.
I also don't believe it is particularly specific to Perl. It
seems to me that it is just particularly visible in Perl, because
the high manipulexity and whipuptitude we so enjoy make it quite
feasible to reinvent moderately complex wheels, so people do it.
But it actually happens everywhere.
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
Tels
On Thursday 06 April 2006 13:42, David Golden wrote:
> Randy W. Sims wrote:
[snip a lot of sensible words]
> I suspect that many of these are API driven. Programming should be fun
> and using an API that doesn't "fit" isn't fun. As a result people go
> write their own stuff that they feel is easier/faster to use. This is
> the flip side of impatience and hubris. E.g. CPAN search found 510
> "Simple", 82 "Easy" and 80 "Fast" modules -- not to mention the 49
> "Getopt" modules. I don't think that sort of thing is going to change.
I am at least responsoble for a few of these Simple, Easy and Fast
module :)
But trust me, neither BigInt nor Graph::Easy are re-invents (for different
reasons :D
Best wishes,
Tels
--
Signed on Thu Apr 6 18:35:27 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"We're looking at a future where only the very largest companies will be
able to implement software, and it will technically be illegal for other
people to do so." -- Bruce Perens, 2004-01-23
Tels
On Thursday 06 April 2006 14:59, A. Pagaltzis wrote:
> * David Golden <da...@hyperbolic.net> [2006-04-06 13:45]:
> >> This underlying behavior is one of my biggest pet peeves with
> >> the perl community. Too many people want to go out and write
> >> their own version of modules instead of contributing to the
> >> work others began.
> >
> > I suspect that many of these are API driven. Programming
> > should be fun and using an API that doesn't "fit" isn't fun.
> > As a result people go write their own stuff that they feel is
> > easier/faster to use. This is the flip side of impatience and
> > hubris. E.g. CPAN search found 510 "Simple", 82 "Easy" and 80
> > "Fast" modules -- not to mention the 49 "Getopt" modules. I
> > don't think that sort of thing is going to change.
>
> I also don't believe it is particularly specific to Perl. It
> seems to me that it is just particularly visible in Perl, because
> the high manipulexity and whipuptitude we so enjoy make it quite
> feasible to reinvent moderately complex wheels, so people do it.
> But it actually happens everywhere.
In addition, thanx to the highly central CPAN repository, it is also a
very visible problem. Of the hundred re-inventions for Heap in C, C++ or
C# you never hear anything because you never know they even exist.
Best wishes,
Tels
--
Signed on Thu Apr 6 18:36:47 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
This email violates U.S. patent #6,756,999 <http://tinyurl.com/2vuqm>:
[ [ Konsoles* ] [ Mozilla ] [ KMail ]]
Adam Kennedy
> I suspect that many of these are API driven. Programming should be fun
> and using an API that doesn't "fit" isn't fun. As a result people go
> write their own stuff that they feel is easier/faster to use. This is
> the flip side of impatience and hubris. E.g. CPAN search found 510
> "Simple", 82 "Easy" and 80 "Fast" modules -- not to mention the 49
> "Getopt" modules. I don't think that sort of thing is going to change.
And don't forget, 3 "Tiny" modules :)
Adam K
Adam Kennedy
The problem is that it isn't the behavior that is wrong, only their use
of it.
UNIVERSAL::isa/can when called as a function does a very specific thing,
and one that is often misunderstood.
And if you were able to distinguish between good and bad uses, then fine.
The problem comes that under UNIVERSAL::isa/can there is NO way to
UNIVERSAL::isa/can in the documented way.
If a warning was generated, then at least those people using it for the
correct reason would be able to disable warnings. But that doesn't
happen. And it's going to cause problems down the road, as all this sort
of magic does. It's going to end up interacting in unexpected ways with
someone else's magic and explode.
I keep adding bugs for new more-evil cases as I encounter them, and to
you credit you keep fixing them (that re-entrant bug might be tricky
though) but I can see some time soon we're going to reach a point where
we are going to have bugs that can't be fixed.
If there was a way to have the code that knows what it's doing still be
able to do what they mean work, I wouldn't care so much.
But when you fix the broken cases, you also break the working cases.
That these ways are subtle just means that we aren't going to see them
for a while.
Adam K
Adam Kennedy
> 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 it was that version that fixed the last major Unicode bug.
Something to do with C<join> ?
Adam K
Chromatic
> 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 distinguish between good and bad uses, then fine.
>
> The problem comes that under UNIVERSAL::isa/can there is NO way to
> UNIVERSAL::isa/can in the documented way.
From the documentation in bleadperl:
=head1 EXPORTS
None by default.
You may request the import of all three functions (C<isa>, C<can>, and
C<VERSION>), however it is usually harmful to do so. Please don't do this
in new code.
-- c
Tels
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 5.8.4 minimum whenever it sees any
> mention of Unicode.
Didn't know Perl::MinimumVersion existed :/
> I believe it was that version that fixed the last major Unicode bug.
> Something to do with C<join> ?
The code never says 5.8.4:
$VERSION = '0.11';
# Export the PMV convenience constant
@EXPORT_OK = 'PMV';
# The primary list of version checks
%CHECKS = (
# Various small things
_bugfix_magic_errno => version->new('5.008.003'),
# Included in 5.6. Broken until 5.8
_pragma_utf8 => version->new('5.008'),
_perl_5006_pragmas => version->new('5.006'),
_any_our_variables => version->new('5.006'),
_any_binary_literals => version->new('5.006'),
_magic_version => version->new('5.006'),
_any_attributes => version->new('5.006'),
_perl_5005_pragmas => version->new('5.005'),
_perl_5005_modules => version->new('5.005'),
_any_tied_arrays => version->new('5.005'),
_any_quotelike_regexp => version->new('5.005'),
_any_INIT_blocks => version->new('5.005'),
);
Would be good to find this out. ALso, the changelog mentions "ignore
perlvar", could you please fix it?
Best wishes,
Tels
--
Signed on Fri Apr 7 10:35:40 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"Let's say there are a thousand. But there are 284 million people in
this country. You can't have public policy that is aimed at 100,000
people when the other multi-multi-millions are also involved. You can't
do it that way." - Jack Valenty in http://tinyurl.com/2y65n
David Cantrell
> 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.
I disagree. In particular, I disagree that
Data::Compare::Plugins::Data::Transactional, which uses isa as a
function on a tied and blessed thingy, is incorrect.
Of course, if you feel that it *is* incorrect, I'd welcome a failing test.
Adam Kennedy
Oh really? :)
Here's your acid test, should work on anything that claims to be OO.
my $your_object = (as normal);
my $lookalike = Class::Adapter::Clear->new($your_object);
(your tests as normal)
In fact, if it breaks with Class::Adapter::Clear, which is specifically
designed to make NO change in behaviour in OO code (and thus be usable
as a base class), that also breaks with anything that follows the
Adapter pattern, like Object::Destroyer, or things generated using
Class::Adapter::Builder.
It should also break with the Mock Pattern things like chromatic's module.
Just because I (repeatedly) attack chromatic over UNIVERSAL::isa/can
nobody should be under the impression that using the functions directly
is in any way a good thing.
The only cases for which it's genuinely useful is asking "ignoring what
you say you are in OO terms, what are you actually implemented as
underneath".
Adam K
Demerphq
> Just because I (repeatedly) attack chromatic over UNIVERSAL::isa/can
> nobody should be under the impression that using the functions directly
> is in any way a good thing.
>
> The only cases for which it's genuinely useful is asking "ignoring what
> you say you are in OO terms, what are you actually implemented as
> underneath".
The only advantage I can think of using the function form of isa/can
is that you dont have to do a ref test first. Or if you want to find
out if a module is lying to you about what it isa/can do. But its not
actually that useful to find out how the module is implemented
underneath, nor is that useful for finding out how an object can be
used/dereferenced.
Actually afaik there is no good way to find out what dereferencing
operators an object supports. The best that I know of is reftype(),
but that only tells you the objects underlying intrinsic type, it
doesnt tell you if you can dereference the type other ways.
David Wright
On Fri, 7 Apr 2006, demerphq wrote:
> On 4/7/06, Adam Kennedy <cp...@ali.as> wrote:
>> Just because I (repeatedly) attack chromatic over UNIVERSAL::isa/can
>> nobody should be under the impression that using the functions directly
>> is in any way a good thing.
>>
>> The only cases for which it's genuinely useful is asking "ignoring what
>> you say you are in OO terms, what are you actually implemented as
>> underneath".
> The only advantage I can think of using the function form of isa/can
> is that you dont have to do a ref test first. Or if you want to find
> out if a module is lying to you about what it isa/can do. But its not
> actually that useful to find out how the module is implemented
> underneath, nor is that useful for finding out how an object can be
> used/dereferenced.
Your $thingy could be a hashref, in which case $thingy->isa will die.
I've been using it a lot recently to catch exceptions. What's so wrong
with the below, almost identical to the example in perldoc -f die? I'd
rather not die again immediately by assuming $@->isa will work.
eval {
# do some stuff
};
if ( $@ ) {
if( UNIVERSAL::isa($@, 'My::Exception') ) {
# known exception, handle appropriately
}
else {
die "Ooops-a-daisy: $@";
}
}
--
david
Ricardo SIGNES
> Actually afaik there is no good way to find out what dereferencing
> operators an object supports. The best that I know of is reftype(),
> but that only tells you the objects underlying intrinsic type, it
> doesnt tell you if you can dereference the type other ways.
I actually just ranted about this recently in my journal:
http://use.perl.org/~rjbs/journal/29229
This code should be relatively demonstrative:
sub _CALLABLE {
(Scalar::Util::reftype($_[0])||'') eq 'CODE'
or
Scalar::Util::blessed($_[0]) and overload::Method($_[0],'&{}')
? $_[0]
: undef;
}
--
rjbs
Demerphq
>
> On Fri, 7 Apr 2006, demerphq wrote:
>
> > On 4/7/06, Adam Kennedy <cp...@ali.as> wrote:
> >> Just because I (repeatedly) attack chromatic over UNIVERSAL::isa/can
> >> nobody should be under the impression that using the functions directly
> >> is in any way a good thing.
> >>
> >> The only cases for which it's genuinely useful is asking "ignoring what
> >> you say you are in OO terms, what are you actually implemented as
> >> underneath".
>
> > The only advantage I can think of using the function form of isa/can
> > is that you dont have to do a ref test first. Or if you want to find
> > out if a module is lying to you about what it isa/can do. But its not
> > actually that useful to find out how the module is implemented
> > underneath, nor is that useful for finding out how an object can be
> > used/dereferenced.
>
> Your $thingy could be a hashref, in which case $thingy->isa will die.
Yes, thats what I meant, I should have said blessed() not ref().
> I've been using it a lot recently to catch exceptions. What's so wrong
> with the below, almost identical to the example in perldoc -f die? I'd
> rather not die again immediately by assuming $@->isa will work.
>
> eval {
> # do some stuff
> };
>
> if ( $@ ) {
> if( UNIVERSAL::isa($@, 'My::Exception') ) {
> # known exception, handle appropriately
> }
> else {
> die "Ooops-a-daisy: $@";
> }
> }
Well, the problem with that is as chromatic says: What happens if $@
is an object that is pretending to be a My::Exception (ie, interface
compatible but not isa)? I think he would say it should be rewritten
as
if (blessed($@) and $@->isa('My::Exception')) {
...
}
But the problem with that is blessed() wasnt even core until 5.8.x,
and isn't a true keyword but an exported sub. So you are putting a
dependency on a module that wont always be around.
IMO if the only kind of exception classes involved are your own then
there is no point.
cheers,
Demerphq
My general approach to this is to just ignore it. I dont write or use
parameter validation routines except if the routine could be
potentially harmful. Otherwise I just let Perl handle it. It seems to
me that usually thats a better approach than doing parameter
validation all over the place.
But i can see how the code above could be pretty useful. Say for a
potentially destructive routine that you cant just execute to see if
its executable.
David Golden
> Your $thingy could be a hashref, in which case $thingy->isa will die.
The point of the discussion is that you should be checking if $thingy is
blessed() first, as UNIVERSAL::isa breaks for objects that masquerade as
other objects (e.g. via an adaptor pattern).
> I've been using it a lot recently to catch exceptions. What's so wrong
> with the below, almost identical to the example in perldoc -f die? I'd
> rather not die again immediately by assuming $@->isa will work.
>
> eval {
> # do some stuff
> };
>
> if ( $@ ) {
> if( UNIVERSAL::isa($@, 'My::Exception') ) {
> # known exception, handle appropriately
> }
> else {
> die "Ooops-a-daisy: $@";
> }
> }
Exception::Class now offers the "caught" method so you don't have to use
UNIVERSAL::isa that way. I also wrote Exception::Class::TryCatch for a
little more helpful sugar:
eval {
# do stuff;
};
# catch() upgrades non-object $@ to Exception::Class::Base
if ( catch my $err ) {
if ( $err->isa('My::Exception') ) {
# handle it
}
else {
$err->rethrow;
}
}
Regards,
David Golden
A. Pagaltzis
> Just because I (repeatedly) attack chromatic over
> UNIVERSAL::isa/can nobody should be under the impression that
> using the functions directly is in any way a good thing.
>
> The only cases for which it's genuinely useful is asking
> "ignoring what you say you are in OO terms, what are you
> actually implemented as underneath".
I still wonder what’s bad about using
UNIVERSAL::can( $foo, "can" )
as a pre-Scalar::Util-compatible replacement of
blessed( $foo )
that is, purely as a boolean test where only the truthness of the
return value is of interest but the actual reference is not. This
is the only case for which I ever invoke `UNIVERSAL::can` as a
function. (`UNIVERSAL::isa` I never invoke as a function at all.)
Given that all I’m interested in is the truthness of the return
value, the only scenario in which this would be a dumb idea would
be if
!!UNIVERSAL::can( $foo, "can" ) != !!$foo->can( "can" )
holds. The only way for that to hold given
defined UNIVERSAL::can( $foo, "can" )
is if
!defined $foo->can( "can" )
is true.
In other words, calling `UNIVERSAL::can` as a function would be
bad if `$foo` responds to a `->can` query… claiming that it has
no `can` method.
Which is absurd.
Hence, I cannot see how calling `UNIVERSAL::can` as a function is
harmful for *this one particular specific case* of inquiring
whether or not a reference can respond to `->can`.
Chromatic
> I still wonder what’s bad about using
>
> UNIVERSAL::can( $foo, "can" )
>
> as a pre-Scalar::Util-compatible replacement of
>
> blessed( $foo )
>
> that is, purely as a boolean test where only the truthness of the
> return value is of interest but the actual reference is not. This
> is the only case for which I ever invoke `UNIVERSAL::can` as a
> function. (`UNIVERSAL::isa` I never invoke as a function at all.)
The lack of multimethods with variant return types is what's bad about it. I
trust you to get it right and me to get it right and just about everyone else
on this list to get it right, but without at least a comment and a warning in
the code that this is the only case in which this code has a chance of
working correctly, I worry that it might become example code for other people
who let it escape and mutate into an incorrect form.
-- c
Chromatic
> Actually afaik there is no good way to find out what dereferencing
> operators an object supports. The best that I know of is reftype(),
> but that only tells you the objects underlying intrinsic type, it
> doesnt tell you if you can dereference the type other ways.
eval { dereference_somehow( $thingie ) }
-- c
Demerphq
Sure, thats what i was saying elsewhere too. But I dont consider that
a reasonable solution. Consider if dreferencing it means executing it
and its intended purpose is potentially dangerous.
Chromatic
> > eval { dereference_somehow( $thingie ) }
I realize the zeitgeist on this list has suddenly seemingly turned to
"Installing modules that weren't core in Perl 5.005 is hideous, awful, and
causes barefoot, starving, third-world children to go blind", but then have
you considered roles or traits?
-- c
Adam Kennedy
I don't think anyone considers Scalar::Util something to be avoided.
It's going to be installed, and it's ok to do so. A massive percentage
of CPAN uses it in some way/shape/form.
Adam K