On Thursday 13 July 2006 23:37, H.Merijn Brand wrote:
> If I got it right, the wish that was expressed is more like the wish for
> an installer with a GUI.
Nope, just for a nice, easily-installable bundle of modules that work around
the unpleasant backwards compatibilities and warts of Perl 5.
> On Thu, 13 Jul 2006 19:36:52 -0400, "Randy W. Sims" <[EMAIL PROTECTED]>
> said:
> David Wheeler wrote:
>> On Jul 13, 2006, at 05:56, Fergal Daly wrote:
>>
>>> That's funny, it looks like I did put some code in to disable the END
>>> block if it's "require"d rather than "use"d. Tu
On Fri, 14 Jul 2006 01:25:51 +0200, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> * chromatic <[EMAIL PROTECTED]> [2006-07-14 00:55]:
> > Sure, but it's only one thing people need to remember. One
> > thing is easier than N things, especially as N changes every
> > time the core changes.
>
> Yes,
On 7/14/06, Tels <[EMAIL PROTECTED]> wrote:
afte seeing the recent discussion about CPANDB and CPAN::Index, I don't
think I want to work on that project anymore for two reasons:
Hey Tels,
Please ignore the other people in the thread. Instead spend a little
bit of time to do something simple t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Heya Tim,
afte seeing the recent discussion about CPANDB and CPAN::Index, I don't
think I want to work on that project anymore for two reasons:
* announced to early - now everybody tells me how I have to implement it and
why my way wont work
* ano
David Wheeler wrote:
On Jul 13, 2006, at 05:56, Fergal Daly wrote:
That's funny, it looks like I did put some code in to disable the END
block if it's "require"d rather than "use"d. Turns out I did this to
make MakeMaker happy, so MakeMaker does actually do a full require,
Well, IIRC, both Ma
* chromatic <[EMAIL PROTECTED]> [2006-07-14 00:55]:
> Sure, but it's only one thing people need to remember. One
> thing is easier than N things, especially as N changes every
> time the core changes.
Yes, I agree. Don’t get me wrong, I’m not saying Bundle::PerlPlus
is a bad idea (though in addin
On Thursday 13 July 2006 15:40, A. Pagaltzis wrote:
> People would install these modules anyway even if they
> never get into core or a Bundle::PerlPlus, if they knew that
> these modules are important to them in the first place.
That's really the point. Instead of saying, "Go install X and Y an
* chromatic <[EMAIL PROTECTED]> [2006-07-13 23:25]:
> On Thursday 13 July 2006 13:32, A. Pagaltzis wrote:
> >I thought that’s called “the core distribution.” NEXT is
> >already in there. So is List::Util (a big deal for me).
>
> Maybe for Perl 5.9.x... but how long will it be between someone
> rea
On 7/13/06, chromatic <[EMAIL PROTECTED]> wrote:
Why is there not a Bundle::PerlPlus (and yes, I've lathered up my yak with
that name) that downloads and installs the modules that should have been in
the box?
Sure, a Bundle::PerlPlus would be fun. Installing it wouldn't be.
Perl module instal
Wheeling back over to the extra diagnostic output that Schwern
originally proposed, I agree with Adam in that any additions we make
to TAP must be completely backward-compatible.
I hereby recant my burblings. After reading Adam's replies, I think I
might have pushed the thread in the wrong direct
On Thursday 13 July 2006 13:32, A. Pagaltzis wrote:
> I thought that’s called “the core distribution.” NEXT is already
> in there. So is List::Util (a big deal for me).
Maybe for Perl 5.9.x... but how long will it be between someone
realizing "Hey, SUPER should have been in Perl 5 from the start
* chromatic <[EMAIL PROTECTED]> [2006-07-13 21:10]:
> Why is there not a Bundle::PerlPlus (and yes, I've lathered up
> my yak with that name) that downloads and installs the modules
> that should have been in the box?
I thought that’s called “the core distribution.” NEXT is already
in there. So is
wow, my code is being used in a flame war! *blush* :-)
Sorry! I didn't want this to come across as a flame. I just wanted to
make sure I (and other people ;) have the distinction between TAP and
uses of TAP clear in their minds. The sooner we can agree over what the
protocol should call "g
On 7/13/06, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
> are you serious? listen to what they people here are saying - we _all_
> read the raw TAP output, all the time, and not because we're TAP
> developers interested in the underlying implementations. as users, the
> (current) raw TAP diagn
* Tels <[EMAIL PROTECTED]> [2006-07-13 21:50]:
> On Thursday 13 July 2006 19:40, A. Pagaltzis wrote:
> > * Tels <[EMAIL PROTECTED]> [2006-07-12 19:00]:
> > > Using SQLite or similiar is what really creates the
> > > problems with CPANTS - you cant just access the raw
> > > database without the fron
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Moin,
On Thursday 13 July 2006 19:40, A. Pagaltzis wrote:
> * Tels <[EMAIL PROTECTED]> [2006-07-12 19:00]:
> > Using SQLite or similiar is what really creates the problems
> > with CPANTS - you cant just access the raw database without the
> > front-e
I asked "How does a programming language stagnate?" a couple of weeks ago.
Peter Scott responded with wisdom, in particular:
Modules like SUPER and NEXT are pragmata designed to make Perl behave
the way
we (for large values of "we") think it should have behaved to begin with.
Attribut
are you serious? listen to what they people here are saying - we _all_
read the raw TAP output, all the time, and not because we're TAP
developers interested in the underlying implementations. as users, the
(current) raw TAP diagnostics helps us figure out why a test failed, and
if it doesn't
On Thu, Jul 13, 2006 at 02:29:38PM +0300, Gabor Szabo wrote:
> On 7/13/06, Fergal Daly <[EMAIL PROTECTED]> wrote:
> >I could change it so that it tries to figure out whether it's being
> >used for real or not and disable the END block code but that's stress
> >and hassle. As a module author, as far
* Michael Peters <[EMAIL PROTECTED]> [2006-07-13 19:50]:
> And if you use DBD::SQLite you don't even need that. I has
> everything you'd need.
Actually that’s more of a hassle. If you install DBI::Shell you
get close, but having to specify a DSN is still a hassle. With
the SQLite binary you just s
* Smylers <[EMAIL PROTECTED]> [2006-07-13 10:50]:
> When you first suggested those terms earlier in this thread I
> did find that I had to slow down when reading them to work out
> which is which.
>
> I had no such slowdown on reading David Landgren's mail.
Same here.
> I think it's just that "w
On Jul 13, 2006, at 05:56, Fergal Daly wrote:
That's funny, it looks like I did put some code in to disable the END
block if it's "require"d rather than "use"d. Turns out I did this to
make MakeMaker happy, so MakeMaker does actually do a full require,
Well, IIRC, both MakeMaker and Module::Bu
A. Pagaltzis wrote:
> * Tels <[EMAIL PROTECTED]> [2006-07-12 19:00]:
>> Using SQLite or similiar is what really creates the problems
>> with CPANTS - you cant just access the raw database without the
>> front-end.
>
> All you need is one binary from www.sqlite.org – I don’t follow
> why this is
* Tels <[EMAIL PROTECTED]> [2006-07-12 19:00]:
> Using SQLite or similiar is what really creates the problems
> with CPANTS - you cant just access the raw database without the
> front-end.
All you need is one binary from www.sqlite.org – I don’t follow
why this is a problem. And I certainly prefe
On Thursday 13 July 2006 08:52, Jonathan Rockway wrote:
> Nobody reads the raw TAP output!
I would love to see your TAP diagnostic parser and reporter. I, unfortunately,
don't have one and must read the raw TAP output myself. :)
-- c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Moin,
On Thursday 13 July 2006 08:26, Adam Kennedy wrote:
> Tels wrote:
> > The DB backend shouldn't matter at all, it should be transparent and be
> > switchable without any noticable change at the front.
>
> Yep, right with you. Hence DBIx::Class.
On 13/07/06, Geoffrey Young <[EMAIL PROTECTED]> wrote:
Jonathan Rockway wrote:
> While I agree with David, this argument is almost completely pointless.
> Nobody reads the raw TAP output!
are you serious? listen to what they people here are saying - we _all_
read the raw TAP output, all the tim
Jonathan Rockway wrote:
> While I agree with David, this argument is almost completely pointless.
> Nobody reads the raw TAP output!
are you serious? listen to what they people here are saying - we _all_
read the raw TAP output, all the time, and not because we're TAP
developers interested in th
While I agree with David, this argument is almost completely pointless.
Nobody reads the raw TAP output! If you want your TAP harness to
display "got" and "expected", let it. If you want it so say "foo" and
"bar" (so they line up :-P), then great.
The actual TAP is going to live in a protoc
On 13/07/06, Smylers <[EMAIL PROTECTED]> wrote:
Fergal Daly writes:
> On 12/07/06, Smylers <[EMAIL PROTECTED]> wrote:
>
> > I have this one-liner as ~/bin/pmv:
> >
> > #! /bin/sh
> > perl -m$1 -le 'print '$1'->VERSION || die "No VERSION in '$1'\n"'
>
> These all fail for modules that do interest
Fergal Daly writes:
> On 12/07/06, Smylers <[EMAIL PROTECTED]> wrote:
>
> > I have this one-liner as ~/bin/pmv:
> >
> > #! /bin/sh
> > perl -m$1 -le 'print '$1'->VERSION || die "No VERSION in '$1'\n"'
>
> These all fail for modules that do interesting things. For example
> Test::NoWarnings perf
On Thu, 13 Jul 2006 14:29:38 +0300, "Gabor Szabo" <[EMAIL PROTECTED]> wrote:
> On 7/13/06, Fergal Daly <[EMAIL PROTECTED]> wrote:
> > I could change it so that it tries to figure out whether it's being
> > used for real or not and disable the END block code but that's stress
> > and hassle. As a m
On 7/13/06, Fergal Daly <[EMAIL PROTECTED]> wrote:
I could change it so that it tries to figure out whether it's being
used for real or not and disable the END block code but that's stress
and hassle. As a module author, as far as I'm concerned, if MakeMaker
can figure out my version then my job
On 12/07/06, Smylers <[EMAIL PROTECTED]> wrote:
David Wheeler writes:
> On Jul 12, 2006, at 03:41, Gabor Szabo wrote:
>
> >perl -MModule -e'print $Module::VERSION'
>
> I have this alias set up:
>
> function pv () { perl -M$1 -le "print $1->VERSION"; }
Along similar lines, I have this one-line
David Wheeler writes:
> On Jul 12, 2006, at 03:41, Gabor Szabo wrote:
>
> >perl -MModule -e'print $Module::VERSION'
>
> I have this alias set up:
>
> function pv () { perl -M$1 -le "print $1->VERSION"; }
Along similar lines, I have this one-liner as ~/bin/pmv:
#! /bin/sh
perl -m$1 -le 'prin
demerphq wrote:
On 7/13/06, David Landgren <[EMAIL PROTECTED]> wrote:
[...]
>> They strike me as the teams most intuitively recognizable and least
open
>> to misinterpretation.
I choose to disagree.
If so i think you might be disagreing with yourself. :-)
That was a quote of Smylers agre
On 7/13/06, David Landgren <[EMAIL PROTECTED]> wrote:
demerphq wrote:
> On 7/12/06, Smylers <[EMAIL PROTECTED]> wrote:
>> David Landgren writes:
>>
>> > Expected and actual has a long tradition in scientific endeavour,
>
> And are still sucky as they are different lengths meaning the two
> output
demerphq wrote:
On 7/12/06, Smylers <[EMAIL PROTECTED]> wrote:
David Landgren writes:
> Expected and actual has a long tradition in scientific endeavour,
And are still sucky as they are different lengths meaning the two
outputs are offset on the screen making it harder to see the failure.
Y
On 7/13/06, Smylers <[EMAIL PROTECTED]> wrote:
demerphq writes:
> On 7/12/06, Smylers <[EMAIL PROTECTED]> wrote:
>
> > David Landgren writes:
> >
> > > Expected and actual has a long tradition in scientific endeavour,
>
> And are still sucky as they are different lengths meaning the two
> output
demerphq writes:
> On 7/12/06, Smylers <[EMAIL PROTECTED]> wrote:
>
> > David Landgren writes:
> >
> > > Expected and actual has a long tradition in scientific endeavour,
>
> And are still sucky as they are different lengths meaning the two
> outputs are offset on the screen making it harder to
On 7/12/06, Smylers <[EMAIL PROTECTED]> wrote:
David Landgren writes:
> Expected and actual has a long tradition in scientific endeavour,
And are still sucky as they are different lengths meaning the two
outputs are offset on the screen making it harder to see the failure.
They strike me as
David Landgren writes:
> Expected and actual has a long tradition in scientific endeavour,
They strike me as the teams most intuitively recognizable and least open
to misinterpretation.
Smylers
43 matches
Mail list logo
