printf capture

printf capture

Dear All,

I'm running R-2.4.1 on WindowsXP.
I wrote a small C++ DLL using Rprintf() and all works fine
dyn.load(), is.loaded('f1'), Rprintf(), .C(), all is ok.

Now, the worry :
I use also a 3rd party piece of C++ program which was not designed
for R and uses printf().

I though on sink(...) before .C('f1'), but it doesn't work.
I call sink(file="res.txt") and only the Rprintf() are catched

Is there any way to however capture those printf() outputs ?

Thanks for any hint/pointer (... and i apologize
if i missed something obvious !).

Vincent

(for what may be worth, a "minimal" stuff is at www.khi.fr/IB/rp2)

If you are using Rgui (it should work under rterm) there is no C-level 
'stdout' file stream (the normal state for Windows GUI programs), so no 
way to capture it inside R.

On Thu, 12 Apr 2007, mel wrote:

  

printf capture

Dear All,

I'm running R-2.4.1 on WindowsXP.
I wrote a small C++ DLL using Rprintf() and all works fine
dyn.load(), is.loaded('f1'), Rprintf(), .C(), all is ok.

Now, the worry :
I use also a 3rd party piece of C++ program which was not designed
for R and uses printf().
    

If you have the program, can you not edit it before compiling it?
Adding

#define printf Rprintf

will probably do the trick.

  

I though on sink(...) before .C('f1'), but it doesn't work.
I call sink(file="res.txt") and only the Rprintf() are catched

Is there any way to however capture those printf() outputs ?

Thanks for any hint/pointer (... and i apologize
if i missed something obvious !).

Vincent

(for what may be worth, a "minimal" stuff is at www.khi.fr/IB/rp2)

If you are using Rgui (it should work under rterm) 

there is no C-level 'stdout' file stream (the normal state
for Windows GUI programs), so no way to capture it inside R.

If you have the program, can you not edit it before compiling it?
Adding
#define printf Rprintf
will probably do the trick.

Prof Brian Ripley a ?crit :

If you are using Rgui (it should work under rterm)

yes indeed, it works under rterm

there is no C-level 'stdout' file stream (the normal state
for Windows GUI programs), so no way to capture it inside R.

Aie ! (I feared this answer). Thanks however for the explanation.
I was looking at pipe(), scan() etc.
So, no hope from this side.

If you have the program, can you not edit it before compiling it?
Adding
#define printf Rprintf
will probably do the trick.

yes thanks, I already though on that, and it works.
But i would have preferred not touching this 3rd party code.

=====================================

There is another little annoyance (always on WindowsXP + R-2.4.1)
When including both <windows.h> and <R.h>
#include <windows.h>
#include <R.h>

There is a #define ERROR redefinition

#define ERROR ),error(R_problem_buf);} // this one in Rs.h
#define ERROR 0                        //  in MinGW/.../wingdi.h

It's only a warning, but i would prefer to avoid it
and i'm searching how to avoid it.
Thanks for any idea.

PS : compilation details :

g++ -IJ:/softs/R-2.4.1/include -c f1.cpp -o f1.o
In file included from J:/softs/R-2.4.1/include/R.h:49,
                 from f1.cpp:11:
J:/softs/R-2.4.1/include/R_ext/RS.h:40:1: warning: "ERROR" redefined
In file included from
f:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windows.h:52,
                 from f1.cpp:10:
f:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/wingdi.h:313:1:
warning: this is the location of the previous definition

You can always link in a wrapper that defined printf and passes the 
arguments to Rprintf.

It's documented in 'Writing R Extensions'.
  The defines used for compatibility with @Sl{} sometimes causes
  conflicts (notably with Windows headers), and the known
  problematic defines can be removed by defining @code{STRICT_R_HEADERS}.

Prof Brian Ripley a ?crit :

You can always link in a wrapper that defined printf and passes  
the arguments to Rprintf.

I apologize but confess i didn't completely understand this  
suggestion.

It's documented in 'Writing R Extensions'.
  The defines used for compatibility with @Sl{} sometimes causes
  conflicts (notably with Windows headers), and the known
  problematic defines can be removed by defining @code 
{STRICT_R_HEADERS}.

Yes, i added
#define STRICT_R_HEADERS
in my cpp code, and the redefinition warning vanishes indeed.

Many thanks for your precise tips and my apologies for the late  
answer.

The wrapper:

#include <R.h>

int printf(const char *format, ...) {
  va_list (ap);
  va_start(ap, format);
  Rvprintf((char*)format, ap);
  va_end(ap);
  return 0;
}

If you link this in your project (simply create a separate object file 
with this), the project will be using Rprintf via this wrapper instead 
of printf from libc. Note that you shouldn't be relying on the return 
value literally, otherwise you're in trouble ;).

Cheers,
Simon