Visual D 0.48-beta1

[James Japherson]

On Wednesday, 10 October 2018 at 17:40:49 UTC, Rainer Schuetze 
wrote:
>
>
> On 10/10/2018 09:21, James Japherson wrote:
>> On Wednesday, 10 October 2018 at 06:37:33 UTC, Rainer Schuetze 
>> wrote:
>>>
>>>
>>> On 08/10/2018 19:55, Rainer Schuetze wrote:
>>>>
>>>>
>>>> On 08/10/2018 17:16, James Japherson wrote:
>>>>> Basically I'm having lots of problems with 0.48.
>>>>>
>>>>> 1. I get that one error about the stack constantly. Usually 
>>>>> happens when I hit '.' but sometimes not.
>>>>
>>>> I can reproduce with a combination of "static foreach" and 
>>>> "tupleof", I hope we can find a solution.
>>>>
>>>
>>> Please try the new beta: 
>>> https://github.com/dlang/visuald/releases/tag/v0.48.0-beta2
>> 
>> Oh man! Almost! It worked for about 3 minutes! I thought I was 
>> going to get somewhere! It got me with the stack frame bug.
>
> Do you have some test code that you can share?
>
>> 
>> I'm having a bigger problem though, not sure I think this is 
>> always been a problem with visual D.
>> 
>> I can't see any outer variables in the debug windows. It seems 
>> lambda's and inner functions and global scope is never shown 
>> while in those scopes! This makes it very hard to debug them 
>> because one can't see the outside variables. One has to make a 
>> sort of local copy.
>> 
>> e.g.,
>> 
>> int x = 3; // Won't be seen while in foo
>> 
>> void foo()
>> {
>>    // BP stopped here, can't see x in debug watches unless we 
>> do the
>> following:
>>    int tmpx = x;
>> }
>> 
>
> Unfortunately it has always been this way: dmd only emits the 
> context pointer "this" as a void*, while it could be a struct 
> containing the captured variables. LDC might behave a bit 
> better here, but has other quirks.
>
> Globals can be watched by specifying the fully qualified name, 
> no import/lookup information is available otherwise. (There is 
> a workaround that allows them to be seen in D functions that 
> are part of the same scope so lookup can be derived from the 
> fully qualified function name).

This makes it very difficult to do any debugging, basically 
impossible, when one is using lambdas and nesting functions and 
globals. It's like running blind. Delegates which capture the 
context are basically useless because you can never see that 
context in the debugger. Globals are somewhat useless because you 
can't see them in the debugger automatically(so you have to 
remember the name spelling, etc).

Something should be done about this! Surely it is not a hard 
problem!


Can hacks be done? Some way for visual D to get the context? 
Surely it knows the outer context because it can trace the stack. 
It should just have to work itself up the stack to get the 
locations of the functions and then, if it knows the stack 
structure(locals, which D should emit) then it can determine who 
and what and then add them to the watch as needed?

After all, all we are talking about here is a

Variable name, it's type, and it's value.


I'm also mainly talking about the locals, auto, and watch. Locals 
could be true locals, auto could include the total context and 
watch could automatically determine context(do a match, search to 
find the watched name in any ancestral match, could list for 
multiple matches, although there should only ever be one since D 
does not allow shadowing).

If this is too hard for Visual D, what does D itself need to make 
it happen?
IMO, debugging is a real pain because of this. To debug I one has 
to know the values, but one cannot get the values.

Even if Visual D had to use hacks, it is better than nothing.

e.g., if Visual D could remember outer variables(not sure how 
unless it tracked each function call then it could just display 
the values by caching them and then using the cached version, but 
this would lead to them not being consistent if changed inside. 
But it would be better than nothing. Put a BP at the start of the 
function and see the correct outside variable values then just 
note any changes.

Of course, if you could do that then it probably wouldn't be hard 
to just get the addresses so one could get the actual values.

If this is a limitation of D, could you ask any of the 
maintainers about getting the required info so it can be done? 
This is a sever limitation in D and makes debugging large 
programs impossible slow(orders of magnitude).

To simulate this effect require usually requires that I create 
temp variables connecting the dots(e.g., using local variable 
that is assigned the value of the global). I have to add, run the 
program, then remove the bloat. This has to happen for any 
outside variable.

I think though that Visual D can do this:

Because Visual D can see the stack, I can click on some ancestor 
call and it will show the variables in it(the locals I guess)..

So, really all Visual D needs to do is collect all that info and 
put it in the auto's. It seems to all be there, or at least a lot 
more.

Ok, it's not quite the same because of captures are not going to 
work for function pointers(they capture a different context than 
what the call stack).


Also, when visual D breaks due to an error, such as an assert, it 
doesn't jump to the actual line it says in the error message but 
usually, it seems, to the call location. This should be easy by 
juts matching the line number and source file in the error with 
that of the line/source in the program. The locations seem to 
accurately give the error but I have to manually go find it... 
sometimes it's in a different file making it slow.


Also, many times errors due to something in my program end up 
opening up debug libraries saying the error is in them when it is 
not. It would be nice to have a sort of "debug my code only" like 
.NET has.


Thanks.