Re: Devel::Cover better practice to identify uncovered files

On 04/18/2017 07:43 PM, Jason Pyeron wrote: Currently we are using this script to find files (line 48) under the scripts directory and add them to the coverage report. After running the programs under test, the script is run: $ ./tests/script/cover-missing.pl load ingest 17 known covered file(

Re: Devel::Cover missing lines?

On 04/18/2017 12:32 PM, Jason Pyeron wrote: I am "require"ing a file but Devel::Cover is not logging the statements, only the sub, use, and eval portions. Exactly *which* statements is it not logging which you believe should be logged? I've been using Devel::Cover for 13 years. I would not

Re: Updated CPAN River available

On 04/16/2017 09:46 PM, Ricardo Signes wrote: * 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

Re: Updated CPAN River available

On 04/09/2017 08:54 PM, James E Keenan wrote: On 04/09/2017 11:33 AM, James E Keenan wrote: An updated printout of the CPAN River is available here: https://gist.github.com/jkeenan/a7670b2ffe1ffe3e8d8cbdbc2b3dd721 Today I began a fifth round of testing. As in the previous round of

Re: Updated CPAN River available

On 04/09/2017 09:03 PM, Kent Fredric wrote: On 10 April 2017 at 12:54, James E Keenan wrote: 7. Used a revised version of 'order-battle.pl' to record the order in which various modules *first* appeared in the 'fails' file and the total number of times each module wa

Re: Updated CPAN River available

On 04/09/2017 11:33 AM, James E Keenan wrote: An updated printout of the CPAN River is available here: https://gist.github.com/jkeenan/a7670b2ffe1ffe3e8d8cbdbc2b3dd721 Using this data we can conduct a fourth round of testing. Today I began a fourth round of testing. I am doing so to

Updated CPAN River available

An updated printout of the CPAN River is available here: https://gist.github.com/jkeenan/a7670b2ffe1ffe3e8d8cbdbc2b3dd721 This is an update of the data presented by David Golden in 2016 here: https://gist.github.com/xdg/af7a32c5b21d45a6b255 I have chosen to present this in .csv format to make

Re: BBC testing from upriver downwards

On 04/04/2017 07:24 PM, Kent Fredric wrote: On 5 April 2017 at 10:35, James E Keenan wrote: Module::Runtime was successfully installed all three times -- though that's actually two times, because my first run used an earlier perl 5 blead commit. Each of the three runs used a diff

Re: BBC testing from upriver downwards

On 04/04/2017 05:37 PM, Kent Fredric wrote: On 5 April 2017 at 08:28, James E Keenan wrote: the tip of the order of battle looks substantially different I must say though, your results confuse me. In my testing, the things that are holding back the most are ... Module::Runtime , and Task

Re: BBC testing from upriver downwards

On 03/30/2017 04:36 PM, James E Keenan wrote: [snip] 7. Wrote second perl program (attached) called 'order-battle.pl' to record the order in which various modules *first* appeared in the 'fails' file and the total number of times each module was cited. Results are attached

Re: BBC testing from upriver downwards

On 03/30/2017 05:16 PM, Kent Fredric wrote: On 31 March 2017 at 09:36, James E Keenan wrote: For example, today David Golden prepared a new version of Sub::Uplevel -- the #1 distro in the order of battle. Once he releases that to CPAN, a tremendous number of downstream distros will have their

Re: BBC testing from upriver downwards

On 03/20/2017 09:32 PM, James E Keenan wrote: On 03/17/2017 09:42 PM, Karen Etheridge wrote: ​> ​ 1. Compose a list of CPAN distros starting with those farthest up river, i.e., distros that only depend on the perl 5 core. Within that set of distros I'd like to order them from most

Re: BBC testing from upriver downwards

On 03/17/2017 09:42 PM, Karen Etheridge wrote: ​> ​ 1. Compose a list of CPAN distros starting with those farthest up river, i.e., distros that only depend on the perl 5 core. Within that set of distros I'd like to order them from most reverse dependencies to fewest. Then go down river from the

BBC testing from upriver downwards

perl-5.25.11 will be released on Monday March 20. Since this will be the first monthly dev release to reflect the banishment of '.' from the default @INC, it is the first monthly release in which we can assess the effect of that change on CPAN. Up until now we've mainly relied on Andreas and

Re: Test::Smoke failing to test most recent commit to Perl 5 blead

On 01/29/2017 11:37 AM, demerphq wrote: I have some further comments in the other thread. Nothing that needs to stop your patch from being applied, but I noticed some stuff I found quite surprising, although I only did a quick scan so I very well may be talking out my ass in that thread. Yves

Re: Test::Smoke failing to test most recent commit to Perl 5 blead

On 01/27/2017 10:58 PM, demerphq wrote: On 28 Jan 2017 6:32 a.m., "James E Keenan" mailto:jk...@verizon.net>> wrote: On 01/14/2017 10:10 AM, James E Keenan wrote: Here is the first part of the smokecurrent.log for this run -- with some comments: # [201

Re: Test::Smoke failing to test most recent commit to Perl 5 blead

On 01/14/2017 10:10 AM, James E Keenan wrote: On 01/13/2017 11:25 PM, James E Keenan wrote: The most recent smoke testing of Perl 5 blead I have conducted in my FreeBSD-10.3 VM is that found at: Here is an additional instance of the problem, which I have reported as: https://rt.cpan.org

perl5.test-smoke.org feature request: explanation of git-id

When you go to http://perl5.test-smoke.org/search, one of the columns presented is "Git-id". Its contents look like this: v5.25.8-269-g01f9673 v5.25.8-196-g3626fc2 v5.25.8-208-g05053e2 v5.25.8-260-g57b3a6b6ec What these strings mean is not entirely self-evident. I can infer that 'v5.25.8' me

perl5.test-smoke.org feature request: order by column

When you go to http://perl5.test-smoke.org/search, you see a table whose columns are these: ArchHostOS Git-id Smoke date Status AFAICT, you have no ability to select the way the rows in the table are ordered. It appears that the sorting is done on the columns in left-to-ri

Re: Test::Smoke failing to test most recent commit to Perl 5 blead

On 01/13/2017 11:25 PM, James E Keenan wrote: The most recent smoke testing of Perl 5 blead I have conducted in my FreeBSD-10.3 VM is that found at: http://perl5.test-smoke.org/report/53193 The commit tested there was 3626fc2020b81652c4b3c7dd5ef0822b194d2d5e: # commit

Test::Smoke failing to test most recent commit to Perl 5 blead

The most recent smoke testing of Perl 5 blead I have conducted in my FreeBSD-10.3 VM is that found at: http://perl5.test-smoke.org/report/53193 The commit tested there was 3626fc2020b81652c4b3c7dd5ef0822b194d2d5e: # commit 3626fc2020b81652c4b3c7dd5ef0822b194d2d5e Author: Karl Williamso

Devel::Cover broken on Perl 5 blead

Devel::Cover is failing to build on most versions of Perl 5 blead (5.25.-*). See http://matrix.cpantesters.org/?dist=Devel-Cover, where most reports are ending as UNKNOWN or FAIL for 5.25.2 and later. Today, while testing the proposed -Ddefault_inc_excludes_dot switch, I build perl 5, install

Re: CPANifying our test framework - or parts of it

On 09/09/2016 09:34 PM, Sam Kington wrote: Hi, At $WORK we have an extensive test suite that we’ve built up over the years, with loads of convenience methods for calling e.g. Dancer endpoints and checking returned data structures against what we expect. One of our dev team recently left for p

Re: Why does File::Path not respond to 'cover'?

015 at 10:08 PM, James E Keenan wrote: Richard Elberger and I recently received co-maintenance bits on the File-Path distribution. As is my wont, I ran it through Devel::Cover -- but was surprised to see that 'cover' reported zero coverage. Does anyone know why File-Path is unrespons

Why does File::Path not respond to 'cover'?

Richard Elberger and I recently received co-maintenance bits on the File-Path distribution. As is my wont, I ran it through Devel::Cover -- but was surprised to see that 'cover' reported zero coverage. # $ perl Makefile.PL && make Generating a Unix-style Makefile Writing Makefile for File:

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

On 04/26/2015 12:15 AM, Chad Granum wrote: I am not sure it is entirely my decision. If it is entirely my decision than this is it: Must have a working scalar::util::weaken to use the new Test::Simple. The Test-Simple dist itself will not require a c compiler to install, as in no xs is included i

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

On 04/25/2015 05:57 PM, bulk88 wrote: 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, is my understand

New York City Perl Hackathon

As some readers of this list already know, two weeks after the upcoming Perl QA Hackathon in Berlin we are having a more locally based hackathon in New York City: the Second New York City Perl Hackathon. Our wiki starts here: https://github.com/nyperlmongers/nyperlhackathon2015/wiki Having

Re: hackathon web page displays strangely

On 03/23/2015 02:08 PM, Tina Müller wrote: I got another solution from Bjoern: #content { width: calc(100% - 450px) } which I chose since it was easier than the one from Lasse ;-) Works for me on chrome and FF (also on my phone) WFM Thanks for taking the time to investigate this. jimk

Re: hackathon web page displays strangely

On 03/21/2015 09:45 AM, Shlomi Fish wrote: Hi James, On Sat, 21 Mar 2015 08:51:42 -0400 James E Keenan wrote: http://act.qa-hackathon.org/qa2015/main In Firefox, at least, all the pages on this site are displaying in a strange way. Each page has a left sidebar with internal links and a

hackathon web page displays strangely

http://act.qa-hackathon.org/qa2015/main In Firefox, at least, all the pages on this site are displaying in a strange way. Each page has a left sidebar with internal links and a right sidebar with sponsors. But the main content for each page only starts to appear *below* the end of the longer

Re: Final TPF Devel::Cover grant report

On 10/07/2014 05:42 PM, Paul Johnson wrote: In accordance with the terms of my grant from TPF this is the final report for my work on improving Devel::Cover. What a long, strange trip it's been! Since the last report I have released versions 1.16 and 1.17. The stable release of perl 5.20.1

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

On 1/30/14 10:25 PM, Leon Timmermans wrote: On Fri, Jan 31, 2014 at 1:59 AM, Torbjørn Lindahl< torbjorn.lind...@gmail.com> wrote: 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 save me one ,

Re: New Test::Builder version broke Test::ParallelSubtest

On 1/13/14 6:55 PM, Jan Seidel wrote: I initially skipped this as I saw another open bug that hasn't been addressed since 2 years now. But I agree that for tracking purposes it is nonetheless a good idea to open a bug: https://rt.cpan.org/Public/Bug/Display.html?id=92119 Heh! Even much mor

Re: TPF Devel::Cover grant report July 2013

On 9/1/13 10:53 PM, Ricardo Signes wrote: * Paul Johnson [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

Testing coverage-related work at 2013 Perl QA Hackathon

The following was posted at http://2013.qa-hackathon.org/qa2013/wiki?node=Achievements, but I figured that it should be posted on-list as well. ## At the 2013 Perl QA Hackathon in Lancaster, England, testing coverage-related issues were handled by several participants, including the

Devel::Cover path analysis not present

In Devel/Cover.pm's documentation, I read: # =head1 OPTIONS -blib - "use blib" and ignore files matching \bt/ (default true iff blib directory exists). -coverage criterion - Turn on coverage for the specified criterion. Criteria include statement, branch, condition, path,

QA Site pages need updating

These are non-wiki pages which lack useful information: http://2013.qa-hackathon.org/qa2013/venue.html http://2013.qa-hackathon.org/qa2013/news This one has one bind variable needing filling in: http://2013.qa-hackathon.org/qa2013/accommodation.html

Booked by Organisers: which nights

Re: http://2013.qa-hackathon.org/qa2013/wiki?node=Accommodation, specifically, the section: "Booked by Organisers" What nights are covered by this booking? I ask because I may want to arrive in Lancaster on Wed, Apr 10, and if I do I'd like to stay at the same hotel we're using for the event.

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

On 2/11/13 4:56 PM, Paul Johnson wrote: On Wed, Jan 02, 2013 at 10:39:21PM -0500, James E Keenan wrote: So, thanks again for making this coverage available, and let me recommend that you include all packages included with the Perl 5 core. That's a great suggestion. I have done just

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

On 1/2/13 9:36 AM, Paul Johnson wrote: 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. This report covers 08.12 to 28.12. Last week I mentioned the pull requests I had received. I this week I merged a pull request from

Re: Feedback on the undocumented --rules option for 'prove'

On 8/19/12 1:07 PM, James E Keenan wrote: And it's not alone in being undocumented. Go to http://search.cpan.org/~ovid/Test-Harness-3.25/lib/App/Prove.pm#Attributes and note that 'rules' is one of over 40 attributes which are described as existing but are otherwise undocumented.

Re: Feedback on the undocumented --rules option for 'prove'

On 8/17/12 3:53 PM, Mark Stosberg wrote: In 2008 Alex Vandiver contributed a patch to "prove" that allowed you to specify that you wanted some tests to run in parallel and others in serial. This is a great feature for those of us with large test suites that would like to test advantage of parall

Re: Test::Builder2: running coverage fails to display key modules

On 8/4/12 11:34 AM, James E Keenan wrote: On 8/4/12 11:16 AM, James E Keenan wrote: On 8/4/12 10:54 AM, Paul Johnson wrote: How did you generate your coverage report? Main part of my shell script: cd $SOURCEDIR && \ cover -delete $COVERAGEDIR && \ PERL5OPT=-MDevel::Cover=

Re: Test::Builder2: running coverage fails to display key modules

On 8/4/12 11:16 AM, James E Keenan wrote: On 8/4/12 10:54 AM, Paul Johnson wrote: How did you generate your coverage report? Main part of my shell script: cd $SOURCEDIR && \ cover -delete $COVERAGEDIR && \ PERL5OPT=-MDevel::Cover=-db,$COVERAGEDIR/ \ perl Makefile.PL &

Re: Test::Builder2: running coverage fails to display key modules

On 8/4/12 10:54 AM, Paul Johnson wrote: How did you generate your coverage report? Main part of my shell script: cd $SOURCEDIR && \ cover -delete $COVERAGEDIR && \ PERL5OPT=-MDevel::Cover=-db,$COVERAGEDIR/ \ perl Makefile.PL && make && make test && \ cover $COVERAGEDIR \ -coverage sta

Test::Builder2: running coverage fails to display key modules

When I run Devel::Cover over the Test::Builder2 test suite (v1.005000_001-193-g00d4609), I get no coverage reports for blib/lib/Test/Builder2.pm or blib/lib/Test/More.pm. See: http://thenceforward.net/test-more/coverage/coverage.html Any thoughts on why that is happening? Thank you very much

Re: Devel::Cover: uninitialized value warning in 'cover'

On 6/4/12 2:46 PM, Matthew Horsfall (alh) wrote: On Sat, Jun 2, 2012 at 11:49 AM, James E Keenan wrote: Use of uninitialized value $Devel::Cover::Ignore_filenames in regexp compilation at /usr/local/lib/perl5/site_perl/5.16.0/i686-linux/Devel/Cover/DB.pm line 882. On a side note, I'

Devel::Cover: uninitialized value warning in 'cover'

As I have described previously, I use Devel::Cover to measure the extent to which parts of the Parrot virtual machine's test suite exercises certain Perl 5 programs and modules in Parrot's configuration and build systems. Today for the first time I noticed this uninitialized value warning, whi

Re: TPF Devel::Cover grant report Week 1

On 5/28/12 7:48 PM, Paul Johnson wrote: What is this? You may recall that recently I submitted a grant proposal to The Perl Foundation to work on Devel::Cover. [snip] So, the work I have completed in the time covered by this report is: Closed RT tickets: 75944 Warning about Moose clearer

Re: Devel::Cover problem: getting analysis of .xs file but not of .pmfile

On 4/25/12 9:08 PM, James E Keenan wrote: Friends, Can anyone advise as to why I am getting coverage analysis of Util.xs but not of lib/Hash/Util.pm? Locking %ENV frustrates Devel::Cover. Starting at approximately line 172 of t/Util.t, we have a test which, after I've reformatted

Devel::Cover problem: getting analysis of .xs file but not of .pm file

Friends, As an extension of my work on https://rt.perl.org/rt3/Ticket/Display.html?id=112126, I am trying to measure the test coverage for Perl 5 core distribution Hash-Util provided by the Perl 5 test suite. For ease of development, I have copied ext/Hash-Util/lib/Hash/Util.pm and ext/Hash-

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

On 4/11/12 12:33 PM, Michael G Schwern wrote: Let me reiterate, I have no plans to *deprecate* `use_ok`. Even if I wanted to there are simply too many users to make deprecation worth while. It works fine if what you want is a runtime require + import + assert, and sometimes you want that. The

Re: Perl QA Hackathon: What was accomplished?

On 4/6/12 9:14 PM, David Golden wrote: I don't know if this page is on the main page, yet, but this is the running summary page: http://2012.qa-hackathon.org/qa2012/wiki?node=Results Thanks, that's what I was looking for. But it would also be good to have a write-up on this list, since a p

Perl QA Hackathon: What was accomplished?

Could someone post a summary of what was done/not done at this year's QA hackathon in Paris (http://2012.qa-hackathon.org/qa2012)? Thank you very much. Jim Keenan

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

On 3/14/12 10:30 PM, Michael G Schwern wrote: > > Is it possible you had a pre-existing cover_db directory? No. Since, to the best of my knowledge, Devel::Cover had never been installed on this machine, I had never tried to run 'cover' on it. > > On 3/15/12 9:07 AM, Paul Johnson wrote: Cl

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

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

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

On 11/16/11 2:15 AM, Michael G Schwern wrote: That's the task. Write a TAP version 12 formatter. 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

Re: Dual life t/test.pl?

On 11/14/11 7:59 PM, Michael G Schwern wrote: 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 undocumen

Re: What does t/test.pl do?

On 11/5/11 4:21 PM, Michael G Schwern 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 separa

What does t/test.pl do?

In a github issue (https://github.com/schwern/test-more/issues/73), Michael Schwern argued that Test::Builder2 ought to be tested with a "completely unrelated test system. We have one, t/test.pl from the Perl core." I thought to myself, "How difficult could that be?" I vaguely remembered tes

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

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-Builder2&sort=created&direction=desc&state=open&page=1 I will start to look at these ... but would these be suitable for Google Code-In s

Re: Can TAP::Harness::Archive be made to play well with TAP::Parser::Aggregate

This is now available on CPAN: http://search.cpan.org/dist/TAP-Harness-Multiple/ Tested on Linux and Darwin but not yet on Windows. Thank you very much. Jim Keenan

Re: Do we need subtests in TAP?

On 10/25/11 11:56 PM, Michael G Schwern wrote: I keep looking at subtests and keeping thinking that if there wasn't a test count to manage, would we need subtests? Do we need all that complexity? If it's just about the test count, can it be managed a better way? I haven't followed this discu

Re: Can TAP::Harness::Archive be made to play well with TAP::Parser::Aggregate

On 10/22/11 12:54 PM, James E Keenan wrote: I have now achieved this in the kid51/testsets2 branch of Parrot. This should yield two new modules for CPAN. Details to come. Development is proceeding here: https://github.com/jkeenan/TAP-Harness-Multiple

Re: Can TAP::Harness::Archive be made to play well with TAP::Parser::Aggregate

On 10/16/11 10:33 PM, James E Keenan wrote: For certain modifications to the Parrot project's smoke testing mechanism, I need to create an archive from an aggregation of test harnesses and then send that archive to our smoke server. Has anyone tried to combine these two modules with

Re: Can TAP::Harness::Archive be made to play well with TAP::Parser::Aggregate

On 10/16/11 10:33 PM, James E Keenan wrote: However, we don't simply want to print this information to the console. When our harness is passed '--archive --send-to-smolder', we want the *aggregated* test output to be archived and transmitted to our smoke server. Unfortunat

Can TAP::Harness::Archive be made to play well with TAP::Parser::Aggregate

For certain modifications to the Parrot project's smoke testing mechanism, I need to create an archive from an aggregation of test harnesses and then send that archive to our smoke server. Currently, we create an archive from just a single run of a given testing target. So we have a 'make smo

Re: Devel::Cover 'time' html column

On May 25, 2010, at 3:32 PM, Paul Johnson wrote: Certainly you should be using NYTprof for anything serious in this area, but it didn't exist when I first wrote this code. Now it does, I'm considering removing the time coverage. Does anyone have any thoughts one way or the other about th

Re: Devel::Cover 'time' html column

Dan MacNeil wrote: What information is in the 'time' column ? Like you, I could not find any information about this in any of: perldoc Devel::Cover perldoc cover perldoc Devel::Cover::Tutorial ISTR a post by Paul Johnson about this a few years back. You might want to search the Google

Re: qa.perl.org

Leo Lapworth wrote: Hi, Please note this is cross posted. Several of the QA people have kindly said they will help with updating http://qa.perl.org/. 3) Phalanx Though in one sense it pains me to say it, Phalanx does not need to be a major tab. It can be demoted to a link somewhere. The

Re: Test::More, Test::Builder, Test::Simple now on github

Michael G Schwern wrote: After wrestling some alligators, Test::More's repository now on github. Please feel free to clone, push, pull, fork or whatever it is you kids do these days. http://github.com/schwern/test-more/tree/master Does this imply that the Test::More repository on googlecode i

Devel::Cover: metadata about files being reported on

At http://thenceforward.net/parrot/coverage/configure-build/coverage.html I have for over a year displayed the results of coverage analysis on Parrot's configuration and build tools. I have come to realize that while these reports are very useful for me as the maintainer of the Perl 5 aspect

Re: Devel::Cover anomaly: Double reporting of statement coverage

Paul Johnson wrote: If you delete all the coverage information and start from scratch does that "solve" the problem? Problem was reproduced: http://thenceforward.net/parrot/coverage/configure-build/config-auto-pmc-pm.html

Re: Devel::Cover anomaly: Double reporting of statement coverage

Paul Johnson wrote: There does seem to be something rather strange going on here. The results for the unshift a few lines earlier are also duplicated. Yes, I noticed that after the OP. But more stragely, the statement counts on lines 109 and 124 seem somewhat excessive. My best guess

Devel::Cover anomaly: Double reporting of statement coverage

In the attachment, I show several lines from this file coverage report on a Perl 5 module in the Parrot distribution: http://thenceforward.net/parrot/coverage/configure-build/config-auto-pmc-pm.html http://tinyurl.com/5fovnc Two statements, lines 261-262, each of which is a simple 'push'.

Re: Rebuilding the Test::Builder community

Michael G Schwern wrote: Next step is to get people who want to contribute to the project signed up as project members. To do this, please send me your Google account email address. And a reminder to those who have signed up: When you go to do your initial 'svn co', the password you us

Re: cpants.perl.org giving 404 not founds

Paul Fenwick wrote: G'day QA folks, Just wanted to report that: http://cpants.perl.org/ is presently giving me 404 (not found) errors. Appears fixed as of the time of this message.

Re: best practices for temporary files during testing

Gabor Szabo wrote: Should I just use File::Tempdir ? I haven't yet explored File::Tempdir. But File::Temp has the advantages of being core, having both functional and OO interfaces, and widely used. We use it extensively in testing Parrot -- and just tonight I converted one case where

Re: Non-standard use of Devel::Cover

Rick Fisk wrote: Has anyone been successful with producing meaningful coverage reports when the test files are in a non-standard location? Any help would be appreciated. If you make judicious use of the command-line options to cover, as well as to Devel::Cover's own options, you can probably

YA Hackathon Topic: Help Improve Parrot's Smoke Testing

If by some chance you run out of things to hack on, you can help out the Parrot project by taking a look at our smoke testing system -- specifically, its reliance on, and hackish overriding of, two CPAN modules. http://perl-qa.hexten.net/wiki/index.php/Oslo_QA_Hackathon_2008_:_Topics#Improve_Pa

Re: Hackathon logistics

Michael G Schwern wrote: My concern is that we'll be spending time futzing with git rather than hacking on QA stuff. We all know SVN/SVK and can stand to use it for a little while longer. Agreed. One hackathon I attended wasted one-third of the participants' available time because ever

Re: My Perl QA Hackathon Wishlist

On Mar 25, 2008, at 2:57 PM, Salve J Nilsen wrote: Feel free to show up! Those who do get to decide what to do. ;-) Unfortunately I'm an ocean away and between lack of vacation time and the decline of the US$, I won't be able to attend. Which is why it was a wishlist! But I do follow

My Perl QA Hackathon Wishlist

1. A "canned" training session, "Learn Test::Harness 3.0," that would provide the user with a guided tour of T::H 3+ and have him/her actually type and run examples of the new functionality. "Canned" in the sense that at a local Perlmongers meeting everyone could download a tarball and work t

Perl Testing and QA at YAPC::NA::2008 in Chicago, June 16-18

A couple of points about YAPC::NA: 1. It's almost two weeks earlier this year than it has been in the past three years. So if your mental clock has been set to "3 days of YAPC + 2 days of hackathon + 3-day 4th-of-July weekend" (as mine has), please reset that clock. 2. Consequentially, th

Re: Providing command-line arguments to tests run via 'prove'

James E Keenan wrote: I would like to be able to provide the tests run via 'prove' with options something like this: some_variant_of_prove t/*.t --option1 --option2 arg1 arg2 ... where those 4 command-line options/arguments would be available to *each* of the individual tes

Re: CPANTS Site Seems... Confused

Thomas Klausner wrote: which wasn't proof-read by any english speaking person yet, so if @you want to: patches welcome ;-) s/not longer dreadlocked/no longer dreadlocked/

Re: buildbot - an experiment

David Cantrell wrote: On Tue, Jan 01, 2008 at 08:23:52PM -0500, James E Keenan wrote: David Cantrell wrote: If anyone can give me an idiots' guide to how to grab the most recent source tree, build it, and test it, then I can test it on the same boxes as I do CPAN testing, plus maybe a c

Re: buildbot - an experiment

David Cantrell wrote: On Sat, Dec 29, 2007 at 05:51:50PM -0500, James E Keenan wrote: If anyone can give me an idiots' guide to how to grab the most recent source tree, build it, and test it, then I can test it on the same boxes as I do CPAN testing, plus maybe a couple of others. s

Re: buildbot - an experiment

Matisse Enzer wrote: I've spent some of this holiday season learning how to set up BuildBot (http://buildbot.net/) which is a Continuous Integration system that is especially aimed at open-source style projects: You set up a central "build master", and one or more "build slaves" - and it is very

Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received

Ovid wrote: --- Dave Rolsky <[EMAIL PROTECTED]> wrote: [snip] I think there's some truth to this view. For support I submit this bug ticket - http://rt.cpan.org/Ticket/Display.html?id=27208 Sorry Dave, but I understand Imacat's point of view. I think part of the issue is that English is not

Re: Fwd: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi6.2-release' has NOT been received

Michael G Schwern wrote: As for the social problem, the BSD testers could try to help out with whatever the problem is. On Marc's side he could ask for help instead of asking everyone to turn off the immensely useful automated testing. Not to excuse what Marc's automated response said but

Re: Milton Keynes PM coding collaboration

Edwardson, Tony wrote: Anyone written any CPAN modules for which the testing coverage needs to be improved ? [snip] Something from http://qa.perl.org/phalanx/ would be good Aspiring hoplites, I salute you! You can read about the adventures of grizzled veter

Providing command-line arguments to tests run via 'prove'

Let's suppose that I have a suite of test files which I customarily run with 'prove': prove t/*.t ... where the tests in t/ are: alpha.t beta.t gamma.t Let's further suppose that each of these three tests simulates the operation of a Perl program which is normally called with command

Re: Devel::Cover Oddity: "Test returned status 0 ... after all subtestscompletedsuccessfully"

James E Keenan wrote: James E Keenan wrote: James E Keenan wrote: t/configure/029-option_or_datadubious Test returned status 0 (wstat 11, 0xb) after all the subtests completed successfully I'm still in much the same situation as I was last month.

Re: Devel::Cover Oddity: "Test returned status 0 ... after all subtestscompletedsuccessfully"

James E Keenan wrote: James E Keenan wrote: t/configure/029-option_or_datadubious Test returned status 0 (wstat 11, 0xb) after all the subtests completed successfully This problem is maddening because it is intermittent. After not appearing for more

Re: Planning talk on Devel::Cover

On Sep 21, 2007, at 10:35 AM, Paul Johnson wrote: Actually, the options Michael gave *are* for Devel::Cover itself. There are similar (but slightly different - and I hate that) options for cover. Well, then, I'm glad I began this thread. While I'm a D::C enthusiast, I guess my own ne

Re: Planning talk on Devel::Cover

Michael Carman wrote: On 9/12/2007 7:41 PM, James E Keenan wrote: I'd also like to hear any other coverage-related ideas you think would be worthwhile bringing up at this workshop. Here's my 2¢ For applications with code in multiple modules use the options for including and exclu

Re: Planning talk on Devel::Cover

On Sep 13, 2007, at 2:14 AM, Joshua ben Jore wrote: Do you know of any addons to the cover program to use information like "this method call site always resolves to the following destinations" or "if execution went through this part, what else probably happened?" Sorry, I don't know of any

Planning talk on Devel::Cover

I have had a proposal accepted to do a presentation at the Pittsburgh Perl Workshop (Oct 13-14) on "Better Code via Coverage Analysis during Testing" (http://pghpw.org/ppw2007/talk/725). During this presentation I hope to: 1. Channel pjcj to the best of my ability. 2. Share some things I've

  1   2   >