All the great features we know and love in C/C++/C# don't work well in VisualD. Things like peak definition, find all references, debugging issues: variables not showing up, becoming corrupt requiring a clean of the solution, variables with different scopes but same name getting corrupt, the inability to watch variables properly due to scope issues, breakpoints not always functioning as expected, etc.

The things I use most in VS are the things that VD neglected to implement ;/ This makes the experience when programming VD very poor for me. While I can code and build just like in C++, which VD does a good job at, all the bells and whistles that have become an integral part of the programming experience for me are missing ;/

Because these features greatly enhance my productivity, I feel very inefficient when programming D code and this leads me to not desiring to use D or VD.

The debugging experience is almost painful because it is somewhat alien and does not function as VC++'s debugging experience does. Because it is so close, of course, it creates more of a mess than it helps in many cases.

In VC++/VC# I can rely on the debugger to help me quickly solve my problems. I have had several experiences where the VD debugger(most mago and VS version) have show incorrect values leading me to believe I am having some other problem than what is really going on. Once I clean the project they start working again only to eventually become corrupt.

I know it must be hard work to main VD to keep it consistent with visual studio(which nearly changes every year), Until the D community comes up with a proper visual program environment, it is all that us "newbs" have(if I had to program out of notepad I'd probably hang myself, it's like using MS Paint vs Adobe Photoshop).

How hard would it be to add these features? I would think that many windows C++ would be more willing to get in to D if the hurdle was not so mind boggling(as it is almost better for it to be completely different, at least one doesn't go in with expectations and habits).

Any idea if you will ever get around to implementing these features and fixing some of the issues? (Seems like VD hasn't been updated in a while)

On 23.01.2017 23:23, Profile Anaysis wrote:
> All the great features we know and love in C/C++/C# don't work well in
> VisualD. Things like

> peak definition,

I never use it myself when working in C++, but I agree, it would be nice to have. At first glance there seems to be little support to implement it easily, though. The Code Definition window works, though.

> find all references,

The current implementation is very experimental. Never had the time to improve it though. Refactoring tools are pretty nasty because D is not a simple language...

> debugging
> issues: variables not showing up, becoming corrupt requiring a clean of
> the solution, variables with different scopes but same name getting
> corrupt, the inability to watch variables properly due to scope issues,
> breakpoints not always functioning as expected, etc.
[...]
>
> The debugging experience is almost painful because it is somewhat alien
> and does not function as VC++'s debugging experience does. Because it is
> so close, of course, it creates more of a mess than it helps in many cases.

The debugging experience very much relies on the debug info emitted by the compiler. Unfortunately this is a rather neglected part of the compiler as the main developers prefer printf debugging.

[...]
>
> Any idea if you will ever get around to implementing these features and
> fixing some of the issues? (Seems like VD hasn't been updated in a while)
>

There should be some improvements with the recent beta and the latest dmd release. If you have reproducible issues, please file them here: https://issues.dlang.org/

On Thursday, 26 January 2017 at 08:24:37 UTC, Rainer Schuetze wrote:
>
>
> On 23.01.2017 23:23, Profile Anaysis wrote:
>> [...]
>
>> [...]
>
> I never use it myself when working in C++, but I agree, it would be nice to have. At first glance there seems to be little support to implement it easily, though. The Code Definition window works, though.
>
>> [...]
>
> The current implementation is very experimental. Never had the time to improve it though. Refactoring tools are pretty nasty because D is not a simple language...
>

But it shouldn't be hard to return something. I'd rather have invalid results than no results at all. A simple file search would do. If it returned entries that were in comments, I wouldn't mind.


>> [...]
> [...]
>> [...]
>
> The debugging experience very much relies on the debug info emitted by the compiler. Unfortunately this is a rather neglected part of the compiler as the main developers prefer printf debugging.
>
> [...]
>>[...]
>
> There should be some improvements with the recent beta and the latest dmd release. If you have reproducible issues, please file them here: https://issues.dlang.org/

The 0.44b2 didn't help(or made things worse).

also, "globals"(non-locals) do not show up in watch list/locals at all ;/ Makes it very hard to debug ;/

If I put, say, a variable outside a function, it will not be in any list and I cannot see it's value unless I make a local alias to it.

On 30.01.2017 02:50, Profile Anaysis wrote:
> also, "globals"(non-locals) do not show up in watch list/locals at all
> ;/ Makes it very hard to debug ;/
>
> If I put, say, a variable outside a function, it will not be in any list
> and I cannot see it's value unless I make a local alias to it.
>

Unfortunately, there is no debug information about the current module scope. To watch globals, you need to specify them fully qualified (with module and package name, e.g. "pkg.module.var"). Depending on the debugger engine, you'll have to replace '.' with '@'.

Static variables inside extern(D) functions are supported in mago, because the scope can be extracted from the function name.