• Adam Wilson (38/38) Dec 13 2018 I am pleased to announce that Autowrap has now gained the ability to
• bachmeier (3/8) Dec 13 2018 I've never done much with .NET. Will this allow calling of D
• Adam Wilson (7/15) Dec 13 2018 Yes. The generated C# can be built into a .NET Class Library and then
• Sjoerd Nijboer (11/11) Dec 14 2018 Is there any overhead on the generated interface? Or overhead the
• Adam Wilson (13/25) Dec 14 2018 Yes, any overheads that would normally be associated with a P/Invoke
• JJS jjs.com (70/78) Dec 14 2018 This is an interesting ideal Visual D already provides a D
• Neia Neutuladh (25/42) Dec 14 2018 Retaining the "On Sat, 15 Dec, Person A wrote:" lines is helpful for

Adam Wilson <flyboynw gmail.com> writes:

I am pleased to announce that Autowrap has now gained the ability to 
generate .NET interfaces for D libraries! This means that if you have a 
D library that you would like to call from .NET you can now Autowrap it 
and use the library in .NET as if it were any other .NET assembly.

Autowrap will generate interfaces for the following features of D:

Primitive Types that map between the two languages (no cent/ucent/real)
Module-level Functions
Structs and Classes
   - Constructors
   - Fields
   - Properties
   - Methods
1-Dimensional Ranges

Please note that this is initial work and there may be bugs and things 
that don't work. For example we know the following things will not work:

SysTime/DateTime/UUID types
Multi-Dimensional Ranges
Templates
Delegates/Callbacks

Amoung the items that do work, 1D ranges have not been thoroughly tested 
and there may be corner cases around class/reference lifetime. At the 


Therefore, multiple copies of the same D reference may experience 
use-after-free as the memory will be unpinned after the first destructor 
is called. For most scenarios this will not be a problem, but it is 
something to be aware of. I am exploring alternatives to handle this 
problem but nothing has yet been decided and I am curious what your 
opinions and experience would suggest.



More information can be found here:
GitHub Repo: https://github.com/kaleidicassociates/autowrap
DUB Package: http://code.dlang.org/packages/autowrap

I would like to thank Symmetry Investments for sponsoring this effort.

-- 
Adam Wilson
IRC: EllipticBit
import quiet.dlang.dev;

bachmeier <no spam.net> writes:

On Thursday, 13 December 2018 at 11:24:05 UTC, Adam Wilson wrote:
 I am pleased to announce that Autowrap has now gained the 
 ability to generate .NET interfaces for D libraries! This means 
 that if you have a D library that you would like to call from 
 .NET you can now Autowrap it and use the library in .NET as if 
 it were any other .NET assembly.

I've never done much with .NET. Will this allow calling of D 

Adam Wilson <flyboynw gmail.com> writes:

On 12/13/18 6:28 AM, bachmeier wrote:
 On Thursday, 13 December 2018 at 11:24:05 UTC, Adam Wilson wrote:
 I am pleased to announce that Autowrap has now gained the ability to 
 generate .NET interfaces for D libraries! This means that if you have 
 a D library that you would like to call from .NET you can now Autowrap 
 it and use the library in .NET as if it were any other .NET assembly.

 
 I've never done much with .NET. Will this allow calling of D libraries 





-- 
Adam Wilson
IRC: EllipticBit
import quiet.dlang.dev;

Sjoerd Nijboer <dlang sjoerdnijboer.com> writes:

Is there any overhead on the generated interface? Or overhead the 
compiler can't trivially optimise away.

Do you have any recocmendations about mixing coe like, don't use 

vice-versa.

Do you have plans to incorportae this as a VisualD project 
.csproj project since it's already intended to be microsoft 
oriented? (It would seem like a good fit to me.) That way you 
could even take away the mixin code and the "running the main 
method" code.

Does it work with LDC or only with DMD? How about GCC on linux?

Adam Wilson <flyboynw gmail.com> writes:

On 12/14/18 2:33 PM, Sjoerd Nijboer wrote:
 Is there any overhead on the generated interface? Or overhead the 
 compiler can't trivially optimise away.
 

Yes, any overheads that would normally be associated with a P/Invoke 
call will be present here.

 Do you have any recocmendations about mixing coe like, don't use strings 

 

Strings are fine. But definitely try to minimize switching as there is 
some pretty significant overheads on the D side with module 
constructors. And "switching" can happen in some pretty well hidden 
places, for example, appending to a range is switch.

 Do you have plans to incorportae this as a VisualD project .csproj 
 project since it's already intended to be microsoft oriented? (It would 
 seem like a good fit to me.) That way you could even take away the mixin 
 code and the "running the main method" code.
 

I do not since I wouldn't know where to start, but it's possible.

 Does it work with LDC or only with DMD? How about GCC on linux?

It works with anything that can output a shared library and C interfaces. :)

-- 
Adam Wilson
IRC: EllipticBit
import quiet.dlang.dev;

JJS jjs.com <JJS jjs.com> writes:

 Do you have plans to incorportae this as a VisualD project 
 .csproj project since it's already intended to be microsoft 
 oriented? (It would seem like a good fit to me.) That way you 
 could even take away the mixin code and the "running the main 
 method" code.
 

 I do not since I wouldn't know where to start, but it's 
 possible.


This is an interesting ideal Visual D already provides a D 
injection in to C++ projects.

Using DLangInNet(I'm renamed your project for you ;) one should 

compatible project.

You should talk to Rainer about this. It shouldn't be all that 


all the calls to the D code using Pinvoke when necessary?

So the idea is that one can add .d files to .Net projects, when 
built:

1. The D files are compiled.


etc). Basically an autobinding generator from D to whatever, 
might be a good project to develop.
3. .Net handles the rest.

The point of having it this way in Visual Studio is that one can 
on a single project that has many different languages involved 
and can setup a rather seamless connection. This allows one to 
tailor the program design to the language of choice. E.g., D for 


This could be used for Unity, say, for using D in algorithms. 
Such a feature would attract far more users and give D a boost in 
it's userbase and more will get done.

What we need is an idea that just works and one can use any 
appropriate source language at any time and they all bind without 
hicup's in most cases.

One can easily update all the compilers at a click and unwind if 
any compiler fails to build a project, etc. So much more could be 
done. But a start would be getting some of these different 
zones(e.g., languages, 3D engines, compilers, etc) to all work 
seamlessly in an integrated fashion.

E.g., something along the lines of:

1. Pick your language's
2. Pick your rendering engine
3. Pick your standard library
4. Pick your extensions


And so one can mix and match all things and everything just 
connects together. E.g., your python file will "intellisense" 
with your D file. Write a function in Haskell and it is callable 
in VB which can be called by your python file.

of course, this would suggest that there is just one underlying 
language and many "versions"(mappings) on top... which is 
basically IR with .NET.

I'm just thinking grander and not having to write a new 
compiler... just using bindings and wrapper generators to 
generate the code. Since most languages use object files and 
pretty much follow the same basic principles, it probably could 
be done for most things needed by most people.

One would just have to come up with the proper design so that 
people could build on it and connect languages in to the 
ecosystem easily.

This is the direction in which IDE's are headed but I don't think 
they realize it yet.

It seems it wouldn't be all that much work either. Essentially 
one just maintains a list of "exportable" symbols for each 
language source, project, module, etc and all other language 
sources can see them.

E.g., write a public global function or variable in D, say, and 
it is automatically exported which can then be seen in any other 
language source. Proper interaction will be chosen and everything 
will just work.

This would be like being able to speak 10 languages nearly 
simultaneously! With such an IDE it could even deal with 
Marshalling and seg faulting issues such as apply warnings when a 
variable should be free'd when it is interopted with and the IDE 
knows it should(e.g., D and C++ issues) or whatever. (People 
would be able to write such rules so that errors could be 
minimized)

Neia Neutuladh <neia ikeran.org> writes:

On Sat, 15 Dec 2018 00:43:42 +0000, JJS jjs.com wrote:
 Do you have plans to incorportae this as a VisualD project .csproj



Retaining the "On Sat, 15 Dec, Person A wrote:" lines is helpful for 
keeping track of the conversation.

 Using DLangInNet(I'm renamed your project for you ;)

Only the project maintainers have that authority. The project exposes D 
types and functions in Python, Excel, and .NET, so DLangInNet would be a 
terrible name for it.

 You should talk to Rainer about this. It shouldn't be all that difficult


 using Pinvoke when necessary?

This is discussed in the Autowrap readme file.

 So the idea is that one can add .d files to .Net projects, when built:


to specify Autowrap and the D compiler as dependencies. You need to hook 
this up into the build script.



 Basically an autobinding generator from D to whatever, might be a good
 project to develop.

Perhaps a good name for that would be "Autowrap".

 The point of having it this way in Visual Studio is that one can on a
 single project that has many different languages involved and can setup
 a rather seamless connection.


you rebuild. This is not seamless. Making it seamless requires your IDE to 
know how the binding will be constructed and to have good support for 
every language you're using. Plus each language plugin needs to use a 
common set of data structures to represent your source code.

Technically, this isn't hard for a common set of languages, at least if 
you're only binding from a statically typed, strongly typed language with 
ideally little metaprogramming and in any case no ability to change types 
at runtime.

 What we need is an idea that just works and one can use any appropriate
 source language at any time and they all bind without hicup's in most
 cases.

Languages need a certain level of similarity for that to work. Haskell 
assumes immutability and would not work particularly well with a D 
function that mutates its input. Javascript objects can gain and lose 
fields and methods at runtime, something that D can't model well. A Python 
function can return a value of any type at all.