Re: Bad TAP in Perl core?

2006-09-18 Thread Michael G Schwern
Ovid wrote: - Original Message From: Michael G Schwern [EMAIL PROTECTED] foreach $test (11..14) {print ok $test # skipped on non-VMS system\n}; That unescaped hash mark is causing me lots of pain. Because its not an unescaped hash mark. Its an old school skip directive.

Re: Bad TAP in Perl core?

2006-09-18 Thread Ovid
- Original Message From: Michael G Schwern [EMAIL PROTECTED] In regex terms, a directive is simply ($type, $reason) = /#\s*(\S+)(?:\s+(.*))?$/. TAPx::Parser can record the type and reason and move along. You might want to warn about the unknown directive type, but consider this

TAPx::Parser plans

2006-09-18 Thread Ovid
Various notes for those who are curious. Please remember that the parser is still alpha software! I have no plans to label it beta until such time that I know all core features are added. With luck, they'll be working, too. Feedback appreciated. * Rename all boolean methods with 'is_'.

Re: A short rant on the purpose of the CPAN install chain.

2006-09-18 Thread David Golden
Al Tobey wrote: Sysadmins everywhere feel this broken tests are a good thing syndrome as real, almost physical, pain nearly every time they work with CPAN these days. It's great that TDD is making the progress it has, but I think some coders got religion and missed the point: quality. Maybe

Re: Bad TAP in Perl core?

2006-09-18 Thread Michael G Schwern
Ovid wrote: - Original Message From: Michael G Schwern [EMAIL PROTECTED] In regex terms, a directive is simply ($type, $reason) = /#\s*(\S+)(?:\s+(.*))?$/. TAPx::Parser can record the type and reason and move along. You might want to warn about the unknown directive type, but

Re: A short rant on the purpose of the CPAN install chain.

2006-09-18 Thread chromatic
On Monday 18 September 2006 03:26, David Golden wrote: I think authors need to aim to have the quality of test code be the same as the quality of module code.  (Though I'll admit that I don't always live up to that standard myself.) At some point, this ought to be a major goal of Perl QA.

Re: Terrible diagnostic failure

2006-09-18 Thread Ovid
- Original Message From: Michael G Schwern [EMAIL PROTECTED] What about an optional environment variable which forcess *all* output to STDOUT or STDERR but, if not present, leaves things as is? Did anyone think to try it? $ cat ~/tmp/stdout.t #!/usr/bin/perl -w use

Re: Terrible diagnostic failure

2006-09-18 Thread Chris Dolan
On Sep 18, 2006, at 11:55 AM, Ovid wrote: I have a bit of a problem, I think. It could simply be a matter of misunderstanding how things work, but I have the following bit of code in TAPx::Parser::Source::Perl: my $sym = gensym; if ( open $sym, $command 21 | ) { return

Re: Terrible diagnostic failure

2006-09-18 Thread Ovid
- Original Message From: Ovid [EMAIL PROTECTED] If Test::Builder accepted an environment variable which allowed me to override this, I might have a way out. So far removing the 21 seems to make my tests pass on a Linux box, but that strikes me as bizarre as I thought STDERR wouldn't

Re: Terrible diagnostic failure

2006-09-18 Thread Ovid
- Original Message From: Chris Dolan [EMAIL PROTECTED] Try IPC::Open3, it's in the Perl core. http://search.cpan.org/perldoc?IPC::Open3 IPC::Run3 is supposed to be good on Windows, but I haven't tried it enough. http://search.cpan.org/perldoc?IPC::Run3 Anyone have a Windows

Re: Terrible diagnostic failure

2006-09-18 Thread Ricardo SIGNES
* Ovid [EMAIL PROTECTED] [2006-09-18T13:18:19] Anyone have a Windows box and is willing to test this out for me? I will gladly run tests under WinXP + Strawberry if you tell me where to get it and what you want to know. Drop me an IM or email. -- rjbs

Re: Breaking compatability with Test::Harness and friends?

2006-09-18 Thread Adrian Howard
On 17 Sep 2006, at 23:25, Fergal Daly wrote: [snip] So while I don't think I'd vote for stopping the install because of an expected pass, I don't think it's ever a good sign. The idea of something working better than than the author expected is a bit dubious. [snip] I'm not so sure about

Re: Terrible diagnostic failure

2006-09-18 Thread demerphq
On 9/18/06, Ovid [EMAIL PROTECTED] wrote: - Original Message From: Michael G Schwern [EMAIL PROTECTED] What about an optional environment variable which forcess *all* output to STDOUT or STDERR but, if not present, leaves things as is? Did anyone think to try it? $ cat

Re: Breaking compatability with Test::Harness and friends?

2006-09-18 Thread Fergal Daly
On 18/09/06, Adrian Howard [EMAIL PROTECTED] wrote: On 17 Sep 2006, at 23:25, Fergal Daly wrote: [snip] So while I don't think I'd vote for stopping the install because of an expected pass, I don't think it's ever a good sign. The idea of something working better than than the author

Redirecting STDERR/STDOUT on Win32 (was Re: Terrible diagnostic failure)

2006-09-18 Thread David Golden
demerphq wrote: On 9/18/06, Ovid [EMAIL PROTECTED] wrote: I've gotten a report that the open command fails on Windows. Not a surprise, now that I think about it. However, I don't know of any portable way of forcing STDERR to STDOUT (and I don't have a Windows box handy). This means that my

Re: Redirecting STDERR/STDOUT on Win32 (was Re: Terrible diagnostic failure)

2006-09-18 Thread demerphq
On 9/18/06, David Golden [EMAIL PROTECTED] wrote: demerphq wrote: On 9/18/06, Ovid [EMAIL PROTECTED] wrote: I've gotten a report that the open command fails on Windows. Not a surprise, now that I think about it. However, I don't know of any portable way of forcing STDERR to STDOUT (and I

Re: Redirecting STDERR/STDOUT on Win32 (was Re: Terrible diagnostic failure)

2006-09-18 Thread Michael G Schwern
demerphq wrote: I found that the suggested code for saving and restoring STDOUT and STDERR given in perldoc -f open seems to work OK. This is essentially what IPC::Run3 is doing -- capturing to an external file and then reading it back in and making it available. Yeah, but thats a can of

Re: Breaking compatability with Test::Harness and friends?

2006-09-18 Thread Michael G Schwern
Fergal Daly wrote: But there's nothing here for the author to do so it should not be marked TODO. Sure there is. They now know Fribble works and can once again start relying on it. This should be a skip wrapped in something to test if the installed version of Fribble works or not.