[Bioc-devel] using covr with the parallel package
james.f.hester at gmail.com
Mon Aug 17 22:29:13 CEST 2015
Setting `mc.preschedule = TRUE` and `ncores < 2` results in `mclapply`
(which `mcmlapply` calls) delegating to a simple `lapply` (see
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!
(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
> is called by predictTxFeatures in main.R (inside mcmapply with
> mc.preschedule = FALSE)
> but it is considered untested.
> Thanks for looking into this.
> On Mon, Aug 17, 2015 at 11:24 AM, Jim Hester <jhester at fredhutch.org>
> > 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,
> > (
> > 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
[[alternative HTML version deleted]]
More information about the Bioc-devel