October 10, 2018
It seems to be happening mainly on runs. Might help narrow it down.

October 10, 2018
It did start speeding up on me and got within several times a second. Wasn't doing it on run so that might have been coincidences before.

October 10, 2018

On 10/10/2018 09:21, James Japherson wrote:
> On Wednesday, 10 October 2018 at 06:37:33 UTC, Rainer Schuetze wrote:
>>
>>
>> On 08/10/2018 19:55, Rainer Schuetze wrote:
>>>
>>>
>>> On 08/10/2018 17:16, James Japherson wrote:
>>>> Basically I'm having lots of problems with 0.48.
>>>>
>>>> 1. I get that one error about the stack constantly. Usually happens when I hit '.' but sometimes not.
>>>
>>> I can reproduce with a combination of "static foreach" and "tupleof", I hope we can find a solution.
>>>
>>
>> Please try the new beta: https://github.com/dlang/visuald/releases/tag/v0.48.0-beta2
> 
> Oh man! Almost! It worked for about 3 minutes! I thought I was going to get somewhere! It got me with the stack frame bug.

Do you have some test code that you can share?

> 
> I'm having a bigger problem though, not sure I think this is always been a problem with visual D.
> 
> I can't see any outer variables in the debug windows. It seems lambda's and inner functions and global scope is never shown while in those scopes! This makes it very hard to debug them because one can't see the outside variables. One has to make a sort of local copy.
> 
> e.g.,
> 
> int x = 3; // Won't be seen while in foo
> 
> void foo()
> {
>    // BP stopped here, can't see x in debug watches unless we do the
> following:
>    int tmpx = x;
> }
> 

Unfortunately it has always been this way: dmd only emits the context pointer "this" as a void*, while it could be a struct containing the captured variables. LDC might behave a bit better here, but has other quirks.

Globals can be watched by specifying the fully qualified name, no import/lookup information is available otherwise. (There is a workaround that allows them to be seen in D functions that are part of the same scope so lookup can be derived from the fully qualified function name).
October 10, 2018
See, when I override opApply, since it uses delegate, `foreach` cannot be easily debugged because when inside they show nothing on the outside. One cannot determine values, etc...

These types of problem make the programming experience not fun(I spend more time debugging than I do writing code ;/). Mainly because of all the hoops that are required to actually "see" things such as outer variables. I'll never believe that this problem can't be solve!! ;)

