On 20 October 2015 at 20:44, Vladimir Panteleev via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Monday, 19 October 2015 at 21:24:00 UTC, Iain Buclaw wrote:
>
>> In order:
>> You are responsible, the library maintainers (I chip in a bit on the side
>> when I have the hardware / virtual environment).
>> You are responsible, the authors and reviewers of the testsuite and
>> unittests.
>>
>
> Who is this "You", specifically?
>
> If I run into a bug with GDC on a specific platform/architecture, who am I supposed to talk to? With DMD/Phobos bugs I can at least use "git blame".
>
> Also, are you saying that it is every Phobos/Druntime contributor's responsibility to make sure that their changes are GDC-compatible? Other than the Travis auto-tester which seems to be failing half the time, we don't have any CI or any tests at all for GDC!
>
>

What can I say?  We have a lot of faith in our porters. :-)


You can talk to me if you run into any problems, because I'm certainly more *aware* of porting and portability than most other druntime and compiler maintainers.  However you submit to upstream.

On Tuesday, 20 October 2015 at 20:02:26 UTC, Iain Buclaw wrote:
> What can I say?  We have a lot of faith in our porters. :-)
>
>
> You can talk to me if you run into any problems, because I'm certainly more *aware* of porting and portability than most other druntime and compiler maintainers.  However you submit to upstream.

Okay :) Then I'd like to ask you to please check http://dlang.org/download.html and http://wiki.dlang.org/Compilers and make sure everything is correct. If something is not up-to-date on the wiki, please fix it, as the wiki page is linked to from the former dlang.org page. In particular, as discussed in this thread, information about mobile platforms is missing.

Am Tue, 20 Oct 2015 22:02:17 +0200
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 20 October 2015 at 20:44, Vladimir Panteleev via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
> 
> > On Monday, 19 October 2015 at 21:24:00 UTC, Iain Buclaw wrote:
> > 
> >> In order:
> >> You are responsible, the library maintainers (I chip in a bit on
> >> the side when I have the hardware / virtual environment).
> >> You are responsible, the authors and reviewers of the testsuite and
> >> unittests.
> >> 
> >
> > Who is this "You", specifically?
> >
> > If I run into a bug with GDC on a specific platform/architecture, who am I supposed to talk to? With DMD/Phobos bugs I can at least use "git blame".
> >
> > Also, are you saying that it is every Phobos/Druntime contributor's responsibility to make sure that their changes are GDC-compatible? Other than the Travis auto-tester which seems to be failing half the time, we don't have any CI or any tests at all for GDC!
> >
> > 
> 
> What can I say?  We have a lot of faith in our porters. :-)
> 
> 
> You can talk to me if you run into any problems, because I'm certainly more *aware* of porting and portability than most other druntime and compiler maintainers.  However you submit to upstream.
> 

To further explain this: Our GDC policy is to not accept changes into
druntime or phobos which have not been constributed in druntime /
phobos upstream (D-Programming-Language) first.
Having too many local changes in the GDC version makes merging new
versions much more complicated (and also means the GDC team has to
maintain that code), so we obviously like to avoid that.

There are some compiler specific things in druntime: Basically everything in gcc.* Changes to these modules will need to go to GDC repositories directly. AFAIR we also have not committed GCC inline ASM to druntime upstream as it's not useful for DMD.

However, most changes required when porting are definitions to C-interfacing headers, maybe some minimal GC changes and Fiber support (now in threadasm.S) and all these changes need to go to upstream druntime/phobos.

Another problem when porting is the testsuite. It actually contains quite some inline ASM. It's usually very simple inline ASM so it's easy to port but the ASM code is scattered over quite some files. I think we also didn't upstream these changes.

It might make sense to reconsider upstreaming our inline ASM code. I think the main reason we didn't do that yet was that the druntime developers think of druntime as a compiler specific library anyway. And then there's no use in having GDC specific ASM in a DMD specific druntime.

On Wednesday, 21 October 2015 at 08:06:34 UTC, Johannes Pfau wrote:
> It might make sense to reconsider upstreaming our inline ASM code. I think the main reason we didn't do that yet was that the druntime developers think of druntime as a compiler specific library anyway. And then there's no use in having GDC specific ASM in a DMD specific druntime.

Even if gdc-specific stuff doesn't go into druntime, I would think that it would make sense to update druntime where appropriate to segregate the stuff that's compiler-specific so that it's easy for the gdc and ldc teams to replace the parts that they need to replace. That being said, I would think that using version blocks to separate compiler-specific stuff would have been appropriate and that ideally the gdc and ldc teams wouldn't have their own versions of druntime or Phobos, but even then, modularizing that stuff is likely to be more maintainable than having it scattered throughout the code.

- Jonathan M Davis

On 21 October 2015 at 10:26, Jonathan M Davis via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Wednesday, 21 October 2015 at 08:06:34 UTC, Johannes Pfau wrote:
>
>> It might make sense to reconsider upstreaming our inline ASM code. I think the main reason we didn't do that yet was that the druntime developers think of druntime as a compiler specific library anyway. And then there's no use in having GDC specific ASM in a DMD specific druntime.
>>
>
> Even if gdc-specific stuff doesn't go into druntime, I would think that it would make sense to update druntime where appropriate to segregate the stuff that's compiler-specific so that it's easy for the gdc and ldc teams to replace the parts that they need to replace. That being said, I would think that using version blocks to separate compiler-specific stuff would have been appropriate and that ideally the gdc and ldc teams wouldn't have their own versions of druntime or Phobos, but even then, modularizing that stuff is likely to be more maintainable than having it scattered throughout the code.
>
> - Jonathan M Davis
>


In a way, druntime has three parts to it.

core.stdc:  Exposes enough platform bindings to interact with system C
library.
core, gc: D runtime library.  Everything should be compiler agnostic within
reason.
rt: Per-compiler runtime internals.  EH, Vector operations, Runtime calls,
etc...

The first two are the concern of upstream to maintain.

The thread topic has wandered so far from "Code of Conduct" that nobody will ever find this current discussion. Perhaps start a new thread?

On Wednesday, 21 October 2015 at 18:38:34 UTC, Walter Bright wrote:
> The thread topic has wandered so far from "Code of Conduct" that nobody will ever find this current discussion. Perhaps start a new thread?

LOL. Yeah. That's a pretty epic change of topic; it's not even _close_ to the original anymore.

- Jonathan M Davis

On 21 October 2015 at 20:36, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> The thread topic has wandered so far from "Code of Conduct" that nobody will ever find this current discussion. Perhaps start a new thread?
>

If only we had a Code of Conduct for derailing threads!

On Wednesday, 21 October 2015 at 18:56:25 UTC, Jonathan M Davis wrote:
> LOL. Yeah. That's a pretty epic change of topic; it's not even _close_ to the original anymore.

How about this D Code of Conduct: do the stuff.

Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> writes:

> On 10/18/15 7:55 AM, Joakim wrote:
>> Now, the download page has not traditionally listed alphas and betas. But the importance of mobile is so high that I think it is worth it to do so, with the appropriate cautions about alpha quality.
>
> Yes, very much so. Please make that happen. Thanks! -- Andrei

I think it makes sense to add a link to the LDC iOS releases in http://wiki.dlang.org/Compilers.  Perhaps a row for iOS in table "Package and/or binary availability, by platform and compiler".

I am not sure it belongs on http://dlang.org/download.html though until somebody besides me has reported success using D in an iOS App.

How should I proceed?
-- 
Dan