Visual D Debugger "complaints" (Mago?)

[Joerg Joergonson via Digitalmars-d-ide]

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