Re: Relying more on Mouse
On Fri, Nov 25, 2011 at 11:58:48PM -0800, Ovid wrote: > Rename TB2::Mouse to something like TB2::_U_R_A_MORON_FOR_USING_THIS_ and I > think the problem will take care of itself. Or just add some doco to it thus right at the top of the file: =head1 ALL THE DOCUMENTATION This module is for the use of Test::Builder2 only. You should not use it. It is subject to arbitrary incompatible changes from one version to another. =cut -- David Cantrell | Godless Liberal Elitist Aluminum makes a nice hat. All paranoids will tell you that. But what most do not know Is reflections will show On the CIA's evil landsat.
Re: Relying more on Mouse
Ovid schrieb am 25.11.2011 um 23:58 (-0800):
> Rename TB2::Mouse to something like TB2::_U_R_A_MORON_FOR_USING_THIS_
> and I think the problem will take care of itself.
Or what about an addition to TB2::Mouse's import routine?
sub import {
# prevent unauthorised use
my $calling_pkg = (caller)[0];
croak __PACKAGE__ . ' is for internal use only'
unless $calling_pkg =~ m/^(:?Test|TB2)::/;
# or some other suitable usage policy check
...
Wouldn't that practically solve the hypothetical problem?
--
Michael Ludwig
Re: Relying more on Mouse
Michael G Schwern schrieb am 18.11.2011 um 20:24 (-0800): > 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? Sounds like a good idea to me. I don't know how likely breakage will be despite the Mouse folks' tests against Test::Builder1.5. Maybe allow the user to override the Mouse detection by specifying TB2_RODENT_INTERNAL=1 and emit a diag() alerting the user to that setting and the rodent module currently being used at the beginning of each run. (Nice publicity for the internal TB2::Mouse.) -- Michael Ludwig
Re: Relying more on Mouse
Gabor Szabo schrieb am 26.11.2011 um 10:44 (+0200): > On Sat, Nov 26, 2011 at 9:58 AM, Ovid > wrote: > > Rename TB2::Mouse to something like > > TB2::_U_R_A_MORON_FOR_USING_THIS_ and I > > think the problem will take care of itself. > I can just imagine what people outside of the Perl community > will say when they see such code in the official distribution > of Perl. Which is why TB2::Mole or TB2::Vole are better solutions. I don't understand the concern for unauthorised use. How would it be different from relying on any other implementation detail? In spirit, it's like relying on internal JDK classes. TB2::Mouse/Hamster/Mole/Vole does not mean Mouse is core. Just my two end user cents. -- Michael Ludwig
Re: Relying more on Mouse
On Saturday, November 26, 2011 at 12:44 AM, Gabor Szabo wrote: > I can just imagine what people outside of the Perl community > will say when they see such code in the official distribution of Perl. The same things they already do? -- c
Re: Relying more on Mouse
On Sat, Nov 26, 2011 at 9:58 AM, Ovid wrote: >> From: Michael G Schwern > > >>Let's keep our heads. The whole argument against TB2::Mouse is predicated on >>the idea that shipping TB2::Mouse in the core MIGHT cause future maintenance >>hassle for p5p. If the alternatives will cause EVEN MORE maintenance hassle >>for p5p and/or CPAN authors... we should just ship TB2::Mouse. > > > Rename TB2::Mouse to something like TB2::_U_R_A_MORON_FOR_USING_THIS_ and I > think the problem will take care of itself. > > Note: I'm not saying Schwern is a moron! I'm saying that if anyone dares to > use TB2::Mouse with the above name, they'll definitely think twice. I can just imagine what people outside of the Perl community will say when they see such code in the official distribution of Perl. Gabor
Re: Relying more on Mouse
> From: Michael G Schwern >Let's keep our heads. The whole argument against TB2::Mouse is predicated on >the idea that shipping TB2::Mouse in the core MIGHT cause future maintenance >hassle for p5p. If the alternatives will cause EVEN MORE maintenance hassle >for p5p and/or CPAN authors... we should just ship TB2::Mouse. Rename TB2::Mouse to something like TB2::_U_R_A_MORON_FOR_USING_THIS_ and I think the problem will take care of itself. Note: I'm not saying Schwern is a moron! I'm saying that if anyone dares to use TB2::Mouse with the above name, they'll definitely think twice. Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter- http://twitter.com/OvidPerl/
Re: Relying more on Mouse
Once again, I would like to rein this all in. Employing a counter-factual, the WORST CASE is that p5p has to ship a single 110K file which they never have to touch themselves. I am unable to get excited over the consequences. Let's keep our heads. The whole argument against TB2::Mouse is predicated on the idea that shipping TB2::Mouse in the core MIGHT cause future maintenance hassle for p5p. If the alternatives will cause EVEN MORE maintenance hassle for p5p and/or CPAN authors... we should just ship TB2::Mouse. On 2011.11.25 5:07 PM, David Golden wrote: > On Fri, Nov 25, 2011 at 4:02 PM, Michael G Schwern wrote: >> Keeping this all in perspective, TB2::Mouse is one 110K file (compressed down >> to 25K) with no POD. It's part of the Test-Simple distribution. p5p has to >> do NO EXTRA WORK AT ALL to include or maintain it. It just comes with >> Test-Simple like any other .pm file in Test-Simple. >> >> If I didn't bring it up, nobody would know it was there. Think about that. > > That sounds oddly like "security through obscurity" except it's > "compatibility through obscurity". :-) Someone always finds these > things out and then relies on them and then claims the need for > ongoing existence in core. Obscurity, documentation (or lack thereof) and social contract is how Perl enforces encapsulation. Whether we like it or not. Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun” ―- Larry Wall People can (and do) rely on internal code and then want us to maintain compatibility. At some point, project willpower to enforce encapsulation has to win out. I quote Tom... You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it. -- tchrist in <31832.969261130@chthon> Some careful and B documentation in TB2::Mouse can make this point even more clear. At some point, users take responsibility for ignoring the clearly marked warning signs. https://twimg0-a.akamaihd.net/profile_images/63014578/Crocodiles.jpg > As the current maintainer of Parse::CPAN::Meta -- which *is* an exact > copy of YAML::Tiny with a quick paint job (*cough* DZP::Doppelgaenger > *cough*), I'm sensitized to the issues, that's all. Roger. >> The real problem is how does Test::More depend on a non-core CPAN module >> without having a dependency on a non-core CPAN module? One which uses >> Test::More. That problem always remains. Test::More has it. MakeMaker has >> it. And the simple answer is bundling. > > I don't follow. I was speaking to the suggestions to use Role::Tiny or Object::Tiny or Role::Basic instead of a copy of Mouse::Tiny. They all present the same problem as TB2::Mouse. But you bring up some other scenarios while I'll address... > The only things that need to be in core (or need to > be bundled with a CPAN release) are modules sufficient to get a CPAN > client to deal with build_requires (and eventually test_requires). ...and the modules CPAN clients depend on. Very important. ...and the dependencies for everything else we currently ship in core. I would so love if the "only stuff for CPAN" policy was real and retroactive, but it is not. > Test::Hoopy can depend on Test::More 2 and core can have Test::More > 0.99 and CPAN clients will deal. You've already talked about a non > Test-More framework to test TB2, so you've already eliminated that > element of bootstrapping. Here's an example I hope will clarify. 1. CPAN-Meta's tests rely on Test::More. (they do) 2. CPAN-Meta is shipped with the core. (it is) 3. The next version of CPAN-Meta (knowingly or not) relies on a Test::More 1.5.x feature or bug fix in its tests. In order to ship CPAN-Meta, p5p has these options... 1. The core ships with Test::More 1.5.x. 2. CPAN-Meta is forced to downgrade their tests to only use 0.9x features. 3a. CPAN-Meta is forced to downgrade their tests to only use t/test.pl and copy t/test.pl into their CPAN distribution. 3b. Same as 3a, but we fork t/test.pl and make it available is an independent test library... and then ship it with the core. 4. p5p maintains a patched version of CPAN-Meta. 5. p5p stops running CPAN-Meta's tests as part of the build process. I think you'll agree, upgrading Test::More and accepting a single extra file that requires no extra maintenance is the approach with the most flexibility and least hassle for p5p and dual-life modules. This can happen to any module in cpan/ and dist/ http://cpansearch.perl.org/src/SHAY/perl-5.15.5/cpan/ http://cpansearch.perl.org/src/SHAY/perl-5.15.5/dist/ >> BTW What are those downstream maintenance costs? > > Someone ignores the "internal" nature of TB2::Mouse, sees that it's in > corelist, and writes something that depends on it. Later, you switch > to something else, or TB2::Mouse is no longer used by Test::More, or > you get hit by a bus
Re: Relying more on Mouse
On Fri, Nov 25, 2011 at 4:02 PM, Michael G Schwern wrote: > Keeping this all in perspective, TB2::Mouse is one 110K file (compressed down > to 25K) with no POD. It's part of the Test-Simple distribution. p5p has to > do NO EXTRA WORK AT ALL to include or maintain it. It just comes with > Test-Simple like any other .pm file in Test-Simple. > > If I didn't bring it up, nobody would know it was there. Think about that. That sounds oddly like "security through obscurity" except it's "compatibility through obscurity". :-) Someone always finds these things out and then relies on them and then claims the need for ongoing existence in core. > This discussion is EXACTLY THE SAME if TB2 were using Role::Tiny or > Role::Basic or any other CPAN module which is not currently core. Agreed. I'm having two separate thought-streams. First is "do non Mouse things get you 80% of what you need without the speed hit" and the answer seems to be "no". Second is "is it good policy to add clones of CPAN modules under another name"? As the current maintainer of Parse::CPAN::Meta -- which *is* an exact copy of YAML::Tiny with a quick paint job (*cough* DZP::Doppelgaenger *cough*), I'm sensitized to the issues, that's all. > The real problem is how does Test::More depend on a non-core CPAN module > without having a dependency on a non-core CPAN module? One which uses > Test::More. That problem always remains. Test::More has it. MakeMaker has > it. And the simple answer is bundling. I don't follow. The only things that need to be in core (or need to be bundled with a CPAN release) are modules sufficient to get a CPAN client to deal with build_requires (and eventually test_requires). Test::Hoopy can depend on Test::More 2 and core can have Test::More 0.99 and CPAN clients will deal. You've already talked about a non Test-More framework to test TB2, so you've already eliminated that element of bootstrapping. > BTW What are those downstream maintenance costs? Someone ignores the "internal" nature of TB2::Mouse, sees that it's in corelist, and writes something that depends on it. Later, you switch to something else, or TB2::Mouse is no longer used by Test::More, or you get hit by a bus and the next maintainer switches to TB2::Hamster. Then someone complains "TB2::Mouse was in core! You have to have a deprecation cycle", etc. None of these are impossible to solve, but with the deprecation policy in flux, I'd be nervous to add anything that might have to be maintained for a long time by *someone* whether or not that is *you*. Personally, I'm a "tough love" person on p5p. I'm relatively happier to break stuff and tell people to test their code and don't upgrade Perl if you don't like the new version. But there are others who don't and the vision that Jesse laid out implies that "use v5.XX" might mean that it should be honored by v5.30. Meaning "use v5.18" requires having the same copy of TB2::Mouse that was available in v5.18 years and years from now -- albeit with any security bug fixes that might appear. I hope that Rik clarifies that promise to something more manageable and it's an unlikely case, but the risk is there. > Anyhow, they would be in violation of the documentation (which would be > written in bold neon on the first page) and not supported. I *would* include just enough Pod to get an abstract line that says "for internal use only". I would also encourage you to call it something other than TB2::Mouse. TB2::Object or whatever. For the same reasons that Parse::CPAN::Meta isn't Parse::YAML::Tiny or whatever else it could have been called. Just don't imply Mouse. "It's just a black box. Naughty user, please go away!" Etc. > It won't work for the simple reason that if any dual-life CPAN module decides > to use a feature or bug fix of Test::More 1.5.0 then it can't be cored. The > forward dependency march will drag it in. We live in that world already, but with perl features. Which is why toolchain development sometimes sucks. > It also means the perl core gets no bug fixes and no feature enhancements. > Holding it back in the core is just YET ANOTHER immediate upgrade > that's necessary after a fresh perl install. C.f. Task::Kensho. The community has already decided that core Perl isn't enough for real tasks. Ditto "Bundle::CPAN" for that matter. > If I didn't point it out, nobody would have known it was there. I'd rather have the discussion up front and reach consensus than find something implemented that we regret later. Not a core example, but "PERL_CPANPLUS_IS_RUNNING" having to be set in CPAN.pm and cpanm is one of those examples of things where someone's bright idea has led to cruft that we'll be living with in every CPAN client for decades. It was a bright idea that made things easier for Module::Install... but with hugely annoying downstream impacts. Net -- I'd run this explicitly past Rik (if he's not following along), but I'm supportive if the answer is "TB2::Object
Re: Relying more on Mouse
On 2011.11.25 3:04 PM, chromatic wrote: > On Friday, November 25, 2011 at 01:02 PM, Michael G wrote: >> We did it once with Test::Harness::Straps, though not nearly that well >> thought out, and it worked. > > Do you know anyone (besides me) who used it? I know I dealt with some DarkPAN users, but it's been so long I can't enumerate them. There's a handful on CPAN and in Google Code Search. https://metacpan.org/requires/module/Test::Harness::Straps http://www.google.com/codesearch#search/&q=%22use%20Test::Harness::Straps%22%20lang:perl&type=cs I agree it's not a scale test, but the mechanism worked. >> I do see a work around. Document that TB2::Mouse can be used, but you MUST >> add it as a dependency anyway. > > I hate to see the core (even implicitly) blessing Yet Another Object System. The core hasn't blessed any object system, directly or indirectly, unless you count the ad hoc messes previously cobbled together in the old OO tutorials. So it's hard to say "yet another". But I'm willing to say whatever they come up with in the future is going to look an awful lot like Moose. One of the major problems with including a module in the core is its *implicit* blessing. The core never said anything about whether a core module was blessed or better than others, users just assumed it. With TB2::Mouse, we have a chance to *explicitly* state the terms. If it's going to be for internal TB2 use only, we can state that. If it's going to be a stop-gap until a better OO system is core, we can state that. Those old OO tutorials are going away BTW. Moose, Mouse, Class::Accessor, Object::Tiny and Role::Tiny are all talked about in the new OO tutorial. http://cpansearch.perl.org/src/SHAY/perl-5.15.5/pod/perlootut.pod >> It won't work for the simple reason that if any dual-life CPAN module >> decides to use a feature or bug fix of Test::More 1.5.0 then it can't be >> cored. > > I'm also little enamored of pre-emptive coring. > > I'd like to see TB2 *used* outside of bootstrapping for a while first before > considering it a replacement for TB. There's some sort of misunderstanding or terminology mix up. The TB2 modules cannot be separated from Test::More any more than Test::Builder can. Test::Builder is using the TB2 infrastructure. Even if I chucked out the whole event system, Test::Builder would still make use of TB2::Formatter. I expect TB2 to go through an alpha period for a while. The current formal alpha phase for compatibility with existing code, make sure nothing breaks. Then a post-stable 1.5.0 phase where the TB2 interfaces are considered unstable, so we can knock them around. I'm sure there will be plenty of little changes. People can try TB2 out NOW and give feedback. Even if it's "I don't understand this, the docs for X suck". That is useful! I'm so deep in the design its hard for me to see that. There are plenty of modules which could be rewritten right now far easier using TB2. Off the top of my head... Test::SharedFork Test::Aggregate Test::NoWarnings Test::Class Test::Block Fennic Test::DebugOnFail (that's in the examples directory) And I'm still waiting on someone taking a stab at an alternative output format like JUnit or JSON. -- I am somewhat preoccupied telling the laws of physics to shut up and sit down. -- Vaarsuvius, "Order of the Stick" http://www.giantitp.com/comics/oots0107.html
Re: Relying more on Mouse
On Friday, November 25, 2011 at 01:02 PM, Michael G wrote: > We did it once with Test::Harness::Straps, though not nearly that well > thought out, and it worked. Do you know anyone (besides me) who used it? > I do see a work around. Document that TB2::Mouse can be used, but you MUST > add it as a dependency anyway. I hate to see the core (even implicitly) blessing Yet Another Object System. > It won't work for the simple reason that if any dual-life CPAN module > decides to use a feature or bug fix of Test::More 1.5.0 then it can't be > cored. I'm also little enamored of pre-emptive coring. I'd like to see TB2 *used* outside of bootstrapping for a while first before considering it a replacement for TB. -- c
Re: Relying more on Mouse
Keeping this all in perspective, TB2::Mouse is one 110K file (compressed down to 25K) with no POD. It's part of the Test-Simple distribution. p5p has to do NO EXTRA WORK AT ALL to include or maintain it. It just comes with Test-Simple like any other .pm file in Test-Simple. If I didn't bring it up, nobody would know it was there. Think about that. This discussion is EXACTLY THE SAME if TB2 were using Role::Tiny or Role::Basic or any other CPAN module which is not currently core. On 2011.11.25 3:53 AM, David Golden wrote: > To be clear -- I'm not (yet) saying that TB2 should absolutely roll > it's own OO, but I am concerned about hiding yet another copy of a > perfectly decent CPAN module so that we can avoid saying that we're > including another CPAN module in core. It's seductively easy to get > the benefits *now* during the development of TB2, but there are > downstream maintenance costs that we shouldn't discount lightly. That is only a tangential problem. The real problem is how does Test::More depend on a non-core CPAN module without having a dependency on a non-core CPAN module? One which uses Test::More. That problem always remains. Test::More has it. MakeMaker has it. And the simple answer is bundling. BTW What are those downstream maintenance costs? >> 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. > > And potentially *other*, non-test modules could start doing so too. Disallowing non-Test modules is not strictly necessary, it's just something I have in my head to rein this in a bit. I don't think it changes anything. Anyhow, they would be in violation of the documentation (which would be written in bold neon on the first page) and not supported. p5p doesn't always toe that line, but that's their problem. > Is there a guarantee that TB2::Mouse will always be in core (short of > a deprecation cycle)? Would it have to be available "forever" under > "use v5.18"? I'm very leery of adding more core modules when the core > policy around deprecation or lack thereof is in flux. If it's documented, then yes. See above about it being a single file with no extra support costs for p5p. I do see a work around. Document that TB2::Mouse can be used, but you MUST add it as a dependency anyway. That way when we do remove it from the core (and I do agree, it would be nice if we could) then it can be put on CPAN and slurped in like anything else. We did it once with Test::Harness::Straps, though not nearly that well thought out, and it worked. > [ Social hack: include TB2::Mouse but mark it "deprecated" from the > start. :-) ] That would be "for internal use only" and lacking documentation like all the other "for internal use only" .pm files already in core and other CPAN modules. The "everyone else gets an OO framework" part of this plan is just gravy. Right now it's not documented at all, so anyone using it has violated encapsulation and gets no support. > If I had my druthers, I'd like to see Stevan's core MOP work finished, > then I'd like to see a powerful, minimalist object system on top of > *that* built for inclusion in core, then I'd like to see core modules > gradually migrating to that. And I'd like a pony, too. Throw in a time machine so we can all fast forward three years to that version of the future. Wait... eleven years! Gotta wait for all those versions of Perl that don't have a MOP to end-of-life! :-/ > Maybe the related, fundamental question is whether TB2 itself needs to > be in core -- or, if so, *when* it needs to be in core. Maybe core is > just fine with Test::More as is and anyone needing more powerful > testing frameworks can install TB2 from CPAN. (Ditto for any new test > modules that are written that rely on TB2.) Eventually, when TB2 is > well proven on CPAN and the core offers the kind of MOP that TB2 > needs, then it can migrate in. It won't work for the simple reason that if any dual-life CPAN module decides to use a feature or bug fix of Test::More 1.5.0 then it can't be cored. The forward dependency march will drag it in. It also means the perl core gets no bug fixes and no feature enhancements. Unless they want to maintain their own fork, which I sure as hell am not. And that IS an extra maintenance load for p5p. As TB2 is a pretty radical internals restructuring, and I expect new and existing Test modules will want to start using those internals, and people will want to start using those new versions, Test::More 1.5.0 will be required. Holding it back in the core is just YET ANOTHER immediate upgrade that's necessary after a fresh perl install. While we might debate the utility of having certain modules in the core, modules which help install other modules have always been in that set. The test framework used by 80% of CPAN is squarely in that category. Should it be thrown ou
Re: Relying more on Mouse
On Thu, Nov 24, 2011 at 4:23 PM, Michael G Schwern wrote: > 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 Of course, that pretty much describes Perl OO in a nutshell until Moose/Class::MOP came along. And it describes pretty much how every other core module does OO. (With the possible exception of CPANPLUS, which dragged Object::Accessor into core with it.) To be clear -- I'm not (yet) saying that TB2 should absolutely roll it's own OO, but I am concerned about hiding yet another copy of a perfectly decent CPAN module so that we can avoid saying that we're including another CPAN module in core. It's seductively easy to get the benefits *now* during the development of TB2, but there are downstream maintenance costs that we shouldn't discount lightly. > 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. And potentially *other*, non-test modules could start doing so too. Is there a guarantee that TB2::Mouse will always be in core (short of a deprecation cycle)? Would it have to be available "forever" under "use v5.18"? I'm very leery of adding more core modules when the core policy around deprecation or lack thereof is in flux. [ Social hack: include TB2::Mouse but mark it "deprecated" from the start. :-) ] If I had my druthers, I'd like to see Stevan's core MOP work finished, then I'd like to see a powerful, minimalist object system on top of *that* built for inclusion in core, then I'd like to see core modules gradually migrating to that. And I'd like a pony, too. Maybe the related, fundamental question is whether TB2 itself needs to be in core -- or, if so, *when* it needs to be in core. Maybe core is just fine with Test::More as is and anyone needing more powerful testing frameworks can install TB2 from CPAN. (Ditto for any new test modules that are written that rely on TB2.) Eventually, when TB2 is well proven on CPAN and the core offers the kind of MOP that TB2 needs, then it can migrate in. -- David
Re: Relying more on Mouse
On 2011.11.23 12:49 AM, Ovid wrote: > As an aside, while I'm sure that Schwern is using far more > than just roles, Role::Basic already handles multiple roles, > is forwards-compatible with Moose::Role and it adheres much > more closely to the traits spec, particularly with regards > to the commutative and associative properties that Role::Tiny > and Moose::Role ignore (https://metacpan.org/module/Role::Basic::Philosophy) Sorry, but Role::Basic is nearly as slow to load as Mouse and only provides one piece of the puzzle. -- s7ank: i want to be one of those guys that types "s/j&jd//.^$ueu*///djsls/sm." and it's a perl script that turns dog crap into gold.
Re: Relying more on Mouse
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
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
- Original Message - > From: David Golden > > And I wonder if Role::Tiny could be extended to do multiple roles. As an aside, while I'm sure that Schwern is using far more than just roles, Role::Basic already handles multiple roles, is forwards-compatible with Moose::Role and it adheres much more closely to the traits spec, particularly with regards to the commutative and associative properties that Role::Tiny and Moose::Role ignore (https://metacpan.org/module/Role::Basic::Philosophy) Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl/
Re: Relying more on Mouse
# from Michael G Schwern # on Tuesday 22 November 2011 20:19: >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. 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. --Eric -- I arise in the morning torn between a desire to improve the world and a desire to enjoy the world. This makes it hard to plan the day. --E.B. White --- http://scratchcomputing.com ---
Re: Relying more on Mouse
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
On Tue, Nov 22, 2011 at 10:49 PM, Michael G Schwern wrote: > 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. Attributes -- leaving aside types and coercion -- are you just talking about the sugar? 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. 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? 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). [N.B. Not arguing not to use it -- trying to provoke discussion of preexisting assumptions.] -- David
Re: Relying more on Mouse
On 2011.11.22 11:22 AM, David Golden wrote: > On Tue, Nov 22, 2011 at 2:02 PM, Eric Wilhelm 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
On Tue, Nov 22, 2011 at 2:02 PM, Eric Wilhelm 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) -- David
Re: Relying more on Mouse
# from Michael G Schwern # on Monday 21 November 2011 17:56: >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. 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? Is there a way to remove some of the work Mouse is doing at startup? What is it doing? 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. --Eric -- You can't whack a chisel without a big wooden mallet. --- http://scratchcomputing.com ---
Re: Relying more on Mouse
On Mon, Nov 21, 2011 at 5:35 AM, yary wrote: > I'd think Michael has the interests of CPAN smoke testers in mind with > these performance benchmarks. You're right in that for the typical > developer, it's not significant. Just to offer a contrasting viewpoint: if you're using TDD, you're running tests *constantly*. My typical work cycle is to run a single test file (whichever one I'm working on) over and over--several times a minute--until I get to a certain point, then run a larger subset of tests to verify I haven't broken anything (perhaps a couple times an hour), then the full test suite before I check anything in. So the test speed is pretty important. The slower the tests run, the more it encourages people to delay running the tests, which in turn means more changes between test runs and longer debugging cycles. -- Buddy
Re: Relying more on Mouse
> > From: 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. I have to agree with this. Test performance is an issue that people constantly hit. And aside from Test::Class/Test::Aggregate style solutions (I see to recall someone put out an alternative to Test::Aggregate?), individual tests in separate processes is the norm. For larger, "enterprisey" type systems, my experience shows that they generally have enough other issues that a tiny hit on Test::More won't matter, but when you add up all the tiny hits, it's death by a thousand cuts. Dave, you weren't on the PIPs team when I optimized their test suite, but it was those "thousand cuts" that I stripped away one by one to get an hour long test suite running in less than 15 minutes. So yeah, this is a very important issue. If performance isn't dealt with, it's going to be a constant sore spot. And Schwern: thanks for all of your good work in this area! Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter- http://twitter.com/OvidPerl/
Re: Relying more on Mouse
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: Relying more on Mouse
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
On Mon, Nov 21, 2011 at 5:30 PM, 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. > > Separately -- once the Perl core gets a MOP, maybe this gets > easier/faster anyway. Yeah. Adding a dependency to a core module should be discussed on p5p first, and even more so if it's such a heavy and controversial one. Leon
Re: Relying more on Mouse
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. Separately -- once the Perl core gets a MOP, maybe this gets easier/faster anyway. -- David On Sat, Nov 19, 2011 at 2:20 AM, Michael G Schwern wrote: > I did some profiling and easy optimizations which sped things up quite a bit, > but it didn't translate into real world improvements. Turns out the real > problem is startup time. > > use Test::More; > > 0.98 > real 0m0.021s > user 0m0.016s > sys 0m0.004s > > 1.5 > real 0m0.092s > user 0m0.083s > sys 0m0.008s > > That's going to be a tough one to cut down, simply because Test::Builder1.5 > contains so many more individual files to load and attributes to set up. > There's some things it's doing at compile time that can be hard coded (like > setting up all the Result subclasses), but what shaves off a good chunk is > using Mouse with XS. > > 1.5 with XS Mouse > real 0m0.070s > user 0m0.061s > sys 0m0.007s > > So that's another point in its favor. > > > -- > What we learned was if you get confused, grab someone and swing > them around a few times > -- Life's lessons from square dancing >
Re: Relying more on Mouse
I'd think Michael has the interests of CPAN smoke testers in mind with these performance benchmarks. You're right in that for the typical developer, it's not significant. -y
Re: Relying more on Mouse
On Fri, Nov 18, 2011 at 11:20:00PM -0800, Michael G Schwern wrote: > I did some profiling and easy optimizations which sped things up quite a bit, > but it didn't translate into real world improvements. Turns out the real > problem is startup time. > > use Test::More; > > 0.98 > real 0m0.021s > user 0m0.016s > sys 0m0.004s > > 1.5 > real 0m0.092s > user 0m0.083s > sys 0m0.008s > > That's going to be a tough one to cut down But then how often does one need to 'use Test::More'? Not enough to bother optimising it, I'd say. 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. Also bear in mind that in the Test::Class world, a great many test files will get run in the same perl process, so that 0.07 second hit will be a one-off for many instances of 'use Test::More'. If you like, I can benchmark the new Test::More/Builder against our code and we can see whether the slowdown is *really* significant or not. -- David Cantrell | Reality Engineer, Ministry of Information Seven o'clock in the morning is something that happens to those less fortunate than me
Re: Relying more on Mouse
I did some profiling and easy optimizations which sped things up quite a bit, but it didn't translate into real world improvements. Turns out the real problem is startup time. use Test::More; 0.98 real0m0.021s user0m0.016s sys 0m0.004s 1.5 real0m0.092s user0m0.083s sys 0m0.008s That's going to be a tough one to cut down, simply because Test::Builder1.5 contains so many more individual files to load and attributes to set up. There's some things it's doing at compile time that can be hard coded (like setting up all the Result subclasses), but what shaves off a good chunk is using Mouse with XS. 1.5 with XS Mouse real0m0.070s user0m0.061s sys 0m0.007s So that's another point in its favor. -- What we learned was if you get confused, grab someone and swing them around a few times -- Life's lessons from square dancing
