<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 9 August 2015 at 11:07, Johannes Pfau via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am Sun, 9 Aug 2015 00:32:00 -0700<br>
schrieb Walter Bright <<a href="mailto:newshound2@digitalmars.com">newshound2@digitalmars.com</a>>:<br>
<div><div class="h5"><br>
> On 8/8/2015 11:36 PM, Tofu Ninja wrote:<br>
> > On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:<br>
> >> dmd not being deprecated continues the cycle of gdc/ldc lagging<br>
> >> versions behind and being understaffed in manpower.<br>
> ><br>
> > I think another point to look at is how far gdc and ldc have come<br>
> > while still having so few people working on them. Clearly they are<br>
> > able to get more done faster because they can leverage the work of<br>
> > the llvm and gcc devs. Seems silly that the majority of our talent<br>
> > is focused on dmd when it is the slowest of the bunch. D's "not<br>
> > made here" syndrome strikes again!<br>
><br>
> There's pretty much no talent focused on the dmd back end. I do most<br>
> of the (very) occasional bug fixes, and sometimes Martin or Daniel<br>
> correct something, and that's about it.<br>
><br>
> The idea that it is sucking up resources is incorrect.<br>
><br>
<br>
</div></div>The DMD devs aren't working on the backend, but the GDC and LDC are<br>
neither ;-) He's talking about the glue layer.<br>
<br>
DMD has the advantage that whenever a frontend pull request requires<br>
glue layer changes you get at and once by the contributor. But for<br>
LDC and GDC the glue layer changes have to be implemented by GDC/LDC<br>
devs.<br>
</blockquote></div><br></div><div class="gmail_extra">I think that is more of a problem with length of development + number of contributors/changes.<br><br></div><div class="gmail_extra">For instance, when it was just Walter committing changes, the number of "fixed" bugs was of a reasonable number such that I could have gone through them all and tested them within a day (this is back when the D2 testsuite was private and I had no way other way to track whether or not codegen changes were required).<br><br></div><div class="gmail_extra">Now we have the testsuite, which seems to be a good enough gauge for finding problems.  However if there's been a change (eg: refactor) between what codegen is lowered in the frontend vs. glue, then it becomes a commit hunt trawling through thousands of changes to work out which one is relevant to the new wrong-code-on-previously-working test.  One day turns into a week, turns into a month, turns into half a year.<br><br></div><div class="gmail_extra">Iain.<br></div></div>