Stefan Mandel
Stefan Mandel
Using the current regex implementation in https://github.com/almondtools/regexbench is very imperformant. It would be fine to find the reasons for this.
I have written a [regex benchmark](https://github.com/almondtools/regexbench) comparing different regex engines for Java. Lately I found your approach and would be curious how it performs compared to the other alternatives: -...
I am not certain how to succintly express an assert in following context (shortened, abstract example): Assume following context: ``` #[derive(PartialEq, Debug)] struct S { val:u32 } impl S {...
By annotating values with `@LoadFromFile` we could point the generator not to generate code into the test but to read the setup/matcher directly from a file. This schould prevent generated...
The current test generator (matcher generator) is appropriate for small objects, but does not really scale up: * unprecise test failure locations * hard to understand mismatch messages Yet this...
Currently exceptions in instrumentation code cannot be located back to there origin. It could be helpfull if exceptions contain hints in which file the exception has failed. My first intuitions...
After the API is stable there should be more documentation and a tutorial. Hopefully the API gets stable in the next time.
Currently the naive algorithm seems to perform quite well for large alphabets and small patterns. There are some reasons for that: - small patterns means that backtracking cost is low...
I have written a [regex benchmark](https://github.com/almondtools/regexbench) comparing different regex engines for Java. Lately I found your approach and would be curious how it performs compared to the other alternatives. Yet...