Gee, I love YAML. (Sigh.)
You and me both.
It's at this point I make very quiet noises about YAML::Tiny, and how it
only supports ordinary data, so things like objects and circulars and
other crazy things can't happen.
It's not done yet, but the basics all should work.
You might want
David Golden wrote:
[cc'd to perl-qa for awareness of the issue]
The switch to version objects in Module::Build means that the generated
META.yml now has this:
Is this with or without YAML itself loaded (so I know where to start)?
John
--
John Peacock
Director of Information Research and
Btw, the Module::Build list moved from module-build-
[EMAIL PROTECTED] to module-build@perl.org
Shouldn't somebody disable the old list?
Ray
On Jul 20, 2006, at 7:07 PM, John Peacock wrote:
David Golden wrote:
[cc'd to perl-qa for awareness of the issue]
The switch to version
Is there anything out there that will generate a tree of
dependencies, probably based on META.yml?
I figure I can pass in Mason, Test::WWW::Mechanize and Catalyst and
get back a list of dependencies that those require. It would be the
entire tree, so like so:
Test::WWW::Mechanize
David Golden wrote:
Dropping the exists or changing that to ref $node-{version} makes
it all work just fine.
I'll run a few tests in the AM, using both YAML and the fallback M::B::YAML to
make sure there aren't any other surprises...
(Though technically, it really ought to check that the ref
Le vendredi 14 juillet 2006 à 10:57, Gabor Szabo écrivait:
Hi all,
what is the current best practices for testing code that forks?
I saw there was a recent discussion about patching Test::More
to support forking.
Is that going to happen or are there better ways to do it?
I have tests for
Hi!
On Thu, Jul 20, 2006 at 10:24:49PM -0500, Andy Lester wrote:
Is there anything out there that will generate a tree of
dependencies, probably based on META.yml?
AFAIK there are several people working on stuff like that
(Graph::Dependency, Module::Dependency, CPAN::Dependency, maybe more).
John Peacock schrieb:
David Golden wrote:
Dropping the exists or changing that to ref $node-{version} makes
it all work just fine.
I'll run a few tests in the AM, using both YAML and the fallback M::B::YAML to
make sure there aren't any other surprises...
(Though technically, it really
Steffen Mueller wrote:
John Peacock schrieb:
David Golden wrote:
(Though technically, it really ought to check that the ref equals
Module::Build::Version).
No, that would be wrong too. Never test a ref() against a specific
object
class, since it paints you into a corner with inheritance.
On 7/20/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
use Test::More;
plan tests = my $tests;
{
require_ok( 'MyModule' );
my $obj = MyModule-new();
isa_ok( $obj, 'MyModule' );
}
BEGIN { $tests += 3 }
[snip clever code]
Like Schwern said, this stuff is
I'm beaten over this argument. After a little thought,
I agree with Andy and chromatic that the plan at the end
buys very little and can disturb the simplicity of the testing
API for nothing.
After all, it is very easy to write a code like that
and rewrite our examples.
use Test::More
Thomas Klausner wrote:
Hi!
I've found some tuits to spend on CPANTS, so I changed the whole author
rating thing (aka the CPANTS game).
I've split the metrics into core metircs and optional ones. At the
moment, the only optional metric is 'is_prereq'.
I've also changed the kwalitee rating from
On 20 Jul 2006, at 00:38, demerphq wrote:
[snip]
The whole reason this thread started was that i suggested that test
descriptions be mandatory, as they were in my opinion the best way to
resolve this problem.
[snip]
How about something like:
---
package Test::StrictName;
use Test::Builder;
On Wednesday 19 July 2006 17:08, Salve J Nilsen wrote:
Just a wild thought...
Would it be useful to check for references to community support channels
like mailing lists, IRC channels, public bug trackers and official web
pages?
Interesting idea. One thing I should probably note is that ESR
If I run this script
use Test::More;
plan tests = 2;
BEGIN { use_ok( 'My', 'foo' ); }
ok(1);
is(foo, 1);
I got the output, which says nothing about the use_ok. It is not
counted as a test, it does not ruin the plan, it does its job
(requiring and importing a foo subroutine).
* David Landgren [EMAIL PROTECTED] [2006-07-21 14:55]:
I think the enjoyment of getting that last extra point for 18
Kwalitee far outweighs the anguish due to the decline in mean
Kwalitee when releasing a new module. After all, this decrease
tends towards zero as the number of your released
Hi Adriano,
* Adriano Ferreira [EMAIL PROTECTED] [2006-07-21 15:20]:
If I run this script
use Test::More;
plan tests = 2;
BEGIN { use_ok( 'My', 'foo' ); }
ok(1);
is(foo, 1);
I got the output, which says nothing about the use_ok. It is
not counted as a test, it
On Friday 21 July 2006 19:50, A. Pagaltzis wrote:
Hi Adriano,
* Adriano Ferreira [EMAIL PROTECTED] [2006-07-21 15:20]:
If I run this script
use Test::More;
plan tests = 2;
BEGIN { use_ok( 'My', 'foo' ); }
ok(1);
is(foo, 1);
I got the output, which says
I will never get used to mailing lists that don't default to reply
all...
Begin forwarded message:
From: Joe McMahon [EMAIL PROTECTED]
Date: July 21, 2006 11:43:31 AM PDT
To: A. Pagaltzis [EMAIL PROTECTED]
Subject: Re: Test::More, BEGIN use_ok, plan, what?
On Jul 21, 2006, at 9:50 AM, A.
* Shlomi Fish [EMAIL PROTECTED] [2006-07-21 20:05]:
On Friday 21 July 2006 19:50, A. Pagaltzis wrote:
I assume it’s because, despite the order in the file, the
BEGIN block runs before the `plan tests = 2` line.
Sure looks like a bug.
I don't think that it is. Perl preprocesses the files
How about a stripe for this shit?
http://search.cpan.org/src/SKNPP/Chest-0.082/lib/Chest.pm
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
On Friday 21 July 2006 12:14, A. Pagaltzis wrote:
Of *course* it’s not BEGIN that’s buggy. I was commenting on the
fact that nothing in T::B/T::M screams bloody murder when you run
a test before you’ve declared your plan. Assuming I conjectured
correctly, then if that’s what not a bug, I
On Friday 21 July 2006 12:17, Andy Lester wrote:
http://search.cpan.org/src/SKNPP/Chest-0.082/lib/Chest.pm
Half of that is a valid Scheme program.
-- c
* Joe McMahon [EMAIL PROTECTED] [2006-07-21 20:45]:
On Jul 21, 2006, at 9:50 AM, A. Pagaltzis wrote:
I assume it’s because, despite the order in the file, the
BEGIN block runs before the `plan tests = 2` line.
That's correct; since the plan is invoked separately, the
BEGIN block's already
Andy Lester wrote:
How about a stripe for this shit?
http://search.cpan.org/src/SKNPP/Chest-0.082/lib/Chest.pm
It's been seen before. I think all of DOMIZIO's stuff is written that
way. There was a thread on it on Perlmonks a while back:
http://perlmonks.org/index.pl?node_id=349737
On Jul 21, 2006, at 12:25 PM, Tyler MacDonald wrote:
Andy Lester [EMAIL PROTECTED] wrote:
How about a stripe for this shit?
http://search.cpan.org/src/SKNPP/Chest-0.082/lib/Chest.pm
Kwalitee metric: Package does not depend on Chest.pm. ;-)
I was thinking Author is not batshit insane, but
On Fri, Jul 21, 2006 at 03:10:30PM -0700, Joe McMahon wrote:
On Jul 21, 2006, at 12:25 PM, Tyler MacDonald wrote:
Andy Lester [EMAIL PROTECTED] wrote:
How about a stripe for this shit?
http://search.cpan.org/src/SKNPP/Chest-0.082/lib/Chest.pm
Kwalitee metric: Package does not depend
On Thu, Jul 20, 2006 at 10:24:49PM -0500, Andy Lester wrote:
Is there anything out there that will generate a tree of
dependencies, probably based on META.yml?
I figure I can pass in Mason, Test::WWW::Mechanize and Catalyst and
get back a list of dependencies that those require. It
28 matches
Mail list logo
