• Eppason (2/2) Jul 14 2016 I have private static fields that visual D is not allowing me to
• Rainer Schuetze (20/22) Jul 14 2016 You have to specify the fully qualified name including module name in
• Eppason (8/32) Jul 15 2016 Is this not considered a bug? What about for the complex template
• Rainer Schuetze (9/46) Jul 15 2016 I agree it can be troublesome, especially with template classes or

Eppason <Epp son.com> writes:

I have private static fields that visual D is not allowing me to 
see while debugging. I am flying blind, does not feel good!!

Rainer Schuetze <r.sagitario gmx.de> writes:

On 15.07.2016 02:53, Eppason wrote:
 I have private static fields that visual D is not allowing me to see
 while debugging. I am flying blind, does not feel good!!

You have to specify the fully qualified name including module name in 
the watch window, i.e.

module test;

struct S
{
	int foo()
	{
		return xyz;
	}
	static int xyz = 7;
}

int main()
{
	S s;
	return s.foo();
}

Depending on the debug engine used, watching S.xyz needs "test.S.xyz" in 
mago and "test S xyz" with the VS engines. Mago has some extra code to 
allow watching "xyz" when executing S.foo.

Eppason <Epp son.com> writes:

On Friday, 15 July 2016 at 06:33:54 UTC, Rainer Schuetze wrote:
 On 15.07.2016 02:53, Eppason wrote:
 I have private static fields that visual D is not allowing me 
 to see
 while debugging. I am flying blind, does not feel good!!

 You have to specify the fully qualified name including module 
 name in the watch window, i.e.

 module test;

 struct S
 {
 	int foo()
 	{
 		return xyz;
 	}
 	static int xyz = 7;
 }

 int main()
 {
 	S s;
 	return s.foo();
 }

 Depending on the debug engine used, watching S.xyz needs 
 "test.S.xyz" in mago and "test S xyz" with the VS engines. Mago 
 has some extra code to allow watching "xyz" when executing 
 S.foo.

Is this not considered a bug? What about for the complex template 
types like

module library.configrators;
struct PostHardThunk(Test, Actuator).


Do I really have to type all that stuff out just to get a watch?

Should the debugger not get the current module and type the 
cursor is at and use them as defaults?

Rainer Schuetze <r.sagitario gmx.de> writes:

On 15.07.2016 09:55, Eppason wrote:
 On Friday, 15 July 2016 at 06:33:54 UTC, Rainer Schuetze wrote:
 On 15.07.2016 02:53, Eppason wrote:
 I have private static fields that visual D is not allowing me to see
 while debugging. I am flying blind, does not feel good!!

 You have to specify the fully qualified name including module name in
 the watch window, i.e.

 module test;

 struct S
 {
     int foo()
     {
         return xyz;
     }
     static int xyz = 7;
 }

 int main()
 {
     S s;
     return s.foo();
 }

 Depending on the debug engine used, watching S.xyz needs "test.S.xyz"
 in mago and "test S xyz" with the VS engines. Mago has some extra code
 to allow watching "xyz" when executing S.foo.

 Is this not considered a bug? What about for the complex template types
 like

 module library.configrators;
 struct PostHardThunk(Test, Actuator).


 Do I really have to type all that stuff out just to get a watch?

 Should the debugger not get the current module and type the cursor is at
 and use them as defaults?


I agree it can be troublesome, especially with template classes or 
structs. The problem is that the compiler does not emit symbol lookup 
information in the debug information. I think we'll have to add these at 
some point.

What I do sometimes is to look at the disassembly of an access to the 
global/static variable and drag the shown symbol into the watch window. 
Unfortunately, this does not work with thread local variables, because 
these are just relative offsets.