On 18/01/13 02:02, Utpal Sarkar wrote:
Hi,
I was assuming that sys.stdout would be referencing the same physical stream as
iostreams::cout running in the same process, but this doesn't seem to be the
case.
The following code, which makes a call to a C++ function with a python wrapper called
"
On Fri, Jan 18, 2013 at 2:51 AM, Utpal Sarkar wrote:
> Thanks a lot Chris and Nobody! I'll have a look at dup2 for a start.
Okay. Look for code that redirects the standard I/O streams and then
exec()s another process (possibly after fork()ing); you're going to be
doing pretty much the same thing.
Thanks a lot Chris and Nobody! I'll have a look at dup2 for a start.
> > I was assuming that sys.stdout would be referencing the same physical
> > stream as iostreams::cout running in the same process, but this doesn't
> > seem to be the case.
>
>
>
> That's more-or-less true, but there will
On Fri, Jan 18, 2013 at 2:02 AM, Utpal Sarkar wrote:
> I was assuming that sys.stdout would be referencing the same physical stream
> as iostreams::cout running in the same process, but this doesn't seem to be
> the case.
That's more-or-less true, but there will likely be separate buffering,
so
On Thu, 17 Jan 2013 07:02:24 -0800, Utpal Sarkar wrote:
> I was assuming that sys.stdout would be referencing the same physical
> stream as iostreams::cout running in the same process, but this doesn't
> seem to be the case.
At startup, it refers to the same FILE* as C's stdout. This initially
sh
Hi,
I was assuming that sys.stdout would be referencing the same physical stream as
iostreams::cout running in the same process, but this doesn't seem to be the
case.
The following code, which makes a call to a C++ function with a python wrapper
called "write", that writes to cout:
from cStrin
