from:"Michael G Schwern"

On 2012.4.10 2:52 PM, Mike Doherty wrote:
 On 12-04-10 05:20 PM, Paul Johnson wrote:
 On Tue, Apr 10, 2012 at 12:20:20PM -0700, Michael G Schwern wrote:
 2. Should use_ok() be discouraged in the documentation?

 I'm very much in favour of this.
 
 I don't see any discouragement in the documentation...

We're discussing adding that discouragement.


 and what's wrong with use_ok to begin with?

That was the second half of my post.  It's a lot of extra work for a version
of this that doesn't work quite right...

use Foo::Bar;
pass Loaded Foo::Bar;

And the pass() is just informational.  If Foo::Bar fails to load the test dies
which is a failure.


 I typically use_ok(...) or BAIL_OUT. If that's the only way to use
 use_ok safely, then maybe it should do that for you automatically.

It cannot be a bail out, because there's nothing which says the module being
loaded is THE CRITICAL MODULE on which the whole test suite hangs.

It could die, but that introduces even more compatibility issues than the
lexical change.  And it still leaves the problem of having to remember to wrap
it in a BEGIN block for it to truly emulate use properly.


Aristotle Pagaltzis said pagalt...@gmx.de
 I think the ideal way to handle `use` would be a `bail_on_use_failure`
 switch that intercepts `use` errors and turns them into BAIL_OUT,

Implementing this involves putting in a $SIG{__DIE__} and all the fun that
entails.  Test::Builder got rid of its $SIG{__DIE__} to avoid interfering with
other code.

And it cannot be a bail out for the reasons above.


 Then `use_ok` would just completely deprecated.

I don't think it needs to be deprecated in the issue a warning sense.  It's
not actively harmful to use, if its working for you go ahead and use it, it's
just kinda useless and not worth the effort of maintaining.  I don't think
it's worth the effort to change all the hojillions of test suites that use it.
 Documentation and a decision not to add more features should be enough.


-- 
ROCKS FALL! EVERYONE DIES!
http://www.somethingpositive.net/sp05032002.shtml

Re: Revert use_ok() change to allow lexical effects?

On 2012.4.10 6:21 PM, The Sidhekin wrote:
 * How would you rewrite a test script such as my own
 http://cpansearch.perl.org/src/EBHANSSEN/Test-Trap-v0.2.2/t/00-load.t so
 that it does not use use_ok()?

  use Test::More tests = 1;

  use Test::Trap::Builder::TempFile;
  use Test::Trap::Builder::SystemSafe;
  SKIP: {
  skip 'Lacking PerlIO', 1 unless eval use PerlIO; 1;
  require Test::Trap::Builder::PerlIO;
  Test::Trap::Builder::PerlIO-import;
  }
  use Test::Trap::Builder;
  require Test::Trap
  or BAIL_OUT( Nothing to test without the Test::Trap class );

  diag( Testing Test::Trap $Test::Trap::VERSION, Perl $], $^X );
  pass(Test::Trap loaded successfully);

Or a slimmed down version, recognizing that Test::Trap loads all the above
already and will tell you just which module failed to load.  It also makes the
test black box.

  eval {
  require Test::Trap;
  Test::Trap-import;
  1;
  } or BAIL_OUT(Test::Trap failed to load);

  diag( Testing Test::Trap $Test::Trap::VERSION, Perl $], $^X );
  pass(Test::Trap loaded successfully);

This can be boxed up in a module.  There's already Test::Requires.  It skips
instead of bails, it would be a good target for test_must_have() or something
that bails.


 * Why would you? :-\

Because it reads like normal Perl and doesn't rely on more code to do
something rather simple: load a module.

TAP (the ok 1 stuff) has us very much convinced that we need to output
something for every assert.  The rest of the testing universe relies on
exceptions to tell them something's failed and seems to get along just fine
with that.

But quite honestly, if use_ok() works for you, if all you need is require +
import + test, continue to use it.  I don't plan on eliminating it.


-- 
Hating the web since 1994.

Re: Revert use_ok() change to allow lexical effects?

On 2012.4.11 7:35 AM, Andy Lester wrote:
 So is there ANY legit use for use_ok()?

Yes.  Sometimes you want to conditionally test if a module can be loaded and
its import does not blow up.

It's a convenience function so it can be more easily understood what's going
on and we don't each write it a million different ways.  require_ok() solves a
big chunk of the problem.

if( something something ) {
use_ok 'Foo';

#   Here's one long hand way...
#   require_ok 'Foo';
#   ok eval { Foo-import; 1; } or diag $@;

#   or maybe this, hope you remember that 1;
#   eval 'use Foo; 1;' or diag $@;
}

Similar to how like() is basically a convenience for...

my $regex = qr/bar/;
ok $foo =~ $regex or diag $foo does not match $regex;

If it didn't already exist, it could probably be argued that it's not needed.
 But it's there and can be left alone.


-- 
87. If the thought of something makes me giggle for longer than 15
seconds, I am to assume that I am not allowed to do it.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: Revert use_ok() change to allow lexical effects?

On 2012.4.11 9:39 AM, Andy Lester wrote:
 In this example:
 
 BEGIN {
 use_ok( 'App::Ack' );
 use_ok( 'App::Ack::Repository' );
 use_ok( 'App::Ack::Resource' );
 use_ok( 'File::Next' );
 }
 diag( Testing App::Ack $App::Ack::VERSION, File::Next $File::Next::VERSION, 
 Perl $], $^X );
 
 it sounds like we're saying that the use_ok() doesn't help at all, and I 
 might as well write
 
 use App::Ack;
 use App::Ack::Repository;
 use App::Ack::Resource;
 use File::Next;
 diag( Testing App::Ack $App::Ack::VERSION, File::Next $File::Next::VERSION, 
 Perl $], $^X );
 
 Agreed?

Yes, exactly.


-- 
I do have a cause though. It's obscenity. I'm for it.
- Tom Lehrer

Re: Revert use_ok() change to allow lexical effects?

On 2012.4.11 9:53 AM, Aristotle Pagaltzis wrote:
 * Michael G Schwern schw...@pobox.com [2012-04-11 18:35]:
 Nope, too much magic for too small a use case.
 
 And faithfully duplicating `use` would be less so? :-)

This discussion is about backing away from that.  The most magical bits of
use_ok() have not yet gone out in a stable and can be reverted.


 I don’t see how it is any more magic than `done_testing`.

done_testing() has no global side effects, it's just a function.

Unless I'm mistaken, Test::AutoBailOut is doing to need a global $SIG{__DIE__}
handler or override CORE::require or add something to @INC or try to parse
exception messages or something like that.  Any of those have global side
effects which can potentially interfere with or be overwritten by the code
being tested.


 What exactly makes you uneasy? Maybe there is a way to address that
 if you can be more specific.

Mostly that it's cramming yet more complexity into core test library for a
fairly narrow use case and functionality that lives quite happily in its own
module.  It's already difficult enough to keep stable.

To reverse it, why should it be in Test::More?  People don't like to have
extra test dependencies is not accepted.  If you want to bundle it all
together into a sort of universal set of testing extensions, Test::Most does 
that.

While it could be argued that every distribution should be testing that their
modules load and bailing out if they don't, the bailing out part we can live
without.  But it is handy.


 It works fine if what you want is a runtime require + import + assert,
 and sometimes you want that.  The problem is it's been overused and
 has come to replace a simple `use` in test scripts.  To that end the
 question is whether to *discourage* its use in the documentation: to
 scale it back from use this when you load a module to use this for
 some special cases.
 
 *Which* special cases? I would rather not recommend it in any case ever.

In my reply to Andy I outlined some cases where you need a runtime require +
import + assert and its better to have a function which does that than write
it all out by hand.


 My suggestion to ship AutoBailOut was so you would be able to suggest it
 as a replacement in the docs, as it covers the one case where `use_ok`
 is even of interest (though still not the right solution).
 
 But I guess you could do that even if it ships outside of Test::More.

Precisely.  For example, it already suggests Test::Differences and Test::Deep.


-- 
185. My name is not a killing word.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: Revert use_ok() change to allow lexical effects?

On 2012.4.11 11:43 AM, Eirik Berg Hanssen wrote:
   If this fails, the test script will terminate immediately:
 
 * I won't get to know if any of the other modules loaded correctly, or how
 they fail.  Less of the interesting output.
 * And there will be no BAIL_OUT, so the rest of the tests will run, burying
 the interesting output.  More uninteresting output.

Like I said, if use_ok() is working for you keep using it.  Your example where
you want to load a bunch of modules just to make sure they compile is one of
those cases where use_ok() is probably the right thing.


  * Why would you? :-\
 
 Because it reads like normal Perl and doesn't rely on more code to do
 something rather simple: load a module.
 
   But it fails to DWIW: report clearly on failures.  Perhaps what it is doing
 is not so simple, after all?

Personally I'm a fan of scroll up and read the first failure.  It always 
works!


-- 
7. Not allowed to add In accordance with the prophesy to the end of
   answers I give to a question an officer asks me.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Revert use_ok() change to allow lexical effects?

2012-04-10 Thread Michael G Schwern

In a series of patches, Father Chrysostomos and I enhanced use_ok() so that it
can apply lexical effects to more closely emulate the real `use`.  For example,

use_ok('strict');

Previously this would just load strict and call import, but strictures would
not actually be applied to your scope.  Now strictures *will* be applied
making it work more like a regular use.

Testing has shown it's caused just a handful of compatibility problems, and it
hasn't gone out in a stable release yet.  Because the new use_ok() is so much
more complex than before I'm having second thoughts about whether it's worth
it and would like opinions.

There are two questions:

1. Should the lexical effect patches to use_ok() be rolled back?
2. Should use_ok() be discouraged in the documentation?

The new use_ok(), while it works remarkably well, is significantly more
complex than previously and it touches magical variables $^H and %^H.  There
is a danger of invoking bugs by touching those variables.

It continues to have compatibility issues, for example...

BEGIN {  use_ok 'Some::Module' }

this will apply lexical effect while...

BEGIN { use strict }

will not but

BEGIN { require strict; strict-import }

will.  Confusing.

use_ok() has low utility to begin with.  If you want exports and lexical
effects to be properly applied you have to wrap it in a BEGIN block.  And as
has been pointed out before, if use_ok() fails you probably want the program
to halt.  So the full invocation should be...

BEGIN {
use_ok(Some::Module) or die;
}

At which point you might as well write...

use Some::Module;

And if you really want the load to be a passing test, you can add...

pass(Loaded Some::Module);

If all you want to do is check that a module can compile, there is the much
simpler require_ok().

Apologies to Father Chrysostomos if his work is reverted, it has been top
notch.  If it is reverted, it may find life in another module where a complete
emulation of use is desired as a user function or method.


-- 
31. Not allowed to let sock puppets take responsibility for any of my
actions.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: Devel::Cover: whence the reference to Class::MethodMaker?

2012-03-14 Thread Michael G Schwern

On 2012.3.14 5:49 PM, James E Keenan wrote:
 On a machine where I can only install libraries underneath my home directory,
 I today tried to install and use Devel::Cover.  After considerable effort, I
 was able to install Devel-Cover-0.79.  But when I went to use it in
 conjunction with 'prove' I got error output like this:
 
 #
 $ HARNESS_PERL_SWITCHES=-MDevel::Cover prove t/001_new.t
 t/001_new..Devel::Cover: Can't open
 blib/lib/Class/MethodMaker/Engine.pm for MD5 digest: No such file or directory
 Devel::Cover: Can't open blib/lib/Class/MethodMaker/scalar.pm for MD5 digest:
 No such file or directory
 Devel::Cover: Can't open blib/lib/Class/MethodMaker/array.pm for MD5 digest:
 No such file or directory
 Devel::Cover: Can't open blib/lib/Class/MethodMaker/hash.pm for MD5 digest: No
 such file or directory
 #
 
 Class::MethodMaker is probably not installed on this machine, and it's
 certainly neither installed underneath my home directory nor used in the
 testing code or the code being tested.  But what's really puzzling to me is
 the fact that I cannot locate the string 'MethodMaker' anywhere in the
 Devel::Cover source code!

Is it possible you had a pre-existing cover_db directory?  Try deleting it.


-- 
emacs -- THAT'S NO EDITOR... IT'S AN OPERATING SYSTEM!

Re: What is the best code on the CPAN?

2012-02-08 Thread Michael G Schwern

On 2012.2.7 6:29 PM, Jeffrey Thalhammer wrote:
 I'm working with a group of Perl developers with various backgrounds and 
 skill levels.
 We have instituted a fairly effective code inspection process, but we still 
 get
 bogged down in debates over what good code is.   Unfortunately, the
developers work
 in isolated silos and spend the vast majority of the time looking only at
their own code.
 So they rarely have an opportunity to see what good (or just better) code
might actually
 look like.

If the silos are eliminated and people have to cooperate and work with each
other, you'll find that the discussions about what is good code become far
more practical and people's attitudes become less provincial.


 So in your opinion, which distribution on the CPAN best demonstrates these 
 qualities?
 Or do you think there are other more important qualities that I should be
