CONSISTENCY: Should all futures capture stdout & stderr as well?

[HenrikBengtsson]

Should all futures capture stdout & stderr as well, at least as an options, such that we can get a consistent behavior also for such output across all types of futures?

UPDATE: It's possible to stack output to stdout, e.g.

> x <- capture.output({
+   print(1)
+   y <- capture.output(print(2))
+   print(3)
+   cat(y)
+ })
> x
[1] "[1] 1" "[1] 3" "[1] 2"

However, it's not possible to stack message (stderr) outputs:

> x <- capture.output({
+   message(1)
+   y <- capture.output(message(2), type="message")
+   message(3)
+   message(y)
+ }, type="message")
3
2
> x
[1] "1"

The latter two lines are outputted to the message, which reopened, because the inner capture resets it to the default when it closes it's redirect.

[HenrikBengtsson]

Note: To move forward on this one, I think one should ignore stderr for now (because it's non-stackable by sink), and just worry about capturing standard output (stdout). The API could be extended using:

$ f <- future(..., stdout = TRUE)  ## stdout = TRUE could be the new default.
$ v <- value(f)
$ str <- captured_stdout(f)

Need a better name than captured_stdout() though.

[HenrikBengtsson]

Another feature could be a show_stdout() to display the captured output locally.

Another related feature is to have this called asap/automatically, i.e. when the value has been retrieved. A generalization of that thought leads to hook functions.

[HenrikBengtsson]

UPDATE 2018-03-05: (in the develop branch) I've taken the first fundamental step required to make it possible to return not only the value of a future expression but also any output captured while resolving the future. It's unlikely that this will be supported in the next release of the future package, but we're now much closer than before.

[HenrikBengtsson]

Moved to Issue #232. Closing this one.