Open blwh opened 10 months ago
for tests, add a few tests with the new feature but don't change old ones. That way we can check that the change is not breaking. All old tests should still pass (including the deprecated ones, which is not the case at the moment)
I've added tests. However, the performance test in core.jl
sometimes fails. It seems to be due to the required truncation on line 209
full_width = trunc(Int, (displaysize(output)[2]*width_fraction))
It's not consistent, as it sometimes (mostly) fails on my machine. I ran the performance test prog_perf(n)
on line 28 in core.jl
and got on average that the code with the truncation is about 7% slower (0.144s vs 0.135s), which makes the test on line 51 in core.jl
barely fail
@test @elapsed(prog_perf(10^7)) < 9*@elapsed(noprog_perf(10^7))
I think the 9 is a bit arbitrary and that the potential slowdown of the truncation is not bad enough. If not, I do not have any other suggestions to improve the code.
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
5b3bd1d
) 96.81% compared to head (f854e4c
) 96.81%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
do you have a reproducible example of your original problem (the progressbar overflowing)? I believe it might be a problem with #233 where a space is added without reducing the size of the progressbar
edit: nvm I could reproduce it with testfunc4()
in the tests
I find that the progress bar usually overflows when the ETA quickly converges from a large to a small value. Because of this, I want to make the bar shorter. However, since the TTY width is not immediately obvious to me, I would rather like to scale the length of the bar by some fraction. This PR adds this feature.
Summary of changes:
barlen_fraction
to theProgress
-struct, which can take on any float. This means that the bar can be scaled negatively and larger than 1.I might have added too much to the testing, and the argument might be too verbose.