www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Visual D 1.2.0-rc1 available

reply Rainer Schuetze <r.sagitario gmx.de> writes:
Hi,

I have just uploaded a new release candidate for Visual D at 
https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

Cheers,
Rainer
Nov 29 2021
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 29 November 2021 at 08:47:25 UTC, Rainer Schuetze 
wrote:
 Hi,

 I have just uploaded a new release candidate for Visual D at 
 https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

 Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

 Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

 Cheers,
 Rainer
THANK YOU
Nov 29 2021
prev sibling next sibling parent kinjal kishor <kinjalkishor gmail.com> writes:
On Monday, 29 November 2021 at 08:47:25 UTC, Rainer Schuetze 
wrote:
 Hi,

 I have just uploaded a new release candidate for Visual D at 
 https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

 Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

 Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

 Cheers,
 Rainer
Thank You very much. Did not looked in release section on GitHub as 1.1.0 is seen on project page. I find VS code somewhat cumbersome and prefer Visual Studio.
Dec 13 2021
prev sibling parent reply Complexity <Matters Universe.com> writes:
On Monday, 29 November 2021 at 08:47:25 UTC, Rainer Schuetze 
wrote:
 Hi,

 I have just uploaded a new release candidate for Visual D at 
 https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

 Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

 Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

 Cheers,
 Rainer
Visual D is crashing Visual Studio 2022 after doing a fresh install of both. This seems to be happening when debugging and adding breakpoints. Did not happen with 2019 so it's either the VisualD release(I think I was using the same) or due to 2022. I think simply trying to debug a program will give you the crash.
Dec 19 2021
next sibling parent reply Rumbu <rumbu rumbu.ro> writes:
On Sunday, 19 December 2021 at 16:53:44 UTC, Complexity wrote:
 On Monday, 29 November 2021 at 08:47:25 UTC, Rainer Schuetze 
 wrote:
 Hi,

 I have just uploaded a new release candidate for Visual D at 
 https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

 Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

 Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

 Cheers,
 Rainer
Visual D is crashing Visual Studio 2022 after doing a fresh install of both. This seems to be happening when debugging and adding breakpoints. Did not happen with 2019 so it's either the VisualD release(I think I was using the same) or due to 2022. I think simply trying to debug a program will give you the crash.
Debugging works for me in VS 2022. What is not working for me: - in x64 mode the linker cannot find phobos64.lib, I must add manually windows/lib64 to lib paths in the project configuration. - icons for visualdproj files are blank. - syntax highlighting does not work after several edits. It can be linked to dmdserver.exe, I end with 5-6 instances after some time. In VS2019 it still works like a charm, thank you Rainer for the good work.
Dec 19 2021
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 19/12/2021 21:47, Rumbu wrote:
 Debugging works for me in VS 2022.
 
 What is not working for me:
 - in x64 mode the linker cannot find phobos64.lib, I must add manually 
 windows/lib64 to lib paths in the project configuration.
Is this with the D specific projects (visualdproj), or the Visual C++ integration? I cannot reproduce it neither with DMD nor LDC. If the former, please enable verbose compilation to see what library paths are used for linking.
 - icons for visualdproj files are blank.
Indeed, I see it here, too.
 - syntax highlighting does not work after several edits. It can be 
 linked to dmdserver.exe, I end with 5-6 instances after some time.
I don't see dmdserver.exe crashing or restarting, but there seems to be something odd as it sometimes produces very few completions after initialization. Loading another file helped in this case.
 
 In VS2019 it still works like a charm, thank you Rainer for the good work.
 
Thanks, good to hear :-)
Dec 24 2021
parent reply rumbu <rumbu rumbu.ro> writes:
On Friday, 24 December 2021 at 11:06:42 UTC, Rainer Schuetze 
wrote:
 On 19/12/2021 21:47, Rumbu wrote:
 Debugging works for me in VS 2022.
 
 What is not working for me:
 - in x64 mode the linker cannot find phobos64.lib, I must add 
 manually windows/lib64 to lib paths in the project 
 configuration.
