May 09, 2012
On 10/05/12 01:49, Adam D. Ruppe wrote:
> How did you install it? That's the stumbling block for me.

In my case, the easy way: it's available as a package in Ubuntu. :-)

Ubuntu 12.04 has GDC 4.6.3 in its repositories, 11.10 had 4.6.1 if I remember correctly.

I haven't yet tried building it from source, but may do so at some point in the future.
May 10, 2012
On Thu, May 10, 2012 at 01:33:39AM +0200, Adam D. Ruppe wrote:
> On Wednesday, 9 May 2012 at 23:31:26 UTC, H. S. Teoh wrote:
> >Right, so what's the reason behind not adopting gdc or ldc as the reference compiler?
> 
> Have you actually used them? I've tried and never got far.
> 
> dmd just works.

I use gdc regularly without a hitch. The only catch is that it's always a bit behind dmd, so it doesn't always work with the latest git druntime/phobos. So for bleeding-edge D code I still have to resort to dmd.


T

-- 
Talk is cheap. Whining is actually free. -- Lars Wirzenius
May 10, 2012
On Thu, May 10, 2012 at 01:47:27AM +0200, Joseph Rushton Wakeling wrote:
> On 10/05/12 01:33, Adam D. Ruppe wrote:
> >Have you actually used them? I've tried and never got
> >far.
> 
> Yes, but that's because right now they are playing perpetual catch-up with DMD.  With the frontend stabilized, it'll be a different situation.
> 
> GDC works extremely well for me in general, and also produces significantly faster executables than DMD.

Yeah, gcc's backend has much more advanced optimizations that dmd.  I've actually looked at the assembly code output for different D snippets, and often find that gdc's output has just several instructions where dmd would output half a page of instructions (or an entire function together with the entire call/return sequence).

Plus the gcc backend automatically gives you access to a whole slew of target architectures that dmd would never have the manpower to support.


T

-- 
English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicests of all possible ways. -- Larry Wall
May 10, 2012
On Thu, May 10, 2012 at 01:59:27AM +0200, Joseph Rushton Wakeling wrote:
> On 10/05/12 01:49, Adam D. Ruppe wrote:
> >How did you install it? That's the stumbling block for me.
> 
> In my case, the easy way: it's available as a package in Ubuntu. :-)
[...]

Yeah, I use Debian, and apt-get install gdc-4.6 does everything necessary to setup gdc in working condition. Gotta love apt. :-)


T

-- 
2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
May 10, 2012
On Thu, 10 May 2012, Joseph Rushton Wakeling wrote:

> On 10/05/12 01:43, Brad Roberts wrote:
> > If you're using ldc or gdc, you should develop agains the gdc/ldc provided druntime and phobos too.
> 
> No, that's a recipe for fragmentation.  Phobos should be developed in consort with the DMD frontend.  The problem is that DMD frontend updates take time to percolate across to GDC/LDC.

You're reading something other than what I said.  Develop against doesn't imply leave it forked.
May 10, 2012
On Thursday, 10 May 2012 at 00:28:43 UTC, Brad Roberts wrote:
> On Thu, 10 May 2012, Joseph Rushton Wakeling wrote:
>
>> On 10/05/12 01:43, Brad Roberts wrote:
>> > If you're using ldc or gdc, you should develop agains the gdc/ldc provided
>> > druntime and phobos too.
>> 
>> No, that's a recipe for fragmentation.  Phobos should be developed in consort
>> with the DMD frontend.  The problem is that DMD frontend updates take time to
>> percolate across to GDC/LDC.
>
> You're reading something other than what I said.  Develop against doesn't
> imply leave it forked.

