ugrep

an llm so I can say things like "How do I fix this error" or "what debian package do I need to get this to run right?" ... both these are recent patterns I've started and they've been real game changers Some lesser game-changers: * tmux extrakto - opens an "fzf" like search of all the text on the screen. So after a "git status", I can do git add (run extracto - enter partial path, press tab) and continue: https://github.com/laktak/extrakto * mcfly history: https://github.com/cantino/mcfly just watch the demo, you'll see * ugrep: grep with a powerful tui: https://github.com/Genivia/ugrep - I became an instant convert. * batcat: https://github.com/sharkdp/bat ... you really need to use some of its other features to leverage it. It's really nice.

CPU expensive. This method is extensively tested with many configurations of parameters to find the optimal parameterization as tested on several machines. This was then compared to the best-known algorithms I could find and implemented in C (tested in memory, not on files and not reported in the ugrep project). I will gladly share this method publicly eventually in a technical paper. For a while I contemplated filing a utility patent, but did not move forward on that because I want this technology to be freely available to everyone and not proprietary. Of course, it would be nice to receive some recognition and not get ripped off. Most of the grep tools just use what is already available publicly and aren't doing something new that is clever, with the possible exception of hyperscan. Secondly, I am glad to see that ugrep is useful to many others. In my conversations with ugrep users, performance is not their top concern but having these new features that ugrep offers that other grep lack. As long as ugrep is very fast, they are more than happy. They also suggested that ugrep should be compatible with GNU grep's options and not try to be "too clever" to skip files and directories, at least not out-of-the-box. None of the ugrep perf tests skip files or directories and includes all hidden files/directories, binary files, and compressed files. Combining all these requirements and suggestions by users into ugrep wasn't trivial. But I believe we accomplished that goal reasonably well. Having said that, ugrep is relatively new and still evolving. There are a lot of opinionated folks when it comes to performance. Many in my domain of expertise realized already over a decade ago that it is a folly to pursue "the best performance" when the variety of architectures is vast and hardware and software are still evolving, even when slowly. There is no set of perfect benchmarks. There are always assumptions and requirements that affect the results wildly (I am a professor in CS and spent my entire career as a researcher, including in the area of high-performance computing.) I enjoy working now and then on deep and challenging coding projects, such as ugrep. It's a crazy fun project to work on when I have time. Cheers!