Re: Sometimes MakeMaker won't make.

Rob Bloodgood wrote: Adam Kennedy wrote: Doesn't makemaker only like you if you have a single .pm file just in the root directory? And otherwise you have to have your lib files actually under lib? lib/Tree/Splay.pm lib/Tree/Splay/Node.pm lib/Tree/Splay/IntRange.pm t/01_basics.t t/02_compat.t

Re: RT Permissions

Andy Lester wrote: On Fri, Dec 02, 2005 at 12:10:24PM -0800, Ovid ([EMAIL PROTECTED]) wrote: I've wondered about this myself. I've taken over Class::Trait but I can't take ownership of the RT requests. RT should do it automagically. Email Jesse directly if not. As I found out when taki

Devel::Cover failure: Storable binary image v2.7 more recent than I am (v2.6)

I would like to report a problem I encountered using Devel::Cover today and how I got around it. In preparation for CPAN uploads, I was using Devel::Cover v0.55 on Perl 5.8.7 to do coverage analysis of two different modules I maintain. One of these modules, Data::Presenter, has been under int

Re: How to use Devel::Cover?

Scott Wang wrote: Hi , I am new to use Devel::Cover. We have lots of product Perl modules in our product "lib" folder and we have lots of Perl test scripts to cover those modules, right now, we are trying to get the code coverage metrics for our tests on those modules. I find we might get hel

Re: How to use Devel::Cover?

Scott Wang wrote: Hi Chris, I am still confus. For example, On my Linux box, I have a module "/tmp/experiment/lib/module_to_test.pm" to be tested, and I have two Perl unit test scripts "/tmp/experiment/tests/test1.pl" and '"/tmp/experiment/tests/test2.pl" to load the module_to_test.pm module

Re: Need help diagnosing Test-Simple-0.62 make test error

David Golden wrote: Dear Michael and Perl QA colleagues, Wes Barris was trying to install one of my modules and encountered a dependency problem when Test-Simple-0.62 failed to make on his system. I was able to get some additional details, but I'm not sure what advice to offer him. The prob

Re: Test Script Best-Practices

Tyler MacDonald wrote: Jeffrey Thalhammer <[EMAIL PROTECTED]> wrote: [snip] * When run outside of 'make test', should the test script force modules to load from the distro's lib or blib directory by default? Or should it just load from the user's existing @INC (whatever it may be). The conv

Re: Test Script Best-Practices

Steffen Schwigon wrote: Quite often -l (to read from lib/) is enough, depending on your module build complexity. For -b you have to call ./Build before "prove", which can be annoying and/or difficult to remember. I'll have to try that out. My modules all use MakeMaker rather than Module::Buil

Re: bug with Test::Exception? or imacat's autotest box?

Sébastien Aperghis-Tramoni wrote: CPANPLUS sent the report to your module because its tests failed, because it uses Test::Exception which uses Sub::Uplevel which wasn't available during the test phase. The reason why Sub::Uplevel is missing may come from a problem in IMACAT's box, or maybe n

Re: MAKE SCHWERN PAY!]

Steve Peters wrote: *

Re: Where did I see this use of plan()?

Yitzchak Scott-Thoennes wrote: I remember working with some module that had tests something like: use Test::More; plan tests => numtests(); ... is($foo, $bar, 'foo is bar'); sub numtests { 13 } So that when you added a new test to the bottom, the number to modify was right there a

Re: prove users: Please test P/PE/PETDANCE/Test-Harness-2.57_04.tar.gz

Andy Lester wrote: I'm about to release T::H 2.58, but I have a pretty big difference in how globbing is done in prove, per Audrey. Please download and try it out on your box and make sure it's all good. One warning thrown, apparently in t/00compile.t. 37 tests skipped for "various reaso

Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz

David H. Adler wrote: Tests pass. One "not numeric" warning: t/00compile.ok 1/6Argument "2.57_06" isn't numeric in subroutine entry at t/lib/Test/More.pm line 670 This is the same warning I reported in an earlier message: http://groups.google.com/group/perl.qa/msg/fee69dde25cf42ec

