> <mailto:
alex@xxxxxxxxx>>> wrote:
>
> Hi Jae,
>
> One of the problems was the parsing of the property
> children nodes
> - nodeName was not checked.
> I have fixed that code.
>
> And another issue is strange numchildren values.
>
> If returns the following context names:
>
> <response xmlns="urn:debugger_protocol_v1"
> command="context_names"
> transaction_id="12">
> <context name="Locals" id="0"/>
> <context name="Globals" id="1"/>
> *
> <context name="Code Objects" id="2"/>*
>
> </response>
>
> We treat 2 as class variables, but here it is "*Code Objects"*,
> and it returns A and B with numchildren=1,
> and getObject() function with numchildren=7 (does it mean
> number
> of lines?).
>
> At the moment I have added code to fill children that were not
> retrieved from the debugger with instances of the
> UnknownVariable.
>
> I don't know what these code objects mean for the python
> developer. Probably we should handle them specially, but that
> should be configured for the python only.
>
> Regards,
> Alex
>
> Jae Gangemi wrote:
>
> hello all -
>
> i keep getting an exception thrown when the code tries to
> update the children count for python objects. i've tracked
> down the issue and it seems that for some values
> returned by
> the python engine, the children count is less than the
> available children count. the ScriptValue object's
> 'variables'
> field is initialized to be the size of
> 'property.getChildrenCount', and 'fillVariables' is
> making a
> call to getAvailableChildren and an
> ArrayOutOfBoundsException
> ends up being thrown b/c the 'variables' array ends up
> being
> too small.
>
> you can see this behavior for yourself by using the
> attached
> python script. just set a breakpoint on line 21 (myobject =
> getObject(1)) and then 'step over'.
>
> the attached patch fixes this behavior by checking to
> see if
> the 'childrenCount' of the dbgp property is less then the
> number of 'availableChildren' (instead of checking to
> see if
> it's less then 0), and if yes, then it sets the
> 'childrenCount' = availableChildren. as far as i can tell,
> this change does not seem to negatively impact any of the
> other debuggers, but perhaps there is a better solution
> for this.
>
> -- -jae
>
> ------------------------------------------------------------------------
>
>
>
> _______________________________________________
> dltk-dev mailing list
>
dltk-dev@xxxxxxxxxxx <mailto:
dltk-dev@xxxxxxxxxxx>