-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Custom bar symbols formatting + bar_format callback and dict return #223
base: master
Are you sure you want to change the base?
Conversation
PS: I forgot to say that I tried to minimize the performance impact of this PR on standard core |
I was just working on this! going to merge into this PR... thanks, Stephen. On 4 August 2016 at 22:58, Stephen L. notifications@github.com wrote:
|
Codecov Report
@@ Coverage Diff @@
## master #223 +/- ##
=========================================
Coverage ? 78.48%
=========================================
Files ? 8
Lines ? 660
Branches ? 135
=========================================
Hits ? 518
Misses ? 141
Partials ? 1 Continue to review full report at Codecov.
|
Ah lol @casperdcl, maybe some kind of telepathy was at work here? XD |
I didn't plan to work on this at all, it just popped into my mind a few days ago, so that's indeed quite a coincidence we were working on the same feature at the same time :) |
Just for reference and for fun: |
@lrq3000 to minimize performance strain, let's make a branch that internally changes the code, or even make a new class. This small feature shouldn't slow everybody down. |
For standard tqdm, it's an increase of 3 opcodes per printing (not per loop), this doesn't impact much the performance. However it can probably be implemented in a separate submodule. It would incur repetition of some code (calculations of the bar length and current frac) and thus violate DRY somewhat and the change of the tags from |
Fixed the custom_symbols tag string extraction, now it's preprocessed once in |
Moved all the code into its own module in Please do NOT squash all the commits, because the original commit can be useful to reimplement back to the core. |
Added two new features:
The downside of the last modification (looping speed not dependent on |
Signed-off-by: Stephen L. <lrq3000@gmail.com>
… for total=None Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
Signed-off-by: Stephen L. <lrq3000@gmail.com>
8cade97
to
a65e347
Compare
The bar_format callback should be separated back into its own PR and merged with milestone >5. |
6ec00f1
to
4b6476a
Compare
@lrq3000 Thanks for this PR (and tqdm in general )!
Is anyone planning to work on this part in the near future ? If not, I could give it a try.. |
Might merge in #227 (which is simple) and put this PR into a submodule as suggested there as it's quite large |
Implements also #181 (add callback support for bar_format) + custom bar symbols formatting as a submodule.
Not the most urgent PR, but we missed some more customization (pretty sure someone will ask someday!). So here it is: the ability to set custom bar symbols, just like our fellow progressbar2:
Respective outputs:
For multiline (work in progress, needs bugfixes):
User can specify both ascii and unicode versions of the bar, if one isn't provided, then it will fallback to the default tqdm bar.
TODO:
__init__
and then loading it at the same time asc_symbol
(eg,c_symbol_reverse = self.bar_format[key].get('ascii_reverse', None)
? Would allow manual user reversing BTW).self.last_print_height
(works with leave=False, need to fix leave=True bug)About multiline symbols:
We should try to implement multiline animated ascii-art bars like nyanbar or fish. This shouldn't be too hard to implement, let me explain:
Basically, we have currently 4 different bar displays:
#
when enough progress, and it gets filled up until it reaches 100% completion.Then for all these cases, you can add
multiline
support. We can then assimilatefish
andnyanbar
to the following cases:So if we can support multiline, we can essentially support what these two libraries do (somewhat, because for example
nyanbar
would only be simulated since the real one generates random colored blocks, our version would have fixed sprites but if you make enough of them, then you can give the illusion it's random).Only issue is how to handle multiple concurrent tqdm bars, but this can be managed I think (we can memorize the number of lines of the last printed symbol and get back to original position, just like we currently do with automated nesting, then when we
move_to()
we would compute the correct position to print usingsum([t.s_height for t in tqdm._instances if t.pos < self.pos])
).The rest of the text here is for the old version of this PR.
For reference, the old way with bar string templating was like this (but it was scraped to give more flexibility, but maybe it will be reintroduced in the future if people like it):
There are four different new tags for
bar_format
:{bar_symbols}
and{bar_symbols_ascii}
set custom progress bar symbols (unicode or ascii respectively){bar_symbols_loop}
and{bar_symbols_loop_ascii}
set animated looping symbols (unicode or ascii respectively)As you can see, I added both unicode and ascii tags, so that the user can provide either one or both. If the user didn't provide custom symbols for the target environment (eg, user provided
{bar_symbols}
but the environment is ascii), then the bar will fallback to the default bar. Why? This is to ensure robustness, so the user has to explicitly provide both a unicode and an ascii bars to work in all envs.Formatting follow a rule similar to egrep: the first character is the separator, then the rest is compiled in a list of symbols. Eg:
{bar_symbols}|1|2|3|#{/bar_symbols}
-->|
is the separator{bar_symbols_loop},|,/,-,\{/bar_symbols_loop}
-->,
is the separatorNote that symbols are not necessarily only one character long, they can be longer (can be interesting for animated loops). /EDIT: tested and it works.