looking for?
 I realize there is more than one way to do it, so I don't really expect to
find the
 best code.  I just want something I can hold up as strong example that 
 people
 (including myself) can learn from and aspire to.

At the risk of sounding immodest, with the exception of failing to use other
CPAN modules, because it can't, Test-Simple 1.5 matches your criterion pretty
well.
http://search.cpan.org/~mschwern/Test-Simple-1.005000_002/


-- 
91. I am not authorized to initiate Jihad.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: Reconsidering Mouse in TB2

2011-12-06 Thread Michael G Schwern

On 2011.12.6 1:23 AM, Cosimo Streppone wrote:
 Plus, what would happen if at some point Mouse wanted to
 use TB2 for its test suite?

You might have missed that part of the conversation.  TB2 would not depend on
Mouse, it has its own embedded copy.  It would work fine.


-- 
Clutter and overload are not an attribute of information,
 they are failures of design
-- Edward Tufte

Re: Reconsidering Mouse in TB2

2011-12-06 Thread Michael G Schwern

On 2011.12.6 10:56 AM, Cosimo Streppone wrote:
 I wasn't referring to a dependency problem,
 but to the actual code being the same on the
 thing-that-tests and thing-that-is-being-tested.

It would be a problem if they were the same code, but they're not because
TB2::Mouse is a copy of an earlier released version of Mouse.


 I would tend to avoid this (who controls the controller etc)
 but maybe it's not a problem at all.

That wouldn't be possible because both have good test suites.

Mouse has to pass its test suite to release a new version.
TB2 has to pass its test suite after it embeds a new version of Mouse.

There's no more risk than any other dependency.

However, TB2 would have to be smart and keep the oh, Mouse is installed so
I'll use that logic from kicking in.  That would be a problem.


-- 
THIS I COMMAND!

Reconsidering Mouse in TB2

2011-12-05 Thread Michael G Schwern

As a result of the discussions, I'm now reconsidering using Mouse in TB2.  Its
interesting, it's not for any of the reasons I thought, but for a distressing
encapsulation breech built into Moose.

The main concern is that the fact that we're using Mouse leaks out.  We must
document that we're using Mouse and users must rely on this implementation
detail.  Anything wishing to consume a role must use Mouse.  Anything wishing
to take full advantage of subclassing must use Mouse.

This is a critical violation of encapsulation.  It means TB2 is stuck using
Mouse forever.  I look ahead a few years and see that becoming a severe
limitation.

A side issue is the compile time performance.  While XS fueled Mouse is the
fastest OO implementation, compile time appears to be most critical to Perl
test suite performance.

So, uhh... I'm going to go do a bad thing.


-- 
If you want the truth to stand clear before you, never be for or against.
The struggle between for and against is the mind's worst disease.
-- Sent-ts'an

Re: Need suggestions for terminology

2011-12-02 Thread Michael G Schwern

You might want to crib from BackPAN::Index.  It has a lot of this terminology.


On 2011.12.2 5:21 PM, Jeffrey Thalhammer wrote:
 The context is Pinto, which is yet-another suite of libraries and tools
 for building a private CPAN-like repository.

Does it explode when hit from the rear?  No?  Joke too old?
https://secure.wikimedia.org/wikipedia/en/wiki/Ford_Pinto#Fuel_tank_controversy


 Distribution:  A Distribution is an abstract concept that defines
 relationships between packages.  The minimal concrete implementation
 of a Distribution would be just a META.json (or equivalent) file.
 Distributions also have names and versions like Foo-Bar-1.2

This is what I term a release.

A distribution is the whole Foo-Bar series of releases.  It has a name, a
list of releases, and not much else.  All the real data is associated with a
distribution's releases.  See BackPAN::Index::Dist.

A release is a specific version of a distribution.  It has a CPAN id, date
of release, what distribution it's for, a filename, version, what files are in
it, etc... basically everything that's in the meta file is associated with a
release.  See BackPAN::Index::Release.


 Distribution Archive:  A Distribution Archive is the physical
 manifestation of a Distribution, and corresponds to an actual file on the
 local disk.  For example, /home/jeff/Foo-Bar-1.2.tar.gz or
 C:\MyDocuments\Foo-Bar-1.2.tar.gz

Release archive I guess.


 Distribution Path:  The Distribution Path is how an Archive is identified
 in a CPAN index.  It is basically a URL fragment that looks like
 A/AU/AUTHOR/Foo-Bar-1.2.tar.gz.  This is the term I'm having the most
 trouble with.  CPAN::DistnameInfo calls this the prefix but I don't
 really like that either.

Release path.  I agree that prefix is a poor name.

I would store it as just AUTHOR/Foo-Bar-1.2.tar.gz.  The A/AU/ is an
implementation contrivance and can be calculated.

There is value in having just the filename available separate from the rest of
the path as well.


 Package:  A package is just a package, in the usual way.  That is,
 something declared with the package keyword.

Agreed.


 Module: I actually avoid using the term Module because I think it is
 often misused.  I feel that a Module is a physical file (i.e. something
 that you use).  But some folks use the terms Module and Package
 interchangeably.  To be precise, CPAN (and Pinto) index Packages not
 Modules.  So when you ask cpan[1] to install Foo::Bar, what you actually
 install is an Archive that contains some Module that provides Package
 Foo::Bar, and that Module may or may not be called Foo/Bar.pm.
  At least, that's how I understand it.

Agreed that module is overloaded.  I would associated it either with
the .pm file or with the distribution.  Probably best to avoid it all together.

 Repository: A repository is a general term for any CPAN-like pile of
 files.  This includes CPAN mirrors, as well as any DarkPAN or mini-cpans.
 A repository has a URL that identifies the entry point.  For example:
 http://cpan.perl.org

You might want to record the type of repository, even if there's
only CPAN for now.  It might be worth differentiating CPAN from BackPAN.
 The structure is the same, but one has some CPAN releases and the later as
has all CPAN releases.

For example, if you wanted to pull from Debian or Fedora sources.


 CPAN: *THE* CPAN is http://cpan.perl.org (or wherever PAUSE publishes
 stuff).  *A* CPAN is one of the mirrors that replicate *THE* CPAN.
  A DarkPAN or mini-cpan or Pinto are *not* CPANs.

I'd call it something else, as this can rapidly get confusing.  I'm not sure 
what.


-- 
44. I am not the atheist chaplain.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: TB2::Mouse will be internal use only... with one hitch.

2011-11-30 Thread Michael G Schwern

On 2011.11.30 2:04 AM, David Golden wrote:
 On Wed, Nov 30, 2011 at 12:39 AM, Michael G Schwern schw...@pobox.com wrote:
 There is a 3rd choice, which brings us full circle to where this discussion
 started.  We write TB2::Object [1] to select load Mouse if its available,
 TB2::Mouse otherwise.  That way TB2 classes are compatible with Mouse just in
 time.  They also get a performance kick.

 The core gets the for internal use only marked TB2::Mouse as previously
 discussed.
 
 Without commenting on the rest of the plan, to which I want to give a
 little more thought, it occurs to me TB2 as released to CPAN could
 explicitly depend on Mouse, so that any TB2 installed (or upgraded)
 via CPAN client gets Mouse installed (or upgraded).

Unfortunately, that would be a circular dependency between Mouse and TB2 
unless...

* Mouse never depends on Test::More newer than the one which shipped with
5.8.1 (0.47).

This is a bit much to ask of the Mouse folks.  They're already using 0.88 and
I don't want to make their life harder to make mine easier.

* Mouse bundles Test::More.

A distinct possibility.  You'd put all the .pm files into t/lib and then Cuse
lib t/lib in each test.  Modules used to do this all the time, when we
weren't sure about this whole new fangled Test::More thing and module authors
complained bitterly about having to add a dependency just for testing.


-- 
But there's no sense crying over every mistake.
You just keep on trying till you run out of cake.
-- Jonathan Coulton, Still Alive

Re: TB2::Mouse will be internal use only... with one hitch.

2011-11-30 Thread Michael G Schwern

On 2011.11.30 4:31 AM, David Golden wrote:
 On Wed, Nov 30, 2011 at 6:13 AM, Michael G Schwern schw...@pobox.com wrote:
 Unfortunately, that would be a circular dependency between Mouse and TB2 
 unless...
 
 Not a complete dependency, though, as one can function without the
 other.  As long as the CPAN clients are smart enough not to follow the
 prereq chain endlessly, it might work.

*All* CPAN clients.  This includes package builders, DarkPAN tools, and so on.

Circular dependencies are bad juju.  Putting one at the root of the dependency
tree would be asking for disaster.  It risks breaking the whole automated CPAN
bootstrapping and upgrading process.


 And possibly TB2's
 Makefile could be smart and only add the Mouse prereq if it finds a
 version of itself (or, really, of Test::More) sufficient to meet
 Mouse's prereq needs.  (Bundling might still be easier.)

That might work.

It puts information about Mouse into the Test-Simple distribution.
Information which will change.  It means the two distributions must be coupled
even more tightly.  If Mouse changes its Test::More dep, a new version of
Test::More must be cut immediately if not before the Mouse change.  Very time
sensitive.


 Another idea might be for TB2 to use the new runtime/recomends
 prereq type in v2 CPAN Meta files.

Same problem as a regular prereq as they are resolved before building and
installation.


-- 
10. Not allowed to purchase anyone's soul on government time.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: TB2::Mouse will be internal use only... with one hitch.

2011-11-30 Thread Michael G Schwern

On 2011.11.30 7:20 AM, Ricardo Signes wrote:
 re: internal use
 
 What does internal define here?  What are the boundaries of the space to
 which TB2::Mouse use is internal?

Like any other internal use only .pm file in a CPAN module, it can only be
used by the Test-Simple distribution (Test::Simple, Test::More, Test::Builder,
TB2::Blah...).


 In what scenarios do I have to write something that uses it?

You're patching Test-Simple.


 If I do that, am I likely using Mouse sugar?

Yes.  More than sugar, you're likely uhh... eating meat and potatoes?  I don't
know what the food analogy for roles and attribute default overrides would be.


-- 
Alligator sandwich, and make it snappy!

TB2::Mouse will be internal use only... with one hitch.

2011-11-29 Thread Michael G Schwern

After the discussion, some pondering and hearing from Goro, I've decided that
TB2::Mouse will be marked for internal use only.

1. People are uncomfortable that I'm shipping a copy of Mouse::Tiny,
   let alone making it public.

2. If it's private now, it can be made public later.  Can't do it the
   other way around.

3. We don't need it for stable.

4. Mouse is a very easy dependency.  It has no dependencies and can
   work without a compiler.  There's not much value in providing a
   bundled copy.  They can just depend on Mouse.

5. Goro wants it that way.

Except there's a problem.

In order to properly subclass a TB2 module your subclass must use TB2::Mouse.
 You can't use Mouse.  For example.

package My::TAP::Formatter;
use Mouse;
extends 'TB2::Formatter::TAP::v13';

has '+show_tap_version' =
default = 0;

This doesn't work.  Mouse doesn't see the superclass's attributes because they
were declared by a different namespace, TB2::Mouse.  The subclass must use
TB2::Mouse if it wants to override attributes.  I hadn't realized that.  It
also must use TB2::Mouse if it wants to consume TB2 roles.

This offers two choices:

#1 Subclass authors will just have to deal.

#2 TB2::Mouse is available IF AND ONLY IF you are subclassing
   or using a role.

#1 isn't much different from the status quo of subclassing a non-Mo[ou]se Perl
5 OO module... except for the problem of roles.

#2 is effectively publishing it.

This is not academic.  TB2::Event and TB2::EventHandler are roles.  Writing
new Events and EventHandlers are the primary way to extend how TB2 works.
They could be turned into classes, but that would make things more difficult
to extend.

There is a 3rd choice, which brings us full circle to where this discussion
started.  We write TB2::Object [1] to select load Mouse if its available,
TB2::Mouse otherwise.  That way TB2 classes are compatible with Mouse just in
time.  They also get a performance kick.

The core gets the for internal use only marked TB2::Mouse as previously
discussed.

The examples in the TB2 documentation can be changed to always show them using
Mouse, further distancing TB2::Mouse from user eyeballs who might want to
abuse it.

The end result is...

1. The core gets a shrouded copy of Mouse::Tiny, with different
   namespaces, as discussed at the beginning.

2. TB2 gets a performance kick once Mouse is installed.

3. Extension authors can use Mouse to subclass TB2 and consume
   TB2 roles as normal.

4. TB2 continues to be able to take full advantage of Mouse.

Nobody needs to ever know there's a copy of Mouse::Tiny in there.

Thoughts?


[1] I'd probably reverse it so that TB2::Mouse is the selector and TB2::Object
is the Mouse::Tiny copy, but I don't want to make the discussion more
confusing than it is.


-- 
s7ank: i want to be one of those guys that types s/jjd//.^$ueu*///djsls/sm.
   and it's a perl script that turns dog crap into gold.

Re: TB2::Mouse will be internal use only... with one hitch.

2011-11-29 Thread Michael G Schwern

On 2011.11.29 9:49 PM, David E. Wheeler wrote:
 How much slower will this make running the core tests,
 since neither Mouse nor Mouse::XS will every be available
 there (during development, at core installation time).

Doing some back of the envelope calculations, it looks like an extra minute
and a half on my laptop.  I don't know how long core tests take right now.

Running...

use Test::More tests = 1;
pass(ok);

100 times via prove...

With 0.98:  2.2s
With 1.5:   10s

An extra 8 seconds per 100 tests.  There's about 1100 core tests which use
Test::More.  8 seconds x 11 is about 90 seconds.

That's worst case.  I can probably get compile time down at least 20ms which
shaves off about 30 seconds.


-- 
170. Not allowed to defect to OPFOR during training missions.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: Relying more on Mouse

2011-11-24 Thread Michael G Schwern

On 2011.11.22 8:06 PM, David Golden wrote:
 Attributes -- leaving aside types and coercion -- are you just talking
 about the sugar?

Mostly, and the sugar is very helpful, but not all of it.

There's also the potential runtime performance win.  Mouse XS accessors are
significantly faster than pure Perl accessors you write by hand, (Mouse pure
Perl ones are no slower).

It's also handy to be able to list a class' accessors.  This is used to allow
the dumping of the data contents of an Event.  Not strictly necessary, but it
will be handy for the JSON formatter/dumper.


 And I wonder if Role::Tiny could be extended to do multiple roles.
 
 Or could you do a poor-man's version of roles using mix-ins?
 
 I understand the goal of decomposition and why Mo[ou]se rocks, but for
 a testing framework, maybe simpler is better.

I don't think cobbling together an OO system from bits and bobs, and then
relying on it, makes more sense than using a fully baked one.  While
Role::Tiny might load faster, there's no evidence it will compose roles faster.

And there's no evidence loading a bunch of individual OO modules will be any
faster than loading Mouse::Tiny.

Also one of the side benefits of shipping TB2::Mouse is now other Test modules
can rely on it getting the benefit of a fully operational OO system without
adding further dependencies.

Finally, it's a whole lot of regressive work to tear Mouse out.  I'd rather do
some investigation into performance optimizations in TB2 and Mouse first
before we go into writing YET ANOTHER PERL OO FRAMEWORK, whe!

I wonder if I can find an excuse for TB2 to need a template module... ;-)


 For example, Moose will detect method clashes with roles, right?  (I
 assume Mouse does that.)  Do you really need that?  Or could you
 verify the design by hand rather than relying on a MOP to do the
 work for you?

I actually don't know.  I sure don't need it.  But this presumes that's where
the performance problem is.


 How much of it is fundamental to what you're trying to do and how much
 of it is just making life easier for you in implementing it?  Granted,
 well tested Mouse might be less buggy than hand-rolled replacement,
 but a special-purpose class framework could possibly be simpler (thus
 faster and less buggy).

None of it is fundamental.  All of it is making life easier.


-- 
Reality is that which, when you stop believing in it, doesn't go away.
-- Phillip K. Dick

Re: Relying more on Mouse

2011-11-24 Thread Michael G Schwern

On 2011.11.23 12:15 AM, Eric Wilhelm wrote:
 Was there some work in Moose to generate and load pre-cooked classes for 
 startup-time basics like the accessors and roles?  It seems like being 
 able to do that work once during `make` would be a big win.

I think that was wrt pre-cooking Moose's meta stuff, but if the attributes
could be pre-compiled that would be awesome.


-- 
Alligator sandwich, and make it snappy!

Re: Relying more on Mouse

2011-11-22 Thread Michael G Schwern

On 2011.11.22 11:22 AM, David Golden wrote:
 On Tue, Nov 22, 2011 at 2:02 PM, Eric Wilhelm enoba...@gmail.com wrote:
 Is there a way to remove some of the work Mouse is doing at startup?
 What is it doing?
 
 How much of Mouse is needed?  Could Moo be used?  (I ask without
 having read the details of the OO breakdown of TB2)

No.  Moo has runtime dependencies, is harder to bundle (multiple files), is
not upward compatible with Moose (their type system is incompatible), lacks
Moose types, a class can't use more than one role at once, and has no meta
system.  And it's slower at runtime.

I'm also not convinced of Moo's stability.  Mouse has strictly adhered to
being a subset of Moose.  Moo hasn't.  The Mouse folks have said they'd test
vs Test::Builder2.  Finally, Moo has only existed for a year.

About the only advantage is Moo loads about 10ms faster than Mouse/XS.

The major Mo[ou]se features that Test::Builder2 uses heavily is roles and
attributes.  It also uses types, coercion, meta classes and method modifiers,
but those could be removed if necessary.  I've tried to keep it simple to
avoid touching any actual or potential Mouse bugs.


-- 
There will be snacks.

Re: Relying more on Mouse

2011-11-22 Thread Michael G Schwern

On 2011.11.22 11:02 AM, Eric Wilhelm wrote:
 By being THE testing framework, it places an upper bound on how fast
 anyone's tests can be.  10 .t files per second, no faster.  That
 sucks.
 
 I agree.  But, with XS mouse, you're only cutting the startup time to 
 0.07s from 0.09s, correct?  And really, 14.3 .t/s also sucks vs the 
 50 .t/s with v0.98, no?

That's before any further optimization is done.  XS Mouse buys us 20ms before
we even start.


 Is there a way to remove some of the work Mouse is doing at startup?  
 What is it doing?

I don't know about Mouse, but I know Test::Builder2 is eating 13ms building up
all the different types of Results at compile time in TB2::Result.  Results
are over-engineered.  I have a not-too-old branch to simplify them.

Some of the time is spent applying roles and generating accessors and there
isn't much to be done about that in Test::Builder2.  Performance enhancements
in Mouse itself would be appreciated by all.

I've added a branch called gonzales which uses Mouse directly.  You can
experiment with that and NYTProf to examine compile time performance issues
yourself.
https://github.com/schwern/test-more/commits/gonzales


 I did once suggest a pre-loading / forking harness (along the lines of 
 Test::Aggregate), though it would probably be much better to make the 
 test code start faster rather than need to work around it.

That's an interesting idea.

FWIW Test::Aggregate should become much easier with Test::Builder2.  Instead
of the shenanigans it goes through to merge tests together, it can just
intercept set_plan events and turn them into subtests or just scrub them out
entirely.


-- 
184. When operating a military vehicle I may *not* attempt something
 I saw in a cartoon.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: Relying more on Mouse

2011-11-21 Thread Michael G Schwern

On 2011.11.21 4:07 AM, David Cantrell wrote:
 But then how often does one need to 'use Test::More'?  Not enough to
 bother optimising it, I'd say.

In every single .t file that gets run by just about everybody.

By being THE testing framework, it places an upper bound on how fast anyone's
tests can be.  10 .t files per second, no faster.  That sucks.


 To take a real-world example, it occurs 182 times in our test suite at
 work, a test suite that takes almost 2 hours to run in full.  Those
 extra 182 * 0.07 == 13 seconds are of absolutely no importance at all.

I run tests a lot while developing.  I can see they're slower without even
benchmarking it.  You wouldn't think you'd notice 70 ms, but you do.

I don't want to give anyone an excuse to not run tests often or not upgrade.


-- 
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml

Re: Relying more on Mouse

2011-11-21 Thread Michael G Schwern

On 2011.11.21 8:30 AM, David Golden wrote:
 My bigger concern would be inclusion of Mouse in core as a dependency,
 since the direction of Perl seems to be to have fewer core modules,
 not more.  I'd run that discussion by p5p/Ricardo before getting too
 tied to Mouse.

Mouse won't be in the core.  TB2::Mouse (a copy of Mouse::Tiny, a single 114K
file) will, marked only for use by testing modules.  This was discussed a long
time ago with the Mouse folks and p5p, it's been the plan for quite some time.
 Neither party wanted Mouse in the core, but they were ok with a copy of
Mouse::Tiny for internal use only.


 Separately -- once the Perl core gets a MOP, maybe this gets
 easier/faster anyway.

Great, with my backwards compatibility requirements maybe I'll be able to use
it in TB3 10 years from now! :-P


-- 
A: Yes.
 Q: Are you sure?
 A: Because it reverses the logical flow of conversation.
 Q: Why is top posting annoying in email?

Re: Dual life t/test.pl?

2011-11-18 Thread Michael G Schwern

On 2011.11.17 4:08 AM, Nicholas Clark wrote:
 1) It's not really my goal to make it distributable as a CPAN module,
but as just something you copy.
 
 It continues to be my goal to reduce the amount of effort needed to support
 the core. Exposing more of the internals runs counter to this.
 
 2) Test::More would lose the benefit of improvements from p5p.

 3) p5p would lose the benefit of improvements from Test::More.
 
 The core is using Test::More for pretty much every core-maintained test
 outside of t/
 
 One of the things I've been working on slowly is trying to turn pretty
 much to every, by removing each impediment in turn.
 
 p5p continues to benefit from Test::More, and certainly I'm grateful for
 your continued work on that. (I assume everyone else is)

Sorry, I think I wasn't clear.  It wasn't meant as a I'm taking Test::More
and going home screed.

I was only commenting on FC's suggestion to fork t/test.pl.  That is, when
Test::More patches its copy of t/test.pl p5p can benefit.  And when p5p
patches t/test.pl Test::More can benefit.  That only works if I keep them in 
sync.


 The library upon which 372 core tests rely is undocumented and untested.
 Moving it into its own repo and tracker allows it to be tested and stable
 without having to go through the p5p memorial bike shed.
 
 That's the entire bloody point. It's not *meant* to be assumed to be stable.
 It's an internal implementation detail of testing the core.

I think this is the key point on which we fundamentally disagree, and we can't
go further without clearing this one up.

If I'm hearing you correctly, your argument is that t/test.pl is internal to
the core and does not need to be documented or tested.  Docs are for
publishing stable APIs.  Tests are for checking regression against those
stable APIs.

My argument is that in order to write tests using t/test.pl, core developers
need to know how to use it.  That's what docs would be for.  What does
fresh_perl() do, what are it's arguments and limitations?  What about
run_multiple_progs()?  display()?  within()?  like_yn()?  That t/test.pl lacks
documentation is a barrier to core developers writing tests.  Just because
it's internal to the core doesn't mean people magically know how to use it.

Tests for t/test.pl have a similar argument.  They make sure that the basis
for our core testing system works and continues to work.  They ensure that
changes to how it works are deliberate and not accidental.

Docs and tests are something t/test.pl needs, dual-life or not.  If we don't
agree on that, then this isn't going anywhere.


-- 
29. The Irish MPs are not after Me frosted lucky charms.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Relying more on Mouse

2011-11-18 Thread Michael G Schwern

Test::Builder1.5 is slow.  How slow?  About 3x slower than 0.98.  Enough to
significantly impact test performance.  For example, Spiffy takes 1 second
with 0.98 vs 3.3s with 1.5.

I deliberately didn't do any profiling or optimization while the design was
coming together.  This avoided spending time optimizing something that might
just be thrown out, and it focused on getting things working.  And while my
policy has always been that performance is not a priority, a 3x drop is
unacceptable.

use Test::More;

pass() for 1..1;

done_testing;

0.98
real0m0.747s
user0m0.726s
sys 0m0.019s

1.5
real0m2.301s
user0m2.271s
sys 0m0.027s

One thing which I know for sure is slowing things down is its use of a pure
Perl Mouse::Tiny.  Test::Builder1.5 has a copy of Mouse::Tiny bundled as
TB2::Mouse.  This both avoids a dependency on Mouse and protects Test::Builder
against Mouse bugs.

Test::Builder 0.98's performance benefits from being a monolithic object which
can quickly grab at it's own guts.  Test::Builder1.5 is well factored out into
objects with attribute accessors.  Pure Perl accessors can't compete with hash
lookups.

But Mouse boosted with XS can.

1.5-gonzales
real0m1.702s
user0m1.675s
sys 0m0.025s

Just switching over to my installed Mouse with XS shaved off a big chunk of
the runtime.  Enough that I'm confident profiling can knock off the rest,
there's a lot of easy fat in there.  I've already lopped it down to 1.368s
with two small changes.

The idea would be to continue to ship a copy of Mouse::Tiny as TB2::Mouse,
that takes care of the dependency loop, but to only use it if a good enough
version of Mouse is not already installed.

To mitigate risk of a new version of Mouse breaking Test::Builder, I'd ask the
Mouse folks to test their releases against Test::Builder1.5.  I think they're
already doing that.

Thoughts?


-- 
60. The Giant Space Ants are not at the top of my chain of command.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Test::Builder 1.5 first alpha

2011-11-17 Thread Michael G Schwern

Gentlemen, start your smokers!
https://metacpan.org/release/MSCHWERN/Test-Simple-1.005000_001

