In a mailing list post, it was mentioned that stack test hides output from parallel tests to prevent interleaving.
Indeed, this was the traditional behavior of cabal -- to link parallelism to output verbosity. But this always annoyed me; rather, I argue that these are orthogonal configuration options that should be controlled by separate flags. In particular there are good ways to handle the concurrent output that do not require ugly interleaving.
- gather output from parallel sub-tasks but stream it to stdout in the order that the sequential execution would have (deterministic)
- allow nondeterminism in overall ordering, but only pass through output from subtasks that have completed.
- monitor output in real time and elect the sub-task with either the highest rate of ongoing output, or the highest likelyhood of completion to hold stdout. The semantics of this are the same as option (2), but the perceived latency should be lower, as there is always some sub-task holding onto stdout.
- interleave output but prefix it with some identifying
[tag], and possibly buffer it for a second or more so that it gets grouped into "chunks" rather than interleaved lines or characters. This option offers an upper-bound on delay to any individual output line.
- (whimsical) split the screen as many times as necessary to show the concurrent output. This is a fun way to visualize the degree of parallelism, and I played around with this in a little library called hydra-print based on the
io-streams package.
I see that stack already depends on conduit. This seems like the kind of issue that could be solved generally, once and for all, at the conduit level. But, that presumes that stdout/stderr are captured and routed in all the right places.
I haven't read much of the code, but having a look at Execute.hs, it looks like the notion of parallel actions includes exception handling but not output streams.
On the other hand, Read.hs contains machinery for capturing output of sub-processes, and try/readProcessStdout are called in various places. But actions like running tests are handled by the underlying Cabal library, right? Does that mean their output can't be managed easily without changing Cabal?
Anyway, if a capability for generally handling output stream muxing/demuxing would be a desired feature I'd like to lend a hand with this.
In a mailing list post, it was mentioned that
stack testhides output from parallel tests to prevent interleaving.Indeed, this was the traditional behavior of cabal -- to link parallelism to output verbosity. But this always annoyed me; rather, I argue that these are orthogonal configuration options that should be controlled by separate flags. In particular there are good ways to handle the concurrent output that do not require ugly interleaving.
[tag], and possibly buffer it for a second or more so that it gets grouped into "chunks" rather than interleaved lines or characters. This option offers an upper-bound on delay to any individual output line.io-streamspackage.I see that
stackalready depends on conduit. This seems like the kind of issue that could be solved generally, once and for all, at the conduit level. But, that presumes that stdout/stderr are captured and routed in all the right places.I haven't read much of the code, but having a look at Execute.hs, it looks like the notion of parallel actions includes exception handling but not output streams.
On the other hand,
Read.hscontains machinery for capturing output of sub-processes, andtry/readProcessStdoutare called in various places. But actions like running tests are handled by the underlyingCaballibrary, right? Does that mean their output can't be managed easily without changing Cabal?Anyway, if a capability for generally handling output stream muxing/demuxing would be a desired feature I'd like to lend a hand with this.