V Thu, 11 Sep 2014 12:26:59 +0300
ketmar via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:

> good luck telling users that thay has to have D compiler to build D compiler. and good luck persuading GNU/Linux programmers that they need binary blob to compile D compiler. it's deadend -- at least for GNU/Linux, in which i'm interested.

What? I don't see any problem with binary blob. With gcc it is same I need binary blob to be able to compile gcc from source. And if I am really scary of binary dmd compiler I can still use last C++ version and compile it with gcc, then use this product to compile next ddmd and so on.

On Thu, 11 Sep 2014 09:43:19 +0000
Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> If it is easy you are welcome to implement it and provide patches.
in no way. i'm already told that it will not happen in DMD, and i myself have no needs in such translator. besides, i'm little busy with gdc right now.

but it's not that hard. my estimation is 3 or 4 weeks max (or ~1.5 weeks for dedicated full-time developer). note that translator is necessary to translating parts of the compiler, so it can be targeted at specific code, just like magicport.

On Thu, 11 Sep 2014 11:54:08 +0200
Daniel Kozak via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> What? I don't see any problem with binary blob. With gcc it is same I need binary blob to be able to compile gcc from source. And if I am really scary of binary dmd compiler I can still use last C++ version and compile it with gcc, then use this product to compile next ddmd and so on.
as i said -- good luck with it. D is not GCC (yet?), and GDC is not a part of GCC. it's very naive to assume that FOSS programmer that wants to try D will take last C++ version, then compiles it, than compiles next D version and so on. he will take either gdc from distro repo (and this will be old, if not ancient) just to find that it has no shiny new features the programmer just read about in NG, or will try to build HEAD and... and drop D, 'cause "if they make it so hard to build their compiler, they can play with it without me".

inability to be built with GCC out-of-the-box pushing D into marginality. and inability to use new shiny compiler features 'cause compiler should be buildable with previous versions too. and this will effectively kill language progress: "we will not change this, 'cause it's breaking change and old compilers will not be able to build new ones".

lose-lose-lose. being self-hosting is cool, but it will turn D into C++
(by spirit).

On Thursday, 11 September 2014 at 10:13:17 UTC, ketmar via Digitalmars-d wrote:
> On Thu, 11 Sep 2014 11:54:08 +0200
> Daniel Kozak via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> What? I don't see any problem with binary blob. With gcc it is same I
>> need binary blob to be able to compile gcc from source. And if I am
>> really scary of binary dmd compiler I can still use last C++ version
>> and compile it with gcc, then use this product to compile next ddmd
>> and so on.
> as i said -- good luck with it. D is not GCC (yet?), and GDC is not a
> part of GCC. it's very naive to assume that FOSS programmer that wants
> to try D will take last C++ version, then compiles it, than compiles
> next D version and so on. he will take either gdc from distro repo (and
> this will be old, if not ancient) just to find that it has no shiny new
> features the programmer just read about in NG, or will try to build
> HEAD and... and drop D, 'cause "if they make it so hard to build their
> compiler, they can play with it without me".

As a package maintainer I have no problem with chained building of the compiler. Will take quite some time when its needed but nothing critical.

There is a known issue that gcc release model is badly compatible with one of DMD frontend (which causes certain headache with gdc package maintenance) but it only means that gdc won't be recommended for casual ddmd hacking and ldc will prevail for this specific case. Don't see it as a big deal if building with gdc still remains possible for maintainers.

On Thu, 11 Sep 2014 10:35:09 +0000
Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> As a package maintainer I have no problem with chained building of the compiler. Will take quite some time when its needed but nothing critical.
some people like to experiment with bleeding edge versions. incidentally, those are people who are most willing to contribute, either sporadically ("hey, i found a bug in your HEAD! ;-)") or by becoming dedicated developers. but if they neeed to do that, and that, and then compile that, and that, and... just to play with something, they will drop it and switch to another toy with lighter entry barriers. or start using prepackaged versions and stop fixing bugs: "ah, it's an old version, and i don't want to rebuild it anyway, so... let's wait unitl that fixed, and use ugly hackarounds for now".

one of the best features of D (somebody sees that as a weakness, but i
believe that this is killer feature) is it's changing nature. there are
alot of idiotic legacy in C++, and nobody can fix that -- due to C++ is
"designed by committee" now and due to alot of legacy code that will
break. pushing changes to D is hard, but *way* easier than to C++. and
having easily-buildable compiler that needs only system C++
compiler to be built encourages people to experiment.

