[Bug] divide by zero panic after exiting test

[EcoBay]

I am using ttyper 0.4.0 and I have encountered a panic after escaping during test I don't know what causes it and i can't replicate it

thread 'main' panicked at 'attempt to divide by zero', /home/eco/.local/share/cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.16.0/src/widgets/chart.rs:425:22

[max-niederman]

I can't say for sure without testing, but my guess is that this could happen when the test is quit before a character is typed, causing a division by zero in the wpm graph generation somewhere. I'll look into it tomorrow.

[max-niederman]

After some testing, I have also been unable to reproduce this. If you're ever able to reproduce it, please update the issue and I can work on a fix.

[rkmiec]

I just stumbled upon this error and came here to report it.
I don't know the exact step, but I was able to reproduce it once using the following steps: when first word was misspelled but space pressed I used backspace to move back to a first word and then used ESC to leave the test.

[ysxninja]

Bug occurs randomly? Try with first three words in the 50 of the 200 most common english words test.

[ysxninja]

Throws a panick sometimes

ore::ops::function::FnOnce<A> for &F>::call_once::hf833e7144973d4be
at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/core/src/ops/function.rs:280:13
23:     0x5635d06aae9e - std::panicking::try::do_call::h79761d203bfb6b46
at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panicking.rs:492:40
24:     0x5635d06aae9e - std::panicking::try::h0561cbbe1722251d
at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panicking.rs:456:19
25:     0x5635d06aae9e - std::panic::catch_unwind::hbca347ddd031b141
at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panic.rs:137:14
26:     0x5635d06aae9e - std::rt::lang_start_internal::{{closure}}::h0492050ad281ec32
at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/rt.rs:128:48
27:     0x5635d06aae9e - std::panicking::try::do_call::h3ebce69871996bb3
at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panicking.rs:492:40
28:     0x5635d06aae9e - std::panicking::try::hbed537d20e728475
at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panicking.rs:456:19
29:     0x5635d06aae9e - std::panic::catch_unwind::h4185e2024c6a5d05
at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panic.rs:137:14
30:     0x5635d06aae9e - std::rt::lang_start_internal::h1899cfd715ca6829
at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/rt.rs:128:20
31:     0x5635d061a652 - main
32:     0x7f7d303a2290 - <unknown>
33:     0x7f7d303a234a - __libc_start_main
34:     0x5635d060a7c5 - _start
at /build/glibc/src/glibc/csu/../sysdeps/x86_64/start.S:115
35:                0x0 - <unknown>

[bolphen]

I think the issue is when a Chart only has one label: tui is trying to divide by the number of labels minus 1 (which is arguably a bug)

[bolphen]

Just looked into it again. The issue is here

ttyper/src/ui.rs

Line 325 in 9790d54

(wpm_sma_min as u16..wpm_sma_max as u16)

tui expects at least two labels in the y-axis. If the wpm range is too small (which can often be triggered if you quit the test too early) we get only one label here and there will be a division by zero.

And the fix is to simply increase the wpm range here to ensure at least two labels.