October 10, 2018
On Wednesday, 10 October 2018 at 07:21:29 UTC, James Japherson wrote:
> On Wednesday, 10 October 2018 at 06:37:33 UTC, Rainer Schuetze wrote:
>>
>>
>> On 08/10/2018 19:55, Rainer Schuetze wrote:
>>> 
>>> 
>>> On 08/10/2018 17:16, James Japherson wrote:
>>>> Basically I'm having lots of problems with 0.48.
>>>>
>>>> 1. I get that one error about the stack constantly. Usually happens when I hit '.' but sometimes not.
>>> 
>>> I can reproduce with a combination of "static foreach" and "tupleof", I hope we can find a solution.
>>> 
>>
>> Please try the new beta: https://github.com/dlang/visuald/releases/tag/v0.48.0-beta2
>
> Oh man! Almost! It worked for about 3 minutes! I thought I was going to get somewhere! It got me with the stack frame bug.
>
> I'm having a bigger problem though, not sure I think this is always been a problem with visual D.
>
> I can't see any outer variables in the debug windows. It seems lambda's and inner functions and global scope is never shown while in those scopes! This makes it very hard to debug them because one can't see the outside variables. One has to make a sort of local copy.
>
> e.g.,
>
> int x = 3; // Won't be seen while in foo
>
> void foo()
> {
>    // BP stopped here, can't see x in debug watches unless we do the following:
>    int tmpx = x;
> }
>
>
> --
> Best I can tell is that the stack frame bug occurs much less. Maybe 1/10th of the time(before it was every few seconds, now it's every minute maybe(although it might get worse after it gets worse).

Also, It seems that break points are not hit within meta code. If one uses static ifs much then one can't debug them. I realize that some of the code is compiled out, but that code can't create runtime bugs(because it was compiled out)..

So the remaining code from using the static code can still be compiled. Basically the compiler needs to keep track of static compile time code it optimizes out and sent that info to the debugger so it knows that there was suppose to be code there and where the actual run time code that was inside the static code went...

static if (...) // CT code, won't exist in binary but compiler can still emit it, basically pretending it exists as an if statement.
{
     int x = 43; // RT code, exists in the binary, should have a line number and BP cabable. We can put a BP on the static if and it should at least end here.
}
October 10, 2018
On Wednesday, 10 October 2018 at 17:40:49 UTC, Rainer Schuetze wrote:
>
>
> On 10/10/2018 09:21, James Japherson wrote:
>> On Wednesday, 10 October 2018 at 06:37:33 UTC, Rainer Schuetze wrote:
>>>
>>>
>>> On 08/10/2018 19:55, Rainer Schuetze wrote:
>>>>
>>>>
>>>> On 08/10/2018 17:16, James Japherson wrote:
>>>>> Basically I'm having lots of problems with 0.48.
>>>>>
>>>>> 1. I get that one error about the stack constantly. Usually happens when I hit '.' but sometimes not.
>>>>
>>>> I can reproduce with a combination of "static foreach" and "tupleof", I hope we can find a solution.
>>>>
>>>
>>> Please try the new beta: https://github.com/dlang/visuald/releases/tag/v0.48.0-beta2
>> 
>> Oh man! Almost! It worked for about 3 minutes! I thought I was going to get somewhere! It got me with the stack frame bug.
>
> Do you have some test code that you can share?
>
>> 
>> I'm having a bigger problem though, not sure I think this is always been a problem with visual D.
>> 
>> I can't see any outer variables in the debug windows. It seems lambda's and inner functions and global scope is never shown while in those scopes! This makes it very hard to debug them because one can't see the outside variables. One has to make a sort of local copy.
>> 
>> e.g.,
>> 
>> int x = 3; // Won't be seen while in foo
>> 
>> void foo()
>> {
>>    // BP stopped here, can't see x in debug watches unless we do the
>> following:
>>    int tmpx = x;
>> }
>> 
>
> Unfortunately it has always been this way: dmd only emits the context pointer "this" as a void*, while it could be a struct containing the captured variables. LDC might behave a bit better here, but has other quirks.
>
> Globals can be watched by specifying the fully qualified name, no import/lookup information is available otherwise. (There is a workaround that allows them to be seen in D functions that are part of the same scope so lookup can be derived from the fully qualified function name).

This makes it very difficult to do any debugging, basically impossible, when one is using lambdas and nesting functions and globals. It's like running blind. Delegates which capture the context are basically useless because you can never see that context in the debugger. Globals are somewhat useless because you can't see them in the debugger automatically(so you have to remember the name spelling, etc).

Something should be done about this! Surely it is not a hard problem!


Can hacks be done? Some way for visual D to get the context? Surely it knows the outer context because it can trace the stack. It should just have to work itself up the stack to get the locations of the functions and then, if it knows the stack structure(locals, which D should emit) then it can determine who and what and then add them to the watch as needed?

After all, all we are talking about here is a

Variable name, it's type, and it's value.


I'm also mainly talking about the locals, auto, and watch. Locals could be true locals, auto could include the total context and watch could automatically determine context(do a match, search to find the watched name in any ancestral match, could list for multiple matches, although there should only ever be one since D does not allow shadowing).

If this is too hard for Visual D, what does D itself need to make it happen?
IMO, debugging is a real pain because of this. To debug I one has to know the values, but one cannot get the values.

Even if Visual D had to use hacks, it is better than nothing.

e.g., if Visual D could remember outer variables(not sure how unless it tracked each function call then it could just display the values by caching them and then using the cached version, but this would lead to them not being consistent if changed inside. But it would be better than nothing. Put a BP at the start of the function and see the correct outside variable values then just note any changes.

Of course, if you could do that then it probably wouldn't be hard to just get the addresses so one could get the actual values.

If this is a limitation of D, could you ask any of the maintainers about getting the required info so it can be done? This is a sever limitation in D and makes debugging large programs impossible slow(orders of magnitude).

To simulate this effect require usually requires that I create temp variables connecting the dots(e.g., using local variable that is assigned the value of the global). I have to add, run the program, then remove the bloat. This has to happen for any outside variable.

I think though that Visual D can do this:

Because Visual D can see the stack, I can click on some ancestor call and it will show the variables in it(the locals I guess)..

So, really all Visual D needs to do is collect all that info and put it in the auto's. It seems to all be there, or at least a lot more.

Ok, it's not quite the same because of captures are not going to work for function pointers(they capture a different context than what the call stack).


Also, when visual D breaks due to an error, such as an assert, it doesn't jump to the actual line it says in the error message but usually, it seems, to the call location. This should be easy by juts matching the line number and source file in the error with that of the line/source in the program. The locations seem to accurately give the error but I have to manually go find it... sometimes it's in a different file making it slow.


Also, many times errors due to something in my program end up opening up debug libraries saying the error is in them when it is not. It would be nice to have a sort of "debug my code only" like .NET has.


Thanks.



October 12, 2018

On 11/10/2018 01:05, James Japherson wrote:
> On Wednesday, 10 October 2018 at 17:40:49 UTC, Rainer Schuetze wrote:
>>
>>
>> On 10/10/2018 09:21, James Japherson wrote:
>>> On Wednesday, 10 October 2018 at 06:37:33 UTC, Rainer Schuetze wrote:
>>>>
>>>>
>>>> On 08/10/2018 19:55, Rainer Schuetze wrote:
>>>>>
>>>>>
>>>>> On 08/10/2018 17:16, James Japherson wrote:
>>>>>> Basically I'm having lots of problems with 0.48.
>>>>>>
>>>>>> 1. I get that one error about the stack constantly. Usually happens when I hit '.' but sometimes not.
>>>>>
>>>>> I can reproduce with a combination of "static foreach" and "tupleof", I hope we can find a solution.
>>>>>
>>>>
>>>> Please try the new beta: https://github.com/dlang/visuald/releases/tag/v0.48.0-beta2
>>>
>>> Oh man! Almost! It worked for about 3 minutes! I thought I was going to get somewhere! It got me with the stack frame bug.
>>
>> Do you have some test code that you can share?
>>
>>>
>>> I'm having a bigger problem though, not sure I think this is always been a problem with visual D.
>>>
>>> I can't see any outer variables in the debug windows. It seems lambda's and inner functions and global scope is never shown while in those scopes! This makes it very hard to debug them because one can't see the outside variables. One has to make a sort of local copy.
>>>
>>> e.g.,
>>>
>>> int x = 3; // Won't be seen while in foo
>>>
>>> void foo()
>>> {
>>>    // BP stopped here, can't see x in debug watches unless we do the
>>> following:
>>>    int tmpx = x;
>>> }
>>>
>>
>> Unfortunately it has always been this way: dmd only emits the context pointer "this" as a void*, while it could be a struct containing the captured variables. LDC might behave a bit better here, but has other quirks.
>>
>> Globals can be watched by specifying the fully qualified name, no import/lookup information is available otherwise. (There is a workaround that allows them to be seen in D functions that are part of the same scope so lookup can be derived from the fully qualified function name).
> 
> This makes it very difficult to do any debugging, basically impossible, when one is using lambdas and nesting functions and globals. It's like running blind. Delegates which capture the context are basically useless because you can never see that context in the debugger. Globals are somewhat useless because you can't see them in the debugger automatically(so you have to remember the name spelling, etc).
> 
> Something should be done about this! Surely it is not a hard problem!
> 

Some guesswork could be added. See also https://issues.dlang.org/show_bug.cgi?id=18882

> 
> Can hacks be done? Some way for visual D to get the context? Surely it knows the outer context because it can trace the stack. It should just have to work itself up the stack to get the locations of the functions and then, if it knows the stack structure(locals, which D should emit) then it can determine who and what and then add them to the watch as needed?
> 
> After all, all we are talking about here is a
> 
> Variable name, it's type, and it's value.
> 
> 
> I'm also mainly talking about the locals, auto, and watch. Locals could be true locals, auto could include the total context and watch could automatically determine context(do a match, search to find the watched name in any ancestral match, could list for multiple matches, although there should only ever be one since D does not allow shadowing).
> 
> If this is too hard for Visual D, what does D itself need to make it
> happen?
> IMO, debugging is a real pain because of this. To debug I one has to
> know the values, but one cannot get the values.
> 
> Even if Visual D had to use hacks, it is better than nothing.
> 
> e.g., if Visual D could remember outer variables(not sure how unless it tracked each function call then it could just display the values by caching them and then using the cached version, but this would lead to them not being consistent if changed inside. But it would be better than nothing. Put a BP at the start of the function and see the correct outside variable values then just note any changes.
> 
> Of course, if you could do that then it probably wouldn't be hard to just get the addresses so one could get the actual values.
> 
> If this is a limitation of D, could you ask any of the maintainers about getting the required info so it can be done? This is a sever limitation in D and makes debugging large programs impossible slow(orders of magnitude).
> 
> To simulate this effect require usually requires that I create temp variables connecting the dots(e.g., using local variable that is assigned the value of the global). I have to add, run the program, then remove the bloat. This has to happen for any outside variable.
> 
> I think though that Visual D can do this:
> 
> Because Visual D can see the stack, I can click on some ancestor call and it will show the variables in it(the locals I guess)..
> 
> So, really all Visual D needs to do is collect all that info and put it in the auto's. It seems to all be there, or at least a lot more.
> 
> Ok, it's not quite the same because of captures are not going to work for function pointers(they capture a different context than what the call stack).

Because of this I think doing all the hacks above is not worth the trouble. It is a lot easier to fix it in the compiler, it just has to pass Walters debugger-phobia.

> 
> 
> Also, when visual D breaks due to an error, such as an assert, it doesn't jump to the actual line it says in the error message but usually, it seems, to the call location. This should be easy by juts matching the line number and source file in the error with that of the line/source in the program. The locations seem to accurately give the error but I have to manually go find it... sometimes it's in a different file making it slow.

It is sometimes impossible to correctly walk thestack without complete debug information. This is probably related: https://issues.dlang.org/show_bug.cgi?id=17811

> 
> 
> Also, many times errors due to something in my program end up opening up debug libraries saying the error is in them when it is not. It would be nice to have a sort of "debug my code only" like .NET has.

I guess this happens for templates that still get compiled into your object files with debug information. Or does it show disassembly for code without debug information? That might be easier to skip.
November 10, 2018
I have just released a new beta:

https://github.com/dlang/visuald/releases/tag/v0.48.0-beta3

Changes:

- VDServer refactoring
- experimental: option to enable semantic identifier highlighting (see
Tools->Options->Text Editor->D->Editor page)
- mago:
  - fix crash in VS if a value is marked expandable, but doesn't yield
any children
  - fix .ptr property of static array if it is a struct/class member
  - add option to disable strings to be expandable
  - support showing closure and capture variables as locals for dmd
2.084 (nightlies)



On 05/10/2018 14:41, Rainer Schuetze wrote:
> Hi,
> 
> I have prepared a beta for the next release of Visual D. Here are some highlights:
> 
> - fixed installation/uninstallation issues in VS2017
> - new VC project: allow adding C++ skeleton, fix some default settings
> - settings: removed some legacy settings and made scope clearer
> - dparser: support for "static foreach", fixed "find references",
> experimental "show value of constants in tooltip"
> - mago: fix crash in VS2017, shows return values of functions stepped over
> - fixed "Compile and Run" on selection
> - fixed help via F1
> 
> You can find the installer and more details here: https://github.com/dlang/visuald/releases/tag/v0.48.0-beta1
> 
> Rainer
November 13, 2018
On Saturday, 10 November 2018 at 08:50:53 UTC, Rainer Schuetze wrote:
> I have just released a new beta:
>
> https://github.com/dlang/visuald/releases/tag/v0.48.0-beta3
>
> Changes:
>
> - VDServer refactoring
> - experimental: option to enable semantic identifier highlighting (see
> Tools->Options->Text Editor->D->Editor page)
> - mago:
>   - fix crash in VS if a value is marked expandable, but doesn't yield
> any children
>   - fix .ptr property of static array if it is a struct/class member
>   - add option to disable strings to be expandable
>   - support showing closure and capture variables as locals for dmd
> 2.084 (nightlies)
>
>
>
> On 05/10/2018 14:41, Rainer Schuetze wrote:
>> Hi,
>> 
>> I have prepared a beta for the next release of Visual D. Here are some highlights:
>> 
>> - fixed installation/uninstallation issues in VS2017
>> - new VC project: allow adding C++ skeleton, fix some default settings
>> - settings: removed some legacy settings and made scope clearer
>> - dparser: support for "static foreach", fixed "find references",
>> experimental "show value of constants in tooltip"
>> - mago: fix crash in VS2017, shows return values of functions stepped over
>> - fixed "Compile and Run" on selection
>> - fixed help via F1
>> 
>> You can find the installer and more details here: https://github.com/dlang/visuald/releases/tag/v0.48.0-beta1
>> 
>> Rainer

I'm getting the "This breakpoint will not be hit. No symbols have been loaded" error after updating again. Seems something broke? dmdx86

Seems this is a reoccurring problem?
November 13, 2018

On 13/11/2018 02:23, Nierjerson wrote:
> On Saturday, 10 November 2018 at 08:50:53 UTC, Rainer Schuetze wrote:
>> I have just released a new beta:
>>
>> https://github.com/dlang/visuald/releases/tag/v0.48.0-beta3
>>
> 
> I'm getting the "This breakpoint will not be hit. No symbols have been loaded" error after updating again. Seems something broke? dmdx86
> 
> Seems this is a reoccurring problem?

I am not aware of changes in that area, but who knows...

It worked and still works with beta2?

With dmdx86 you mean building for Win32 OMF (COFF output disabled)? What
debug engine? Does it report converting the debug information while
building (see debug options)?