On Apr 23, 2013, at 12:43 PM, dpleydell wrote:
Many thanks Simon for your response
Identifying the source of the message is a non-trivial problem because there are a large number of calls to printf and fprintf etc in several thousands of lines of code spread over many different *.c files.
There should be none, so apparently you have broken the rules quite a lot ;). This is not a new rule, R just got better at identifying the transgressions. Number of lines in your code is quite irrelevant - that's why there is grep and the search function in editors.
Well, that wouldn't be the first time I've broken rules ;0)
But, how bad could the consequences of my misbehaviour be here? Are we talking about crashing R or just messing the output a little?
We're not talking life and death here ;) - yes, frustrated users because of messed up output is the main danger here. Also the behavior changes by GUI and platform, so throw in inconsistency charge as well.
To be precise, there are two issues: a) the output on stdout/stderr is not necessarily visible (e.g. the Windows GUI discards it) and it is separate from the console (e.g. sink() doesn't work on it). More importantly b) it messes up the use of R in streaming, i.e. uses where you are processing input on stdin and streaming output on stdout -- it will break the output. This is most frustrating because the user has no way to control this behavior other than deleting the offending package.
In Writing R Extensions (current on-line version) the worst they say about printf is
[QUOTE]
The most useful function for printing from a C routine compiled into R is Rprintf. This is used in exactly the same way as printf, but is guaranteed to write to R's output (which might be a GUI console rather than a file, and can be re-directed by sink).
[UNQUOTE]
and both printf and fprintf are used in section 8.2.2 in the rtest.c example. Also, the manual does not say explicitly what fprintf should be replaced with.
fprintf() is ok as long as you don't use it with stdout/stderr. You can use it for files, no problem there.
Come to think of it... my package performs MCMC and uses fprintf to write samples to an output file. I have noticed that once in each nth blue-moon (for large n) a single line of output has been dropped or scrambled. More frequently, the updates of the output file seem to lag behind the progress of the algorithm's principal loop - for example, file size becomes non-zero much later than I expect.
Typically, I/O is buffered, so the file is not necessarily updated after you use fprintf(). By default, it will get updated only after the output buffer has been filled. You can use fflush() to flush the output buffer to disk immediately (alternatively you can mark the stream as unbuffered).
I never understood this behaviour or saw how to rectify it. Perhaps replacing fprintf with something else could "guarantee" the end of this undesirable behaviour? Great!
Is there a "safe" way to re-write the following?
fprintf(fMCMCout, "%d %e %e ", iteration, posteriorLoglik, parameter);
if (numberRandomEffects > 1) {
for (k=0; k < numberRandomEffects; k++) {
fprintf(fMCMCout, "%e ", randomEffects[k]);
}
fprintf(fMCMCout,"\n");
This is really a question of 2 parts
1) what is the best replacement of fprintf in the above?
If MCMCout is a file, the above is fine.
and
2) Writing R Extensions says "It is wise to write complete lines (including the "\n") before returning to R.", so is it legal to defer \n as in the example above?
many thanks
David
--
David Pleydell,
INRA,
UMR-1351 CMAEE,
Domaine Duclos,
Prise D'eau,
97122 Petit Bourg,
Guadeloupe
dpleydell at antilles.inra.fr
pleydell at cirad.fr
Tel +33 5 90 25 54 42
Fax +33 5 90 94 03 96