sqlitefs
ripgrep
Our great sponsors
sqlitefs | ripgrep | |
---|---|---|
4 | 346 | |
46 | 44,253 | |
- | - | |
10.0 | 9.3 | |
over 1 year ago | 1 day ago | |
Rust | Rust | |
MIT License | The Unlicense |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
sqlitefs
- What If OpenDocument Used SQLite?
-
SQLite: 35% Faster Than the Filesystem
> but also presents as a true filesystem.
As does:
https://github.com/guardianproject/libsqlfs
https://github.com/narumatt/sqlitefs
(I know nothing about these, just got them from a quick search)
- Why SQLite may become foundational for digital progress
- Fd: A simple, fast and user-friendly alternative to 'find'
ripgrep
-
Level Up Your Dev Workflow: Conquer Web Development with a Blazing Fast Neovim Setup (Part 1)
live grep: ripgrep
-
Modern Java/JVM Build Practices
The world has moved on though to opinionated tools, and Rust isn't even the furthest in that direction (That would be Go). The equivalent of those two lines in Cargo.toml would be this example of a basic configuration from the jacoco-maven-plugin: https://www.jacoco.org/jacoco/trunk/doc/examples/build/pom.x... - That's 40 lines in the section to do the "defaults".
Yes, you could add a load of config for files to include/exclude from coverage and so on, but the idea that that's a norm is way more common in Java projects than other languages. Like here's some example Cargo.toml files from complicated Rust projects:
Servo: https://github.com/servo/servo/blob/main/Cargo.toml
rust-gdext: https://github.com/godot-rust/gdext/blob/master/godot-core/C...
ripgrep: https://github.com/BurntSushi/ripgrep/blob/master/Cargo.toml
socketio: https://github.com/1c3t3a/rust-socketio/blob/main/socketio/C...
-
Ugrep – a more powerful, ultra fast, user-friendly, compatible grep
Another issue with Hyperscan is that if you enable HS_FLAG_UTF8[1], which hypergrep does[2,3], and then search invalid UTF-8, then the result is UB.
> This flag instructs Hyperscan to treat the pattern as a sequence of UTF-8 characters. The results of scanning invalid UTF-8 sequences with a Hyperscan library that has been compiled with one or more patterns using this flag are undefined.
That's another issue you'll need to grapple with if you use Hyperscan. PCRE2 used to have this issue[4], but they've since defined the semantics of searching invalid UTF-8 with Unicode mode enabled. ripgrep 14 uses that new mode, but I haven't updated that FAQ answer yet.
[1]: https://intel.github.io/hyperscan/dev-reference/api_files.ht...
[2]: https://github.com/p-ranav/hypergrep/blob/ee85b713aa84e0050a...
[3]: https://github.com/p-ranav/hypergrep/blob/ee85b713aa84e0050a...
[4]: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#why...
I'm not clear on why you're seeing the results you are. It could be because your haystack is so small that you're mostly just measuring noise. ripgrep 14 did introduce some optimizations in workloads like this by reducing match overhead, but I don't think it's anything huge in this case. (And I just tried ripgrep 13 on the same commands above and the timings are similar if a tiny bit slower.)
Interesting, it supports an n-gram indexer. ripgrep has had this planned for a few years now [1] but hasn't implemented it yet. For large codebases I've been using csearch, but it has a lot of limitations.
Unfortunately... I just tried the indexer and it's extremely slow on my machine. It took 86 seconds to index a Linux kernel tree, while csearch's cindex tool took 8 seconds.
- Tell HN: My Favorite Tools
-
Potencializando Sua Experiência no Linux: Conheça as Ferramentas em Rust para um Desenvolvimento Eficiente
Explore o Ripgrep no repositório oficial: https://github.com/BurntSushi/ripgrep
-
Scrybble is the ReMarkable highlights to Obsidian exporter I have been looking for
🔎🗃️ ripgrep or ugrep (search fast, use regex patterns or fuzzy search, pipe output to bash/zsh shell for further processing V coloring)
- RFC: Add ngram indexing support to ripgrep (2020)
What are some alternatives?
telescope-live-grep-args.nvim - Live grep with args
fd - A simple, fast and user-friendly alternative to 'find'
ugrep - NEW ugrep 5.1: an ultra fast, user-friendly, compatible grep. Ugrep combines the best features of other grep, adds new features, and searches fast. Includes a TUI and adds Google-like search, fuzzy search, hexdumps, searches nested archives (zip, 7z, tar, pax, cpio), compressed files (gz, Z, bz2, lzma, xz, lz4, zstd, brotli), pdfs, docs, and more
the_silver_searcher - A code-searching tool similar to ack, but faster.
fzf - :cherry_blossom: A command-line fuzzy finder
alacritty - A cross-platform, OpenGL terminal emulator.
python-regex-cheatsheet - Python 2.7 Regular Expression cheatsheet, as a restructured text document and Makefile to convert it to PDF
Parallel
xsv - A fast CSV command line toolkit written in Rust.
delta - A syntax-highlighting pager for git, diff, and grep output
jq - Command-line JSON processor [Moved to: https://github.com/jqlang/jq]
zsh-syntax-highlighting - Fish shell like syntax highlighting for Zsh.