[Bioc-devel] using covr with the parallel package

2015-08-17 Thread Leonard Goldstein
Hi Jim, I noticed that when covr calculates test coverage, functions called inside mclapply or mcmapply with argument mc.preschedule = FALSE are considered untested (even if unit tests exist) When running checks I only use one core. So an easy fix would be to set mc.preschedule to TRUE if

Re: [Bioc-devel] using covr with the parallel package

2015-08-17 Thread Charles Determan
This may be more appropriate to ask the covr package maintainer on his github page (https://github.com/jimhester/covr/issues). Charles On Mon, Aug 17, 2015 at 1:13 PM, Leonard Goldstein goldstein.leon...@gene.com wrote: Hi Jim, I noticed that when covr calculates test coverage, functions

Re: [Bioc-devel] help with imports for new package and other questions

2015-08-17 Thread Lo
Thanks a lot Hervé. Your suggestions are perfect. I fully imported these classes because I realized that it would be less chances of errors, as you say here. I used that, and it is true that I am using these functions for dplyr. The reason I tried to do with dplyr is was to summarize

Re: [Bioc-devel] help with imports for new package and other questions

2015-08-17 Thread Hervé Pagès
Hi Lorena, In your particular case it seems to me that you're using dplyr internally for convenient data frame transformations (nothing that couldn't be done with plain R BTW), and that you're only using a few dplyr symbols for this. The codetoolsBioC package could be useful to help you identify

Re: [Bioc-devel] using covr with the parallel package

2015-08-17 Thread Jim Hester
Leonard, Setting `mc.preschedule = TRUE` and `ncores 2` results in `mclapply` (which `mcmlapply` calls) delegating to a simple `lapply` (see https://github.com/wch/r-source/blob/7578138223130d3c6197b95c3cbbe1e78a5cf230/src/library/parallel/R/unix/mclapply.R#L117). Since this `lapply` runs in the

Re: [Bioc-devel] using covr with the parallel package

2015-08-17 Thread Leonard Goldstein
Hi Jim, You are right -- the problem is not related to mc.preschedule but simply arises when there are child processes. Thanks for pointing this out. I will make some changes to my package to make sure all *apply calls are run in the current process in situations where there is no