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