On 6/4/17 01:18, Jakub Szewczyk wrote:
This is an interface to the Mono libraries, D/CLI would require quite a
lot of compiler changes, both on the front-end and back-end side, but
thanks to metaprogramming a wrapper library can get very close to such
an interface.
I plan on making an automated D to Mono bridge, akin to LuaD, so that it
can be used as a scripting platform for e.g. games. I haven't thought
about doing it the other way around, but now it seems like a very
interesting idea! Unfortunately no XAML
(http://www.mono-project.com/docs/gui/wpf/), but many other libraries,
such as XWT (https://github.com/mono/xwt) could be ported this way, I'll
certainly look into it.

My interest is less in code ports than bindings to the actual code. My experience with code ports or translations is that often subtle bugs creep in during translation due to the fact that each language has different idioms.

What I am thinking about is a tool that loads an assembly, examines it's types and methods via this API and emits D code that directly interfaces into the .NET types via this API. The tricky part here is mapping the .NET dependencies into D. The moment the library exposes a type from a dependency, that dependency ALSO needs to be included somehow. All libraries reference "mscorlib", AKA the BCL, so we'd have to provide a "mono-bcl" package on DUB.

One solution is to simply include the exposed dependency in the generated code. This would work because while the D code would have distinct types for the same class, the underlying .NET types is the same. The drawback with this approach is that you can't share the instances across D interfaces as the types are different. For example, Library1.B and Library2.C both rely on Dependency.A. In D you would have Library1.B.A and Library2.C.A and these two types, while the same in practice, are different types to the compiler. Maybe a clever use of alias can solve this at code-gen time... more research is required there.

The other solution is too have the code-gen throw an error when it encounters a type from a dependency. This ensures that the types are the same across libraries in D, but at the cost of increased complexity for the developer when running the tool (specifying extra deps) and when building their code (ensuring all relevant packages are built/referenced).

I'm not sold on either one. And it'd be best if it's possible to support both somehow.

As for the WPF remark, my brain immediately jump to trying to interface to .NET/Core using a similar mechanism, but alas some research time indicates that this is not possible outside of COM. *le sigh* My apologize for the random side-track.

Mono actually supports some kind of GC bridging as far as I understand,
as there is a sgen-bridge.h header just for that, and it has apparently
been used in the C#-Java Xamarin interace on Android. As for exceptions
- D functions have to be wrapped in a nothrow wrapper, but that can be
completely automated with templates. The other way around is also quite
simple - when invoking a Mono function a pointer can be given that will
set an exception reference if one is thrown from the .NET side, and a
wrapper can easily rethrow it back to D.

On the GC side I was mostly thinking about GC Handles so that the objects don't get collected out from underneath us. That is something is trivial to code-gen.

As for exceptions, I like the catch->translate->rethrow mechanism. And if the exception is unknown we could simply throw a generic exception. The important thing is to get close to the D experience, not try to map it perfectly.

I can make a static library version, it's just some regex substitutions
done on the functions file actually, most probably I'll publish it
today. It will be a dub subconfiguration like it is the case for GLFW3.
Btw, I've manually ported the basic and configuration headers, so that
no mistakes are made, and then used DStep and a modified DStep to
generate the rest of the headers - my modification was only to change
the way function declarations are generated, to make them in derelict
form of alias da_function = void function(...);, and the rest was done
with quite a lot of editor(VSCode) shortcuts.

Thank you for this! I find static libraries easier to deal with. I'm sure other people have differing opinions, so having both would make everyone happy.

I am very excited about this!

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

Reply via email to