Associative arrays not displayed in debugger

[Andrew]

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

[Aldo Nunez]

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.

[Rainer Schuetze]

Post by Aldo Nunez
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 :-)

[Aldo Nunez]

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").

[Andrew]

On Mon, 27 Feb 2012 15:17:49 +0000 (UTC)

Post by Aldo Nunez
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

[Rainer Schuetze]

Post by Andrew
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:
Loading Image... )

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

[Andrew]

On Tue, 28 Feb 2012 09:16:47 +0100

Post by Rainer Schuetze

Post by Andrew
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

<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

[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.

Post by Andrew
On Tue, 28 Feb 2012 09:16:47 +0100

Post by Rainer Schuetze

Post by Andrew
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

<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