Re: Red Hat's issues in considering the D language

[deadalnix via Digitalmars-d]

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.

Re: Red Hat's issues in considering the D language

[Dejan Lekic via Digitalmars-d]

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

[rikki cattermole via Digitalmars-d]

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

[Nicholas Wilson via Digitalmars-d]

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

[Chris Wright via Digitalmars-d]

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

[Chris Wright via Digitalmars-d]

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

[Russel Winder via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Kagamin via Digitalmars-d]

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

[Jonathan M Davis via Digitalmars-d]

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

[Matthias Klumpp via Digitalmars-d]

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

[Ilya Yaroshenko via Digitalmars-d]

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

[rikki cattermole via Digitalmars-d]

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

[Russel Winder via Digitalmars-d]

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

[Russel Winder via Digitalmars-d]

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

[qznc via Digitalmars-d]

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

[Matthias Klumpp via Digitalmars-d]

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

[Kagamin via Digitalmars-d]

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

[Jack Applegame via Digitalmars-d]

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

[Daniel Kozák via Digitalmars-d]

? 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

[deadalnix via Digitalmars-d]

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

[Stefan Koch via Digitalmars-d]

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

[Jerry via Digitalmars-d]

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

[safety0ff via Digitalmars-d]

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

[Stefan Koch via Digitalmars-d]

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

[Jerry via Digitalmars-d]

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

[safety0ff via Digitalmars-d]

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

[Jonathan M Davis via Digitalmars-d]

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

[Andrei Alexandrescu via Digitalmars-d]

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

[hardreset via Digitalmars-d]

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

[Jonathan M Davis via Digitalmars-d]

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

[Jonathan M Davis via Digitalmars-d]

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

[Jerry via Digitalmars-d]

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

[Jonathan M Davis via Digitalmars-d]

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

[Yuxuan Shui via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d]

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

[Jerry via Digitalmars-d]

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

[Andrei Alexandrescu via Digitalmars-d]

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

[Ilya Yaroshenko via Digitalmars-d]

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

[H. S. Teoh via Digitalmars-d]

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

[Brad Anderson via Digitalmars-d]

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

[Seb via Digitalmars-d]

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

[Johannes Pfau via Digitalmars-d]

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

[Johannes Pfau via Digitalmars-d]

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

[Dejan Lekic via Digitalmars-d]

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

[Jesse Phillips via Digitalmars-d]

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

[hardreset via Digitalmars-d]

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

[Andrei Alexandrescu via Digitalmars-d]

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

[hardreset via Digitalmars-d]

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

[bachmeier via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d]

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

[bachmeier via Digitalmars-d]

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

[Gerald via Digitalmars-d]

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=GNOME-Potential-Rust

Re: Red Hat's issues in considering the D language

[Jacob Carlborg via Digitalmars-d]

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

[Madaz Hill via Digitalmars-d]

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

[Ilya Yaroshenko via Digitalmars-d]

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

[ixid via Digitalmars-d]

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

[Andrei Alexandrescu via Digitalmars-d]

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

[hardreset via Digitalmars-d]

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

[Gary Willoughby via Digitalmars-d]

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

[Jacob Carlborg via Digitalmars-d]

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

[deadalnix via Digitalmars-d]

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

[Guillaume Piolat via Digitalmars-d]

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

Red Hat's issues in considering the D language

[Andrei Alexandrescu via Digitalmars-d]

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