DMD is great for experiments: it builds very fast, it's small, it's self-contained and requires only C++ toolchain. yet it has proprietary codegen, so it can't be put in repositories of free software. and if DMD will become self-hosted, people will need to install *another* D compiler just to build DMD. this will turn off many potential contributors and volunteer evangelists. and DMD is proprietary in the eyes of FOSS-dedicated people, so many of them will not agree to use prebuilt DMD binaries to rebuild DMD too.

sure, this is not a big deal for windows and macos people, but it's the big deal for GNU/Linux developers. not D users, but potential developers of D itself. it's moderately acceptably to use compiler with proprietary codegen if it comes with full source code and can be built with system-provided toolchain, but it's not OK to depend of binary blobs to build it.

please note that i'm not talking about people who just using D to writing their code, but about people who found D fun and want to contribute. i myself dreaming of times when GDC will get more developers to keep it in sync with HEAD frontend, so i can write my patches against GDC and then porting 'em to DMD, not vice versa.

With regard to the whole self-hosting thing, perhaps it is worth copying the way Rust handles this:

https://github.com/rust-lang/rust/wiki/Note-compiler-snapshots

So in order to build one would usually download a binary compiler and use it to bootstrap, but in theory one can take the last version of the compiler before it became self-hosting, and build all the way to the current version (but it would take a long time).

On Thursday, 11 September 2014 at 10:02:39 UTC, ketmar via
Digitalmars-d wrote:
> On Thu, 11 Sep 2014 09:43:19 +0000
> Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> If it is easy you are welcome to implement it and provide patches.
> in no way. i'm already told that it will not happen in DMD, and i
> myself have no needs in such translator. besides, i'm little busy with
> gdc right now.
>
> but it's not that hard. my estimation is 3 or 4 weeks max (or ~1.5
> weeks for dedicated full-time developer). note that translator is
> necessary to translating parts of the compiler, so it can be
> targeted at specific code, just like magicport.

So you are asking someone to do something you have no need of,
just because you think it's a good idea ? Daniel already poured
countless hours in DDMD, and you seem to underestimate his
investment, and the number of bugs he uncovered / fixed.

That being said, I see no issue for newcomer:
- If you want to play with D, download a compiler;
- If you really want bleeding edge, download a compiler then
build master with it;
- If you can't stand building a compiler with a downloaded
binary, that's not the community problem.

However, I haven't seen any post about how LDC and GDC will react
to this change. Will that influence the 1-frontend-late "rule" we
currently have, or require a lot of work on the glue layer ?

> "Thiez"  wrote in message news:ywwfdsfqlxqcdchptota@forum.dlang.org...
> With regard to the whole self-hosting thing, perhaps it is worth copying the way Rust handles this:
>
> https://github.com/rust-lang/rust/wiki/Note-compiler-snapshots
>
> So in order to build one would usually download a binary compiler and use it to bootstrap, but in theory one can take the last version of the compiler before it became self-hosting, and build all the way to the current version (but it would take a long time).

And that's how it will work with ddmd.  Binaries will be available in the form of releases with at least the most recent one being able to compile master.  Exactly how many releases we maintain compatibility for is yet to be decided.

You can always pull the last C++ version from git and use that to step all the way up to the latest ddmd, if you feel it's important to waste lots of your time that way. 

On Thu, 11 Sep 2014 13:00:37 +0000
Mathias LANG via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> So you are asking someone to do something you have no need of, just because you think it's a good idea ?
no, i don't want to work for trashcan. i have enough things to do for fun. and it's clearly written: "The DDMD project is nearly complete, and this is not going to happen as a part of it."

so thank you, find another trashcan-filler.

> that's not the community problem
i got it. "we need contributors, but that's not the community problem!" where's my money than? no money, and "not the community problem"? ok, working on D is not fun anymore.

"Iain Buclaw via Digitalmars-d" <digitalmars-d@puremagic.com> wrote in message news:mailman.722.1410407468.5783.digitalmars-d@puremagic.com...

> For GDC (and distributions that ship GDC), that would extend to 3 or 4 versions,
> as gcc releases are a round about, or just over yearly.

I can live with yearly, although I wouldn't mind if GDC released more often.