Re: Updated CPAN River available

* James E Keenan [2017-04-12T22:15:22] > For me the most interesting aspect of this fifth round is that 29 > distributions which appeared in order-of-battle-20170409.txt (the > previous round focusing on no-dot) no longer appear in > order-of-battle-20170412.txt. That is,

Re: Test::Buildder v. Test2 subtests

* Chad Granum [2016-12-13T11:35:19] > ok, thanks for trying that, I will look into it when I have time and if > nothing else at least explain why it behaves like it does. If it is a bug I > will fix it. This has remained a problem for me, so this morning I had a run through

Re: Test-Deep as_test_deep_cmp branch

* Ricardo Signes <perl...@rjbs.manxome.org> [2016-12-18T09:08:23] > When you call cmp_deeply($have, $want), objects found in $want are either > Test::Deep::Cmp objects or not. If they are, they do their special test > magic. If they are not, they are more or less compared to th

Test-Deep as_test_deep_cmp branch

I've filed a PR against Test-Deep: https://github.com/rjbs/Test-Deep/pull/52 addresses https://github.com/rjbs/Test-Deep/issues/50 The idea is: When you call cmp_deeply($have, $want), objects found in $want are either Test::Deep::Cmp objects or not. If they are, they do their special

Re: Test::Buildder v. Test2 subtests

* Chad Granum [2016-12-13T11:13:56] > I would like to see the results when you use > Test2::Tools::Subtest::subtest_streamed() which is the actual equivalent to > Test::More::subtest(). Thanks for the pointer. I have tried this and got identical ("bad") results to

Test::Buildder v. Test2 subtests

I've hit a nasty (to me) difference between Test2::API::run_subtest and Test::Builder::subtest. Shout out to Matthew Horsfall for helping localize the problem. Here's my trivial reproducer: #!perl use strict; use warnings; use Test::More; use Test2::API; my $code = sub { if

Re: test/subtest flow control with exceptions

* Chad Granum [2016-11-30T10:30:38] > I do have implementation commentary however: Thanks, greatly appreciated! > * You should not be obtaining a context inside your subtest (specifically > line 18 So, I've moved it to after the eval. I (think that I) need it inside the

test/subtest flow control with exceptions

Often, I have a test like this: subtest "do things with an api" => sub { my $result = $api_client->do_first_thing; is( $result->documents->first->title, "The Best Thing", ); ... }; Sometimes, the result comes back with zero documents. ->first throws an

Re: Test2/Test::Builder release plan

* Chad Granum [2016-03-19T13:03:34] > RJBS and I have spoken, and feel it is time to set a release date for > Test2/Test-Builder. We have agreed that doing it at the QAH in Rugby is a > good time. The plan is to release Test2 and the new Test::Builder as stable > either at the

Re: Test-Stream! Test-Simple! Go!

* Ricardo Signes <perl...@rjbs.manxome.org> [2015-11-23T18:12:22] > * make a set of GitHub issues for the punch list, tagged as such https://github.com/Test-More/test-more/issues?q=is%3Aopen+is%3Aissue+label%3ATest-Stream > * make GitHub issues for other topics to review, also

Test-Stream! Test-Simple! Go!

Wow, the last update on this was in April! Then stuff came up. Has all the stuff that came up gone down? I hope so. I think that there is not one person who wants the up-in-the-air-ness of Test-Builder-on-Test-Stream to last longer than it has to. I sure don't. Now that it seems like there

Re: new Stream Test::Simple question, XS requirement

* bulk88 bul...@hotmail.com [2015-04-25T23:56:23] Because of the rjbs post that supposedly (someone else should confirm this) minitest does not use Test::*, new Test::Simple can use all the XS it wants. Re-confirmation welcome! For the record: My first check was scanning all the tests run by

Re: new Stream Test::Simple question, XS requirement

* bulk88 bul...@hotmail.com [2015-04-25T17:57:19] Since Test::Stream::Context's core design uses weaken() everywhere, that means new Test::Simple always requires XS building (for Scalar::Util), which means it will never run on miniperl, and hence, new Test::Simple will never be in Perl core,

Re: TPF Devel::Cover grant report May/June 2014

* Paul Johnson p...@pjcj.net [2014-07-20T18:59:51] Hours worked: Total 25:00 Thanks, Paul, +1! -- rjbs signature.asc Description: Digital signature

Re: anyone want to adopt Test::Tester?

* David Cantrell da...@cantrell.org.uk [2014-06-26T09:19:00] I understand that Test::Builder::Tester is the way to go these days - and it's distributed with Test::Builder, so incompatibilities should never* happen. Test::Tester is really nice and easy to use. Test::Builder::Tester is awful

Re: TPF Devel::Cover grant report April 2014

* Paul Johnson p...@pjcj.net [2014-05-20T17:50:35] In accordance with the terms of my grant from TPF this is the monthly report for my work on improving Devel::Cover covering April 2014. Thanks, Paul, +1. -- rjbs signature.asc Description: Digital signature

Re: Discussion/request on Test::More , have it add t/lib to @INC if -d

* Eirik Berg Hanssen eirik-berg.hans...@allverden.no [2014-01-31T10:17:53] Yeah; just name the package accordingly, and, screwy or not, it'll still work: package t::lib::MyPackage; sub import { print import() was called\n } This is my advice as well as my custom. -- rjbs

Re: Discussion/request on Test::More , have it add t/lib to @INC if -d

* Torbjørn Lindahl torbjorn.lind...@gmail.com [2014-01-30T19:59:04] It seems t/lib is a common place to put modules used to support testing, how about having Test::More push that path to @INC if -d 't/lib' ? It would I suggest this alternative: use t::lib::MyPackage; ;) -- rjbs

