-
-
Notifications
You must be signed in to change notification settings - Fork 872
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
Rethink the progress bar #1880
Comments
- creates a globally accessible, bespoke progress bar `knit_progress()` - create `set_knit_progress()` to update value and/or printed text - also use `cat()` (instead of `message()` for printing information about processed files, to prevent mixing of streams from `stdout` and `stderr`
Perhaps as part of this, it might make sense to separate out two concerns currently addressed by the
More discussion in #2035. |
Just a note as I am seing this: VSCODE extension integrates the progress bar with the UI. Changing the progress bar may have some impact there I believe. |
What is the current plan ?We plan to tackle this in two steps for now :
GoalsFrom notes with @hadley , there would be 2 main goals for the progress bar in knitr:
There is also the goals shared by @maxheld83 above, related to #2077 to "be able to handle the progress information of knitr documents more flexibly." This goes with another feedback I got about a use case that the progress bar outputs should be possible to customize by user inputs from the Rmd file, for the context of scheduled rendering on RStudio Connect. Like an interactive log report of some sort. I understand the usage, not sure if it should be a progress bar features, or another features that would be working well with the progress bar formatting. Ex: outputting more verbose context that just the chunk name,Like grouping code chunks and steps together or sharing some information about the processing in the knitting log. processing file: monthly-report.Rmd
--[ Pre-Process work ] --
text |.............. | 20%
chunk: unnamed-chunk-2 |................... | 27%
text |...................... | 33%
chunk: unnamed-chunk-3 |...................... | 40%
text |...................... | 47%
chunk: unnamed-chunk-4 |...................... | 53%
text |...................... | 60%
--[ Got 3 updated results - generating new report ] --
chunk: unnamed-chunk-5 |...................... | 67%
inline code |...................... | 73%
chunk: unnamed-chunk-6 |........................ | 80%
text |............................. | 87%
--[ Updating database with new results ] --
chunk: unnamed-chunk-7 |................................. | 93%
chunk: unnamed-chunk-8 |......................................| 100%
--[ 3 new records ] -- Formatting.
@yihui @rich-iannone please do share your thoughts. @hadley we welcome any new feedback on this. |
@cderv great summary! I think it would be useful to start collecting these notes in a google doc. |
Displaying more info should not be the defaultThis issue was born with the intent to produce a more compact progress bar. So, maybe, displaying more info with the progress bar should not be the default (or the focus). Yet, we want to give the freedom to the user to produce such infos, if they want to. I think the best way to do that is to add a chunk option (like We could also use a list in this chunk option, to allow the user to decide which "logging function" they want to use. Like: start of chunk ....
# Will use `cli::cli_alert_warning()` to print the message:
#| progress_message = list(message = "A message", log_fun = "cli::cli_alert_warning()")
end of chunk .... |
Noting a recent customer request re:
The vertical lines are like below:
As part of the enhancement, it might be interesting to think about how the product teams can build off this work. Thinking of what this means for RStudio Background Jobs for reporting progress and/or on Connect what happens with it's logging. |
@jthomasmock I wonder if this request does not add to the idea of multiple type of report due to multiple goals. In broader term we need user friendly progress report, with helpful information for debugging and we may need another mechanism for more machine-friendly logging about the knitting process to help diagnose and analyze in usual company grade logging framework. Just thinking out loud for now. |
Agreed - I just wanted to note that there are potential downstream side effects or benefits with modification of the current |
One advantage of using cli is that it already handles some of differences between interactive (e.g. running locally in RStudio) and batch environments (e.g. running on RStudio connect): https://cli.r-lib.org/articles/progress-advanced.html#non-interactive-r-sessions. This would probably require a little additional work to verify that if knitr fails in a non-interactive environment you still find out exactly where the problem occurred. Also need to think about what happens when (e.g.) you have I think we could handle the need for users to add arbitrary content to the output through a new helper called |
The progress bar has been condensed in the dev version of knitr. The major changes are:
remotes::install_github('yihui/knitr') For people who want to use their own progress bars, I'm hoping to allow for custom progress bars instead of supporting every single progress package: #2196 Feedback welcome!
@cderv Thanks for the info! I've filed an issue there for notification and discussion.
@jthomasmock Can they
@hadley I've made changes in evaluate so that |
This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary. |
I think it's time to rethink the knitr progress bar. Since the progress bar was created, we have collectively learnt a lot about how to create minimal, informative progress bars, that still show you what's happening.
For example, I think this progress output:
could be reduced to something like this:
where in most context the each line would overwrite the previous line, so that you see an interactive progress bar gradually filling up over time. I've dropped the display of options because I don't find that useful; reincorporating it into a single line display would be challenging, but definitely possible.
The text was updated successfully, but these errors were encountered: