Okay, Uwe, I will close the connection between examples. Thanks Henrik, Duncan, Gabor, and Uwe for participating in the discussion.
-- David On Mon, Aug 27, 2018 at 4:47 PM Uwe Ligges <lig...@statistik.tu-dortmund.de> wrote: > > I still do not undertsand why you cannot stop scala and related > connections at the end of each example. You can insert a comment that > this is not needed if you have follow up tasks for scala. > > Best, > Uwe > > On 27.08.2018 07:14, David B. Dahl wrote: > > Henrik, > > > > Thanks for the suggest. Yes, definitely, I think your more nuanced > > test would be a big improvement. The only wrinkle is that the > > connection is established *not* when the package is *loaded* but > > rather when the connection is *first needed* (using delayedAssign when > > the package is loaded). That way, loading the package doesn't block > > the REPL for ~5 seconds while Scala and the JVM first start. > > > > -- David > > > > On Thu, Aug 23, 2018 at 11:19 PM Henrik Bengtsson > > <henrik.bengts...@gmail.com> wrote: > >> > >> Does R CMD check --as-cran test for newly opened connections or any > >> open connections? Could the check for stray connection in > >> examples/vignettes be: > >> > >> 1. Record what connections are open > >> 2. Attach the package > >> 3. Record what connections are open > >> 4. Run the example > >> 5. Assert that no *new* connections in addition to what's recorded in > >> Step 3 are open > >> 6. Unload the package > >> 7. Assert that no *new* connections in addition to what's recorded in > >> Step 1 are open > >> > >> Step 5 asserts that the code in the example does not leave stray > >> connections behind, and Step 7 that the package itself does not leave > >> stray connections behind. > >> > >> /Henrik > >> On Thu, Aug 23, 2018 at 1:25 PM David B. Dahl <d...@stat.byu.edu> wrote: > >>> > >>> Oops, I accidentally did not "reply-all".... Here is my message: > >>> > >>> Thanks Uwe, Duncan, and Gabor for the response, advise, and flexibility. > >>> > >>> Regarding Uwe's suggestion: "... there should be a function that > >>> creates the connction and one that closes the connection," I should > >>> clarify. The rscala package does just that. There is a function > >>> (named "scala") that creates the connection (using delayedAssign) and > >>> another the closes the function (namely an S3 close method). The > >>> examples for the rscala package do this full open/close semantics, > >>> but... > >>> > >>> The problem comes when authors of another package, let's call it the > >>> "FooBar" package, want to implement an algorithm in Scala based on > >>> functionality provided by the rscala package. Let's say they write a > >>> function called "neatAlgorithm" based on Scala. Yes, the FooBar > >>> package author could require that, before the user calls the > >>> "neatAlgorithm" function, they first call a function to set up the > >>> connection (which itself would call the "rscala::scala" function) and > >>> then, after calling the "neatAlgorithm" function, they call a function > >>> to close the connection. > >>> > >>> But that is not very user friendly and exposes the user to > >>> implementation details of the algorithm. The user of the FooBar > >>> package don't really care whether the "neatAlgorithm" is implemented > >>> in pure R, C++, Scala, or whatever, much like the users of the 'lm' > >>> function don't need to know the implementation details or do any setup > >>> before and after calling the function. > >>> > >>> The current approach is that the connection to Scala is transparent to > >>> the end user of a package. Behind the scenes, the package author > >>> establish the connection once it is needed and the rscala package > >>> manages the connection and explicitly closes it when 1. the package is > >>> unloaded or 2. the R session ends. This approach does not leave > >>> dangling connections --- which I believe is the point of the new test > >>> --- yet my package is caught up in the test. > >>> > >>> I hope that this approach is still valid. Perhaps the test could > >>> result in a warning (instead of an error) and CRAN could accept > >>> packages with such a warning. > >>> > >>> If not, a work-around is to have a \dontshow section in the examples > >>> that will close the connection (but leave the Scala process running) > >>> and then automatically reestablish the connection as needed. This > >>> would not be very efficient but, as Duncan mentioned, it mostly only > >>> effects the package examples themselves. Plus, it would not be too > >>> burdensome for package developers. > >>> > >>> Again, thanks for considering my situation. > >>> > >>> Best regards, > >>> > >>> -- David > >>> > >>> On Mon, Aug 20, 2018 at 11:11 PM Uwe Ligges > >>> <lig...@statistik.tu-dortmund.de> wrote: > >>>> > >>>> 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 [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel