Re: [lmi] Patches for stderr output

[Greg Chicares]

On 2014-12-04 21:08Z, Vadim Zeitlin wrote:
> On Thu, 04 Dec 2014 04:43:17 +0000 Greg Chicares <address@hidden> wrote:
[...]
>  In the meanwhile, to finish with this one: I don't actually think writing
> everything to stdout is correct neither. It's arguably more correct than
> writing everything to stderr, but the ideal behaviour would seem to be to
> write the test progress messages to stdout while sending the errors to
> stderr. This can't be done with any standard class such as wxLogStderr but
> it's not difficult to define a custom log target which would do it. Do you
> think it's worth doing this or is the trivial patch above enough?

I applied your patch on 20141205T1720Z, revision 6045.

It's more than enough: it's actually preferable. Normally it would be
better to keep stdout and stderr separate, but in this case we will
never want them separated: we really do want to write all output to
a file, and we're just using the standard stream as an anonymous file.

We could write to separate streams and combine them with '2>&1'. But
a few years ago I had a problem with separate streams. IIRC, stdout
and stderr were buffered differently: perhaps one was "line buffered"
and the other "unbuffered", or something like that. Keeping them
separate and then recombining them with '2>&1' made the output order
indeterminate, and IIRC I discussed that with the compiler maintainer
and learned that this is not a compiler defect. Our only use case is
redirecting output into a file for comparison with results from
stored prior runs. Separate streams are never helpful here, and may
be harmful, so your patch is actually ideal.

> GC> All lines on stderr begin "[TEST] " except for one:
> GC> 
> GC> [TEST] benchmark_census: started
> GC> Run case for census_1: 423ms elapsed (expected -2.53%)
> GC> [TEST] benchmark_census: ERROR (Assertion 'std::fabs(diff_in_percents) < 
> 10' ...
> GC> 
> GC> Is that intentional?
> 
>  I wouldn't go as far as saying that this is intentional, but I am not
> actually sure how should this behave. Do we want to have "[TEST] " prefix
> for all messages produced by the testing code?

Actually, we prefer to use no such prefix ever. So that I can focus
on your other message about logging, could I ask you to propose a
patch to remove the prefix?

>  So my outstanding questions here are:
> 
> 1. Do we want to send [only] messages about test errors to stderr?

No, with your patch, lmi HEAD now does exactly what we want.

> 2. For which messages, if any, do we want to have "[TEST] " prefix?

For none, please.