• James Japherson (47/47) Oct 10 2018 I've been having a lot of issues with visual D. I'm not sure if
• Rainer Schuetze (13/62) Oct 12 2018 Pedantically, Visual D has only very little influence on the debug

James Japherson <JJ goolooking.com> writes:

I've been having a lot of issues with visual D. I'm not sure if 
it's just dysfunctional, has a few bugs, new bugs were 
introduced, or what has happened. Some things have always been 
like then. I have a potential solution though.

I will invest quite a bit of time documenting the issues I have 
using video, pictures and text, explaining why these problems are 
bad and even give the source code so you can use it to help fix 
these problems.

Most of these problems seem like bugs, some are inadequacies, 
some are probably just incomplete features, some may be expected 
behavior for some peoples workflow but doesn't work in mine.

If I do this will you be willing to take a serious look in to 
these problems and try to resolve them if we can come to an 
agreement that they are problems? (and that might simply be that 
it is an issue on my side if everything works as they are suppose 
to on yours)

Why I'm asking is that I am extremely unproductive in D because 
of it's arcane debugging problems that I seem to run in to quite 
often. I'm sure if these problems could be fixed(or the major 
ones), I'd be far more productive and enjoy the experience more 
too.

But there is no point in me doing this if you won't or can't 
invest the time(it's not a demand or insult, I just don't want to 
waste my time).

I've already brought up many of these problems so you basically 
know about them more or less. I realize it's hard to really know 
what's going on much less fix them without really seeing the 
problem and knowing why it is a problem(most of these problems 
have solutions but the solutions/work-arounds are extremely time 
consuming compared to what the debugger/ide can do). This is why 
I would invest the time to really show these problems in detail 
and explain why the alternative is better(and these things are 
not arcane issues I have, at least most of them).

I realize some of these problems are not solvable in any 
satisfiable sense but some are definitely needed for efficiency. 
Some of the harder ones could be long term goals to work on a 
little at a time so they eventually get fixed.

Since I'm not proficient and already have too much on my plate, I 
can't learn the inner workings of Visual D and try to fix these 
things myself, hence why you'll have to do it if you choose to.

Of course, you have none to lose to pretend that you'll invest 
your time... but I hope you wouldn't do that to me. No big deal 
if you really don't want to or can't. Life is more important, but 
if these fixes can persist(not regress) then they should make 
programming in Visual D much more friendly for most people that 
use it in the future.

Thanks.

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

On 11/10/2018 06:34, James Japherson wrote:
 I've been having a lot of issues with visual D. I'm not sure if it's
 just dysfunctional, has a few bugs, new bugs were introduced, or what
 has happened. Some things have always been like then. I have a potential
 solution though.
 
 I will invest quite a bit of time documenting the issues I have using
 video, pictures and text, explaining why these problems are bad and even
 give the source code so you can use it to help fix these problems.
 
 Most of these problems seem like bugs, some are inadequacies, some are
 probably just incomplete features, some may be expected behavior for
 some peoples workflow but doesn't work in mine.
 
 If I do this will you be willing to take a serious look in to these
 problems and try to resolve them if we can come to an agreement that
 they are problems? (and that might simply be that it is an issue on my
 side if everything works as they are suppose to on yours)
 
 Why I'm asking is that I am extremely unproductive in D because of it's
 arcane debugging problems that I seem to run in to quite often. I'm sure
 if these problems could be fixed(or the major ones), I'd be far more
 productive and enjoy the experience more too.
 
 But there is no point in me doing this if you won't or can't invest the
 time(it's not a demand or insult, I just don't want to waste my time).
 
 I've already brought up many of these problems so you basically know
 about them more or less. I realize it's hard to really know what's going
 on much less fix them without really seeing the problem and knowing why
 it is a problem(most of these problems have solutions but the
 solutions/work-arounds are extremely time consuming compared to what the
 debugger/ide can do). This is why I would invest the time to really show
 these problems in detail and explain why the alternative is better(and
 these things are not arcane issues I have, at least most of them).
 
 I realize some of these problems are not solvable in any satisfiable
 sense but some are definitely needed for efficiency. Some of the harder
 ones could be long term goals to work on a little at a time so they
 eventually get fixed.
 
 Since I'm not proficient and already have too much on my plate, I can't
 learn the inner workings of Visual D and try to fix these things myself,
 hence why you'll have to do it if you choose to.

Pedantically, Visual D has only very little influence on the debug
experience, it is a combination of the compiler-generated debug
information, the VS debugger and the mago debugger-plugin or mago
debug-engine depending on what engine you select.

 
 Of course, you have none to lose to pretend that you'll invest your
 time... but I hope you wouldn't do that to me. No big deal if you really
 don't want to or can't. Life is more important, but if these fixes can
 persist(not regress) then they should make programming in Visual D much
 more friendly for most people that use it in the future.

I'm interested in making the debug experience better, but I can't
promise I can solve all issues. Visual D and mago are still more-or-less
one-man-projects I do in my spare time.

Videos are good if the issue is hard to demonstrate or not easily
reproducible. Small reproducible test cases are often a lot easier to
get started, though.

Please post issues to https://issues.dlang.org, so they don't get lost
in forum discussions.