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

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.

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.

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.

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

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.

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.

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!

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.