Anatol Belski

Thanks for checking the patch! Sure the QA needs to pass prior a merge. I'm around anytime once CI is fixed, to refresh it for the next round. Thanks!

@BenHanson i think there's a need to clarify the matter a bit. PHP uses an `ASCII` based serialization format. The point here is of course about the PHP own items...

Yep, that could be an approach. To keep in mind is also the security component, as the serialized string can be ponentially manipulated. Thansk

The idea with the serialization is exactly about having the data saved outside the app. Like for example ```php $f = "/path/to/dump.txt"; if (file_exists($f)) { $paser = Parser::from(file_get_contents($f)); } else...

Yep, JSON is of no use, but i guess a hash would be not much of that as well. Once the list of numbers is outside, the hash can be...

@BenHanson with regard to UTF-8 vs UTF-32 - the conversion currently relies on `libstdc++`, please see here `lib/parle/cvt.hpp` . I think Windows is not quite happy there, but that's probably...

AFAIR the reason to support `UTF-32` is that otherwise some regex options are not available. At least these come in question: https://www.php.net/manual/en/parle.regex.unicodecharclass.php These seem to be provided standard C++ lib...

The conversions already happen at the corresponding places, as mentioned with regard to `./lib/parle/cvt.hpp` currently using the functionality from ``. The conversion happens at runtime. It's just with the current...

Very nice. The `char32_t` issue is what i've seen as well as a blocker for the UTF-32 part. Thansk

@BenHanson this might be indeed a low hanging fruit. At least for the single byte based variant, places that can be integrated are `_parser_dump` and `_lexer_dump`. The resulting string buffer...