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;
