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

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)
{
}

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.

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.

? 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!

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. :)

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.

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?

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.

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 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.winder@ekiga.net 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