www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Visual D Debugger "complaints" (Mago?)

reply Joerg Joergonson <JJoergonson gmail.com> writes:
It is pretty hard to visual D's debugger because it is not very 
helpful.

1. It generally shows memory addresses for objects. Doesn't do me 
much good. Would be nice to first try a toString() or display the 
type name.

2. Objects are not shown as they are but their base class types. 
This tends to leave a lot of info out of the display.

3. Cannot do a refactored type of renaming. Have to use 
search/replace which isn't great.

4. Cannot execute commands in the debugger watch such as 
cast(toChild)x; (see 2)

5. Enums are not shown by name. Do I really have to memorize all 
the values?

6. A lot of junk information that takes up space. e.g., strings 
show "length=0x00000084". would be better to minimize to 84 and 
show by name: e.g., "This is 84 chars long?"(84)

7. Line stepping can be weird because sometimes the current line 
will jump to random places then jump back when stepping again. 
This is probably a bug.


I assume this is due to the mago debugger rather than Visual D 
but not sure(except the renaming ability).
Jun 15 2016
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 16.06.2016 02:20, Joerg Joergonson wrote:
 It is pretty hard to visual D's debugger because it is not very helpful.

 1. It generally shows memory addresses for objects. Doesn't do me much
 good. Would be nice to first try a toString() or display the type name.
I guess you are coming from C# where displaying the result of toString is more common. The C++ debugger never does this as executing code can be harmful. I've added showing the derived type as in C++ just a couple of days ago.
 2. Objects are not shown as they are but their base class types. This
 tends to leave a lot of info out of the display.
The new version also allows inspecting the derived class.
 3. Cannot do a refactored type of renaming. Have to use search/replace
 which isn't great.
Refactorings are not so easy because it can be harmful if it changes things too many places. Fixing "Find all references" would be a first step...
 4. Cannot execute commands in the debugger watch such as cast(toChild)x;
 (see 2)
You have to name the type with fully qualified type (e.g. "pgk.module.Child") for the cast operation as the debugger has no symbol lookup information.
 5. Enums are not shown by name. Do I really have to memorize all the
 values?
This information is not written by the COFF backend of dmd. I need to double check with the OMF backend.
 6. A lot of junk information that takes up space. e.g., strings show
 "length=0x00000084". would be better to minimize to 84 and show by name:
 e.g., "This is 84 chars long?"(84)
You get much shorter numbers if you disable hexadecimal display. The next version also just prints the string in the "preview" line. To actually show length,ptr pair, you can use the raw formatting by appending ",!" as with the C++ debugger.
 7. Line stepping can be weird because sometimes the current line will
 jump to random places then jump back when stepping again. This is
 probably a bug.
That's usually due to bad debug information written by dmd (but not always). Please file a bug if you have some reproducible test case.
 I assume this is due to the mago debugger rather than Visual D but not
 sure(except the renaming ability).
Yes, mago and dmd involved.
Jun 15 2016
next sibling parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Thursday, 16 June 2016 at 05:51:54 UTC, Rainer Schuetze wrote:
 [...]
 4. Cannot execute commands in the debugger watch such as 
 cast(toChild)x;
(see 2) You have to name the type with fully qualified type (e.g. "pgk.module.Child") for the cast operation as the debugger has no symbol lookup information.
For very long time I actually thought that this wasn't possible with VisualD, until I discovered that I could use the FQ name by accident. I think it would be very helpful if the error message said "try using the fully qualified name e.g. package.module.Type", instead of just "symbol not found". For me the biggest problem is that its not clearly visible what operations are supported by the debugger and I need to figure this out by trial and error. Is possible to include some short documentation that is displayed e.g. when the user clicks a "?" button next to the minimize/restore/close buttons on the QuickWatch window? Just a short string listing what is currently supported would be a huge improvement in terms of discoverability. BTW, thank for your work on VisualD and improvements to dmd's debug info! It's much appreciated!
Jun 16 2016
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 16.06.2016 12:04, ZombineDev wrote:
 On Thursday, 16 June 2016 at 05:51:54 UTC, Rainer Schuetze wrote:
 [...]
 4. Cannot execute commands in the debugger watch such as cast(toChild)x;
