Visual D 0.48-beta1

[Rainer Schuetze]

On 11/10/2018 01:05, James Japherson wrote:
> 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!
> 

Some guesswork could be added. See also
https://issues.dlang.org/show_bug.cgi?id=18882

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

Because of this I think doing all the hacks above is not worth the
trouble. It is a lot easier to fix it in the compiler, it just has to
pass Walters debugger-phobia.

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

It is sometimes impossible to correctly walk thestack without complete
debug information. This is probably related:
https://issues.dlang.org/show_bug.cgi?id=17811

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

I guess this happens for templates that still get compiled into your
object files with debug information. Or does it show disassembly for
code without debug information? That might be easier to skip.