Closed EcoBay closed 1 year ago
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.
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.
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.
Bug occurs randomly? Try with first three words in the 50 of the 200 most common english words
test.
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>
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)
Just looked into it again. The issue is here https://github.com/max-niederman/ttyper/blob/9790d540b1f0023d4294416630d395fb7d8a5bbd/src/ui.rs#L325
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.
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