Thanks very much to the contributors who stepped up:
* James E Keenan
* Jason Galea
* Nóirín Plunkett
* Aaron Crane
* chromatic
* Father Chrysostomos
* Larry Leszczynski
* Michael Ludwig
* Mike Doherty
* Pedro Melo
* Shawn M Moore
* Shawn Sorichetti

I'm going to go sleep for a while now.

1.005000_001  Thu Nov 17 01:38:53 PST 2011
This is the first alpha release of what has been termed Test::Builder1.5.
It is Test::Builder implemented with the Test::Builder2 internals
(formatters, event system, etc...).  Aside from thread support, it is
feature complete and supports all existing features of Test::Builder,
Test::Simple and Test::More.

Tests should continue to work as written.  Please report any breakages
at https://github.com/schwern/test-more/issues/

Incompatible Changes (since 2.00_07)
* A lot, too many to list.  If you were using an earlier alpha,
  all bets are off.

Incompatible Changes (since 0.98)
* The test output format has changed in small ways.  A later release
  will provide the means to format the output just like 0.98 does now.


-- 
THIS I COMMAND!

Re: Task: Write a TAP v12 formatter for Test::Builder1.5

2011-11-16 Thread Michael G Schwern

On 2011.11.16 4:19 PM, James E Keenan wrote:
 Should we proceed on the assumption that this specifies v12?
 
 http://testanything.org/wiki/index.php/TAP_specification
 
 ... and that this specifies v13?
 
 http://testanything.org/wiki/index.php/TAP_version_13_specification

No, not for our purposes.  YAML diagnostics are not implemented.

I thought about it some more, and the v12/v13 split isn't what we're really
going for here.  Rather than calling it the v12 formatter, it should more
properly be called the legacy or TB1 formatter.  It's not so much about
producing TAP v12 as it is replicating what Test::Builder currently outputs.

I can break the issue into two parts.

Write a v12 TAP formatter (really v12 this time).  This will serve as an easy
way to split the formatter into extensible pieces, as all the code currently
lies in TAP::v13.  This is really straightforward.
https://github.com/schwern/test-more/issues/219

Write the legacy formatter as a subclass of TAP::v12.  This mostly involves
putting the strings TAP uses into attributes and making a subclass of TAP::v12
which changes those defaults.
https://github.com/schwern/test-more/issues/215


-- 
184. When operating a military vehicle I may *not* attempt something
 I saw in a cartoon.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Subtests work! New alpha imminent.

2011-11-16 Thread Michael G Schwern

Subtests are now 100% operational in Test::Builder1.5.

It slipped in place very nicely with the new event system, which makes me very
happy, and it's much simpler than it used to be.  The only vestige of the old
system I had to retain was tracking TODO tests since that's still done in the
Test::Builder object.

Thank you Ovid and others for writing such excellent and comprehensive tests.

Before the next alpha can go out, I just have to finish merging from master
and do a handful of major class/method name changes so early adoptors don't
get screwed again next alpha.
https://github.com/schwern/test-more/issues?milestone=5

It looks like Jason Galea stepped up and did the refactorings.  There's just
one small one left.  I'd appreciate a taker.
https://github.com/schwern/test-more/issues/210

Then I can collapse with the flu while you all knock around the alpha.


-- 
170. Not allowed to defect to OPFOR during training missions.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Smoker setup to compare old vs new versions?

I'd like a smoker setup which can do two things:

1) Run smokes for all the Test:: modules.
2) Compare the results between two different installed versions of Test::More.

This will allow me to smoke Test::Builder 1.5 against CPAN, see what it's
broken and try to fix it.

I've never used the CPAN smoker software before and I'm hoping somebody has a
recipe?

Thanks.


-- 
package Outer::Space;  use Test::More tests = 9;

Re: TAP - Test::More - fork

On 2011.11.15 1:01 AM, Buddy Burden wrote:
 I did not know this ... just to be super-clear, obviously I know that
 if I have script.pl and it starts with
 
 #! /usr/bin/perl -w
 
 and I make it executable and run it directly, I get perl -w.  But
 you're saying that even if I type:
 
 perl script.pl
 
 I _still_ get perl -w?  That, I was not aware of.

Yep.

Now, want to have your mind blown?

$ cat ~/tmp/test
#!/usr/bin/python

def hello():
  print Hello world!
  return

hello();

$ python ~/tmp/test
Hello world!

$ perl ~/tmp/test
Hello world!


 Adding -w to the #! line on your tests is a very good idea to avoid the
 gotcha of differences between a test being run with `prove` (does not set
 -w), ...
 
 Well, yes, prove doesn't _normally_ set -w, but if you run prove -w,
 it does, doesn't it?

Yes.

If you don't set it in #! you, or somebody else, will forget to pass -w to
prove and then you'll spent a bunch of time scratching your head wondering why
the test is running differently from in make test.


-- 
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml

Re: Problem with running lots of tests (I think)

On 2011.11.15 1:14 AM, Buddy Burden wrote:
 Okay, just to follow-up in case anyone cared what the resolution on
 this one was, changing the loop full of ok()s to one giant pass() or
 fail() per loop fixed _everything_.  Plus it runs a lot faster now.  I
 know I've seen test suites that do thousands and thousands of tests,
 but they must be doing it some other way that I'm not privvy to or
 somethin'.

There is a 3rd option.  The perl core maintains a separate implementation of
Test::More in t/test.pl.  You can drop that into your project and use it for
your enormous tests.  It does not record test results, that I know, and should
not consume memory.

I use it to test Test::More and am considering spinning it out into its own
project.


-- 
94. Crucifixes do not ward off officers, and I should not test that.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: Discuss change of namespace Test::Builder2 - TB2?

On 2011.11.15 6:40 AM, Leon Timmermans wrote:
 I'm not seeing the point really. By this logic we can reduce all
 frameworks on CPAN to some three letter acronym. To be honest I don't
 think Test::Builder is used directly often enough to justify that.

Test::Builder was just one monolithic module.  It isn't any more.  There's
lots of pieces now.

People who develop Test modules that do interesting things will be typing it
more often.  People who don't won't even know anything has changed, so they're
not really a concern.


Elliot Shank uttered:
 I'm against abbreviation; it makes things harder to read.  Your
 text editor's completion mechanism should take care of having to
 typing out long names.

When you make them up on the spot and use them twice, abbreviations are bad.
When you repeat it 1300 times in the project... folks will figure it out.

While I agree good editor skills are good, and I have a crappy editor isn't
an excuse, getting an editor to autocomplete Perl class names is non-trivial.
 It gets into TAG files and having the editor be aware of the whole project
and parsing Perl correctly and guh.

I don't know how to do it.  I don't expect contributors and users to know or
have a copy of Perl Hacks.


-- 
101. I am not allowed to mount a bayonet on a crew-served weapon.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Task: Write a TAP v12 formatter for Test::Builder1.5

I have an important task for getting Test::Builder 1.5 stable.

Test::Builder 1.5 outputs TAP version 13.  There are minor formatting changes
including a TAP version header and changes to the ending commentary.

A lot of tests look at this output and so they break.  Rather than make
everybody change their tests (and have to upgrade their Test::More
dependency), I'd rather provide a legacy TAP formatter that outputs like
Test::Builder currently does.  Then folks can switch it on in their tests, and
Test::Builder::Tester will use it by default.

That's the task.  Write a TAP version 12 formatter.
https://github.com/schwern/test-more/issues/215
https://github.com/schwern/test-more/wiki/Preferred-workflow

It's a mildly difficult task, mostly because the v13 formatter does things
which really should be done in a superclass, but it's way easier than trying
to do it in Test::Builder 0.x.

If anyone would like to take it on, please say so in the ticket and we'll try
to get things off the ground.

Thanks.


-- 
164. There is no such thing as a were-virgin.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: Discuss change of namespace Test::Builder2 - TB2?

2011-11-14 Thread Michael G Schwern

On 2011.11.14 12:41 AM, Philippe Bruhat (BooK) wrote:
 I'm more annoyed with the version number being part of the name.
 Even if I can understand the reason why (CPAN only knows one way to
 upgrade: up).

I used to be with you there.

I've since found it's a remarkably simple and foolproof way to indicate an API
split.  The name, code and docs are neatly delineated.  It works with all
existing CPAN tools.  Both API versions can exist in harmony.  The name change
tells the user this is not their father's Kansas.

Besides, tee bee two rolls off the mouth nicely and TB:: is a bit too short.


-- 
I have a date with some giant cartoon robots and booze.

Dual life t/test.pl?

2011-11-14 Thread Michael G Schwern

Having a parallel and featureful testing system is very useful.  I use it to
test Test::More (in the Test-Builder1.5 branch).  Others might find it useful
to do the same.

t/test.pl is very important to the Perl core tests, but it is largely
undocumented and untested.  Going through the p5p process to patch it makes
working on it difficult and open to bike shedding.  If it were dual-lived it
could be worked on as its own thing with its own commits and tests.

By having a dedicated feed of issues and commits, careful attention could be
paid to what code and features are going in.  Close attention and discussion
can happen about whether the code is simple enough and the features apt for
the needs of the core.

If folks are cool with that, I can set up a Github repository for it.  We'll
worry about whether CPAN release is appropriate later.

The starting set of collaborators would be picked from the folks who use it
and patch it and want a commit bit.


-- 
24. Must not tell any officer that I am smarter than they are, especially
if it's true.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: The end of 5.6 is nigh!

2011-11-13 Thread Michael G Schwern

On 2011.11.13 8:39 AM, Reini Urban wrote:
 I've come around your hammering lately and had this idea:
 
 Cannot CPAN add logic to avoid downloading your new versions on older 
 releases?

Yes, but it is non-trivial.

It would requiring creating a new index which supplies modules and versions
for every release (aka tarball and zip) instead of just the latest one.
Various folks are working on that, it is a key piece of missing information.

And then you need another index of what the minimum version of each release
is... if it's declared.

And traverse the module's dependency tree to pick the newest version that is
compatible.

And hope all dependencies are compatible.

And then you have to pray that's something like reality.

There have also been approaches which use CPAN testers data to select the last
compatible version.  Contact Dave Cantrell about that.

There is my CPANgloss.com project to provide this as a service, but it is not
operational.


 5.6.2 still is the fastest perl around. As long as you keep making it
 slower and fatter you have to come up with some kind of practical
 solution.

If you're not completely satisfied with your free software, you get TRIPLE
your money back!

Ya know, I'll bet DOS would run pretty fast on a modern machine...


-- 
Life is like a sewer - what you get out of it depends on what you put into it.
- Tom Lehrer

The end of 5.6 is nigh!

2011-11-12 Thread Michael G Schwern

It's that time again!  Time when I hammer the last few nails in the coffin of
a version of Perl.

By which I mean, the next major release of Test::More (aka Test::Builder1.5)
will support 5.8.1 and up.  ExtUtils::MakeMaker will probably go that way,
too.  This effectively cuts off most of CPAN from 5.8.0 and down.  This will
happen in the next few months.

Test::More might nudge its requirement a little higher depending on just how
difficult it is to work around early threading bugs in the earlier 5.8 releases.

At this point I don't imagine this will cause too much disruption.  There
aren't many serious 5.6 users left and whomever is left has to have already
come up with some sort of 5.6PAN solution.

Dropping 5.6 will ease maintenance and testing of these modules and make a
greater baseline of core modules available.  However, if a company or
organization would like to see 5.6 compatibility retained, they can contact me
about sponsoring the extra work for continued maintenance.

Thanks to Sarathy and rgs for some great and long lived releases!  It's been a
good eight years.

Schwern
  Slayer of Pseudo-Hashes
  Defender of Lexical Encapsulation
  Destroyer of Perl Versions

Re: TAP - Test::More - fork

2011-11-11 Thread Michael G Schwern


On 2011.11.10 7:44 PM, chromatic wrote:

On Thursday, November 10, 2011 at 05:57 PM, Michael G wrote:

If you don't want global warnings, explicitly turn them off with BEGIN { $^W
= 0 }.


I thought the argument that test modules should set global policy unilaterally
died out when I made Test::MockObject *not* enable UNIVERSAL::isa and
UNIVERSAL::can by default.


That argument happened well after Test::Harness was written to set -w.  If 
nothing else, it's a major compatibility issue.




It's the 21st century. Why can't Test::Harness find a nice middle ground and
respect the lexical encapsulation of warnings introduced in 2000? (I think it
just might catch on.)


We're discussing how to deal with the reality and smooth over the existing 
differences between the various ways to run a test.


If you want to crack open the -w in testing discussion, start another thread 
and lay out your argument.



--
Whip me, beat me, make my code compatible with VMS!

Differences between make test and prove (was Re: TAP - Test::More - fork)

2011-11-10 Thread Michael G Schwern


On 2011.11.10 7:15 AM, H.Merijn Brand wrote:

Yes, there indeed is a core

