www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - VisualD's Proof Of Bigfoot!

reply 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
Jul 21
next sibling parent 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 ;/
Jul 21
prev sibling next sibling parent FoxyBrown <Foxy Brown.IPT> writes:
And another bug showing how loops do not function properly.

https://ufile.io/74dct
Jul 21
prev sibling next sibling parent 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.
Jul 21
prev sibling next sibling parent 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.
Jul 21
prev sibling next sibling parent 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.
Jul 21
prev sibling parent reply 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.
Jul 22
parent reply 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 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 ;)
Jul 22
parent reply 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 
 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.
Jul 23
parent 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 
 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.
Jul 23