- Original Message
From: Michael G Schwern <[EMAIL PROTECTED]>
> Something to consider in all this is that TAPx::Parser
> needs to know to display what goes to STDERR
> and suppress what goes to STDOUT. This means
> you simply can't mash the two streams together,
> you have to read them
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. Oth
I had lots of trouble getting IPC::Run to work well on Win32; if it
worked well there, I'd recommend it for this application.
If anyone knows how, in Perl, to open up to 3 pipes and then use
WaitForMultipleObjects() on the ends the parent process reads & writes,
please let me know. That's the
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
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 STDOU
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 m
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 e
On 18 Sep 2006, at 17:39, chromatic wrote:
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 poi
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?
>
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 tha
* 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
- 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 W
- 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
> 2>&1 seems to make my tests pass on a Linux box, but that
> strikes me as bizarre as I thought STDERR w
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 2>&1 |" ) {
return
- 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
>
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.
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
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
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_'.
I've
- 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
>
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
21 matches
Mail list logo
