permit restart w/ handler_progress
Closed this issue · 9 comments
Overview
I have a progress bar for a process that iterates multiple times with different input lengths inside a loop.
Issue
Everything is just as expected with other progress bars (i.e., handler_txtprogressbar, or handler_rstudio): every cycle, the bar restart with the new length. The issue is that, from the second run, the bar is not displayed using handler_progress.
Reprex
library(progressr)
library(purrr)
fun_safe <- safely(function(x, p) {
on.exit(p())
Sys.sleep(1)
if (runif(1) > 0.5) stop()
x
})
run <- function(xs) {
set.seed(1)
res <- vector("list", length(xs))
todo <- TRUE
while (any(todo)) {
xs_todo <- xs[todo]
res[todo] <- map(xs_todo, fun_safe, p = progressor(along = xs_todo))
todo <- map_lgl(res, ~!is.null(.x[["error"]]))
}
invisible(res)
}
x <- seq_len(10)
in_rstudio <- requireNamespace("rstudioapi", quietly = TRUE) &
rstudioapi::isAvailable()
if (in_rstudio) with_progress(run(x), handler_rstudio()) # OK
with_progress(run(x), handler_txtprogressbar(clear = FALSE)) # OK
with_progress(run(x), handler_progress(clear = FALSE)) # First pb onlyCreated on 2021-12-16 by the reprex package (v2.0.1)
Session info
sessioninfo::session_info()
#> - Session info ---------------------------------------------------------------
#> setting value
#> version R version 4.1.2 (2021-11-01)
#> os Windows 10 x64
#> system x86_64, mingw32
#> ui RTerm
#> language (EN)
#> collate English_United States.1252
#> ctype English_United States.1252
#> tz Europe/Berlin
#> date 2021-12-16
#>
#> - Packages -------------------------------------------------------------------
#> ! package * version date lib
#> P backports 1.2.1 2020-12-09 [?]
#> P cli 3.0.1 2021-07-17 [?]
#> P crayon 1.4.1 2021-02-08 [?]
#> digest 0.6.27 2020-10-24 [1]
#> P ellipsis 0.3.2 2021-04-29 [?]
#> P evaluate 0.14 2019-05-28 [?]
#> P fansi 0.5.0 2021-05-25 [?]
#> P fastmap 1.1.0 2021-01-25 [?]
#> P fs 1.5.0 2020-07-31 [?]
#> P glue 1.4.2 2020-08-27 [?]
#> P highr 0.9 2021-04-16 [?]
#> P hms 1.1.0 2021-05-17 [?]
#> P htmltools 0.5.2 2021-08-25 [?]
#> P knitr 1.33 2021-04-24 [?]
#> P lifecycle 1.0.0 2021-02-15 [?]
#> P magrittr 2.0.1 2020-11-17 [?]
#> P pillar 1.6.2 2021-07-29 [?]
#> P pkgconfig 2.0.3 2019-09-22 [?]
#> P prettyunits 1.1.1 2020-01-24 [?]
#> P progress 1.2.2 2019-05-16 [?]
#> progressr * 0.9.0-9001 2021-12-15 [1]
#> P purrr * 0.3.4 2020-04-17 [?]
#> P R6 2.5.0 2020-10-28 [?]
#> P reprex 2.0.1 2021-08-05 [?]
#> P rlang 0.4.11 2021-04-30 [?]
#> P rmarkdown 2.9 2021-06-15 [?]
#> P rstudioapi 0.13 2020-11-12 [?]
#> P sessioninfo 1.1.1 2018-11-05 [?]
#> P stringi 1.7.3 2021-07-16 [?]
#> P stringr 1.4.0 2019-02-10 [?]
#> P styler 1.5.1 2021-07-13 [?]
#> P tibble 3.1.3 2021-07-23 [?]
#> P utf8 1.2.2 2021-07-24 [?]
#> P vctrs 0.3.8 2021-04-29 [?]
#> P withr 2.4.2 2021-04-18 [?]
#> P xfun 0.24 2021-06-15 [?]
#> P yaml 2.2.1 2020-02-01 [?]
#> source
#> CRAN (R 4.1.0)
#> RSPM (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> RSPM (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> RSPM (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> Github (HenrikBengtsson/progressr@13fa95f)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> RSPM (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> RSPM (R 4.1.0)
#> CRAN (R 4.1.0)
#> RSPM (R 4.1.0)
#> RSPM (R 4.1.0)
#> RSPM (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#> CRAN (R 4.1.0)
#>
#> [1] C:/Users/corra/Documents/ubesp/mpg2wav/renv/library/R-4.1/x86_64-w64-mingw32
#> [2] C:/Users/corra/AppData/Local/Temp/RtmpIbIeJR/renv-system-library
#> [3] C:/Program Files/R/R-4.1.2/library
#>
#> P -- Loaded and on-disk path mismatch.Before anything else, have you made sure you get the same result in each of those case, i.e. with_progress(res <- run(x), ...)?
It could be that progress loads a package on the fly that forwards the RNG state such that you don't get the same random numbers.
Actually, maybe that's not sufficient for what I'm after. To see you get the same random numbers, you might have to do something like:
fun_safe <- safely(function(x, p) {
on.exit(p())
Sys.sleep(1)
random <- runif(1)
print(random)
if (random > 0.5) stop()
x
})and compare the output.
I have possibly expressed myself wrongly, sorry. The issue is not the result but the showing of the progress bar: if the loop run, e.g., four times, each time it runs for a different length, so with a new progress bar of different length too. So, in this example I would see four different progress bars. The issue is that in the handler_txtprogressbar, and handler_rstudio cases the progress bars are shown every time (i.e. I "see" four progress bars!), while in the handler_progress case only the first progress bar is shown.
I have added a print(todo) statement at line 20 to make it more evident in the console's output.
Thanks for confirming it's not RNG; my hypothesis was that you got to the stop() at a different place when using progress. Anyway, I have had a chance to test myself and can reproduce it in R --vanilla using just:
library(progressr)
options(width=50)
run <- function() {
for (ii in 1:2) {
message(sprintf("Progress bar #%d", ii))
p <- progressor(10)
for (jj in 1:10) {
Sys.sleep(0.1)
p()
}
}
}
message("txtprogressbar [OK]")
handlers(handler_txtprogressbar(clear = FALSE))
with_progress(run())
message("progress [FAIL]")
handlers(handler_progress(clear = FALSE))
with_progress(run())This gives
txtprogressbar [OK]
Progress bar #1
|========================================| 100%
Progress bar #2
|========================================| 100%
progress [FAIL]
Progress bar #1
| [======================================] 100%
Progress bar #2
> I'll try to figure out what happens.
I've fixed this in progressr 0.9.0-9002;
remotes::install_github("HenrikBengtsson/progressr", ref="develop")Could you please verify it works for you as expected?
I have just run my code, and it worked as expected. Great! Thank you so much!!
Thanks for confirming. I'll look into submitting to CRAN asap, so we can get this in before they close for holidays (Dec 21-Jan 3).
... forgot to say, thanks for report this problem. It indirectly also led two a couple of bugs being fixed too.