Re: Dynamic binding to the Mono runtime API
On 6/3/17 10:30, 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. PS: Because I don't own a Mac I have no idea what the correct paths to the Mono shared library are, so it'd be great if someone could post/create a PR of them. [1] http://www.mono-project.com/ [2] http://www.mono-project.com/docs/advanced/embedding/scripting/ I work with C# professionally and this is some SERIOUSLY cool work. Thank you for this! 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! -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On 6/3/2017 5:20 PM, Mike Parker wrote: On Saturday, 3 June 2017 at 20:06:05 UTC, Walter Bright wrote: On 6/3/2017 12:28 AM, Petar Kirov [ZombineDev] wrote: Personally, making contracts less verbose and more powerful is much higher on my list We did discuss bouncing the DIP back with a request to revamp it as a complete overhaul of the contract syntax, but decided that this DIP was about resolving a simple and immediate problem, and it shouldn't be held up on that basis. 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!
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Saturday, 3 June 2017 at 23:43:10 UTC, Ali Çehreli wrote: If that's the only change, then we have a serious issue with the text of this DIP. I think the DIP must be corrected with the following change. Please review and then change the DIP accordingly: from: "Add do as an optional keyword in the place of body." to: "Add do as an alternative keyword in place of body." (Unimportantly, I removed a "the" as well.) Ali I think the two words are fairly close in meaning in this context. Changed it anyway (and caught a typo, too). Thanks!
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Saturday, 3 June 2017 at 20:06:05 UTC, Walter Bright wrote: On 6/3/2017 12:28 AM, Petar Kirov [ZombineDev] wrote: Personally, making contracts less verbose and more powerful is much higher on my list We did discuss bouncing the DIP back with a request to revamp it as a complete overhaul of the contract syntax, but decided that this DIP was about resolving a simple and immediate problem, and it shouldn't be held up on that basis. There's currently a proposal in the PR queue to enhance the contract syntax. https://github.com/dlang/DIPs/pull/66
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On 06/02/2017 11:44 PM, H. S. Teoh via Digitalmars-d-announce wrote: > Yes, count me somewhat disappointed at merely changing `body` to `do`. If that's the only change, then we have a serious issue with the text of this DIP. I think the DIP must be corrected with the following change. Please review and then change the DIP accordingly: from: "Add do as an optional keyword in the place of body." to: "Add do as an alternative keyword in place of body." (Unimportantly, I removed a "the" as well.) Ali
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Saturday, June 03, 2017 17:16:52 Jacob Carlborg via Digitalmars-d- announce wrote: > On 2017-06-02 16:17, Mike Parker wrote: > > Congratulations are in order for Jared Hanson. Walter and Andrei have > > approved his proposal to remove body as a keyword. I've added a summary > > of their decision to the end of the DIP for anyone who cares to read it. > > In short: > > > > * body temporarily becomes a contextual keyword and is deprecated > > * do is immediately allowed in its place > > * body is removed and do replaces it fully > > > > Congratulations, Jared! > > > > https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md > > That's great. > > BTW, didn't we use to vote on the DIPs, or was that only for new Phobos > modules? 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. - Jonathan M Davis
Re: Dynamic binding to the Mono runtime API
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. PS: Because I don't own a Mac I have no idea what the correct paths to the Mono shared library are, so it'd be great if someone could post/create a PR of them. [1] http://www.mono-project.com/ [2] http://www.mono-project.com/docs/advanced/embedding/scripting/ This is very cool - thank you for doing this. It could prove very helpful. Have you thought of/any interest in looking at automatically generating C# wrapper and bindings for D code? (I'm interested myself mostly in nested templated structs/arrays rather than classes). It may not be relevant for you, but if it is please drop me an email on laeeth ... at kaleidic.io Thanks. Laeeth.
Re: Release D 2.074.1
On Friday, 2 June 2017 at 09:52:45 UTC, Joseph Rushton Wakeling wrote: Great news, thanks Martin. I'll update the snap packages over the weekend. :-) Done. sudo snap refresh --classic --edge dmd should upgrade things for anyone who already has the package install; otherwise, sudo snap install --classic --edge dmd will install the dmd snap package for you.
Re: Dynamic binding to the Mono runtime API
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 just checked on my mac and it works from the get go! Cheers, Stephan
Re: Release D 2.074.1
On Saturday, 3 June 2017 at 21:17:18 UTC, Seb wrote: I understand the problem, but there's only so much Martin can do in his free time. I'm not asking anyone to do the work. I'm asking for a clear recognition that this is a problem that should be fixed. I'm also asking for a clear recognition that the impact of this problem is greater now that there is likely to be a greater volume of downstream packaging of dmd. Yep, but it's just a one-liner, right? https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/dmd#n32 Not the point. Workaround != fix. Well, as said before _until_ there's no one volunteering to do this, it won't happen. FWIW in the past sometimes even bumping the major version has been forgotten: https://github.com/dlang/dmd/commits/master/VERSION I'm aware of that. All the more reason to address the fundamental problem. I pointed you to the release scripts, because these are the spots where an addition to automatically update the VERSION file could be inserted ;-) Thanks for the heads-up, then. But I'm not sure that the best way to deal with this problem is to automate the process of patching the VERSION file. It would be better to find a way to avoid the need for the VERSION file altogether. Obvious example: if you want to promote a release candidate to the final release, it's much nicer to be able to tag the same commit, than to need to add an extra patch just to update VERSION.
Re: Release D 2.074.1
On Saturday, 3 June 2017 at 19:57:36 UTC, Joseph Rushton Wakeling wrote: It's a mistake that remains tolerated, despite the problem being known and having an associated issue, because the dlang/installer scripts work around it, meaning the fundamental problem never gets fixed. I understand the problem, but there's only so much Martin can do in his free time. So I'm not sure how necessary it is. The problem here is that anyone downstream wanting to build or package from source has to work around this issue, that without manual intervention, the version information of the compiler will be incorrect. Yep, but it's just a one-liner, right? https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/dmd#n32 If that's not fixed in how dmd itself is managed (NOT the dlang/installer scripts), this will continue to be an unnecessary burden on downstream packagers. Well, as said before _until_ there's no one volunteering to do this, it won't happen. FWIW in the past sometimes even bumping the major version has been forgotten: https://github.com/dlang/dmd/commits/master/VERSION I very much appreciate your pointing me to material that can help me create a workaround. But I'd feel a lot better about implementing such a workaround if I felt sure that there was a clear understanding of why it matters to fix this properly in dmd itself. I pointed you to the release scripts, because these are the spots where an addition to automatically update the VERSION file could be inserted ;-) For example, the PRs merging stable <-> master are generated from these scripts as well.
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On 6/3/2017 12:28 AM, Petar Kirov [ZombineDev] wrote: Personally, making contracts less verbose and more powerful is much higher on my list We did discuss bouncing the DIP back with a request to revamp it as a complete overhaul of the contract syntax, but decided that this DIP was about resolving a simple and immediate problem, and it shouldn't be held up on that basis.
Re: Release D 2.074.1
On Saturday, 3 June 2017 at 19:31:51 UTC, Seb wrote: Tags are only made from the stable branch. The point is that the VERSION file is wrong in the officially tagged release source. Well, as mentioned minor point releases have never been changed in the git repo before: https://github.com/dlang/dmd/commits/stable/VERSION Yes, and this is wrong. It means that one cannot reliably build from unmodified source and wind up with a DMD that accurately describes its own version. It's a mistake that remains tolerated, despite the problem being known and having an associated issue, because the dlang/installer scripts work around it, meaning the fundamental problem never gets fixed. So I'm not sure how necessary it is. The problem here is that anyone downstream wanting to build or package from source has to work around this issue, that without manual intervention, the version information of the compiler will be incorrect. If that's not fixed in how dmd itself is managed (NOT the dlang/installer scripts), this will continue to be an unnecessary burden on downstream packagers. Anyhow, the interesting bits are here: I very much appreciate your pointing me to material that can help me create a workaround. But I'd feel a lot better about implementing such a workaround if I felt sure that there was a clear understanding of why it matters to fix this properly in dmd itself. Note, I don't say anything about what such a fix should be, so please don't assume that I'm asking for any particular thing to be done. (There are a variety of ideas in the open issue.) What I'm asking is that it should be possible to build from unmodified source and have correct version info in the compiler.
Re: Release D 2.074.1
On Saturday, 3 June 2017 at 19:02:36 UTC, Joseph Rushton Wakeling wrote: On Saturday, 3 June 2017 at 18:42:57 UTC, Seb wrote: So, I guess your problem is the VERSION file on the dmd stable branch? No, it's the VERSION file present if one checks out the v2.074.1 tag. Tags are only made from the stable branch. I suspect this doesn't show up in the official packages because IIRC the VERSION file is edited as part of the standard official-package build process. Yes. The point is here that this keeps happening. Assuming a VERSION file is considered necessary at all (I believe the intent is to support people using a tarball of the source rather than a git checkout), it shouldn't be possible for a release to be made without it containing the correct version number. Well, as mentioned minor point releases have never been changed in the git repo before: https://github.com/dlang/dmd/commits/stable/VERSION So I'm not sure how necessary it is. Anyhow, the interesting bits are here: https://github.com/dlang/installer/tree/master/create_dmd_release in particular: https://github.com/dlang/installer/blob/master/create_dmd_release/build_all.d#L494 https://gist.github.com/MartinNowak/a471fe7ddbfeef205cdf04c93a94c6d0
Re: Release D 2.074.1
On Saturday, 3 June 2017 at 19:02:36 UTC, Joseph Rushton Wakeling wrote: The point is here that this keeps happening. The relevant issue (filed over a year ago): https://issues.dlang.org/show_bug.cgi?id=15910
Re: Release D 2.074.1
On Saturday, 3 June 2017 at 18:42:57 UTC, Seb wrote: So, I guess your problem is the VERSION file on the dmd stable branch? No, it's the VERSION file present if one checks out the v2.074.1 tag. I suspect this doesn't show up in the official packages because IIRC the VERSION file is edited as part of the standard official-package build process. Can't you simply overwrite the VERSION file in your build process? Otherwise it's just one simple PR away ;-) The point is here that this keeps happening. Assuming a VERSION file is considered necessary at all (I believe the intent is to support people using a tarball of the source rather than a git checkout), it shouldn't be possible for a release to be made without it containing the correct version number. Workarounds like this just perpetuate the problem and throw a burden on downstream packagers. Now that dmd is open-sourced and widespread packaging is feasible, it really would be preferable to fix the problem where it arises.
Re: Release D 2.074.1
On Thursday, 1 June 2017 at 21:04:00 UTC, Martin Nowak wrote: This point release fixes a few issues over 2.074.0, see the changelog for more details. I'm afraid that the release has another fault: the VERSION file still gives 2.074.0. This means that unless it is edited during the build process, the compiler will report the wrong version number when `dmd --version` is invoked.
Dynamic binding to the Mono runtime API
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. PS: Because I don't own a Mac I have no idea what the correct paths to the Mono shared library are, so it'd be great if someone could post/create a PR of them. [1] http://www.mono-project.com/ [2] http://www.mono-project.com/docs/advanced/embedding/scripting/
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On 06/03/2017 11:08 AM, Andrei Alexandrescu wrote: On 6/2/17 10:17 AM, Mike Parker wrote: Congratulations are in order for Jared Hanson. Walter and Andrei have approved his proposal to remove body as a keyword. I've added a summary of their decision to the end of the DIP for anyone who cares to read it. In short: * body temporarily becomes a contextual keyword and is deprecated * do is immediately allowed in its place * body is removed and do replaces it fully Congratulations, Jared! https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md Congrats to all who worked on this. Next step is to revise the DIP that puts the approved option to the fore and mentions the others only as other options that have been analyzed. This is because we have an "Approved" status but not "Approved Option X". Thanks! -- Andrei Sorry, was looking at a stale copy. I think the DIP is fine as is. The previously discussed options are available as earlier revisions of the DIP. -- Andrei
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Saturday, 3 June 2017 at 07:01:48 UTC, Walter Bright wrote: On 6/2/2017 9:56 PM, MysticZach wrote: Also Mike Parker seems to be doing a very good job in his appointed position as DIP manager. Yes, I am very happy with Mike's contributions on this, as well as on his blog work. We are very fortunate to have Mike with us. Thanks!
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On 2017-06-02 16:17, Mike Parker wrote: Congratulations are in order for Jared Hanson. Walter and Andrei have approved his proposal to remove body as a keyword. I've added a summary of their decision to the end of the DIP for anyone who cares to read it. In short: * body temporarily becomes a contextual keyword and is deprecated * do is immediately allowed in its place * body is removed and do replaces it fully Congratulations, Jared! https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md That's great. BTW, didn't we use to vote on the DIPs, or was that only for new Phobos modules? -- /Jacob Carlborg
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On 6/2/17 10:17 AM, Mike Parker wrote: Congratulations are in order for Jared Hanson. Walter and Andrei have approved his proposal to remove body as a keyword. I've added a summary of their decision to the end of the DIP for anyone who cares to read it. In short: * body temporarily becomes a contextual keyword and is deprecated * do is immediately allowed in its place * body is removed and do replaces it fully Congratulations, Jared! https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md Congrats to all who worked on this. Next step is to revise the DIP that puts the approved option to the fore and mentions the others only as other options that have been analyzed. This is because we have an "Approved" status but not "Approved Option X". Thanks! -- Andrei
Re: DIP 1003 (Remove body as a Keyword) Accepted!
Petar Kirov [ZombineDev] wrote: Personally, making contracts less verbose and more powerful is much higher on my list (I don't remember ever needing to use 'body' as an identifier, but I see why is it important for many domains) yeah. i'm really tired to use `flesh` instead of it. and i have bodies literally everywhere: active, sleeping, dead, broken... several of my game engines has more-or-less physics-based simulations, so i need `body`! ;-)
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Friday, June 02, 2017 23:44:21 H. S. Teoh via Digitalmars-d-announce wrote: > On Sat, Jun 03, 2017 at 04:56:40AM +, MysticZach via > Digitalmars-d-announce wrote: [...] > > > Yes, congratulations are in order. Although those of us who were > > questioning the need for any keyword at all in `body`s place may be a > > little disappointed that it has merely been replaced with `do`, I > > think no one can doubt the main thrust of the DIP, which is that > > `body` is an incredibly useful identifier, and that having it newly > > available makes D a better language. > > [...] > > Yes, count me somewhat disappointed at merely changing `body` to `do`. > But at least it's better than nothing, and frees as `body` as an > identifier instead of a keyword that's only ever used in a single > context. And it's marginally shorter to type. :-D I cared far more about getting rid of the need for a keyword there than freeing up body, so I'm not sure that I care much about this change (particularly since I rarely deal with cases where I'd use body as a variable name), but it's still good that body was freed up. - Jonathan M Davis
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Saturday, 3 June 2017 at 04:56:40 UTC, MysticZach wrote: On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote: Congratulations are in order for Jared Hanson. Walter and Andrei have approved his proposal to remove body as a keyword. I've added a summary of their decision to the end of the DIP for anyone who cares to read it. In short: * body temporarily becomes a contextual keyword and is deprecated * do is immediately allowed in its place * body is removed and do replaces it fully Congratulations, Jared! https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md Yes, congratulations are in order. Although those of us who were questioning the need for any keyword at all in `body`s place may be a little disappointed that it has merely been replaced with `do`, I think no one can doubt the main thrust of the DIP, which is that `body` is an incredibly useful identifier, and that having it newly available makes D a better language. Personally, making contracts less verbose and more powerful is much higher on my list (I don't remember ever needing to use 'body' as an identifier, but I see why is it important for many domains), so I'm also disappointed that we replaced one keyword with another. At least 'body' will be a contextual keyword, so it won't cause a massive breakage. Also, I've been following the forums for several years now, and this is the first DIP that I know of that was not written by the language authors, and yet was still accepted into the language. Correct me if I'm wrong, but that seems like a real landmark! Yes, it's the first approved DIP after DIP1000, but there are quite a few approved DIPs not coming Walter and Andrei before that: https://wiki.dlang.org/DIPs - DIP2, DIP3, DIP6, DIP9 (it seems it got traction, even though it doesn't say approved) DIP12, DIP18 (it looks like it was the first @nogc proposal) DIP20, DIP37, DIP42, DIP43 (it's partially implemented), and so on. Actually most language enhancements happened without going through the DIP process. These are that went through bugzilla: https://issues.dlang.org/buglist.cgi?bug_severity=enhancement_status=RESOLVED=dmd_id=215170=bug_id=D_based_on=_format=advanced=FIXED=D2 and many other exist only as pull requests on GitHub - a very incomplete list: https://github.com/dlang/dmd/pulls?utf8=✓=is%3Apr%20is%3Aclosed%20enhancement. If you look carefully at the history in bugzilla and github, even though probably most of the enhancements were little, you'll see there many huge changes to the language that should have gone through the DIP process, but have not. Also Mike Parker seems to be doing a very good job in his appointed position as DIP manager. Agreed, I'm optimistic about the DIP process under his lead.
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On 6/2/2017 9:56 PM, MysticZach wrote: Also Mike Parker seems to be doing a very good job in his appointed position as DIP manager. Yes, I am very happy with Mike's contributions on this, as well as on his blog work. We are very fortunate to have Mike with us.
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Sat, Jun 03, 2017 at 04:56:40AM +, MysticZach via Digitalmars-d-announce wrote: [...] > Yes, congratulations are in order. Although those of us who were > questioning the need for any keyword at all in `body`s place may be a > little disappointed that it has merely been replaced with `do`, I > think no one can doubt the main thrust of the DIP, which is that > `body` is an incredibly useful identifier, and that having it newly > available makes D a better language. [...] Yes, count me somewhat disappointed at merely changing `body` to `do`. But at least it's better than nothing, and frees as `body` as an identifier instead of a keyword that's only ever used in a single context. And it's marginally shorter to type. :-D T -- This sentence is false.
Re: DIP 1003 (Remove body as a Keyword) Accepted!
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
