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