• FoxyBrown (14/14) Jul 21 2017 Here is a visual to prove some of the bad behavior that visual D
• FoxyBrown (7/22) Jul 21 2017 Here are some more video errors:
• FoxyBrown (2/2) Jul 21 2017 And another bug showing how loops do not function properly.
• FoxyBrown (3/8) Jul 21 2017 and another problem is that we cannot use go to definition on an
• FoxyBrown (7/22) Jul 21 2017 and another problem is that if one puts a BP on the line below a
• FoxyBrown (4/9) Jul 21 2017 and another problem is that enum values are displayed as ints,
• Rainer Schuetze (37/54) Jul 22 2017 Thanks for taking the time to create the videos and report these issues....
• FoxyBrown (46/106) Jul 22 2017 Surely we could ask for an enhancement to do this? The problem
• Rainer Schuetze (25/109) Jul 23 2017 AFAICT GDC has implemented this to some extend. It would be nice if the
• jj (12/20) Jul 23 2017 thats too bad. your project was the one that let me try to try D,

FoxyBrown <Foxy Brown.IPT> writes:

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

FoxyBrown <Foxy Brown.IPT> writes:

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

FoxyBrown <Foxy Brown.IPT> writes:

And another bug showing how loops do not function properly.

https://ufile.io/74dct

FoxyBrown <Foxy Brown.IPT> writes:

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.

FoxyBrown <Foxy Brown.IPT> writes:

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.

FoxyBrown <Foxy Brown.IPT> writes:

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.

Rainer Schuetze <r.sagitario gmx.de> writes:

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.

FoxyBrown <Foxy Brown.IPT> writes:

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 

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

Rainer Schuetze <r.sagitario gmx.de> writes:

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 

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


environments. Any help is welcome.

jj <jj aol.com> writes:

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 


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.