[xdebug-general] Re: arrays in local context limited to 31 elems?

Hi Mike, some thoughts of mine based from my experience writing a debugger
gui for XDebug.

> Derick,
>
> I just received the email notice on the issue resolution
> (http://bugs.xdebug.org/bug_view_page.php?bug_id=0000327) and wanted to
> give you some additional thoughts from the user perspective.
>
> Your note in the resolution of the issue was "The defaults need to be
> different as it is a bad idea to have a depth != 1 for remote debugging,
> while it also cumbersome to deal with var_dump() displays if the depth =
> 1 there."
>
> I'd agree with the intent of your comment, but shouldn't the decision on
> the merits or detriments of returning mounds of data in a remote setting
> be left to the user vs. having the decision made for you prior to use
> implemented with what appear to be static random values? Personally I
> spent more than a few hours trying to figure out why my array depths
> were so shallow, the combination of my newness to the app coupled with
> the lack of doc on this sent me on a good goose chase for the better
> part of a day before I dug in and figured it out.

I would argue that the amount of data transfered to a remote debugger
interface
doesn't need to be defined in php.ini at all and should be fully
controllable
by the client debugger. The client debugger can take options from the user
to control the amount of data flow. I make these options available to the
user
and the values themselves don't affect being able to get all the
information
but how much data is transfered and thus cached by each user interaction.
(note that the debugclient IMHO is not meant to be used a proper client
debugger
but purely a test environment to help understand the Xdebug implementation
of
DBGp, and to verify and get information for raising bugs if things don't
seem to
behave as they should).

>
> I'd make the case that in some situations returning a gob of data to
> help debug the app is a good thing and required to chase down an issue
> when debugging. Informing the user that: 1) in remote usage these
> features are assigned different values (you've done this, but see
> below), and 2) the value in a remote debugging situation is set to N,
> and 3) there is a workaround by providing an example for how to expand
> the results in the documentation are good things.
>
> Your updated doc shows: "This setting does not have any influence on the
> number of children that is send to the client through the Remote
> Debugging feature." This seems somewhat misleading to me - it implies
> that in a remote setting there is no way to change max_children. You
> are correct in that the php.ini setting for
> xdebug.var_display_max_children is ignored in remote, however you can
> instruct xdebug via the feature_set command when interacting with the
> debugger during a debug session to change the value and it will indeed
> return a boatload of data when the setting is increased in remote
> settings to the point of overwhelming the client app.
>

To me this doesn't imply that max_children cannot be controlled
through remote debugging. It implies to me that this php.ini entry
affects only the var_display features of xdebug.

> I offer a different doc snippet for you to consider:
>
> xdebug.var_display_max_children
> Type: integer, Default value: 128*
> Controls the amount of array children and object's properties are shown
> when variables are displayed with either xdebug_var_dump(),
> xdebug.show_local_vars or through Function Traces.
> * Remote Debugging Usage: This setting is overridden to 32 in order to
> decease the amount of information being returned. To modify the value
> use 'feature_set -i <trans_id> -n max_children -v <value>'. Note: Use
> caution with increasing this value via feature_set as the amount of data
> returned might be significant and cause unexpected results.
>
>
> It would be great if the info was on the remote debugging doc page as
> well since this info is specific to remote debugging, someone focused on
> remote might miss the info if it is not on the remote page as well.

Sorry Mike, I don't think that the remote debug section needs any
reference
to xdebug.var_display_max_children. However I do think it might be good
to have more information about the xdebug specific implementation of the
DBGp
facilities. For example the default max_children, the supported encodings,
which
features are supported etc.

>
> Thanks for taking all this into consideration, I'm enjoying the program
> and my increased productivity when it's in use.
>
> Mike
>
>

Dave Kelsey

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Received on Mon Oct 29 2007 - 12:24:31 GMT