My advise:
Apparently you want to have communication via sockets to scala.
So there should be a function that creates the connction and one tha
closes the connection.
Comparable to starting some parallel cluster and stopping it again.
In the meantime, you can allow for all sorts of communication.
So that's fine.
Then in your examples, simply design them to be standalone, i.e. in
*your* examples always start the connection and stop it again at the end
of one examples block, i.e. the exampels defined in one Rd file.
Best,
Uwe Ligges
On 20.08.2018 02:11, Duncan Murdoch wrote:
On 19/08/2018 12:34 PM, Gábor Csárdi wrote:
Sorry, missed that these were examples, so, yeah, that's harder. G.
How about a function that checks if the connection is open before doing
anything, and then at the end you close it if it wasn't already open?
This will make all examples run slower on CRAN, but won't affect most
users who are doing their own stuff as well as running examples.
Or, how about the startup code for the package opens the connection?
Or perhaps CRAN will respond to this thread with another suggestion.
Duncan Murdoch
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
______________________________________________
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