(see 2) You have to name the type with fully qualified type (e.g. "pgk.module.Child") for the cast operation as the debugger has no symbol lookup information.
For very long time I actually thought that this wasn't possible with VisualD, until I discovered that I could use the FQ name by accident. I think it would be very helpful if the error message said "try using the fully qualified name e.g. package.module.Type", instead of just "symbol not found".
I agree, the error message could be more helpful. Long term, I'm hoping for the D compiler to emit some lookup information. IIRC GDC does this already for DWARF debug info.
 For me the biggest problem is that its not clearly visible what
 operations are supported by the debugger and I need to figure this out
 by trial and error.

 Is possible to include some short documentation that is displayed e.g.
 when the user clicks a "?" button next to the minimize/restore/close
 buttons on the QuickWatch window?
 Just a short string listing what is currently supported would be a huge
 improvement in terms of discoverability.
The UI is not really under control of the debug engine, but the string-view window could be abused for some help message.
 BTW, thank for your work on VisualD and improvements to dmd's debug
 info! It's much appreciated!
Thanks.
Jun 17 2016
prev sibling parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Thursday, 16 June 2016 at 05:51:54 UTC, Rainer Schuetze wrote:
 On 16.06.2016 02:20, Joerg Joergonson wrote:
 It is pretty hard to visual D's debugger because it is not 
 very helpful.

 1. It generally shows memory addresses for objects. Doesn't do 
 me much
 good. Would be nice to first try a toString() or display the 
 type name.
I guess you are coming from C# where displaying the result of toString is more common. The C++ debugger never does this as executing code can be harmful. I've added showing the derived type as in C++ just a couple of days ago.
 2. Objects are not shown as they are but their base class 
 types. This
 tends to leave a lot of info out of the display.
The new version also allows inspecting the derived class.
 3. Cannot do a refactored type of renaming. Have to use 
 search/replace
 which isn't great.
Refactorings are not so easy because it can be harmful if it changes things too many places. Fixing "Find all references" would be a first step...
 4. Cannot execute commands in the debugger watch such as 
 cast(toChild)x;
 (see 2)
You have to name the type with fully qualified type (e.g. "pgk.module.Child") for the cast operation as the debugger has no symbol lookup information.
 5. Enums are not shown by name. Do I really have to memorize 
 all the
 values?
This information is not written by the COFF backend of dmd. I need to double check with the OMF backend.
 6. A lot of junk information that takes up space. e.g., 
 strings show
 "length=0x00000084". would be better to minimize to 84 and 
 show by name:
 e.g., "This is 84 chars long?"(84)
You get much shorter numbers if you disable hexadecimal display. The next version also just prints the string in the "preview" line. To actually show length,ptr pair, you can use the raw formatting by appending ",!" as with the C++ debugger.
 7. Line stepping can be weird because sometimes the current 
 line will
 jump to random places then jump back when stepping again. This 
 is
 probably a bug.
That's usually due to bad debug information written by dmd (but not always). Please file a bug if you have some reproducible test case.
 I assume this is due to the mago debugger rather than Visual D 
 but not
 sure(except the renaming ability).
Yes, mago and dmd involved.
Ok, Thanks. If you could work, at your own pace, at getting mago and Visual D up to par with the latest Visual Studio and SDK's I would put in some effort in to helping "clean" things up(whatever that means). I really like the experience that C# has, and maybe I'm just spoiled or conditioned to it, but I miss that in D. I'm sure it would be quite easy to add code based debugging helpers(sort of like visualizers) to do using D source. To prevent "security" issues a warning system could be added easily: class XXX { string Name; version(Debugger_Visualizer) { string toString() { return x.Name~" is trying to Hack you!?"; } } or one could include all that in a separate source like module Debugger_Visualizers string to!(XXX)(XXX x) { return x.Name~" Hacked?!!"; } } Then just keep track of all these cases and make the user sign off on(hash the code and use an AA to see if the user has previously allowed it). Other debuggers could eventually take advantage of it too and more complex debugging visualizations could be implemented than just toStrings (e.g., something similar to std.conv.to).
Jun 16 2016
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 17.06.2016 04:05, Joerg Joergonson wrote:
 I'm sure it would be quite easy to add code based debugging helpers(sort
 of like visualizers) to do using D source. To prevent "security" issues
 a warning system could be added easily:

 class XXX
 {
    string Name;
    version(Debugger_Visualizer)
    {
        string toString() { return x.Name~" is trying to Hack you!?"; }
    }

 or one could include all that in a separate source like

 module Debugger_Visualizers

 string to!(XXX)(XXX x) { return x.Name~" Hacked?!!"; }
 }


 Then just keep track of all these cases and make the user sign off
 on(hash the code and use an AA to see if the user has previously allowed
 it).

 Other debuggers could eventually take advantage of it too and more
 complex debugging visualizations could be implemented than just
 toStrings (e.g., something similar to std.conv.to).
