-
-
Notifications
You must be signed in to change notification settings - Fork 756
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
Verbosity fixes #288
Merged
Merged
Verbosity fixes #288
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
an alternative to this would be to use more than a letter in the output, for example: orig: 16.82 GB comp: 9.44 GB dedup: 25.86 MB home/
without this, there would be a solid 20 seconds here without any sort of output on the console, regardless of the verbosity level. this makes nice incremental messages telling the user that borg is not stalled (or waiting for a lock, for that matter) the "processing files" message is a little clunky, as we somewhat abuse the cache to figure out if we are just starting... but it helps if there are problems reading the actual files: it tells us the initialization is basically complete and we're going ahead with the reading of all the files.
as it was, surrogates were not always removed, for example we may also want to output at different levels or control if we want to print unchanged files and so on
a single -v flag shouldn't flood the console with all the files in the path specified, it makes -v basically useless this way, -v can also be used with --progress to have nicer output: initializing cache reading files cache processing files 5.20 GB O 2.66 GB C 25.13 MB D 27576 N baz/...
the --stats output would be slightly garbled by --progress, because of the \r that is output at the last line... example: initializing cache reading files cache processing files ------------------------------------------------------------------------------ s/twotone Archive name: 2015-10-15-test
we use the new get_terminal_size() function, with a fallback for Python 3.2. we default to 80 columns. then we generate the stats bit and fill the rest with the path, as previously, but with a possibly larger field. note that this works with resizes in my test (uxterm)
we stop enforcing a minimum width for fields, it changes only on logarithmic boundaries, so not a big problem. string conversion is implicit this gives us a little more width for the path
i saw the errors in my ways: __format__ is only to customize the "format mini-language", what comes after ":" in a new string format. unfortunately, we cannot easily refer to individual fields in there, short of re-implementing a new formatting language, which seems silly. instead, we use properties to extract human-readable versions of the statistics. more intuitive and certainly a more common pattern than the exotic __format__(). also add unit tests to prove this all works
this function was over-coupling the cache system and the statistics module. they are now almost decoupled insofar as the cache system has its own rendering system now that is called separately. furthermore, we have a much more flexible formatting system that is used coherently between --progress and --stats the degenerate case here is if we want to change the label in the statistics summary: in this case we need to override the default __str__() representation to insert our own label.
it was broken by recent commits. also remove the __format__() anti-pattern from cache as well.
the columns handling fixed that isssue more elegantly This reverts commit 7f77778. Conflicts: borg/helpers.py
It is actually necessary, for now. This reverts commit 8fdd1ed. Conflicts: borg/helpers.py
this makes --progress a toggle: if there's a terminal, it turns it off, if there isn't, it forces it on.
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this covers a lot of ground, and is a followup on #233.
it concentrates on fixes to the --progress bar, most notably it now guesses the terminal columns to fit the display to the terminal width. progress is also enabled by default now if there is a terminal to send it to.
finally, there are also cosmetic fixes to the --stats output that were broken in the logging refactoring. some weird
__format__()
functions were used then, and we simply stop using those in a spirit of clarity.