Test-Class 0.40

Once Test::Simple 1.001002 is release, I will upload Test-Class 0.40, which makes it pass its tests with 0.98 and previous as well as 1.001001 and later. 0.99 is broken. You can test it here: https://dl.dropboxusercontent.com/u/88746/perl/Test-Class-0.40.tar.gz -- rjbs signature.asc

Test::Simple 1.0!!! (plus 0.001001001)

NOW WITH MORE DIGITS! We released 0.99 recently. There was a regression. We need a new release. To sync up with the 1.005001 versioning, we are moving to X.YYYZZZ-style. I think the longer-term goal will be to use Perlified semantic versions. For now, I'm just dealing with important

Test-Simple 0.98_06

Test-Simple has built up a nice set of changes in the two years since its last release. Some of these are adjustments to changes in core for which Test-Simple was patched in blead. Test-Simple 0.98_06 integrates (or replaces) those fixes, and has other fixes of its own. Please test your code

Re: TAP::Harness and -w

* Leon Timmermans faw...@gmail.com [2013-09-17T11:26:40] Just as I expected, make it a wiki means it gets warnocked again. Can we please make a decision, or if we must first come to an agreement on how to make it? Allow me to offer this:

Re: TAP::Harness and -w

* Ovid curtis_ovid_...@yahoo.com [2013-09-18T04:19:28] As I said in my previous email on July 7th: backwards-incompatible changes to the backwards-compatibility layer (Test::Harness) are not a good idea. The proper response is to have people impacted by this issue switch to TAP::Harness, as

Re: TAP::Harness and -w

* Leon Timmermans faw...@gmail.com [2013-09-18T19:21:44] Or both just setting $Test::Harness::switches = ''… Yes. I was cleaning out ~/tmp on the flight over here and I found this dzil plugin: package inc::STFUEUMM; use Moose; extends 'Dist::Zilla::Plugin::MakeMaker'; use

Re: TPF Devel::Cover grant report July 2013

* Paul Johnson p...@pjcj.net [2013-09-02T06:37:20] And I'm not really sure what a 50¢ explanation is, so I hope I've guessed correctly. Perfect, thanks! -- rjbs signature.asc Description: Digital signature

