-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
[Data] Do not show AllToAll progress bar if the disable flag is set #45136
Conversation
Signed-off-by: Jari Rosti <jari@iprally.com>
b411547
to
1c94ebe
Compare
enabled = is_all_to_all or ( | ||
DataContext.get_current().enable_progress_bars and verbose_progress | ||
progress_bar_enabled = DataContext.get_current().enable_progress_bars and ( | ||
is_all_to_all or verbose_progress | ||
) | ||
self.progress_bar = ProgressBar( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ProgressBar is bit confusing name because it has responsibilities in the monitoring lifecycle: e.g. if sub_progress_bars are not initialized the program does not work.
I'd change name to ProgressMonitor - which can then have progress-bar property as it currently has - I think it makes the intention bit more clear: it is not just a visual detail, but it tells the completion of the underlying operation which is then coupled to the control flow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, I agree with you in general, I think it's a nit for now, so we can live with ProgressBar
without updating too many places.
# Initialize must be called for sub progress bars, even the | ||
# bars are not enabled via the DataContext. | ||
num_progress_bars += self.op.initialize_sub_progress_bars(index + 1) | ||
return num_progress_bars if progress_bar_enabled else 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Original code wants to return number of enabled progress bars, although I think that number of created "ProgressBar" instances would be more meaningful.
I preserved original behaviour since I did not follow the calls if the visibility of the progress bar is really what client wants to know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, let's keep existing behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @jrosti for the fix!
Why are these changes needed?
AllToAll main progress bar is shown even if progress bars are disabled.
Related issue number
Closes #44770
Checks
git commit -s
) in this PR.scripts/format.sh
to lint the changes in this PR.method in Tune, I've added it in
doc/source/tune/api/
under thecorresponding
.rst
file.