Visualizer code in the binary sounds like an interesting idea. Given some convention on naming so that symbols are discoverable and rather safe to call, that could be doable. Mago does not yet support calling code in the debugged process, so that would be a first step to implement such kind of visualizers.
Jun 17 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Friday, 17 June 2016 at 08:18:59 UTC, Rainer Schuetze wrote:
 On 17.06.2016 04:05, Joerg Joergonson wrote:
 I'm sure it would be quite easy to add code based debugging 
 helpers(sort
 of like visualizers) to do using D source. To prevent 
 "security" issues
 a warning system could be added easily:

 class XXX
 {
    string Name;
    version(Debugger_Visualizer)
    {
        string toString() { return x.Name~" is trying to Hack 
 you!?"; }
    }

 or one could include all that in a separate source like

 module Debugger_Visualizers

 string to!(XXX)(XXX x) { return x.Name~" Hacked?!!"; }
 }


 Then just keep track of all these cases and make the user sign 
 off
 on(hash the code and use an AA to see if the user has 
 previously allowed
 it).

 Other debuggers could eventually take advantage of it too and 
 more
 complex debugging visualizations could be implemented than just
 toStrings (e.g., something similar to std.conv.to).
Visualizer code in the binary sounds like an interesting idea. Given some convention on naming so that symbols are discoverable and rather safe to call, that could be doable. Mago does not yet support calling code in the debugged process, so that would be a first step to implement such kind of visualizers.
It would be interesting, easy on the end user, and "portable" if it could be done. Having it stored in modules could allow mago/VD to compile the code(since we know we have the compiler) outside the project. Generic debugging helpers could be written and shared. It just depends on the difficulty of implementing properly ;)
Jun 18 2016
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 18.06.2016 17:57, Joerg Joergonson wrote:
 On Friday, 17 June 2016 at 08:18:59 UTC, Rainer Schuetze wrote:
 Visualizer code in the binary sounds like an interesting idea. Given
 some convention on naming so that symbols are discoverable and rather
 safe to call, that could be doable.

 Mago does not yet support calling code in the debugged process, so
 that would be a first step to implement such kind of visualizers.
It would be interesting, easy on the end user, and "portable" if it could be done. Having it stored in modules could allow mago/VD to compile the code(since we know we have the compiler) outside the project. Generic debugging helpers could be written and shared. It just depends on the difficulty of implementing properly ;)
Visualizers in a separate module or even binary have the problem of not being able to access private symbols. Having it in a DLL built and loaded by mago/vd needs an extensive API for reflection and memory access. This seems like a larger project... I'd rather start with some functions in the debuggee itself to be searched for the type data to be displayed, e.g. string mago_visualizer(ref T data); string mago_visualizer(T)(ref T data); or some sink-delegate-version to avoid allocations. mago will try to resolve these for T and its base classes. If it finds one, it is called and the string result is displayed.
Jun 19 2016
next sibling parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:
 On 18.06.2016 17:57, Joerg Joergonson wrote:
 On Friday, 17 June 2016 at 08:18:59 UTC, Rainer Schuetze wrote:
 Visualizer code in the binary sounds like an interesting 
 idea. Given
 some convention on naming so that symbols are discoverable 
 and rather
 safe to call, that could be doable.

 Mago does not yet support calling code in the debugged 
 process, so
 that would be a first step to implement such kind of 
 visualizers.
It would be interesting, easy on the end user, and "portable" if it could be done. Having it stored in modules could allow mago/VD to compile the code(since we know we have the compiler) outside the project. Generic debugging helpers could be written and shared. It just depends on the difficulty of implementing properly ;)
Visualizers in a separate module or even binary have the problem of not being able to access private symbols. Having it in a DLL built and loaded by mago/vd needs an extensive API for reflection and memory access. This seems like a larger project... I'd rather start with some functions in the debuggee itself to be searched for the type data to be displayed, e.g. string mago_visualizer(ref T data); string mago_visualizer(T)(ref T data); or some sink-delegate-version to avoid allocations. mago will try to resolve these for T and its base classes. If it finds one, it is called and the string result is displayed.
I have no problem with that, anything that makes life easier is a + for me ;) A side note, intellisense shows all the possible invocations on a type. It would be nice to make a distinction of direct members, and such e.g., a list Type method1 field1 ... Base method1 field1 ... External .... When looking for a method that I'm not aware of I have to scroll through all the module imports(e.g., min, max, Date, abs, etc...). If all this stuff was at the button of the list and the more relevant stuff was at the top, it would be better. A line separator is all that is needed to distinguish. Basically break the list in to derivation type and sub-sort alphabetically rather than using a flat list sorted alphabetically. Probably something quite easy to do? Could be an option.
Jun 21 2016
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 22.06.2016 00:34, Joerg Joergonson wrote:
 On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:
 On 18.06.2016 17:57, Joerg Joergonson wrote:
 On Friday, 17 June 2016 at 08:18:59 UTC, Rainer Schuetze wrote:
 Visualizer code in the binary sounds like an interesting idea. Given
 some convention on naming so that symbols are discoverable and rather
 safe to call, that could be doable.

 Mago does not yet support calling code in the debugged process, so
 that would be a first step to implement such kind of visualizers.
It would be interesting, easy on the end user, and "portable" if it could be done. Having it stored in modules could allow mago/VD to compile the code(since we know we have the compiler) outside the project. Generic debugging helpers could be written and shared. It just depends on the difficulty of implementing properly ;)
Visualizers in a separate module or even binary have the problem of not being able to access private symbols. Having it in a DLL built and loaded by mago/vd needs an extensive API for reflection and memory access. This seems like a larger project... I'd rather start with some functions in the debuggee itself to be searched for the type data to be displayed, e.g. string mago_visualizer(ref T data); string mago_visualizer(T)(ref T data); or some sink-delegate-version to avoid allocations. mago will try to resolve these for T and its base classes. If it finds one, it is called and the string result is displayed.
I have no problem with that, anything that makes life easier is a + for me ;) A side note, intellisense shows all the possible invocations on a type. It would be nice to make a distinction of direct members, and such e.g., a list Type method1 field1 ... Base method1 field1 ... External .... When looking for a method that I'm not aware of I have to scroll through all the module imports(e.g., min, max, Date, abs, etc...). If all this stuff was at the button of the list and the more relevant stuff was at the top, it would be better. A line separator is all that is needed to distinguish.
I guess the less relevant stuff comes from matching UFCS functions with broad constraints. You can disable these on the language option page.
 Basically break the list in to derivation type and sub-sort
 alphabetically rather than using a flat list sorted alphabetically.
It can be quite confusing if you are looking for some of the "less relevant" functions by typing the first characters, but these don't appear due to non-overall sorting. Other suggestions have been to use coloring or different fonts.
 Probably something quite easy to do? Could be an option.
Unfortunately, adding something to the UI that is not available by the standard control usually means reimplementing the full control.
Jun 22 2016
prev sibling parent reply StarGrazer <Stary Night.com> writes:
On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:
 On 18.06.2016 17:57, Joerg Joergonson wrote:
 [...]
Visualizers in a separate module or even binary have the problem of not being able to access private symbols. Having it in a DLL built and loaded by mago/vd needs an extensive API for reflection and memory access. This seems like a larger project... I'd rather start with some functions in the debuggee itself to be searched for the type data to be displayed, e.g. string mago_visualizer(ref T data); string mago_visualizer(T)(ref T data); or some sink-delegate-version to avoid allocations. mago will try to resolve these for T and its base classes. If it finds one, it is called and the string result is displayed.
Has anything like this been added yet? I would like to be able to see the GUID value in the debugger, but it is not showing up...
Mar 22
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 22.03.2017 22:13, StarGrazer wrote:
 On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:
 On 18.06.2016 17:57, Joerg Joergonson wrote:
 [...]
Visualizers in a separate module or even binary have the problem of not being able to access private symbols. Having it in a DLL built and loaded by mago/vd needs an extensive API for reflection and memory access. This seems like a larger project... I'd rather start with some functions in the debuggee itself to be searched for the type data to be displayed, e.g. string mago_visualizer(ref T data); string mago_visualizer(T)(ref T data); or some sink-delegate-version to avoid allocations. mago will try to resolve these for T and its base classes. If it finds one, it is called and the string result is displayed.
Has anything like this been added yet? I would like to be able to see the GUID value in the debugger, but it is not showing up...
No, nothing added to that respect. You should be able to view a GUID, though. It could be a case of debug info missing from a library (see https://issues.dlang.org/show_bug.cgi?id=4014).
Mar 26
parent reply StarGrazer <Stary Night.com> writes:
On Sunday, 26 March 2017 at 15:45:47 UTC, Rainer Schuetze wrote:
 On 22.03.2017 22:13, StarGrazer wrote:
 On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:
 [...]
Has anything like this been added yet? I would like to be able to see the GUID value in the debugger, but it is not showing up...
No, nothing added to that respect. You should be able to view a GUID, though. It could be a case of debug info missing from a library (see https://issues.dlang.org/show_bug.cgi?id=4014).
How would I find out? All I know is that GUID and some other things show up with as {}, which is very uninformative.
Mar 26
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 26.03.2017 19:49, StarGrazer wrote:
 On Sunday, 26 March 2017 at 15:45:47 UTC, Rainer Schuetze wrote:
 On 22.03.2017 22:13, StarGrazer wrote:
 On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:
 [...]
Has anything like this been added yet? I would like to be able to see the GUID value in the debugger, but it is not showing up...
No, nothing added to that respect. You should be able to view a GUID, though. It could be a case of debug info missing from a library (see https://issues.dlang.org/show_bug.cgi?id=4014).
How would I find out? All I know is that GUID and some other things show up with as {}, which is very uninformative.
Actually, phobos and druntime are built without debug information, and dmd does not generate corresponding debug info for code that uses structs declared by the libraries. Even if you rebuild druntime and phobos with debug information, you might hit the issue mentioned above. A workaround should be to actually reference GUID.init somewhere, as the debug info is only linked in when the init property is referred to. To help with this issue, Visual D has the project option "build and use local version of phobos with same compiler options" on the linker page. It also allows debugging calls into druntime/phobos. Unfortunately, this build is broken with recent dmd versions. Currently investigating...
Mar 27
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 27.03.2017 18:50, Rainer Schuetze wrote:
 To help with this issue, Visual D has the project option "build and use
 local version of phobos with same compiler options" on the linker page.
 It also allows debugging calls into druntime/phobos.

 Unfortunately, this build is broken with recent dmd versions. Currently
 investigating...
Should be fixed for dmd 2.073 in this build: https://ci.appveyor.com/project/rainers/visuald/build/1.0.115/job/7r384dme5sw1pnq2/artifacts Unfortunately, GUID having an initializer with all zeroes causes all references to the init property to be optimized away. The only way I found to drag the debug info in is to place this code somewhere at global scope. extern extern(C) __gshared int D4core3sys7windows8basetyps4GUID6__initZ; __gshared ref_GUID_init = &D4core3sys7windows8basetyps4GUID6__initZ;
Mar 27
parent reply StarGrazer <Stary Night.com> writes:
On Monday, 27 March 2017 at 18:05:23 UTC, Rainer Schuetze wrote:
 On 27.03.2017 18:50, Rainer Schuetze wrote:
 [...]
Should be fixed for dmd 2.073 in this build: https://ci.appveyor.com/project/rainers/visuald/build/1.0.115/job/7r384dme5sw1pnq2/artifacts Unfortunately, GUID having an initializer with all zeroes causes all references to the init property to be optimized away. The only way I found to drag the debug info in is to place this code somewhere at global scope. extern extern(C) __gshared int D4core3sys7windows8basetyps4GUID6__initZ; __gshared ref_GUID_init = &D4core3sys7windows8basetyps4GUID6__initZ;
None of this worked for me ;/
Mar 27
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 28.03.2017 01:57, StarGrazer wrote:
 On Monday, 27 March 2017 at 18:05:23 UTC, Rainer Schuetze wrote:
 On 27.03.2017 18:50, Rainer Schuetze wrote:
 [...]
Should be fixed for dmd 2.073 in this build: https://ci.appveyor.com/project/rainers/visuald/build/1.0.115/job/7r384dme5sw1pnq2/artifacts Unfortunately, GUID having an initializer with all zeroes causes all references to the init property to be optimized away. The only way I found to drag the debug info in is to place this code somewhere at global scope. extern extern(C) __gshared int D4core3sys7windows8basetyps4GUID6__initZ; __gshared ref_GUID_init = &D4core3sys7windows8basetyps4GUID6__initZ;
None of this worked for me ;/
"not working" means it built the "private" phobos library with debug information and your code compiled and linked with the above snippet, but debug info was still missing?
Apr 01