If the former, please enable verbose compilation to see what library paths are used for linking.
I looked into the build logs and there are 2 diferences when loading the same project: VS2019: ``` set LIB=C:\D\dmd2\windows\bin\..\lib64 ``` VS2022: ``` set LIB= ``` VS2019: ``` "C:\Program Files (x86)\VisualD\pipedmd.exe" -msmode -deps x64\Debug\WindowsApp11.lnkdep "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX86\x86\link.exe" C:\Users\Rumbu\source\repos\WindowsApp11\x64\Debug\WindowsApp11.link.rsp ``` VS2022: ``` "C:\Program Files (x86)\VisualD\pipedmd.exe" -msmode -deps x64\Debug\WindowsApp1.lnkdep link.exe C:\Users\Rumbu\source\repos\WindowsApp11\x64\Debug\WindowsApp11.link.rsp ```
 I don't see dmdserver.exe crashing or restarting, but there 
 seems to be something odd as it sometimes produces very few 
 completions after initialization. Loading another file helped 
 in this case.
Unfortunately, I cannot find a pattern, sometimes works for hours perfectly, sometimes it does basic syntax highlighting only (does not colorize recognized symbols, only keywords). Restarting doesn't help either, after some time it's comming back to the normal experience, irrespective of my actions (opening another doc, killing dmdserver or DParserComServer). Anyway, as a bottom line, it's more stable with DParserComServer than with dmdserver, tried both.
Dec 24 2021
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 24/12/2021 19:13, rumbu wrote:
 On Friday, 24 December 2021 at 11:06:42 UTC, Rainer Schuetze wrote:
 On 19/12/2021 21:47, Rumbu wrote:
 Debugging works for me in VS 2022.

 What is not working for me:
 - in x64 mode the linker cannot find phobos64.lib, I must add 
 manually windows/lib64 to lib paths in the project configuration.
If the former, please enable verbose compilation to see what library paths are used for linking.
I looked into the build logs and there are 2 diferences when loading the same project: VS2019: ``` set LIB=C:\D\dmd2\windows\bin\..\lib64 ``` VS2022: ``` set LIB=
This setting is read from the [Environment64] section in sc.ini in the dmd bin folder. Are you using different compiler versions in the different VS?
 ```
 
 
 VS2019:
 ```
 "C:\Program Files (x86)\VisualD\pipedmd.exe" -msmode -deps 
 x64\Debug\WindowsApp11.lnkdep "C:\Program Files (x86)\Microsoft Visual 
 Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX86\x86\link.exe" 
  C:\Users\Rumbu\source\repos\WindowsApp11\x64\Debug\WindowsApp11.link.rsp
 ```
 
 VS2022:
 ```
 "C:\Program Files (x86)\VisualD\pipedmd.exe" -msmode -deps 
 x64\Debug\WindowsApp1.lnkdep link.exe 
  C:\Users\Rumbu\source\repos\WindowsApp11\x64\Debug\WindowsApp11.link.rsp
 ```
 
This suggests that sc.ini isn't found at all. In that case the setting from Tools->Options->Projects and Solutions->Visual D Settings->DMD Directories->x64->Linker isn't applied (which is a bug). Please verify your settings on that page.
 
 I don't see dmdserver.exe crashing or restarting, but there seems to 
 be something odd as it sometimes produces very few completions after 
 initialization. Loading another file helped in this case.
Unfortunately, I cannot find a pattern, sometimes works for hours perfectly, sometimes it does basic syntax highlighting only (does not colorize recognized symbols, only keywords). Restarting doesn't help either, after some time it's comming back to the normal experience, irrespective of my actions (opening another doc, killing dmdserver or DParserComServer). Anyway, as a bottom line, it's more stable with DParserComServer than with dmdserver, tried both.
hasn't been updated in years, so I consider it legacy. I'd recommend it only to people that cannot run the dmdserver 64-bit executable. Being I suspect that crashes depend on the actual code being analyzed. While editing, bogus code can crash the dmd frontend or cause ICEs. Maybe some logging can be added that allows to analyze them better.
Dec 25 2021
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 19/12/2021 17:53, Complexity wrote:
 On Monday, 29 November 2021 at 08:47:25 UTC, Rainer Schuetze wrote:
 Hi,

 I have just uploaded a new release candidate for Visual D at 
 https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

 Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

 Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

 Cheers,
 Rainer
Visual D is crashing Visual Studio 2022 after doing a fresh install of both. This seems to be happening when debugging and adding breakpoints. Did not happen with 2019 so it's either the VisualD release(I think I was using the same) or due to 2022. I think simply trying to debug a program will give you the crash.
Cannot reproduce here, e.g. on the dmdserver executable. Do you find a crashdump of devenv.exe in c:\Users\name\AppData\CrashDumps?
Dec 24 2021
parent reply Complexity <C D.com> writes:
On Friday, 24 December 2021 at 11:12:51 UTC, Rainer Schuetze 
wrote:
 On 19/12/2021 17:53, Complexity wrote:
 On Monday, 29 November 2021 at 08:47:25 UTC, Rainer Schuetze 
 wrote:
 Hi,

 I have just uploaded a new release candidate for Visual D at 
 https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

 Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

 Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

 Cheers,
 Rainer
Visual D is crashing Visual Studio 2022 after doing a fresh install of both. This seems to be happening when debugging and adding breakpoints. Did not happen with 2019 so it's either the VisualD release(I think I was using the same) or due to 2022. I think simply trying to debug a program will give you the crash.
Cannot reproduce here, e.g. on the dmdserver executable. Do you find a crashdump of devenv.exe in c:\Users\name\AppData\CrashDumps?
No, it doens't produce it, although I had a few crash dumps from 12-30-21 involving the dmd server so maybe it was them. c:\Users\name\AppData\Local\CrashDumps BTW It does it both with x64 and x86 although I tried to run it with buggy code(trying to modify some code and had a bug(array accessor) and it crashed in to the debugger but at the entrypoint code with no real information about what happened(but since it was a minor change and an array index error(length instead of length-1 basically) it was obvious where the bug was. So without BP's it does go in to the debugger, more or less but with BP's it crashes VS entirely. This is 100% due to upgrading to Visual Studio 2022. I tried another project and I get "cannot launch debbugger on ... hr 89710016". I also get the error Severity Code Description Project File Line Suppression State Error Error: file `"Plotter.py"` cannot be found or not in a path specified with `-J` C:\Projects\XXX\XXX.d(125): Path(s) searched (as provided by `-J`): C:\Projects\XXX\XXX.d 125 Which never occurred before upgrading and seems to not stop the program from working(I have the -J and since it's compiling it is finding the file so this seems to be another bug, maybe related). Clearly something is off. I'm pretty sure just a few days ago I was able to run that same project(a different one and a new project I created recently under the new VS) so the issue with launching the debugger maybe because it crashed when I was trying to debug the first project and now it can't launch. I'll reboot and try again later. (The reason I say it must have worked is because I had a BP set in the project and don't remember it not working at all) So maybe it is an issue with debug information in projects created in previous versions of VS that are not translating debug information correctly to newer projects? If you tried it on a fresh project maybe open up an old one and see. (although I do think that the project I used was old but I heavily modified it) Almost surely some type of memory access issue given the nature of the crash. What happens when I place a breakpoint then run the program it does show the code and the yellow arrow on top of the red BP disk and then it shows the crash dialog about "The instruction at ... references memory at .... The memory could not be written.". If I try to debug it then it opens up a new VS with the devenv.exe but nothing really is going on and then if I click start debugging it will run VS. If I open up the project then it says an exception is thrown with "Exception thrown at .... (comctl32.dll) in devenv.exe: 0xC00000005: Access violation writing location .... It also says comctl32.pdb not loaded but not sure if that has anything to do with it. Does any of this make any sense? Maybe the comctl32.dll is corrupted or versioned wrong or something?
Jan 11
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 12/01/2022 05:41, Complexity wrote:
 On Friday, 24 December 2021 at 11:12:51 UTC, Rainer Schuetze wrote:
 On 19/12/2021 17:53, Complexity wrote:
 Visual D is crashing Visual Studio 2022 after doing a fresh install 
 of both. This seems to be happening when debugging and adding 
 breakpoints. Did not happen with 2019 so it's either the VisualD 
 release(I think I was using the same) or due to 2022.

 I think simply trying to debug a program will give you the crash.
Cannot reproduce here, e.g. on the dmdserver executable. Do you find a crashdump of devenv.exe in c:\Users\name\AppData\CrashDumps?
No, it doens't produce it, although I had a few crash dumps from 12-30-21 involving the dmd server so maybe it was them.
I forgot that writing the dumps is not enabled by default. Here's a description of the necessary registry entries to enable it: https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps The next Visual D installer will enable it for dmdserver.exe, but not for other applications.
 
 c:\Users\name\AppData\Local\CrashDumps BTW
 
 It does it both with x64 and x86 although I tried to run it with buggy 
 code(trying to modify some code and had a bug(array accessor) and it 
 crashed in to the debugger but at the entrypoint code with no real 
 information about what happened(but since it was a minor change and an 
 array index error(length instead of length-1 basically) it was obvious 
 where the bug was. So without BP's it does go in to the debugger, more 
 or less but with BP's it crashes VS entirely.
 
 This is 100% due to upgrading to Visual Studio 2022. I tried another 
 project and I get "cannot launch debbugger on ... hr 89710016".
Are you using the visualdproj format projects or the integration with VC++ projects. If the former, don't use the legacy "Mago" debug engine, it is not supported in a 64-bit environment like VS 2022 (though unfortunately still the default for new projects). Both "Visual Studio" debug engines integrate the Mago debugger extension.
 I also get the error
 Severity    Code    Description    Project    File    Line    
 Suppression State
 Error        Error: file `"Plotter.py"` cannot be found or not in a
path 
 specified with `-J`
 C:\Projects\XXX\XXX.d(125): Path(s) searched (as provided by 
 `-J`):        C:\Projects\XXX\XXX.d    125
This seems unrelated and is likely some option -J missing within the language server.
 
 Which never occurred before upgrading and seems to not stop the program 
 from working(I have the -J and since it's compiling it is finding the 
 file so this seems to be another bug, maybe related).
 
 Clearly something is off. I'm pretty sure just a few days ago I was able 
 to run that same project(a different one and a new project I created 
 recently under the new VS) so the issue with launching the debugger 
 maybe because it crashed when I was trying to debug the first project 
 and now it can't launch.
 
 I'll reboot and try again later. (The reason I say it must have worked 
 is because I had a BP set in the project and don't remember it not 
 working at all)
 
 So maybe it is an issue with debug information in projects created in 
 previous versions of VS that are not translating debug information 
 correctly to newer projects?
 
 If you tried it on a fresh project maybe open up an old one and see. 
 (although I do think that the project I used was old but I heavily 
 modified it)
 
 Almost surely some type of memory access issue given the nature of the 
 crash.
Cannot reproduce with some sample projects, e.g. the Visual D istself or the D compiler. I suspect it depends on the variables being shown in the Locals/Auto Window.
 
 What happens when I place a breakpoint then run the program it does show 
 the code and the yellow arrow on top of the red BP disk and then it 
 shows the crash dialog about "The instruction at ... references memory 
 at .... The memory could not be written.".
 
 If I try to debug it then it opens up a new VS with the devenv.exe but 
 nothing really is going on and then if I click start debugging it will 
 run VS. If I open up the project then it says an exception is thrown 
 with "Exception thrown at .... (comctl32.dll) in devenv.exe: 
 0xC00000005: Access violation writing location ....
 
 It also says comctl32.pdb not loaded but not sure if that has anything 
 to do with it.
 
 Does any of this make any sense? Maybe the comctl32.dll is corrupted or 
 versioned wrong or something?
Hard to say without a full stack trace or dump. Missing symbols for the last release, please retry with the next one.
Jan 14