(gdb) where
#0  0xc0258c70:0 in free+0x1d0 () from /usr/lib/hpux64/libc.so.1
#1  0x4017f7e0:0 in Perl_safesysfree () at util.c:262
#2  0x400d0ab0:0 in perl_destruct () at perl.c:871
#3  0x4009a740:0 in main () at perlmain.c:119

I however do not understand why prove seems to be safe, but make test
is not


First, try to replicate everything make test is doing with prove.

For starters, even though test processes are supposed to remain separate, 
other tests could be interfering and the segfault only happens when you run 
the whole test suite.  So run the whole test suite.


prove -wbr t

I see you're firing off child processes, if you're doing the same in the 
previous test it could be that they're not finished from the previous test 
starts.  It could be that your database is in a bad state.


The second major difference is make test sets the PERL_DL_NONLAZY flag which 
is helpful for XS testing, so add that into the mix.


PERL_DL_NONLAZY=1 prove -wbr t

If that doesn't work, go the other way.  Strip out everything you can, 
including prove, and start adding things in.  When you want verbose test 
output, don't use prove -v, just run the program.


perl -w -Mblib t/21-uni-regex.t

If that doesn't replicate, try adding in subtle things which are different 
between 'make test', 'prove' and running manually.


Try having STDOUT go to a pipe instead of a TTY.

perl -w -Mblib t/21-uni-regex.t | cat

Try the same for input.

echo | perl -w -Mblib t/21-uni-regex.t

Try both.

echo | perl -w -Mblib t/21-uni-regex.t | cat

Or it could be that prove is setting environment variables which Test::Harness 
is not, check them.  They could be affecting your shell command.



--
124. Two drink limit does not mean first and last.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: TAP - Test::More - fork

2011-11-10 Thread Michael G Schwern


On 2011.11.10 4:59 PM, Buddy Burden wrote:

chromatic/Merjin,


Not use warnings but the -w command line flag -- the non-lexical, warnings-
on-everywhere one.



no change whatsoever. I've now added -w to all #! lines in the t files


Does that do anything?  I didn't think prove respected the shebang
line.  Anyway, I thought the -w to prove would be effectively doing
that all along.


Perl respects the *options* on the #! line, prove only adds to them.

Adding -w to the #! line on your tests is a very good idea to avoid the gotcha 
of differences between a test being run with `prove` (does not set -w), `make 
test` (sets -w), and running it as a normal Perl program (does not set -w).


If you don't want global warnings, explicitly turn them off with BEGIN { $^W = 
0 }.

Re: What does t/test.pl do?

2011-11-06 Thread Michael G Schwern

On 2011.11.6 5:20 AM, James E Keenan wrote:
 You're absolutely correct that it has no docs.  Some of this is to avoid 
 using
 the inline POD feature, in case it breaks while developing the core.  But it
 could be documented either in comments, or POD in an __END__ block, or (the
 safest) in a separate POD file.  Documenting it, even a little bit, would be
 very helpful.
 
 If I or someone else were to take that on, what should I treat as my starting
 point?  (It's my impression that the t/test.pl in Perl 5.14.2 differs from the
 one in the Test-Builder1.5 branch of your github test-more repository.)

The Perl core is upstream, work on that in blead.  test-more pushes all its
improvements upstream to the Perl core.


-- 
39. Not allowed to ask for the day off due to religious purposes, on the
basis that the world is going to end, more than once.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: What does t/test.pl do?

2011-11-05 Thread Michael G Schwern

On 2011.11.5 5:23 AM, James E Keenan wrote:
 Does anyone actually use t/test.pl?  What does it do?  What is it for?

test.pl has the classic meaning of pl meaning Perl Library not the
bastardized Perl Executable.  It's a simpler, parallel alternative to
Test::More written using simpler Perl features less likely to break.  It has
most of Test::More's API, plus a few tricks of its own.

Its original purpose was back in 2001 when Test::More was a bit more unstable
(so was the Perl core) and testing was not entirely accepted.  Jarkko started
it to use in the most basic perl tests and invoking as few complicated Perl
features as possible.

I co-opted it to test Test::More for similar purposes.  If part of Test::More
broke (and it was rather broken during a lot of Test::Builder2 development)
test.pl would continue to work.  It also resolved the test yourself problem
without complicated hacks.

You're absolutely correct that it has no docs.  Some of this is to avoid using
the inline POD feature, in case it breaks while developing the core.  But it
could be documented either in comments, or POD in an __END__ block, or (the
safest) in a separate POD file.  Documenting it, even a little bit, would be
very helpful.

Mostly it acts like Test::More, but figuring out what the other functions do
will be a matter of looking at the code and also how its used in the Perl core
tests.


-- 
3. Not allowed to threaten anyone with black magic.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: Document the delegator or the delegated?

2011-11-04 Thread Michael G Schwern

On 2011.11.3 8:44 PM, Michael G Schwern wrote:
 When doing delegation I have a documentation dilemma: do the API docs go in
 the delegator or the delegate?

To answer my own question, I've decided to do the best of both worlds.

I will document each object's native methods in it's own .pm file, which is
easiest to maintain.

Then a tool will extract the relevant bits of EventCoordinator's (the
delegate) docs and insert them into TestState's (the delegator) docs.  The
result will be written as TestState.pod which `perldoc
Test::Builder2::TestState` will display before it goes looking in TestState.pm.

I know Pod::Weaver and Pod::Elemental can do this sort of thing, but their
docs are pretty sparse.  Someone want to tackle it?
https://github.com/schwern/test-more/issues/172


-- 
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
-- tchrist in 31832.969261130@chthon

Re: Small pile of Test::Builder 1.5 refactoring tasks

2011-11-03 Thread Michael G Schwern

On 2011.11.2 7:24 PM, James E Keenan wrote:
 On 11/2/11 4:35 PM, Michael G Schwern wrote:
 Here's all the current gardening tasks.
 https://github.com/schwern/test-more/issues?labels=Gardening%2CTest-Builder2sort=createddirection=descstate=openpage=1
 
 I will start to look at these ... but would these be suitable for Google
 Code-In students?

Yes, except GCI will be too late for most of them.  GCI doesn't start until
Nov 21st and runs through mid January.  Most of that needs to be done ASAP.

However, the Gardening and Easy labels can be used as a dynamic set of
tasks for GCI.


-- 
The interface should be as clean as newly fallen snow and its behavior
as explicit as Japanese eel porn.

Document the delegator or the delegated?

2011-11-03 Thread Michael G Schwern

When doing delegation I have a documentation dilemma: do the API docs go in
the delegator or the delegate?

In this case it's Test::Builder2::TestCase which delegates to a stack of
Test::Builder2::EventCoordinator objects.  The user will primarily interact
with TestCase objects.  Only rarely should they ever touch an EventCoordinator
directly.

Do I put all the documentation in TestCase, because that's what the user will
work with, and put a pointer to EventCoordinator?

This presents a unified interface to the user... but it's harder to maintain.
 And if you DO need to use an EventCoordinator it's harder to know which
methods are EC's and which are TestCase's.

Do I document their native methods in their respective classes and point the
TestCase docs at EventCoordinator?

It's inconvenient to the user to have to jump between two class's
documentation to learn how to use one class.  But it is easier to maintain.
It also conveys the true nature of things presenting a more accurate model
(not necessarily more useful).

Meanwhile, I'm going with documenting in place.  It's easier while the API is
evolving.

Hmmm... sectional POD includes anyone?


-- 
Look at me talking when there's science to do.
When I look out there it makes me glad I'm not you.
I've experiments to be run.
There is research to be done
On the people who are still alive.
-- Jonathan Coulton, Still Alive

subtest design in TB1.5

2011-11-02 Thread Michael G Schwern

https://github.com/schwern/test-more/wiki/Subtest-Design

I've decided on a complete design for subtests and written it up, mostly to
get it out of my head before I forget it. :-)  Please let me know what you
think.  Here's a summary...


In short, from a Test::Builder point of view, subtests do two things.

1. Set up a new test state isolated from the parent.
2. Communicate the result of the subtest back to the parent.

Rather than have each EventHandler have a stack, each nested state has its own
EventCoordinator (which contains all the EventHandlers).  A stack of these
coordinators are maintained by a TestState object (which doesn't exist yet)
which delegates to the top of the stack.

When a new test state is created, each EventHandler is asked to make a new
handler for the subtest.  Those are then attached to the new EventCoordinator.
 This isolates the subtest's state.

Communication is accomplished by attaching the subtest's History object to a
subtest_end event and passing this around to the parent's EventHandlers.  They
can do whatever they like with it and have as much information as the subtest 
did.

This design tries to keep as much of the complexity of subtests away from the
EventHandler and Formatter authors.  Ideally an EventHandler does not need to
be aware that it's nested while a Formatter just needs to know how deeply it's
nested.


-- 
emacs -- THAT'S NO EDITOR... IT'S AN OPERATING SYSTEM!

Small pile of Test::Builder 1.5 refactoring tasks

2011-11-02 Thread Michael G Schwern

Designing the subtests made me realize a few things about the event system
that would be better done a little differently.  Mostly renaming things.

It would help me immensely if people could do these refactorings so I can
focus on the design.  They should be straightforward, it's just time consuming.

Here's all the current gardening tasks.
https://github.com/schwern/test-more/issues?labels=Gardening%2CTest-Builder2sort=createddirection=descstate=openpage=1

Thanks!


-- 
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml

Re: Do we need subtests in TAP?

2011-10-31 Thread Michael G Schwern

On 2011.10.30 11:15 PM, Eric Wilhelm wrote:
# from Michael G Schwern
# on Sunday 30 October 2011 20:30:

The current Test::Builder implementation is a mess and its design
cannot go forward. They have to be gotten just right to ensure that
not just nested TAP is supported, but nesting in other formats. Or
if those formats don't have nesting, then linearizing the subtests in
those formats. And event watcher (ie. plugins) authors have to be
shielded from the complexity.

Maybe have a null or default handler for the subtests -- possibly
allowing authors to use a base class or role which gives them a
subtest_start() returning the null handler and subtest_end() which just
forwards the summary as a single test event.

Is there a second format being implemented to test this API?

There's five. TAP v13, POSIX, Null, PlusMinus and SimpleHTML. [1] [2] Of
them all, TAP is the one that's most fleshed out. POSIX has proven most
useful as a disparate format.

I would love to see a formatter for Jenkins/JUnit, [3] that would probably be
the most useful and interesting. I'd also love to see one that just spat out
events as a list of JSON objects [4], useful both for debugging and as a
lossless format for communicating to a harness.

[1]
https://github.com/schwern/test-more/tree/Test-Builder1.5/lib/Test/Builder2/Formatter
[2]
https://github.com/schwern/test-more/blob/Test-Builder1.5/examples/TB2/lib/TB2/Formatter/SimpleHTML.pm
[3] https://github.com/schwern/test-more/issues/158
[4] https://github.com/schwern/test-more/issues/159

--
24. Must not tell any officer that I am smarter than they are, especially
if it's true.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/

Re: Do we need subtests in TAP?

2011-10-30 Thread Michael G Schwern

On 2011.10.30 7:21 PM, David Golden wrote:
 I haven't followed the T::B 2 work closely enough, so could I ask you
 to please step back and explain the benefits of T::B 1.5 that is worth
 stepping backwards in terms of capabilities?  What I mean is that we
 have TAP::Harness now that processes subtest TAP and we have a T::B
 now that produces subtest TAP, so why stop?

I'm not advocating one side or the other just yet.  I'm investigating what
subtests are used for and if they're worth the bother, because I don't use
them.  Ovid always took care of them.

They're a lot of bother, but it looks like it would be even more bother to do
them without nested TAP.

The current Test::Builder implementation is a mess and its design cannot go
forward.  They have to be gotten just right to ensure that not just nested TAP
is supported, but nesting in other formats.  Or if those formats don't have
nesting, then linearizing the subtests in those formats.  And event watcher
(ie. plugins) authors have to be shielded from the complexity.

The end result is looking to be fairly simple, but that doesn't mean a lot of
work didn't go into it.


 This quote from the TB 2 docs scares me a little: Test::Builder2 is
 very generic and doesn't do a lot of the work you've probably come to
 expect a test framework to do. This reduction of assumptions increases
 flexibility and ensures that TB2 can remain the core of Perl testing
 for another decade to come.
 
 That sounds an awful lot like second system syndrome. And -- hey,
 that's great if it works -- I mean no offense is saying that.  But
 something that is *half* of a second system that loses a nice feature
 of the first system seems a suboptimal outcome.

D O N ' T   P A N I C

What you read is about the Test::Builder2 *class*.  The class is separate from
the Test::Builder2 framework.  Sorry if that's not clear.  The framework can
do what Test::Builder does (with the current exception of subtests) and more.

The Test::Builder2 class does a lot less than the Test::Builder class.  I
intended to provide a provide a pack of roles to add in more functionality,
and people could write more.  But I'm not worrying about the Test::Builder2
class right now.  Test::Builder2 is a user friendly shell to generate test
events.  Much of the Test::Builder functionality has been (or will be) pushed
down into event watchers.

Test::Builder 1.5 will use that event system.  The benefit is we can continue
to have a unified testing framework, but write tests using whatever interface
you like and output in whatever format you like.  Plugins which effect the
whole state of the test (such as Test::NoWarnings) become safer to write and
continue to work even as testing styles become different.  You can even write
your own builder.

TB2 is the opposite of the second system syndrome.  The second system is
traditionally overbuilt with too many features that nobody needs.  While the
event system might qualify, the Test::Builder2 class itself does not.


-- 
10. Not allowed to purchase anyone's soul on government time.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: Do we need subtests in TAP?

2011-10-29 Thread Michael G Schwern

On 2011.10.28 12:23 AM, Ovid wrote:
 Echo chamber alert: I've often seen long discussions on this list ignore
 the real world (though often for good reason). In this case, it sounds
 like there's a consideration of removing a feature from TAP.

No, not removing from TAP but removing support for producing it from
Test::Builder.


 I also find subtests so incredibly
 convenient and opens up so many possibilities that I would hate to lose them
 (and I use them a lot).

Do you find *blocks with their own name and plan* convenient, or subtests
which have their own separate test state (as currently implemented)?


-- 
Clutter and overload are not an attribute of information,
 they are failures of design
-- Edward Tufte

Re: Do we need subtests in TAP?

2011-10-29 Thread Michael G Schwern

On 2011.10.28 6:52 AM, David Golden wrote:
 Without looking at the actual code, I would guess that the complexity
 is implementing subtests while preserving the legacy procedural
 interface that wraps calls to a global singleton.

No, that's not really the problem.  It was when Ovid originally implemented
subtests.  In 1.5 the singleton will not contain test state, that will be in
event handlers held by the EventCoordinator.  So the Test::Builder singleton
does not have to change like it currently does.

The problem is all the event handlers need nested state.  Formatters have to
know how to be nested (ex. indentation for TAP or not writing the
header/footer for XML).  History is no longer a linear set of events and
results but a tree.  User written event handlers (Test::NoWarnings is one
example) also have to cope without pushing complexity onto the test module
authors.

And if subtest state is implemented as a new object (which it's looking to be)
then the result of the subtest has to be communicated back to the parent and
assimilated.

I finally have solutions for these which don't suck, but I like to solve
complex problems by eliminating the problem if possible.

So the question is if we need *subtests* meaning a block of tests which is an
entirely separate state or if we just need named blocks with a separate plan?
 This question is orthogonal to the complexity of implementation and it only
applies to what Test::Builder produces, not what TAP::Harness reads.

With the 1.5 architecture changes in test state are now granular events,
rather than it happening all over the place.  Subtests are looking easier than
I thought.


-- 
Whip me, beat me, make my code compatible with VMS!

Re: Do we need subtests in TAP?

2011-10-29 Thread Michael G Schwern

On 2011.10.29 3:51 AM, Fergal Daly wrote:
 It seems like it's impossible then to declare a global plan in advance
 if you use subtests unless you go counting all the sub tests which is
 no fun,

Yes, that's a very good point.

use Test::More tests = 3;

subtest first  = sub { ... };
subtest second = sub { ... };
subtest three  = sub { ... };

The main count remains three no matter how the subtests change.  I just use
done_testing() but for those who like to count tests, it is more convenient.


-- 
Don't try the paranormal until you know what's normal.
-- Lords and Ladies by Terry Prachett

Event handling: One method per event or one method for all?

2011-10-26 Thread Michael G Schwern

tl;dr version:  Is it better for event handlers to have one method per type of
event?  Or one method to accept all events?  Or something else?

Currently event handlers (called EventWatchers) in Test::Builder2 implement
two methods:  accept_event and accept_result.  accept_result() is a special
case to handle results (which are special events) and accept_event() takes
care of everything else.

This means you wind up writing stuff like:

my %event_dispatch = (
stream start  = accept_stream_start,
stream end= accept_stream_end,
set plan  = accept_set_plan,
log   = accept_log,
);

sub accept_event {
my $self  = shift;
my($event, $ec) = @_;

my $type = $event-event_type;
my $method = $event_dispatch{$type};
return unless $method;

$self-$method($event, $ec);

return;
}

Which isn't too bad, but it seems like make-work.

The alternative is for the event handlers to have a method for each event,
(ie. accept_stream_start, etc...) falling back to accept_event if there is no
specific handler.

my $method = type2method($event-event_type);
$handler-can($method) ?
$handler-$method($event) : $handler-accept_event($method);

I chose a single method for all events for two reasons:

1) Speed.  The event coordinator doesn't have to call can() on every handler
and every event.
2) It makes it easy to write a handler that slurps up all events, like the
History object.

