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.

I'm don't know if this is a VD, Mago, or VS problem, and was wondering if someone here could point me in the right direction. Thanks.

--

Andrew

Mago doesn't yet support associative arrays. That's what I'm working on right now.

So far, I've checked in support for the indexing expression with basic, enum, pointer, and delegate keys. Next come the "in" expression and struct and array (including string) keys.

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:

aarray
+ [0] <key1, value1>
+ [1] <key2, value2>
+ [2] <key3, value3>
+ [3] <key4, value4>

I think this is pretty alright. (See also the tooltip shown here: http://www.dsource.org/projects/visuald/browser/wiki/debug.png )

If this does not work for you, I expect that the Visual D installer failed to patch autoexp.dat correctly.

On 27.02.2012 16:17, Aldo Nunez wrote:
> Mago doesn't yet support associative arrays. That's what I'm working on right now.
>
> So far, I've checked in support for the indexing expression with basic, enum,
> pointer, and delegate keys. Next come the "in" expression and struct and array
> (including string) keys.

Good to see you back :-)

You bring up a good point in the other post about expanding associative array (AA) variables. I'll look into the ability to show the elements of an AA as children when watching such a variable, in addition to looking up specific elements (indexing and "in").

On Mon, 27 Feb 2012 15:17:49 +0000 (UTC)
Aldo Nunez <aldonunez1@gmail.com> wrote:

> Mago doesn't yet support associative arrays. That's what I'm working on right now.

All right. Thank you for responding, and it's good to hear development is still on-going.

--

Andrew

On Tue, 28 Feb 2012 09:16:47 +0100
Rainer Schuetze <r.sagitario@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

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@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