Sorry, missed that these were examples, so, yeah, that's harder. G. On Sun, Aug 19, 2018 at 6:32 PM Gábor Csárdi <csardi.ga...@gmail.com> wrote: > > You could just create a function to close the connection and then > people could call it at the end of their test suites. > > Gabor > On Sun, Aug 19, 2018 at 6:22 PM David B. Dahl <d...@stat.byu.edu> wrote: > > > > 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
______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