It turns out #1 can be made moot with some careful programming.  #2 can be
handled by falling back to a generic handler.

So now the question is one of good event handler design, which I don't have
experience with.  How does one design a good event handler?  Is the pattern
one method per type of event?  Or one method to do the dispatching?  Or
something else?


-- 
Being faith-based doesn't trump reality.
-- Bruce Sterling

Re: Subtest design in Test::Builder 1.5

2011-10-25 Thread Michael G Schwern

On 2011.10.25 12:29 AM, Eric Wilhelm wrote:
 I like the sound of plan B, except for the stores itself in combined 
 with swap me out.

Any specific doubts?


 Can the event coordinator keep a stack?  At the point where the parent 
 handler has to tell the coordinator swap me out, you could have the 
 coordinator providing the functionality which you were thinking of 
 getting from the delegator.

That's an interesting idea.  It certainly could happen.  The two problems are
A) it constrains what an event watcher can do (see below) and B) the subtest
watcher still has to communicate its results back to the parent watcher.

B could be solved by the event coordinator doing the swap and then asking the
subtest history to generate a result event summarizing the subtest.  The
parent watchers (which are now swapped in) will see that.  Come to think of
it, that sort of thing is nice and clean no matter who is doing the swapping.

But I don't see a solution to A.

What the event coordinator could do to help is keep track of the subtest depth
and add that onto events.  Then nothing else has to worry about setting or
tracking that, they just ask the event.


 The code to handle the creating and swapping of a subtest could be put
 in the event handler superclass.
 
 Would that be for convenience of reuse or because an essential part of 
 the API is the freedom to override that method and do it differently?  
 I think putting this in the coordinator would allow fewer surprises.

Both.  For example, I can easily imagine a history or event logger that wants
to record the whole test as a tree.

Part of the point is to provide maximum flexibility to test module authors, so
we're not stuck with design mistakes 10 years later, while still retaining a
system that's easy to use if you do things as expected.


-- 
44. I am not the atheist chaplain.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Subtest design in Test::Builder 1.5

2011-10-24 Thread Michael G Schwern

Subtests are the last major feature hurdle for Test::Builder 1.5.  They're
kind of a hacky mess in Test::Builder 1 which I don't want to bring forward.

A subtest has to

1) create a separate state of the test
2) change the format of the output
3) communicate the result of the test back to the parent

Currently this is done by

1) copying the existing TB singleton
2) creating a new TB object set to indent the output
3) jamming it in place of the TB singleton
4) running the subtests
5) restoring the original singleton
6) the subtest object tells the singleton how it turned out

#3 is necessary because Test modules tend to get the singleton once and
continue to use it, so the subtest object has to use the same object.

In Test::Builder 1.5 the state of the test no longer resides in the
Test::Builder object (this is a white lie, but becoming less so), but rather
in event handlers such as the Formatter and History objects.  This means
subtests can continue to use the same Test::Builder object and the madness is
not necessary.

Instead, subtests would generate 'subtest_start' and 'subtest_end' events
which would be handled by the event handlers.  There's two ways to go on this:

Plan A... each event handler that cares about subtests is actually a delegator
to the real event handler.  When a subtest_start happens...

1) The delegator creates a new instance of the real event handler is created.
2) The old one is squirreled away in a stack.
3) The new handler is told how deeply it's nested.
4) The delegator starts delegating to the newly created handler.

When a subtest_end happens...

1) The delegator communicates the result of the subtest to the first handler
2) The delegator pops the stack and starts talking to the original handler

On the up side, event handlers can be written without having to worry too much
about nesting.  They just need to be able to be nested.  For TAP that just
means indenting the output.  For XML that just means not outputting headers.
All pretty easy.

On the down side, every handler needs a delegator clogging and complicating
things.  While it could be made pretty generic, it's yucky.  I've known it
sucks which has stopped me from doing anything about it.

Plan B... when a subtest_start happens...

1) An event handler creates a new one of itself (the subtest handler)
2) The subtest handler is told how deeply nested it is.
3) The parent handler stores itself in the subtest handler.
4) The parent tells the event coordinator to remove itself and add the subtest
handler instead.

When a subtest_end happens...

1) The subtest handler tells its parent how things turned out
2) The subtest handler tells the event coordinator to remove itself and put
the parent handler back
3) The subtest handler forgets about the parent to avoid a circular dep

I like this because it retains the upside of Plan A, event handlers don't have
to worry too much about nesting, without each event handler having a middleman.

On the down side, the event coordinator needs a swap me out method for event
handlers.  This isn't too hard, I'll just have to add a unique ID method to
event handlers.

The code to handle the creating and swapping of a subtest could be put in the
event handler superclass.

I'm going to code up Plan B, and I'd like to hear people's thoughts on solving
this problem.  Rarely has my first stab at a solution been the right one in
this project.

Thanks for listening.


-- 
Who invented the eponym?

Test::Builder 1.5

2011-10-19 Thread Michael G Schwern

tl;dr/Executive Summary
---
Harvest the internal improvements from Test::Builder2 for Test::Builder
creating a backwards compatible Test::Builder 1.5 which accomplishes the
lion's share of the grant deliverables.  Have a feature complete alpha release
before the end of November.


Background
--
The TPF Grant for Test::Builder2 is due to be shut down at the end of November
along with all the other old style grants which do not have reporting
requirements.  They've been far more than patient.  I have a final crack at
submitting a last report before the end of November to determine some level of
success.


Details
---
After thinking about it some, at this point the most speculative and least
developed part of Test::Builder2 is, ironically, Test::Builder2.  That is, the
backwards incompatible class which replaces Test::Builder as the interface for
test authors.  All the rest: the formatter, results, events, etc... are solid
improvements which can be used by Test::Builder.

This will still introduce alternative formatters and event hooks (except
assert failed).  This gives us things like a safer Test::NoWarnings.  It
also remains possible to write additional builders which work in coordination.

The critical thing Test::Builder2 brought in was stacked asserts.  Those
eliminate the need to play around with $Level and also provide a reliable
assert fail event.  So we don't get that with Test::Builder 1.5... but we
weren't getting that usefully until test modules switched over to TB2 anyway.

The Test::Builder2 branch already has an operational Test::Builder which is
using the new TB2 pieces.  Test::Builder 1.5 would focus on finishing the
conversion of a backwards compatible, improved Test::Builder, rather than
designing Test::Builder2.

The primary hurdles remain the same: supporting threads and subtests in the
new formatter/event model.  It's not hard, it's just work I have to do.

I've set up a milestone with the outstanding 1.5 issues.
https://github.com/schwern/test-more/issues/milestones


-- 
I have a date with some giant cartoon robots and booze.

Re: Multi-Core Tests

2011-07-17 Thread Michael G Schwern

On 2011.7.14 6:00 PM, Eden Cardim wrote:
 It appears there are several distributions on CPAN whose tests don't
 pass when using several cores. This is an annoyance because some of the
 larger deplists nearly always have a module with broken tests in them,
 so testing can't just be a fire-and-forget operation, it also confuses
 some of the less experient developers that have HARNESS_OPTIONS set in
 .bashrc.

Just to make sure, when you say using several cores you mean testing in
parallel?  Like setting the jobs flag (or -j with prove)?


 I'm wondering if there has been any discussion directed to
 addressing this issue, I've done some research and couldn't find
 anything in that regard. What I'm thinking is that maybe the cpan tester
 service can do an extra multi-process run on each distribution, and
 store the test status along with the other metadata and somehow hand
 that information to Test::Harness so it can automatically run in
 single-process mode when it finds a test suite that doesn't pass in
 multi-process mode. Anyway, I'd just like to get the discussion started,
 and I'd be willing to put in some tuits towards implementing a solution
 if necessary.

I don't like work arounds for test failures, and what you're describing is an
enormous work around database.

I think the first step is to report multi-process test failures as normal
bugs.  Especially for the most important modules.  Then they can start to fix
them.

Second step is to set up a CPAN smoker doing multi-process testing.  Then
we'll start getting ubiquitous testing data and annoying distribution authors
with failures.  It will be interesting to see what percentage pass.  I suspect
it is higher than we think.

Moving out of the realm of what you can do today, it may be worth adding a key
to the meta file which indicates the tests are not safe for parallel testing.

I prefer this over the inverse (a flag stating that the tests ARE safe for
parallel testing) because moving forward it would be most efficient for large
scale testing if we encourage authors to make their tests safe for parallel
processing.


-- 
I do have a cause though. It's obscenity. I'm for it.
- Tom Lehrer

Re: post-install testing

2011-04-12 Thread Michael G Schwern

On 2011.4.13 1:50 AM, Jozef Kutej wrote:
 citeIt turned out that there is quite a lot that can go wrong./cite
 
 Found this gem in our internal wiki. :-)
 
 My question is regarding the post-install testing. Normally the test are run
 before installation and then discarded with all the rest of the distribution
 files. But what possibilities do we have about testing of already installed
 code? Is anyone working on this concept?

Are you talking about integrity testing, making sure the system still has all
their pieces and they still work?  Or runtime testing, essentially a
combination of asserts and logging which run from inside the code to check
that the system is internally consistent?

For the former, you can run the shipped module tests on your installed code.
Run them with prove and leave off the -l.  The two issues there is they may
want bits of the source directory, so you're best off running it from the
original source directory.  #2 is the tests might hard code @INC to use the
source library so you'll have to find and knock those out.

You can also write whatever tests you like, using Test::More and friends, and
run them periodically against your installed code.  Just make sure they're not
destructive.

For the latter, there is traditional asserts (Carp::Assert,
Carp::Assert::More), and design-by-contract (Sub::Contract) to start.  I
experimented with putting tests right in the code with Test::AtRuntime.  The
results go to a log file which can then be watched for failures.  It has some
issues: it's a source filter; it will chew up memory needlessly storing test
history; test functions aren't designed to be fast... but the idea is solid.


-- 
184. When operating a military vehicle I may *not* attempt something
 I saw in a cartoon.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: [test-more-users] [ANNOUNCE] Test::Builder2 2.00_06

2011-03-30 Thread Michael G Schwern

On 2011.3.31 10:00 AM, Michael Ludwig wrote:
 Took me a moment to understand that.  Would this cover your need?

 result_like shift @$results, {
 ...
 };
 
 That's very good! But does it mess with $history's results directly?
 Or does $history-result return a shallow copy of the results?

Right now it messes with the directly.  That's ok since that history object is
allocated just for the capture() run.


 If you like it, could I get you to document the concern and technique
 in an EXAMPLES section?
 https://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Builder2/Tester.pm
 
 Yes, you could. If you want me to commit directly, my github login is
 milu71. Else I can send you an email.

How a bout a fork and pull request please?


-- 
100. Claymore mines are not filled with yummy candy, and it is wrong
 to tell new soldiers that they are.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: [test-more-users] [ANNOUNCE] Test::Builder2 2.00_06

2011-03-29 Thread Michael G Schwern

(moving this to perl-qa because we decided to retire test-users)


