Consider a simple C function void say_hi() { printf("Hello World!\n"); } which you compile and call from Python via Cython, Boost.Python, ctypes, or any other means.
Calling say_hi() in the python console and plain IPython both work as desired:
>>> say_hi()
Hello World!
However in any of the multiprocess IPython interfaces (parallel, qtconsole, console, notebook) the command appears to do nothing at all:
Of course what is actually happening is that the text is being written directly to the C stdout file descriptor so the zmq stdout redirection has no chance to grab the text.
In most cases, the easiest way to deal with this problem is to rewrite your C source to use Pythonic methods, e.g. PySys_WriteStdout:
#define printf PySys_WriteStdout
But sometimes the printf statements lie in libraries for which you have little (or no) control of the actual source code. In this case it'd be convenient for IPython to capture the OS level stdout and stderr file descriptors and send their contents in the zmq streams. This functionality was once in IPython (cf 97262e9), but has not AFAIK been resurrected in the zmq era.
A similar approach is likely feasible, but there are many potential issues in implementation (e.g., ipython console might be tricky because there we need a functioning stdout for printing to the terminal!).
At a minimum I think we need to document this behavior for confused users. Beyond that it'd be great to offer a simple script, or configuration profile option which enables this OS level stdout/stderr capture.
Consider a simple C function
void say_hi() { printf("Hello World!\n"); }which you compile and call from Python via Cython, Boost.Python, ctypes, or any other means.Calling
say_hi()in the python console and plain IPython both work as desired:However in any of the multiprocess IPython interfaces (parallel, qtconsole, console, notebook) the command appears to do nothing at all:
Of course what is actually happening is that the text is being written directly to the C stdout file descriptor so the zmq stdout redirection has no chance to grab the text.
In most cases, the easiest way to deal with this problem is to rewrite your C source to use Pythonic methods, e.g. PySys_WriteStdout:
But sometimes the printf statements lie in libraries for which you have little (or no) control of the actual source code. In this case it'd be convenient for IPython to capture the OS level stdout and stderr file descriptors and send their contents in the zmq streams. This functionality was once in IPython (cf 97262e9), but has not AFAIK been resurrected in the zmq era.
A similar approach is likely feasible, but there are many potential issues in implementation (e.g.,
ipython consolemight be tricky because there we need a functioning stdout for printing to the terminal!).At a minimum I think we need to document this behavior for confused users. Beyond that it'd be great to offer a simple script, or configuration profile option which enables this OS level stdout/stderr capture.