Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit the number of progression conditions signaled #81

Open
HenrikBengtsson opened this issue May 7, 2020 · 1 comment
Open

Limit the number of progression conditions signaled #81

HenrikBengtsson opened this issue May 7, 2020 · 1 comment

Comments

@HenrikBengtsson
Copy link
Collaborator

HenrikBengtsson commented May 7, 2020

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
Copy link
Collaborator Author

HenrikBengtsson commented May 9, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant