It can encounter a weird segfault on OS X with sqlite when Qt is present (?!)
The main reason to use the fork was to get the port number,
but this is easy now that notebooks write a server-info file.
Further advantage is that the symptom of a failed server start
is no longer silence and hanging tests, but an actual failure with the server's log output.
Add a setup() method to be called when we know we're going to use a test
group, for creating temporary dirs etc., and a print_extra_info() method
to display extra information.
* Closing old pages to prevent fd leaks.
* Making sure kernels are killed to prevent fd leaks.
* Moving towards deleting old notebooks (this is not done, but
this should be merged as is).
This supersedes PR #4268.
Run the tests with '--subproc-streams show' to show output from
subprocesses (kernels, IPython.parallel components) in the terminal, or
with '--subproc-streams discard' to send it to /dev/null. By default (or
with '--subproc-streams capture') the output is piped, captured and
displayed only when tests fail. But in some situations, a test fails
because of an error which actually occurred earlier, so you have to see
all the output.
An interaction between wx and threads was blocking certain Unix signals,
causing an unrelated test to fail for me.
We were only checking for wx to exclude the inputhookwx module from the
test run. It contains no tests anyway, so we may as well just exclude it
in all cases.
Rather than using a transient pipe for each subprocess started, the
StreamCapturer now makes a single pipe, and subprocesses redirect their
output to it.
So long as this works on Windows (I've done brief testing, and os.pipe()
seems to be functional), this will hopefully make this much more robust.
The recent failures in ShiningPanda on IPython.parallel have been caused
by StreamCapturer.