VisualD's Intellisense not workign with gtk

Thu Aug 10 23:36:51 PDT 2017

On 10.08.2017 15:47, Johnson wrote:
> On Thursday, 10 August 2017 at 07:05:26 UTC, Rainer Schuetze wrote:
>>
>>
>> On 06.08.2017 21:27, Rainer Schuetze wrote:
>>>
>>>> ------------------------------Part 2----------------------------
>>>> I just tried downloading the source code and get >
>>>> "C:\Program Files (x86)\Microsoft Visual 
>>>> Studio\2017\Enterprise\\Common7\Tools\vsvars32.bat"
>>>>
>>>> when building build.
>>>
>>> I suspect Visual D doesn't build out of the box with VS2017. I still 
>>> use VS2013 to avoid dependencies in the resulting binaries on newer 
>>> versions.
>>>
>>
>> I have updated the build scripts and the C to D conversion to also 
>> work with VS2017 and Windows SDK 10.0.15063.0.
> 
> Awesome! I think I got it to build!
> 
> I had a few issues. I still had to fix a few hard coded paths I listed 
> above(I think it was mainly the tools/build.bat:
> 
> c:\d\dmd2\windows\bin\dmd.exe -g tlb2idl.d oleaut32.lib uuid.lib snn.lib 
> kernel32.lib
> if errorlevel 1 goto xit
> "C:\Program Files (x86)\VisualD\cv2pdb\cv2pdb.exe" -D1 tlb2idl.exe 
> tlb2idl_pdb.exe
> :xit
> 
> which had hard coded paths for dmd2 and cv2pdb.

Sorry, this is an outdated build batch. tlb2idl is also built by the 
build-project in the solution. I'll better delete this batch.

> 
> A new issue was with
> 
> Must fix up vsct or add proper vssdk path to visuald.visualdproj:
> 
> C:\Program Files (x86)\Microsoft Visual 
> Studio\2017\Enterprise\VSSDK\VisualStudioIntegration\Tools\Bin\vsct.exe
[...]
> set VSSDKInstall=%VSSDK140Install%
> if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK120Install%
> if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK110Install%
> if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK100Install%
> if "%VSSDKInstall%" == "" set VSSDKInstall=%VSSDK90Install%
> if "%VSSDKInstall%" == "" set VSSDKInstall=C:\l\vssdk
> set VSCT=%VSSDKInstall%\VisualStudioIntegration\Tools\Bin\VSCT.exe
>
> So, I guess VSSDKx0Install isn't set on my system because it was always 
> looking for vsct in C:\l\vssdk.
> 
> Fix that and everything built!

This is missing the check for VSSDK150Install which is set by the 
vcvars32.bat of VS2017. I've added that.

> 
> Now the question is, what do I do with this? Is there any automated way 
> to update VisualD after a build or someway to simultaneously debug 
> visualD when something happens in another project?

I usually debug Visual D as described at 
http://rainers.github.io/visuald/visuald/BuildFromSource.html under 
"Deployment", but that doesn't work for VS2017 anymore due to the 
private registry of VS. AFAICT the "official" way is to have a package 
definition in a user extension folder, but that never worked for me (or 
I haven't tried enough because the other way worked, too).

If you replace the standard installed DLL with a debug version, VS can 
get quite slow. This is mainly because the debug version writes a 
log-file visuald.log into the folder where you started devenv from.

You can also attach a debugger to a running devenv process. If you are 
using a release build of visuald with optimizations, debug information 
can be a lot more confusing than without, though.

> Basically, how to make it all seamless debug app/fix visualD cycle? Or 
> do you just manually do all the work? I figure copying visualD over to 
> the install dir requires stopping VS since visualD.dll and others will 
> probably be in use. It would be nice, say, to be able to break in to 
> visualD's source when debugging to to get at specific parts of visual D 
> like how it displays watches so I can more quickly fix things rather 
> than having to learn how visual D is put together before I actually 
> start investigating issues or enhancements.

I guess you might have noticed, but to make sure you don't get lost in 
the dependencies:

- the semantic engine is a local COM server written in C#: 
https://github.com/rainers/D_Parser/tree/visuald

I usually debug this by starting DParserCOMServer.exe from within the 
solution, then kill all other running instances. When you edit code in 
Visual D, it will reconnect to the debug instance.

- the debug engine is written in C++: https://github.com/rainers/mago

Debugging the Concord extension (MagoNatCC built in configuration "Debug 
StaticDE") is easiest: just copy the DLL bin\Win32\Debug\MagoNatCC.dll 
to <VSInstall>\Common7\Packages\Debugger, start debugging in another 
devenv process and attach the debugger to this other process.

- CodeView to PDB conversion for builds with -m32 is done by cv2pdb: 
https://github.com/rainers/cv2pdb

> 
> Thanks again! Maybe I can contribute a little to Visual D in the future ;)

Looking forward to your pull requests!

> 
> I saw all your other replies, thanks! I got them. I might reply to a few 
> later if I get some time.
> 
> 
> I'll spend a little time trying to figure out what's going on and how 
> visual D is setup and where the main bulk of the code for visual studio 
> exists and hopefully it will make enough sense to get somewhere.
> 
> Thanks!