Associative arrays not displayed in debugger

[Rainer Schuetze]

I just noticed that a new project still specifies a pre-2.043 D version, 
which had another associative array implementation. You should change 
the D version in the project configuration to "2.043+". I guess I should 
remove that complication completely.

Even if that is set correctly, I agree, it gets a bit messy once you 
want to drill into the keys or values themself. I have now tweaked the 
visualizer to just show key and value.


On 2/29/2012 2:19 AM, Andrew wrote:
> On Tue, 28 Feb 2012 09:16:47 +0100
> Rainer Schuetze<r.sagitario at gmx.de>  wrote:
>
>> On 26.02.2012 04:56, Andrew wrote:
>>> I'm not sure if here is the right place for this, but: I'm
>>> debugging a D program using Mago running under Visual D. It doesn't
>>> show the contents of watched associative arrays and I can't figure
>>> out how to make it do so. Google has been unhelpful.
>>>
>>> I can switch to the VS debugger and it will show the internals, but
>>> the view is...highly nonoptimal, to say the least.
>>
>> With the visualizer macros in autoexp.dat, the VS debugger shows an
>> associative array something like this:
>
> <snip>
> You're right. On second inspection it seems that it's not the array
> that's confusing the VS debugger, but its contents. They keys are
> showing up as garbage. The values are class objects for which I can
> only see the base type's members, if I expand down far enough to find
> them. That may be working as designed. I'm mostly familiar with C and
> python. C didn't have inheritance and I've never done anything complex
> enough in Python to require a debugger, so I must admit I'm unfamiliar
> with how debugger watches operate in the presence of inheritance.
>
> Given my relative inexperience with D I'm inclined to think the garbage
> keys indicate a problem with my code rather than a problem with the
> debugger. :-)
>
> Although I'd add that on my end it expands the array into indexed
> entries; each entry into some implementation details, one of which is
> "value"; and "value" expands into the actual object. That still strikes
> me as nonoptimal. array->keys->members_of_key_value would be much
> nicer.
>
> Mago suits me better in all other respects so I'll probably stick with
> that anyway.
>
> --
>
> Andrew