www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Visual D 0.48-beta1

reply Rainer Schuetze <r.sagitario gmx.de> writes:
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
Oct 05 2018
next sibling parent kinke <noone nowhere.com> writes:
Thx, no issues with VS 2017 anymore after a quick check.
Oct 05 2018
prev sibling next sibling parent reply James Japherson <JJ goolooking.com> writes:
On Friday, 5 October 2018 at 12:41:52 UTC, 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 just upgraded and now I'm constantly getting

A new guard page for the stack cannot be created

DParserCOMServer.

I upgraded from the linked file
Oct 07 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 07/10/2018 13:47, James Japherson wrote:

 On Friday, 5 October 2018 at 12:41:52 UTC, 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 just upgraded and now I'm constantly getting
 
 A new guard page for the stack cannot be created
 
 DParserCOMServer.





 
 I upgraded from the linked file


Please specify a few more details about your environment: VS ersion, OS,
etc.

Is this happening for a specific project or source code? Does it happen
for a new "Hello World" project, too?
Oct 07 2018
next sibling parent James Japherson <JJ goolooking.com> writes:
I installed 0.47 and tried intellisense and got an exception. 
I'll downgrade back to 0.46 which was working...

Seems that intellisense is broke. In 0.48 I did get the 
intellisense but on the same code with 0.46 it doesn't want to 
show up.

This is possibly because I'm using a static foreach to generate 
the structure in that case which 0.48 handled properly except it 
would crash most of the time.

(maybe the static foreach code added is buggy?)

0.46 doesn't crash though.
Oct 07 2018
prev sibling next sibling parent James Japherson <JJ goolooking.com> writes:
On Sunday, 7 October 2018 at 13:38:18 UTC, Rainer Schuetze wrote:

 On 07/10/2018 13:47, James Japherson wrote:

 On Friday, 5 October 2018 at 12:41:52 UTC, 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 just upgraded and now I'm constantly getting
 
 A new guard page for the stack cannot be created
 
 DParserCOMServer.





 
 I upgraded from the linked file


 Please specify a few more details about your environment: VS 
 ersion, OS, etc.

 Is this happening for a specific project or source code? Does 
 it happen for a new "Hello World" project, too?



Pretty much latest of everything. Obviously Windows by default. 
Any project.

This seems to happen when I use intellisense. Almost definitely 
an issue with any changes recently made. This did not happen with 
0.44.


It seems that if I do something like

obj. <- crashes when adding the .

repeat, sometimes crashes sometimes not. Eventually I get a list 
of the intellisense.

Not sure if it only happens with . but it definitely seems to 
trigger it regularly, making this release nearly impossible to 
use. I think it also happens outside of intellisense though.
Oct 07 2018
prev sibling parent reply James Japherson <JJ goolooking.com> writes:
On Sunday, 7 October 2018 at 13:38:18 UTC, Rainer Schuetze wrote:

 On 07/10/2018 13:47, James Japherson wrote:

 On Friday, 5 October 2018 at 12:41:52 UTC, 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 just upgraded and now I'm constantly getting
 
 A new guard page for the stack cannot be created
 
 DParserCOMServer.





 
 I upgraded from the linked file


 Please specify a few more details about your environment: VS 
 ersion, OS, etc.

 Is this happening for a specific project or source code? Does 
 it happen for a new "Hello World" project, too?



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.

2. error messages are pointing to lines below the actual error. 
Was very confusing to have D say the error is at line x when it 
is at line x - 3.

3. Not all debug symbols are showing in locals. foreach does not 
allow one to see symbols outside it, all kinds of problems here.

4. I tried downgrading to 0.46 which was working find yesterday 
and now it gives me an error about not being able to find 
user32.lib. Upgrading back to 0.47 fixes the user32.lib



So far 0.47 seems to be the best of 0.46 and 0.48. I haven't used 
it enough to know though.

Not sure what happened but 0.48 has become unusable. All kinds of 
minor problems.

Hopefully it is just a simple fix!
Oct 08 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.


 
 2. error messages are pointing to lines below the actual error. Was very
 confusing to have D say the error is at line x when it is at line x - 3.


I don't see this. If the error reported in the output window is already
wrong, it is the compiler to blaim. Visual D doesn't modify the output.

I see a one line offset with "Find References", though. (And a crash :-/ )


 3. Not all debug symbols are showing in locals. foreach does not allow
 one to see symbols outside it, all kinds of problems here.


That happens if the foreach body is translated to a delegate literal. It
should not be new to this version of Visual D and very much depends on
the compiler generated debug info.


 
 4. I tried downgrading to 0.46 which was working find yesterday and now
 it gives me an error about not being able to find user32.lib. Upgrading
 back to 0.47 fixes the user32.lib


I suspect this happened due to some changes to the default library
search paths, that are migrated upwards, but not downwards with 0.47 IIRC.


 
 
 So far 0.47 seems to be the best of 0.46 and 0.48. I haven't used it
 enough to know though.
 
 Not sure what happened but 0.48 has become unusable. All kinds of minor
 problems.
 
 Hopefully it is just a simple fix!


Let's hope so. Thanks for reporting.
Oct 08 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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
Oct 09 2018
next sibling parent reply James Japherson <JJ goolooking.com> writes:
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).
Oct 10 2018
next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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).
Oct 10 2018
next sibling parent James Japherson <JJ goolooking.com> writes:
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!! ;)
Oct 10 2018
prev sibling parent reply James Japherson <JJ goolooking.com> writes:
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.
Oct 10 2018
parent Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Oct 12 2018
prev sibling parent James Japherson <JJ goolooking.com> writes:
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.
}
Oct 10 2018
prev sibling next sibling parent James Japherson <JJ goolooking.com> writes:
It seems to be happening mainly on runs. Might help narrow it 
down.
Oct 10 2018
prev sibling parent James Japherson <JJ goolooking.com> writes:
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.
Oct 10 2018
prev sibling next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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
Nov 10 2018
next sibling parent reply Nierjerson <Nierjerson somewhere.com> writes:
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?
Nov 12 2018
parent Rainer Schuetze <r.sagitario gmx.de> writes:
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)?
Nov 13 2018
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
rc1 is now available:

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

Changes from beta3:
  * build system
    - fixed linking privatephobos.lib if intermediate dir
      different from output dir
  * mago
    - add option to disable strings to be expandable
    - support showing closure and capture variables as locals for
      dmd 2.084/nightly
  * editor
    - added outlining for case statements
    - implemented commands View.PopBrowsContext and ForwardBrowseContext
    - reindent if multiple lines added by completion
    - tweaked formatting for enumerators, struct and array initializers
    - added option to not indent case statements

Please report issues and regressions here or for component visuald at
https://issues.dlang.org/

Rainer

On 10/11/2018 09:50, 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
Nov 24 2018
parent kinke <noone nowhere.com> writes:
On Saturday, 24 November 2018 at 13:54:57 UTC, Rainer Schuetze 
wrote:

 rc1 is now available


Thanks!
Nov 25 2018
prev sibling parent reply Markus Pursche <pursche01 gmail.com> writes:
Hi Rainer, I wasn't sure exactly where to ask this, but I figured 
this is was as good of a place as any.

The new C++/D Project template looks absolutely amazing, it has 
never been this easy to get started with a C++ main function that 
can call D, especially on Windows. I was wondering how exactly 
this works in the background though, are you compiling to .obj 
files with the different compilers (MSVC+DMD) and then passing it 
to the linker, or are you creating a D static library and linking 
it that way behind the scenes?

I looked at the .vcxproj file and it looks very similar to 
"regular" .vcxproj files, could I edit my already existing C++ 
project (that uses a non-standard project template with a custom 
compiler, not MSVC) and just add the D parts and convert a C++ 
project to C++/D that way?

This might just be the last step needed to get more game 
developers to follow Remedy and start using D in their engines 
(alongside C++ at first), assuming that it actually is that easy 
to do with any kind of C++ project.

