futureverse / futureverse/progressr

Limit the number of progression conditions signaled

Open
#81 2 comments 4 reactions 0 assignees View on GitHub
enhancement feature request feature/nested-progress
Dominant language
R
Stars
299
Forks
11
PR merge metrics
No merged PRs in 30d

Description

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.
```r
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.:
```r
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
```r
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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.