www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Where is Visual-D C# code?

reply Ramon <midiway midi.rs> writes:
I use Visual-D for Visual Studio daily for writing D programs. 
Also I am very experienced in writing Visual Studio extensions, I 
wrote this commercial one: http://misoftware.rs/OmniCode.

Now, looking at Visual-D source code, 85% is D code. Well, at 
first it seems OK to write a D extension for D in D, but I 
wonder, how do you manage to use all .NET APIs from D?

Because for implementing every aspect of a language extension in 
Visual Studio (Intellisense, outlining, QuickInfo, signature 
help, snippets), in my experience, you really need to work with 
the .NET assemblys of the Visual Studio Extensibility SDK. I 
guess you are doing it in a old COM way, which I think is still 
supported by VS. But I think that is far from being productive. 
Also I doubt you can support every new aspect of VS editor 
experience, because since VS 2010 I think, the editor is based on 
WPF, so it is .NET in all its glory.

I am just worried if Visual-D is taking the right approach for 
implementing stuff. I could definitely help in the C# area.
Oct 30 2015
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 31.10.2015 00:19, Ramon wrote:
 I use Visual-D for Visual Studio daily for writing D programs. Also I am
 very experienced in writing Visual Studio extensions, I wrote this
 commercial one: http://misoftware.rs/OmniCode.

 Now, looking at Visual-D source code, 85% is D code. Well, at first it
 seems OK to write a D extension for D in D, but I wonder, how do you
 manage to use all .NET APIs from D?

 Because for implementing every aspect of a language extension in Visual
 Studio (Intellisense, outlining, QuickInfo, signature help, snippets),
 in my experience, you really need to work with the .NET assemblys of the
 Visual Studio Extensibility SDK. I guess you are doing it in a old COM
 way, which I think is still supported by VS. But I think that is far
 from being productive. Also I doubt you can support every new aspect of
 VS editor experience, because since VS 2010 I think, the editor is based
 on WPF, so it is .NET in all its glory.

 I am just worried if Visual-D is taking the right approach for
 implementing stuff. I could definitely help in the C# area.
You are right that writing Visual D in D has not been the easiest way to write an extension for VS. The first attempt was actually a derivation of a C# extension, but I hated it (I might be more relaxed about this today). Please note that this was before the release of VS2010, so VS itself was not based on C# as much as today. My reasoning was this: why should I spend my spare time writing code in a language I don't like? Writing it in D seemed natural instead, and actually doing this meant contributing to the dmd compiler/library/toolchain resulting in automatic conversion of Windows and VS SDK to D, DLL support for D, precise GC and numerous bug fixes. Most functionality can be accessed through COM, but WPF seems to be very different. That's why there is vdextensions.csproj to integrate some stuff that I didn't manage to access directly.
Oct 31 2015
parent reply default0 <Kevin.Labschek gmx.de> writes:
On Saturday, 31 October 2015 at 08:31:54 UTC, Rainer Schuetze 
wrote:
 On 31.10.2015 00:19, Ramon wrote:
 I use Visual-D for Visual Studio daily for writing D programs. 
 Also I am
 very experienced in writing Visual Studio extensions, I wrote 
 this
 commercial one: http://misoftware.rs/OmniCode.

 Now, looking at Visual-D source code, 85% is D code. Well, at 
 first it
 seems OK to write a D extension for D in D, but I wonder, how 
 do you
 manage to use all .NET APIs from D?

 Because for implementing every aspect of a language extension 
 in Visual
 Studio (Intellisense, outlining, QuickInfo, signature help, 
 snippets),
 in my experience, you really need to work with the .NET 
 assemblys of the
 Visual Studio Extensibility SDK. I guess you are doing it in a 
 old COM
 way, which I think is still supported by VS. But I think that 
 is far
 from being productive. Also I doubt you can support every new 
 aspect of
 VS editor experience, because since VS 2010 I think, the 
 editor is based
 on WPF, so it is .NET in all its glory.

 I am just worried if Visual-D is taking the right approach for
 implementing stuff. I could definitely help in the C# area.
You are right that writing Visual D in D has not been the easiest way to write an extension for VS. The first attempt was actually a derivation of a C# extension, but I hated it (I might be more relaxed about this today). Please note that this was before the release of VS2010, so VS itself was not based on C# as much as today. My reasoning was this: why should I spend my spare time writing code in a language I don't like? Writing it in D seemed natural instead, and actually doing this meant contributing to the dmd compiler/library/toolchain resulting in automatic conversion of Windows and VS SDK to D, DLL support for D, precise GC and numerous bug fixes. Most functionality can be accessed through COM, but WPF seems to be very different. That's why there is vdextensions.csproj to integrate some stuff that I didn't manage to access directly.
I seem to remember that it is possible to call into managed code from C++ (something like C++/CLI). Would it theoretically be possible to have a wrapper that allows direct access to the managed .NET API from D? A project like this could also help improve general interoperability between D and the .NET platform. Not sure on the specifics about these things, though, and just thinking about it this seems like a stupid amount of work to get right. Maybe I'm actually gonna give this a try, since I have way too many things to do anyways it seems to be very reasonable to start yet another (possibly gigantic) thing!
Oct 31 2015
next sibling parent reply Ramon <midiway midi.rs> writes:
I really would not recommend to use D at all for writing VS 
extensions. The thing is, are you be able to debug your D 
extension in Visual Studio experimental instance? Also Visual 
Studio is only for Windows, no need to multiplataform support, so 
just write it in C# and be ultra-productive, VS extension API is 
already cryptic enough.
Oct 31 2015
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 31.10.2015 16:47, Ramon wrote:
 I really would not recommend to use D at all for writing VS extensions.
 The thing is, are you be able to debug your D extension in Visual Studio
 experimental instance? Also Visual Studio is only for Windows, no need
 to multiplataform support, so just write it in C# and be
 ultra-productive, VS extension API is already cryptic enough.