I'll stick around the #d IRC channel if you have any specific 
questions about what it is I want to do, but I'm not sure how 
much I should say here.
Dec 12 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 12/12/2018 11:25, Markus Pursche wrote:

 Hi Rainer, I wasn't sure exactly where to ask this, but I figured this
 is was as good of a place as any.
 
 The new C++/D Project template looks absolutely amazing, it has never
 been this easy to get started with a C++ main function that can call D,
 especially on Windows. I was wondering how exactly this works in the
 background though, are you compiling to .obj files with the different
 compilers (MSVC+DMD) and then passing it to the linker, or are you
 creating a D static library and linking it that way behind the scenes?


Visual D adds a new task "CompileD" to msbuild together with a new "Item
Type" that gets automatically assigned to items with extension .d. This
task creates object files that are added to the linker command line in
addition to some additional options like library search paths.


 
 I looked at the .vcxproj file and it looks very similar to "regular"
 .vcxproj files, could I edit my already existing C++ project (that uses
 a non-standard project template with a custom compiler, not MSVC) and
 just add the D parts and convert a C++ project to C++/D that way?
 


You can just drag a .d file into any VC project to integrate it with
compilation and linkage. The D compiler options page will appear
automatically. (Depending on what your code does you might have to add
the phobos library to the linker settings, but it is supposed to be
automatic, too).


 This might just be the last step needed to get more game developers to
 follow Remedy and start using D in their engines (alongside C++ at
 first), assuming that it actually is that easy to do with any kind of
 C++ project.
 
 I'll stick around the #d IRC channel if you have any specific questions
 about what it is I want to do, but I'm not sure how much I should say here.
Dec 12 2018
parent reply Michelle Long <HappyDance321 gmail.com> writes:
Small request on the latest release.

You added the ability to collapse case statements, which is nice. 
The only problem I'm having which is just annoying more than 
anything else is that the collapse bleeds over to the next case 
statement's header comments:


case 1:
....
break;


// Case 2
case2:


When collapsing case 1, the comment will get folded along with it.


As a simple work around I suggest:

You go to the next case(or default or closing }) and then 
backtrack to fight the last return, break, throw, or goto and 
then everything in between will either go with the second case, 
or be split up based "closeness" to the case statement.



the idea is to handle footer comments of the previous case:

case 1:
....
break;
// that was case 1

// Case 2
case2:


Here the nl will break the two apart but mainly because // Case 2 
is right next to case 2.



Or simply attack all connected comments preceding the case 
statement to the case statement(within scope of course).

Thanks.. Seems VD is starting to shape up! ;)
Dec 13 2018
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 14/12/2018 03:25, Michelle Long wrote:

 Small request on the latest release.
 
 You added the ability to collapse case statements, which is nice. The
 only problem I'm having which is just annoying more than anything else
 is that the collapse bleeds over to the next case statement's header
 comments:
 
 
 case 1:
 ....
 break;
 
 
 // Case 2
 case2:
 
 
 When collapsing case 1, the comment will get folded along with it.
 
 
 As a simple work around I suggest:
 
 You go to the next case(or default or closing }) and then backtrack to
 fight the last return, break, throw, or goto and then everything in
 between will either go with the second case, or be split up based
 "closeness" to the case statement.
 
 
 
 the idea is to handle footer comments of the previous case:
 
 case 1:
 ....
 break;
 // that was case 1
 
 // Case 2
 case2:
 
 
 Here the nl will break the two apart but mainly because // Case 2 is
 right next to case 2.
 
 
 
 Or simply attack all connected comments preceding the case statement to
 the case statement(within scope of course).
 
 Thanks.. Seems VD is starting to shape up! ;)


Yes, keeping the comment above the case makes sense. I guess it's very
uncommon to have a comment after the end of the previous case block (or
almost any block), but the newline rule sounds good, too.

In C++ I tend to add "// fallthrough" right there if I actually don't
want to break, but that's not how it works in D.
Dec 14 2018