Re: [PHP-DEV] [VOTE] Dump results of expressions in `php -a`
On Mon, 1 Feb 2021 at 15:40, Bob Weinand wrote: > My main concern in this iteration of the RFC is: what happens with > big/deeply nested objects? > They tend to spew tons of lines if var_dump()'ed. Do we have reasonable > depth/output limitations in default dumping mode? > Good catch Bob, I'd completely overlooked this was missing in the RFC. I like how IPython's REPL has configuration options for this. When I start it I can pass in arguments to truncate the output a lot or not at all. If I always want these settings, I add them to a config file. I hoped existing REPLs (in different languages) would have consensus about when and where to truncate output, and representations to use; but when I played with a few over the weekend, there wasn't. Some assume you want everything output; others (for data structures) the first N items, and others the first N/2 and the last N/2. Objects often show very little that's useful. Do you know of any research or writeups as to what works best - or even saved output of how various REPLs show their output? Peter
Re: [PHP-DEV] [VOTE] Dump results of expressions in `php -a`
On Wed, Feb 3, 2021 at 3:40 PM tyson andre
wrote:
> Hi Bob Weinand,
>
> Voting has started on
> https://wiki.php.net/rfc/readline_interactive_shell_result_function
> on 2021-01-19, and ends on 2021-02-02.
>
> This RFC proposes to dump the results of non-null expressions using
> var_dump/var_export() by default in `php -a` (the interactive shell).
> Additionally, this adds a new function
> `readline_interactive_shell_result_function` to the readline PHP module.
> This function only affects interactive shells - it can optionally be
> used to set or clear a closure when `extension_loaded('readline') === true`,
> but that closure would only be called in interactive shells (i.e. php
> -a).
> (That closure would be called instead of the native implementation
> with the snippet of code that was evaluated and the expression's result,
> if a php statement contained a single expression such as `2+2;` or
> `$x = [1,2];` (that could be used as the expression of a return statement)
> - Dumping of expression results can be disabled using an ini setting
> or at runtime
>
> Thanks,
> - Tyson
> >>>
> >>> Hey Tyson,
> >>>
> >>> My main concern in this iteration of the RFC is: what happens with
> big/deeply nested objects?
> >>> They tend to spew tons of lines if var_dump()'ed. Do we have
> reasonable depth/output limitations in default dumping mode?
> >>>
> >>> I'm often enough using php -a to do some quick ad-hoc processing
> (example, read a big json file, and then access a value; instantiating a
> mediawiki bot framework and calling replace on it; ...).
> >>>
> >>> It's really cool to have any interactive feedback at all, but please,
> at least by default, limit the output. (An example is the JS REPL in
> browser console - it shows you a minimal preview of the object, and then
> you can expand with your mouse. Obviously with a pure cli application, this
> needs different - intuitive - navigation.)
> >>>
> >>> As it currently stands, this makes php -a unusable in any but the
> simplest cases, without just disabling the whole feature.
> >>>
> >>> I like the whole feature, but the missing output limitation (I have
> yet enough nightmares from var_dump()'ing the wrong object filling my shell
> with tons of irrelevant information… I don't need that potentially
> happening on every single evaluated expression)
> >>>
> >>> Thus I'm voting no, for now.
> >>
> >> As-is, the entire object or string would be dumped with
> var_export/var_dump to stdout.
> >>
> >> Thoughts on the adding following output truncation mechanism
> >> (for the default C result dumper implementation)
> >> before printing the results of the returned expression
> >> (the user output continues to be untruncated, and the existence of
> cli.pager
> >> would not affect this mechanism in case the binary is not actually a
> pager)?
> >> For arrays/objects used with var_dump - the equivalent of
> >> `ob_start(); var_dump($result); $result = ob_get_clean();`
> >> would have to be used first from C since var_dump still writes to the
> output buffer (php_printf(), etc.)
> >
> >var_dump() tends to be quite intensive in newline usage. I don't think
> var_dump() (as is) is the best mechanism to print. At least I'd use one
> property/one array argument = single line instead of two lines.
> >Additionally, when dumping a nested object, it's more valuable to see as
> much as possible from the primary object rather than the deep nesting.
> >
> >
> >> I'd omitted output truncation from the RFC because I wasn't sure how
> many people
> >> would consider it excessive to include a limit on var_dump output, and
> there was little feedback before the RFC vote started.
> >
> >Yeah, sorry for the late comment on that :-)
> >
> >> The simplest implementation would be to truncate to a byte limit and
> append `...` if truncated,
> >> but the main concern that's been brought up is the approximate number
> of lines.
> >> Obviously, there'd be a value in truncating the output if there were to
> be megabytes of output,
> >> though exactly what settings make sense as a default would vary.
> >
> >As mentioned a section earlier, there should be limits according to the
> nesting-level … e.g. if it's the top-level value, a string may have 20
> lines printed and array and objects as well. And array entries/properties
> should then be in a single line or take up to max ... 20 / count(properties
> or array entries) lines (width before truncation can be determine from
> terminal width), which then can be mostly in one line flattened output.
> >The general rule here should be, show me my object/array at hand and give
> me a brief overview of what's nested within - and if I'm interested in
> detail, let me (manually) output that object.
> >Also consider, when dumping strings within (nested) arrays/objects to
> replace newlines with \n, for nicer display.
> >
> >> C would not print anything (e.g. `=> `) or even call
>
Re: [PHP-DEV] [VOTE] Dump results of expressions in `php -a`
Hi Bob Weinand,
Voting has started on
https://wiki.php.net/rfc/readline_interactive_shell_result_function
on 2021-01-19, and ends on 2021-02-02.
This RFC proposes to dump the results of non-null expressions using
var_dump/var_export() by default in `php -a` (the interactive shell).
Additionally, this adds a new function
`readline_interactive_shell_result_function` to the readline PHP module.
This function only affects interactive shells - it can optionally be used
to set or clear a closure when `extension_loaded('readline') === true`,
but that closure would only be called in interactive shells (i.e. php -a).
(That closure would be called instead of the native implementation with
the snippet of code that was evaluated and the expression's result,
if a php statement contained a single expression such as `2+2;` or `$x =
[1,2];` (that could be used as the expression of a return statement)
- Dumping of expression results can be disabled using an ini setting or at
runtime
Thanks,
- Tyson
>>>
>>> Hey Tyson,
>>>
>>> My main concern in this iteration of the RFC is: what happens with
>>> big/deeply nested objects?
>>> They tend to spew tons of lines if var_dump()'ed. Do we have reasonable
>>> depth/output limitations in default dumping mode?
>>>
>>> I'm often enough using php -a to do some quick ad-hoc processing (example,
>>> read a big json file, and then access a value; instantiating a mediawiki
>>> bot framework and calling replace on it; ...).
>>>
>>> It's really cool to have any interactive feedback at all, but please, at
>>> least by default, limit the output. (An example is the JS REPL in browser
>>> console - it shows you a minimal preview of the object, and then you can
>>> expand with your mouse. Obviously with a pure cli application, this needs
>>> different - intuitive - navigation.)
>>>
>>> As it currently stands, this makes php -a unusable in any but the simplest
>>> cases, without just disabling the whole feature.
>>>
>>> I like the whole feature, but the missing output limitation (I have yet
>>> enough nightmares from var_dump()'ing the wrong object filling my shell
>>> with tons of irrelevant information… I don't need that potentially
>>> happening on every single evaluated expression)
>>>
>>> Thus I'm voting no, for now.
>>
>> As-is, the entire object or string would be dumped with var_export/var_dump
>> to stdout.
>>
>> Thoughts on the adding following output truncation mechanism
>> (for the default C result dumper implementation)
>> before printing the results of the returned expression
>> (the user output continues to be untruncated, and the existence of cli.pager
>> would not affect this mechanism in case the binary is not actually a pager)?
>> For arrays/objects used with var_dump - the equivalent of
>> `ob_start(); var_dump($result); $result = ob_get_clean();`
>> would have to be used first from C since var_dump still writes to the output
>> buffer (php_printf(), etc.)
>
>var_dump() tends to be quite intensive in newline usage. I don't think
>var_dump() (as is) is the best mechanism to print. At least I'd use one
>property/one array argument = single line instead of two lines.
>Additionally, when dumping a nested object, it's more valuable to see as much
>as possible from the primary object rather than the deep nesting.
>
>
>> I'd omitted output truncation from the RFC because I wasn't sure how many
>> people
>> would consider it excessive to include a limit on var_dump output, and there
>> was little feedback before the RFC vote started.
>
>Yeah, sorry for the late comment on that :-)
>
>> The simplest implementation would be to truncate to a byte limit and append
>> `...` if truncated,
>> but the main concern that's been brought up is the approximate number of
>> lines.
>> Obviously, there'd be a value in truncating the output if there were to be
>> megabytes of output,
>> though exactly what settings make sense as a default would vary.
>
>As mentioned a section earlier, there should be limits according to the
>nesting-level … e.g. if it's the top-level value, a string may have 20 lines
>printed and array and objects as well. And array entries/properties should
>then be in a single line or take up to max ... 20 / count(properties or array
>entries) lines (width before truncation can be determine from terminal width),
>which then can be mostly in one line flattened output.
>The general rule here should be, show me my object/array at hand and give me a
>brief overview of what's nested within - and if I'm interested in detail, let
>me (manually) output that object.
>Also consider, when dumping strings within (nested) arrays/objects to replace
>newlines with \n, for nicer display.
>
>> C would not print anything (e.g. `=> `) or even call var_dump/var_export if
>> the limits were set to 0.
>>
>> ```
>> >
>> const ASSUMED_BYTES_PER_LINE = 80;
>> const
Re: [PHP-DEV] [VOTE] Dump results of expressions in `php -a`
Hey Tyson,
> Am 02.02.2021 um 03:35 schrieb tyson andre :
>
> Hi Bob Weinand,
>
>>> Am 20.01.2021 um 01:55 schrieb tyson andre :
>>>
>>> Hi internals,
>>>
>>> Voting has started on
>>> https://wiki.php.net/rfc/readline_interactive_shell_result_function
>>> on 2021-01-19, and ends on 2021-02-02.
>>>
>>> This RFC proposes to dump the results of non-null expressions using
>>> var_dump/var_export() by default in `php -a` (the interactive shell).
>>> Additionally, this adds a new function
>>> `readline_interactive_shell_result_function` to the readline PHP module.
>>> This function only affects interactive shells - it can optionally be used
>>> to set or clear a closure when `extension_loaded('readline') === true`,
>>> but that closure would only be called in interactive shells (i.e. php -a).
>>> (That closure would be called instead of the native implementation with the
>>> snippet of code that was evaluated and the expression's result,
>>> if a php statement contained a single expression such as `2+2;` or `$x =
>>> [1,2];` (that could be used as the expression of a return statement)
>>> - Dumping of expression results can be disabled using an ini setting or at
>>> runtime
>>>
>>> Thanks,
>>> - Tyson
>>
>> Hey Tyson,
>>
>> My main concern in this iteration of the RFC is: what happens with
>> big/deeply nested objects?
>> They tend to spew tons of lines if var_dump()'ed. Do we have reasonable
>> depth/output limitations in default dumping mode?
>>
>> I'm often enough using php -a to do some quick ad-hoc processing (example,
>> read a big json file, and then access a value; instantiating a mediawiki bot
>> framework and calling replace on it; ...).
>>
>> It's really cool to have any interactive feedback at all, but please, at
>> least by default, limit the output. (An example is the JS REPL in browser
>> console - it shows you a minimal preview of the object, and then you can
>> expand with your mouse. Obviously with a pure cli application, this needs
>> different - intuitive - navigation.)
>>
>> As it currently stands, this makes php -a unusable in any but the simplest
>> cases, without just disabling the whole feature.
>>
>> I like the whole feature, but the missing output limitation (I have yet
>> enough nightmares from var_dump()'ing the wrong object filling my shell with
>> tons of irrelevant information… I don't need that potentially happening on
>> every single evaluated expression)
>>
>> Thus I'm voting no, for now.
>
> As-is, the entire object or string would be dumped with var_export/var_dump
> to stdout.
>
> Thoughts on the adding following output truncation mechanism
> (for the default C result dumper implementation)
> before printing the results of the returned expression
> (the user output continues to be untruncated, and the existence of cli.pager
> would not affect this mechanism in case the binary is not actually a pager)?
> For arrays/objects used with var_dump - the equivalent of
> `ob_start(); var_dump($result); $result = ob_get_clean();`
> would have to be used first from C since var_dump still writes to the output
> buffer (php_printf(), etc.)
var_dump() tends to be quite intensive in newline usage. I don't think
var_dump() (as is) is the best mechanism to print. At least I'd use one
property/one array argument = single line instead of two lines.
Additionally, when dumping a nested object, it's more valuable to see as much
as possible from the primary object rather than the deep nesting.
> I'd omitted output truncation from the RFC because I wasn't sure how many
> people
> would consider it excessive to include a limit on var_dump output, and there
> was little feedback before the RFC vote started.
Yeah, sorry for the late comment on that :-)
> The simplest implementation would be to truncate to a byte limit and append
> `...` if truncated,
> but the main concern that's been brought up is the approximate number of
> lines.
> Obviously, there'd be a value in truncating the output if there were to be
> megabytes of output,
> though exactly what settings make sense as a default would vary.
As mentioned a section earlier, there should be limits according to the
nesting-level … e.g. if it's the top-level value, a string may have 20 lines
printed and array and objects as well. And array entries/properties should then
be in a single line or take up to max ... 20 / count(properties or array
entries) lines (width before truncation can be determine from terminal width),
which then can be mostly in one line flattened output.
The general rule here should be, show me my object/array at hand and give me a
brief overview of what's nested within - and if I'm interested in detail, let
me (manually) output that object.
Also consider, when dumping strings within (nested) arrays/objects to replace
newlines with \n, for nicer display.
> C would not print anything (e.g. `=> `) or even call var_dump/var_export if
> the limits were set to 0.
>
Re: [PHP-DEV] [VOTE] Dump results of expressions in `php -a`
Hi Bob Weinand,
> > Am 20.01.2021 um 01:55 schrieb tyson andre :
> >
> > Hi internals,
> >
> > Voting has started on
> > https://wiki.php.net/rfc/readline_interactive_shell_result_function
> > on 2021-01-19, and ends on 2021-02-02.
> >
> > This RFC proposes to dump the results of non-null expressions using
> > var_dump/var_export() by default in `php -a` (the interactive shell).
> > Additionally, this adds a new function
> > `readline_interactive_shell_result_function` to the readline PHP module.
> > This function only affects interactive shells - it can optionally be used
> > to set or clear a closure when `extension_loaded('readline') === true`,
> > but that closure would only be called in interactive shells (i.e. php -a).
> > (That closure would be called instead of the native implementation with the
> > snippet of code that was evaluated and the expression's result,
> > if a php statement contained a single expression such as `2+2;` or `$x =
> > [1,2];` (that could be used as the expression of a return statement)
> > - Dumping of expression results can be disabled using an ini setting or at
> > runtime
> >
> > Thanks,
> > - Tyson
>
> Hey Tyson,
>
> My main concern in this iteration of the RFC is: what happens with big/deeply
> nested objects?
> They tend to spew tons of lines if var_dump()'ed. Do we have reasonable
> depth/output limitations in default dumping mode?
>
> I'm often enough using php -a to do some quick ad-hoc processing (example,
> read a big json file, and then access a value; instantiating a mediawiki bot
> framework and calling replace on it; ...).
>
> It's really cool to have any interactive feedback at all, but please, at
> least by default, limit the output. (An example is the JS REPL in browser
> console - it shows you a minimal preview of the object, and then you can
> expand with your mouse. Obviously with a pure cli application, this needs
> different - intuitive - navigation.)
>
> As it currently stands, this makes php -a unusable in any but the simplest
> cases, without just disabling the whole feature.
>
> I like the whole feature, but the missing output limitation (I have yet
> enough nightmares from var_dump()'ing the wrong object filling my shell with
> tons of irrelevant information… I don't need that potentially happening on
> every single evaluated expression)
>
> Thus I'm voting no, for now.
As-is, the entire object or string would be dumped with var_export/var_dump to
stdout.
Thoughts on the adding following output truncation mechanism
(for the default C result dumper implementation)
before printing the results of the returned expression
(the user output continues to be untruncated, and the existence of cli.pager
would not affect this mechanism in case the binary is not actually a pager)?
For arrays/objects used with var_dump - the equivalent of
`ob_start(); var_dump($result); $result = ob_get_clean();`
would have to be used first from C since var_dump still writes to the output
buffer (php_printf(), etc.)
I'd omitted output truncation from the RFC because I wasn't sure how many
people
would consider it excessive to include a limit on var_dump output, and there
was little feedback before the RFC vote started.
The simplest implementation would be to truncate to a byte limit and append
`...` if truncated,
but the main concern that's been brought up is the approximate number of lines.
Obviously, there'd be a value in truncating the output if there were to be
megabytes of output,
though exactly what settings make sense as a default would vary.
C would not print anything (e.g. `=> `) or even call var_dump/var_export if the
limits were set to 0.
```
= ASSUMED_BYTES_PER_LINE) {
$total_lines++;
$offset = ($offset - ASSUMED_BYTES_PER_LINE) %
ASSUMED_TAB_WIDTH;
}
break;
default:
$offset++;
if ($offset >= ASSUMED_BYTES_PER_LINE) {
$total_lines++;
$offset = 0;
}
break;
}
}
if ($i >= $strlen) {
return $raw_output;
}
return substr($raw_output, 0, $i) . "..."; // C appends newlines already
if there was none
}
// unmodified
var_dump(truncate_string("test short string"));
// 5000 'A's followed by "...\n"
var_dump(truncate_string(str_repeat('A', 1)));
// 100 lines containing "A" followed by "...\n"
var_dump(truncate_string(str_repeat("A\n", 1)));
```
Thanks,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Dump results of expressions in `php -a`
> Am 20.01.2021 um 01:55 schrieb tyson andre :
>
> Hi internals,
>
> Voting has started on
> https://wiki.php.net/rfc/readline_interactive_shell_result_function
> on 2021-01-19, and ends on 2021-02-02.
>
> This RFC proposes to dump the results of non-null expressions using
> var_dump/var_export() by default in `php -a` (the interactive shell).
> Additionally, this adds a new function
> `readline_interactive_shell_result_function` to the readline PHP module.
> This function only affects interactive shells - it can optionally be used to
> set or clear a closure when `extension_loaded('readline') === true`,
> but that closure would only be called in interactive shells (i.e. php -a).
> (That closure would be called instead of the native implementation with the
> snippet of code that was evaluated and the expression's result,
> if a php statement contained a single expression such as `2+2;` or `$x =
> [1,2];` (that could be used as the expression of a return statement)
> - Dumping of expression results can be disabled using an ini setting or at
> runtime
>
> Thanks,
> - Tyson
Hey Tyson,
My main concern in this iteration of the RFC is: what happens with big/deeply
nested objects?
They tend to spew tons of lines if var_dump()'ed. Do we have reasonable
depth/output limitations in default dumping mode?
I'm often enough using php -a to do some quick ad-hoc processing (example, read
a big json file, and then access a value; instantiating a mediawiki bot
framework and calling replace on it; ...).
It's really cool to have any interactive feedback at all, but please, at least
by default, limit the output. (An example is the JS REPL in browser console -
it shows you a minimal preview of the object, and then you can expand with your
mouse. Obviously with a pure cli application, this needs different - intuitive
- navigation.)
As it currently stands, this makes php -a unusable in any but the simplest
cases, without just disabling the whole feature.
I like the whole feature, but the missing output limitation (I have yet enough
nightmares from var_dump()'ing the wrong object filling my shell with tons of
irrelevant information… I don't need that potentially happening on every single
evaluated expression)
Thus I'm voting no, for now.
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Dump results of expressions in `php -a`
> On Jan 19, 2021, at 18:55, tyson andre wrote:
>
> Hi internals,
>
> Voting has started on
> https://wiki.php.net/rfc/readline_interactive_shell_result_function
> on 2021-01-19, and ends on 2021-02-02.
>
> This RFC proposes to dump the results of non-null expressions using
> var_dump/var_export() by default in `php -a` (the interactive shell).
> Additionally, this adds a new function
> `readline_interactive_shell_result_function` to the readline PHP module.
> This function only affects interactive shells - it can optionally be used to
> set or clear a closure when `extension_loaded('readline') === true`,
> but that closure would only be called in interactive shells (i.e. php -a).
> (That closure would be called instead of the native implementation with the
> snippet of code that was evaluated and the expression's result,
> if a php statement contained a single expression such as `2+2;` or `$x =
> [1,2];` (that could be used as the expression of a return statement)
> - Dumping of expression results can be disabled using an ini setting or at
> runtime
>
> Thanks,
> - Tyson
I voted “no” because I don’t think
`readline_interactive_shell_result_function()` solves a problem in a way that
is better than can be done in userland. It’s quite limited, requiring the
readline extension, and anyone who wishes to build a more complex
implementation will need to require users to add something to
`auto_prepend_file` or manually load something after dropping into interactive
mode.
I had originally thought that userland implementations might be able to make
use of this to piggyback off of `php -a`, but Justin Hileman (author of PsySH)
thinks it’s not something that would be useful to userland REPLs [^1].
> There’s still no way to do 99% of what PsySH does without a userland REPL.
> This just makes the output look similar.
I do think there’s value in improving PHP’s built-in interactive mode with
prettier dumping of expression results, but I think
`readline_interactive_shell_result_function()` will not end up being used in
practice.
Cheers,
Ben
[^1]: https://twitter.com/ramsey/status/1347661890420428802
signature.asc
Description: Message signed with OpenPGP
[PHP-DEV] [VOTE] Dump results of expressions in `php -a`
Hi internals,
Voting has started on
https://wiki.php.net/rfc/readline_interactive_shell_result_function
on 2021-01-19, and ends on 2021-02-02.
This RFC proposes to dump the results of non-null expressions using
var_dump/var_export() by default in `php -a` (the interactive shell).
Additionally, this adds a new function
`readline_interactive_shell_result_function` to the readline PHP module.
This function only affects interactive shells - it can optionally be used to
set or clear a closure when `extension_loaded('readline') === true`,
but that closure would only be called in interactive shells (i.e. php -a).
(That closure would be called instead of the native implementation with the
snippet of code that was evaluated and the expression's result,
if a php statement contained a single expression such as `2+2;` or `$x =
[1,2];` (that could be used as the expression of a return statement)
- Dumping of expression results can be disabled using an ini setting or at
runtime
Thanks,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