Changing permissions on temporary directories during testing

Let's say that I'm writing a test suite for a Perl module which creates files and then, optionally, moves those files to predetermined directories. To test this module's functionality, I would have to see what happens when the user running the tests does not have write permissions on the desti

Re: Changing permissions on temporary directories during testing

Michael G Schwern wrote: There's other issues with this code. For one, its not portable. You're using a system command (touch) and you're assuming Unix filepath syntax. Another is your errors do not include $! which is the reason the command failed (no such file or directory). Additionally,

Re: Getting to hello world?

Gabor Szabo wrote: On Ubuntu it was quite straigt forward, I think this is everything I needed: sudo apt-get install subversion sudo apt-get install ghc6 Given that, in the above, you installed subversion and ghc6 for all users ... [snip] # To compile Parrot svn co https://svn.perl.org

Re: CPANTS is not a game.

David Golden wrote: How does "is_prereq" improve quality? I've mostly ignored CPANTS, in large part because I refuse to include t/pod.t and t/pod_coverage.t in my distributions because they don't pick up the format in which some of my best documentation is written. And refusing to inc

Re: Question - (1) Devel:;Cover and B::Deparse issue (2) "cover" and its momory consuming issue

Scott Wang wrote: We are trying to use Devel::Cover module and "cover" in our regression tests run to generate product code coverage data. However, we met two big problems: (1) Lots of our perl test scripts failed in code coverage run and seems related to B::Deparse and we got million lines of m

Re: Question - (1) Devel:;Cover and B::Deparse issue (2) "cover" and its momory consuming issue

Scott Wang wrote: Hi James, Any information on, generally, how and why Devel::Cover use B::Deparse module? Google is your friend. I recommend going to Google Groups and searching the archives for perl.qa for B::Deparse. I saw tons of messages "Deep recursion on subroutine "B::Deparse::fi

Re: Old and broken versions of Module::Install

Steffen Mueller wrote: You can find a complete (and somewhat current) list of problematic modules at http://steffen-mueller.net/mi_old.html Thank you very much for this public service! jimk

Re: [perl #40803] [BUG] 'make' fails on Darwin at -lgmp

On Nov 11, 2006, at 5:56 AM, Joshua Hoblitt via RT wrote: I believe that the attachment containing your make output was truncated. Can you try again or just inline the make error(s)? See below. It should be noted that I upgraded to GMP 4.2.1. before trying to build Parrot (or, more precisely,

Re: Fwd: Re: [pirate] Re: languages/python - any plans?

Leopold Toetsch wrote: I don't know if this was cc'ed to p2p, so just in case. leo Subject: Re: [pirate] Re: languages/python - any plans? From: "Tyler Coumbes" <[EMAIL PROTECTED]> If anyone is interested in looking at t

pmc2c.pl: Proposed Strategy for Revisions and Testing

Friends: Last week I had my first encounter with the Parrot project when I attended the Chicago Perl Hackathon. There Jerry Gay suggested that I work on improving the tests applied to Parrot build/install tools written in Perl 5 -- specifically, tools/build/pmc2c.pl. I devoted the balance o

Re: pmc2c.pl: Proposed Strategy for Revisions and Testing

Allison Randal wrote: Go with the more extensive and thoroughly tested refactor. Particle will work with you (mentoring/code review) and make sure your changes get checked in. As my 2nd post noted, I made an error in counting the number of subroutines that could be deprecated. Only gen_

3 subroutines with same name

Note the results: [parrot] 502 $ ack 'sub gen_c' lib/Parrot/Pmc2c.pm 1221:sub gen_c { lib/Parrot/Pmc2c/Library.pm 134:sub gen_c { tools/build/pmc2c.pl 821:sub gen_c { 3 identically named subroutines: 2 in modules and 1 in a script. And all 3 will be in modules as I'm planning to refactor m

Re: 3 subroutines with same name

chromatic wrote: On Tuesday 21 November 2006 18:36, James E Keenan wrote: 3 identically named subroutines: 2 in modules and 1 in a script. And all 3 will be in modules as I'm planning to refactor much of pmc2c.pl into a module called Parrot::Pmc2c::Utils. (For drafts of these revi

pmc2c.pl --dump : What Files Does Makefile Supply as @ARGV

And now, a question about how the Parrot Makefile utilizes pmc2c.pl ... The Makefile calls: PMC2CD = $(PERL) $(BUILD_TOOLS_DIR)/pmc2c.pl --dump ... which inside pmc2c.pl translates into: dump_pmc([EMAIL PROTECTED], @ARGV); What kind of files does the Makefile place in @ARGV? I need to fi

Are Instructions for Submission of NEW Files Up-to-Date?

Last night I prepared two emails, one containing patches, one containing new files. I followed the instructions in docs/submissions.pod, i.e. I prefaced their subject lines with [PATCH] and [NEW] respectively and mailed both to [EMAIL PROTECTED] (The mail was sent from jkeen AT verizon DOT ne

Re: Are Instructions for Submission of NEW Files Up-to-Date?

James E Keenan wrote: Did I do something wrong -- or are the instructions with respect to submission of new files? Well, my submissions finally showed up -- 11 hours after posting. So I guess the instructions are correct and I followed them correctly -- but the processing is slooow!

Re: [perl #41064] [BUG]: Not-so-new 'make' failures on Darwin

Will Coleda wrote: Here's my shell script for running config: #!/bin/sh CC="ccache gcc-4.0" CX="ccache g++-4.0" /usr/bin/perl Configure.pl --cc="$CC" --cxx="$CX" --link="$CX" -- ld="$CX" --without-icu $@ Following further discussion with Coke on #parrot, I ran this slight variation o

pmc2c.pl's print_tree() subroutine: Does it have a purpose other than diagnosis?

My problems running 'make' having been allayed, I've gotten back on track in my work on refactoring and testing tools/build/pmc2c.pl. In an earlier posting I reported that my first attempt at patches failed because I had not understood that tests of some of the subroutines in that program will

Re: [perl #41020] [PATCH] pmc2c.pl functionality extracted into separate package

chromatic wrote: On Monday 25 December 2006 21:44, James Keenan via RT wrote: A few style comments here. Utils.pm unshift @{$allargsref->{include}}, ( ".", "$FindBin::Bin/../..", "$FindBin::Bin/../../src/pmc/" ); Why no File::Spec here? There are certain ways i

Re: [perl #41020] [PATCH] pmc2c.pl functionality extracted into separate package

James Keenan via RT wrote: On Sun Dec 03 14:08:31 2006, [EMAIL PROTECTED] wrote: The files attach refactor tools/build/pmc2c.pl, extracting most of its functionality into lib/ Parrot/Pmc2c/Utils.pm and provide 8 test files to be stored in t/tools/pmc2cutils/. These substitute for my fi

Re: [perl #41020] [PATCH] pmc2c.pl functionality extracted into separate package

James Keenan via RT wrote: On Sun Dec 03 14:08:31 2006, [EMAIL PROTECTED] wrote: The files attach refactor tools/build/pmc2c.pl, extracting most of its functionality into lib/ Parrot/Pmc2c/Utils.pm and provide 8 test files to be stored in t/tools/pmc2cutils/. These substitute for my fi

Re: [perl #41144] [PATCH] refresh front page of parrotcode.org

Allison Randal wrote: # New Ticket Created by Allison Randal # Please include the string: [perl #41144] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41144 > This patch clears out some accumulated cruft from the main pag

Re: [perl #41186] [BUG]: tools/build/ops2pm.pl: Variable used in both package scope and loop iteration

James Keenan wrote: # New Ticket Created by James Keenan # Please include the string: [perl #41186] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41186 > Particle has asked me to consider testing and refactoring ('phal

Re: [perl #41186] [BUG]: tools/build/ops2pm.pl: Variable used in both package scope and loop iteration

James Keenan wrote: # New Ticket Created by James Keenan # Please include the string: [perl #41186] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41186 > Particle has asked me to consider testing and refactoring ('phal

Re: [perl #41185] [BUG]: examples/shootout/regexdna.pir.input: Persistently failing test

James Keenan wrote: # New Ticket Created by James Keenan # Please include the string: [perl #41185] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41185 > On Sept 23 2006, chromatic reported that two tests were failing in

What Skills Do We Need to Finish Parrot?

Do we have answers to the following questions? 1. What code is still unwritten that we will need to have Parrot ready to go (where "ready to go" is defined as: "ready for a Perl 6 alpha")? (I'll leave aside the question of when *that* will be ready.) 2. What skills are needed to write that

Re: PMC Tools Test Failure

chromatic wrote: Hi there, I see one failure with the buildtools tests, run right after make realclean and a fresh Configure. t/tools/pmc2cutils/04-dump_pmc...ok 103/119 # Failed test (t/tools/pmc2cutils/04-dump_pmc.t at line 533) t/tools/pmc2cutils/04-du

Re: PMC Tools Test Failure: t/tools/pmc2cutils/04-dump_pmc.t test #106

Failed 1/119 tests, 99.16% okay -- c and later chromatic further wrote: > On Thursday 01 February 2007 04:07, James E Keenan wrote: > > >>IIRC, in order to be able to get full coverage on a branch, I >>have to determine whether a file was overwritten or not, which I'm

Re: [perl #41425] [BUG] and [PATCH]: Refactoring of lib/Parrot/Pmc2c/Utils.pm -> test failure

James Keenan wrote: # New Ticket Created by James Keenan # Please include the string: [perl #41425] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41425 > Refactoring of code in lib/Parrot/Pmc2c/Utils.pm can and should be

Re: [perl #41485] [TODO] Add a test for svn:eol-style property

jerry gay wrote: On 2/11/07, via RT Paul Cochrane <[EMAIL PROTECTED]> wrote: # New Ticket Created by Paul Cochrane # Please include the string: [perl #41485] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41485 > svn:eol

Re: [perl #41529] [BUG]: t/perl/Parrot_Distribution.t test failure

Two points in follow-up: 1. This bug has been difficult to diagnose because Parrot::Distribution -- which is what it is ultimately testing -- names some variables in ways that, IMHO, are misleading. Take, for example, this subroutine: sub get_perl_language_files { my $self = shift;

Re: [perl #41529] [BUG]: t/perl/Parrot_Distribution.t test failure

jerry gay wrote: On 2/17/07, via RT James Keenan <[EMAIL PROTECTED]> wrote: The file which is failing the test is a Parrot source file (which happens to be a Parrot test file) -- not a Perl source file (which happens to be a Perl test file). So the test at line 75 is correctly formatted. part

Re: [perl #41455] [NEW] and [PATCH]: tools/build/ops2pm.pl refactored

James Keenan wrote: # New Ticket Created by James Keenan # Please include the string: [perl #41455] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41455 > Following discussion with particle today, these patches and new

Re: [perl #41455] [NEW] and [PATCH]: tools/build/ops2pm.pl refactored

James E Keenan wrote: James Keenan wrote: # New Ticket Created by James Keenan # Please include the string: [perl #41455] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41455 > Following discussion with parti

Re: [perl #41619] [PATCH] add add_attr, rem_attr, and rem_attr_str vtable methods

Alek Storm wrote: # New Ticket Created by "Alek Storm" # Please include the string: [perl #41619] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41619 > This patch adds the add_attr, rem_attr, and rem_attr_str vtable meth

Re: [perl #41620] [PATCH] change opcode syntax for label arguments

Alek Storm wrote: # New Ticket Created by "Alek Storm" # Please include the string: [perl #41620] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41620 > This patch changes the , , and syntax in opcodes to , , and , resp

Re: What is intended use of Parrot::Distribution?

Elizabeth: I think the question you ask in your subject line is the most important aspect of your posting. Over the past month I've gotten errors from time to time when running tests which call Parrot::Distribution. This has led me to poke around inside lib/Parrot/Distribution.pm and be puz

Re: PIR Tutorial

Klaas-Jan Stol wrote: hi, I've started a bit on a PIR tutorial on the wiki. If anybody can spare a few moments, some feedback would be very welcome! I am very glad to see this. One suggestion and one request for clarification: 1. First bullet point in FAQ should be: What does PIR stand f

Re: [BUG] and [PATCH]: Failures in 5 tests during 'make test'; partiallypatched

James Keenan wrote: I got errors in 5 different tests running 'make test' this morning on a tree freshly updated from trunk. An excerpt from 'make test' output is attached. I mistakenly sent this first to [EMAIL PROTECTED], so I think it didn't open a bug ticket in RT. I have re-sent it

Re: [perl #41328] [BUG] pmc2c generates unnecessary code for void functions

chromatic wrote: Jim, can you resend with diffs in unified format? (That's "diff -u", not "diff".) They're much, much easier to read. -- c I screwed up. I attached this to the wrong ticket.

Re: [perl #41201] [TODO] Remove temporary conf hack in Configure.pl

Paul Cochrane wrote: # http://rt.perl.org/rt3/Ticket/Display.html?id=41201 > In Configure.pl there is a mention of $Parrot::Configure::Step::conf being a temporary hack, this should be implemented properly. The patch attached addresses this problem by transforming the Parrot::Configure objec

Re: [PATCH] Hints must come early in Configure.pl

Andy Dougherty wrote: Hints need to come *before* inter/progs. The hints set up various platform-specific callbacks to be performed after the different programs are selected. Actually, I suspect they should even come before the init::install unit. Certainly in perl5's hints, there are a numb

Re: IRC discussion of smoking and branching

Eric Hanchrow wrote: Here's the relevant bits from my config file: [miscellany] ### Set enable-auto-props to 'yes' to enable automatic properties ### for 'svn add' and 'svn import', it defaults to 'no'. ### Automatic properties are defined in the section 'auto-props'. enable-

Re: IRC discussion of smoking and branching

Eric Hanchrow wrote: Here's the relevant bits from my config file: [miscellany] ### Set enable-auto-props to 'yes' to enable automatic properties ### for 'svn add' and 'svn import', it defaults to 'no'. ### Automatic properties are defined in the section 'auto-props'. enable-

Re: Perl Build related query

Dhevendran K wrote: Hi, When I am building PERL 5.6.1 on Linux 2.6 Kernel AMD 64 bit machine [i.e. "SUSE LINUX Enterprise Server 9 (x86_64) - Kernel 2.6.5-7.97-default (1)" ], I am getting the following errors. [snip] lib/io_multihomedInvalid argument at lib/io_multihomed.t line 108. Conn

Re: DBD-mysql coverage == 56% - am I on drugs ??

Leif Eriksen wrote: Can this be right ? I checked out DBD-mysql-2.9007 and ran it through Devel::Cover. Apart from skipping 15 tests to do with leaks and 1 test to do with transactions, the overall coverage figure from Devel::Cover is 56% All tests successful, 1 test and 14 subtests skipped. Fi

Re: Module suggestion

Vsevolod Ilyushchenko wrote: Hi, I'd like to suggest a module that I came up with to test CGI file uploading logic. I have little experience with file uploads via CGI.pm, so let me pose some questions on more peripheral aspects of your proposal. "test" in what sense? Is this supposed to

Re: Devel::cover bug?

Kevin Scaldeferri wrote: I'm looking at a bit of output from Devel::Cover that I imagine has to be a bug. I'll try my best to reproduce the HTML output: stmt branch cond sub time code 221862 100 100 _1613639 next if ($line =~ /^\

Phalanx at YAPC::NA::2005

On Monday, June 27, Marc Prewitt and I will be making a presentation at YAPC::NA::2005 in Toronto entitled "Phalanx from the Trenches: A Local Perl Users Group's Experience." While the main focus of our talk will be on our experience with the Perl Seminar NY Phalanx contingent's work on Text-

Re: Extraneous whitespace on failures with T::Harness 0.48, T::More 0.60

Nik Clayton wrote: All, There seems to have been a change in the output format for test failures semi-recently. Given this test script: #!/usr/bin/perl use Test::Harness 0.48; use Test::More 0.60; plan tests => 2; ok(1, 'test 1'); ok(0, 'test 2'); I get this outpu

Re: Hello

GlennH wrote: Hello folks, I read about the Phalanx project on the yahoo Agile Testing group and thought I'd sign up the mailing list and skulk in the background. Don't just skulk. Enlist! http://qa.perl.org/phalanx/ http://phalanx.kwiki.org/ jimk

Re: Scalability of Devel::Cover

Kevin Scaldeferri wrote: It seems to me like the time Devel::Cover takes to do its book-keeping when a process terminates is linear in the total number of files in the cover_db, rather than linear in the number of files involved in that particular process. [snip] This seems unfortunate for a

Re: Test::Builder::Tester vs. Test::Tester

Nik Clayton wrote: As I write my first set of Test::Builder based tests I'm looking for a way to test the tests themselves, and make sure that they're doing the right thing. A quick peruse of CPAN has thrown up Test::Builder::Tester and Test::Tester. I've seen quite a few modules that use

Re: 5.004_xx in the wild?

Paul Johnson wrote: As someone whose production code is currently required to run under 5.5.3, I'm very grateful to module authors whose code still runs under that version at least. A number of modules which don't run under 5.5.3 do with simple changes, primarily changing "our" to "use vars" a

Re: 5.004_xx in the wild?

Michael G Schwern wrote: That said, here's the main differences: Thanks. My modules are sufficiently non-evil that I should be able to compensate for these differences. jimk

Testing a Script Distributed with a Module

I am having trouble figuring out how to test a Perl script which functions as a command-line utility and which is included with a CPAN-style distribution. For purpose of discussion, let's call the distribution XYZ and the script xyz.pl. My distribution has the following standard structure:

Re: Testing a Script Distributed with a Module

Michael G Schwern wrote: Make sure MakeMaker is told about that script via EXE_FILES or it won't know to do anything with it (like install it). Check. In Makefile.PL, I already had: EXE_FILES=> [ 'scripts/modulemaker', ], [snip]

Re: Testing a Script Distributed with a Module

Michael G Schwern wrote: Oh yeah, forgot about that. Its not in your path so you have to give it the full path to the program. The directories in blib have no relation to where the file came from. Non-binary executables always go into blib/script. Binary executables go into blib/bin. O

Re: Devel::Cover Problem: testing || for a default value.

Michael G Schwern wrote: The other examples in the ticket play out the same way: bless {}, ref $class || $class; I encountered the coverage problem inherent in this code in the constructor of a module whose maintenance I recently assumed. (For that matter, I could have encountered

Re: Testing a Script Distributed with a Module

James E Keenan wrote: Michael G Schwern wrote: Oh yeah, forgot about that. Its not in your path so you have to give it the full path to the program. The directories in blib have no relation to where the file came from. Non-binary executables always go into blib/script. Binary

Re: 5.004_xx in the wild?

Michael G Schwern wrote: On Mon, Jul 04, 2005 at 03:59:23PM -0400, James E Keenan wrote: I've only developed in 5.6+ environments. Can anyone provide a link to what I would have to do to make my modules compatible with 5.4 and/or 5.5? Step one: Install 5.4.5 and 5.5.4. Step two:

False Positives from Automated Testing at testers.cpan.org

It's not unheard of for module authors to complain that the automated test reports posted on testers.cpan.org FAIL modules that ought to PASS. Tonight, I wish to make the opposite complaint: that one of my own modules garnered four PASSes when it should have FAILed! Je m'accuse: Two days ag

Re: Why were the CPAN tester results turned upside down?

Michael G Schwern wrote: http://testers.cpan.org/show/Test-Simple.html Looking at the CPAN tester results for Test-Simple... why are they suddenly oldest version first? I care about test results from the newest version, not the oldest. From personal e-mail: On Jul 9, 2005, at 8:49 PM, Leo

Re: Test::Code

Ovid wrote: X-Posted to Perlmonks (http://perlmonks.org/index.pl?node_id=483100) I frequently write code that generates anonymous functions on the fly. However, I often want to verify that these functions are correct without executing them. To this end, I've started writing Test::Code. Here'

Re: ENV problems with testing

Comrade Burnout wrote: I'm not sure this is the right place to ask, but I'm at the end of my rope here. I've been working with the ExtUtils::ModuleMaker author with some beta-testing of new releases. (part of `uname -a`) FreeBSD 5.2.1-RELEASE ( relevant perl -v ) This is perl, v5.6.1 built f

Re: New kwalitee test, has_changes

Ricardo SIGNES wrote: * "Christopher H. Laco" <[EMAIL PROTECTED]> [2005-09-15T08:23:57] Would this look for Change OR ChangeLog? Both seem to be popular on CPAN. ...and some modules have a HISTORY or CHANGES section of POD, and DBI has DBI::Changes. Good point. Modules created with ExtUt

Re: ENV problems with testing

Comrade Burnout wrote: James E Keenan wrote: Comrade Burnout wrote: I'm not sure this is the right place to ask, but I'm at the end of my rope here. perl Makefile.pl make make test VERBOSE=>1 Did you include 'make' between 'perl Makefile.PL

Re: ENV problems with testing

Comrade Burnout wrote: James E Keenan wrote: And, again, to rule out obvious problems ... 1. When you ran 'make', did you get output that looks more or less like this: FWIW, here's the full output of make ... [ burnt ] :: make cp lib/ExtUtils/ModuleMaker/StandardT

Re: ENV problems with testing

Michael G Schwern wrote: On Mon, Sep 19, 2005 at 06:55:12PM -0500, Comrade Burnout wrote: i upgraded to 5.8.2 (i think that's the minor version number .. don't recall), and that "magickally" fixed everything. i was running 5.6.1 at the time. Oh. Did you chdir() at all in the tests? Earl

Re: ENV problems with testing

Michael G Schwern wrote: On Mon, Sep 19, 2005 at 09:42:52PM -0400, James E Keenan wrote: Schwern: Do you think it's worthwhile accounting for this MakeMaker anachronism in writing test files, i.e., providing an absolute path to every chdir call? I think you misunderstand. The probl

Re: New kwalitee test, has_changes

David Landgren wrote: demerphq wrote: You miss my point. Whether the code be cross-platform or cross-version, you need to aggregate the coverage results from all the environments your code is designed to run on. How is this done?

Re: cpan testers and dependencies

David Landgren wrote: Fergal Daly wrote: http://www.nntp.perl.org/group/perl.cpan.testers/257538 shows a fail for Test-Benchmark but the fail seems to be caused by CPANPLUS not installing dependencies: Apparently it's a bug in CPANPLUS that stops it from keeping track of grand children dep

Devel::Cover not DWIMming on upgraded Perl -- but problem solved

When I began to write this posting, it was to get an answer to a question. But I figured out a workaround halfway through, so now I'm posting an answer. I have happily been using Devel::Cover for more than a year on Perl 5.8.4 on Darwin (Mac OS X 10.3). Recently I upgraded to Perl 5.8.7. To

Re: Devel::Cover on Win32: Observations

Paul Johnson wrote: Normally they would not be covered by default, being core modules. Is it possible that your perl is in a different location from that with which the ppm was created? This was probably the case. I may even have downloaded the Devel::Cover which Crazy built against Perl 5.6 rat

Re: need help

Sridhar Subbarayan wrote: Hi, I am urgently in need of some study material that deals with using perl in QA process. How is functionality testing done using perl. How is performance testing done using perl. How does perl help in automation. Please give some examples. Please let me know if there ar

Re: Devel::Cover failure?

Randy W. Sims wrote: The test file below is pared down from Module::Build. The warning from C comes up in several tests, not always causing test failures. The same warning appears if you run MakeMaker as shown in the Devel::Cover docs--it's not specific to Module::Build. [EMAIL PROTECTED]:~/pro

Re: failures under Devel::Cover only

Leif Eriksen wrote: Hi, I am doing some testing under Devel::Cover, and get some weird results sometimes. What should I be looking at in my code or test cases that is provoking this discrepancy? Here's a link to the posting I did on Devel::Cover several months back to which I referred a few

Re: failures under Devel::Cover only

Leif Eriksen wrote: Hi, I am doing some testing under Devel::Cover, and get some weird results sometimes. What should I be looking at in my code or test cases that is provoking this discrepancy? Without D::C ++ [snip] All tests successful. Files=13, Tes

Re: [Maybe Spam] Re: failures under Devel::Cover only

Leif Eriksen wrote: Ah, OK, I know I was guilty of doing this (until recently) [EMAIL PROTECTED] (of couse $#$arrref is correct). Used to give me "Bizzare copy of array at ..." but only under "perl -d script.pl" (or perl -d:ptkdb script.pl when its available to me) . I'll checkit out, ther

Re: Phalanxed

Michael G Schwern wrote: Anyhow, point is I know what the Phalanx project is but other authors might not. It may be a good idea to send out a little note to authors who have been Phalanxed explaining what the Phalanx project is all about and letting them know they might see a sudden spike in test

Re: Testing What Was Printed

David Cantrell wrote: Jim Keenan wrote: Using the standard Test::More framework, is it possible to test whether what was printed to a filehandle matches a predetermined string or list of strings? Would IO::Capture be of help here? Looks promising. Hope to find time today to try it out and report

Re: Testing What Was Printed

David Cantrell wrote: Jim Keenan wrote: Using the standard Test::More framework, is it possible to test whether what was printed to a filehandle matches a predetermined string or list of strings? Would IO::Capture be of help here? And here are the fruits of my application of IO::Capture: a module

Re: Testing What Was Printed

David Golden wrote: My $0.02: Very nice integration of IO::Capture. I think this is very promising, but all the start(), stop() calls seem overly repetitive to me. Agreed. What about refactoring it into a set of test functions that handle it for the user automatically? Just quickly off the cu

Re: Testing What Was Printed

David H. Adler wrote: A question: is there any reason that you made this an OO module but still show calls to the methods as functions rather than methods on the object? An answer: It was a quick hack based on my first day's experience with IO::Capture::Stdout. Its original rationale was simpl

Re: Testing What Was Printed

Shawn Sorichetti wrote: I've started working on Test::Output that is based on Schwern's TieOut module that comes with Test::More. I'm hoping to have it released on CPAN later tonight. Test::Output is a self contained so that it can be included with other modules, and no prereqs. Right now it

Re: Testing What Was Printed

Tels wrote: On Friday 11 February 2005 21:08, David H. Adler wrote: Just askin'. :-) In similiar line of thought: Why "verify_number_lines" instead of the (much shorter :) "lines"? "Speaking source code" is something I like, but it shouldn't gabble on :) Oh, and why "TestAuxiliary" and not "Test::

Re: Testing What Was Printed

David H. Adler wrote: A question: is there any reason that you made this an OO module but still show calls to the methods as functions rather than methods on the object? I.e. why C rather than C<$capture->verify_number_lines> ? This would also remove the need to explicitly export those functions. J

  1   2   3   4   >