On 1/31/14, 7:16 AM, Andrej Mitrovic wrote:
> On 1/31/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> * Ask the community for help NOT on a large matter.
>
> The way I see it both the GDC and LDC projects suffer from a difficult
> barrier to entry for anyone new to the compilers. For example, to
> build either of the compilers you need to go through a massive list of
> things that you have to do **manually**:
>
> http://wiki.dlang.org/GDC/Installation/Generic
> http://wiki.dlang.org/Building_LDC_from_source
>
> And those are Posix instructions. Windows instructions are typically
> out of date, randomly break, have never been tested, missing crucial
> info, etc etc. It's always a nightmare to build the damn thing.
>
> Why aren't there simple scripts that can auto-build the compilers from
> start to finish, including fetching the dependencies?
[snip]

This is very interesting observation, and an obvious area of improvement. Andrej, could you please file two issues under bugzilla with the respective tags ldc and gdc? I'll see if I can place bounties on them.


Andrei

On 1/31/14, Craig Dillabaugh <cdillaba@cg.scs.carleton.ca> wrote:
> I am going to hazard a guess that you are not an Arch Linux fan

I like configurability, a lot, but when I want to contribute to something I may not be interested in all the interesting choices I'm forced to make beforehand. I just want to get from point A to point Z.

I like to think there should be a sensible default to software configuration, which I can *later* configure to my liking.

On 1/31/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Andrej, could you please file two issues under bugzilla
> with the respective tags ldc and gdc? I'll see if I can place bounties
> on them.

That's a great idea! Here we go:

https://d.puremagic.com/issues/show_bug.cgi?id=12048 https://d.puremagic.com/issues/show_bug.cgi?id=12049

On Friday, 31 January 2014 at 17:28:41 UTC, Andrej Mitrovic wrote:
> On 1/31/14, Craig Dillabaugh <cdillaba@cg.scs.carleton.ca> wrote:
>> I am going to hazard a guess that you are not an Arch Linux fan
>
> I like configurability, a lot, but when I want to contribute to
> something I may not be interested in all the interesting choices I'm
> forced to make beforehand. I just want to get from point A to point Z.
>
> I like to think there should be a sensible default to software
> configuration, which I can *later* configure to my liking.

I think he may have meant that as Arch Linux has gdc package
available, such simple script exists - it is a package build
script which is publicly available. But it is for 4.8 gcc branch
so does not really help much :(

On 1/31/14, Dicebot <public@dicebot.lv> wrote:
> I think he may have meant that as Arch Linux has gdc package available, such simple script exists - it is a package build script which is publicly available. But it is for 4.8 gcc branch so does not really help much :(

Right, I need something to build the source with after I modify the source. Git-head, and all that. Prebuilt binaries are of no use. :)

On Friday, 31 January 2014 at 19:43:22 UTC, Andrej Mitrovic wrote:
> On 1/31/14, Dicebot <public@dicebot.lv> wrote:
>> I think he may have meant that as Arch Linux has gdc package
>> available, such simple script exists - it is a package build
>> script which is publicly available. But it is for 4.8 gcc branch
>> so does not really help much :(
>
> Right, I need something to build the source with after I modify the
> source. Git-head, and all that. Prebuilt binaries are of no use. :)

Sadly, it was the former.  Based on all the rave reviews on the "Best Linux" thread I tried to install Arch on a VirtualBox VM yesterday.  I spent 2.5 hours carefully reading (and following I believed) the installation instructions, only to end up with an unbootable VM.  It wasn't wasted time though really, because I learned some new things that I never would have picked up with a graphical install. However, I could see that someone who didn't want to learn the installation details would have gone crazy.

After that I installed Mint on another VM, in about 5 minutes. It booted with no troubles.

On 1/31/14, Craig Dillabaugh <craig.dillabaugh@gmail.com> wrote:
> After that I installed Mint on another VM, in about 5 minutes. It booted with no troubles.

This is getting OT, but Manjaro worked for me, which is Arch Based. Unlike Arch it has a GUI installer which is really simple to use, and it installed in a few minutes. D-related packages seem to work and they show up in the package manager even though Manjaro apparently uses its own packaging system (P.S. most D projects seem to be packaged by Dicebot).

On 31 January 2014 01:39, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 1/30/14 4:13 AM, Iain Buclaw wrote:
>>
>> Hi all,
>>
>> On March 22, 2014, GDC will turn 10! \o/
>>
>> This is a great landmark achievement in brevity for GDC, but we still haven't achieved in my personal opinion any levity of worthy note.  So much to the point I'm beginning to give doubt myself as to how long things can continue with a bus-factor of me.
>
>
> Congratulations!
>
>
>> Lets talk history.
>>
>> In late 2010, Digital Mars raised awareness with the FSF to start the process of merging GDC into GCC.  Nothing then happened until a year later when the copyright assignment/disclaimers had been completed by most parties.
>>
>> More silenced followed for a further year until the first set of patches were ready for submission, and over the year that followed resolving implementation issues, most were spent waiting for GCC development to re-open for feature pulls.  Now a further year has gone by with that merge window open and shut and we are once again two releases away from seeing any possible inclusion.
>
>
> Sucks to be an evangelist, eh? :o) The thing is, most of the people in this forum are blissfully unaware of GNU's process, milestones, and deadlines. I know it's unpleasant to do so, but one thing to do would be to overcommunicate. There's a lot to be said about reminding people, time and again, about an impending deadline and what they can do to help. Messages in with titles like the samples below would make a world of difference:
>
> [GDC] Four pulls up for review, aiming at GNU acceptance in three months
> [GDC] Help needed: front-end pull, blocks GNU acceptance in two months
> [GDC] URGENT: three weeks to GNU deadline, please review!
> etc.
>
> This kind of work is as important as the technical work you're doing (actually more important right now). It is true that more people would see others get the work done and they just download the GNU suite with GDC in it. But there's plenty of evidence there are many collaborators who are eager to help and simply don't have any information on what exactly which rocks to lift and where to take them. You need to be the guy coordinating that, and once per decade is not enough :o).
>
>



