www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Visual D debugging messed up

reply IntegratedDimensions <IntegratedDimensions gmail.com> writes:
Lots of temp variables and breakpoints are not hit: says missing 
symbols but then next line works fine. Sometimes the stack trace 
doesn't work, sometimes it does. Won't break sometimes if the BP 
is the last line of a block. Everything latest version and fresh 
install and in x86 mode.
May 02 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 02/05/2018 21:56, IntegratedDimensions wrote:

 Lots of temp variables and breakpoints are not hit: says missing symbols 
 but then next line works fine. Sometimes the stack trace doesn't work, 
 sometimes it does. Won't break sometimes if the BP is the last line of a 
 block. Everything latest version and fresh install and in x86 mode.


To hide the temporaries go to Tools->Options->Debugging->Mago and enable 
"Hide compiler generated symbols".

If you are using VS2013 or later, I'd recommend selecting the "Visual 
Studio" debug engine, as this has the mago D expression evaluator 
plugged into the native VS debugger for better integration.

For stacktraces, you can sometimes end up in a system call where the 
debugger doesn't know how to walk the stack. Usually loading the symbols 
from the Microsoft symbol server helps here.

If there is some strange things happening regarding breakpoint 
positions, that's likely inaccurate debug information emitted by the 
compiler. It would be good if you could isolate examples and post them 
to bugzilla: https://issues.dlang.org/
May 06 2018
parent reply IntegratedDimensions <IntegratedDimensions gmail.com> writes:
On Monday, 7 May 2018 at 06:32:54 UTC, Rainer Schuetze wrote:

 On 02/05/2018 21:56, IntegratedDimensions wrote:

 Lots of temp variables and breakpoints are not hit: says 
 missing symbols but then next line works fine. Sometimes the 
 stack trace doesn't work, sometimes it does. Won't break 
 sometimes if the BP is the last line of a block. Everything 
 latest version and fresh install and in x86 mode.


 To hide the temporaries go to Tools->Options->Debugging->Mago 
 and enable "Hide compiler generated symbols".

 If you are using VS2013 or later, I'd recommend selecting the 
 "Visual Studio" debug engine, as this has the mago D expression 
 evaluator plugged into the native VS debugger for better 
 integration.

 For stacktraces, you can sometimes end up in a system call 
 where the debugger doesn't know how to walk the stack. Usually 
 loading the symbols from the Microsoft symbol server helps here.

 If there is some strange things happening regarding breakpoint 
 positions, that's likely inaccurate debug information emitted 
 by the compiler. It would be good if you could isolate examples 
 and post them to bugzilla: https://issues.dlang.org/


It really is messed up!

I have loops who's loop counters shown in the auto's clearly has 
the wrong values(using a local copy has the right value).

and even weirder bug! If I put a BP on a line I get missing 
symbols loaded. If I move the cursor a few pixels higher but on 
the same line I get the BP!! I know you won't believe me!!

I know! I bet! How can a few pixels matter?

I think Visual D needs a work over. Getting lots of strange bugs 
and behaviors. It's so close to being a good IDE but I struggle 
using it.

Anyways, here's the proof since you don't believe me!

Do you actually use visual D for any serious development? I ask 
that because I imagine if you did you would surely run in to 
these problems. I doubt I'm the only one.

Proof:
https://ibb.co/isnhBT


Using latest everything installed relatively fresh. Happens 
everywhere but not all lines of code behave this way or I just 
get lucky clicking most of the time. The error is no symbols have 
been loaded for the document. I do have some plugin that shrinks 
lines that empty and maybe that has something to do with 
it(shouldn't but if it does maybe there is a calculation error in 
determining the line... although that invalid BP still shows up 
on the correct line)

I have a list of complaints:


1. For loops and blocks do not break properly.

for(...) {
}
----;

putting a BP on the line ---- will break in to the for loop so 
any continuation of the debugger will hit the BP for each loop 
iteration. Easy work around but kinda a pain. Seems to be that 
lines are calculated a bit wrong in some cases(off by 1 error)... 
maybe related to the bug above.

2. Still getting temp variables, visual studio debugger shows 
less but still some.

