Re: Dynamic binding to the Mono runtime API
On 2017-06-04 20:19, Jakub Szewczyk wrote: The problem is, it emits completely wrong code whereever a function is necessary, like in function pointers. I can try to isolate the change to global-level function declarations only, to make it generate correct code that doesn't require running two versions of DStep in parallel to extract all the information, when I do that I'll submit a PR. Cool, that would be great. -- /Jacob Carlborg
Re: Dynamic binding to the Mono runtime API
On Sunday, 4 June 2017 at 15:43:09 UTC, Jacob Carlborg wrote: On 2017-06-04 10:18, Jakub Szewczyk wrote: 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. Would you like to contribute your changes under a flag to DStep? The problem is, it emits completely wrong code whereever a function is necessary, like in function pointers. I can try to isolate the change to global-level function declarations only, to make it generate correct code that doesn't require running two versions of DStep in parallel to extract all the information, when I do that I'll submit a PR.
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Sunday, 4 June 2017 at 03:01:41 UTC, Walter Bright wrote: On 6/3/2017 5:20 PM, Mike Parker wrote: There's currently a proposal in the PR queue to enhance the contract syntax. https://github.com/dlang/DIPs/pull/66 I know. That's as it should be! Well that's encouraging! Thanks!
Re: Dynamic binding to the Mono runtime API
On 2017-06-04 10:18, Jakub Szewczyk wrote: 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. Would you like to contribute your changes under a flag to DStep? -- /Jacob Carlborg
Re: Dynamic binding to the Mono runtime API
On 2017-06-03 23:44, extrawurst wrote: On Saturday, 3 June 2017 at 17:30:05 UTC, Jakub Szewczyk wrote: Mono runtime is a cross-platform, open-source alternative to Microsoft's .NET framework [1], and it can be embedded in other applications as a "scripting" VM, but with JIT-compilation enhanced performance and support of many languages such as C#, F# or IronPython [2]. It provides a C API, so I've bound it to D as a Derelict-based project, available at https://github.com/kubasz/derelict-mono, and as a DUB package (http://code.dlang.org/packages/derelict-mono). It currently wraps the Mono 5.0 API. There's also a simple example of calling a C# main from D code, and C# code calling a native function implemented in D. [...] Cool work! Thanks! Did u use dstep for the translation or manual labor? I'm guessing no, since these bindings are using function pointers while DStep will translate function declarations to function declarations in D as well, not function pointers. -- /Jacob Carlborg
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On 2017-06-04 01:10, Jonathan M Davis via Digitalmars-d-announce wrote: Only new Phobos modules. DIPs have been discussed quite a bit in the newsgroup, but their decision process has never been democratic. It's always been a matter of talking Walter into it, which has usually led to stuff never going anywhere when we haven't had a process for it with someone organizing it. Previously, I think that most DIPs that got implemented were something that Walter was personally interested in, or you managed to convince him in person. What Dicebot and Mike have done with DIPs has changed things drastically, but it's still completely up to Walter and Andrei. Right. -- /Jacob Carlborg
Re: Dynamic binding to the Mono runtime API
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.
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Sunday, June 04, 2017 05:56:15 Jack Stouffer via Digitalmars-d-announce wrote: > On Saturday, 3 June 2017 at 06:09:21 UTC, Jonathan M Davis wrote: > > On Saturday, June 03, 2017 02:00:13 Jack Stouffer via > > > > Digitalmars-d-announce wrote: > >> I recommend a longer deprecation cycle than usual for this, as > >> this will break many legacy libraries that don't get > >> maintained often. A period of two years sounds about right. > > > > For Phobos, that _is_ the normal length of the deprecation > > cycle. For the language itself, I don't think that it's > > anywhere near as consistent, but I've gotten the impression > > that deprecations in the language usually stick around for > > quite awhile, but I haven't exactly tracked it closely, so I > > don't know. > > > > - Jonathan M Davis > > All of the recent Phobos deprecations have been a year. 18 months > at most. If you think that, I think that you misunderstand how the Phobos deprecation process works. When a symbol is deprecated, it's marked in the documentation with the year-month that it will be removed from the documentation (usually about one year from the point that it's deprecated). Once that year has passed, the documentation is removed from Phobos, and instead, it's marked with a non-ddoc comment stating that the symbol is explicitly undocumented and that it will be removed at year-month where that's usually a year from when the symbol is removed from the documentation. Once that second date arrives, the symbol is completely removed. So, the whole deprecation cycle is approximately two years, and if anything, it sometimes takes a bit longer, because I'm sometimes slow to move the symbol along to the next stage. I suspect that what's confused you is that when the symbol is deprecated, it states in the documentation that the symbol will be removed at year-month and does not say anything about the fact that that removal date is when it will be removed from the documentation, not when it will be fully removed from the library. - Jonathan M Davis
Re: D for Android beta
On Friday, 2 June 2017 at 00:00:17 UTC, Laeeth Isharc wrote: On Thursday, 1 June 2017 at 19:31:28 UTC, Joakim wrote: [...] Congratulations, Joakim! https://www.reddit.com/r/programming/comments/6eqv46/write_mixed_dc_android_apps_even_build_them/ and news.ycombinator.com Looking forward to termux. Haha, I lol'ed when I just read this comment: "Ah, D only came into my field of view with the recent support on Android and I assumed it was a recent language designed for Android." https://www.reddit.com/r/programming/comments/6eqv46/comment/dif3sa0 Well, at least we're getting more of these Android people introduced to D.
Re: Dynamic binding to the Mono runtime API
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;
Re: Dynamic binding to the Mono runtime API
On Sunday, 4 June 2017 at 05:47:32 UTC, Adam Wilson wrote: On 6/3/17 10:30, Jakub Szewczyk wrote: ... I work with C# professionally and this is some SERIOUSLY cool work. Thank you for this! Thank you all! I've looked over the code a bit and I have a couple of questions. This appears to be an interface to the runtime itself, not a BCL interface correct? It looks like this could be used to could this be used to read into a Mono Class Libraries, and if so would so some sort of automated code generation tool be required? It looks to me like the binding will be non-trivial, with GC, exceptions, etc. that all need to be handled at the call-site. Can we get a static library version of this, or is there a dependency on dynamic libraries? I have to admit I am very impressed. I have spent a lot of time building code generators before and I have to admit that the idea of binding to arbitrary .NET libraries via code generation is extremely appealing to me. I am seriously tempted to take this and start building a binding generator... I seriously need more free time! Way too many cool and useful things happening in D for my limited free time. A D binding for XAML ... THAT would sight to behold! 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. 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. 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.
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Saturday, 3 June 2017 at 06:09:21 UTC, Jonathan M Davis wrote: On Saturday, June 03, 2017 02:00:13 Jack Stouffer via Digitalmars-d-announce wrote: I recommend a longer deprecation cycle than usual for this, as this will break many legacy libraries that don't get maintained often. A period of two years sounds about right. For Phobos, that _is_ the normal length of the deprecation cycle. For the language itself, I don't think that it's anywhere near as consistent, but I've gotten the impression that deprecations in the language usually stick around for quite awhile, but I haven't exactly tracked it closely, so I don't know. - Jonathan M Davis All of the recent Phobos deprecations have been a year. 18 months at most.
