Limit the number of progression conditions signaled

[HenrikBengtsson]

There are already mechanisms for control how frequent handlers report on progress updates (interval and times), but there's no mechanism built-in for controlling how frequently updates are signaled (e.g. Issue #74).

The workaround is for the developer to limit this, e.g.

  p <- progressr::progressor(length(x) / 10)
  sum <- 0
  for (kk in seq_along(x)) {
    Sys.sleep(0.1)
    sum <- sum + x[kk]
    if (kk %% 10 == 0) p(message = sprintf("Added %g", x[kk]))
  }

However, when using map-reduce functions (e.g. lapply(X, function(x) { ... }), we don't have access to an index, only the value x.

One solution could be to introduce an every argument to progressor() and then have it skip internally, e.g.:

  p <- progressr::progressor(along = x, every = 10L)
  sum <- 0
  for (kk in seq_along(x)) {
    Sys.sleep(0.1)
    sum <- sum + x[kk]
    p(message = sprintf("Added %g", x[kk]))
  }

and

  p <- progressr::progressor(along = X, every = 10L)
  y <- lapply(X, FUN = function(x) {
    p(message = sprintf("Added %g", x[kk]))
    Sys.sleep(0.1)
    sqrt(x)
  })

One can also imagine a (per minute) frequency and (total) times argument.

[HenrikBengtsson]

If we limit by time, say, per minute, then we cannot rescale the total number of steps because then different runs could produce different number of step. To solve that, the progressor needs to "buffer-and-agregate" progression before releasing a single progress update. This is related to ideas of nested progress bars updates.

So, although there's a quick solution (every), there might be a better, more general solution that require a solid design.

It could also be that there's room for both models.