Re: TPF Devel::Cover grant report June 2013

* Paul Johnson p...@pjcj.net [2013-08-31T18:59:11] In accordance with the terms of my grant from TPF this is the monthly report for my work on improving Devel::Cover covering June 2013. +1, thanks Paul. -- rjbs signature.asc Description: Digital signature

Re: TPF Devel::Cover grant report July 2013

* Paul Johnson p...@pjcj.net [2013-08-31T19:01:09] In accordance with the terms of my grant from TPF this is the monthly report for my work on improving Devel::Cover covering July 2013. +1, Thanks, Paul! The rest of the work this month was spent on p5cover. This is the project to get test

Re: TPF Devel::Cover grant report August 2013

* Paul Johnson p...@pjcj.net [2013-08-31T19:02:48] In accordance with the terms of my grant from TPF this is the monthly report for my work on improving Devel::Cover covering August 2013. +1, thanks, Paul! 5.18.1 breaks Devel::Cover. I'm very sorry to have been part of the problem, here.

Re: TAP::Harness and -w

* Leon Timmermans faw...@gmail.com [2013-07-04T14:04:21] By what process? Define consensus? Given Andy is the official maintainer and Ovid is the effective maintainer, I don't think they need our consensus a priori. 06perms.txt says: Test::Harness,ANDYA,m Test::Harness,MSCHWERN,c

Re: TAP::Harness and -w

* Eric Wilhelm enoba...@gmail.com [2013-07-04T17:33:45] # from Leon Timmermans on Thursday 04 July 2013: ewilhelm : We should keep the original change, but update EUMM to restore -w I'm not sure that's what he meant. Yeah no. I said get rid of Test::Harness. TAP::Harness provides a

TAP::Harness and -w

I just submitted: https://github.com/Perl-Toolchain-Gang/Test-Harness/pull/16 ...to document two undocumented changes. First, the removal of turn on -w by default with no easy way to turn it off and secondly the reversion of that. These commits are, respectively:

Re: TPF Devel::Cover grant report May 2013

* Paul Johnson p...@pjcj.net [2013-06-23T18:43:41] In accordance with the terms of my grant from TPF this is the monthly report for my work on improving Devel::Cover covering May 2013. Thanks, Paul! Looks good. I look forward to putting some of this work to good use myself! -- rjbs

Re: TPF Devel::Cover grant report March 2013

* Paul Johnson p...@pjcj.net [2013-05-01T16:38:26] In accordance with the terms of my grant from TPF this is the monthly report for my work on improving Devel::Cover covering March 2013. +1, thanks, Paul! -- rjbs signature.asc Description: Digital signature

Re: TPF Devel::Cover grant report April 2013

* Paul Johnson p...@pjcj.net [2013-05-01T16:40:17] In accordance with the terms of my grant from TPF this is the monthly report for my work on improving Devel::Cover covering April 2013. [...] This month I released Devel::Cover 1.02 but, apart from that, almost all of my work on Devel::Cover

Re: Smoke Test::More 0.98_05 please.

* Michael G. Schwern schw...@pobox.com [2013-04-25T13:35:49] 0.98_05 is a release candidate for 0.99. I would say this is the last stable release of Test::More before 1.5.0 but hahahaha I won't say that. https://metacpan.org/release/MSCHWERN/Test-Simple-0.98_05/ Test::Exception fails, which

Re: Smoke Test::More 0.98_05 please.

* Adrian Howard adri...@quietstars.com [2013-04-27T20:09:09] On 27 April 2013 15:19, Ricardo Signes perl...@rjbs.manxome.org wrote: Test::Exception fails, which breaks a lot of my basic toolchain from installing. T::E 0.32 just uploaded that kills the false failure. Thanks

Re: TPF Devel::Cover grant report February 2013

