www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Red Hat's issues in considering the D language

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Dec 20 2016
next sibling parent Guillaume Piolat <first.last gmail.com> writes:
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
Dec 20 2016
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
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.
Dec 20 2016
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Dec 20 2016
prev sibling next sibling parent Gary Willoughby <dev nomad.so> writes:
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
Dec 21 2016
prev sibling next sibling parent reply hardreset <invalid email.address> writes:
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?
Dec 21 2016
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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.
Dec 21 2016
parent reply hardreset <invalid email.address> writes:
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?
Dec 21 2016
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Dec 21 2016
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2016-12-21 at 16:32 +0000, hardreset via Digitalmars-d wrote:

 On Wednesday, 21 December 2016 at 16:20:31 UTC, Jack Stouffer=C2=A0
 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=C2=A0
 roadmap?


=20
 Nope.


=20
 So whats the solution to the "DMD compiler issues" listed?


Use LDC.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 23 2016
prev sibling parent reply bachmeier <no spam.net> writes:
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?
Dec 21 2016
next sibling parent reply hardreset <invalid email.address> writes:
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.
Dec 21 2016
next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
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!
Dec 21 2016
parent reply Daniel =?iso-8859-1?b?S2964Ws=?= via Digitalmars-d writes:
? I am on fedora and I have dmd, so it is not true :P

Dejan Lekic via Digitalmars-d <digitalmars-d puremagic.com> napsal St,=20
pro 21, 2016 v 6=E2=88=B636 :

 On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote:

=20
 Moving the reference compiler to LLVM as was suggested in the list.


=20
 LDC is the only compiler on Fedora/CentOS anyway!


=
Dec 22 2016
next sibling parent Jack Applegame <japplegame gmail.com> writes:
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 <digitalmars-d puremagic.com> 
 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. :)
Dec 22 2016
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
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 <digitalmars-d puremagic.com> 
 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.
Dec 28 2016
prev sibling parent reply Brad Anderson <eco gnuk.net> writes:
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.
Dec 21 2016
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Dec 21, 2016 at 06:33:52PM +0000, 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
Dec 21 2016
prev sibling next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
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
Dec 21 2016
prev sibling parent reply hardreset <invalid email.address> writes:
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.
Dec 21 2016
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Dec 21 2016
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
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.
Dec 21 2016
parent reply Jerry <hurricane hereiam.com> writes:
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.
Dec 21 2016
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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?
Dec 21 2016
parent reply Jerry <hurricane hereiam.com> writes:
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.
Dec 21 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Dec 21 2016
next sibling parent reply safety0ff <safety0ff.dev gmail.com> writes:
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
Dec 21 2016
parent reply Jerry <hurricane hereiam.com> writes:
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.
Dec 21 2016
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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 ?
Dec 21 2016
parent reply Jerry <hurricane hereiam.com> writes:
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)
{
}
Dec 21 2016
parent Stefan Koch <uplink.coder googlemail.com> writes:
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.
Dec 21 2016
prev sibling parent safety0ff <safety0ff.dev gmail.com> writes:
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
Dec 21 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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
Dec 23 2016
prev sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
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...
Dec 21 2016
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Dec 21 2016
parent deadalnix <deadalnix gmail.com> writes:
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.
Dec 21 2016
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Dec 21 2016
next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
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.
Dec 21 2016
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 21 Dec 2016 08:18:48 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:


 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 =20


=20
 An engineer from Debian wrote down what's needed on the distribution=20
 side to give a green light to the D language:
=20
 https://gist.github.com/ximion/fe6264481319dd94c8308b1ea4e8207a
=20
=20
 Andrei
=20


"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.


=46rom 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.
Dec 21 2016
next sibling parent Seb <seb wilzba.ch> writes:
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
Dec 21 2016
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Dec 21 2016
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 <SeeWebsiteForEmail erdani.org>:

 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
Dec 21 2016
prev sibling parent qznc <qznc web.de> writes:
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 <SeeWebsiteForEmail erdani.org>:


 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.
Dec 22 2016
prev sibling next sibling parent reply ixid <adamsibson gmail.com> writes:
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?
Dec 21 2016
parent reply Madaz Hill <mhmhmh mhmh.mh> writes:
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) !
Dec 21 2016
parent Jacob Carlborg <doob me.com> writes:
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
Dec 21 2016
prev sibling next sibling parent reply Gerald <gerald.b.nunn gmail.com> writes:
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
Dec 21 2016
next sibling parent bachmeier <no spam.net> writes:
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.
Dec 21 2016
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Wed, 21 Dec 2016 15:46:19 +0000
schrieb Gerald <gerald.b.nunn gmail.com>:


 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
Dec 21 2016
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Dec 21 2016
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2016-12-21 at 15:49 -0800, Jonathan M Davis via Digitalmars-d
wrote:

 [=E2=80=A6]
=20
 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?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 23 2016
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Dec 23 2016
next sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
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.
Dec 23 2016
parent Matthias Klumpp <mak debian.org> writes:
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
Dec 23 2016
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via Digitalmars-d
wrote:

 [=E2=80=A6]
=20
 Except dmd's backend is far more well proven then LLVM is.


Come now that is obfuscation =E2=80=93 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.
=20

 So that argument needs to be tweaked a little bit.


No it doesn't, it stands as stated.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 23 2016
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Fri, 23 Dec 2016 18:29:15 +0000, 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.
Dec 23 2016
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 23 December 2016 at 22:41:28 UTC, Chris Wright wrote:

 On Fri, 23 Dec 2016 18:29:15 +0000, 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.
Dec 23 2016
prev sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
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.
Dec 23 2016
prev sibling parent deadalnix <deadalnix gmail.com> writes:
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.
Dec 28 2016
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
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.
Dec 22 2016
parent reply Matthias Klumpp <mak debian.org> writes:
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?
Dec 22 2016
parent Kagamin <spam here.lot> writes:
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.
Dec 23 2016
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Dec 23 2016
parent Chris Wright <dhasenan gmail.com> writes:
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.
Dec 23 2016