0

Just like this question, except this package author is EVEN MORE vexing and is using printf and snprintf to display a mix of messages, warnings, and errors in the C/C++ code:

library('inline')
silly_developer_cxx_function <- cxxfunction(
  signature(x = "integer"),
  'printf("%s", "Seriously! Thanks for using my function!!");
  return ScalarReal(INTEGER(x)[0]);'
  )
silly_developer_function <- function(i){
  print("Thanks for using my function!!")
  return(silly_developer_cxx_function(as.integer(i)))
}

I can suppress the R-level print statement with capture.output, but the sprintf statement seems un-killable:

> capture.output(x <- silly_developer_function(1L), file='/dev/null')
Seriously! Thanks for using my function!!
Community
  • 1
  • 1
Zach
  • 29,791
  • 35
  • 142
  • 201
  • That's a serious implementation flaw, have you contacted the author of the package? Maybe she thinks it's funny, but to us all it's just annoying... – Stefano Sanfilippo Oct 30 '14 at 18:07
  • @Stefano Sanfilippo I am contacting the author of the package in question, but am trying to work around the bug in the meantime. – Zach Oct 30 '14 at 19:42

1 Answers1

0

Zach, do you have more context? Are you talking about the CRAN Package RPostgreSQL which I once mentored for Google Summer of Code and later maintained (and which is now in the very capabable hands of Tomoaki Nishiyama) as CRAN does not allow actual printf or std::cout per Section 6.5 of Writing R Extensions.

You can generally reach maintainers of the DB packages on r-sig-db which Tomoaki reads, and we have (had?) a dedidated list for rpostgresql as well. Tomoaki is very responsive, and I suggest using the proper venue. Venting is not going help. I only caught it because you (mistakenly?) stuck the Rcpp tag on this. Or did you by chance mean the (very different) rpg by Tim Keitt, yet mistakenly referred to RPostgreSQL instead?

Edit: Some history. We never had proper backend to PostgreSQL. So suggested this as topic for Google Summer of Code, and a student took it and wrote a first, somewhat hackish version. Chiefly by looking what RMySQL did and adapting to the PostgreSQL API. Because behaviour was defined by the R / S definition of the Database Interface -- DBI.

So what you appear to complain about are things like (first grep find in the RPostgreSQL sources)

    (void) sprintf(buf, msg, (int) mgr->length);
    RS_DBI_errorMessage(buf, RS_DBI_ERROR);

and I would hence be fairly certain that RMySQL does the same. Given that this is a programmatic use if the prepared string (or, rather, char vector), I would think that you can in fact suppress this.

If I were you, I'd take a look at the source and/or ask on r-sig-db.

Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
  • Hi Dirk, Sorry about that. I fixed the tags. I do indeed mean `RPostgreSQL` on CRAN. It uses `sprintf` and `snprintf`, which seem to be a variant of `printf` (although it's hard for me to tell). Their output seems to bypass R. E.g. `capture.output(suppressMessages(suppressWarnings(x <- dbGetQuery(con, 'bogus query;'))), file='/dev/null'); print(x)`, where con is a connection to a PostgreSQL database. – Zach Oct 30 '14 at 19:36
  • If it helps, my session info is: `R version 3.1.1 (2014-07-10) Platform: x86_64-apple-darwin13.1.0 (64-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] RPostgreSQL_0.4 DBI_0.3.1 ` – Zach Oct 30 '14 at 19:40
  • I *think* you misunderstand. Look at manual page, or C library site. Both `sprintf` and `snprintf` print to a _string_, hence the leading s. What matters with that string is what matters. R is oicky about NOT letting us use direct `(f)printf` precisely because one cannot filter / suppress from R because these would be outside of R's I/O. Hence Section 6.5 of WRE as I mentioned. – Dirk Eddelbuettel Oct 30 '14 at 19:42
  • Hmmm, so the un-supressable print statement I'm seeing must be coming from the postgres driver itself. I had (wrongly) assumed it must be emanating from RPostgreSQL – Zach Oct 30 '14 at 20:03
  • Indeed. I would be *very surprised* if RPostgreSQL had managed to sneak unsuppressable messages past the CRAN maintainers. This is a very clear check, and I *very certain* that the package is clean. The external library, as you point, is an entire matter. So there: just rewrite that library ;-) – Dirk Eddelbuettel Oct 30 '14 at 20:18
  • How would I pass the `--quiet` flag to Postgres through `dbGetQuery()`? – Zach Oct 30 '14 at 20:53
  • 1
    Not sure, that may be a request for an API extension. You can reach Tomoaki at the list ;-) – Dirk Eddelbuettel Oct 30 '14 at 20:58
  • With libpq, you might try setting the error verbosity. 'rpg' exposes that. I can't recall if you can do this via setting options using a simple query. – THK Jan 13 '15 at 16:47