On 6 March 2013 09:28, John Colvin <john.loughran.colvin@gmail.com> wrote:

> On Wednesday, 6 March 2013 at 03:19:23 UTC, Jonathan M Davis wrote:
>
>> On Wednesday, March 06, 2013 02:44:07 Rob T wrote:
>>
>>> On Wednesday, 6 March 2013 at 00:25:30 UTC, Adam Wilson wrote: [...]
>>>
>>> > My preference would be to completely replace the back-end > with
>>> > LLVM. Why LLVM? Well as opposed to GCC it was designed from > the
>>> > ground up to support many languages. The benefit here is that
>>> > it is possible to create standalone compiler the generates > LLVM
>>> > bytecode that can then be run through LLVM. My understanding
>>> > (and I am happy to be corrected here) is that LLVM does not
>>> > need the front-end to be compiled into the back-end.
>>>
>>> That seems like the most obvious direction to take. Is there any valid reason not to?
>>>
>>
>> Because LDC already does that, there are potential legal issues with
>> Walter
>> working on other backends, and it's completely unnecessary. It's a shame
>> that
>> the stance of debian and some other distros makes it so that dmd can't be
>> on
>> them, but both gdc and ldc already exist and are both completely FOSS. The
>> picky distros can just stick with those, and if anyone using them really
>> wants
>> the reference compiler, they can just install it themselves.
>>
>> I agree that it sucks that dmd's backend is not fully open source, but the
>> code is available to read and provide fixes for, and no code compiled by
>> it is
>> affected by the license. All it really affects is whether it can go on
>> some
>> Linux distros, and given that we have two other perfectly good compilers
>> which
>> _can_ go on such distros, I don't think that it's at all worth worrying
>> about
>> dmd's license. There are much, much more important things to worry about
>> (like
>> bug fixing).
>>
>> - Jonathan M Davis
>>
>
> Is it realistic to consider making the frontend completely portable across backends?
>
> I'm imagining a situation where there is no gdc/ldc frontend, just glue to the backend. The advantages seem significant.
>


This is not new.  Though people seem to only just be speculating the idea in the NG, the truth is that this has started to happen around 2 months ago.  However this is a slow process that will take time.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

A big problem is that GDC and LDC in the distros are not up to date. GDC was 2.058 I think. This has forced me to use dmd even for my final code (I don't want to get in the trouble of building them by source, this is ancient).

On Mar 6, 2013 12:51 PM, "Minas Mina" <minas_mina1990@hotmail.co.uk> wrote:
>
> A big problem is that GDC and LDC in the distros are not up to date. GDC
was 2.058 I think. This has forced me to use dmd even for my final code (I don't want to get in the trouble of building them by source, this is ancient).

One of the benefits of the merger would be that this would be a part non-issue anymore, as all distros will (or should) ship gdc.

However what won't happen is frontend updates following a release of gdc. So eg: one release will come with 2.062 frontend, and 10 months later the next release will come with 2.068, or whatever happens to be the current at the time.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Mar 6, 2013 1:18 PM, "Iain Buclaw" <ibuclaw@ubuntu.com> wrote:
>
> On Mar 6, 2013 12:51 PM, "Minas Mina" <minas_mina1990@hotmail.co.uk>
wrote:
> >
> > A big problem is that GDC and LDC in the distros are not up to date.
GDC was 2.058 I think. This has forced me to use dmd even for my final code (I don't want to get in the trouble of building them by source, this is ancient).
>
> One of the benefits of the merger would be that this would be a part
non-issue anymore, as all distros will (or should) ship gdc.
>
> However what won't happen is frontend updates following a release of gdc.
So eg: one release will come with 2.062 frontend, and 10 months later the next release will come with 2.068, or whatever happens to be the current at the time.
>

This also might be a time to re-address the minor release scheme that has been discussed in the past (eg: 2.062.1, 2.062.2, etc).   Rather than focus on maintaining a tree for each release of the D frontend implementation, we pick a common release that gdc/ldc is shipped with, and pull in bug fixes from main development and later releases.  When the shipped versions of gdc/ldc get updated, we then start the process over from that new common release (again, eg: 2.068) and start maintaining minor releases for that (2.068.1, etc).

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Wednesday, 6 March 2013 at 00:25:30 UTC, Adam Wilson wrote:
> My preference would be to completely replace the back-end with LLVM. Why LLVM? Well as opposed to GCC it was designed from the ground up to support many languages.

I heard, llvm was written for C and x86. C++, exceptions and ARM pushed it beyond its limits and created a lot of kludge and redesigns.

On Thursday, 7 March 2013 at 14:55:18 UTC, Kagamin wrote:
> On Wednesday, 6 March 2013 at 00:25:30 UTC, Adam Wilson wrote:
>> My preference would be to completely replace the back-end with LLVM. Why LLVM? Well as opposed to GCC it was designed from the ground up to support many languages.
>
> I heard, llvm was written for C and x86. C++, exceptions and ARM pushed it beyond its limits and created a lot of kludge and redesigns.

And so what ? LLVM is more awesome with each version and is clearly evolving much faster than other compiler. That is a clear success story.

On Wednesday, 6 March 2013 at 03:19:23 UTC, Jonathan M Davis wrote:
> It's a shame that
> the stance of debian and some other distros makes it so that dmd can't be on
> them, but both gdc and ldc already exist and are both completely FOSS. The
> picky distros can just stick with those, and if anyone using them really wants
> the reference compiler, they can just install it themselves.

According to distrowatch Ubuntu and Mint are more popular than Debian, and Ubuntu allows proprietary software like Opera browser and Nvidia drivers, so dmd won't be a problem too. Why Debian policies should be an issue?

On Wednesday, 6 March 2013 at 02:26:43 UTC, Chris Cain wrote:
> There's a few problems with LLVM. Specifically, the last I heard,
> it doesn't do exceptions very well on Windows (maybe not at
> all?). However, some of the expertise from this community could
> be leveraged to provide patches to LLVM to support this better.
> This probably wouldn't be that big of a deal and it would also
> help out everyone using LLVM currently.

clang supports dwarf exceptions in 32-bit. 32-bit SEH is not planned for patent issues. 64-bit SEH is under development.

On 2013-03-07 15:55, Kagamin wrote:

> I heard, llvm was written for C and x86. C++, exceptions and ARM pushed
> it beyond its limits and created a lot of kludge and redesigns.

Apple is betting everything on Clang/LLVM and they really need ARM for iOS. They have basically given up on GCC. Last time GCC got update was with Xcode 3.2.6, latest Xcode is 4.6, according to this:

http://en.wikipedia.org/wiki/Xcode#Toolchain_Versions

-- 
/Jacob Carlborg

On 03/07/2013 01:03 PM, Kagamin wrote:
>
> According to distrowatch Ubuntu and Mint are more popular than Debian,
> and Ubuntu allows proprietary software like Opera browser and Nvidia
> drivers, so dmd won't be a problem too. Why Debian policies should be an
> issue?

Both Ubuntu and Mint are based off of Debian, so if you get on Debian you get on those and many Debian-based others as well. Besides that, Debian is more popular with hardcore developer types that will help push adoption. And finally, while I think it's a shame that the reference compiler is proprietary, Debian has a non-free repository that DMD can be placed on as long as the binaries are redistributable.