aboutsummaryrefslogtreecommitdiff
path: root/src/libmain/progress-bar.hh
AgeCommit message (Collapse)Author
2024-07-02libmain: better fix for #424, #425eldritch horrors
not printing activities at all when no progress information is available hides *all* progress information from e.g. flake show. this is not ideal and needs to be fixed, but the fix *still* has problems with flake show: in multiline mode we will overwrite all useful flake show output as soon as the progress bar is redrawn. flake show output is also mangled in any number of other situations (like -v being set), so we should probably be not too worried about it and fix progress reporting properly another day Change-Id: I6d39d670e261bbae00560b6a8e15dec8e16b35c4
2024-07-01tree-wide: unify progress bar inactive and paused statesAlois Wohlschlager
Previously, the progress bar had two subtly different states in which the bar would not actually render, both with their own shortcomings: inactive (which was irreversible) and paused (reversible, but swallowing logs). Furthermore, there was no way of resetting the statistics, so a very bad solution was implemented (243c0f18dae2a08ea0e46f7ff33277c63f7506d7) that would create a new logger for each line of the repl, leaking the previous one and discarding the value of printBuildLogs. Finally, if stderr was not attached to a TTY, the update thread was started even though the logger was not active, violating the invariant required by the destructor (which is not observed because the logger is leaked). In this commit, the two aforementioned states are unified into a single one, which can be exited again, correctly upholds the invariant that the update thread is only running while the progress bar is active, and does not swallow logs. The latter change in behavior is not expected to be a problems in the rare cases where the paused state was used before, since other loggers (like the simple one) don't exhibit it anyway. The startProgressBar/stopProgressBar API is removed due to being a footgun, and a new method for properly resetting the progress is added. Co-Authored-By: Qyriad <qyriad@qyriad.me> Change-Id: I2b7c3eb17d439cd0c16f7b896cfb61239ac7ff3a
2024-06-24libmain/progress-bar: move implementation out of the headerAlois Wohlschlager
Change-Id: Ib4b42ebea290ee575294df6b2f17a38a5d850b80
2024-06-22libmain: add progress bar with multiple status linesFinn Behrens
Add the log-formats `multiline` and `multiline-with-logs` which offer multiple current active building status lines. Change-Id: Idd8afe62f8591b5d8b70e258c5cefa09be4cab03
2024-06-20add a basic libmain test for the progress bar renderingQyriad
Hooray for leaky abstraction allowing us to test this particular part of the render pipeline. Change-Id: Ie0f251ff874f63324e6a9c6388b84ec6507eeae2
2024-06-20use a type alias for ProgressBar's chosen time point typeQyriad
Change-Id: I621a455b1daba806fc498958aee7931fbfc55445
2024-06-20extract ProgressBar declaration into its header fileQyriad
Change-Id: Ica9e2ec41d99eaa196a0d535501edf45c589b2b6
2023-03-31Ensure all headers have `#pragma once` and are in API docsJohn Ericson
`///@file` makes them show up in the internal API dos. A tiny few were missing `#pragma once`.
2022-08-24Fix progress bar flicker with -LEelco Dolstra
This was caused by -L calling setLogFormat() again, which caused the creation of a new progress bar without destroying the old one. So we had two progress bars clobbering each other. We should change 'logger' to be a smart pointer, but I'll do that in a future PR. Fixes #6931.
2020-06-11Style fixesEelco Dolstra
2020-06-08Move progress-bar.cc to libmainregnat
Needed so that we can include it as a logger in loggers.cc without adding a dependency on nix This also requires moving names.hh to libutil to prevent a circular dependency between libmain and libexpr