Christmas request! VD closure debugging
Michelle Long
HappyDance321 at gmail.com
Fri Dec 14 03:21:58 UTC 2018
I've mentioned this before but I am really struggling with this
issue and it is probably the biggest problem I have with VD + D
in general.
Again, any nesting of stuff (such as functions) or opApply
overrides of foreach and other cases lose scope of the locals
above it(it's globals) are lost in the locals, auto, watch,
etc....
This makes it tremendously difficult to debug unless hard aliases
are created... which uglify the code and must be maintained to
prevent having to constantly re-add them and remove them.
You told me that dmd and walter do not think it is a big issue
and that it is a problem with dmd. If this is true surely you can
use your clout to get him to change his mind. He doens't realize
the headache this causes in debugging. The whole point of being
able to see the contents of variables is at the essence of
debugging. Without it the debugging experience would be rather
pointless.
I'm not sure what is required and how it can be done much less of
the exact cause so I implore you to try to convince Walter it is
necessary for VD to function properly. Surely some compromise
could be had. D is a very nested language and many times a simple
nesting of a function and or struct can make all the difference
in a problem.
But even since opApply exhibits this problem, it is very common.
I run across it even when I am using library code or anything
that overrides foreach. I actually though I remembered not having
this problem a while back or I'm sure I would have complained
about it from the get go... but I could be wrong or just not
experienced it much at the time.
I don't think it would be a hard problem to solve since it really
is just keeping track of the variables addresses and which ones
that need to be exposed. But maybe this is not so easy to get
working?
More information about the Digitalmars-d-ide
mailing list