Red Hat's issues in considering the D language
Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b Thanks, Andrei
Re: Red Hat's issues in considering the D language
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b Pretty cool. One of the DUB issues is: There is no default "release-build-with-debug-symbols" target. Seems like a documentation bug, because: dub -b release-debug does exist. Now: https://github.com/dlang/dub/issues/1025
Re: Red Hat's issues in considering the D language
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b Thanks, Andrei It's always the same thing, isn't it ? DMD isn't free software (as non redistribuable), poor integration with existing tools and file format (here deps files, but generally almost everything use its own format rather than industry standard), non standard command line flags/syntax, and unittest are kind of weird.
Re: Red Hat's issues in considering the D language
On 2016-12-21 00:08, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b I had a suggestion [1] to do something about the current state of unit tests but that was quickly shot down or went (slightly) off topic. [1] http://forum.dlang.org/thread/npptbk$2mk0$1...@digitalmars.com -- /Jacob Carlborg
Re: Red Hat's issues in considering the D language
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b Thanks, Andrei The assert/unittest issues can be solved with a library: https://github.com/nomad-software/dunit
Re: Red Hat's issues in considering the D language
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. Is moving to LLVM backend or LDC something that is on the roadmap?
Re: Red Hat's issues in considering the D language
On 12/20/16 6:08 PM, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b An engineer from Debian wrote down what's needed on the distribution side to give a green light to the D language: https://gist.github.com/ximion/fe6264481319dd94c8308b1ea4e8207a Andrei
Re: Red Hat's issues in considering the D language
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b Thanks, Andrei What is the story over the ownership of DMD's backend? I believe Walter's former employer has some stake in it. Has Walter spoken to them about them donating whatever rights they have to the D foundation?
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 13:18:48 UTC, Andrei Alexandrescu wrote: On 12/20/16 6:08 PM, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b An engineer from Debian wrote down what's needed on the distribution side to give a green light to the D language: https://gist.github.com/ximion/fe6264481319dd94c8308b1ea4e8207a Andrei Thank you for finding this links. The listed issues are very important.
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 13:26:14 UTC, ixid wrote: On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b Thanks, Andrei What is the story over the ownership of DMD's backend? I believe Walter's former employer has some stake in it. Has Walter spoken to them about them donating whatever rights they have to the D foundation? You have the answer elements here https://forum.dlang.org/search?q=backend%20symantec&page=1. tl;dr: the backend comes from a commercial C++ compiler that was written by Bright but commercialized by Symantec. This company still owns the rights. I'd like to add that the windows version would require another change so that DMD becomes true FOSS. Unless the 32 bit version get dropped away, the standard C library, snn.lib, is even not open-sourced (which is a worst than the backend situation) !
Re: Red Hat's issues in considering the D language
On 2016-12-21 15:58, Madaz Hill wrote: I'd like to add that the windows version would require another change so that DMD becomes true FOSS. Unless the 32 bit version get dropped away, the standard C library, snn.lib, is even not open-sourced (which is a worst than the backend situation) ! A. The 64bit version uses the Microsoft tool chain, how is that more open source? B. It's possible to use the Microsoft tool chain when compiling for 32bit as well -- /Jacob Carlborg
Re: Red Hat's issues in considering the D language
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b I'm the author of Terminix (https://github.com/gnunn1/terminix), a semi-popular terminal emulator for Gnome and Linux. Ximion was the driving force behind getting terminix, ldc and other D related programs packaged for Debian. I'm glad he took the time to write up the issues and share them here. Most of the issues he highlights are relevant for all of the Linux distros so solving them would really help applications written in D gain a wider audience and make it more viable for developers to choose it. Given that DMD is a non-starter for Linux packages, how feasible is it to simply deprecate GDC and declare LDC as the reference/production compiler for D? DMD could become the experimental/future facing compiler used to evolve D as a language but not meant to be used for production code. This would resolve the non-free aspect of DMD as well as the ABI issue between compilers. It should also be noted that Gnome is looking into Rust as well: http://www.phoronix.com/scan.php?page=news_item&px=GNOME-Potential-Rust
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 15:46:19 UTC, Gerald wrote: Given that DMD is a non-starter for Linux packages, how feasible is it to simply deprecate GDC and declare LDC as the reference/production compiler for D? DMD could become the experimental/future facing compiler used to evolve D as a language but not meant to be used for production code. This would resolve the non-free aspect of DMD as well as the ABI issue between compilers. These are choices that are made by individual developers. Someone wanting to use one compiler or the other can simply do so.
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: Is moving to LLVM backend or LDC something that is on the roadmap? Nope.
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. Is moving to LLVM backend or LDC something that is on the roadmap? What does it mean to "move" to LDC? Why can't you use LDC now?
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 16:20:31 UTC, Jack Stouffer wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: Is moving to LLVM backend or LDC something that is on the roadmap? Nope. So whats the solution to the "DMD compiler issues" listed?
Re: Red Hat's issues in considering the D language
On 12/21/2016 11:32 AM, hardreset wrote: On Wednesday, 21 December 2016 at 16:20:31 UTC, Jack Stouffer wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: Is moving to LLVM backend or LDC something that is on the roadmap? Nope. So whats the solution to the "DMD compiler issues" listed? We are working on it, cannot disclose more for the time being. -- Andrei
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. Is moving to LLVM backend or LDC something that is on the roadmap? What does it mean to "move" to LDC? Why can't you use LDC now? Moving the reference compiler to LLVM as was suggested in the list.
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: Is moving to LLVM backend or LDC something that is on the roadmap? What does it mean to "move" to LDC? Why can't you use LDC now? People that want to use D, want to use the latest and greatest. The reference compiler moves the fastest so they want the reference compiler to be switched to a different backend. Why a FOSS back end is required to use D depends on the person, usually it is political.
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: Moving the reference compiler to LLVM as was suggested in the list. LDC is the only compiler on Fedora/CentOS anyway!
Re: Red Hat's issues in considering the D language
Am Wed, 21 Dec 2016 08:18:48 -0500 schrieb Andrei Alexandrescu : > On 12/20/16 6:08 PM, Andrei Alexandrescu wrote: > > Hello, a few engineers at Red Hat are taking a look at using the D > > language on the desktop and have reached out to us. They have > > created a list of issues. We are on the top-level ones, and of > > course would appreciate any community help as well. > > > > https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b > > An engineer from Debian wrote down what's needed on the distribution > side to give a green light to the D language: > > https://gist.github.com/ximion/fe6264481319dd94c8308b1ea4e8207a > > > Andrei > "GDC does not support creating shared libraries at time, which is a big deal for distros which need it to reduce duplicate code and make security fixes easier." You can cross that one off the list. "GDC only supports an ancient version of the D standard library, which has many nice classes and also bugfixes missing." We're at 2.068.2 now. Still old, but good enough to run the latest vibe.D release. From a compiler dev point of view I think one of the most important issues is the stable ABI. Many of the compiler specific problems could be solved easily if we could mix code from different compilers.
Re: Red Hat's issues in considering the D language
Am Wed, 21 Dec 2016 15:46:19 + schrieb Gerald : > Given that DMD is a non-starter for Linux packages, how feasible > is it to simply deprecate GDC and declare LDC as the > reference/production compiler for D? Hey, GDC is still in active development ;-) We need some more time to catch up but we'll get there. OTOH if people start compiling recent D code with compilers from debian stable you'll have to support old frontend versions anyway :-P
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 17:49:43 UTC, Johannes Pfau wrote: We're at 2.068.2 now. Still old, but good enough to run the latest vibe.D release. Just a quick heads up (and maybe motivation): the upcoming 0.8.0 release will drop the support for 2.068 ;-) https://github.com/rejectedsoftware/vibe.d/commit/ce9c1250aeef97c948787192136e611525c3df3c
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. Is moving to LLVM backend or LDC something that is on the roadmap? What does it mean to "move" to LDC? Why can't you use LDC now? Moving the reference compiler to LLVM as was suggested in the list. I've never been able to understand why it matters. You can use LDC or GDC now. Slapping the name "reference compiler" on one of them won't change anything. I think most frontend developers prefer working in the DMD umbrella for speed and simplicity reasons. Editing and building DMD is dead simple. In theory the backend should be completely divorced from the frontend and people would be editing a libd repo or something and there wouldn't be a need for a reference compiler.
Re: Red Hat's issues in considering the D language
On Wed, Dec 21, 2016 at 06:33:52PM +, Brad Anderson via Digitalmars-d wrote: [...] > In theory the backend should be completely divorced from the frontend > and people would be editing a libd repo or something and there > wouldn't be a need for a reference compiler. Isn't our plan to eventually split the backend from the frontend? But I understand that will be a long process, given the current state of the code. T -- Why are you blatanly misspelling "blatant"? -- Branden Robinson
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 18:33:52 UTC, Brad Anderson wrote: On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: [...] Is moving to LLVM backend or LDC something that is on the roadmap? What does it mean to "move" to LDC? Why can't you use LDC now? Moving the reference compiler to LLVM as was suggested in the list. I've never been able to understand why it matters. You can use LDC or GDC now. Slapping the name "reference compiler" on one of them won't change anything. I think most frontend developers prefer working in the DMD umbrella for speed and simplicity reasons. Editing and building DMD is dead simple. In theory the backend should be completely divorced from the frontend and people would be editing a libd repo or something and there wouldn't be a need for a reference compiler. It will simplify development process for DRuntime, LDC and GDC. In addition, DMD support for numeric libraries requires more efforts and workarounds. DMD is less documented then LLVM (this is important for numeric and betterC libraries) --Ilya
Re: Red Hat's issues in considering the D language
On 12/21/2016 12:49 PM, Johannes Pfau wrote: We're at 2.068.2 now. Johannes, are you personally involved with gdc? If so please email me. Thanks! -- Andrei
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 16:41:58 UTC, Jesse Phillips wrote: On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: Is moving to LLVM backend or LDC something that is on the roadmap? What does it mean to "move" to LDC? Why can't you use LDC now? People that want to use D, want to use the latest and greatest. The reference compiler moves the fastest so they want the reference compiler to be switched to a different backend. Why a FOSS back end is required to use D depends on the person, usually it is political. Any other backend would be better. DMD with -O takes over an hour for my project to compile. In comparison LDC with -O3 takes less than a minute and produces a faster binary. It doesn't really make sense to increase the workload maintaining 2-3 different compilers when D is already lacking manpower.
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote: Any other backend would be better. DMD with -O takes over an hour for my project to compile. In comparison LDC with -O3 takes less than a minute and produces a faster binary. It doesn't really make sense to increase the workload maintaining 2-3 different compilers when D is already lacking manpower. A 60:1 speedup? I've never heard of that big of a difference before. Especially since LDC is typically slower to compile, even on massive code bases like Weka's. Could you please file a bug with some details?
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote: On Wednesday, 21 December 2016 at 16:41:58 UTC, Jesse Phillips wrote: On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: [...] People that want to use D, want to use the latest and greatest. The reference compiler moves the fastest so they want the reference compiler to be switched to a different backend. Why a FOSS back end is required to use D depends on the person, usually it is political. Any other backend would be better. DMD with -O takes over an hour for my project to compile. In comparison LDC with -O3 takes less than a minute and produces a faster binary. It doesn't really make sense to increase the workload maintaining 2-3 different compilers when D is already lacking manpower. That sounds like a bug in the DMD backend...
Re: Red Hat's issues in considering the D language
On Wednesday, December 21, 2016 22:05:32 Yuxuan Shui via Digitalmars-d wrote: > On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote: > > On Wednesday, 21 December 2016 at 16:41:58 UTC, Jesse Phillips > > > > wrote: > >> On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier > >> > >> wrote: > >>> [...] > >> > >> People that want to use D, want to use the latest and > >> greatest. The reference compiler moves the fastest so they > >> want the reference compiler to be switched to a different > >> backend. Why a FOSS back end is required to use D depends on > >> the person, usually it is political. > > > > Any other backend would be better. DMD with -O takes over an > > hour for my project to compile. In comparison LDC with -O3 > > takes less than a minute and produces a faster binary. It > > doesn't really make sense to increase the workload maintaining > > 2-3 different compilers when D is already lacking manpower. > > That sounds like a bug in the DMD backend... Definitely. It is almost always the case that building a program with dmd is much faster than building with gdc or ldc. The tradeoff is that gdc and ldc do a much better job optimizing the resultant binary. So, with dmd, you get fast compilation but a somewhat slower binary, whereas with gdc and ldc, you get slow compilation but a faster binary. If anyone is seeing dmd compile anything significantly more slowly than gdc or ldc, then dmd has a bug, and it should be reported (though reducing the code to something reportable can be entertaining; fortunately, dustmite can be a big help with that). - Jonathan M Davis
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 21:27:57 UTC, Jack Stouffer wrote: On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote: Any other backend would be better. DMD with -O takes over an hour for my project to compile. In comparison LDC with -O3 takes less than a minute and produces a faster binary. It doesn't really make sense to increase the workload maintaining 2-3 different compilers when D is already lacking manpower. A 60:1 speedup? I've never heard of that big of a difference before. Especially since LDC is typically slower to compile, even on massive code bases like Weka's. Could you please file a bug with some details? I ran it again, was a bit over a minute. But still 1 min 30 seconds compared to an hour. 1:07:40.162314 -- dmd with -O 0:01:28.632916 -- ldc2 with -O 0:00:23.802639 -- dmd without -O 0:00:33.818080 -- ldc2 without -O It'd be quite a bit of work to narrow down what it is and if it has something to do with how many structures I use or otherwise. I'd have to try and emulate that with test code as I can't use my code. Then the issue would just sit there for who knows how long. It's not that big of an issue, as I just use ldc2 instead anyways.
Re: Red Hat's issues in considering the D language
On Wednesday, December 21, 2016 15:46:19 Gerald via Digitalmars-d wrote: > Given that DMD is a non-starter for Linux packages, how feasible > is it to simply deprecate GDC and declare LDC as the > reference/production compiler for D? DMD could become the > experimental/future facing compiler used to evolve D as a > language but not meant to be used for production code. This would > resolve the non-free aspect of DMD as well as the ABI issue > between compilers. Anyone who wants to use ldc can use ldc. It doesn't need to be the reference compiler for that. And unlike gdc, it's actually pretty close to dmd. So, there should be no problem with folks using ldc for production right now if they want to. - Jonathan M Davis
Re: Red Hat's issues in considering the D language
On Wednesday, December 21, 2016 18:49:43 Johannes Pfau via Digitalmars-d wrote: > Am Wed, 21 Dec 2016 08:18:48 -0500 > > schrieb Andrei Alexandrescu : > > On 12/20/16 6:08 PM, Andrei Alexandrescu wrote: > > > Hello, a few engineers at Red Hat are taking a look at using the D > > > language on the desktop and have reached out to us. They have > > > created a list of issues. We are on the top-level ones, and of > > > course would appreciate any community help as well. > > > > > > https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b > > > > An engineer from Debian wrote down what's needed on the distribution > > side to give a green light to the D language: > > > > https://gist.github.com/ximion/fe6264481319dd94c8308b1ea4e8207a > > > > > > Andrei > > "GDC does not support creating shared libraries at time, which is a big > deal for distros which need it to reduce duplicate code and make > security fixes easier." > > You can cross that one off the list. > > "GDC only supports an ancient version of the D standard library, which > has many nice classes and also bugfixes missing." > > We're at 2.068.2 now. Still old, but good enough to run the latest > vibe.D release. Well, that's quite old at this point, and many programs will not build with it. vibe.d is a bit abnormal in that it tries to compile with several releases, whereas most projects tend to just use the latest. So, I think that the complaint that "GDC only supports an ancient version of the D standard library" is completely justified. At this point, if you want to compile with GDC, you pretty much need to target it and/or version portions of your code for different compilers or different compiler/library versions (which is what the vibe.d guys go to the extra effort of doing but very few D developers do). I fully expect that GDC will eventually catch up, but unfortunately, until it does, for many projects, it's useless. And I'd honestly recommend to people to avoid it until it does catch up, since otherwise, they're just going to run into compatability problems, and when they ask questions on SO or in the forums about what does or doesn't work, they're going to have problems due to differences in what does and doesn't work with GDC vs dmd and ldc. - Jonathan M Davis
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 18:33:52 UTC, Brad Anderson wrote: On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. Is moving to LLVM backend or LDC something that is on the roadmap? What does it mean to "move" to LDC? Why can't you use LDC now? Moving the reference compiler to LLVM as was suggested in the list. I've never been able to understand why it matters. Cause people think LDC is better and it would be a big win if everyone focused just on that. It's not about which has "official compiler" slapped on it, it's about where the development effort is focused. That said I dont care really, I was just curious what the solution was to the closed source back end was.
Re: Red Hat's issues in considering the D language
On 12/21/16 7:09 PM, Jerry wrote: On Wednesday, 21 December 2016 at 21:27:57 UTC, Jack Stouffer wrote: On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote: Any other backend would be better. DMD with -O takes over an hour for my project to compile. In comparison LDC with -O3 takes less than a minute and produces a faster binary. It doesn't really make sense to increase the workload maintaining 2-3 different compilers when D is already lacking manpower. A 60:1 speedup? I've never heard of that big of a difference before. Especially since LDC is typically slower to compile, even on massive code bases like Weka's. Could you please file a bug with some details? I ran it again, was a bit over a minute. But still 1 min 30 seconds compared to an hour. 1:07:40.162314 -- dmd with -O 0:01:28.632916 -- ldc2 with -O 0:00:23.802639 -- dmd without -O 0:00:33.818080 -- ldc2 without -O It'd be quite a bit of work to narrow down what it is and if it has something to do with how many structures I use or otherwise. I'd have to try and emulate that with test code as I can't use my code. Then the issue would just sit there for who knows how long. It's not that big of an issue, as I just use ldc2 instead anyways. Would be great to narrow this down regardless. Shouldn't be too difficult since the penalty is so huge. Must be a pathological case we should fix anyway. -- Andrei
Re: Red Hat's issues in considering the D language
On Thursday, December 22, 2016 00:59:27 hardreset via Digitalmars-d wrote: > On Wednesday, 21 December 2016 at 18:33:52 UTC, Brad Anderson > >> Moving the reference compiler to LLVM as was suggested in the > >> list. > > > > I've never been able to understand why it matters. > > Cause people think LDC is better and it would be a big win if > everyone focused just on that. It's not about which has "official > compiler" slapped on it, it's about where the development effort > is focused. Most of the focus is on the frontend, not any of the backends. So, most of the work is automatically shared across all of the compilers. It's just that the frontend isn't 100% compiler agnostic (though work has been done to get it there), so some work has to be done to get it and the glue layer updated, and dmd gets that first. LDC isn't far behind though. GDC's main problem is the hump in getting from the frontend being in C++ to it being in D, and once they've got that sorted out, I expect that they'll be _much_ faster at updating. Regardless, most of the effort is going towards stuff that has nothing to do with the compiler backend. - Jonathan M Davis
Re: Red Hat's issues in considering the D language
On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei Alexandrescu wrote: Must be a pathological case we should fix anyway. -- Andrei Likely related bug has been open 5 years minus 1 day: https://issues.dlang.org/show_bug.cgi?id=7157
Re: Red Hat's issues in considering the D language
On Thursday, 22 December 2016 at 01:57:55 UTC, safety0ff wrote: On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei Alexandrescu wrote: Must be a pathological case we should fix anyway. -- Andrei Likely related bug has been open 5 years minus 1 day: https://issues.dlang.org/show_bug.cgi?id=7157 Yup looks like that was the cause. Removed some of the functions that did a "foreach()" over some large tuples. Down to 26 seconds with that removed.
Re: Red Hat's issues in considering the D language
On Thursday, 22 December 2016 at 02:32:30 UTC, Jerry wrote: On Thursday, 22 December 2016 at 01:57:55 UTC, safety0ff wrote: On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei Alexandrescu wrote: Must be a pathological case we should fix anyway. -- Andrei Likely related bug has been open 5 years minus 1 day: https://issues.dlang.org/show_bug.cgi?id=7157 Yup looks like that was the cause. Removed some of the functions that did a "foreach()" over some large tuples. Down to 26 seconds with that removed. tuples as in compiler tuples ? The T... kind ?
Re: Red Hat's issues in considering the D language
On Thursday, 22 December 2016 at 02:32:30 UTC, Jerry wrote: Yup looks like that was the cause. Removed some of the functions that did a "foreach()" over some large tuples. Down to 26 seconds with that removed. Also: https://issues.dlang.org/show_bug.cgi?id=2396
Re: Red Hat's issues in considering the D language
On Thursday, 22 December 2016 at 02:34:48 UTC, Stefan Koch wrote: On Thursday, 22 December 2016 at 02:32:30 UTC, Jerry wrote: On Thursday, 22 December 2016 at 01:57:55 UTC, safety0ff wrote: On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei Alexandrescu wrote: Must be a pathological case we should fix anyway. -- Andrei Likely related bug has been open 5 years minus 1 day: https://issues.dlang.org/show_bug.cgi?id=7157 Yup looks like that was the cause. Removed some of the functions that did a "foreach()" over some large tuples. Down to 26 seconds with that removed. tuples as in compiler tuples ? The T... kind ? Not using AliasSeq if that's what you mean. I don't know if the "tupleof" for a struct would be considered the same as "T..." but basically what I was doing: foreach(ref field; myLargeStruct.tupleof) { }
Re: Red Hat's issues in considering the D language
On Thursday, 22 December 2016 at 03:18:42 UTC, Jerry wrote: Not using AliasSeq if that's what you mean. I don't know if the "tupleof" for a struct would be considered the same as "T..." but basically what I was doing: foreach(ref field; myLargeStruct.tupleof) { } Yes that is a compiler-tuple as well. which means that the foreach is not loop at all. Rather it's body gets duplicated myLargeStruct.tupleof.length times. Leading to giant numbers statements, at those conditions N^{2,3,N} algorithms in the optimizer do not scale gracefully.
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 23:33:50 UTC, Jonathan M Davis wrote: Definitely. It is almost always the case that building a program with dmd is much faster than building with gdc or ldc. The tradeoff is that gdc and ldc do a much better job optimizing the resultant binary. So, with dmd, you get fast compilation but a somewhat slower binary, whereas with gdc and ldc, you get slow compilation but a faster binary. If anyone is seeing dmd compile anything significantly more slowly than gdc or ldc, then dmd has a bug, and it should be reported (though reducing the code to something reportable can be entertaining; fortunately, dustmite can be a big help with that). - Jonathan M Davis That is very true for regular build, but not especially for optimized builds.
Re: Red Hat's issues in considering the D language
? I am on fedora and I have dmd, so it is not true :P Dejan Lekic via Digitalmars-d napsal St, pro 21, 2016 v 6∶36 : On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: Moving the reference compiler to LLVM as was suggested in the list. LDC is the only compiler on Fedora/CentOS anyway!
Re: Red Hat's issues in considering the D language
On Thursday, 22 December 2016 at 08:33:55 UTC, Daniel Kozák wrote: ? I am on fedora and I have dmd, so it is not true :P Dejan Lekic via Digitalmars-d napsal St, pro 21, 2016 v 6∶36 : On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: Moving the reference compiler to LLVM as was suggested in the list. LDC is the only compiler on Fedora/CentOS anyway! I am on CentOS and I have dmd too. :)
Re: Red Hat's issues in considering the D language
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b Aren't requirements for packaging and recent versions mutually exclusive? The packaged version will undergo version freeze and will be older than the recent version no matter what you package. Unittest checks are not necessarily the same as asserts in the application code. Unittest checks throwing exceptions of a different type than exceptions from the application code are useful for precise analysis of exceptions. Unittests also need indication of unconditional failure and inconclusive tests. Builtin unittests just give a run to the code, they shouldn't be written in such a way that you can't figure out what's going on there. Confusing claim that he can't use dmd given that he says he uses it.
Re: Red Hat's issues in considering the D language
To clarify this point on the list: On Thursday, 22 December 2016 at 10:40:32 UTC, Kagamin wrote: On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b Aren't requirements for packaging and recent versions mutually exclusive? The packaged version will undergo version freeze and will be older than the recent version no matter what you package. This is true when the distribution is frozen, but there is a time when we will just get new software versions in there as soon as they are released. But the much more important point for us is support and maintainability. The reference compiler will have a much bigger development team and higher focus of attention. Additionally, people will likely build their code with that compiler and might not test with other compilers. So, if we then take D code and build it with a configuration upstream didn't test, and then encounter a bug, this will be an additional obstacle to overcome when communicating with upstream. Furthermore, the compiler package - once frozen - will have to be supported for many years, and a bigger team behind it helps in finding issues and fixing them. Additionally, people learning D will told "use DMD" and won't find it in their distribution, which is annoying for them (they think D isn't well supported, while our LDC/GDC packages are less used). Those are all points which make it useful to have a completely free compiler as reference compiler and in the distribution. On the point of "free" being ideological: It of course is also an ideological issue, but that's not the only point. See this excerpt from the DMD backend license: ``` The Software is copyrighted and comes with a single user license, and may not be redistributed. If you wish to obtain a redistribution license, please contact Digital Mars. ``` This alone makes it impossible for use and all our derivatives to legally redistribute the software. Adding it to a distro is a no-op. Also, licenses restricting modification of software or proprietary software in general makes it impossible for use to deliver security fixes, and also makes integrating the software into the system much harder and sometimes impossible. For GDC: Being part of GCC would be very awesome there, because then the Toolchain team of the respective distributions could easily make the D compiler available and maintain it (as done with e.g. gccgo for the Go language). At time we patch in GDC and Debian, but it looks like Red Hat will not go that way on RHEL/Fedora (and I completely understand why they don't want to do that). Anyway, it's great to hear that the GDC Phobos isn't as old anymore as it was when I wrote the first version of the list :) Confusing claim that he can't use dmd given that he says he uses it. Huh? Where is this stated?
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 17:49:43 UTC, Johannes Pfau wrote: Am Wed, 21 Dec 2016 08:18:48 -0500 schrieb Andrei Alexandrescu : On 12/20/16 6:08 PM, Andrei Alexandrescu wrote: > Hello, a few engineers at Red Hat are taking a look at using > the D language on the desktop and have reached out to us. > They have created a list of issues. We are on the top-level > ones, and of course would appreciate any community help as > well. > > https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b An engineer from Debian wrote down what's needed on the distribution side to give a green light to the D language: https://gist.github.com/ximion/fe6264481319dd94c8308b1ea4e8207a From a compiler dev point of view I think one of the most important issues is the stable ABI. Many of the compiler specific problems could be solved easily if we could mix code from different compilers. Rust is considering to install packages as source code. https://internals.rust-lang.org/t/debian-rust-packaging-policy-draft/4453 Not an ideal solution. Having a stable ABI would be better. A pragmatic idea, though.
Re: Red Hat's issues in considering the D language
On Wed, 2016-12-21 at 16:32 +, hardreset via Digitalmars-d wrote: > On Wednesday, 21 December 2016 at 16:20:31 UTC, Jack Stouffer > wrote: > > On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: > > > Is moving to LLVM backend or LDC something that is on the > > > roadmap? > > > > Nope. > > So whats the solution to the "DMD compiler issues" listed? Use LDC. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Red Hat's issues in considering the D language
On Wed, 2016-12-21 at 15:49 -0800, Jonathan M Davis via Digitalmars-d wrote: > […] > > Anyone who wants to use ldc can use ldc. It doesn't need to be the > reference > compiler for that. And unlike gdc, it's actually pretty close to dmd. > So, > there should be no problem with folks using ldc for production right > now if > they want to. Strikes me that the really obvious thing to say is that DMD is the playground where whoever wants to can play with and progress the D front end in the knowledge that no-one is going to use DMD in production. People use LDC in production because it is the right thing to do: stable proven front end, stable proven backend, and yet up to date. What is not to like here? What is the problem here? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Red Hat's issues in considering the D language
On 24/12/2016 3:14 AM, Russel Winder via Digitalmars-d wrote: On Wed, 2016-12-21 at 15:49 -0800, Jonathan M Davis via Digitalmars-d wrote: […] Anyone who wants to use ldc can use ldc. It doesn't need to be the reference compiler for that. And unlike gdc, it's actually pretty close to dmd. So, there should be no problem with folks using ldc for production right now if they want to. Strikes me that the really obvious thing to say is that DMD is the playground where whoever wants to can play with and progress the D front end in the knowledge that no-one is going to use DMD in production. People use LDC in production because it is the right thing to do: stable proven front end, stable proven backend, and yet up to date. What is not to like here? What is the problem here? Except dmd's backend is far more well proven then LLVM is. So that argument needs to be tweaked a little bit.
Re: Red Hat's issues in considering the D language
On Friday, 23 December 2016 at 14:44:41 UTC, rikki cattermole wrote: On 24/12/2016 3:14 AM, Russel Winder via Digitalmars-d wrote: On Wed, 2016-12-21 at 15:49 -0800, Jonathan M Davis via Digitalmars-d wrote: […] Anyone who wants to use ldc can use ldc. It doesn't need to be the reference compiler for that. And unlike gdc, it's actually pretty close to dmd. So, there should be no problem with folks using ldc for production right now if they want to. Strikes me that the really obvious thing to say is that DMD is the playground where whoever wants to can play with and progress the D front end in the knowledge that no-one is going to use DMD in production. People use LDC in production because it is the right thing to do: stable proven front end, stable proven backend, and yet up to date. What is not to like here? What is the problem here? Except dmd's backend is far more well proven then LLVM is. So that argument needs to be tweaked a little bit. It is not true for Mir projects, sometimes ICE occurs without any description while LDC just works. --Ilya Bug report for ICEs requires to much efforts because code size should be reduced.
Re: Red Hat's issues in considering the D language
On Friday, 23 December 2016 at 15:02:23 UTC, Ilya Yaroshenko wrote: [...] It is not true for Mir projects, sometimes ICE occurs without any description while LDC just works. --Ilya Bug report for ICEs requires to much efforts because code size should be reduced. I found quite a few in LDC too ;-) In any case, Dustmite[1] helps to greatly reduce the time needed to create a minimal testcase to report as a bug, and the tool will soon be available as a Debian package as well (anything that doesn't use dub and is no library is rather easy to package). [1]: https://github.com/CyberShadow/DustMite
Re: Red Hat's issues in considering the D language
On Friday, December 23, 2016 14:14:41 Russel Winder via Digitalmars-d wrote: > On Wed, 2016-12-21 at 15:49 -0800, Jonathan M Davis via Digitalmars-d > > wrote: > > […] > > > > Anyone who wants to use ldc can use ldc. It doesn't need to be the > > reference > > compiler for that. And unlike gdc, it's actually pretty close to dmd. > > So, > > there should be no problem with folks using ldc for production right > > now if > > they want to. > > Strikes me that the really obvious thing to say is that DMD is the > playground where whoever wants to can play with and progress the D > front end in the knowledge that no-one is going to use DMD in > production. People use LDC in production because it is the right thing > to do: stable proven front end, stable proven backend, and yet up to > date. > > What is not to like here? What is the problem here? dmd compiles code faster, which is better from a development standpoint. Assuming that dmd and ldc are compatible enough, it makes a lot of sense to do most of the development with dmd and produce the actual product with ldc. But if someone wants to use ldc for the whole thing because of FOSS concerns or personal preference or whatever, that's fine too. It's just not what I'd want to do if I could avoid it. dmd's compilation speed is worth a lot. - Jonathan M Davis
Re: Red Hat's issues in considering the D language
On Thursday, 22 December 2016 at 12:15:06 UTC, Matthias Klumpp wrote: But the much more important point for us is support and maintainability. The reference compiler will have a much bigger development team and higher focus of attention. Bugs in frontend, phobos and most of druntime currently go to DMD team. Bugs in LLVM backend go to LLVM team. The bug you had with atomicOp was trivial and was fixed in a day. Additionally, people learning D will told "use DMD" and won't find it in their distribution, which is annoying for them (they think D isn't well supported, while our LDC/GDC packages are less used). That recommendation is probably already a mistake. One reason to recommend dmd is that it's recent, but this implies installation of the recent version; if people use packaged version, the recommendation is moot (and they again suffer from old docs and libs). Another reason is compilation speed and some people see it important, so to stop dmd recommendation you also need to kill dmd for good else it will still have speed advantage. Confusing claim that he can't use dmd given that he says he uses it. Huh? Where is this stated? DMD being non-free also makes it incredibly hard to sell D in the FLOSS community. Because of that, I can not actually test my code with dmd which means that I don't benefit from improvements done in druntime, Phobos and other parts of D as quickly as others (You don't benefit from recent improvements because you use a packaged version) When using dmd this is not an issue, since dmd is very fast Ah, I probably misunderstood this as if you use dmd.
Re: Red Hat's issues in considering the D language
On 12/21/2016 5:30 PM, Andrei Alexandrescu wrote: Would be great to narrow this down regardless. Shouldn't be too difficult since the penalty is so huge. Must be a pathological case we should fix anyway. -- Andrei Not a complete solution, but should help: https://github.com/dlang/dmd/pull/6356
Re: Red Hat's issues in considering the D language
On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via Digitalmars-d wrote: > […] > > Except dmd's backend is far more well proven then LLVM is. Come now that is obfuscation – you need to make good on this claim. The LLVM backend has many, many more users than the DMD backend and the LLVM backend is used with many more different languages than the DMD backend. The LLVM backend is proven far more than the DMD backend simply on the basis of statistical likelihood. I'll back LLVM any day in this argument. > So that argument needs to be tweaked a little bit. No it doesn't, it stands as stated. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Red Hat's issues in considering the D language
On Fri, 23 Dec 2016 07:59:40 -0800, Jonathan M Davis via Digitalmars-d wrote: > dmd compiles code faster, which is better from a development standpoint. > Assuming that dmd and ldc are compatible enough, it makes a lot of sense > to do most of the development with dmd and produce the actual product > with ldc. You'll want your CI server to build with both thanks to ABI incompatibilities. That way, if I depend on a library that you wrote, I can grab an official build from the CI server that's ABI-compatible with DMD. Or do everything from source.
Re: Red Hat's issues in considering the D language
On Fri, 23 Dec 2016 18:29:15 +, Russel Winder via Digitalmars-d wrote: > On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via Digitalmars-d > wrote: >> […] >> >> Except dmd's backend is far more well proven then LLVM is. > > Come now that is obfuscation – you need to make good on this claim. > > The LLVM backend has many, many more users than the DMD backend and the > LLVM backend is used with many more different languages than the DMD > backend. The LLVM backend is proven far more than the DMD backend simply > on the basis of statistical likelihood. Plus the number of people on hand to fix errors in LLVM outweighs the number available to fix errors in the DigitalMars backend by a factor of several hundred.
Re: Red Hat's issues in considering the D language
On Friday, 23 December 2016 at 22:41:28 UTC, Chris Wright wrote: On Fri, 23 Dec 2016 18:29:15 +, Russel Winder via Digitalmars-d wrote: On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via Digitalmars-d wrote: […] Except dmd's backend is far more well proven then LLVM is. Come now that is obfuscation – you need to make good on this claim. The LLVM backend has many, many more users than the DMD backend and the LLVM backend is used with many more different languages than the DMD backend. The LLVM backend is proven far more than the DMD backend simply on the basis of statistical likelihood. Plus the number of people on hand to fix errors in LLVM outweighs the number available to fix errors in the DigitalMars backend by a factor of several hundred. Although there is a small delay in that. While we try to remain compilable with LLVM trunk it does tend to break frequently and you then have to use llvm trunk.
Re: Red Hat's issues in considering the D language
On 24/12/2016 7:29 AM, Russel Winder via Digitalmars-d wrote: On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via Digitalmars-d wrote: […] Except dmd's backend is far more well proven then LLVM is. Come now that is obfuscation – you need to make good on this claim. The LLVM backend has many, many more users than the DMD backend and the LLVM backend is used with many more different languages than the DMD backend. The LLVM backend is proven far more than the DMD backend simply on the basis of statistical likelihood. I'll back LLVM any day in this argument. So that argument needs to be tweaked a little bit. No it doesn't, it stands as stated. My entire argument there is from its age.
Re: Red Hat's issues in considering the D language
On Thursday, 22 December 2016 at 08:33:55 UTC, Daniel Kozák wrote: ? I am on fedora and I have dmd, so it is not true :P Dejan Lekic via Digitalmars-d napsal St, pro 21, 2016 v 6∶36 : On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: Moving the reference compiler to LLVM as was suggested in the list. LDC is the only compiler on Fedora/CentOS anyway! What I meant is that LDC is the only D compiler in the official Fedora/CentOS repositories.
Re: Red Hat's issues in considering the D language
On Friday, 23 December 2016 at 14:14:41 UTC, Russel Winder wrote: Strikes me that the really obvious thing to say is that DMD is the playground where whoever wants to can play with and progress the D front end in the knowledge that no-one is going to use DMD in production. People use LDC in production because it is the right thing to do: stable proven front end, stable proven backend, and yet up to date. What is not to like here? What is the problem here? If I need the lastest version for whatever reason, I can't get my LDC build, upgrade it and get it to work. DMD use its own nonsense brew of flags and command line syntax. If I find a bug, report it and get it fixed, I need to wait literally month before being able to use the bugfix in LDC. Or, in short, a playground is not appropriate for the reference compiler if you want to be anything else than a toy.