VisualD's Proof Of Bigfoot!

Sat Jul 22 11:36:21 PDT 2017

On Saturday, 22 July 2017 at 08:20:00 UTC, Rainer Schuetze wrote:
>
>
> On 21.07.2017 21:37, FoxyBrown wrote:
>> Here is a visual to prove some of the bad behavior that visual 
>> D is having and turning me off from D. Since no one will 
>> believe that such problems could exist, I decided to get a 
>> video of the yeti up close and personal.
>> 
>> The video should be self explanatory. These are not the only 
>> problems I have run in to with Visual D. I do not think my 
>> system is unique, windows 10 + Visual Studio 2017. Anyone that 
>> uses that combination should run in to these issues fairly 
>> quickly I'd imagine(I've had them on several other system 
>> combinations also).
>> 
>> I have issues with the watch values not being correct. They 
>> also are reported before they "exist"(according to the line 
>> number. They should be hidden if the local line number < 
>> declaration line number of the variable).
>> 
>> http://s000.tinyupload.com/index.php?file_id=89572735278741121549
>
> Thanks for taking the time to create the videos and report 
> these issues. Most of these are not strictly Visual D problems, 
> but caused by the compiler emitting incomplete or bad debug 
> information. I concur that this doesn't really make a 
> difference to a user, though.
>
> 1. bad line number info for if statements: I haven't yet seen 
> something similar to your case (I suspect writing the full 
> if/then/else block into a single line makes it worse). Instead, 
> the debugger sometimes seems to execute the then-statement when 
> actually skipping it.
>
> 2. no debug info for ssp: this looks like 
> https://issues.dlang.org/show_bug.cgi?id=4014 which should be 
> resolved in git-master of dmd (new option -gf).
>
> 3. globals have to specified with their fully qualified names 
> in the watch window because the compiler does not emit symbol 
> lookup information (e.g. imports).

Surely we could ask for an enhancement to do this? The problem 
is, any lower scope seems to also have these issues.

I'm not sure if I made a video of it, I think it did, but if I 
put a BP on an inner block and run to it, then the outer blocks 
variables are not shown. If I step in to that inner block then 
they are shown. It's as if the debugger doesn't bother or can't 
collect the variables outside of the scope when not stepped 
through. This could be a similar issue with the globals, being 
the outer most scope, might just be ignored.

> 4. Intellisense: D is a quite complex language, which makes it 
> not so easy to provide good intellisense information (using the 
> compiler as a library is work in progress, but is unlikely to 
> be usable in the near future). Especially if inference (e.g. 
> with "auto") is involved, it can get pretty difficult.

Surely the compiler can emit the type to use? It has to know it. 
Maybe the compiler could be modified to output D debug info that 
you could use for mago to enhance it?

Should be relatively easy to do? I think the main problem

> 5. foreach loops: with ranges, the compiler usually translates 
> the loop body into a delegate, which it calls during iteration. 
> With incomplete context information, this hides local variables 
> of the outer functions. See the call stack when stepping 
> through the loop body.

Ok, maybe that was what I was talking about in 3. Again, surely 
the compiler can emit information to help with this? The compiler 
and mago should be coupled in such a way that mago can function 
properly.

> 6. compiler generated variables: the latest rc of Visual D (the 
> mago debug engine to be precise) allows to hide these variables 
> (see Tools->Options->Debugger->Mago).
>

Thanks.

> 7. some jump instructions are elided by the compiler even in 
> debug builds, which causes the bad behavior with "continue". I 
> tried disabling that optimization but Walter was against it. 
> Maybe this should be restricted to jumps with no or identical 
> debug line information.

Again, surely the compiler can emit information to help with 
this? a -mago switch that outputs whatever info is needed by the 
compiler.

> 8. "go to definition on an alias": not sure about this one: do 
> you mean "Search Symbols"? This uses compiler generated 
> information in JSON files. For phobos symbols you might want to 
> run "Build phobos browse info".

When I use "go to" on a symbol that is an alias, it takes me to 
the alias definition, but from there, I can't proceed because a 
go to on the alias symbols leads no where. Hence, I have to do a 
search for the symbol to find the actual reference.

I can make a video of it if your still confused. But basically 
trying to "go to" any symbol that is backed by an alias(specially 
some win32 stuff that aliases a lot of the unicode and ansi 
functions) should show the problem.

> 9. enum values: very old bug: 
> https://issues.dlang.org/show_bug.cgi?id=982. Not sure why it 
> has been assigned to D1, only.

Ok. Can it show both the value and the symbol?  That will make it 
real helpful ;)

My main issues is that it is simply difficult to program in D 
using VisualD/Visual Studio. If my problems are not isolated, I 
think that many C++/C# Visual Studio users will be turned off by 
D too.  While some of the more advanced features are nice, the 
basic ones are the ones that are relied upon and used the most 
and should just work. Not being able to visualize a struct, for 
example, is a big problem IMO. It's something I am so used to 
that I now rely on it as part of the debugging process. IMO, the 
more info I can get at my fingertips, the better the experience. 
When I have to fight the "debugger"(or whatever it is ultimately) 
to do a job, it makes it difficult to enjoy what I'm doing. I'd 
imagine it is more or less the same with everyone. Hopefully we 
can get D/VisualD/VisualStudio up to snuff relatively soon so I 
can live with peace and happiness ;)