* Paul Johnson p...@pjcj.net [2013-03-07T17:38:54] In accordance with the terms of my grant from TPF this is the monthly report for my work on improving Devel::Cover covering February 2013. Great, thanks, +1! Finally, David Golden politely observed that the coverage reporting for ||=

Re: TPF Devel::Cover grant report January 2013

* Paul Johnson p...@pjcj.net [2013-02-11T15:53:10] I'm pleased to be able to report that we've agreed to continue with the second half of the grant. Excellent! I'd like to publicly thank Ricardo Signes and Florian Ragwitz for their help and support in managing the first half of the grant

Re: TPF Devel::Cover grant report Weeks 30-32

* Paul Johnson p...@pjcj.net [2013-01-02T09:36:45] In accordance with the terms of my grant from TPF this is the report for weeks 30-32 of my work on improving Devel::Cover. [...] Total 8:50 Thanks, Paul. Interesting report, and good luck! +1 -- rjbs signature.asc Description:

Re: TPF Devel::Cover grant report Weeks 30-32

* James E Keenan jk...@verizon.net [2013-01-02T22:39:21] On 1/2/13 9:36 AM, Paul Johnson wrote: Last week I mentioned the pull requests I had received. I this week I merged a pull request from Steffen Schwigon adding some important modules to cpancover.com. I'm always happy to add modules

Re: TPF Devel::Cover grant report August 2012

* Paul Johnson p...@pjcj.net [2012-09-07T10:36:52] In accordance with the terms of my grant from TPF this is the monthly report for my work on improving Devel::Cover covering August 2012. +1, thanks very much, Paul! -- rjbs signature.asc Description: Digital signature

Re: TPF Devel::Cover grant report July 2012

* Paul Johnson p...@pjcj.net [2012-08-01T11:48:43] In accordance with the terms of my grant from TPF this is the monthly report for my work on improving Devel::Cover covering July 2012. Thanks Paul, +1. -- rjbs signature.asc Description: Digital signature

Re: TPF Devel::Cover grant report June 2012

* Paul Johnson p...@pjcj.net [2012-07-12T13:36:26] Feature request: some way of easily seeing just my dists. TODO I can't promise when I'll get around to it, but I do have plans for extending cpancover. However, this work is fairly well decoupled from the core of Devel::Cover, so if

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

Sorry for the long delay. Lately I'm task-switching at a slow pace. Also, I'm quoting you out of order. * Michael G Schwern schw...@pobox.com [2011-11-30T17:16:47] RJBS wrote, The only case when the programmer needs to know about the Mouse underpinnings is when hacking on the dist itself,

Re: Need suggestions for terminology

