ConsoleReporter and line buffering

[Adam Bergmark]

I noticed that the ConsoleReporter calls "hSetBuffering stdout NoBuffering", I often want to print things while i'm writing tests and this garbles the output (even with --num-threads 1). Is it there for a reason it's there?

It's possible to override it by doing "defaultMain . withResource (hSetBuffering stdout LineBuffering) (const $ return ()) . const" but it feels a bit hacky :-)

Regards,

Adam

[Roman Cheplyaka]

Yes, it's there for a reason. We need to print the test name, then wait
for test completion, then print its status on the same line. Since the
test may take a long time to complete, it's nice when we see which test
is being waited for.

I assume you're asking because of https://github.com/feuerbach/tasty/issues/55
Well, if your processes print directly to stdout, then line buffering
is not a proper solution anyway since buffering inside your processes
and Haskell's buffering are independent, so you still may observe
interleaved output (although perhaps with smaller probability).

Another reason why printing and ConsoleReporter are incompatible has to
do with --hide-successes. It needs to erase test names that completed
successfully. If there's side output to the console, this can't be done
properly.

If you want this interleaving badly, write your own TestReporter and
insert synchronisation points as you need. This would be the most
correct solution, I think. You may have to sacrifice some of
ConsoleReporter's capabilities, though.

* Adam Bergmark <ad...@bergmark.nl> [2014-02-27 07:55:42-0800]

> --
> You received this message because you are subscribed to the Google Groups "tasty" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to haskell-tast...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Adam Bergmark]

Okay, thanks for the explanation!

It's actually a different test suite this time, it has synchronous tests so it seems to be fine to just override the buffering like I did.

I was a bit ambiguous in my phrasing, this is just for temporary logging while I'm writing the tests. After that I remove these log statements.

So I think I'll just keep my hack, no need to make a new reporter.

- Adam