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

On Friday, 21 July 2017 at 19:37:25 UTC, 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

Here are some more video errors:

https://ufile.io/6wpn1

There is some type of major issue with VisualD. It is not fun to use ;/ I always feel like it is slowing me down rather than helping me. It's so close to being a pretty good ide for D and windows, but seems that the foundation is cracked ;/

And another bug showing how loops do not function properly.

https://ufile.io/74dct

On Friday, 21 July 2017 at 19:37:25 UTC, 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.
>
> [...]

and another problem is that we cannot use go to definition on an alias. One has to copy the alias name then do a search.

On Friday, 21 July 2017 at 19:37:25 UTC, 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


and another problem is that if one puts a BP on the line below a loop, one is forced to step through the loop as if the BP was inside the loop.

There seems to be a general bug in the source code to line mapping where end of groups are not treated properly and only the last declaration is used... and possibly an off-by-1 bug.

On Friday, 21 July 2017 at 19:37:25 UTC, 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.
>
> [...]


and another problem is that enum values are displayed as ints, rather than both the value and the enum element name. I don't memorize enum values.

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

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.

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.

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

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.

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

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.

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

On 22.07.2017 20:36, FoxyBrown wrote:
> On Saturday, 22 July 2017 at 08:20:00 UTC, Rainer Schuetze wrote:
>>
>> 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? 

AFAICT GDC has implemented this to some extend. It would be nice if the that information would be available: https://issues.dlang.org/show_bug.cgi?id=17675


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

As noted below, this is likely caused by nested functions, either explicitly or implicitly added by the compiler.

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

Intellisense must work while you type, so there is no debug information available at that time. Very likely the current text isn't even compilable.

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

Yes, the compiler could help: https://issues.dlang.org/show_bug.cgi?id=4898

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

Sure, it just shouldn't remove that information.

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

I tried it on LoadLibrary, that took me to the alias to LoadLibraryA, which didn't let me go further. This is disabled code, though, it should have been LoadLibraryW. Go to definition on the respective alias definition works. Other alias definition in the vicinity of LoadLibraryA seem to work, though.

Is this what you are referring to?

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

If the information, that's up for the debugger to decide.

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

Unfortunately, Visual D is still a one man project, and I have also "inherited" maintenance of the external dependencies (the debug engine and the semantic engine). There is little help from the main D developers to improve debug information as they don't seem to use debuggers, but prefer printf debugging (which is sometimes better if a lot of information needs to be logged).

So it's pretty tough to meet the expected standards of C++ or even C# environments. Any help is welcome.

On Sunday, 23 July 2017 at 07:56:14 UTC, Rainer Schuetze wrote:
> Unfortunately, Visual D is still a one man project, and I have also "inherited" maintenance of the external dependencies (the debug engine and the semantic engine). There is little help from the main D developers to improve debug information as they don't seem to use debuggers, but prefer printf debugging (which is sometimes better if a lot of information needs to be logged).
>
> So it's pretty tough to meet the expected standards of C++ or even C# environments. Any help is welcome.

thats too bad. your project was the one that let me try to try D, which i postponed the last time to a new version, because of the existing problems. if D the com padres (Walter and Andrei) think to have to oust a lot people that use windoze, then that is ok, but maybe they should be fair enough to tell people so.
reading this and other threads leads me to definitely wait another year or so  - and to maybe come back and see what developed up to that time.
presently i could not recommend D to any of my co workers.

please keep up your good work with Visual D.
Thank you for your time and effort.