David Golden xda...@gmail.com writes: I plan to expand further on this idea of separation at the QA Hackathon in the spring (if I don't start working on it sooner). I'd like to get all CPAN clients able to use an index completely separate from a given repository, where the index could,

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

Please stop cc'ing my personal email address on this mailing list mail. I'm already a subscriber. It just pollutes my personal mail from friends folders. -- rjbs

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

re: internal use What does internal define here? What are the boundaries of the space to which TB2::Mouse use is internal? In what scenarios do I have to write something that uses it? If I do that, am I likely using Mouse sugar? -- rjbs

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

* Michael G Schwern schw...@pobox.com [2011-11-30T15:22:51] 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

Re: Perl QA Hackathon 2012

* Philippe Bruhat (BooK) philippe.bru...@free.fr [2011-11-03T20:25:25] Here are some news about the Perl QA Hackathon 2012. I have very little to offer other than: Good luck, this all sounds fantastic, and I hope I can make it! As others have said, the very expensive venue sounds very nice,

Re: Do we need subtests in TAP?

* Michael G Schwern schw...@pobox.com [2011-10-29T05:20:07] [ What if subtests stop indenting? ] Sorry, I'm quite late to the party. I really like the isolated planning of subtests, and the visual indenting, and (least of the three) the potential for building a better visualizer that works with

Re: QA hackathon 2012

* David Golden xda...@gmail.com [2011-08-22T22:23:42] On Mon, Aug 22, 2011 at 7:07 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 da...@cpan.org wrote: To the usual suspects on this list, especially the ones who could not attend the last times: when do you have time around April? (Traditionally, the QA hackathon is

Re: Vague Testing

* Ovid publiustemp-perl...@yahoo.com [2011-02-17T07:43:16] It would be nice if this was a custom comparator for Test::Deep, then you would be apply the almost to lists of arbitrarily complex items and also conduct that test at any level of the data structure (including nesting if you

Re: QA hackathon 2011: date poll

* Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 da...@cpan.org [2011-01-21T15:40:37] this year's prospective date for the QA hackathon in Amsterdam is 16-18 April. Please reply until Monday morning European time whether this is suitable for you, or you would rather have a different date. Those dates are great for me.

writing tests in an OO paradigm with Test::Routine

I've recently uploaded my new Moose-based system for writing reusable test behavior. I'm very happy with it so far and hope that it can be useful to others, too. I have written about the system and how it works, with links to further material, here: http://rjbs.manxome.org/rubric/entry/1858

Re: Test::Differences and utf8

* Michael Peters mpet...@plusthree.com [2010-02-02T11:13:26] Maybe have the option to UTF8 stdout/stderr and just send the characters and let the display handle it. But I don't think it should be the default. Unicode is tricky and lots of unicode characters can be combined in ways that look

Re: camels

* Pedro Figueiredo m...@pedrofigueiredo.org [2010-01-03T07:06:19] On Sun, Jan 3, 2010 at 11:40 AM, chromatic chroma...@wgz.org wrote: If the design of perl.org had been up to me, I'd have spent much more time promoting the Perl brand instead of the proprietary brand of a privately held

Re: camels

* Shawn H Corey shawnhco...@gmail.com [2010-01-03T07:22:01] Leo Lapworth wrote: Maybe someone could get a grant to hire someone/a company with design skills to come up with a better logo than the onion? I always thought that something to do with pearls would be nice. The problems with

Re: standard for internal-only tests?

* Jonathan Swartz swa...@pobox.com [2009-07-31T14:57:04] Justin Devuyst kindly pointed me to Module::Install::AuthorTests which appears to have the desired behavior if one is using Module::Install (which I happen to be). Thanks again. ...as long as you're looking at AuthorTests, have

Re: Fluent tests?

* David Golden xda...@gmail.com [2009-06-30T14:46:47] Well, if you're doing interface design, one of the first things that comes to mind is that the name of the test should come first, not last. ...I basically liked everything you had to say here: test label goes here = is( $have, $want

Re: Calling All Test:: Authors

* Ovid publiustemp-perl...@yahoo.com [2009-06-30T10:21:24] The latest developer release of Test::More allows subtests. Subtests are great in that they solve a lot of problems in advanced Perl testing, but they have required a change in Test::Builder. Previously you could do stuff like this:

Re: Nested TAP

* Ovid publiustemp-perl...@yahoo.com [2009-04-06T04:35:41] Wondering if anyone's played with nested TAP yet and has any comments/requests/questions? Lot's of people have asked for it, so it would be good to make sure we've got it right before it's pushed out the door. I've given it a bit of a

Re: Nested TAP

* Ovid publiustemp-perl...@yahoo.com [2009-04-06T10:52:33] I thought it might be nice to give the group a description, but really just diagging a description should be good enough for me. I can wait for TAP 15 with preludes, envelopes, and the SWAK marker. Actually, you do a get

Re: test harness presentation layer plugins

* Michael G Schwern schw...@pobox.com [2009-03-31T18:22:50] What if display types could be provided informationally in the TAP stream. The stream could include: want: foo bar have: foo bar presentation: Some::Plugin With the plugin installed, the presentation layer could

test harness presentation layer plugins

I'm mostly sending this email because I had an idea, and it's late, and I don't want to forget. Today it occured to me that many Test:: extensions are more about better diagnostic output than better test comparison. This stinks: want: foo bar have: foo bar So you write some plugin that

Re: Public Humiliation and Kwalitee

* Salve J Nilsen [EMAIL PROTECTED] [2008-10-28T14:54:07] David Cantrell said: On Mon, Oct 27, 2008 at 01:40:03PM +0100, Salve J Nilsen wrote: I think _some_ kind of shaming should be allowed. Carrots are good, but sticks work too when applied in a respectable fashion. They might, but a

Re: App::Prove::History

* Andy Armstrong [EMAIL PROTECTED] [2008-09-19T05:24:40] I'd lean towards epoch for easier comparison on SQLite. I tend to use epoch in SQLite, too, but it's worth nothing that iso8601 is much easier for humans, and SQLite can compare either one pretty well, as 8601 strings are sortable. The

Re: Ignoring Non-Failures

* David E. Wheeler [EMAIL PROTECTED] [2008-09-03T13:27:08] http://cpantesters.perl.org/author/DWHEELER.rss Now that there's a new maintainer, I should send another email... this file, for me is so large (6,680,062 bytes) that my RSS reader times out trying to retrieve it. Ugh. -- rjbs

Re: JSON TAP Diagnostics?

* chromatic [EMAIL PROTECTED] [2008-08-20T13:59:14] Aren't these two separate concerns, human versus machine readability? The latter rarely respects ambiguity. Yes. Right now, there seem to be two pro-YAML arguments. (1) It's easier to for humans read. Sure. I will admit that. It is

Re: Test::Harness Output Change

* Ovid [EMAIL PROTECTED] [2008-08-21T05:36:11] Both of us found this much cleaner. However, this might have unexpected consequences. It also highlights the issue of Test::Harness's long-standing practice of stripping the .t extension from filenames. Why? If we want other extensions, stripping

Re: JSON TAP Diagnostics?

* Eric Wilhelm [EMAIL PROTECTED] [2008-08-21T12:46:59] # from Ovid 1. YAML is prettier. 2. JSON, unlike YAML, is stable. Let's not forget that the debated requirement for diagnostics is that the generators and consumers speak the same language Does it have to be just one? Now and

Re: Should MANIFEST go in the repository?

* Jeffrey Thalhammer [EMAIL PROTECTED] [2008-08-20T12:42:49] But there is some debate about whether the MANIFEST and other metafiles should be put in the source code repository. My gut feeling is that MANIFEST is a generated file, therefore it does not go in the repository. Instead,

Re: JSON TAP Diagnostics?

* Ovid [EMAIL PROTECTED] [2008-08-18T06:50:00] JSON is fairly well implemented and new implementations are trivial. This is not true for YAML. Trying to define a minimum standard of YAML for extended TAP is a quagmire. With JSON, we can punt and just point to a fairly well-established JSON

Re: JSON TAP Diagnostics?

* David Golden [EMAIL PROTECTED] [2008-08-18T09:27:57] What's the latest consensus on the best pure-perl JSON module? And ditto for JSON via XS? JSON and JSON::XS, most likely. Certainly JSON::XS. -- rjbs

Re: JSON TAP Diagnostics?

* Ovid [EMAIL PROTECTED] [2008-08-18T11:17:25] Oh, definitely agreed. I cannot assert that non-Perl implementations of JSON are any better, but JSON is simple enough that I'm pretty damned sure they are. However, YAML is so problematic that I *CAN* state that non-Perl versions are often as

Re: JSON TAP Diagnostics?

* Michael G Schwern [EMAIL PROTECTED] [2008-08-18T12:26:54] YAML types can be little more than local tags which only have meaning to that particular document. name: !customer Evil Business Guy Made Of Butter Yeah, that's neat and everything, but there aren't any Perl implementations that

Re: Have/Want

On Aug 6, 2008, at 20:12, Michael G Schwern wrote: So I encourage folks to use have and want in the future. I'll be using them in Test::Builder2. Test.php updated and released. -- rjbs

Re: Have/Want

* David E. Wheeler [EMAIL PROTECTED] [2008-08-07T00:31:27] On Aug 6, 2008, at 20:12, Michael G Schwern wrote: So I encourage folks to use have and want in the future. I'll be using them in Test::Builder2. Good call. Change committed to pgtap and Test.Builder. and PyTAP, which might

AndyL reports HARNESS_TIMER broken

His email is bustified. http://rafb.net/p/vD8hRk81.html FWIW, I get the same results. -- rjbs

Re: New CPANTS metrics

* brian d foy [EMAIL PROTECTED] [2008-06-10T12:27:29] I'd like to see the metircs that only talk about the quality of the distribution, and leave everything else alone. If it's something I can fix by doing something to the distribution itself, measure it. If it's anything else, leave it out.

Re: User Supplied YAML Diagnostic Keys: Descriptive Version

* Michael G Schwern [EMAIL PROTECTED] [2008-04-11T07:01:19] Here's the descriptive way to specify how the diagnostic keys work. 1) We reserve every key which begins with a lower case letter 2) We say nothing about anything else 3) All keys are optional I thought this had been the

Re: Friday afternoon in Oslo

* David Golden [EMAIL PROTECTED] [2008-03-31T10:07:57] On Mon, Mar 31, 2008 at 9:36 AM, Andy Armstrong [EMAIL PROTECTED] wrote: I'm getting in on Thursday night - so I'll be around. Just planning to wander around taking pictures but could be persuaded by something more structured :)

Re: Hackathon logistics

* Michael G Schwern [EMAIL PROTECTED] [2008-03-26T04:15:47] Not trying to cause repo-wars, but I think I'll need to use git actively for something before I really start to grok it. I had the same thoughts. My concern is that we'll be spending time futzing with git rather than hacking on QA

new module, Pod::Coverage::TrustPod

After having this task languish in my todo for years, at least, I have finally reduced my goal to the important 90% and applied some JFDI. Pod::Coverage::TrustPod acts like Pod::Coverage::CountParents, but accepts non-whitespace lines inside Pod::Coverage POD targets as trustme instructions. In

Module-Faker and CPAN-Faker (RIP EU::FakeMaker)

First, ExtUtils::FakeMaker is now Module::Faker. Schwern suggested that ExtUtils should no longer be used, and gave excellent reasoning, summed up here: http://www.perlfoundation.org/perl5/index.cgi?extutils So, that's done. There haven't been any changes worth mentioning, yet, in its

ExtUtils::FakeMaker 0.001 uploaded

Lately, we're doing a lot of work on some for-now internal tools that operate on CPAN archives as a whole. They're sort of like CPAN::Mini and CPAN::Mini::Inject, writ large. Doing stuff like unpacking an entire CPAN mirror to analyse its contents and prereqs is a real drag, though. We also

Re: author tests with Module::Install::AuthorTests

* Eric Wilhelm [EMAIL PROTECTED] [2008-02-25T12:53:03] # from Ricardo SIGNES # on Monday 25 February 2008 04:59: Basically, it lets you say author_tests('xt') in your Makefile.PL (using Module::Install) to have a directory (or directory tree) of tests run only by the module's authors

author tests with Module::Install::AuthorTests

I thought I'd relay my journal post here: http://use.perl.org/~rjbs/journal/35746 Basically, it lets you say author_tests('xt') in your Makefile.PL (using Module::Install) to have a directory (or directory tree) of tests run only by the module's authors. -- rjbs

Re: phalanx - Getting involved

* Miguel Pignatelli [EMAIL PROTECTED] [2008-01-08T10:10:00] Is there a possibility of getting involved in the phalanx project?. I'm a regular Perl user trying to improve his knowledge and being able to help the community. Absolutely. A very simple way to do this is to pick a distribution

Re: Parsing TAP into TAP

* Andy Armstrong [EMAIL PROTECTED] [2007-12-10T11:52:33] On 10 Dec 2007, at 16:49, Ovid wrote: Seems Ricardo Signes likes this idea, too: http://use.perl.org/~Ovid/journal/35076 Who? :) :'( I like this idea so much that if you point me at a repo and failing tests, I will try

new test module, Test::BinaryData

http://search.cpan.org/dist/Test-BinaryData/lib/Test/BinaryData.pm I won't rehash the whole documentation here, but the gist is that I really hate getting test reports that say: not ok 1 # Failed test in demo.t at line 8. # got: 'foo # bar # ' # expected: 'foo #

Re: new test module, Test::BinaryData

* Michael Peters [EMAIL PROTECTED] [2007-07-21T09:07:42] Ricardo SIGNES wrote: http://search.cpan.org/dist/Test-BinaryData/lib/Test/BinaryData.pm Did you know that Test::LongString (despite the name) can handle binary information too? Probably not as detailed as your diagnostics

Re: podcoverage vs pragmatism

* Eric Wilhelm [EMAIL PROTECTED] [2007-04-09T16:31:31] # from Ricardo SIGNES # on Monday 09 April 2007 05:10 am: I need to finish/test/release my PC subclass that looks at @PKG::POD_COVERAGE_TRUSTME. I saw that in rt, but I really think pod is the place for it. Why clutter the code

Re: .t files as specs

* James E Keenan [EMAIL PROTECTED] [2007-06-19T21:33:11] But, guess what? To the extent that I've been able to determine my own approach to development, I have increasingly moved in the direction of doing step 1 first: documentation-driven development. Or, perhaps more precisely,

Re: The most important TAP tasks.

* Michael G Schwern [EMAIL PROTECTED] [2007-03-09T18:17:57] *) TAP diagnostic format http://perl-qa.yi.org/index.php/TAP_diagnostic_syntax There is no way to output diagnostics in TAP. The stuff Test::More spits out to STDERR are unparsable comments indented for humans. Its not TAP. This

Re: Custom extensions to META.yml

* brian d foy [EMAIL PROTECTED] [2007-03-04T12:09:26] I'm not talking about the particular field name, but the idea that I'd want to say in META.yml Don't send me mail, or whatever setting I want. Instead of having to disable (or enable) CC for every new tool, I'd want a setting that new

Re: Custom extensions to META.yml

* brian d foy [EMAIL PROTECTED] [2007-03-03T13:31:15] In article [EMAIL PROTECTED], Ricardo SIGNES [EMAIL PROTECTED] wrote: extensions: CPAN::Reporter: cc_author: 0 I think in some cases this might work, but I can imagine options that I'd want, such as cc_author

Re: a safer way to use no_plan?

* Eric Wilhelm [EMAIL PROTECTED] [2007-03-03T21:59:32] In fact, so much eyewringing that I've taken to this lately: use inc::testplan(0, + 3 # use + 199 # those others ); What is that ... for? I often do this: use Test::More; my @test_data =

Re: Custom extensions to META.yml

* David Golden [EMAIL PROTECTED] [2007-02-28T22:39:01] Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. Why not: extensions: CPAN::Reporter:

Re: ExtUtils::MakeMaker, and t/ sub-directories

* Adam Kennedy [EMAIL PROTECTED] [2007-02-08T19:17:39] Yep, although M::I has some capacity to add a but of extra magic if you could come up with a workaround (like having File::Find locate them all and provide a complete list of TESTS). I do this in

Re: Comment about BAIL_OUT

* Ovid [EMAIL PROTECTED] [2007-01-04T16:34:31] I guess the reason I have never used BAIL_OUT is because if I have a bunch of tests failing, they fail quickly and I don't have to wait for them :) I suppose it's not that big of a deal, but I noticed it this evening and thought I would toss it

  1   2   >