On Mon, 20 Jul 2015 02:11:49 -0700, Walter Bright wrote:

> On 7/20/2015 1:40 AM, Kagamin wrote:
>> On Monday, 20 July 2015 at 04:35:30 UTC, Walter Bright wrote:
>>> But I view the backend license encumbrance as more of a theoretical issue than a practical one - the license is extremely permissive. There isn't that much more to it than agreeing to not sue Symantec.
>>
>> Redistribution is explicitly disallowed though (i.e. one can't fork it on github without individual permission).
> 
> Yeah, well, I've never denied anyone permission, and the only point of that is they have to agree not to sue Symantec.

but still, the backend license is what blocks including DMD in some GNU/ Linux distros repositories, 'cause "The Software is copyrighted and comes with a single user license, and may not be redistributed."

this effectively blocks all non-source-based distros from redistributing DMD as distro package (both in compiled and in source forms).

i.e. blocks any distros that doesn't "git clone" as the part of package installing process.

On Tue, 21 Jul 2015 01:54:44 -0700, Walter Bright wrote:

> On 7/20/2015 11:34 PM, Martin Nowak wrote:
>> I got this number from Daniel, he didn't found a reason.
>> Chances are it's uniformly slower because of dmd's backend, but of
>> course profiling might help.
> 
> Consider that the Win32 version of dmd is built with with the same backend as dmd. If there's a slowdown with that version, it isn't due to the backend.

DMC version of DMD is noticably slower on building phobos than MinGW version. i'm using HEAD built with MinGW with wine, and the difference can be noticed with my eyes. i didn't measure that with "time", though.

so backend is surely plays a role here.

On Wed, 22 Jul 2015 12:17:21 +0000, Martin Nowak wrote:

> - The backend generates pretty bad code, we'll never be able to catch up with good optimizers. Why should we invest in an outdated backend?

the one reason is that it's small and doesn't require 3rd-party libraries to build. while it's not the best backend out here, change-compile-full- rebuild cycle is very fast for DMD, and doesn't require to install gcc sources or llvm.

yet i'm not sure that this reason will outweigh the translation and maintenance burden.

On Mon, 20 Jul 2015 21:49:00 +0000, Martin Nowak wrote:

> We have a PR from Kenji, that fixes 313+314. https://github.com/D-Programming-Language/dmd/pull/3407
> 
> It's a major change of the import system, so it needs a thorough review and we also need to mitigate the code breakage impact of this change.

at least for phobos, it breaks almost nothing. and where it does some breckage, it identifies invalid code that relies on import bugs anyway.

the same with some projects i tried to build, like deadcode, for example (which is fairly big): this PR breaks only invalid code, i.e. code that relies on current buggy import and should be fixed anyway.

yet, there is surprisingly small amount of such code, literally along 10 or so patches for phobos (and that number constantly decreases), and not much more for deadcode (but for deadcode the fixes was a little more complicated, as i have to add some qualifiers in some modules).

i'm using DMD with that patch incorporated for more a year now, and got no problems with code that doesn't rely on import bugs.