3. Some variables are returning invalid results(this is a bigger 
problem but I can't seem to pin down why or some demo code).

Best I can tell is that I have several blocks that are basically 
copies and using the same identifiers. Maybe the debugger is 
displaying the wrong one which expired.

If I have a for loop like for(int j = 0; j < 100; j++) { auto k = 
j; }

the debugger will show j = 4324532 or something inside the loop 
similar to how it will show junk before the variable is 
initialized. k shows the correct value... so this is a display 
issue.

It might be better not to display variables when they are not in 
scope too.

4. Watch window does not work well. Some variables simply will 
not be valid.
Going to 3, putting those variables in the window also returns 
the wrong values;


5. In the watch or auto window for many types it shows odd stuff:
https://ibb.co/gXuhd8

Note the blank lines.

The blank lines show good useful values but adds additional 
lines. It might be better to consolidate the blank line with the 
line above it(the main line) which only shows the address. addr - 
info or info (addr). Usually one doesn't care about the address 
of a standard variable so it shouldn't be shown first... but
still easy to see.

6. Multiple openings of the same file. Not sure why this is 
happening but A.d will be open twice in the editor sometimes.

Maybe I will get around to making some demo program but it will 
be many weeks. Busy at the moment.

Seems like Visual D is a bit out of date with either the 
compilers or Visual Studio or maybe it is a simple but.

7. I'd really love a refactoring feature. I'm having to use 
search and replace and that is not very code smart and error 
prone.


Thanks for you time!
May 23 2018
next sibling parent reply IntegratedDimensions <IntegratedDimensions gmail.com> writes:
Another issues is that the watch/auto's are arounding doubles.

I have a value that is like 4.999953943 and it shows 5.

I'd rather see at least several digits. This is because when I 
cast it to int I get 4 and the original shows 5 and it is 
confusing where the 1 went when one expects to see higher 
precision... there is plenty of rooms to show more digits so no 
reason to round... it is a double after all but looks like an int 
in the watch window.
May 23 2018
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 23/05/2018 22:46, IntegratedDimensions wrote:

 Another issues is that the watch/auto's are arounding doubles.
 
 I have a value that is like 4.999953943 and it shows 5.
 
 I'd rather see at least several digits. This is because when I cast it 
 to int I get 4 and the original shows 5 and it is confusing where the 1 
 went when one expects to see higher precision... there is plenty of 
 rooms to show more digits so no reason to round... it is a double after 
 all but looks like an int in the watch window.


I could reproduce that with a slightly larger number of '9's. Agreed, it 
should not round. I've changed that to always show the full number of 
digits relevant for the type (float/double/real).
May 26 2018
prev sibling next sibling parent reply IntegratedDimensions <IntegratedDimensions gmail.com> writes:
Any arrays are very verbose:
https://ibb.co/gCVwO8
May 23 2018
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 24/05/2018 00:58, IntegratedDimensions wrote:

 Any arrays are very verbose:
 https://ibb.co/gCVwO8
 
 


This is an array of tuples, which are effectively structs as shown. 
Nothing wrong about arrays AFAICT, but given that the field names of 
tuples can be considered "internal", the debugger could omit their names.
May 26 2018
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 23/05/2018 19:27, IntegratedDimensions wrote:

 On Monday, 7 May 2018 at 06:32:54 UTC, Rainer Schuetze wrote:

 On 02/05/2018 21:56, IntegratedDimensions wrote:

 Lots of temp variables and breakpoints are not hit: says missing 
 symbols but then next line works fine. Sometimes the stack trace 
 doesn't work, sometimes it does. Won't break sometimes if the BP is 
 the last line of a block. Everything latest version and fresh install 
 and in x86 mode.


 To hide the temporaries go to Tools->Options->Debugging->Mago and 
 enable "Hide compiler generated symbols".

 If you are using VS2013 or later, I'd recommend selecting the "Visual 
 Studio" debug engine, as this has the mago D expression evaluator 
 plugged into the native VS debugger for better integration.

 For stacktraces, you can sometimes end up in a system call where the 
 debugger doesn't know how to walk the stack. Usually loading the 
 symbols from the Microsoft symbol server helps here.

 If there is some strange things happening regarding breakpoint 
 positions, that's likely inaccurate debug information emitted by the 
 compiler. It would be good if you could isolate examples and post them 
 to bugzilla: https://issues.dlang.org/


 
 It really is messed up!


There are a number of variables that affect the debug experience, e.g. 
VS version, compiler dmd/LDC, compiler version options used, debug 
engine used. See http://rainers.github.io/visuald/visuald/Debugging.html 
for some information about that. Best to provide information what you 
are using.

I assume you are using what is currently assumed best: VS2015+ with dmd 
2.077+, VS debug engine with debug info suitable for mago.

You can also add -gf to the command line, next version of Visual D will 
have that as a project option, too.

In this mode, the mago extension for D just enumerates locals and 
evaluates expressions, everything else is the same as the C++ debugger 
including breakpoint handling.


 
 I have loops who's loop counters shown in the auto's clearly has the 
 wrong values(using a local copy has the right value).



 and even weirder bug! If I put a BP on a line I get missing symbols 
 loaded. If I move the cursor a few pixels higher but on the same line I 
 get the BP!! I know you won't believe me!!
 
 I know! I bet! How can a few pixels matter?
 
 I think Visual D needs a work over. Getting lots of strange bugs and 
 behaviors. It's so close to being a good IDE but I struggle using it.
 
 Anyways, here's the proof since you don't believe me!
 
 Do you actually use visual D for any serious development? I ask that 
 because I imagine if you did you would surely run in to these problems. 
 I doubt I'm the only one.
 


Nothing serious, but mostly Visual D itself and dmd.


 Proof:
 https://ibb.co/isnhBT
 
 
 Using latest everything installed relatively fresh. Happens everywhere 
 but not all lines of code behave this way or I just get lucky clicking 
 most of the time. The error is no symbols have been loaded for the 
 document. I do have some plugin that shrinks lines that empty and maybe 
 that has something to do with it(shouldn't but if it does maybe there is 
 a calculation error in determining the line... although that invalid BP 
 still shows up on the correct line)


I've never seen something like this. I suspect it is caused by your 
additional plugin. That's not functionality covered by any of the D 
specific extensions, you will have the same issues in C++.


 
 I have a list of complaints:
 
 
 1. For loops and blocks do not break properly.
 
 for(...) {
 }
 ----;
 
 putting a BP on the line ---- will break in to the for loop so any 
 continuation of the debugger will hit the BP for each loop iteration. 
 Easy work around but kinda a pain. Seems to be that lines are calculated 
 a bit wrong in some cases(off by 1 error)... maybe related to the bug 
 above.


That very much depends on the debug info generated by the compiler. It's 
a bit problematic without braces (can happen with C++ aswell), but 
AFAICT it should work with braces. Can you provide a complete example?


 2. Still getting temp variables, visual studio debugger shows less but 
 still some.


You mean variables that start with a double underscore? Can you show an 
example?


 3. Some variables are returning invalid results(this is a bigger problem 
 but I can't seem to pin down why or some demo code).
 
 Best I can tell is that I have several blocks that are basically copies 
 and using the same identifiers. Maybe the debugger is displaying the 
 wrong one which expired.
 
 If I have a for loop like for(int j = 0; j < 100; j++) { auto k = j; }
 
 the debugger will show j = 4324532 or something inside the loop similar 
 to how it will show junk before the variable is initialized. k shows the 
 correct value... so this is a display issue.
 
 It might be better not to display variables when they are not in scope too.


Using the same variable name multiple times is problematic. The debug 
info emitted by dmd should specify the scope of the variables, but if it 
fails there is nothing the debugger can do to find the correct one. Do 
you see the same variable listed multiple times in the locals window?


 
 4. Watch window does not work well. Some variables simply will not be 
 valid.
 Going to 3, putting those variables in the window also returns the wrong 
 values;
 


Global variables have to be specified fully qualified.


 
 5. In the watch or auto window for many types it shows odd stuff:
 https://ibb.co/gXuhd8
 
 Note the blank lines.
 
 The blank lines show good useful values but adds additional lines. It 
 might be better to consolidate the blank line with the line above it(the 
 main line) which only shows the address. addr - info or info (addr). 
 Usually one doesn't care about the address of a standard variable so it 
 shouldn't be shown first... but
 still easy to see.


I agree, the additional line can be annoying, but it is also sometimes 
useful, e.g. with a pointer to a string, you don't want to expand the 
array of characters immediately.


 6. Multiple openings of the same file. Not sure why this is happening 
 but A.d will be open twice in the editor sometimes.


I think I've seen this, too, but AFAICT this happens with C++ too. I 
suspect it is because the same file is opened using different paths, 
e.g. with some relative path elements inside.


 Maybe I will get around to making some demo program but it will be many 
 weeks. Busy at the moment.
 
 Seems like Visual D is a bit out of date with either the compilers or 
 Visual Studio or maybe it is a simple but.
 
 7. I'd really love a refactoring feature. I'm having to use search and 
 replace and that is not very code smart and error prone.
 


We can think about it once we have a reliable semantic engine. 
Unfortunately that's not so easy.
May 26 2018
parent reply IntegratedDimensions <IntegratedDimensions gmail.com> writes:
On Saturday, 26 May 2018 at 07:16:01 UTC, Rainer Schuetze wrote:

 On 23/05/2018 19:27, IntegratedDimensions wrote:

 On Monday, 7 May 2018 at 06:32:54 UTC, Rainer Schuetze wrote:

 On 02/05/2018 21:56, IntegratedDimensions wrote:

 Lots of temp variables and breakpoints are not hit: says 
 missing symbols but then next line works fine. Sometimes the 
 stack trace doesn't work, sometimes it does. Won't break 
 sometimes if the BP is the last line of a block. Everything 
 latest version and fresh install and in x86 mode.


 To hide the temporaries go to Tools->Options->Debugging->Mago 
 and enable "Hide compiler generated symbols".

 If you are using VS2013 or later, I'd recommend selecting the 
 "Visual Studio" debug engine, as this has the mago D 
 expression evaluator plugged into the native VS debugger for 
 better integration.

 For stacktraces, you can sometimes end up in a system call 
 where the debugger doesn't know how to walk the stack. 
 Usually loading the symbols from the Microsoft symbol server 
 helps here.

 If there is some strange things happening regarding 
 breakpoint positions, that's likely inaccurate debug 
 information emitted by the compiler. It would be good if you 
 could isolate examples and post them to bugzilla: 
 https://issues.dlang.org/


 
 It really is messed up!


 There are a number of variables that affect the debug 
 experience, e.g. VS version, compiler dmd/LDC, compiler version 
 options used, debug engine used. See 
 http://rainers.github.io/visuald/visuald/Debugging.html for 
 some information about that. Best to provide information what 
 you are using.

 I assume you are using what is currently assumed best: VS2015+ 
 with dmd 2.077+, VS debug engine with debug info suitable for 
 mago.


yes.


 You can also add -gf to the command line, next version of 
 Visual D will have that as a project option, too.

 In this mode, the mago extension for D just enumerates locals 
 and evaluates expressions, everything else is the same as the 
 C++ debugger including breakpoint handling.


 
 I have loops who's loop counters shown in the auto's clearly 
 has the wrong values(using a local copy has the right value).



 and even weirder bug! If I put a BP on a line I get missing 
 symbols loaded. If I move the cursor a few pixels higher but 
 on the same line I get the BP!! I know you won't believe me!!
 
 I know! I bet! How can a few pixels matter?
 
 I think Visual D needs a work over. Getting lots of strange 
 bugs and behaviors. It's so close to being a good IDE but I 
 struggle using it.
 
 Anyways, here's the proof since you don't believe me!
 
 Do you actually use visual D for any serious development? I 
 ask that because I imagine if you did you would surely run in 
 to these problems. I doubt I'm the only one.
 


 Nothing serious, but mostly Visual D itself and dmd.


I'm sure you don't have the time but it might be a good idea to 
create a long term project where you develop(maybe something 
you've always wanted to do) where you spend a few minutes a week 
on. As you progress in the project and it becomes more complex 
you will probably run in to many bugs and ideas. Since you know 
the most about the extension it would be easiest for you to do 
the fixes. Just a suggestion, I'm sure you've got better things 
to do and I appreciate your work on VD, it can just be a bit 
annoying since I am use to the VS side of things which behave a 
bit better. If VD wasn't close to emulating them it wouldn't be 
as much a problem... expectations I guess... ;)


 Proof:
 https://ibb.co/isnhBT
 
 
 Using latest everything installed relatively fresh. Happens 
 everywhere but not all lines of code behave this way or I just 
 get lucky clicking most of the time. The error is no symbols 
 have been loaded for the document. I do have some plugin that 
 shrinks lines that empty and maybe that has something to do 
 with it(shouldn't but if it does maybe there is a calculation 
 error in determining the line... although that invalid BP 
 still shows up on the correct line)


 I've never seen something like this. I suspect it is caused by 
 your additional plugin. That's not functionality covered by any 
 of the D specific extensions, you will have the same issues in 
 C++.


I disabled the plugin and could not reproduce the issues. Today 
It happened! Exactly the same behavior.

So, unless this is a VS issue, it is a VD issue.

Note that it pops up an error box that says no symbols have been 
loaded for this document but also gives the document name and 
line number except it says character 1...

So this is getting in to VD I imagine.

I mean, VD surely has to inform VS that the BP on a line is 
valid? If so then that code must be buggy. Just putting a bunch 
of breakpoints on a document will eventually give that bug... 
although, the plugin I used seemed to exacerbate the problem.

I have other problems with the BP's.

If I am debugging and remove a BP, sometimes it reappears after 
stopping the debugger. I have to restart VS for normal behavior 
to come back. Seems to apply to all BP's.

Also, sometimes BP's do not show or show up depending on if 
actively debugging or not.


of things so I imagine it is a VD issue. Probably some simple bug 
or two in the BP code.



 
 I have a list of complaints:
 
 
 1. For loops and blocks do not break properly.
 
 for(...) {
 }
 ----;
 
 putting a BP on the line ---- will break in to the for loop so 
 any continuation of the debugger will hit the BP for each loop 
 iteration. Easy work around but kinda a pain. Seems to be that 
 lines are calculated a bit wrong in some cases(off by 1 
 error)... maybe related to the bug above.


 That very much depends on the debug info generated by the 
 compiler. It's a bit problematic without braces (can happen 
 with C++ aswell), but AFAICT it should work with braces. Can 
 you provide a complete example?


I can't seem to get a simple example to work. It might have been 
solved or related to the BP issue.


 2. Still getting temp variables, visual studio debugger shows 
 less but still some.


 You mean variables that start with a double underscore? Can you 
 show an example?


It would just be a picture. I'm looking at it right now

_TMP1922
_TMP1923
_TMP1924

all longs with very large values, looks random. These are 
probably the 3 nested loops I have.



 3. Some variables are returning invalid results(this is a 
 bigger problem but I can't seem to pin down why or some demo 
 code).
 
 Best I can tell is that I have several blocks that are 
 basically copies and using the same identifiers. Maybe the 
 debugger is displaying the wrong one which expired.
 
 If I have a for loop like for(int j = 0; j < 100; j++) { auto 
 k = j; }
 
 the debugger will show j = 4324532 or something inside the 
 loop similar to how it will show junk before the variable is 
 initialized. k shows the correct value... so this is a display 
 issue.
 
 It might be better not to display variables when they are not 
 in scope too.


 Using the same variable name multiple times is problematic. The 
 debug info emitted by dmd should specify the scope of the 
 variables, but if it fails there is nothing the debugger can do 
 to find the correct one. Do you see the same variable listed 
 multiple times in the locals window?


No, but I have see that in the past.


 
 4. Watch window does not work well. Some variables simply will 
 not be valid.
 Going to 3, putting those variables in the window also returns 
 the wrong values;
 


 Global variables have to be specified fully qualified.


But these are local to the current executing code. This maybe 
related to the BP bug.


 
 5. In the watch or auto window for many types it shows odd 
 stuff:
 https://ibb.co/gXuhd8
 
 Note the blank lines.
 
 The blank lines show good useful values but adds additional 
 lines. It might be better to consolidate the blank line with 
 the line above it(the main line) which only shows the address. 
 addr - info or info (addr). Usually one doesn't care about the 
 address of a standard variable so it shouldn't be shown 
 first... but
 still easy to see.


 I agree, the additional line can be annoying, but it is also 
 sometimes useful, e.g. with a pointer to a string, you don't 
 want to expand the array of characters immediately.


Usually it is useless double indirection making one click twice 
to open. Since the debugger doesn't remember expanded variables 
between runs it can require expanding objects many times just to 
see whats going on.


 6. Multiple openings of the same file. Not sure why this is 
 happening but A.d will be open twice in the editor sometimes.


 I think I've seen this, too, but AFAICT this happens with C++ 
 too. I suspect it is because the same file is opened using 
 different paths, e.g. with some relative path elements inside.


 Maybe I will get around to making some demo program but it 
 will be many weeks. Busy at the moment.
 
 Seems like Visual D is a bit out of date with either the 
 compilers or Visual Studio or maybe it is a simple but.
 
 7. I'd really love a refactoring feature. I'm having to use 
 search and replace and that is not very code smart and error 
 prone.
 


 We can think about it once we have a reliable semantic engine. 
 Unfortunately that's not so easy.
Jun 01 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 01/06/2018 09:00, IntegratedDimensions wrote:

 I've never seen something like this. I suspect it is caused by your 
 additional plugin. That's not functionality covered by any of the D 
 specific extensions, you will have the same issues in C++.


 
 I disabled the plugin and could not reproduce the issues. Today It 
 happened! Exactly the same behavior.
 
 So, unless this is a VS issue, it is a VD issue.
 
 Note that it pops up an error box that says no symbols have been loaded 
 for this document but also gives the document name and line number 
 except it says character 1...
 
 So this is getting in to VD I imagine.
 
 I mean, VD surely has to inform VS that the BP on a line is valid? If so 
 then that code must be buggy. Just putting a bunch of breakpoints on a 
 document will eventually give that bug... although, the plugin I used 
 seemed to exacerbate the problem.
 
 I have other problems with the BP's.
 
 If I am debugging and remove a BP, sometimes it reappears after stopping 
 the debugger. I have to restart VS for normal behavior to come back. 
 Seems to apply to all BP's.
 
 Also, sometimes BP's do not show or show up depending on if actively 
 debugging or not.
 

 things so I imagine it is a VD issue. Probably some simple bug or two in 
 the BP code.


This is the only interface implemented by the debugger plugin: 
https://docs.microsoft.com/en-us/dotnet/api/microsoft.visualstudio.debugger.componentinterfaces.idkmlanguageexpressionevaluator?view=visualstudiosdk-2017

Breakpoints are handled by the VS debugger reading the PDB file. You 
might want to blame the compiler for not emitting exact line number 
infos, though.


 You mean variables that start with a double underscore? Can you show 
 an example?


 It would just be a picture. I'm looking at it right now
 
 _TMP1922
 _TMP1923
 _TMP1924
 
 all longs with very large values, looks random. These are probably the 3 
 nested loops I have.


The compiler should have used double underscores here (these are 
reserved for the compiler), otherwise the symbols might clash with user 
symbols.


 
 

 3. Some variables are returning invalid results(this is a bigger 
 problem but I can't seem to pin down why or some demo code).

 Best I can tell is that I have several blocks that are basically 
 copies and using the same identifiers. Maybe the debugger is 
 displaying the wrong one which expired.

 If I have a for loop like for(int j = 0; j < 100; j++) { auto k = j; }

 the debugger will show j = 4324532 or something inside the loop 
 similar to how it will show junk before the variable is initialized. 
 k shows the correct value... so this is a display issue.

 It might be better not to display variables when they are not in 
 scope too.


 Using the same variable name multiple times is problematic. The debug 
 info emitted by dmd should specify the scope of the variables, but if 
 it fails there is nothing the debugger can do to find the correct one. 
 Do you see the same variable listed multiple times in the locals window?


 
 No, but I have see that in the past.


Should be fixed since dmd 2.072.


 4. Watch window does not work well. Some variables simply will not be 
 valid.
 Going to 3, putting those variables in the window also returns the 
 wrong values;


 Global variables have to be specified fully qualified.


 
 But these are local to the current executing code. This maybe related to 
 the BP bug.
 

 5. In the watch or auto window for many types it shows odd stuff:
 https://ibb.co/gXuhd8

 Note the blank lines.

 The blank lines show good useful values but adds additional lines. It 
 might be better to consolidate the blank line with the line above 
 it(the main line) which only shows the address. addr - info or info 
 (addr). Usually one doesn't care about the address of a standard 
 variable so it shouldn't be shown first... but
 still easy to see.


 I agree, the additional line can be annoying, but it is also sometimes 
 useful, e.g. with a pointer to a string, you don't want to expand the 
 array of characters immediately.


 
 Usually it is useless double indirection making one click twice to open. 
 Since the debugger doesn't remember expanded variables between runs it 
 can require expanding objects many times just to see whats going on.
 


I guess the additional line can be removed if the pointer also shows the 
abbreviated display value of the pointee (C++ does this, too).
Jun 02 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 02/06/2018 10:21, Rainer Schuetze wrote:

 Usually it is useless double indirection making one click twice to 
 open. Since the debugger doesn't remember expanded variables between 
 runs it can require expanding objects many times just to see whats 
 going on.


 
 I guess the additional line can be removed if the pointer also shows the 
 abbreviated display value of the pointee (C++ does this, too).


I've added that, you can try a preliminary build from 
https://ci.appveyor.com/project/rainers/visuald/build/job/2r28sjagvc29281d/artifacts
Jun 02 2018
parent reply DigitalDesigns <DigitalDesigns gmail.com> writes:
On Saturday, 2 June 2018 at 12:47:23 UTC, Rainer Schuetze wrote:

 On 02/06/2018 10:21, Rainer Schuetze wrote:

 Usually it is useless double indirection making one click 
 twice to open. Since the debugger doesn't remember expanded 
 variables between runs it can require expanding objects many 
 times just to see whats going on.


 
 I guess the additional line can be removed if the pointer also 
 shows the abbreviated display value of the pointee (C++ does 
 this, too).


 I've added that, you can try a preliminary build from 
 https://ci.appveyor.com/project/rainers/visuald/build/job/2r28sjagvc29281d/artifacts


I'd like to make a similar request if you don't mind:

When using nested functions, only the types local to the function 
are shown in the locals. It would be nice if higher up variables 
would be shown. There is a this pointer but the value is invalid.

void foo(int x)
{
    int y;
    void bar(int z)
    {
      int c;
    }
}

When debugging bar all I see is c and z but not x and y. This 
would work for all nested functions which are functions that have 
a "this pointer". foo itself might be nested.
Jun 02 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 03/06/2018 03:14, DigitalDesigns wrote:

 I'd like to make a similar request if you don't mind:
 
 When using nested functions, only the types local to the function are 
 shown in the locals. It would be nice if higher up variables would be 
 shown. There is a this pointer but the value is invalid.
 
 void foo(int x)
 {
     int y;
     void bar(int z)
     {
       int c;
     }
 }
 
 When debugging bar all I see is c and z but not x and y. This would work 
 for all nested functions which are functions that have a "this pointer". 
 foo itself might be nested.
 


Unfortunately, no debug information is emitted by dmd for the function 
closure. LDC works better in that regard.
Jun 03 2018
next sibling parent reply DigitalDesigns <DigitalDesigns gmail.com> writes:
On Sunday, 3 June 2018 at 07:03:08 UTC, Rainer Schuetze wrote:

 On 03/06/2018 03:14, DigitalDesigns wrote:

 I'd like to make a similar request if you don't mind:
 
 When using nested functions, only the types local to the 
 function are shown in the locals. It would be nice if higher 
 up variables would be shown. There is a this pointer but the 
 value is invalid.
 
 void foo(int x)
 {
     int y;
     void bar(int z)
     {
       int c;
     }
 }
 
 When debugging bar all I see is c and z but not x and y. This 
 would work for all nested functions which are functions that 
 have a "this pointer". foo itself might be nested.
 


 Unfortunately, no debug information is emitted by dmd for the 
 function closure. LDC works better in that regard.


Could a stack trace not work? It might require some slueth work 
but if one can determine that the function was nested then one 
knows the the caller was the parent function... then backtrack 
and get the locals of that function. Would be tricky to be able 
to do it precisely.
Jun 11 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 11/06/2018 09:04, DigitalDesigns wrote:

 On Sunday, 3 June 2018 at 07:03:08 UTC, Rainer Schuetze wrote:

 On 03/06/2018 03:14, DigitalDesigns wrote:

 I'd like to make a similar request if you don't mind:

 When using nested functions, only the types local to the function are 
 shown in the locals. It would be nice if higher up variables would be 
 shown. There is a this pointer but the value is invalid.

 void foo(int x)
 {
     int y;
     void bar(int z)
     {
       int c;
     }
 }

 When debugging bar all I see is c and z but not x and y. This would 
 work for all nested functions which are functions that have a "this 
 pointer". foo itself might be nested.


 Unfortunately, no debug information is emitted by dmd for the function 
 closure. LDC works better in that regard.


 
 Could a stack trace not work? It might require some slueth work but if 
 one can determine that the function was nested then one knows the the 
 caller was the parent function... then backtrack and get the locals of 
 that function. Would be tricky to be able to do it precisely.


Looking at the stack might work in some cases, but the closure can be 
allocated on the heap, too. dmd should just emit that information as LDC 
and GDC do.
Jun 11 2018
parent reply DigitalDesigns <DigitalDesigns gmail.com> writes:
On Monday, 11 June 2018 at 17:50:42 UTC, Rainer Schuetze wrote:

 On 11/06/2018 09:04, DigitalDesigns wrote:

 On Sunday, 3 June 2018 at 07:03:08 UTC, Rainer Schuetze wrote:

 On 03/06/2018 03:14, DigitalDesigns wrote:

 I'd like to make a similar request if you don't mind:

 When using nested functions, only the types local to the 
 function are shown in the locals. It would be nice if higher 
 up variables would be shown. There is a this pointer but the 
 value is invalid.

 void foo(int x)
 {
     int y;
     void bar(int z)
     {
       int c;
     }
 }

 When debugging bar all I see is c and z but not x and y. 
 This would work for all nested functions which are functions 
 that have a "this pointer". foo itself might be nested.


 Unfortunately, no debug information is emitted by dmd for the 
 function closure. LDC works better in that regard.


 
 Could a stack trace not work? It might require some slueth 
 work but if one can determine that the function was nested 
 then one knows the the caller was the parent function... then 
 backtrack and get the locals of that function. Would be tricky 
 to be able to do it precisely.


 Looking at the stack might work in some cases, but the closure 
 can be allocated on the heap, too. dmd should just emit that 
 information as LDC and GDC do.



Well, for locally called nested functions it should work. The 
callee is the parent function. I can only see a problem when the 
nested function is passed around and called somewhere else. If 
there were a way to tell for sure which case one was in, then it 
would work.

Maybe a better way is to show special "super" variable which 
holds the closure of the caller.

The idea is this: For any function call, capture the "closure" of 
the current scope(you have this because all the locals and auto 
are shown from this scope right before the call). Now, once 
inside the call this "super" just shows the history of the 
caller's closure.

Basically what happens now is when a function is about to be 
called, the current state is shown. When the function is called, 
the current state is shown for the called function but the 
previous one is completely lost.

Simply "remember" the previous state and show it in a special 
variable so one can access the data.

See, the problem with the following code is:

auto foo(int i)
{
    auto bar() { return i + 4; }
    return bar + 5;
}

Putting a BP on the first return statement hides i! There is no 
way to evaluate what i is without creating a temporary local, 
which is a pain just to see i.

Instead, the compiler, before it called bar, simply keeps track 
of the data(it has the addresses, names, types, etc) and show it 
somewhere in the debug window(I'd suggest an expandable variable 
like __super__).

It would then be easy to make it recursive so that __super__ 
contains __super__, the function that called the function that 
called the current function.

This is sort of like a stack trace and might be easy to implement 
since it is just tracking data that it already has. The problem 
is the stack doesn't always show the logical nesting. Not sure if 
visual D can figure it out (determine if a function is about to 
be called/entered to get information).

In fact, a stack trace sorta already does this as one can go back 
in time and look at variables. So, maybe just showing the 
previous function info would be the best way.


--------------------------------

Not sure if visual D can do this but sometimes when I do 
computations on a function call: foo(i + x, "43"~tmp); I have to 
create a temp variable so I can see the result. This is time 
consuming.

It would be cool if visual D showed the results of either the 
current function call(the parent, which means I just have to step 
in the line) or the function call at the current line.

could have, in the autos, something like

arg1 = 5
arg2 = 43df34saa



Thanks, just suggestions of course. Getting the interfaces to 
show information was a tremendous help!
Jun 11 2018
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 12/06/2018 08:38, DigitalDesigns wrote:

 On Monday, 11 June 2018 at 17:50:42 UTC, Rainer Schuetze wrote:

 On 11/06/2018 09:04, DigitalDesigns wrote:

 On Sunday, 3 June 2018 at 07:03:08 UTC, Rainer Schuetze wrote:

 On 03/06/2018 03:14, DigitalDesigns wrote:

 I'd like to make a similar request if you don't mind:

 When using nested functions, only the types local to the function 
 are shown in the locals. It would be nice if higher up variables 
 would be shown. There is a this pointer but the value is invalid.

 void foo(int x)
 {
     int y;
     void bar(int z)
     {
       int c;
     }
 }

 When debugging bar all I see is c and z but not x and y. This would 
 work for all nested functions which are functions that have a "this 
 pointer". foo itself might be nested.


 Unfortunately, no debug information is emitted by dmd for the 
 function closure. LDC works better in that regard.


 Could a stack trace not work? It might require some slueth work but 
 if one can determine that the function was nested then one knows the 
 the caller was the parent function... then backtrack and get the 
 locals of that function. Would be tricky to be able to do it precisely.


 Looking at the stack might work in some cases, but the closure can be 
 allocated on the heap, too. dmd should just emit that information as 
 LDC and GDC do.


 
 
 Well, for locally called nested functions it should work. The callee is 
 the parent function. I can only see a problem when the nested function 
 is passed around and called somewhere else. If there were a way to tell 
 for sure which case one was in, then it would work.
 
 Maybe a better way is to show special "super" variable which holds the 
 closure of the caller.
 
 The idea is this: For any function call, capture the "closure" of the 
 current scope(you have this because all the locals and auto are shown 
 from this scope right before the call). Now, once inside the call this 
 "super" just shows the history of the caller's closure.
 
 Basically what happens now is when a function is about to be called, the 
 current state is shown. When the function is called, the current state 
 is shown for the called function but the previous one is completely lost.
 
 Simply "remember" the previous state and show it in a special variable 
 so one can access the data.
 
 See, the problem with the following code is:
 
 auto foo(int i)
 {
     auto bar() { return i + 4; }
     return bar + 5;
 }
 
 Putting a BP on the first return statement hides i! There is no way to 
 evaluate what i is without creating a temporary local, which is a pain 
 just to see i.
 
 Instead, the compiler, before it called bar, simply keeps track of the 
 data(it has the addresses, names, types, etc) and show it somewhere in 
 the debug window(I'd suggest an expandable variable like __super__).
 
 It would then be easy to make it recursive so that __super__ contains 
 __super__, the function that called the function that called the current 
 function.
 
 This is sort of like a stack trace and might be easy to implement since 
 it is just tracking data that it already has. The problem is the stack 
 doesn't always show the logical nesting. Not sure if visual D can figure 
 it out (determine if a function is about to be called/entered to get 
 information).
 
 In fact, a stack trace sorta already does this as one can go back in 
 time and look at variables. So, maybe just showing the previous function 
 info would be the best way.


Sorry for the delay. I think it's more accurate and way easier to just 
make the compiler add the necessary debug information.


 
 
 --------------------------------
 
 Not sure if visual D can do this but sometimes when I do computations on 
 a function call: foo(i + x, "43"~tmp); I have to create a temp variable 
 so I can see the result. This is time consuming.


For most expressions, you can just select the expression and hover over 
it with the mouse: the tooltip will show the result (but doesn't work 
for string concatenations, for example).


 It would be cool if visual D showed the results of either the current 
 function call(the parent, which means I just have to step in the line) 
 or the function call at the current line.
 
 could have, in the autos, something like
 
 arg1 = 5
 arg2 = 43df34saa


C++ also shows the results of invoked functions, that would be nice to 
have. Not sure how it's done, though.

Last release allows executing functions without arguments in the watch 
window (mostly Win64 only due to ABI issues). Beware of side effects, 
the debugger doesn't know if the function is pure or not.
Jun 30 2018
prev sibling parent reply DigitalDesigns <DigitalDesigns gmail.com> writes:
Thanks for the work on the interfaces. Immediate improvement! 
That __vptr is a little funky too see. Future suggestion if you 
think it's worth your time: Try to replace the __vptr values with 
the actual names. This would be, I think, having to reverse those 
pointer values and try to match them with the programs function 
names. Knowing that they come from the interface would be easy to 
pin point them. If it's not too hard you would give the name and 
the function signature so one knows what virtual methods it has. 
Probably not a big deal, but having to see addresses scares me... 
they change every time the program runs ;)
Jun 11 2018
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 11/06/2018 09:11, DigitalDesigns wrote:

 Thanks for the work on the interfaces. Immediate improvement! That 
 __vptr is a little funky too see. Future suggestion if you think it's 
 worth your time: Try to replace the __vptr values with the actual names. 
 This would be, I think, having to reverse those pointer values and try 
 to match them with the programs function names. Knowing that they come 
 from the interface would be easy to pin point them. If it's not too hard 
 you would give the name and the function signature so one knows what 
 virtual methods it has. Probably not a big deal, but having to see 
 addresses scares me... they change every time the program runs ;)


That already works for class vtables, but unfortunately not for 
interfaces. The shown address is to some thunk that subtracts the 
interface offset in the instance and forwards to the actual method, but 
the thunk has no symbol name attached.

You can disable the display of the vtable in the mago options.
Jun 11 2018