Array children inspection limited to 32 child elements about vdebug HOT 7 CLOSED

Completely understood! Sorry for the misunderstanding. Don't worry about bringing a support question - where else are you going to be able to get support for Vdebug anyway? :-P

You've raised a point actually - I think I need to add something to check whether the g:vdebug_features dictionary has already been initialized, so you can use:

let g:vdebug_features = { 'max_children': 128 }

At the moment that won't work if Vdebug gets loaded afterwards, as the dictionary will get overwritten. I'll make that the focus of this issue.

Cheers

from vdebug.

Yeah, I ran into this as well -- takes a long time to figure out your debugger's broken

from vdebug.

@michaelfavia thanks for the detailed information.

Yeah, I ran into this as well -- takes a long time to figure out your debugger's broken

@aaronhuckabee that's completely unhelpful. @aaronhuckabee sorry for the misunderstanding :)

Take a look at #55, as it's relevant. @derickr, the author of Xdebug, pointed out that the xdebug INI settings don't relate to the settings for the debugging connection - for that you want features. One of the features you can set is how many children you display, max_children, and you can see all the other features here.

If you upgrade to the latest version of Vdebug (1.4.0) then you can set these features easily in the g:vdebug_features dictionary in your .vimrc:

" Somewhere in your .vimrc after loading vdebug
let g:vdebug_features['max_children'] = 128

Hope that makes sense. Thanks

from vdebug.

@joonty: I actually know @aaronhuckabee and forwarded him the issue when i made it so he could follow along as he was similarly affected.

He didn't mean your (joonty) debugger is broken he meant your (his) debugger is broken because he was looking through an associative array and the keys were missing but there was no indication that it was a truncated list of the array so he didnt know it was a configuration error and assumed it was his code. He literally sat there trying to figure out where his array elements were until we finally resorted to print_r() ing them to check to see if his debugger was lying to him. ;)

I think he was just trying to confirm the issue for us. He one of the good guys. ;)

That aside: I was able to load this setting in vim and the debugger worked perfectly (WFM). Thank you for your help and sorry to bring an apparent support request to your queue.

For some reason my Spf13 instance is loading the local modification sources in the wrong order so i cant add it to my .vimrc.local or .vimrc.bundles.fork because the variables havent been defined yet and it causes errors on vim startup but thats an upstream issue i think. spf13/spf13-vim#314

Thanks again.

from vdebug.

Forgot to reference this issue in the commit name. This is fixed in commit 699ab0e

from vdebug.

(largely useless comment)
My apologies -- I didn't consider how it sounded before posting, and was only trying to add weight to the issue by confirmation.

Many thanks for the module -- I find it extremely useful.

from vdebug.

This particular example of array truncating is worth adding to FAQ - it may save time someone.
I just spent 20 minutes trying to find $_SERVER['REQUEST_URI'].

My english is too poor to add my own patch ;).

from vdebug.