> -----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 
> 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 PROTECTED],
> >         [qw<$stripped *records> ]
> >     ));
> >
> > And here's the output in the test:
> >
> >   ok 14 - ... and splitting the sql into individual 
> statements should succeed
> >   # $stripped = 'alter table test_colors add column foo 
> varchar(200)';
> >   ok 15 - ... and splitting the sql should succeed
> >   # @records = (
> >   ok 16 - ... but the original SQL should remain unchanged
> >   #              'alter table test_colors add column foo 
> varchar(200)'
> >   #            );
> >   not ok 17 - We should be able to "split" a single statement
> >
> > Ouch.  This is what I 'normally' see when I run this:
> >
> >   ok 14 - ... and splitting the sql into individual 
> statements should succeed
> >   ok 15 - ... and splitting the sql should succeed
> >   ok 16 - ... but the original SQL should remain unchanged
> >   # $stripped = 'alter table test_colors add column foo 
> varchar(200)';
> >   # @records = (
> >   #              'alter table test_colors add column foo 
> varchar(200)'
> >   #            );
> 
> This looks like buffering issues to me. I see stuff like this all the
> time when i run code through an editor. Perl tests to see if stdout
> (and maybe stderr) are terminals and then automatically turns on
> auto-flush when they are. But when i launch the script via my editor
> apparently perl thinks its not dealing with a terminal and doesnt
> buffer the filehandles, resulting in output much like you have above.
> So i wonder if you manually turn on autoflushing of all the output
> handles if that helps.
>
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). I've 
not had consistent behaviour between operating systems and between perl 
versions, but I've not had time to nail the circumstances.

I've also had flushing problems with the debugger, with tests that fork a child 
process (especially with open2 and open3). I find that I lose the results from 
the child, but if I run outside the debugger I am OK.

Ivor.

Reply via email to