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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
prev sibling next sibling parent kinke <noone nowhere.com> writes:
Thanks a lot, Rainer!
Jul 04 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Very nice!

Please consider writing an article about your work!
Jul 07 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020