fancy-regex
build2
Our great sponsors
| fancy-regex | build2 | |
|---|---|---|
| 5 | 5 | |
| 387 | 541 | |
| 2.6% | 1.3% | |
| 7.9 | 9.3 | |
| 3 months ago | 8 days ago | |
| Rust | C++ | |
| MIT License | MIT License |
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.
fancy-regex
-
lemmeknow v0.7.0 is here with support for identifying bytes with help of regex crate!
https://github.com/fancy-regex/fancy-regex/issues/84 it's still open issue
-
Debian Running on Rust Coreutils
Ahh, very interesting, thanks for sharing! Do you have any thoughts around why that is? I presume that's due to Oniguruma supporting a much broader feature set and something like fancy-regexp's approach with mixing a backtracking VM and NFA implementation for simple queries would be needed for better perf? (I am aware you played a role in that) [1]
I have been playing around with regex parsing through building parsers through parser combinators at runtime recently, no clue how it will perform in practice yet (structuring parser generators at runtime is challenging in general in low-level languages) but maybe that could pan out and lead to an interesting way to support broader sets of regex syntaxes like POSIX in a relatively straightforward and performant way.
[1] https://github.com/fancy-regex/fancy-regex#theory
- Fancy-Regex: A hybrid NFA and backtracking Regex library in Rust
-
An additional non-backtracking RegExp engine
Not an expert but fancy regex is a Rust library that uses a hybrid approach to detect whether a sub expression contains backtracking and delegates to the appropriate engine.
https://github.com/fancy-regex/fancy-regex
build2
-
b2 for C++?
Yes, this is a common stumbling block for users with the CMake background. The underlying reason is that build2 is a "multi-repo first" build system while CMake is "mono-repo first" (or perhaps even "mono-repo only"; I don't think there were repositories as we know them when Autotools was designed ;-)). In particular, in build2 it's common to build multiple independent projects/repositories in a shared build configuration. Putting this build configuration as a subdirectory of source directory of one of them would be strange. You can read more on this in this issue: https://github.com/build2/build2/issues/187
-
build2 IDE support?
build2 can generate Clang compilation database (currently indirectly): https://github.com/build2/build2/issues/96 I believe quite a few IDEs (including CLion) can work off that.
-
Debian Running on Rust Coreutils
Yes, please, that would be very helpful: https://github.com/build2/build2/issues
What are some alternatives?
min-sized-rust - 🦀 How to minimize Rust binary size 📦
samurai - ninja-compatible build tool written in C
pomsky - A new, portable, regular expression language
embedded-graphics - A no_std graphics library for embedded applications
just - 🤖 Just a command runner
BSDCoreUtils - BSD coreutils is a port of many utilities from BSD to Linux and macOS.
fab-rs - The fabulous, aspirationally Make-compatible, fabricator of files.
shake - Shake build system
coreutils - Cross-platform Rust rewrite of the GNU coreutils
regex - An implementation of regular expressions for Rust. This implementation uses finite automata and guarantees linear time matching on all inputs.