Consider to add loading progress to first time run message

[cantino]

Consider to add loading progress to first time run message

After 3+ hours of running, it failed with the following error:

thread 'main' panicked at 'McFly error: Insert to work: NulError(NulError(0, [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 101, 120, 101, 99, 32, 115, 116, 97, 114, 116, 120, 32, 38, 38, 32, 101, 120, 105, 116]))', src/libcore/result.rs:997:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Next runs produce the error described here #56

McFly: Upgrading McFly DB to version 3, please wait...thread 'main' panicked at 'McFly error: Unable to add cmd_tpl to commands: SqliteFailure(Error { code: Unknown, extended_code: 1 }, Some("duplicate column name: cmd_tpl"))', src/libcore/result.rs:997:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Following the hint gives:

RUST_BACKTRACE=1 bash
McFly: Upgrading McFly DB to version 3, please wait...thread 'main' panicked at 'McFly error: Unable to add cmd_tpl to commands: SqliteFailure(Error { code: Unknown, extended_code: 1 }, Some("duplicate column name: cmd_tpl"))', src/libcore/result.rs:997:5
stack backtrace:
0: <unknown>
1: <unknown>
2: <unknown>
3: <unknown>
4: <unknown>
5: <unknown>
6: <unknown>
7: <unknown>
8: <unknown>
9: main
10: __libc_start_main
11: <unknown>

[cantino]

Hey @somospocos, I'm sorry to hear that. I haven't seen it take more than a second before. Is there any chance it was happening in two windows at once?

Is there any chance it was happening in two windows at once?

I don't think so. Here are more details about the install attempt:

• I downloaded the binary release, put the binary in PATH, sourced the script in my bashrc, just as README suggests
• bit later I opened another terminal window and got the first run error message. I did it to see how big the sqlite database grew up already, since I kept seeing continuous disk activity
• as I stated in the first post, mcfly worked for at least 15 minutes before I tried to open that new terminal window, this makes me think there was no race condition involved
• as soon as I saw that the new terminal window gets locked, I killed it and used other, older terminal window, that was started before I installed mcfly, so it did not have it enabled, to do CLI stuff

So far I have just disabled mcfly back and will most likely wait for the next stable release before trying again.

Of course, there's always the option to try it on a smaller bash history file, but I have a strong (in my - very likely biased - opinion) argument against it.

As I understand, mcfly does the initial processing of the bash history file only once, at the first run. As the user keeps using it, new commands are added to mcfly's database, so it doesn't work only with the commands that it did load at first run. And this is exactly why I fail to see any reasons why the first run should take long (one second that you said is fair). The following is pure speculation, since I don't know how does mcfly exactly work, but I imagine for a big bash history file, that file could be read incrementally / in background / whatever. Sure while the old history will be loaded partially, mcfly won't be "too smart", but the user having a fluid, non-blocking workflow is higher priority.