On 2011.3.30 6:52 AM, Michael Ludwig wrote:
 Michael G Schwern schrieb am 27.01.2011 um 12:09 (+1000):
 use Test::More;
 use Test::Builder2::Tester;

 my $history = capture {
 plan tests = 2;
 is this, that, this is that;
 ok 1, pass;
 };

 my $plan = $history-plan;
 is $plan-asserts_expected, 2;

 my $results = $history-results;
 result_like $results-[0], {
 …
 
 result_like $results-[1], {
 …
 
 I like a nice function syntax that doesn't require a lot of punctuation.
 However, if you add a test to your capture block in a position other
 than at the end, you'll have to update all the array indices, which is
 awkward.

The intention is to mitigate that by making your capture blocks small, but I
hear ya.  Good point.


 Wouldn't it therefore be better to make a closure over the results that
 maintains the array index for you?
 
   my $checker = make_result_checker $history-results;
   $checker-( { 
 is_pass = 0,
 name= this is that,
 file= $0,
   } );
   $checker-( { 
 …
   } );

Took me a moment to understand that.  Would this cover your need?

result_like shift @$results, {
...
};

And it's not hard wired.

If you like it, could I get you to document the concern and technique in an
EXAMPLES section?
https://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Builder2/Tester.pm


-- 
125. Two drink limit does not mean two kinds of drinks.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

[ANNOUNCE] Test::Builder2 2.00_07

2011-02-28 Thread Michael G Schwern

https://github.com/schwern/test-more/tree/v2.00_07

The major change since 2.00_06 is diag() and note() are now hooked into the
event system and the formatters.  They're log events.  See
Test::Builder2::Event::Log for details.  This means test failure diagnostics
can now be controlled along with everything else.

Next is a cleanup of Test::Builder2::Result and adding structured diagnostics.

https://github.com/schwern/test-more/blob/v2.00_07/Changes

2.00_07  Mon, 28 Feb 2011 23:53:22 +1100
Incompatible Changes (since 2.00_01)
* TB2::Event::Log now uses symbolic levels, not numeric.  This lets us
  add new levels later. [github 111]
* Event log levels have been lower cased.
* The emergency and critical log levels have been removed.  They
  didn't have a use case.
* TB2::Event::Log-levels now returns in order from lowest to highest.

New Features
* Added TB2::Event::Log-between_levels() to compare log levels.
* The TAP formatter now respects log events.
* Test::Builder-diag and -note now use log events and the
  formatter.

Documentation
* The suggested meanings of event log levels are now documented.

Bug Fixes
* Fixed a skip() or todo_skip() called before a plan.  [github 132]



-- 
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
-- tchrist in 31832.969261130@chthon

Test::More discussion moved back to perl-qa@perl.org

2011-02-02 Thread Michael G Schwern

On 2011.1.31 11:56 AM, brian d foy wrote:
 In article 4d4492ac.6080...@pobox.com, Michael G Schwern
 schw...@pobox.com wrote:
 
 Do people not care?  Is it going over everyone's heads?  Is everyone just
 waiting for it to be done?  Does it not seem like TB2 is relevant?
 
 I want Test::Builder 2. I'm just full up with everything else I'm doing.

Ok, it sounds like consensus is to come back.  I'll put test-more-users into
archive mode and shut down the commits list (it's redundant with github).


-- 
Look at me talking when there's science to do.
When I look out there it makes me glad I'm not you.
I've experiments to be run.
There is research to be done
On the people who are still alive.
-- Jonathan Coulton, Still Alive

Move Test::More development discussion back to perl-qa?

2011-01-29 Thread Michael G Schwern

When I started Test::Builder2 I gave it its own mailing list so it could have
its own community and not clutter up perl-qa with detailed chatter about
Test::Builder2 and Test::More development.

I don't get much response to posts on test-more-users, though I know people
are subscribed.  perl-qa traffic has dropped off quite a bit.  I'm wondering
that if I moved Test::More and Test::Builder2 posts back to perl-qa that there
would be more discussion?

Do people not care?  Is it going over everyone's heads?  Is everyone just
waiting for it to be done?  Does it not seem like TB2 is relevant?


-- 
87. If the thought of something makes me giggle for longer than 15
seconds, I am to assume that I am not allowed to do it.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

[ANNOUNCE] Test::Builder2 2.00_06

2011-01-26 Thread Michael G Schwern

https://github.com/schwern/test-more/tree/v2.00_06
Apparently the way you make me write code is send me to a Linux conference.

This is the sixth alpha release of Test::Builder2 and it is a big one.  Maybe
not in lines of code, but in concepts.

The major bits are:

The Design Is Working
-

The biggest thing bout this release is that it's all coming together.

The event design is solving old problems and neatly handling new ones.  This
is an excellent indication of TB2's future flexibility.
Test::Builder2::Tester was almost trivial.  Test::Builder is getting simpler
as more of its state handling and logic is pushed down into events.  The
number of issues in the tracker is for the first time falling.  Slightly.


Stable Is In Sight!
---

...through a telescope.  But it's a ground based one!

I've gone through the issues and tagged everything blocking a stable release.
https://github.com/schwern/test-more/issues/labels/Blocking%20Stable

I've created a meta-issue listing the requirements for a stable release.
https://github.com/schwern/test-more/issues/issue/127

* There are no publicly visible bad ideas in Test::Builder2
* Test::More is using Test::Builder2 (complex use case)
  o Demonstrates TB2 and TB1 working together
* DONE All the Test::Builder stuff still works
* DONE A formatter independent Test:: tester is available
* Use cases demonstrations
  o DONE Die/debug on fail (result hooks)
  o Test::Warn/Exception (nested, but independent, asserts)
  o DONE Test::NoWarnings (event hooks)
* CPAN works
  o Except the modules that do evil things to Test::Builder
+ Unless they're really important
  # In which case we'll ensure they're updated for TB2


Test::Builder will work with a non TAP formatter


This was a big blocker to letting all the existing Test:: modules play with
Test::Builder2.

In previous alpha releases, Test::Builder needed to call special methods on
the TAP formatter to preserve existing features.  Now a lot of that
functionality has either been moved into the History (where it belongs so
everybody has it) or TB1 makes them optional (ie. calls them in an eval).


Test::Builder delegates plan state to History
-

This was another blocker to letting existing Test:: modules play with TB2.

Test::Builder was designed as a monolith.  It would track things like details
of the plan, if the plan had been set, etc.  In TB2, things other than
Test::Builder might set the plan.  So TB1 was being very impolite doing its
own tracking.  This tracking has been moved into the History object available
to everyone as Test::Builder2::History-plan.


Test::Builder2::Tester
--

A proof of concept implementation of a Test:: module tester using
Test::Builder2.  It is very small and elegant.  The interface works much like
Test::Tester.

I would really really really appreciate if other people worked on this so I
don't have to.

use Test::More;
use Test::Builder2::Tester;

my $history = capture {
plan tests = 2;
is this, that, this is that;
ok 1, pass;
};

my $plan = $history-plan;
is $plan-asserts_expected, 2;

my $results = $history-results;
result_like $results-[0], {
is_pass = 0,
name= this is that,
file= $0,
# Test::More doesn't do diagnostics this way yet
#   diagnostics = {
#   have= this,
#   want= that,
#   },
};

result_like $results-[1], {
is_pass = 1,
file= $0
};

done_testing;

capture() stores everything which happens in the block in its own history
which it hands back to the user.  You get all the same information which
Test::Builder does.  The actual functions for testing results are currently
lame... but that's ok because you can use any Test:: module you want to test 
them.

This was not planned, but just something which the event design made easy.

(If you run this, it's a bit leaky because diagnostics aren't run through the
formatter yet, but that will fix itself.)


2.00_06  Thu, 27 Jan 2011 09:58:35 +1000
Incompatible Changes
* The EventCoordinator now only has one history object.
  histories() is now history().  clear_history() and add_histories()
  are gone. [github 115]
* Subtest handling has been removed from the TAP formatter.  The design
  was wrong.  It will come back later in a better form [github 120]
* Test::Builder2::Counter, History and Formatter are no longer singletons.
  This is unnecessary, use the objects provided by your EventCoordinator.
  [github 117]
* stream_depth() is now a method on the History object, not the TAP
  formatter.  This makes it available to all event watchers. [github 118]
* history

Test::Builder2::Tester, first cut

2011-01-24 Thread Michael G Schwern

I'm happy to announce the first rev of Test::Builder2::Tester.  It lets you
test Test:: modules without doing string compares on the TAP.  You can test a
much wider array of detail and much simpler.
https://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Builder2/Tester.pm

Here's an example testing Test::Simple ok():

use Test::Simple tests = 2;
use Test::Builder2::Tester;

my $history = capture {
ok 2+2==5, addition;
ok 2*2==4, multiplication;
};

my $results = $history-results;

result_like $results-[0], {
is_pass = 0,
name= addition,
file= $0
};

result_like $results-[1], {
is_pass = 1,
name= multiplication,
file= $0
};

done_testing;

Using Chad's idea, the code being tested is isolated from the rest of the test
inside a capture() block.  This returns the complete history of whatever
happened inside its block.  This includes every test event and result, all the
same information Test::Builder2 uses itself.  result_like() is a convenience
function which will check only the attributes you specify and ignore the rest.

This makes testing a Test:: module much more straight forward and powerful.
Most importantly, it shields the Test:: module from little changes to the test
output format.

TB2::Tester is currently a rough proof of concept.  result_like() doesn't
produce much in the way of useful diagnostics.  results_like() would likely be
more convenient.  It will eventually work with Test::Builder based modules,
but they don't work without a TAP formatter just yet.


-- 
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
-- tchrist in 31832.969261130@chthon

Re: Doubts about TB2 and the TAP stack

2011-01-17 Thread Michael G Schwern

On 2010.10.29 8:36 AM, Pedro Melo wrote:
 All the process got me thinking about Test::Builder. I spent a couple
 of hours tonight trying to see how would I output JUnit with TB2. I
 tried to write a Formatter::JUnit and was mostly successful, but I
 could not see how TB2 ties into the current TAP::Harness stack, that
 powers App::Prove.
 
 I don't know all the pieces that well yet, but seems to me that TB2
 has no need for formatters. Those should be at the Harness level. TB2
 scripts would generate a more robust stream of TAP events, and the
 TAP2::Harness would feed them into one or more formatters to produce
 the file format.

 Right now, I failed to see how would a Harness module would even setup
 a different format for the test scripts, given that the TB2 setup
 happens in a different process space, after a IPC::Open3 call in the
 TAP::Parser::Iterator::Process.

 I'm sure I'm missing something and there is a plan to glue the Harness
 with TB2 formatters. If some kind soul could take a little bit of time
 to point me in the right direction (maybe there is a TAP2 tree
 somewhere?), I could go and look and try to make use of my hacked
 TB2::Formatter::JUnit.

Hi Pedro,
Sorry, this message got lost along the way.  I'm glad you're interested in TB2
and want to put together a JUnit formatter for it.  Lots has changed since
October.  Fortunately it should be a fairly rote change from the old system of
to accepting events.  I'll be glad to help you fix it up for the new event
system and bring your formatter into the fold, but probably as an example
because of the XML::Generator dep.  Or you can release it as its own CPAN
module.  We definitely need a maintained JUnit formatter.

Also you've noticed that Test::Builder really only works with the TAP
formatter due to all the extra methods.  I'm working on tearing them apart.
Test::Builder does use Test::Builder2::Formatter almost completely as of alpha
2.  I still have to make diagnostics work.  And then Test::More will come along.

Now, to whether you're missing something, you're only missing it because it
isn't there.

TAP::Harness explicitly does not know anything about what it's executing
(beyond enough information to execute it).  It just expects TAP.  If you want
to use TB2 tests with a different format you don't use TAP::Harness. [1] Ta da!

What do you use?  Presumably you use whatever test runner wants the
differently formatted output.  Let that run your test programs directly.

This might seem like it's creating a redundant system of formatters... and in
some way it is.  But forcing (for example) a JUnit runner to instead run prove
which then takes test results, translates them into TAP and then translates
them into JUnit is awkward.  There's a lot of information JUnit can't handle
that TAP can, so information is lost in the translation.

Furthermore, TB1 was having difficulty adapting to TAP extensions.  Extensions
to TAP turn into pretty much different formatters, so internally it needed to
exist anyway.

Right now, making a TB2 test program use a different format is awkward.  You
have to do it per script.  There needs to be a way to control this outside the
script, perhaps an environment variable one can set to swap out formatters.  I
haven't been doing much convenience features, more focusing on just getting
the design solid and things working.  It is a SMOP to make your own test
programs respond to an environment variable if you need something now.

In the future, discussions about Test::Builder2 are more likely to be noticed
on test-more-us...@groups.google.com.


[1] Not entirely true.  You could, for example, use
Test::Builder2::Formatter::Multi and attach two formatters, one which outputs
TAP to stdout and another which writes JUnit to a file.  This is handy for
something like Hudson.


-- 
I went to college, which is a lot like being in the Army, except when
 stupid people yell at me for stupid things, I can hit them.
-- Jonathan Schwarz

Re: Test::Deep 0.108 and the future of Test::Deep

2010-10-18 Thread Michael G Schwern

On 2010.10.16 3:29 PM, Fergal Daly wrote:
 I tried to port this import statement to Perl but functions vs methods
 makes a general implementation impossible unless you have knowledge of
 the module being imported. However there's nothing stopping individual
 modules adopting the convention. It's particularly useful if the
 module exports a large and growing number of symbols. So I could
 imagine the follwoing interface.
 
 use Test::Deep2 qw($deep); # import the module as $deep
 
 $deep-is_deeply($foo, $deep-set([1,2,3,4]));
 
 So no namespace pollution but still access to all Test::Deep symbols
 with little typing.

I'm +1 to using this sort of solution for all the fiddly little special
comparison functions, but not the entire interface.

Exporting test functions is fine, they're unlikely to clash and they get used
plenty.  Exporting ninety bazillion little helper functions with names that
are likely to clash and only get rarely used... not so much.  Huffman encoding.

Exporting a $Deep which the user can use for $Deep-re or $Deep-superhashof
sounds like a good compromise.


-- 
Defender of Lexical Encapsulation

Re: testing an online web service

2010-09-28 Thread Michael G Schwern

On 2010.9.28 8:21 AM, Ovid wrote:
 There are no standards that I know of because different situations can call 
 for
 different responses. However, be very careful about just mocking everything. 
 If
 you do and their API changes, you'll find yourself with passing tests for
code which
 does not work.
 
 Contact the people supplying the API (or read their docs carefully) and find 
 out if
 you can interrogate for a version and what guarantees they provide for said
version.
 Don't allow mocks if the version changes unless you can't connect.  With
that, you
 might offer people the option of connecting live, but also making it clear
that you
 only support version X.

You should also contact them and ask if they have a test server or test
account you can use.  For example, good payment APIs have sets of bogus credit
card numbers you can feed it to generate certain responses.  One number is
guaranteed to always work.  Another is guaranteed to always return an address
verification failure.  Etc...


-- 
But there's no sense crying over every mistake.
You just keep on trying till you run out of cake.
-- Jonathan Coulton, Still Alive

Re: Pending Test::More fixage - DateTime and string overload users take note

2010-05-22 Thread Michael G Schwern

On 2010.5.22 3:45 AM, demerphq wrote:
 One thought...
 
 There has been turbulence in the Regexp space over the last versions of perl.
 
 Is it possible these changes might intersect with those changes to
 make it harder to compare regexes?

No, not unless this:

$regex1 eq $regex2

and this:

$regex1 eq $regex2

would somehow produce different results.  That's the crux of the issue here,
some poorly written overloaded objects do.


-- 
Reality is that which, when you stop believing in it, doesn't go away.
-- Phillip K. Dick

Pending Test::More fixage - DateTime and string overload users take note

2010-05-19 Thread Michael G Schwern

Test::Simple/More/Builder 0.95_02 has just been released.  I'm proud to say
that I had very little to do with it.  All the commits are the work of Nick
Clayton and him not being afraid to flex his commit bit. :)
http://github.com/schwern/test-more/tree/v0.95_02

0.95_01 introduced fixage [1] (my fault, not Nick's) when testing overloaded
objects.  is(), and probably other functions, no longer stringify their
arguments before comparing.  It was a long standing bug that they did.  This
means string overloaded objects will now use their eq method to compare rather
than .

For a well written overloaded objects this should have no effect.
Unfortunately, its very easy to forget to implement a comparison function or
turn on fallback.  DateTime objects prior to 0.54 did this.

use Test::More;
use DateTime;

my $date1 = DateTime-new( year = 2010 );
my $date2 = DateTime-new( year = 2010 );

is( $date1, $date2 );

done_testing();

The above code will fail with DateTime prior to 0.54 and Test::More after (but
not including) 0.94.  Any code which uses DateTime objects should verify
against the Test::More alpha and upgrade DateTime as necessary.  Authors of
string overloaded classes should also verify their implementations and unless
you have a good reason not to, turn on fallback.

For compatibility with older versions of DateTime and Test::More, you should
quote DateTime objects before comparing with is().

is( $date1, $date2 );

CPAN Testers, please load your smokers with Test::More 0.95_02, compare the
results with Test::More 0.94 and report any differences in test results to
their respective authors.  I would like to see a summary of the differences as
well so I know the scope of the fixage.

Thank you and sorry for the inconvenience.


[1] Bug fixes which will reveal failing tests that accidentally pass.

-- 
ROCKS FALL! EVERYONE DIES!
http://www.somethingpositive.net/sp05032002.shtml

Post-Hackathon plans?

2010-03-01 Thread Michael G Schwern

I'm planning out my hackathon trip, and I figure it would be silly to fly all 
the way to Vienna, hack, and then fly all the way back home without at least 
spending a day or two bumming around.  Does anyone else have plans to be a 
tourist around Vienna or even broader for a day or two after the conference? 
If so, I travel better with packs and would love to join in.


Also, does anyone know if there's an active Turkish Perl community?  I plan to 
be in Turkey for about 10 days after the conference and will have some free 
time on my hands for Perl mongering, consulting or delivering talks/classes.



--
E: Would you want to maintain a 5000 line Perl program?
d: Why would you write a 5000 line program?

Re: What's up with No targets specified and no makefile found?


Joshua ben Jore wrote:

The just-released EU::MM 6.56 repeats this pattern frequently:

open my($fh), '', ...
or croak(Can't open ... for writing: $!);
...
print $fh ...; #  no error checking
close $fh ...; #  no error checking

Grepping for code:

egrep -rnH 'print '\\'$[^ ;]+ ' ExtUtils-MakeMaker-6.56

Where is EU::MM's version control? I'd like to submit a patch adding a bunch of:

or croak(Can't write '$fn': $!);


Putting in error checking at some key locations is fine, but the prospect of 
adding `or die Can't print $foo: $!` to every print and close makes me want 
to claw my eyeballs out.  Its unfortunate MakeMaker can't rely on autodie and 
that autodie can't override print.


Since almost nothing checks for print and close failure, and I don't blame 
them its a pain in the ass, out of disk is a veritable minefield of silent 
errors.  Scattering error checking inside MakeMaker is sort of like checking 
the ground in front of you and then merrily marching forward.  Even full error 
checking inside MakeMaker will still leave you to blow up somewhere else, 
probably in the tests.


Fortunately there is one key location where MakeMaker does almost all its 
writing to disk, ExtUtils::MakeMaker-flush.  A simple patch to check that 
would be lovely.  If you want to write and insert a safe _print() wrapper 
method and scatter that around that's fine, too.


MakeMaker's version control is listed in the META.yml and on search.cpan.org.

Does the CPAN testers code have out of disk checks?  If not, before checking 
each distribution it could try to write a decently sized file to the build 
directory to check.  If it fails, halt the build and inform the admin.



--
Stabbing you in the face for your own good.

Re: What's up with No targets specified and no makefile found?


Joshua ben Jore wrote:

Fortunately there is one key location where MakeMaker does almost all its
writing to disk, ExtUtils::MakeMaker-flush.  A simple patch to check that
would be lovely.  If you want to write and insert a safe _print() wrapper
method and scatter that around that's fine, too.


I already clawed my eyes out years ago. In the middle of this, note
ae5f97d4cf9f314a96d68af2b6fcc6ee1c7cad26 which checks
ExtUtils::MakeMaker-flush. Pushed the below to
http://github.com/jbenjore/extutils-makemaker.


The problem with this approach, and I'm sorry you did all that work, is that 
it complicates the code and it'll won't be maintained without effort.  The 
next patch will forget to include the cumbersome or die ... logic.  When you 
have to scatter duplicated code all over to warn about an unrecoverable 
failure in the surrounding environment... well hell, when you have to scatter 
duplicated code all over that's bad, full stop.


I'm very sorry but I have to reject most of that work.  I feel like a dick for 
doing it.


A little experimentation with a small disk image shows that close() will error 
if there's no disk left.  No need to check every print.  And a close() wrapper 
is trivial.  It does mean there needs to be a close() for every open() which 
is annoying but less so.  Though I may have found a non-invasive way for 
autodie to take care of that, it doesn't help us.

https://rt.cpan.org/Ticket/Display.html?id=52985

I'm not going to ask you to write up that patch, I'll do it myself unless 
somebody gets to it first.  I probably won't have time to touch it until 
tomorrow if you're feeling frisky.




MakeMaker's version control is listed in the META.yml and on
search.cpan.org.


I looked in 
http://search.cpan.org/dist/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm#AUTHORS
and found no mention of a repository so I assume it was as-yet
undocumented.


Just letting you know that search.cpan.org tracks that stuff now for future 
use.  I'll add a link to the POD.  Thanks for mentioning it.



--
170. Not allowed to defect to OPFOR during training missions.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: What's up with No targets specified and no makefile found?


Marvin Humphrey wrote:

On Tue, Dec 22, 2009 at 09:03:42PM -0800, Joshua ben Jore wrote:

On Tue, Dec 22, 2009 at 4:29 PM, Michael G Schwern schw...@pobox.com wrote:

A little experimentation with a small disk image shows that close() will
error if there's no disk left.  No need to check every print.  And a close()

You have to check every print. Most prints will just extend the buffer
but some prints will flush the buffer and return a real
success/failure. 


But when print() or flush() fails, doesn't that put the filehandle into a
state where close() will always fail?  


From the perldocs for close():


 Closes the file or pipe associated with the file handle, flushes the IO
 buffers, and closes the system file descriptor.  Returns true if those
 operations have succeeded and if no error was reported by any PerlIO
 layer.

If flushing the IO buffers fails once because the disk is full, I don't expect
that it would succeed in the future, right?

I've been using the technique of skipping checks on print() but checking
close() for a while now.  Maybe I've been lucky, but it seems to have been
pretty successful at detecting disk-full conditions.  The only downside is
that you don't know as soon as it happens -- you only know when you close() --
but depending on how your program is structured, that's usually not a problem.


That's my thinking exactly.  If there is a set of conditions where the buffers 
line up with the stars, that's ok.  The next close will fail.  Really all we 
care here is that you're out of disk shows up somewhere in the report.  The 
cost of covering that edge case is not worth the benefit.



--
94. Crucifixes do not ward off officers, and I should not test that.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: What's up with No targets specified and no makefile found?