parle
parle copied to clipboard
Request: dump() to php://output for buffering.
php
is version 7.3 (macports) @ macOS 10.13;bash
command lines
php -c <(echo extension=parle) -i|gawk '(s&&/^$/||/^parle$/)&&++s==3{exit}s'
shows:
parle
Lexing and parsing support => enabled
Parle version => 0.8.1
Parle internal UTF-32 => no
Currently:
php -c <(echo extension=parle) -r 'echo "unbuffered before".PHP_EOL;ob_start();echo "buffered before".PHP_EOL;(new Parle\Parser)->dump();echo "buffered after".PHP_EOL;echo "unbuffered after:".PHP_EOL.ob_get_clean();' 2>/dev/null
yields:
unbuffered before
%%
%%
unbuffered after:
buffered before
buffered after
Expected:
like php -c <(:) -r 'echo "unbuffered before".PHP_EOL;ob_start();echo "buffered before".PHP_EOL;file_put_contents("php://output","%%\n\n%%\n");echo "buffered after".PHP_EOL;echo "unbuffered after:".PHP_EOL.ob_get_clean();' 2>/dev/null
yielding:
unbuffered before
unbuffered after:
buffered before
%%
%%
buffered after
Thanks for the report. Internally lexertl
uses C++ streams, that's the reason for the discrepancy with PHP. I'd be hesitant patching the bundled library however, as it's not future oriented. Best would be a stream object could be injected there, need to check that.
Thanks.
std::ostringstream os; std::string str;
parsertl::debug::dump(grules, os); str = os.str(); // Do whatever you need to do with str.
@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 can be output with php_write
or alike as here https://github.com/php/php-src/blob/master/main/php.h#L299. The only concern would be if the buffer would become too big, but i guess it's in most case not an issue as it's all the debug scenario only.
In addition to this, a bit more tricky part to address might be when the UTF-32 support is enabled. Perhaps it can belong in the same scope.
Thanks
@weltling I can have a look into this.
Fixed by PR #55