I guess I would use C# now if starting all over, because you don't find any good support or examples in other languages anymore. But as I said, it's a way to actually work with D for me, and it doesn't seem productive to rewrite it in C# (I'm not an expert in that language anyway). Debugging the extension works both with the native and the mixed mode debugger, but the debug information emitted by dmd is sub-standard. I've made a number of pull requests years ago, but they have been mostly ignored.
Oct 31 2015
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 31.10.2015 14:49, default0 wrote:
 I seem to remember that it is possible to call into managed code from
 C++ (something like C++/CLI). Would it theoretically be possible to have
 a wrapper that allows direct access to the managed .NET API from D? A
 project like this could also help improve general interoperability
 between D and the .NET platform. Not sure on the specifics about these
 things, though, and just thinking about it this seems like a stupid
 amount of work to get right.
I guess it should be possible. When debugging Visual D, you see the transition between native and CLI on the callstack several times. AFAICT you usually call into a COM interface that is exposed by the .NET object. Even though these exist for Wpf objects, it's sometimes hard to get hold of these. At least, I failed when trying to implement the coverage margins and had to add the vdextensions C# project.
 Maybe I'm actually gonna give this a try, since I have way too many
 things to do anyways it seems to be very reasonable to start yet another
 (possibly gigantic) thing!
Good luck ;-)
Oct 31 2015
parent reply Ramon <midiway midi.rs> writes:
On Saturday, 31 October 2015 at 16:15:22 UTC, Rainer Schuetze 
wrote:
 On 31.10.2015 14:49, default0 wrote:
 I seem to remember that it is possible to call into managed 
 code from
 C++ (something like C++/CLI). Would it theoretically be 
 possible to have
 a wrapper that allows direct access to the managed .NET API 
 from D? A
 project like this could also help improve general 
 interoperability
 between D and the .NET platform. Not sure on the specifics 
 about these
 things, though, and just thinking about it this seems like a 
 stupid
 amount of work to get right.
I guess it should be possible. When debugging Visual D, you see the transition between native and CLI on the callstack several times. AFAICT you usually call into a COM interface that is exposed by the .NET object. Even though these exist for Wpf objects, it's sometimes hard to get hold of these. At least, I failed when trying to implement the coverage margins and had to add the vdextensions C# project.
 Maybe I'm actually gonna give this a try, since I have way too 
 many
 things to do anyways it seems to be very reasonable to start 
 yet another
 (possibly gigantic) thing!
Good luck ;-)
Are you using https://github.com/Hackerpilot tools as the backend for Visual-D?
Oct 31 2015
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 31.10.2015 19:07, Ramon wrote:
 Are you using https://github.com/Hackerpilot tools as the backend for
 Visual-D?
No. Visual D had it's own semantic engine, but switched to D_Parser by Alex Bothe some years ago (https://github.com/aBothe/D_Parser). This is the engine that is used by Mono-D and is still the best around AFAICT. BTW: D_Parser is all C#, but it runs in a different process.
Oct 31 2015
parent reply Ramon <midiway midi.rs> writes:
On Saturday, 31 October 2015 at 19:59:19 UTC, Rainer Schuetze 
wrote:
 On 31.10.2015 19:07, Ramon wrote:
 Are you using https://github.com/Hackerpilot tools as the 
 backend for
 Visual-D?
No. Visual D had it's own semantic engine, but switched to D_Parser by Alex Bothe some years ago (https://github.com/aBothe/D_Parser). This is the engine that is used by Mono-D and is still the best around AFAICT. BTW: D_Parser is all C#, but it runs in a different process.
Does Visual-D implements a complete Debug Engine?
Nov 01 2015
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 01.11.2015 17:34, Ramon wrote:
 On Saturday, 31 October 2015 at 19:59:19 UTC, Rainer Schuetze wrote:
 On 31.10.2015 19:07, Ramon wrote:
 Are you using https://github.com/Hackerpilot tools as the backend for
 Visual-D?
No. Visual D had it's own semantic engine, but switched to D_Parser by Alex Bothe some years ago (https://github.com/aBothe/D_Parser). This is the engine that is used by Mono-D and is still the best around AFAICT. BTW: D_Parser is all C#, but it runs in a different process.
Does Visual-D implements a complete Debug Engine?
It incorporates Mago, a debug engine created for D: https://github.com/rainers/mago. D also works with C++ engines, but expect some quirks, e.g. you'll have to fall back to C++ expressions for watches.
Nov 01 2015
parent reply Ramon <midiway midi.rs> writes:
Rainer, do you have an e-mail where I can message you about 
working in a C# version?
Nov 04 2015
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 05.11.2015 04:01, Ramon wrote:
 Rainer, do you have an e-mail where I can message you about working in a
 C# version?
It's the email address used to post here: r _dot_ sagitario _at_ gmx _dot_ de. I might be able to resist working in C# for some time though. ;-)
Nov 05 2015