Closed jayhesselberth closed 1 year ago
I also increment n_iter
in this PR; it didn't look like it was being used (and so the interrupt check was useless).
This is does something really strange when using BPPARAM
; the spawned processes don't really consume CPU, and may spend all their time updating the progress bar?
BiocParallel doesn't pass messages from the workers during execution, only at the end, or in log files, so that might be causing the issue?
Once the c code has been more finalized I'll test out and incorporate cli
if possible, as this would be a very nice feature. In the meantime you can report progress using biocparallel, which will update the progress bar at each iteration, which for get_pileup()
will be at each chromosome.
e.g. (p
library(BiocParallel)
bpp <- MulticoreParam(workers = 3, progress = TRUE)
bplapply(seq(1, 10, by = 2), Sys.sleep, BPPARAM = bpp)
Closing for now, the built-in BiocParallel progress bars seems good enough for most use cases:
bpp <- MulticoreParam(
workers = 24,
progressbar = TRUE
)
pileup_sites(..., BPPARAM = bpp)
closes #49
Rough implementation of a progress bar for run_cpileup.
Ideally the progress would be based on the number of sites to be evaluated instead of
NA_REAL
andn_iter
, but I'm not sure where that information is stored.Currently it counts up; if based on the number of sites I think this would convert to a percentage based countdown:
Based on https://cli.r-lib.org/articles/progress-advanced.html#the-c-api