Ovid wrote:
- Original Message
From: ivorw <[EMAIL PROTECTED]>
I've had similar issues with test output out of sequence, especially when
I pipe the output into more or tee (sometimes 2>&1 helps, but not
always).
What about an optional environment variable which forcess *all* output t
Ovid wrote:
- Original Message
From: Andy Lester <[EMAIL PROTECTED]>
I think I might just JFDI a "T::H goes to STDOUT" release.
You can call it the "Ovid wants to have Petdance's children" release. Anyone
care to place bets as to whether or not anything depends on this behavior?
Rafael Garcia-Suarez wrote:
Ovid wrote in perl.qa :
I've had similar issues with test output out of sequence, especially when
I pipe the output into more or tee (sometimes 2>&1 helps, but not
always).
What about an optional environment variable which forcess *all* output
to STDOUT or STDERR bu
I should also note that ADAMK's Perl::Metrics provides a heavy-weight
alternative, using Class::DBI to persist metrics data. At present I'm
interested in something with fewer dependencies.
Well, it doesn't do the actual metrics.
It's a platform for doing the processing and storage of metrics,
On Sep 4, 2006, at 4:15 PM, Ovid wrote:
You can call it the "Ovid wants to have Petdance's children"
release. Anyone care to place bets as to whether or not anything
depends on this behavior?
PLease note as David pointed out that it's really Test::Builder
that's the issue here.
--
And
- Original Message
From: Andy Lester <[EMAIL PROTECTED]>
> I think I might just JFDI a "T::H goes to STDOUT" release.
You can call it the "Ovid wants to have Petdance's children" release. Anyone
care to place bets as to whether or not anything depends on this behavior?
Cheers,
Ovid
On Sep 4, 2006, at 4:00 AM, Leon Brocard wrote:
On 9/4/06, Matisse Enzer <[EMAIL PROTECTED]> wrote:
I've started working on a module to analyze perl code and give
reports like this:
Neato. Kind of similar to my Perl::Metric::Basic:
http://search.cpan.org/dist/Perl-Metric-Basic/
Thanks -
On Sep 4, 2006, at 10:58, Andy Lester wrote:
I think I might just JFDI a "T::H goes to STDOUT" release.
That won't preveing T::B from sending output to two different file
handles…
Best,
David
On Sep 4, 2006, at 07:19, Ovid wrote:
Actually, I'm not sure how this would break anything and *I* don't
see a problem with it, but since the current behavior is to use
separate file handles, I'm not sure if there's anyone relying on
the current behavior. However, given that it's so widesp
On Sep 4, 2006, at 12:44 PM, chromatic wrote:
T::H didn't always know how to cope with that. I patched it within
the past
couple of years.
I think it's a long-time backwards compatibility issue, but I don't
feel
strongly about it.
I think I might just JFDI a "T::H goes to STDOUT" relea
On Monday 04 September 2006 07:12, Rafael Garcia-Suarez wrote:
> What's exactly the problem with sending everything to stdout by default?
> T::H knows how to cope with that.
T::H didn't always know how to cope with that. I patched it within the past
couple of years.
I think it's a long-time ba
- Original Message
From: Rafael Garcia-Suarez <[EMAIL PROTECTED]>
> What's exactly the problem with sending everything to stdout by default?
> T::H knows how to cope with that. I don't like the environment variable
> idea. It's easy to forget your environment and be surprised when
> switc
Ovid wrote in perl.qa :
>> I've had similar issues with test output out of sequence, especially when
>> I pipe the output into more or tee (sometimes 2>&1 helps, but not
>> always).
>
> What about an optional environment variable which forcess *all* output
> to STDOUT or STDERR but, if not present
- Original Message
From: ivorw <[EMAIL PROTECTED]>
> I've had similar issues with test output out of sequence, especially when
> I pipe the output into more or tee (sometimes 2>&1 helps, but not
> always).
What about an optional environment variable which forcess *all* output to
STDOUT
> -Original Message-
> From: demerphq [mailto:[EMAIL PROTECTED]
> Sent: 04 September 2006 13:13
> To: Ovid
> Cc: perl-qa@perl.org
> Subject: Re: Terrible diagnostic failure
>
>
> On 9/4/06, Ovid <[EMAIL PROTECTED]> wrote:
> > Once again we have an example of how using different output
On 9/4/06, Ovid <[EMAIL PROTECTED]> wrote:
Once again we have an example of how using different output streams for regular
and diagnostic information causes serious problems. This is the worst I've
seen. In one method I'm testing I embedded the following:
use Data::Dumper;
::diag(Dat
Once again we have an example of how using different output streams for regular
and diagnostic information causes serious problems. This is the worst I've
seen. In one method I'm testing I embedded the following:
use Data::Dumper;
::diag(Data::Dumper->Dump(
[$stripped, [EMAIL
On 9/4/06, Matisse Enzer <[EMAIL PROTECTED]> wrote:
I've started working on a module to analyze perl code and give
reports like this:
Neato. Kind of similar to my Perl::Metric::Basic:
http://search.cpan.org/dist/Perl-Metric-Basic/
Regards, Leon
http://www.pobox.com/~schwern/src/Test-Simple-0.64_01.tar.gz
This release of Test::More is primarily to remove support for threads in 5.8.0.
Threads are just too buggy in that version and I'm tired of getting bug
reports about the same failing test from 5.8.0 users.
There is also a minor chan
On Sep 3, 2006, at 6:45 PM, Andy Lester wrote:
On Sep 3, 2006, at 8:42 PM, Matisse Enzer wrote:
The module is (very tentively) named Perl::Code::Analyze and uses
Adam Kennedy's PPI module for the real work.
Excellent! Although I'm wondering if it could get folded into
Perl::Critic som
20 matches
Mail list logo
