* init daemon crate
* wip
* minimal functioning daemon, needs cleanup for sure
* better errors
* add signal cleanup
* logging
* things
* add sync worker
* move daemon crate
* 30s -> 5mins
* make clippy happy
* fix stuff maybe?
* fmt
* trim packages
* rate limit fix
* more protoc huh
* this makes no sense, why linux why
* can it install literally just curl
* windows in ci is slow, and all the newer things will not work there. disable the daemon feature and it will build
* add daemon feature
* maybe this
* ok wut where is protoc
* try setting protoc
* hm
* try copying protoc
* remove optional
* add cross config
* idk nix
* does nix want this?
* some random pkg I found does this
* uh oh
* hack, be gone!
* update contributing
* fix(dotfiles): allow clearing aliases, disable import
At the moment there are far too many edge cases to handle importing
aliases.
1. We need an interactive shell to print aliases. Without it, most
shells won't report much.
2. Many people have their shells print things on startup (graphics,
fortunes, etc). This could be detected as an attempt to set an alias.
Rather than spend the next year finding import edge cases, I'm
disabling it for now. There's probably a better way we can do this?
* clippy
* feat(history): create atuin-history, add stats to it
I'd like to eventually pull all the history stuff into this crate. Stats
are a nice start, as I'd like to use them from the UI anyways.
* lock
* clippy
P99 is usually <100ms which is excellent, but occasionally has big
spikes to 1000ms. This is only on the record index.
I don't want this to get out of hand. I've ran a few test queries and
they all complete very fast, and are purely index scans.
Hopefully this helps figure out if it's a specific user with tonnes of
stores or something? Otherwise there could be something up with my db.
I should probably also figure out some proper log levels or tracing lol.
There's a bunch of duplication here!
I'd also like to support syncing shell "snippets", aka just bits of
shell config that don't fit into the structure here. Potentially special
handling for PATH too.
Rather than come up with some abstraction in the beginning, which
inevitably will not fit future uses, I'm duplicating code _for now_.
Once all the functionality is there, I can tidy things up and sort a
proper abstraction out.
Something in atuin-client for map/list style synced structures would
probably work best.
1. Start on a home page, can sort onboarding/etc from there
2. Introduce zustand for state management. It's nice!
Did a production build and clicked around for a while. Memory usage
seems nice and chill.
* feat(doctor): check active preexec framework
To check if "blesh" or "bash-preexec" is loaded and active in the
current Bash session where `atuin doctor` is called, we make the Atuin
integration script for Bash to set the environment variable
`ATUIN_PREEXEC_BACKEND` and store a string when it detects "blesh" or
"bash-preexec".
To check whether the obtained ATUIN_PREEXEC_BACKEND is set by the
current session, we record SHLVL in ATUIN_PREEXEC_BACKEND and check if
it matches SHLVL of the current process.
* feat(doctor): detect the case where Atuin is initialized before blesh
* initial
* ui things
* cargo
* update, add history refresh button
* history page a bit better, add initial dotfiles page
* re-org layout
* bye squigglies
* add dotfiles ui, show aliases
* add default shell detection
* put stats in a little drawer, alias import changes
* use new table for aliases, add alias deleting
* support adding aliases
* close drawer when added, no alias autocomplete
* clippy, format
* attempt to ensure gdk is installed ok
* sudo
* no linux things on mac ffs
* I forgot we build for windows too... end of day
* remove tauri backend from workspace
Bash < 5.0 doesn't support the high-resolution clock EPOCHREALTIME, so
ble.sh uses the builtin command `time` to measure the execution times
in Bash < 5.0. This has a lower resolution of milliseconds but still
more accurate than Atuin's measurent because Atuin's measurement
includes the spawn cost of Atuin, which is typically larger than a
millisecond.
Reported-by: Georgios Vlassis <https://github.com/gvlassis>
Reference: https://github.com/atuinsh/atuin/pull/1484#issuecomment-2047068582
