[Bioc-devel] using covr with the parallel package
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 current process coverage works fine. `mc.preschedule = FALSE` calls `mcparallel` in all cases, which spawns child processes, and coverage is not tracked in child processes. I don't have any plans to support tracking coverage in child processes at the moment (although I suppose it is possible in the future). So the answer seems to be if you want test coverage to work with parallel code you need to run it with `ncores = 1` and `mc.preschedule = TRUE`. I will add something to that effect in the covr README. Thank you for reporting the issue! Jim (posting includes off-list email exchange when I neglected to include bioc-devel in the response) On Mon, Aug 17, 2015 at 2:34 PM, Leonard Goldstein <
goldstein.leonard at gene.com> wrote:
Hi Jim, Thanks for the quick reply! For example, predictTxFeaturesPerSample in https://codecov.io/github/Bioconductor-mirror/SGSeq/R/features-prediction.R is called by predictTxFeatures in main.R (inside mcmapply with mc.preschedule = FALSE) but it is considered untested. Thanks for looking into this. Leonard On Mon, Aug 17, 2015 at 11:24 AM, Jim Hester <jhester at fredhutch.org> wrote:
Leonard, Can you link to an example where this behavior is occurring? I can see evidence where the coverage is working as expected when using mclapply,
e.g.
(
but not the reverse. Jim On Mon, Aug 17, 2015 at 2:13 PM, Leonard Goldstein <goldstein.leonard at gene.com> wrote:
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 mc.cores = 1. But I was wondering if you are aware of this behavior and whether there is a way to avoid it? Many thanks for your help. Leonard
_______________________________________________ Bioc-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel