www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Visual D 1.0.0 released

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

after having passed the 10 year anniversary of public availability
recently, it is finally time to release version 1.0 of Visual D, the
Visual Studio extension that adds D language support to VS 2008-2019.

You can find the installer at
http://rainers.github.io/visuald/visuald/StartPage.html

Highlights from this release:

- semantic engine based on dmd front end now enabled by default and
updated to 2.092. If you are low on memory or run a 32-bit Windows, you
should switch back to the legacy engine.

- debugger extension mago will now evaluate struct or class properties
(methods or fields) __debugOverview, __debugExpanded and __debugTextView
to customize the debugger display. mago can even display forward ranges
as a list, but that is currently rather slow, so it is disabled by
default (see debugger options).

- the bar on the top of the edit window now displays the current edit
scope and allows faster navigation within a source file (needs the dmd
based engine)

- ever wondered how to navigate to the type of a variable declared by
`auto` inference? clicking an identifier in a tool tip from intellisense
will now jump to its definition (only with the dmd based engine)

See https://rainers.github.io/visuald/visuald/VersionHistory.html for
the complete list of changes.

Cheers,
Rainer
Jul 04
next sibling parent reply Manu <turkeyman gmail.com> writes:
This is huge!

Congrats on the super cool milestone with a bunch of really great new stuff.
Thanks so much for your tireless work Rainer!
I wouldn't be here without all your effort on this.

On Sat, Jul 4, 2020 at 11:05 PM Rainer Schuetze via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 Hello,

 after having passed the 10 year anniversary of public availability
 recently, it is finally time to release version 1.0 of Visual D, the
 Visual Studio extension that adds D language support to VS 2008-2019.

 You can find the installer at
 http://rainers.github.io/visuald/visuald/StartPage.html

 Highlights from this release:

 - semantic engine based on dmd front end now enabled by default and
 updated to 2.092. If you are low on memory or run a 32-bit Windows, you
 should switch back to the legacy engine.

 - debugger extension mago will now evaluate struct or class properties
 (methods or fields) __debugOverview, __debugExpanded and __debugTextView
 to customize the debugger display. mago can even display forward ranges
 as a list, but that is currently rather slow, so it is disabled by
 default (see debugger options).

 - the bar on the top of the edit window now displays the current edit
 scope and allows faster navigation within a source file (needs the dmd
 based engine)

 - ever wondered how to navigate to the type of a variable declared by
 `auto` inference? clicking an identifier in a tool tip from intellisense
 will now jump to its definition (only with the dmd based engine)

 See https://rainers.github.io/visuald/visuald/VersionHistory.html for
 the complete list of changes.

 Cheers,
 Rainer
Jul 04
parent reply greatsam4sure <greatsam4sure yahoo.com> writes:
On Saturday, 4 July 2020 at 14:42:05 UTC, Manu wrote:
 This is huge!

 Congrats on the super cool milestone with a bunch of really 
 great new stuff.
 Thanks so much for your tireless work Rainer!
 I wouldn't be here without all your effort on this.

 On Sat, Jul 4, 2020 at 11:05 PM Rainer Schuetze via 
 Digitalmars-d-announce < digitalmars-d-announce puremagic.com> 
 wrote:

 Hello,

 after having passed the 10 year anniversary of public 
 availability recently, it is finally time to release version 
 1.0 of Visual D, the Visual Studio extension that adds D 
 language support to VS 2008-2019.

 You can find the installer at 
 http://rainers.github.io/visuald/visuald/StartPage.html

 Highlights from this release:

 - semantic engine based on dmd front end now enabled by 
 default and updated to 2.092. If you are low on memory or run 
 a 32-bit Windows, you should switch back to the legacy engine.

 - debugger extension mago will now evaluate struct or class 
 properties (methods or fields) __debugOverview, 
 __debugExpanded and __debugTextView to customize the debugger 
 display. mago can even display forward ranges as a list, but 
 that is currently rather slow, so it is disabled by default 
 (see debugger options).

 - the bar on the top of the edit window now displays the 
 current edit scope and allows faster navigation within a 
 source file (needs the dmd based engine)

 - ever wondered how to navigate to the type of a variable 
 declared by `auto` inference? clicking an identifier in a tool 
 tip from intellisense will now jump to its definition (only 
 with the dmd based engine)

 See 
 https://rainers.github.io/visuald/visuald/VersionHistory.html 
 for the complete list of changes.

 Cheers,
 Rainer
Each time run visualD project I get this error. I really did not know what i am not doing well. I will appreciate your help Build Log Building Win32\Debug\WindowsApp2.exe Command Line set PATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\bin\HostX86\x86;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE;C:\Program Files (x86)\Windows Kits\10\bin;C:\D\dmd-2.093.0\windows\bin;%PATH% set DMD_LIB=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\lib\x86;C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\ucrt\x86 set VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\ set VCTOOLSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\ set VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\ set WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\ set WindowsSdkVersion=10.0.18362.0 set UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10\ set UCRTVersion=10.0.18362.0 "C:\Program Files (x86)\VisualD\pipedmd.exe" -deps Win32\Debug\WindowsApp2.dep dmd -debug -m32mscoff -g -gf -X -Xf"Win32\Debug\WindowsApp2.json" -c -of"Win32\Debug\WindowsApp2.obj" WindowsApp2.d if %errorlevel% neq 0 goto reportError set LIB=C:\D\dmd-2.093.0\windows\bin\..\lib32mscoff echo. > C:\Users\great\source\repos\WindowsApp2\Win32\Debug\WindowsApp2.link.rsp echo "Win32\Debug\WindowsApp2.obj" /OUT:"Win32\Debug\WindowsApp2.exe" user32.lib >> C:\Users\great\source\repos\WindowsApp2\Win32\Debug\WindowsApp2.link.rsp echo kernel32.lib >> C:\Users\great\source\repos\WindowsApp2\Win32\Debug\WindowsApp2.link.rsp echo legacy_stdio_definitions.lib /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\lib\x86" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\ucrt\x86" /DEBUG /PDB:"Win32\Debug\WindowsApp2.pdb" /INCREMENTAL:NO /NOLOGO /NODEFAULTLIB:libcmt libcmtd.lib /SUBSYSTEM:CONSOLE >> C:\Users\great\source\repos\WindowsApp2\Win32\Debug\WindowsApp2.link.rsp "C:\Program Files (x86)\VisualD\mb2utf16.exe" C:\Users\great\source\repos\WindowsApp2\Win32\Debug\WindowsApp2.link.rsp "C:\Program Files (x86)\VisualD\pipedmd.exe" -msmode -deps Win32\Debug\WindowsApp2.lnkdep "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\bin\HostX86\x86\link.exe" C:\Users\great\source\repos\WindowsApp2\Win32\Debug\WindowsApp2.link.rsp if %errorlevel% neq 0 goto reportError if not exist "Win32\Debug\WindowsApp2.exe" (echo "Win32\Debug\WindowsApp2.exe" not created! && goto reportError) goto noError :reportError echo Building Win32\Debug\WindowsApp2.exe failed! :noError Output LINK : fatal error LNK1181: cannot open input file 'user32.lib' Building Win32\Debug\WindowsApp2.exe failed!
Jul 12
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 12/07/2020 11:11, greatsam4sure wrote:
[...]
 set WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\
 set WindowsSdkVersion=10.0.18362.0
 set UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10\
 set UCRTVersion=10.0.18362.0
[...]
 echo legacy_stdio_definitions.lib /LIBPATH:"C:\Program Files
 (x86)\Microsoft Visual
 Studio\2019\Community\VC\Tools\MSVC\14.24.28314\lib\x86"
 /LIBPATH:"C:\Program Files (x86)\Windows
 Kits\10\Lib\10.0.18362.0\ucrt\x86"
[...]
 
 LINK : fatal error LNK1181: cannot open input file 'user32.lib'
 Building Win32\Debug\WindowsApp2.exe failed!
I suspect you don't have the Windows SDK installed with Visual Studio. user32.lib is usually found in "C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x86", but that path is not passed on the command line with /LIBPATH.
Jul 12
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 12/07/2020 23:35, Rainer Schuetze wrote:
 
 
 On 12/07/2020 11:11, greatsam4sure wrote:
 [...]
 set WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\
 set WindowsSdkVersion=10.0.18362.0
 set UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10\
 set UCRTVersion=10.0.18362.0
[...]
 echo legacy_stdio_definitions.lib /LIBPATH:"C:\Program Files
 (x86)\Microsoft Visual
 Studio\2019\Community\VC\Tools\MSVC\14.24.28314\lib\x86"
 /LIBPATH:"C:\Program Files (x86)\Windows
 Kits\10\Lib\10.0.18362.0\ucrt\x86"
[...]
 LINK : fatal error LNK1181: cannot open input file 'user32.lib'
 Building Win32\Debug\WindowsApp2.exe failed!
I suspect you don't have the Windows SDK installed with Visual Studio. user32.lib is usually found in "C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x86", but that path is not passed on the command line with /LIBPATH.
On second thought: if you installed the SDK after Visual D, the settings in "Tools -> Options -> Projects and Solutions -> Visual D Settings -> DMD directories -> Win32 COFF32 -> Library Paths" might not reflect that (it should contain something like $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86). You can also click "Reset Settings" on the Visual D settings page to correct that.
Jul 12
parent reply Greatsam4sure <greatsam4sure yahoo.com> writes:
On Monday, 13 July 2020 at 06:48:02 UTC, Rainer Schuetze wrote:
 On 12/07/2020 23:35, Rainer Schuetze wrote:
 
 
 On 12/07/2020 11:11, greatsam4sure wrote:
 [...]
 [...]
[...]
 [...]
[...]
 [...]
I suspect you don't have the Windows SDK installed with Visual Studio. user32.lib is usually found in "C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x86", but that path is not passed on the command line with /LIBPATH.
On second thought: if you installed the SDK after Visual D, the settings in "Tools -> Options -> Projects and Solutions -> Visual D Settings -> DMD directories -> Win32 COFF32 -> Library Paths" might not reflect that (it should contain something like $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86). You can also click "Reset Settings" on the Visual D settings page to correct that.
Thanks a lot. I will look into that today
Jul 13
parent greatsam4sure <greatsam4sure yahoo.com> writes:
On Monday, 13 July 2020 at 10:27:10 UTC, Greatsam4sure wrote:
 On Monday, 13 July 2020 at 06:48:02 UTC, Rainer Schuetze wrote:
 On 12/07/2020 23:35, Rainer Schuetze wrote:
 [...]
On second thought: if you installed the SDK after Visual D, the settings in "Tools -> Options -> Projects and Solutions -> Visual D Settings -> DMD directories -> Win32 COFF32 -> Library Paths" might not reflect that (it should contain something like $(WindowsSdkDir)lib\$(WindowsSdkVersion)\um\x86). You can also click "Reset Settings" on the Visual D settings page to correct that.
Thanks a lot. I will look into that today
thanks a lot. I have to install windows sdk manually and click reset in visual D setting page for the project to compile and run.
Jul 15
prev sibling next sibling parent reply Arafel <er.krali gmail.com> writes:
On 4/7/20 15:00, Rainer Schuetze wrote:
 Hello,
 
 after having passed the 10 year anniversary of public availability
 recently, it is finally time to release version 1.0 of Visual D, the
 Visual Studio extension that adds D language support to VS 2008-2019.
 
 You can find the installer at
 http://rainers.github.io/visuald/visuald/StartPage.html
 
 Highlights from this release:
 
 - semantic engine based on dmd front end now enabled by default and
 updated to 2.092. If you are low on memory or run a 32-bit Windows, you
 should switch back to the legacy engine.
 
 - debugger extension mago will now evaluate struct or class properties
 (methods or fields) __debugOverview, __debugExpanded and __debugTextView
 to customize the debugger display. mago can even display forward ranges
 as a list, but that is currently rather slow, so it is disabled by
 default (see debugger options).
 
 - the bar on the top of the edit window now displays the current edit
 scope and allows faster navigation within a source file (needs the dmd
 based engine)
 
 - ever wondered how to navigate to the type of a variable declared by
 `auto` inference? clicking an identifier in a tool tip from intellisense
 will now jump to its definition (only with the dmd based engine)
 
 See https://rainers.github.io/visuald/visuald/VersionHistory.html for
 the complete list of changes.
 
 Cheers,
 Rainer
 
Looks great! I could only see windows installers though, and at first sight it seems to be Win only... is there any chance it would work with VSCode for linux / VSCodium (even if built manually)?
Jul 04
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 04/07/2020 17:16, Arafel wrote:
 On 4/7/20 15:00, Rainer Schuetze wrote:
 Hello,

 after having passed the 10 year anniversary of public availability
 recently, it is finally time to release version 1.0 of Visual D, the
 Visual Studio extension that adds D language support to VS 2008-2019.

 You can find the installer at
 http://rainers.github.io/visuald/visuald/StartPage.html

 Highlights from this release:

 - semantic engine based on dmd front end now enabled by default and
 updated to 2.092. If you are low on memory or run a 32-bit Windows, you
 should switch back to the legacy engine.

 - debugger extension mago will now evaluate struct or class properties
 (methods or fields) __debugOverview, __debugExpanded and __debugTextView
 to customize the debugger display. mago can even display forward ranges
 as a list, but that is currently rather slow, so it is disabled by
 default (see debugger options).

 - the bar on the top of the edit window now displays the current edit
 scope and allows faster navigation within a source file (needs the dmd
 based engine)

 - ever wondered how to navigate to the type of a variable declared by
 `auto` inference? clicking an identifier in a tool tip from intellisense
 will now jump to its definition (only with the dmd based engine)

 See https://rainers.github.io/visuald/visuald/VersionHistory.html for
 the complete list of changes.

 Cheers,
 Rainer
Looks great! I could only see windows installers though, and at first sight it seems to be Win only... is there any chance it would work with VSCode for linux / VSCodium (even if built manually)?
Indeed, this is Windows only. Visual Studio Code is a different platform than Visual Studio. Not sure why Microsoft named them so that they are easily confused.
Jul 04
prev sibling next sibling parent kinke <noone nowhere.com> writes:
Thanks a lot, Rainer!
Jul 04
prev sibling next sibling parent reply user1234 <user1234 12.de> writes:
On Saturday, 4 July 2020 at 13:00:16 UTC, Rainer Schuetze wrote:
 Hello,

 after having passed the 10 year anniversary of public 
 availability recently, it is finally time to release version 
 1.0 of Visual D, the Visual Studio extension that adds D 
 language support to VS 2008-2019.

 You can find the installer at 
 http://rainers.github.io/visuald/visuald/StartPage.html

 Highlights from this release:

 - semantic engine based on dmd front end now enabled by default 
 and updated to 2.092. If you are low on memory or run a 32-bit 
 Windows, you should switch back to the legacy engine.

 - debugger extension mago will now evaluate struct or class 
 properties (methods or fields) __debugOverview, __debugExpanded 
 and __debugTextView to customize the debugger display. mago can 
 even display forward ranges as a list, but that is currently 
 rather slow, so it is disabled by default (see debugger 
 options).

 - the bar on the top of the edit window now displays the 
 current edit scope and allows faster navigation within a source 
 file (needs the dmd based engine)

 - ever wondered how to navigate to the type of a variable 
 declared by `auto` inference? clicking an identifier in a tool 
 tip from intellisense will now jump to its definition (only 
 with the dmd based engine)

 See 
 https://rainers.github.io/visuald/visuald/VersionHistory.html 
 for the complete list of changes.

 Cheers,
 Rainer
congratulation for this milestone. In open source software people often stagnate forever in their 0.y.z versions so this is wise decision, also because as it's not a library the semver rules matter less. This would have been worth a post in D.announce but D.learn is nice too I suppose ;)
Jul 04
parent user1234 <user1234 12.de> writes:
On Saturday, 4 July 2020 at 22:25:06 UTC, user1234 wrote:
 On Saturday, 4 July 2020 at 13:00:16 UTC, Rainer Schuetze wrote:
 This would have been worth a post in D.announce but D.learn is 
 nice too I suppose ;)
The post appears in the two sections for some reason so there's no problem actually.
Jul 04
prev sibling next sibling parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2020-07-04 13:00:16 +0000, Rainer Schuetze said:

 after having passed the 10 year anniversary of public availability
 recently, it is finally time to release version 1.0 of Visual D, the
 Visual Studio extension that adds D language support to VS 2008-2019.
Even I don't use an IDE, the debugger support alone is so valuable that I can't imagine wokring without it... Great job! -- Robert M. MŁnch http://www.saphirion.com smarter | better | faster
Jul 05
prev sibling next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 04/07/2020 15:00, Rainer Schuetze wrote:
 - debugger extension mago will now evaluate struct or class properties
 (methods or fields) __debugOverview, __debugExpanded and __debugTextView
 to customize the debugger display. mago can even display forward ranges
 as a list, but that is currently rather slow, so it is disabled by
 default (see debugger options).
 
I have added some documentation and screenshots here: https://rainers.github.io/visuald/visuald/Debugging.html#customization
Jul 05
parent Arjan <arjan ask.me.to> writes:
On Sunday, 5 July 2020 at 19:02:23 UTC, Rainer Schuetze wrote:
 I have added some documentation and screenshots here: 
 https://rainers.github.io/visuald/visuald/Debugging.html#customization
Thank you very much, Rainer. Your efforts on this and the gc are really appreciated.
Jul 05
prev sibling next sibling parent IGotD- <nise nise.com> writes:
On Saturday, 4 July 2020 at 13:00:16 UTC, Rainer Schuetze wrote:
 Cheers,
 Rainer
I installed it but I cannot choose a D project when creating a new project. I have VS2019 community edition but I'm running as a user without admin rights. If I use an account with admin rights, then I can actually choose a D project.
Jul 06
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Very nice!

Please consider writing an article about your work!
Jul 07
prev sibling parent reply JN <666total wp.pl> writes:
On Saturday, 4 July 2020 at 13:00:16 UTC, Rainer Schuetze wrote:
 See 
 https://rainers.github.io/visuald/visuald/VersionHistory.html 
 for the complete list of changes.

 Cheers,
 Rainer
Anyone who uses VisualD and Code-D can compare the two? (Yes, I know the difference between Visual Studio and Visual Studio Code).
Jul 07
parent reply Manu <turkeyman gmail.com> writes:
On Tue, Jul 7, 2020 at 10:00 PM JN via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On Saturday, 4 July 2020 at 13:00:16 UTC, Rainer Schuetze wrote:
 See
 https://rainers.github.io/visuald/visuald/VersionHistory.html
 for the complete list of changes.

 Cheers,
 Rainer
Anyone who uses VisualD and Code-D can compare the two? (Yes, I know the difference between Visual Studio and Visual Studio Code).
The difference is night vs day... VisualD is, by far, like REALLY FAR, the most mature and useful IDE and debug environment for D. TL;DR: if you are a D dev, and you use Windows, you should definitely try Visual Studio + VisualD. I for one couldn't work without it!
Jul 07
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/7/2020 6:26 PM, Manu wrote:
 The difference is night vs day... VisualD is, by far, like REALLY FAR, the
most 
 mature and useful IDE and debug environment for D.
 TL;DR: if you are a D dev, and you use Windows, you should definitely try
Visual 
 Studio + VisualD. I for one couldn't work without it!
One great thing about Rainer doing VisualD is he has leveraged that to make crucial changes to dmd's output to better work with the Visual debugger.
Jul 08
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 08/07/2020 10:11, Walter Bright wrote:
 On 7/7/2020 6:26 PM, Manu wrote:
 The difference is night vs day... VisualD is, by far, like REALLY FAR,
 the most mature and useful IDE and debug environment for D.
 TL;DR: if you are a D dev, and you use Windows, you should definitely
 try Visual Studio + VisualD. I for one couldn't work without it!
One great thing about Rainer doing VisualD is he has leveraged that to make crucial changes to dmd's output to better work with the Visual debugger.
My first open source project was cv2pdb, a tool that converts old-style CodeView debug information generated by optlink to a PDB file. Now that this functionality is more or less available in dmd itself when compiling to COFF object files, cv2pdb seems to be more popular among C++ people using gcc on Windows, because it also allows to convert DWARF to PDB.
Jul 09
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/9/2020 11:21 PM, Rainer Schuetze wrote:
 My first open source project was cv2pdb, a tool that converts old-style
 CodeView debug information generated by optlink to a PDB file. Now that
 this functionality is more or less available in dmd itself when
 compiling to COFF object files, cv2pdb seems to be more popular among
 C++ people using gcc on Windows, because it also allows to convert DWARF
 to PDB.
I hope cv2pdb is in D, as that is a fine way to get C++ people used to D!
Jul 10
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 10/07/2020 9:04 PM, Walter Bright wrote:
 I hope cv2pdb is in D, as that is a fine way to get C++ people used to D!
https://github.com/rainers/cv2pdb Nope.
Jul 10
prev sibling next sibling parent reply Greatsam4sure <greatsam4sure yahoo.com> writes:
On Wednesday, 8 July 2020 at 01:26:55 UTC, Manu wrote:
 On Tue, Jul 7, 2020 at 10:00 PM JN via Digitalmars-d-announce < 
 digitalmars-d-announce puremagic.com> wrote:

 On Saturday, 4 July 2020 at 13:00:16 UTC, Rainer Schuetze 
 wrote:
 See 
 https://rainers.github.io/visuald/visuald/VersionHistory.html for the complete
list of changes.

 Cheers,
 Rainer
Anyone who uses VisualD and Code-D can compare the two? (Yes, I know the difference between Visual Studio and Visual Studio Code).
The difference is night vs day... VisualD is, by far, like REALLY FAR, the most mature and useful IDE and debug environment for D. TL;DR: if you are a D dev, and you use Windows, you should definitely try Visual Studio + VisualD. I for one couldn't work without it!
VodualD is great. I appreciate the people behind it. Great thanks to your all. Setting up visual D is not user friendly. I downloaded visualD+dmd+LDC since version 0.52 I could not run ordinary Hello World. All kind of errors. I seek help on the learn group several times to not help. My experience with visual D is bad. Code-d on the order hand does not take 5mins to set up and you are good to go. It works great. Run your code without and errors. Code-d mirror well the ease of using the D compiler Later on I will post my error here if anybody can help out. Thanks to the authors of visualD and code-d, you people have done great job and should be proud of yourself. You have push D to another level of success and give users great ease of setting up D A million thanks to you alll
Jul 08
parent reply Manu <turkeyman gmail.com> writes:
On Wed, Jul 8, 2020 at 7:05 PM Greatsam4sure via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On Wednesday, 8 July 2020 at 01:26:55 UTC, Manu wrote:
 On Tue, Jul 7, 2020 at 10:00 PM JN via Digitalmars-d-announce <
 digitalmars-d-announce puremagic.com> wrote:

 On Saturday, 4 July 2020 at 13:00:16 UTC, Rainer Schuetze
 wrote:
 See
 https://rainers.github.io/visuald/visuald/VersionHistory.html for
the complete list of changes.
 Cheers,
 Rainer
Anyone who uses VisualD and Code-D can compare the two? (Yes, I know the difference between Visual Studio and Visual Studio Code).
The difference is night vs day... VisualD is, by far, like REALLY FAR, the most mature and useful IDE and debug environment for D. TL;DR: if you are a D dev, and you use Windows, you should definitely try Visual Studio + VisualD. I for one couldn't work without it!
VodualD is great. I appreciate the people behind it. Great thanks to your all. Setting up visual D is not user friendly. I downloaded visualD+dmd+LDC since version 0.52 I could not run ordinary Hello World. All kind of errors. I seek help on the learn group several times to not help. My experience with visual D is bad.
I've been testing the first-install process for almost 10 years. I haven't had any problems with first-install for at least 6 years. Make sure to create bug reports for issues like that; what version of VS are you using? Are there any non-standard elements to your installation or dev environment?
Jul 08
parent reply psycha0s <box mail.com> writes:
On Wednesday, 8 July 2020 at 09:09:40 UTC, Manu wrote:
 I've been testing the first-install process for almost 10 years.
 I haven't had any problems with first-install for at least 6 
 years.

 Make sure to create bug reports for issues like that; what 
 version of VS are you using? Are there any non-standard 
 elements to your installation or dev environment?
Just installed Visual Studio Community 2019 and then VisualD from scratch. It looks like VS has no idea that VisualD is installed at all. So there is definitely an issue here.
Jul 10
next sibling parent IGotD- <nise nise.com> writes:
On Friday, 10 July 2020 at 13:53:39 UTC, psycha0s wrote:
 Just installed Visual Studio Community 2019 and then VisualD 
 from scratch. It looks like VS has no idea that VisualD is 
 installed at all. So there is definitely an issue here.
I think you have the same problem as this reported bug. https://issues.dlang.org/show_bug.cgi?id=21028 Check the comments how to fix the problem with an existing VisualD installation.
Jul 10
prev sibling parent psycha0s <box mail.com> writes:
On Friday, 10 July 2020 at 13:53:39 UTC, psycha0s wrote:
 Just installed Visual Studio Community 2019 and then VisualD 
 from scratch. It looks like VS has no idea that VisualD is 
 installed at all. So there is definitely an issue here.
Okay, sorry, I figured it out. It was my fault. I'm a Linux guy, so I'm not used to all Windows stuff. It seems I didn't complete the installation of Visual Studio. The installer asked me to reboot the computer and it was going to install some additional components after that. But after rebooting it didn't do a thing, so I assumed everything is already installed and ran VS.
Jul 10
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 8 July 2020 at 01:26:55 UTC, Manu wrote:
 On Tue, Jul 7, 2020 at 10:00 PM JN via Digitalmars-d-announce < 
 digitalmars-d-announce puremagic.com> wrote:

 On Saturday, 4 July 2020 at 13:00:16 UTC, Rainer Schuetze 
 wrote:
 See 
 https://rainers.github.io/visuald/visuald/VersionHistory.html for the complete
list of changes.

 Cheers,
 Rainer
Anyone who uses VisualD and Code-D can compare the two? (Yes, I know the difference between Visual Studio and Visual Studio Code).
The difference is night vs day... VisualD is, by far, like REALLY FAR, the most mature and useful IDE and debug environment for D.
That's depends on what you're comfortable with and if you're a core windows guy... how you use it too. I would say if you're on Linux/Windows, try VS code, if you're Windows only and like Visual Studio, then VisualD. The two are great. There's others too who're ok with vim, emacs, etc for D. I believe it depends on how you use it and what you're used to. But generally I recommend VisualD or Code-d (VS code).
Jul 08
parent reply Manu <turkeyman gmail.com> writes:
On Wed, Jul 8, 2020 at 10:15 PM aberba via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On Wednesday, 8 July 2020 at 01:26:55 UTC, Manu wrote:
 On Tue, Jul 7, 2020 at 10:00 PM JN via Digitalmars-d-announce <
 digitalmars-d-announce puremagic.com> wrote:

 On Saturday, 4 July 2020 at 13:00:16 UTC, Rainer Schuetze
 wrote:
 See
 https://rainers.github.io/visuald/visuald/VersionHistory.html for
the complete list of changes.
 Cheers,
 Rainer
Anyone who uses VisualD and Code-D can compare the two? (Yes, I know the difference between Visual Studio and Visual Studio Code).
The difference is night vs day... VisualD is, by far, like REALLY FAR, the most mature and useful IDE and debug environment for D.
That's depends on what you're comfortable with and if you're a core windows guy... how you use it too.
Not really. VisualD is objectively the most functional and competent IDE/Debugger solution, BY FAR. It's not an opinion, it's a measurable fact. Obviously, if you are into vim/emacs/whatever, then you don't actually really care much about IDE support and debugging, and in that case, this question is not relevant to you. I agree that Code-D + VSCode is probably the second best solution, but there's really no comparison; the debugger is a kind of funny/sad joke, the D debug experience is poorly integrated, and the intellisense/autocomplete is nowhere near the same standard. There's no competition. Code-D is great work, but it's still catching up, and it may never do so because VSCode just has an embarrassingly bad debugger :(
Jul 08
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 9 July 2020 at 00:03:02 UTC, Manu wrote:
 Not really. VisualD is objectively the most functional and 
 competent
 IDE/Debugger solution, BY FAR.
 It's not an opinion, it's a measurable fact.

 Obviously, if you are into vim/emacs/whatever, then you don't 
 actually
 really care much about IDE support and debugging, and in that 
 case, this
 question is not relevant to you.
 I agree that Code-D + VSCode is probably the second best 
 solution, but
 there's really no comparison; the debugger is a kind of 
 funny/sad joke, the
 D debug experience is poorly integrated, and the 
 intellisense/autocomplete
 is nowhere near the same standard. There's no competition.

 Code-D is great work, but it's still catching up, and it may 
 never do so because VSCode just has an embarrassingly bad 
 debugger :(
Professionally, I've used Visual Studio for the first 3-4 years of my career. Back then the company I worked for was a MSFT partner, so we all had the Professional or Ultimate edition that had all the bells and whistles. I agree that VS has probably the best debugger, though I'd actually say that the debugging always been rock-solid. However, I've since moved to Linux and I couldn't be happier. I haven't had to fire up Windows for the past 1-2 years. On my work machine, I neither have a dual boot, nor even a Windows VM, just Linux. Windows really sucks as a dev environment. And I'm telling this as someone who would for years be one of the first among my colleagues and friends to install the latest Windows, VS, MSVC, .NET FX /.NET Core preview builds, Chocolatey, vcpkg, WSL, Windows Terminal, Cygwin, Msys, Msys2 and so on. The only salvation I see is WSL2, but still, it's overall a pretty bad dev UX. No matter how much effort is put in a GUI IDE, nothing beets Unix as an IDE and especially modern distros, such as NixOS (my daily driver). Yes, it takes much more effort for beginners than VS, but it's all worth it. Coming back to VS Code, for what I do on my daily job it's really destroying the "real" VS: * It's cross-platform, so I can take my dev environment on whichever OS I work. * You don't need to create a "project file" to effectively work on a project * On Windows, admin user is not necessary to install & update. This makes the update process unnoticeable, where VS, before their new modular installer was unbearably slow (1h min). * Start time is much better. Additionally, in many cases, you don't need to restart when you install/uninstall an extension - this make's it much easier to test extensions for 1-2 mins and then throw them away. * The extensions integrate much better - in many cases it takes < 10 secs to install something, while with VS it takes at least 1min in my experience, sometimes even several minutes, depending on the size of the extension. * VS Code integrates much better with the system - on Windows you just right-click to open a folder or file and it's opened in less then 1-3secs. In the terminal you just type `code <path>` and it's done. I know this works already with full VS and I have used it, but its much slower startup time defeats this workflow. * For beginners (which don't know vim), VS Code is actually not a bad choice as the default git editor (it's just `git config --global core.editor "code --wait"`) (e.g. for interactive rebase, writing commit messages, git add -p edit, and so on) * Given that I spend at least at 30-70% of my time in the terminal, VS Code's integrated terminal is much better than whatever VS has had when I tried it over the years. I'd like the perf to be better with vim and git diff, but it's very workable. * vscodevim still has much to be desired, but it's miles ahead then the alternative extensions for the full VS * The editor as a whole is much *easier* to customize and I feel that in the past 1-2 years it has started to be *more* customizable compared to VS * Extensions like Remote development for containers and SSH are live savers. I couldn't live without them (if I have to use a GUI editor / IDE). * The overall language support is much better. VS does a couple of languages really well, but VSCode has a much richer extensions gallery and supports many more languages. * Of course, I'm biased, since I haven't had to use a debugger in the past several months, but these days I'd always pick an editor with a much better extensibility story because many of the things I need daily I haven't found alternatives for in VS. ---- Rainer, the work you have done with VisualD is astounding! I have always been extremely impressed by the progress you have been making over the years! (Of course, not a high priority by any means, but) it would be great to have VisualD's engine for VS Code! I know that a large part of VisualD is very tightly coupled with VS, but I think that anything that could be made a bit more independent and reusable would be a plus. What I really wish is we had a single shared codebase for dlang editor support, that could be shared among editor extension writers, instead of having many community members working on competing solutions.
Jul 09
next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 9 July 2020 at 08:40:24 UTC, Petar Kirov 
[ZombineDev] wrote:
 Code-D is great work, but it's still catching up, and it may 
 never do so because VSCode just has an embarrassingly bad 
 debugger :(
Professionally, I've used Visual Studio for the first 3-4 years of my career. Back then the company I worked for was a MSFT partner, so we all had the Professional or Ultimate edition that had all the bells and whistles. I agree that VS has probably the best debugger, though I'd actually say that the which has always been rock-solid.
s/wanky/kind of janky/
Jul 09
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
FWIW, I actually agree with everything you said about linux as a dev
environment vs windows. But that wasn't the question... as an IDE and
debugger integration, there is absolutely no comparison to VisualD, not by
miles.

It would be really cool if parts from VisualD were more suitable for
VSCode, but I can't see that being easy or practical.
One is the Concorde integration, which is pretty deep, and GDB is just not
even remotely as good, and the vscode debug UX is embarrassing by contrast.
Then the general autocomplete engine, which is fairly dependent on the
detail expressed in the project files. While vcxproj files are very shit to
write, it's much easier on the tooling than trying to extract sufficient
build config from make.
Nobody writes VS project files, you generate them, just the same as
makefiles... nobody writes makefiles.


On Thu, Jul 9, 2020 at 6:45 PM Petar via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On Thursday, 9 July 2020 at 00:03:02 UTC, Manu wrote:
 Not really. VisualD is objectively the most functional and
 competent
 IDE/Debugger solution, BY FAR.
 It's not an opinion, it's a measurable fact.

 Obviously, if you are into vim/emacs/whatever, then you don't
 actually
 really care much about IDE support and debugging, and in that
 case, this
 question is not relevant to you.
 I agree that Code-D + VSCode is probably the second best
 solution, but
 there's really no comparison; the debugger is a kind of
 funny/sad joke, the
 D debug experience is poorly integrated, and the
 intellisense/autocomplete
 is nowhere near the same standard. There's no competition.

 Code-D is great work, but it's still catching up, and it may
 never do so because VSCode just has an embarrassingly bad
 debugger :(
Professionally, I've used Visual Studio for the first 3-4 years of my career. Back then the company I worked for was a MSFT partner, so we all had the Professional or Ultimate edition that had all the bells and whistles. I agree that VS has probably the best debugger, though I'd actually say that the debugging always been rock-solid. However, I've since moved to Linux and I couldn't be happier. I haven't had to fire up Windows for the past 1-2 years. On my work machine, I neither have a dual boot, nor even a Windows VM, just Linux. Windows really sucks as a dev environment. And I'm telling this as someone who would for years be one of the first among my colleagues and friends to install the latest Windows, VS, MSVC, .NET FX /.NET Core preview builds, Chocolatey, vcpkg, WSL, Windows Terminal, Cygwin, Msys, Msys2 and so on. The only salvation I see is WSL2, but still, it's overall a pretty bad dev UX. No matter how much effort is put in a GUI IDE, nothing beets Unix as an IDE and especially modern distros, such as NixOS (my daily driver). Yes, it takes much more effort for beginners than VS, but it's all worth it. Coming back to VS Code, for what I do on my daily job it's really destroying the "real" VS: * It's cross-platform, so I can take my dev environment on whichever OS I work. * You don't need to create a "project file" to effectively work on a project * On Windows, admin user is not necessary to install & update. This makes the update process unnoticeable, where VS, before their new modular installer was unbearably slow (1h min). * Start time is much better. Additionally, in many cases, you don't need to restart when you install/uninstall an extension - this make's it much easier to test extensions for 1-2 mins and then throw them away. * The extensions integrate much better - in many cases it takes < 10 secs to install something, while with VS it takes at least 1min in my experience, sometimes even several minutes, depending on the size of the extension. * VS Code integrates much better with the system - on Windows you just right-click to open a folder or file and it's opened in less then 1-3secs. In the terminal you just type `code <path>` and it's done. I know this works already with full VS and I have used it, but its much slower startup time defeats this workflow. * For beginners (which don't know vim), VS Code is actually not a bad choice as the default git editor (it's just `git config --global core.editor "code --wait"`) (e.g. for interactive rebase, writing commit messages, git add -p edit, and so on) * Given that I spend at least at 30-70% of my time in the terminal, VS Code's integrated terminal is much better than whatever VS has had when I tried it over the years. I'd like the perf to be better with vim and git diff, but it's very workable. * vscodevim still has much to be desired, but it's miles ahead then the alternative extensions for the full VS * The editor as a whole is much *easier* to customize and I feel that in the past 1-2 years it has started to be *more* customizable compared to VS * Extensions like Remote development for containers and SSH are live savers. I couldn't live without them (if I have to use a GUI editor / IDE). * The overall language support is much better. VS does a couple of languages really well, but VSCode has a much richer extensions gallery and supports many more languages. * Of course, I'm biased, since I haven't had to use a debugger in the past several months, but these days I'd always pick an editor with a much better extensibility story because many of the things I need daily I haven't found alternatives for in VS. ---- Rainer, the work you have done with VisualD is astounding! I have always been extremely impressed by the progress you have been making over the years! (Of course, not a high priority by any means, but) it would be great to have VisualD's engine for VS Code! I know that a large part of VisualD is very tightly coupled with VS, but I think that anything that could be made a bit more independent and reusable would be a plus. What I really wish is we had a single shared codebase for dlang editor support, that could be shared among editor extension writers, instead of having many community members working on competing solutions.
Jul 09
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 09/07/2020 10:22 PM, Manu wrote:
 Then the general autocomplete engine, which is fairly dependent on the 
 detail expressed in the project files.
DCD is due for a rewrite into using dmd-fe. However as it stands, I do not believe it is mature enough to use as a library for this purpose. So I commend Rainer for helping to mature it! It'll help in the long run to get IDE's up to VisualD's experience for everything but debugging.
Jul 09
parent reply Manu <turkeyman gmail.com> writes:
The tooling needs detailed build configuration knowledge, which is
relatively available to extract from the msbuild runtime. Makefiles are not
any sort of fun to extract such knowledge from, and I'm not aware of
standard tooling to hook into here.
dub should be simple, but that only works for simple D projects and small
libraries, it all falls over at scale. Even DMD itself is too large a D
project for Code-D to work well with.
There's also no sense of 'active configuration', which makes it impossible
to apply the proper build configuration when navigating or highlighting
code.

For example; VisualD not only *works*, but it can even do goto-definition
between languages; if you extern(C++) some function, and then "go to
definition" from your D code, it'll find it in the C++ code and navigate
there because of the centralised code database engine.
Code-D often can't even go to the definition of D functions in D code
reliably ;)

There is so much more work in VisualD than people can easily see at first
glance.

On Thu, Jul 9, 2020 at 8:55 PM rikki cattermole via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On 09/07/2020 10:22 PM, Manu wrote:
 Then the general autocomplete engine, which is fairly dependent on the
 detail expressed in the project files.
DCD is due for a rewrite into using dmd-fe. However as it stands, I do not believe it is mature enough to use as a library for this purpose. So I commend Rainer for helping to mature it! It'll help in the long run to get IDE's up to VisualD's experience for everything but debugging.
Jul 09
parent reply Jacob Carlborg <doob me.com> writes:
On Friday, 10 July 2020 at 00:39:49 UTC, Manu wrote:
 Even DMD itself is too  large a D project for Code-D to work 
 well with.
I have not used Code-D, but I am using TextMate with DCD integrated. It has no problem with the DMD project. But it only supports go-to-definition, autocomplete and showing documentation for symbols. When opening a project which contains a dub.sdl/dub.json file, the editor reads the import paths. Then it opens a new instance of DCD (one per project) and passes the imports paths to it.
 Code-D often can't even go to the definition of D functions in 
 D code reliably ;)
Yeah, VisualD has a huge advantage since it's now using the DMD frontend for these things. For example, DCD does not support UFCS, which is really annoying. -- /Jacob Carlborg
Jul 10
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 10 July 2020 at 07:32:42 UTC, Jacob Carlborg wrote:

 Yeah, VisualD has a huge advantage since it's now using the DMD 
 frontend for these things. For example, DCD does not support 
 UFCS, which is really annoying.
That is the most annoying thing for sure: It would be great to have the semantic engine of visual-d exposed via a language server ... /P
Jul 10
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 9 July 2020 at 10:22:50 UTC, Manu wrote:
 FWIW, I actually agree with everything you said about linux as 
 a dev environment vs windows. But that wasn't the question... 
 as an IDE and debugger integration, there is absolutely no 
 comparison to VisualD, not by miles.
While I agree about debugging in VS vs VS Code, I'd say that for my use cases VS Code is both a better editor and a better *IDE*. VS may come more fully-featured then VS Code out-of-the-box, but with its extensions ecosystem VS Code is a better IDE for my use cases and I suspect for many other people. Of course, your mileage may vary.
 It would be really cool if parts from VisualD were more 
 suitable for
 VSCode, but I can't see that being easy or practical.
 One is the Concorde integration, which is pretty deep, and GDB 
 is just not
 even remotely as good, and the vscode debug UX is embarrassing 
 by contrast.
I don't care about the VS debug engine since it's Windows only. Some of the UX may be nice to replicate, but think this falls outside big the scope of a dlang editor extension, if said editor already has general native code debugging functionality. Also some people even disagree that VS is better than GDB in general: https://www.quora.com/Why-is-the-Visual-Studio-C%2B%2B-debugger-much-better-than-GDB-LLDB-or-any-other-debugger-for-C%2B%2B?ch=10&share=b4f38907&srid=3E2D0 Even if if I agree that VS provides a better debugging experience than VS Code, GDB is more powerful tool overall, so I don't miss Concorde on Linux.
 Then the general autocomplete engine, which is fairly dependent 
 on the
 detail expressed in the project files.
This is false. Most compilers don't work with project files. Same for LSPs. All you need is the is the list of all importable files and the current active build configuration (what compiler flags are set). It is the job the editor/IDE extension to figure out the build system or parse through project files. The autocomplete engine / the LSP implementation doesn't need to know about that stuff.
 Nobody writes VS project files, you generate them, just the 
 same as
 makefiles... nobody writes makefiles.
The problem is that there are many things (like MSBuild tasks in general) that the VS solution/project properties window doesn't allow you to edit effectively, or at all. Yes, the UI may be sufficient many/most developers, but that hasn't been the case at all for me. E.g. if you make changes through the UI, like the build configurations between x86/x64 and Debug/Release VS ends up duplicating large parts of the configuration, while if you edit the *proj files by hand you can avoid the duplication and make the files easier to read overall. The other deal breaker for me is that when the files are in version control I have to read the XML anyway in order to track changes. Using the UI to track changes to project files is just a nostarter. So, having had to edit both VS *.*proj files and Makefiles manually, I'd say that Makefiles are orders of magnitude more approachable and easier for me. MSBuild is just a giant PITA in my experience. Though I agree that I don't find Makefiles enjoyable either :D, but at least I can more easily track changes to them in VCS.
Jul 09
next sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 10/07/2020 07:07, Petar Kirov [ZombineDev] wrote:
 I don't care about the VS debug engine since it's Windows only. Some of
 the UX may be nice to replicate, but think this falls outside big the
 scope of a dlang editor extension, if said editor already has general
 native code debugging functionality.
Actually the Microsoft C++ extension for VS Code also uses the Concord debug engine, but unfortunately it is not extendible as in VS (yet), see https://github.com/microsoft/vscode-cpptools/issues/2932
 Also some people even disagree that VS is better than GDB in general:
 https://www.quora.com/Why-is-the-Visual-Studio-C%2B%2B-debugger-much-better-than-GDB-LLDB-or-any-other-debugger-for-C%2B%2B?ch=10&share=b4f38907&srid=3E2D0
 
 
 Even if if I agree that VS provides a better debugging experience than
 VS Code, GDB is more powerful tool overall, so I don't miss Concorde on
 Linux.
I think gdb can be compared with windbg. They both have great in-depth functionality. UX wise both are not so well, but it all depends on the front-end built on top of them. The usual downside is that remoting the text-interface can be incredibly slow.
Jul 09
prev sibling parent Jacob Carlborg <doob me.com> writes:
On Friday, 10 July 2020 at 05:07:38 UTC, Petar Kirov [ZombineDev] 
wrote:

 So, having had to edit both VS *.*proj files and Makefiles 
 manually, I'd say that Makefiles are orders of magnitude more 
 approachable and easier for me. MSBuild is just a giant PITA in 
 my experience. Though I agree that I don't find Makefiles 
 enjoyable either :D, but at least I can more easily track 
 changes to them in VCS.
FYI, Visual Studio has native support for CMake projects these days. -- /Jacob Carlborg
Jul 10
prev sibling next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 9 July 2020 at 08:40:24 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Thursday, 9 July 2020 at 00:03:02 UTC, Manu wrote:
 Not really. VisualD is objectively the most functional and 
 competent
 IDE/Debugger solution, BY FAR.
 It's not an opinion, it's a measurable fact.
 Windows really sucks as a dev environment.
Probably Manu and I are arguing from OPPOSITE sides. Linux as a dev env in itself contributes to 60-70% of the better-ness over Windows env for development. Its makes sense he holds such opinion since he's on windows...having to rely on Visual Studio for everything. Visual Studio as an IDE is pretty solid though...just not for everyone. Nevertheless VS Code is pretty good for development. Its not an IDE BTW. And even then its quite interesting people think of it as such. D integration is not perfect, but its what most of us use. I know a lot of people in the community use it. I might as well say its the most used Code editor on earth. Nevertheless, VisualD is high quality (not comparing here)...it makes sense considering the amount of work and yrs put into it.
Jul 09
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 9 July 2020 at 12:06:52 UTC, aberba wrote:
 On Thursday, 9 July 2020 at 08:40:24 UTC, Petar Kirov 
 [ZombineDev] wrote:
 On Thursday, 9 July 2020 at 00:03:02 UTC, Manu wrote:
 Not really. VisualD is objectively the most functional and 
 competent
 IDE/Debugger solution, BY FAR.
 It's not an opinion, it's a measurable fact.
 Windows really sucks as a dev environment.
Probably Manu and I are arguing from OPPOSITE sides. Linux as a dev env in itself contributes to 60-70% of the better-ness over Windows env for development. Its makes sense he holds such opinion since he's on windows...having to rely on Visual Studio for everything. Visual Studio as an IDE is pretty solid though...just not for everyone.
Yep.
 Nevertheless VS Code is pretty good for development. Its not an 
 IDE BTW. And even then its quite interesting people think of it 
 as such. D integration is not perfect, but its what most of us 
 use. I know a lot of people in the community use it. I might as 
 well say its the most used Code editor on earth.
VSCode is not an IDE out-of-the box, but with its extensions its able to become a much better IDE than many other actual IDEs for many use cases.
 Nevertheless, VisualD is high quality (not comparing here)...it 
 makes sense considering the amount of work and yrs put into it.
Yes, I agree that it's amazing.
Jul 09
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On Thursday, 9 July 2020 at 08:40:24 UTC, Petar Kirov 
[ZombineDev] wrote:

 What I really wish is we had a single shared codebase for dlang 
 editor support, that could be shared among editor extension 
 writers, instead of having many community members working on 
 competing solutions.
That would be really nice. Doesn't Visual Studio (not VSCode) supports LSP these days? -- /Jacob Carlborg
Jul 09
next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 9 July 2020 at 12:14:51 UTC, Jacob Carlborg wrote:
 On Thursday, 9 July 2020 at 08:40:24 UTC, Petar Kirov 
 [ZombineDev] wrote:

 What I really wish is we had a single shared codebase for 
 dlang editor support, that could be shared among editor 
 extension writers, instead of having many community members 
 working on competing solutions.
That would be really nice. Doesn't Visual Studio (not VSCode) supports LSP these days? -- /Jacob Carlborg
Given that Microsoft were the ones who designed LSP in the first place, I'd be surprised if the they don't. Rainer for sure knows more about it than me, but a quick Google search yields this as one of the top results: https://docs.microsoft.com/en-us/visualstudio/extensibility/language-server-protocol?view=vs-2019 Note that this article is for VS and not VS Code.
Jul 09
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 09/07/2020 14:14, Jacob Carlborg wrote:
 On Thursday, 9 July 2020 at 08:40:24 UTC, Petar Kirov [ZombineDev] wrote:
 
 What I really wish is we had a single shared codebase for dlang editor
 support, that could be shared among editor extension writers, instead
 of having many community members working on competing solutions.
That would be really nice. Doesn't Visual Studio (not VSCode) supports LSP these days?
There is an extension using DLS as an LSP: https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.visual-studio-dlang It's been some time, but when I tried to use that along side Visual D, it caused problems because both are trying to be a language service for the same language.
Jul 09
parent reply Jacob Carlborg <doob me.com> writes:
On Friday, 10 July 2020 at 06:46:53 UTC, Rainer Schuetze wrote:

 There is an extension using DLS as an LSP: 
 https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.visual-studio-dlang

 It's been some time, but when I tried to use that along side 
 Visual D, it caused problems because both are trying to be a 
 language service for the same language.
I was more hoping for the engine in VisualD to be the new DCD or DLS, since it's already using the DMD frontend for some things. Then it can be used by other editors and IDEs, hint hint, wink wink ;) -- /Jacob Carlborg
Jul 10
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 10/07/2020 09:14, Jacob Carlborg wrote:
 On Friday, 10 July 2020 at 06:46:53 UTC, Rainer Schuetze wrote:
 
 There is an extension using DLS as an LSP:
 https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.visual-studio-dlang


 It's been some time, but when I tried to use that along side Visual D,
 it caused problems because both are trying to be a language service
 for the same language.
I was more hoping for the engine in VisualD to be the new DCD or DLS, since it's already using the DMD frontend for some things. Then it can be used by other editors and IDEs, hint hint, wink wink ;)
The semantic engine shouldn't be too hard to extract, as it is already running as a separate process. It just uses a protocol that predates LSP.
Jul 10