On Thursday, 20 February 2020 at 03:35:13 UTC, jxel wrote:

> one expects these things to change. What seems like common sense means nothing to someone stubborn and blinded by pride.

There are historical reasons why Optlink is still around and they have nothing to do with stubbornness or pride. Please make your points without going ad hominem.

On Thursday, 20 February 2020 at 05:54:13 UTC, Mike Parker wrote:
> On Thursday, 20 February 2020 at 03:35:13 UTC, jxel wrote:
>
>> one expects these things to change. What seems like common sense means nothing to someone stubborn and blinded by pride.
>
> There are historical reasons why Optlink is still around and they have nothing to do with stubbornness or pride. Please make your points without going ad hominem.

That's not true _anymore_. Walter has rejected any kind of PR that would introduce sane defaults in a modern world outright (which is what people commonly understand as stubbornness).

"Funnily" we changed the defaults for dub (one can't build anything with optlink, no vibe.d, no phobos etc. anyhow) more than a year ago and people are fine with dub using LLD (like LDC) and thus being able to have more than 32k symbols in their entire program, getting a 64-bit binary by default and not being linked with an ancient, full of well-known and decade-old bugs custom-brew Digitalmars libc.

On Thursday, 20 February 2020 at 03:35:13 UTC, jxel wrote:
> On Thursday, 20 February 2020 at 01:54:45 UTC, H. S. Teoh wrote:
>> On Thu, Feb 20, 2020 at 01:11:08AM +0000, NaN via Digitalmars-d wrote:
>>> On Wednesday, 19 February 2020 at 19:36:38 UTC, bachmeier wrote:
>> [...]
>>> > What does "dropping DMD" mean? Are you going to go around breaking kneecaps if you catch someone working on DMD? It's an open source project and people who want to work on it are going to work on it.
>>> 
>>> I assume "dropping DMD" just means making LDC the main reference compiler instead of DMD.
>>> 
>>> It's not about forcing anyone to do anything, it's about perception, for example new users will almost always start with the official compiler. So you start to build more user base around LDC, and over time, if the d core team is focused in that direction, most people will follow suit.
>> [...]
>>
>> Good luck getting Walter to agree to abandoning DMD and working on LDC instead.
>>
>>
>> T
>
> No body expect him to. Just how the official DMD isn't built with LDC, why there isn't a 64 bit version of DMD on Windows, why Optlink is still even a thing, why restrictions are placed in DMD to workaround an Optlink bug instead of fixing it. No one expects these things to change. What seems like common sense means nothing to someone stubborn and blinded by pride.

People often don't see how much effort is wasted on maintaining multiple compilers, but how much time i.e.
- the release process (especially with stable releases)
- keeping CIs up, configured and running
- actively triaging bugs
- having multiple test suite solutions
- maintaining automations (e.g. dlang-bot)

consumes is hidden to non-insiders. Furthermore,

- supporting every new feature in each backend (ask Ian or kinke about the recent multiple inner pointer change)
- maintaining multiple installers
- nasty DMD backend bugs (a few people apart from Walter actually do try to fix things in the backend)
- working around obscure infra problems (IIRC Digitalmars libc still isn't thread-safe and people have run in all kinds of problems with it and needed to come up with ingenious solutions, even DMD's build.d shows signs of this)
- working with Digitalmars Make
- maintaining a modern set of features per compiler (address sanitization, ...)
- keeping other compilers up-to-date with upstream (every release introduces regressions)
- maintaining support for every OS for every compiler (e.g.FreeBSD)
- having an n-times bigger surface for bugs
...

And I haven't even mentioned the bottleneck of any major DMD PR needing to be approved by Walter.

In my opinion DMD is only the default because switching development efforts to LDC would be a rather big initial cost (time investment) to setup/change the infrastructure and no one wants to head this effort.

> if the d core team is focused in that direction, most people will follow suit.

I would switch in a heartbeat and I am fairly confident to estimate that the same applies to almost all remaining active contributors who haven't left yet because of frustration.

On 2/19/20 7:29 PM, jxel wrote:
> On Wednesday, 19 February 2020 at 07:27:39 UTC, drug wrote:
>> On 2/18/20 11:00 PM, jxel wrote:
>>>>> IMO you are wrong if you think that dropping dmd will increase man power in ldc/gdc land.
>>>
>>> Who said that? That's your misinterpretation.
>>
>> Experience says that again and again. If someone contributes to project A why he should start contributing to project B if project A would be completed? He can easily start contributing to project C, D etc. You have no warranty at all.
> 
> Like I said, that's your misinterpretation, read the first paragraph.

Well, I responded to your "The problem is that efforts are divided as a result" statement. But probably I misinterpreted indeed.

On 2/20/20 9:34 AM, Seb wrote:
>
> snipped
> 

The reason you listed above get a hot response in my soul. That maintenance things are really annoying. As for me they really are the reasons to change the thing order. Probably we can start from making a new separate repository for the frontend? It seems to me that then things will fall into place themselves.
But I'm afraid of gdc in case we switch on ldc. Gdc is important thing.

On Thursday, 20 February 2020 at 00:52:02 UTC, Walter Bright wrote:

>> 
>> Anything with a 'switch':
>> 
>> void foo() {
>>      switch(true) {
>>          default:
>>      }
>> }
>
> That's true, it's also true for loops. Though trivial functions with switches seem to me to be rare.

We encountered a case recently where we wanted to inline one. It was trivial to work around, though.

>
> Keep in mind that the inliner is part of the dmd front end, not the back end. The inliner would be more effective if it was part of the back end, but that comes with a major memory/time penalty (intermediate code would have to be generated for all functions, even ones not being compiled, and kept around in memory).

Yes, I know about that. People are often willing to pay the cost for highly optimized builds.

On 2/20/2020 2:08 AM, Max Samukha wrote:
> We encountered a case recently where we wanted to inline one. It was trivial to work around, though.

I'm interested in evaluating common cases that don't inline but should.

On 2/19/2020 10:34 PM, Seb wrote:
> And I haven't even mentioned the bottleneck of any major DMD PR needing to be approved by Walter.

Given the current regression list:

https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=230215&query_format=advanced

I'm probably being too permissive. I'm usually the one who gets to fix them. I asked in this forum for some help isolating which PRs caused the regressions, to no avail.

Major PRs *should* be regarded with skepticism. For example, I recently fixed a regression caused by a 2 or 3 hundred line PR, where the substance of the PR was one line and the rest of it was refactoring.

Folks, with PRs, smaller, tightly focused PRs are better. Do not:

1. lump multiple issues into one PR

2. include your favorite refactorings in with it

3. refactors must not change observable behavior

Do:

1. minimize the PR even if the result of the PR suggests a refactoring

2. do that refactor SEPARATELY AFTER THE PR WAS MERGED

On 2/19/2020 8:40 PM, rikki cattermole wrote:
> On 20/02/2020 4:35 PM, jxel wrote:
>> Optlink is still even a thing
> 
> Which is going the way of the dodo soon enough.
> 
> The alternative needs to mature in production for a while before we swap.

32 bit Windows code is becoming irrelevant, and optlink is only for 32 bit Windows. If you have more than 32,000 symbols in the executable, I wonder why you're building a 32 bit executable.

On Thursday, 20 February 2020 at 00:52:02 UTC, Walter Bright wrote:
> On 2/18/2020 10:10 PM, Max Samukha wrote:
>> On Wednesday, 19 February 2020 at 05:42:19 UTC, Walter Bright wrote:
>> 
>>> so it is inlining both forms. If you do have trivial functions that aren't being inlined, please let me know. Thanks!
>> 
>> Anything with a 'switch':
>> 
>> void foo() {
>>      switch(true) {
>>          default:
>>      }
>> }
>
> That's true, it's also true for loops. Though trivial functions with switches seem to me to be rare.
>
> Keep in mind that the inliner is part of the dmd front end, not the back end. The inliner would be more effective if it was part of the back end, but that comes with a major memory/time penalty (intermediate code would have to be generated for all functions, even ones not being compiled, and kept around in memory).

Would moving the inliner to the back end still slow down the compile times even when inlining is turned off?