In preparing to submit an update of my package to CRAN, I found that R-devel has a new test regarding "connects left open" that my packages fail. The new test appears to have been committed by Uwe Ligges in revisions 74959 and 74964 on 2018-07-14 and 2018-07-15, respectively. The commit message says, "check after each example whether open connections exist, indicating e.g. file connections were left open or parallel clusters still running."
I am hoping for advice on how to pass "R CMD check --as-cran". Or, perhaps my situation will prompt a change to the test or, at least, having it result in a warning instead of an error. Below I describe the situation. My rscala package allows developers to write R packages based on Scala (much like rJava and Rcpp for Java and C++, respectively). Scala runs as a separate process and interprocess communication is implemented using socket connections. Suppose a package using rscala has functions that call Scala code. (Such packages are 'bamboo', 'sdols', and 'shallot' on CRAN.) The first time a user executes an R function calling down into Scala, a socket connect between Scala and R is established. For the sake of low latency, after the call to the function ends, the connection stays open until the package is unloaded or the R session ends. But, this approach runs afoul of the new test mentioned above that appears to be designed to catch connections that are *accidentally* left open. I definitely do not want to users of my packages 'bamboo', 'sdols', and 'shallot' to have to think about managing connection between Scala and R. That's an implementation detail and uing the package should be transparent for the user (who doesn't care about the implementation details). On my end, I see two solutions: 1. I could try to reengineer my approach --- establishing a new connection for every single call into Scala --- although I am loath to do anything to increase the latency, or 2. I could wrap all the examples in \donttest so that CRAN checks are passed. Or, again, perhaps my situation will prompt a reevaluation of the test. Perhaps it could result in a warning (instead of an error) and the CRAN maintainers would accept packages with such a warning. Any advise? Thanks a lot! -- David ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel