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

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.

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!

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

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.

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.

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 ;)

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.

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.

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.