>> On top of this, to this day I am yet to hear that the assignment papers have been completed by the original author, which would be a major blocker in itself.
>
>
> Who's that guy and what code did he write? If no response, let's redo his work. We should not be afraid of it.
>

David Friedman, I'm in direct contact with him and give both him and Donald (the FSF assignments clerk) a nudge over the issue once every couple of months.  Whilst David has no problem, he is in the unfortunate position of having his IP owned by a company.  And at last check, they were still dealing with clauses in the assignment.

As for the codebase, I can say that around 60% has been potentially re-written since I picked it up in 2008/2009.


>
>> Alarm bells should be ringing, but at times there seems to be an indifference from the core community on the matter, as if letting a valued D compiler coming up to 10 years of age go awry because of a lack of TLC is O.K.
>
>
> (TLC = tender loving care?)
>
> An increasing number of people depend on GDC for getting work done. Including a couple of projects here at Facebook. Yet the simple reality is that even if I summoned TODAY one of our engineers with "get on helping gdc full time", that engineer would have absolutely no idea where to start.
>

The same could be said with DMD.  I'd never expect someone to pick up a 20k codebase in a week, but one can do it in small steps.  In my opinion, the best way to get stuck into GDC is to do a couple of frontend merges (2.064 -> 2.065 -> future).


>> Before this comes to sound like a death note, please be rest assured that my continued contribution shall remain, but some form of serious support really is needed to speed up process and development if we are even going to achieve any target we have set our sights on.
>>
>> Lets discuss what we can positively do about the situation and start working together to a pillar goal in D's continued success.  Unless the more proactive thing to do would just be to walk in-front of that morning or afternoon bus instead of board it. :)
>
>
> Absolutely! And your note is a great breaker of the thundering silence around working together to get gdc where it belongs.
>
> That being a large endeavor, there's one time-honored way to address it: divide it into smaller steps. So here are a few thoughts:
>
> * Use this forum for EVERYTHING related to gdc, EXCLUSIVELY. Prefix everything with [gdc] so nobody will complain about being spammed.
>
> * Keep people posted about ALL upcoming milestones and deadlines of the relevant gnu process.
>
> * Find the SMALLEST indivisible step that would help push gdc toward integration, file it under bugzilla, and tag it with "gdc". Repeat this many times.
>
> * Ask the community for help NOT on a large matter. Ask for help for EACH SMALL STEP that a competent person can get on to. I bet many in this community read your anniversary message and were like, "wow, tricky..." and back to browsing. I take it https://github.com/D-Programming-Language/dmd/pull/2200 and https://github.com/D-Programming-Language/dmd/pull/2194 are two important ones, is that correct?
>

Differences between gdc and dmd in the frontend implement are important.

GCC has a strict backend and will ICE at any opportunity it can find. As GDC has been well tailored to this over the years to produce correct code for GCC.  Things like this in GCC can flag up any big problems in the frontend quite easily.  Regardless of whether or not DMD compiles it without a hitch.

Having arbitrary changes to the frontend means that not just anyone can pick up the latest version of D and slot it in.  Internal knowledge of what changes are present in that patch, and why in my head after months of study and testing.  It makes merges more difficult, setting aside changes in the frontend have a hidden knock-on effect in the glue.

> I'll do my best on my side to help with very concrete bits, i.e. put bounties on important issues or have legal contact people for signatures. But I need to know!
>

If you can get me in touch with your guy, I could do with a hand in having a third party look over my own code reviews, which doesn't require any previous knowledge of gdc.

http://gcc.gnu.org/codingconventions.html

On Friday, 31 January 2014 at 19:43:22 UTC, Andrej Mitrovic wrote:
> Right, I need something to build the source with after I modify the
> source. Git-head, and all that. Prebuilt binaries are of no use. :)

No, I did not mean to _use_ prebuilt binaries. For any Arch Linux (and thus Manjaro) package there is a matching entry in SVN repository with build script. For example, for GDC it is here: https://projects.archlinux.org/svntogit/community.git/tree/trunk?h=packages/gdc

There is also AUR package for gcc 4.9 - https://aur.archlinux.org/packages/gd/gdc-git/PKGBUILD , maintained by Moritz Maxeiner

At any time you can just download those, make any changes you need and run `makepkg`. Or just use build() function from PKGBUILD as a base for your own build script.

On 1/31/14, Dicebot <public@dicebot.lv> wrote:
> At any time you can just download those, make any changes you need and run `makepkg`. Or just use build() function from PKGBUILD as a base for your own build script.

This is great, I could start hacking on GDC then. Perfect, thanks!