On 4/4/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> * demerphq <[EMAIL PROTECTED]> [2006-04-04 08:05]:
> > Personally i think the "core is too big" argument is a
> > red-herring given that bandwidth is as cheap as it is these
> > days. Adding a couple of modules to core would increase the
> > rsyn
On 4/4/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> I want to see File::HomeDir ultimately in there, because there's a
> number of things that use $ENV{HOME} and implement their own special
> case logic.
If it presents a platform independent way to find a home dir then I
agree with you.
> You wa
chromatic wrote:
On Tuesday 04 April 2006 21:57, Adam Kennedy wrote:
Seeing as the worst support cases are about 10 years in a variety of
countries and situations, I think that is what we should be aiming for
for highly used CPAN modules.
Which last time I checked is now 5.005.something
So I
Tels wrote:
On Tuesday 04 April 2006 01:35, Sébastien Aperghis-Tramoni wrote:
My current $work is to write a Perl program that must execute on about
1200 Linux servers, with Perl versions ranging from 5.004 to 5.8. I
can't upgrade Perl on these because they have different kernel / glibc
/ gcc v
# New Ticket Created by Allison Randal
# Please include the string: [perl #38850]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38850 >
When you pass a non-existent option to the "get_options" method in
Getopt::Obj, it
Ricardo SIGNES wrote:
Could you elaborate on this? As stated, it seems pretty ludicrous to me. It
reads like this:
> [snip]
This can be further distilled to:
There's more than one way to do it, but most of them will get you dirty
looks.
I'd go further. I firmly believe that "there
demerphq wrote:
On 4/4/06, David Landgren <[EMAIL PROTECTED]> wrote:
I don't think bandwidth is the argument.
I was under the impression it was.
Believe it or not, there are programmers who still use modems. This is
usually because they live in the third world, such as Pennsylvania or
Scot
David Cantrell writes:
> rsnapshot (for example) has its own code for traversing a directory
> tree, its own cut-down Memoize, and probably a few others that I've
> not found yet.
>
> That said, I don't want to see those things go into the core, because
> I'm in the "the core is too big already"
On Tue, Apr 04, 2006 at 11:27:07AM +0200, Sébastien Aperghis-Tramoni wrote:
> I don't think that the problem of "core is too big" is a matter of disk
> size, but more a matter of number of modules. P5Porters time is a scarce
> ressource, and they already lack the time to do all the work they'd
> l
On Wed, 5 Apr 2006 14:20:15 +0100, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 04, 2006 at 11:27:07AM +0200, Sébastien Aperghis-Tramoni wrote:
>
> > I don't think that the problem of "core is too big" is a matter of disk
> > size, but more a matter of number of modules. P5Porters time
* "H.Merijn Brand" <[EMAIL PROTECTED]> [2006-04-05T02:39:20]
> I'll just mention two things, both very different
>
> A. CORE modules are tested on all supported architectures, while CPAN modules
>do not give that guarantee. The smoke system still causes all possible
>combinations to be tes
Smylers wrote:
David Cantrell writes:
rsnapshot (for example) has its own code for traversing a directory
tree, its own cut-down Memoize, and probably a few others that I've
not found yet.
That said, I don't want to see those things go into the core, because
I'm in the "the core is too big alr
Smylers wrote:
David Cantrell writes:
rsnapshot (for example) has its own code for traversing a directory
tree, its own cut-down Memoize, and probably a few others that I've
not found yet.
That said, I don't want to see those things go into the core, because
I'm in the "the core is too big al
On 4/5/06, Ricardo SIGNES <[EMAIL PROTECTED]> wrote:
> That said, I don't dispute the point that it can be wildly obnoxious when
> "Something::Trivial" requires DBD::MySQL and Data::Dump::Streamer when it
> could
> use neither -- or at least rely on AnyDBM and Data::Dumper. It will just
> meant
On Apr 5, 2006, at 9:06 AM, David Landgren wrote:
perl -MModule::CoreList -le 'print Module::CoreList->first_release
($_) for @ARGV' File::Find Memoize
5
5.007003
(um, that can no doubt be golfed, but you get the picture).
Yes, it can:
% corelist File::Find Memoize
File::Find was first re
On Wednesday 05 April 2006 02:02, Adam Kennedy wrote:
> But it's also why UNIVERSAL::isa/can and people adding higher-version
> dependencies below their existing lower-dependency modules is bad.
>
> The code used to work just fine, and now it doesn't.
This is a strange definition of "work just fi
* demerphq <[EMAIL PROTECTED]> [2006-04-05T10:23:45]
> On 4/5/06, Ricardo SIGNES <[EMAIL PROTECTED]> wrote:
> > That said, I don't dispute the point that it can be wildly obnoxious when
> > "Something::Trivial" requires DBD::MySQL and Data::Dump::Streamer when it
> > could use neither -- or at leas
Moin,
On Wednesday 05 April 2006 06:43, Adam Kennedy wrote:
> Ricardo SIGNES wrote:
> > * "H.Merijn Brand" <[EMAIL PROTECTED]> [2006-04-04T10:40:39]
> >
[sniplots]
> But there's very little point in using Exporter::Lite because 100 other
> modules use Exporter in any given program.
>
> So even tho
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,
Author: larry
Date: Wed Apr 5 10:19:49 2006
New Revision: 8561
Modified:
doc/trunk/design/syn/S03.pod
Log:
Clarified identity and trivial properties for too-short reduce ops.
Modified: doc/trunk/design/syn/S03.pod
=
On Wed, 5 Apr 2006 18:30:33 +0200, Tels <[EMAIL PROTECTED]> wrote:
> Moin,
>
> On Wednesday 05 April 2006 06:57, Adam Kennedy wrote:
> > chromatic wrote:
> > > On Tuesday 04 April 2006 10:32, Tels wrote:
> > >>There is also the point that supporting ancient Perls means you
> > >>can't use all the
chromatic wrote:
On Wednesday 05 April 2006 02:02, Adam Kennedy wrote:
But it's also why UNIVERSAL::isa/can and people adding higher-version
dependencies below their existing lower-dependency modules is bad.
The code used to work just fine, and now it doesn't.
This is a strange definition of
On Wednesday 05 April 2006 14:09, Adam Kennedy wrote:
> And now in return, we have new modules that changes the way EVERYBODY
> else's code works, and changes the meaning of that code instead, so
> Test::MockObject gets less spurious bug reports.
You mischaracterize the situation.
There is no po
Moin,
On Wednesday 05 April 2006 20:46, H.Merijn Brand wrote:
> On Wed, 5 Apr 2006 18:30:33 +0200, Tels <[EMAIL PROTECTED]>
wrote:
> > Moin,
> > On Wednesday 05 April 2006 06:57, Adam Kennedy wrote:
> > > chromatic wrote:
> > > > On Tuesday 04 April 2006 10:32, Tels wrote:
> > [snip]
> > > > I'm
Author: allison
Date: Wed Apr 5 15:24:24 2006
New Revision: 12125
Modified:
trunk/docs/pdds/clip/pddXX_exceptions.pod
trunk/docs/pdds/clip/pddXX_io.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
A few PDD tweaks.
Modified: trunk/docs/pdds/cli
In: docs/pdds/clip/pddXX_exceptions.pod
As with the I/O PDD, this isn't a final form, it's just a draft to
seed discussion. What's missing? What's inaccurate? What's accurate
for the current state of Parrot, but is something you always intended
to write out later? What thoughts have you had
Author: larry
Date: Wed Apr 5 15:37:22 2006
New Revision: 8562
Modified:
doc/trunk/design/syn/S03.pod
Log:
Got rid of identity and trivial properties in favor of MMD definitions.
Modified: doc/trunk/design/syn/S03.pod
=
Author: larry
Date: Wed Apr 5 15:38:24 2006
New Revision: 8563
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S05.pod
doc/trunk/design/syn/S06.pod
Log:
Documented grammatical categories.
Modified: doc/trunk/design/syn/S02.pod
==
Author: larry
Date: Wed Apr 5 16:21:23 2006
New Revision: 8564
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
Log:
Additional clarifications on how to reduce non-infix ops.
Modified: doc/trunk/design/syn/S02.pod
===
Author: larry
Date: Wed Apr 5 16:30:06 2006
New Revision: 8565
Modified:
doc/trunk/design/syn/S03.pod
Log:
More clarification of how reduce is parsed.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/s
Author: larry
Date: Wed Apr 5 16:37:32 2006
New Revision: 8566
Modified:
doc/trunk/design/syn/S03.pod
Log:
Typo, plus explicate [.foo] meaning.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.
Author: autrijus
Date: Wed Apr 5 18:36:02 2006
New Revision: 8567
Modified:
doc/trunk/design/syn/S03.pod
Log:
* Prefix sigil casters $ @ % & now joins the other prefix
unary operators, such as \ ~ + *, on the 4th level of
precedence table.
Modified: doc/trunk/design/syn/S03.pod
=
Author: autrijus
Date: Wed Apr 5 18:59:00 2006
New Revision: 8568
Modified:
doc/trunk/design/syn/S03.pod
Log:
* S03: Excise the "reference" word; "array reference" is now
simply Array objects, and prefix * can flatten hashes
as well as arrays.
Modified: doc/trunk/design/syn/S03
Author: autrijus
Date: Wed Apr 5 19:08:28 2006
New Revision: 8569
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S05.pod
Log:
* S02/S05: Excise "reference" from them.
Modified: doc/trunk/design/syn/S02.pod
==
Author: autrijus
Date: Wed Apr 5 19:18:40 2006
New Revision: 8570
Modified:
doc/trunk/design/syn/S04.pod
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S09.pod
doc/trunk/design/syn/S10.pod
doc/trunk/design/syn/S12.pod
Log:
* S04/S06/S09/S10/S12: Excise "reference" from them.
M
demerphq wrote:
On 4/4/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
Module::Build wants to go in, but because they use YAML for the data
file, we add Ingy's YAML.pm, who then decides he wants to use Test::Base
for everything he does, so that slips in undernearth, and of course
Test::Base is based
H.Merijn Brand wrote:
demerphq wrote:
Also, there is a tension in the community relating to this issue that
i dont think we will see any resolution of soon.
Many module authors set a design objective of making their modules
"dependent only on core modules". This is a comment that I see on a
r
Author: autrijus
Date: Wed Apr 5 21:20:13 2006
New Revision: 8571
Modified:
doc/trunk/design/syn/S02.pod
Log:
* Damian noted that the S02 chunk about Code object doesn't
quite make sense anymore; fixed the grammar and supplied
two examples.
Modified: doc/trunk/design/syn/S02.pod
> "a" == autrijus <[EMAIL PROTECTED]> writes:
a> Sigils are now invariant. C<$> always means a scalar variable, C<@>
a> an array variable, and C<%> a hash variable, even when subscripting.
a> -Array and hash variable names in scalar context automatically produce
a> -references.
a
> "a" == autrijus <[EMAIL PROTECTED]> writes:
a> -The C is expected to return a reference to an inner
a> -container object of the proper sort (i.e. a variable, subroutine,
a> -or method reference), or to a proxy object that can "autovivify"
a> -lazily, or undef if that name is not to
Author: autrijus
Date: Wed Apr 5 22:15:15 2006
New Revision: 8572
Modified:
doc/trunk/design/syn/S02.pod
Log:
* S02: Grammar fixes from Uri.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod
Author: autrijus
Date: Wed Apr 5 22:30:44 2006
New Revision: 8573
Modified:
doc/trunk/design/syn/S02.pod
Log:
* S02: fix the three places where the old form:
$x .(...)
needs to be replaced to the new form:
$x. (...)
Modified: doc/trunk/design/syn/S02.pod
=
Author: autrijus
Date: Wed Apr 5 22:38:07 2006
New Revision: 8574
Modified:
doc/trunk/design/syn/S02.pod
Log:
* S02: use sane (and valid) examples for rule_mod_internal and
rule_mod_external grammatical categories.
Modified: doc/trunk/design/syn/S02.pod
===
On 4/6/06, Randy W. Sims <[EMAIL PROTECTED]> wrote:
> 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,
44 matches
Mail list logo
