Dynamic binding to the Mono runtime API

[Adam Wilson via Digitalmars-d-announce]

On 6/4/17 04:15, Jakub Szewczyk wrote:
> On Sunday, 4 June 2017 at 09:43:23 UTC, Adam Wilson wrote:
>> On 6/4/17 01:18, Jakub Szewczyk wrote:
>>> This is an interface to the Mono libraries, D/CLI would [...]
>>>
>> 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.
>
> That's what I actually meant, "porting" was a misused term on my part,
> "binding" would be a better word, sorry for that.
> As for the dependency problem - I think that a linking layer generator
> would accept a list of input assemblies (and optionally, specific
> classes) to which it should generate bindings, the core Mono types could
> be automatically translated to D equivalents, and the rest could be left
> as an opaque reference, like MonoObject* in C, also providing support
> for very basic reflection through the Mono methods if it turned out to
> be useful for anyone.
>
>>> Mono actually supports some kind of GC bridging as far as I
>>> understand, [...]
>>>
>> 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.
>
> Yes, GCHandles to keep Mono objects in D and a wrapper based on that GC
> bridge to keep D references from being collected by Mono. I have
> previously implemented a very similar mechanism for Lua in a small
> wrapper layer, and it worked perfectly.
>
>>> I can make a static library version, [...]
>>
>> 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.
>
> It's now public as v1.1.0, I've tested that it works with the tiny
> sample, the only important part is that the library to link must be
> specified by the project using this binding, because those paths may
> vary across systems, and they cannot be specified in code like the
> dynamic link ones. However, a simple "libs":["mono-2.0"] entry in
> dub.json should be enough for most use cases.
>

Thank you for this, I've tried it and it works!

I did some in depth research and prototyping in D, and it looks like the 
only way to enumerate the types in an assembly is to use the Metadata 
Table API's map everything that way. That's a little beyond the scope of 
my free time so I'll have to shelve the idea from now. :(

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