On Jan 3, 2008 10:20 AM, Ovid <[EMAIL PROTECTED]> wrote:
> We couldn't reproduce the segfaults in the debugger or with
> Devel::Trace, but after a lot of work, a colleague and I found the
> culprit: Contextual::Return. Like Sub::Uplevel, it overrides
> CORE::GLOBAL::caller. Apparently the two do
On Dec 31, 2007 6:49 AM, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> "Why not replace this thing you have done which works and is useful
> with the thing I think it should be but haven't implemented"
>
> Hey, Sam - instead of doing whatever you're doing right now come and
> clean my bathroom. That'
On Dec 24, 2007 12:30 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Thinking on this a little more, there is the issue of folks like me who share
> a single CPAN configuration file across multiple Perl installations. I don't
> know how common that is to have a stable and devel perl running of
On Dec 23, 2007 2:37 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> [1] It can be argued that bleadperl testers should probably not email authors,
> and maybe they aren't I can't tell from these archives, but at least the work
> is useful. CPAN::Reporter could change the default configuration
On Dec 22, 2007 8:26 PM, chromatic <[EMAIL PROTECTED]> wrote:
> CPAN Testers reporting failures in every module they test and not stopping to
> ask "Hey, is it possible that not everything else in the world is broken?" is
> *not* an example of CPAN Testers working as expected.
>
> Environments wher
On Dec 22, 2007 6:03 PM, Matisse Enzer <[EMAIL PROTECTED]> wrote:
> I respectfully suggest that maybe there is another way of looking at
> it, where the install process (governed by Makefile.PL/Build.PL) could
> possibly be a "test driven installation" process:
>
> use Test::More tests => 23;
>
On Dec 22, 2007 3:52 PM, chromatic <[EMAIL PROTECTED]> wrote:
> Let me rephrase then.
>
> I feel dirty writing tests just to trip up testers who can't set up working
> testing environments.
Is this really a problem? Let me flip this around -- I get very few
problems of this sort for CPAN::Reporte
On Dec 22, 2007 2:12 PM, chromatic <[EMAIL PROTECTED]> wrote:
> I agree in principle, but in practice I seem to get a lot of failure reports
> from someone who's installed Perl on Windows into a directory with spaces in
> the name, and whatever installer there is just can't cope with that
> situati
On Dec 21, 2007 12:32 PM, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> Anyone with Windows who cares to, please bang on
> http://plasmasturm.org/attic/Proc-Fork-0.5.tar.gz
> before I send it to the CPAN.
Passes on Strawberry Perl 5.10.0 beta 2 as well.
David
On Dec 20, 2007 6:07 PM, Michael Peters <[EMAIL PROTECTED]> wrote:
> I for one would like the full TAP output of the tests. Not just what get's
> sent
> to STDOUT by default. What would be ideal (and it's something that RJBS has
> poked me about before) would be to receive a TAP Archive (prove --a
On Dec 20, 2007 1:19 PM, Dave Rolsky <[EMAIL PROTECTED]> wrote:
> It's generally
> pretty rare that the failure report includes enough information for me to
> do anything about it, so without an engaged party on the other end, it
> really is just noise.
With CPAN::Reporter, I've been trying to add
On Dec 19, 2007 11:03 AM, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> Does it continue to pass if you replace the first line with
>
> my ( $p, $c, $e, $r ) = @{ $config }{ qw( parent child error retry ) };
>
> and then inline the body of `_do_fork`?
>
> (Logically, it should, but this utterly und
On Dec 19, 2007 7:23 AM, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> I wish someone would help me fix Proc::Fork on Windows. I got
> two tickets about it and a bunch of Testers failures, but several
> attempts to make it work have failed and my repeated pleas have
> fallen on deaf ears. :-)
I poked
On Dec 18, 2007 9:59 PM, Chris Dolan <[EMAIL PROTECTED]> wrote:
> Does anyone know how the false negative rates compare for cpan-tester
> smokers vs. CPAN::Reporter users? I've found the former to be
> enormously valuable for cross-platform testing (especially David
> Cantrell and Slaven Rezic), b
> > * test.pl, no output, exit 0 -> EU::MM says pass, M::B says unknown
> > * test.pl, no output, exit 1 -> EU::MM says fail, M::B says unknown
For clarity, let me add the following cases (where T::H < 3.05 includes 2.XX):
* foo.t, no output, exit 0 -> T::H < 3.05 says unknown, T::H 3.05 says fai
On Dec 4, 2007 6:37 PM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Andreas J. Koenig wrote:
> > Bug in CPAN::Reporter and/or Test::Harness and/or CPAN.pm?
> >
> > http://www.nntp.perl.org/group/perl.cpan.testers/796974
> > http://www.nntp.perl.org/group/perl.cpan.testers/825449
> >
> > All
CPAN::Reporter says explicitly that UNKNOWN will return success to
CPAN.pmand not prevent installation. I think this is a Test::Harness
bug.
David
On Dec 4, 2007 3:24 PM, Andreas J. Koenig <
[EMAIL PROTECTED]> wrote:
> Bug in CPAN::Reporter and/or Test::Harness and/or CPAN.pm?
>
> http://www.n
On Dec 4, 2007 12:40 AM, Chris Dolan <[EMAIL PROTECTED]> wrote:
> Or maybe not reinvent the wheel and get tons of extra functionality
> for free!
>
> use base 'Test::Class';
> sub block : Test(2) {
>
>ok(1, "wibble");
>ok(1, "wobble");
> }
But if it goes into Test::More, it eventually goes
Michael G Schwern <[EMAIL PROTECTED]> wrote:
> It also makes it technically possible to allow the test to change it's plan
> mid-stream, though the consequences and interface for that do require some
> thought.
With some sugar, that could actually be quite handy for something like
test blocks. E.
On Nov 27, 2007 12:45 PM, Andy Lester <[EMAIL PROTECTED]> wrote:
> I think he means a legal DoS, where armies of bank-payrolled lawyers
> come in and C&D the entire *.cpan.org and *.perl.org infrastructure.
This is where I would hope that a small guerrilla force of TPF lawyers
to jump in and issue
On Nov 27, 2007 11:42 AM, David Landgren <[EMAIL PROTECTED]> wrote:
> The module is currently not available on CPAN, but it still lurks on the
> BackPAN (which is where the site owner tracked it down). I don't know
> off-hand the exact list of who is currently mirroring, I think there are
> two o
On 10/25/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> Before I work it out for myself does anyone know if it's possible to
> simulate the test environment created by CPANPLUS? We're currently
> seeing some funny results for Test::Harness with CPANPLUS and I'd
> like to add a Build target that ru
On 10/22/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> # from David Golden
> # on Sunday 21 October 2007 20:18:
>
> >Your META.yml says your module needs "Foo::Bar 1.23". Someone doesn't
> >have Foo::Bar installed. Your tests fail. Did they fail because
On 10/21/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> Why is it "die 'OS unsupported'" in one case and "exit 0 unless happy()"
> in the other? Seems like they should both be dying.
Parsing for "OS unsupported" or "No support for OS" was introduced as
a heuristic into CPANPLUS a couple years ago
On 10/21/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> >If a
> >specified prerequisite (from META.yml, Makefile.PL or Build.PL) is not
> >satisfied, failing reports are discarded. (Passing reports are still
> >sent, however.)
>
> Really? Seems like that should report "PREREQ_FAIL" or something.
Y
On 10/21/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> # from David Golden
> # on Sunday 21 October 2007 08:30:
>
> >So, gradually, the more easily determined failure paths have being
> >pruned out to just cut down on the noise. Ones that are easy to
> >automa
On 10/21/07, demerphq <[EMAIL PROTECTED]> wrote:
> B) Absent a documented way to set this in MakeMaker, suggesting that
> it is the appropriate solution to the problem intended to be solved by
> Devel::CheckLib seems out of place at best, and presumptive at worst.
>
> As an aside, it seems to me th
On 10/11/07, chromatic <[EMAIL PROTECTED]> wrote:
> Yes, I know. I know *because* I put in that statement on purpose *because*
> the module doesn't work on Perl 5.005.
>
> Is there a better place to put the "Don't bother trying to run this on ancient
> software?" note in such a way that the CPAN t
On 10/11/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> 1. If find it odd that there's nothing about the build process in this
> report.
CPAN::Reporter has, since the beginning, only reported on the output
of the phase (PL, make, test) that failed. Originally, that was a
result of the fact that i
On 10/11/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> http://cpantest.grango.org/cgi-bin/pages.cgi?act=wiki-page&pagename=CPANAuthorNotes
>
> In the section:
> "Can't CPAN Testers read? I have detailed the format I require for bug
> reports!"
>
> "Please do not get irrate"
It's a wiki. Feel fr
asier. See "Notes for CPAN Authors" on the CPAN Testers Wiki for more
details: http://cpantest.grango.org/
Sincerely,
David Golden
On 10/1/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> Is this really something we want to push *another* X months/years
> out? In the near future 5.10.0 would be the best chance to gain
> an installed base quickly. Having the CPAN client in the core
> capable of upgrading itself is something we've
On 9/27/07, Graham TerMarsch <[EMAIL PROTECTED]> wrote:
> I can actually verify that CPANPLUS doesn't send automated "failure" reports
> when no Makefile is generated; I tested that locally myself this morning
> after reading your previous message.
That's good news.
> That's what I'm finding too;
On 9/27/07, Graham TerMarsch <[EMAIL PROTECTED]> wrote:
> Ok... THATS a useful answer. :)
>
> So... if I set up my Makefile.PL to check for the presence of any modules that
> I require for configuration (e.g. "Apache::Test") and then simply "exit
> 0" -before- the Makefile is written, it'll abort t
he Makefile.PL
without creating a Makefile, then CPAN::Reporter won't FAIL it, but
CPAN notices that no Makefile was created and won't continue. But you
have to exit (exit value 0), not die.
I don't know if CPANPLUS follows the same logic.
Regards,
David Golden
I don't think Module::Build can be a build_requires. I think it has to
be a configure_requires. (Not that support is widespread yet.)
David
On 9/26/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Graham TerMarsch wrote:
> > As a dumb alternative... what about explicitly listing M::B as a buil
On 9/26/07, David Golden <[EMAIL PROTECTED]> wrote:
> On 9/26/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > I think (I hope) David was balking at the idea of encoding release
> > information
> > as CPAN forum tags and not so much at the idea of CPAN forum t
On 9/26/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> I think (I hope) David was balking at the idea of encoding release information
> as CPAN forum tags and not so much at the idea of CPAN forum tags themselves
> as independent search keywords.
The former.
David
On 9/26/07, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
> David Golden wrote:
> > Please no! Let's not spread module metadata around any more than we have
> > to.
> >
> > Extend META.yml to include the same kind of information that used to
> > be man
On 9/25/07, Chris Dolan <[EMAIL PROTECTED]> wrote:
> Well, one option might be something like:
>http://www.cpanforum.com/tags/name/helpwanted
> Gabor, would it be easy to add an Atom/RSS feed for a particular tag?
Please no! Let's not spread module metadata around any more than we have to.
E
On 9/23/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> would have the absolute latest release, even devs. You could set your CPAN.pm
> to pull from one or the other.
If it goes this way, I'd at least want a command or something that
lets me act against the alpha list as a one-off without havi
On 8/17/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> 1. author (kwalitee, pod, etc)
> 2. gui
> 3. network
> 4. you must have an account/password on $external_service
> 5. postgres/mysql/whatever availability/setup/permissions
> 6. no modem attached to /dev/ttyS0
>
> Thus: "more t
On 8/2/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> On 2 Aug 2007, at 23:53, Eric Wilhelm wrote:
> > I think a new toplevel (e.g. ./author_t or ./author_test) directory is
> > going to be most compatible.
>
> +1
Agree, +1 for "author_t" -- using "t" rather than "test" is a better
parallel to th
On 8/2/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> For such usage, extra dependencies would only be optional in extreme
> cases. Further, pod/pod-coverage would possibly even be 'assumed'
> tests. That is, why bother even having a .t file if the authortest
> tool knows how to run testpod and te
On 7/31/07, chromatic <[EMAIL PROTECTED]> wrote:
> This is not a functional failure; it has nothing to do with whether the *code*
> will behave correctly on a user's system.
That's not the question you posed. You asked why POD would "behave
differently". Ask a silly question, get a silly answer.
On 7/31/07, chromatic <[EMAIL PROTECTED]> wrote:
> Please explain to me, in detail sufficient for a three year old, precisely
> how:
>
> 1) POD can possibly behave any differently on my machine versus anyone else's
> machine, being non-executed text and not executed code
What version of Pod::Simpl
On 7/31/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> Can anyone think of anything wrong with the approach of replacing
> require with an instrumented version? If the consensus is that that's
> a sensible approach I'll play with tidying up the code.
This is the approach I thought of. I think yo
On 7/31/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> Slightly tangential but related: is there currently a module that
> simplifies simulating the non-availability of selected modules?
>
> use unavailable qw/LWP::UserAgent/;
> use Module::That::Needs::LWP::UserAgent;
>
>From the synopsis of De
On 7/31/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> >* Test::Pod::Coverage
>
> Why does that matter? Does it care where its .t file lives?
The synopsis suggests t/pod-coverage.t.
David
On 7/30/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> `mkdir at`, but I fail to understand the resistance.
* CPANTS Kwalitee
* Module::Starter
* Test::Pod::Coverage
* ExtUtils::MakeMaker
* Module::Build
I admire your desire to engineer a better solution, but there is a lot
of inertia in the exist
On 7/30/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> Who knows when you'll run into a box in the publishing industry which
> just happens to be setup for AUTHOR_TESTING some other system. Or,
> simply the hardcore CPAN author who put it in their .bashrc and forgot
> about it until some broken pod
On 7/30/07, Christopher H. Laco <[EMAIL PROTECTED]> wrote:
> Sure, Test::Pod::Coverage could fail for some reason other than it's
> main purpose of checking coverage and finding a naked method, but so
> then can Test::More and any other test module.
Ironically, that just happened today with Statis
On 7/30/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> I agree. If I'm going to produce a patch for someone I want to run
> the author tests before I submit it.
Including the tests but leaving them disabled is my preferred
approach. It is trivial to subclass Module::Build to set the
appropriate
On 7/30/07, Ovid <[EMAIL PROTECTED]> wrote:
> aspersions on a great module. The Test::Exception/Sub::Uplevel problem
> causing false negatives was always a bit frustrating for me and it came
> out in the last email.
>
> I'm sorry if I offended you :(
Apology accepted. It frustrated me so much I w
On 7/30/07, Ovid <[EMAIL PROTECTED]> wrote:
> We also have dependencies on Sub::Uplevel (a notorious source of build
> problems),
Excuse me? CPAN::Testers for Sub::Uplevel 0.14: PASS 165 FAIL 0
There was a time when Test::Exception had things in build_requires
that should have been in requires.
On 7/28/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> * chromatic <[EMAIL PROTECTED]> [2007-07-28 19:10]:
> > Let me also suggest #3: revise the appropriate CPANTS tests to
> > add Kwalitee only if the static analysis tests do *not* run by
> > default.
>
> Maybe deduct points for depencies on obvio
On 7/24/07, Adam Kennedy <[EMAIL PROTECTED]> wrote:
He's doing it within a single test script, BAIL_OUT is for the entire
series of test scripts.
"die" is BAIL_OUT for a single test :)
That works. Or use a SKIP block.
David
t is
in the product I am testing.
If the setup phase fails, is there any point to continuing the tests
and showing the real failures? That seems like an ideal situation for
BAIL_OUT($why).
Regards,
David Golden
On 6/28/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
I was thinking there needs to be a shared filehandle with a stream of
time on it similar to the below, but with various time() and sleep()
methods overridden. Calls to time() or sleep() would peel-off lines,
thus keeping everyone in sync. It b
On 4/10/07, David Cantrell <[EMAIL PROTECTED]> wrote:
Adam Kennedy wrote:
> As email continues to get locked down more-heavily, is it worth looking
> into an alternative delivery (possibly even as the default) path for
> CPAN::Reporter?
>
> Could it be possible to set up a simple CGI'ish deliver
Oh, ++.
On 3/31/07, Thomas Klausner <[EMAIL PROTECTED]> wrote:
Hi!
Even though I was fighting mail servers today, I managed to put some time aside
for long-needed CPANTS improvements. (And I really have to thank the
Catalyst/DBIC-guys for their wonderfull tools which made me finish a big
projec
On 3/7/07, Ken Williams <[EMAIL PROTECTED]> wrote:
In the specific instance we're talking about, cc_author, I wouldn't
want it in any such file, whether per-author or per-distribution; I'd
want it as a preference I can set within the cpan-testers system.
Because if I change my mind and decide I'd
On 3/5/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
>> > Instead of having to disable (or enable) CC for every new tool,
>> > I'd want a setting that new tools could look at without me having
>> > to change the META.yml in all of my distributions then
>> > re-uploading them all.
...
>I'm just sayi
On Sunday 04 March 2007 09:40, Shlomi Fish wrote:
My solution to this is:
Of late, one solution I've used is just Ctrl-A and Ctrl-X in Vim, with
some shortcuts:
map ,at m` :silent /plan tests =>3w,/``
map ,rt m` :silent /plan tests =>3w,/``
This works well enough for simple test files.
I've had some requests for a mechanism for module authors to indicate
whether or not they want to be copied on module test emails generated
by CPAN::Reporter (particularly for passing reports). This seems like
the kind of thing that should go in the module META.yml.
Is there a de facto standard
On 2/2/07, Adrian Howard <[EMAIL PROTECTED]> wrote:
For example. Module Foo uses objects from module Bar, which uses
objects from module Ni, which uses objects from module Fribble, which
has a exception in a DESTROY block that the author deliberately
doesn't catch because it doesn't signify an er
On 1/31/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote:
Here's some pathologies that are possible and why I want to delegate
this job to a module (this is also why you don't want to do this stuff
by hand. Use a module):
If the eval ended with no errors but there was a die() during its
scope clean
On 1/30/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote:
Interestingly, this has caused me to wonder how well Test::Exception
handles the corner cases where $@ is clobbered during the scope ending
of eval{} and related. I've just filed a bug against it at
http://rt.cpan.org/Ticket/Display.html?id=2
On 1/21/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
export TEST_HARNESS_DUMP_TAP=/home/me/test.tap
export TEST_HARnESS_DUMP_YAML=/home/me/test.yaml
make test
nit: I know it breaks with tradition, but PERL_TEST_HARNESS_DUMP_TAP, etc.?
When I asked about environment variables to capture for CP
On 1/21/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 21 Jan 2007, at 13:39, David Golden wrote:
> Not just TAP. "make test" runs Test::Harness, which runs tests and
> parses the TAP with TAPx::Parser to produce a result. And then
> CPAN.pm/CPAN::Reporter would
On 1/21/07, demerphq <[EMAIL PROTECTED]> wrote:
Why cant something that wants to monitor the test process do something
other than make test?
They can do a make, and or make test-prep or whatever, and then call
into an alternative test harness framework to monitor the tests.
Can you explain why
On 1/21/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 21 Jan 2007, at 13:15, David Golden wrote:
>> Can you sketch out the interface you'd like?
>
> I vote for saving structured text files with a well-defined format in
> a well-defined location. (YAML?)
Or TAP?
On 1/21/07, Adam Kennedy <[EMAIL PROTECTED]> wrote:
The main reason I want a raw TAP stream is so that later I can rerun the
TAP parser/harness later with improved parsing code.
That said, potentially if all the TAP is merged into a single YAML
document, I can probably parse it and split it up m
On 1/21/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> Of course, it also depends upon what
> output information is being scraped. If it's only something simple
> like 'All
> tests successful', then this is an easier task.
I presume anyone who wanted to know that currently would just be call
On 1/21/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 21 Jan 2007, at 11:31, Adam Kennedy wrote:
> So, seeing as you are going to take over Test::Harness as well, is
> NOW where I ask you for the PITA-related capturing of a copy of the
> TAP streams? :)
Almost certainly :)
Can you sketch out
On 1/20/07, Ovid <[EMAIL PROTECTED]> wrote:
Obviously, nothing will get renamed to Test::Harness without Andy
Lester's blessing. Further, nothing will simply be 'rushed into place'
without extensive testing and we want to feel *extremely* comfortable
that we're not going to break anything. We w
On 1/12/07, Shlomi Fish <[EMAIL PROTECTED]> wrote:
Yuval Kogman claimed that Module::Build generates CPAN testers reports with no
output from the test harness. Now, I released Math::GrahamFunction, which is
based on Module::Build, a few days ago and today received this failure error
report:
http
On 1/5/07, Ovid <[EMAIL PROTECTED]> wrote:
> Moreover, it looks really horrid with non-monospaced fonts.
You use non-monospaced fonts in your terminal? :)
Thta's gmail for you.
David
On 1/5/07, Andy Lester <[EMAIL PROTECTED]> wrote:
On Jan 5, 2007, at 1:28 PM, Nicholas Clark wrote:
>> Failed Test | Total | Fail | List of Failed | TODO Passed
>> +---+--++
>> t/bar.t | 13| 4|2, 6-8 |3-4
>>
On 11/6/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:
And realistically, Ken, Adam and I (maintainers of the major install tools)
really control most of the META.yml generation anyway. If we don't upgrade,
you don't upgrade.
Well, that's not entirely true for things like "no_index" or var
On 11/4/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:
I'd say just check that META.yml conforms to whatever version of the spec it
says it conforms to. If it doesn't have a version, assume 1.0.
I have to second this. There really shouldn't be separate "conforms
to 1.0" and "conforms to 1.
On 11/5/06, Steffen Mueller <[EMAIL PROTECTED]> wrote:
How about a mandatory or optional metric for modules registered with the
modules list? Why is that a sign of (q|kw)alit(y|ee)? Because it means
the author has the blessing of the module list maintainers as far as the
choice of namespace goes.
On 11/3/06, Christopher H. Laco <[EMAIL PROTECTED]> wrote:
> meta-spec:
> url: http://module-build.sourceforge.net/META-spec-v1.2.html
> version: 1.2
The one caution I'd give is around "no_index". The spec always called
for "dir" for directories, but CPAN/PAUSE were checking for
"d
On 11/2/06, Chris Dolan <[EMAIL PROTECTED]> wrote:
It's not an EU::MM bug -- it's a new M::B feature.
What should you do? You're not going to like this answer:
Don't use recursive test directories. :-)
Chris
Does Test::Manifest support nested test files? If so, that might be
an alternative.
On 11/1/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Contact all the authors making use of it and suggest they switch to .t files. Maybe I
could throw a warning into MakeMaker. Also a kwalitee check sounds like a good idea
"not_only_test.pl" or something.
It shouldn't be "not_only". If
On 10/31/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
In a way this is what Linux distros do or ActiveState does, but I
would like to do it
on CPAN level and still in source code.
As a start I could possibly creat a minicpan for particular modules
and their cross-tested
versions.
Does this make se
On 10/30/06, Andreas J. Koenig <[EMAIL PROTECTED]> wrote:
> On Tue, 31 Oct 2006 00:23:09 +0200, "Gabor Szabo" <[EMAIL PROTECTED]>
said:
> The mapping of flag to Module-Version pairs could actually reside on any
> server with ftp or http access. CPAN.pm would be configured to use such
On 10/30/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:
This is not Test.pm's fault but the fact that test.pl is not run through
Test::Harness by MakeMaker.This is a historical accident. No, I won't
change it. Many test.pl's do not output TAP. For example, DBI's test.pl
contains bench
examples metric is the same:
$ touch examples/not_really_an_example
That scores the extra point. And so what?
I'd be much more interested in seeing effort put into things like
checking if detectable prerequisites are listed in the META.yml.
Regards,
David Golden
r
Makefile.PL or META.yml.
Regards,
David Golden
See Win32::TieRegistry
http://search.cpan.org/dist/Win32-TieRegistry
Regards,
David Golden
On 17 Oct 2006 07:33:16 -0700, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
I am on a fact finding mission.
Can Perl be used to update a value in the Windows Registry? If so,
does anyone have
I think this thread is headed towards completely over-engineering this.
For those who really want to customize what gets run when, I think brian's
Test::Manifest solution looks like a winner.
WIth environment variables, I prefer simplicity:
* AUTOMATED_TESTING -- signals that it's *unattended*,
On 10/3/06, Joshua ben Jore <[EMAIL PROTECTED]> wrote:
Fine, I just didn't feel like inventing a list on the spot. There's a
list of values we know perl uses internally. I see David missed
LANGUAGE, LC_ALL, and LANG.
You'd want to be careful not to do qr/^PERL/ because MACPERL doesn't
match tha
On 10/3/06, Alexandr Ciornii <[EMAIL PROTECTED]> wrote:
IMHO, including whole %ENV whould be unsafe. We can create list of
variables to be included. PERL5OPT. Any others? Also maybe
user-configurable list, where user himself decides which variables he
wants to include.
I posted about this r
On 10/2/06, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
CPAN Test reports follow a fairly rigid format that computers can easily
detect. I think it's worth auto-whitelisting messages that look like
"FAIL Foo::Bar 3.14_15" or "PASS Hello::World 2.71". The CPAN::Reporter
(?) and CPANPLUS mails l
and be deluged
with thousands of emails or don't subscribe to the list and accept that your
test reports won't show up immediately. Personally, I have a dummy e-mail
address I use for cpan-testers and use it to filter all test reports except
my own.
Regards,
David Golden
t now, the fallback is that I run
test.plagain to capture the exit code if I can't detect a failure for
other
reasons. E.g. if t/*.t had a failure and there is also a test.pl, I don't
rerun test.pl.
Regards,
David Golden
On 9/28/06, Uwe Voelker <[EMAIL PROTECTED]> wrote:
debian% make
perl -e "die"
Died at -e line 1.
make: *** [all] Fehler 255
It's a Debian Etch with German locale.
Of course. Locales. It all seemed too easy.
Time for plan B.
David
command that CPAN.pm constructs and hands to CPAN::Reporter. Or even just
use qr/^\S*make/ -- though the fuzzier the string the more I worry about
false positives.
Regards,
David Golden
"make" program
returns on failure and let me know.
Thanks very much.
Regards,
David Golden
201 - 300 of 402 matches
Mail list logo
