plyr forces .progress="none" when .parallel=TRUE (although it works with progressr)

[HenrikBengtsson]

Unfortunately, the plyr package ignores the .progress argument whenever .parallel = TRUE. It does this by forcing .progress = "none", e.g. in plyr::llply() there is:

  if (.parallel && .progress != "none") {
    message("Progress disabled when using parallel plyr")
    .progress <- "none"
  }

This is probably based on the assumption that progress updates do not work in parallel processing. However, that does indeed work when using future + progressr. Here's an example of this when we hack plyr to still use .progress = "progressr" internally:

# Force 'progressr' progress bars in plyr
> trace(plyr:::create_progress_bar, tracer = quote(name <- "progressr"))
Tracing function "create_progress_bar" in package "plyr (not-exported)"
[1] "create_progress_bar"

library(plyr)
library(progressr)
doFuture::registerDoFuture()
future::plan("multisession", workers = 2L)
with_progress({
  y <- llply(1:10, function(x) { Sys.sleep(1); identity(x) }, 
                .parallel = TRUE, .progress = "progressr")
})

which outputs:

|====================                              |  40%

and when done:

Tracing create_progress_bar(.progress) on entry 
Progress disabled when using parallel plyr

[HenrikBengtsson]

Created PR https://github.com/hadley/plyr/pull/301 to fix this in plyr.

[HenrikBengtsson]

Good news. This will be supported in the next release of plyr. Due to not having tested this in a while, I had to make a small patch in progressr, but as soon as updated versions of both these packages have been released, this will work.

UPDATE:

• [x] plyr 1.8.7 on CRAN (2022-03-24)
• [ ] progressr (>= 0.10.1) on CRAN