This file provides guidance to the AI assistant when working with code in this repository.
FlowRegex is a revolutionary regular expression library implementing the "Flow Regex Method" - an automaton-free approach to pattern matching based on Brzozowski's derivative theory. The library eliminates traditional automaton construction and provides theoretical immunity against ReDoS attacks while maintaining linear time complexity.
- Core Library:
lib/flow_regex.rb- Main entry point - Core Components:
BitMask- Efficient bitmask operations for position trackingRegexElement- Base class for transformation functionsParser- Converts regex patterns to executable elementsMatcher- Core matching engine using function compositionFuzzyMatcher- Fuzzy matching with edit distance support
- Advanced Features:
OptimizedText- MatchMask pre-computation optimizationTrackedBitMask- Position tracking for lookahead operationsTwoStageMatcher- Substring extraction support
- Location:
c_implementation/ - Purpose: Performance benchmarking and MatchMask optimization proof-of-concept
- Features: Limited subset of Ruby functionality, optimized for speed
- Build System: Standard Makefile-based build
- Version: Assumed to be
3.0.0or later. - Dependencies: No external gem dependencies.
Bundleris not used. - Testing Framework:
Minitest(Ruby's built-in testing library).
- Compiler:
gccas defined inc_implementation/Makefile. - Static Analysis:
cppcheckis used for static analysis viamake analyze.
# Run the main test suite
ruby test/test_flow_regex.rb
# Run a single test method from a file (useful for focused development)
# Example: ruby test/test_flow_regex.rb -n /test_a_specific_pattern/
ruby test/test_flow_regex.rb -n /<test_name_pattern>/
# Use the scratchpad for quick, disposable experiments
ruby quick_test.rb
# Run examples
ruby examples/basic_usage.rb
# Run complex pattern tests
ruby test_complex.rbcd c_implementation
# Build all targets
make all
# Run the main test runner
make test
./test_runner
# Run the comprehensive test suite script
./run_all_tests.sh
# Run performance benchmarks
make analysis_benchmark
./analysis_benchmark
# Run static analysis
make analyze
# Run memory checks with Valgrind
make memcheck
# Clean build artifacts
make cleanYour primary role is to assist in developing, testing, and documenting the FlowRegex library. You should be proactive in suggesting improvements, writing clean and efficient code, and adhering to the project's conventions.
- Core Logic (High Caution): Files in
lib/andc_implementation/src/are critical. Changes must be carefully considered, well-tested, and justified. - Testing (High Activity): Files in
test/andc_implementation/tests/should be actively modified and extended. When adding features or fixing bugs, always add or update corresponding tests. - Experimentation (Free-form):
quick_test.rbis your scratchpad. Use it freely to try out ideas, demonstrate concepts, or verify logic before integrating it into the main codebase.
The debug: true parameter in the Ruby FlowRegex constructor is your primary debugging tool. Use it to get detailed execution traces.
# Example of enabling debug mode for analysis
FlowRegex.new('a.c', debug: true).match('abc')FlowRegex uses transformation functions that convert position sets (bitmasks) representing potential match states. Each regex element is a function that processes character input and transforms the active position set.
- Linear Time Guarantee: O(n) for any input, preventing ReDoS attacks
- Parallel Processing: Multiple match paths processed simultaneously via bitmask operations
- No Backtracking: Eliminates exponential complexity through position set management
- MatchMask Optimization: Pre-computed character masks for high-performance matching
- Ruby Version: 10,000 characters (MAX_TEXT_LENGTH)
- C Version: 100,000 characters (FLOWREGEX_MAX_TEXT_LENGTH)
- Unit Tests: Individual component testing in
test/directory. - Integration Tests: End-to-end pattern matching validation.
- Performance Tests: ReDoS immunity and speed comparisons.
- Fuzzy Matching Tests: Edit distance algorithm validation.
- Functional Tests: Core algorithm correctness via
make test. - Optimization Tests: MatchMask performance validation.
- Memory Tests: Valgrind integration via
make memcheck. - Static Analysis:
cppcheckviamake analyze.
- Ruby: Adhere to the standard Ruby community style guide. Prioritize clarity, simplicity, and maintainability.
- C: Follow the conventions present in the existing C code (e.g., variable naming, comment style).
lib/flow_regex/parser.rb- Pattern parsing and AST constructionlib/flow_regex/matcher.rb- Core matching algorithmlib/flow_regex/bit_mask.rb- Fundamental bitmask operationsc_implementation/src/flowregex.c- C algorithm implementationc_implementation/src/optimized_text.c- MatchMask optimization
When you complete any development task, you MUST create a Pull Request using the following process:
- Commit your changes with a descriptive message.
- Create a new branch for the feature/fix.
- Ask for user approval before creating the Pull Request.
- Create a Pull Request using the
gh pr createcommand only after user confirmation.
CRITICAL: NEVER execute gh pr create without explicit user approval. ALWAYS ask "Should I create a Pull Request for this task?" and wait for confirmation before proceeding.
Use this template for all Pull Requests:
## Summary
<!-- Brief description of what this PR does -->
## Changes Made
<!-- List of specific changes -->
## Testing
<!-- How was this tested? -->
- [ ] Ruby tests pass (`ruby test/test_flow_regex.rb`)
- [ ] C tests pass (`./run_all_tests.sh`)
- [ ] Manual testing completed
- [ ] Performance benchmarks run (if applicable)
## Type of Change
<!-- Check the relevant box -->
- [ ] Bug fix (non-breaking change that fixes an issue)
- [ ] New feature (non-breaking change that adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update
- [ ] Performance improvement
- [ ] Code refactoring
## Implementation Details
<!-- Technical details about the implementation -->
## Performance Impact
<!-- Any performance implications -->
- [ ] No performance impact
- [ ] Performance improved
- [ ] Performance degraded (explain why acceptable)
## Related Issues
<!-- Link any related issues -->
Closes #
---
🤖 Generated with [Claude Code](https://claude.ai/code) & [Gemini Code Assist]
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Gemini <noreply@google.com>After completing any task:
-
Stage and commit changes:
git add . git commit -m "descriptive message"
-
Create feature branch:
git checkout -b feature/task-description
-
Push branch:
git push -u origin feature/task-description
-
Create PR using GitHub CLI:
gh pr create --title "Task: Description" --body-file pr_template.md
Before creating PR, ensure:
- All tests pass
- Code follows project conventions
- Documentation updated if needed
- Performance impact considered
- No breaking changes (or properly documented)
- Commit messages are descriptive