But it implies additional maintenance: merge the upstream druntime/phobos, make sure your custom patches (if any) still works, delay in security and bug fix, additional support for the community if the version shipped with GDC and/or is too old.
May 10, 2012
On Wednesday, May 09, 2012 16:32:34 H. S. Teoh wrote:
> On Wed, May 09, 2012 at 07:16:22PM -0400, Jonathan M Davis wrote:
> > On Wednesday, May 09, 2012 16:04:14 H. S. Teoh wrote:
> > > Dumb question: what prevents someone from rewriting dmd's backend with new code that isn't entangled by the previous license?
> > 
> > It's a _ton_ of work for arguably little benefit. What we have for dmd works just fine, and if you want a fully open source backend, you can use gdc or ldc.
> 
> [...]
> 
> Right, so what's the reason behind not adopting gdc or ldc as the reference compiler?

If nothing else, because Walter would be unable to work on it. He avoids looking at the source for any other compilers, because doing so could cause him legal issues when working on dmd/dmc's backend, which he does professionally. And given that Walter has worked on the backend for over 20 years, I can't imagine that he's going to be all that excited at the prospect of throwing it away in favor of another one.

Once the front-end has stabilized (and it's getting there), it should become a non-issue, because then even if gdc and ldc are a version or two behind, it won't affect anywhere near as much (it will also likely become easier at that point for the gdc and ldc devs to keep them up-to-date).

- Jonathan M Davis
May 10, 2012
On Thursday, May 10, 2012 01:08:34 Joseph Rushton Wakeling wrote:
> On 10/05/12 00:53, Jonathan M Davis wrote:
> > But since that will never happen, it's a moot issue. It doesn't really matter if we would have had 10 times as many people contributing (which I very much doubt), Walter can't change the backend's license, so we're stuck with how things are. There's really no point in arguing about how it affects us (be it positively or negatively), since we can't do anything about it.
> > 
> > But gdc and ldc _do_ exist, so for the really picky people, there are
> > fully
> > FOSS options. And as the front-end stabilizes, which backend you use
> > should
> > matter less and less, so it should become less and less of an issue.
> 
> I don't understand why the project couldn't (or wouldn't) simply bless GDC or LDC as the reference implementation. I do see why in the short term, as finalizing/stabilizing the front end, runtime and development library are much higher-priority goals, but in the longer term it seems like a viable possibility.
> 
> It also seems beneficial to do so given that GDC and LDC offer much better possibilities for supporting architectures beyond x86/x86-64.

Walter works on dmd's backend for a living. He's been working on it for over 20 years. I don't think that he's going to be very interested in using another backend.

Also, he _can't_ use another backend (unless he creates a new one from scratch), because looking the code for another backend could cause legal issues for him when he works on dmd/dmc's backend for his actual job.

There may be other major reasons as well, but those alone would make it so that Walter isn't going to want to switch. Certainly, if it were something that Walter really thought was a good idea, I expect that he would have done so by now.

- Jonathan M Davis
May 10, 2012
On 5/9/12 3:51 PM, Jonathan M Davis wrote:
> Yeah. The lack of open sourceness for the backend is pretty much complete FUD.

The problem is, the damage is there and is real. It's like in those crazy situations - an allegation of harassment still affects a teacher's career, even if there's a simple explanation. The only answer to "is it open source?" can be an unqualified "yes".

I wish we could get rid of this crappy backend situation.


Andrei

May 10, 2012
On Wed, May 09, 2012 at 10:15:23PM -0500, Andrei Alexandrescu wrote:
> On 5/9/12 3:51 PM, Jonathan M Davis wrote:
> >Yeah. The lack of open sourceness for the backend is pretty much complete FUD.
> 
> The problem is, the damage is there and is real. It's like in those crazy situations - an allegation of harassment still affects a teacher's career, even if there's a simple explanation. The only answer to "is it open source?" can be an unqualified "yes".

Yeah, it may be FUD, but it still causes damage. Simply declaring it FUD does not magically repair the damage.


> I wish we could get rid of this crappy backend situation.
[...]

How, though? Clearly, given what is said about Walter's situation, it appears that he can't look at (much less work on) another backend without legal implications and other issues. And asking someone to throw away 20 years of work (rewrite the backend) is asking a bit too much.


T

-- 
English has the lovely word "defenestrate", meaning "to execute by throwing someone out a window", or more recently "to remove Windows from a computer and replace it with something useful". :-) -- John Cowan