You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
There are already mechanisms for control how frequent handlers report on progress updates (
interval
andtimes
), 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.
However, when using map-reduce functions (e.g.
lapply(X, function(x) { ... })
, we don't have access to an index, only the valuex
.One solution could be to introduce an
every
argument toprogressor()
and then have it skip internally, e.g.:and
One can also imagine a (per minute)
frequency
and (total)times
argument.The text was updated successfully, but these errors were encountered: