www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] LLVM Community Code of Conduct

reply Daniel Kozak <kozzi11 gmail.com> writes:
lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

Maybe we could have something similar in D community
Oct 13 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/13/2015 6:36 AM, Daniel Kozak wrote:

 lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

 Maybe we could have something similar in D community


No. People who need to be told what decent behavior is won't pay 
attention to such a document.
Oct 13 2015
next sibling parent Chris <wendlec tcd.ie> writes:
On Tuesday, 13 October 2015 at 19:13:07 UTC, Walter Bright wrote:

 On 10/13/2015 6:36 AM, Daniel Kozak wrote:

 lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

 Maybe we could have something similar in D community


 No. People who need to be told what decent behavior is won't 
 pay attention to such a document.


:-)
Oct 13 2015
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, 13 October 2015 at 19:13:07 UTC, Walter Bright wrote:

 On 10/13/2015 6:36 AM, Daniel Kozak wrote:

 lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

 Maybe we could have something similar in D community


 No. People who need to be told what decent behavior is won't 
 pay attention to such a document.


I was considering saying that we shouldn't add one unless the 
need presents itself, and for the most part, our community has 
been well-behaved, but your response is spot-on. About the only 
reason that I can think of why we might really benefit from such 
a document would be if we did have a problem, and we needed a way 
to fairly justify kicking people out of the newsgroup or from 
other official D channels, then we'd have a set of rules to point 
to that the person had violated rather than it just being the 
say-so of someone in charge. But fortunately, we haven't 
generally had problems like that. Occasionally, we've had a bad 
apple show up and cause problems, but none have stayed around 
long term, and things are normally pretty civil around here.

- Jonathan M Davis
Oct 13 2015
prev sibling next sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Tuesday, 13 October 2015 at 19:13:07 UTC, Walter Bright wrote:

 On 10/13/2015 6:36 AM, Daniel Kozak wrote:

 lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

 Maybe we could have something similar in D community


 No. People who need to be told what decent behavior is won't 
 pay attention to such a document.


Yes, I such such codes of conduct not as a solution to, but and 
indication of a problem.
Oct 14 2015
parent Chris <wendlec tcd.ie> writes:
On Wednesday, 14 October 2015 at 09:50:31 UTC, Marc Schütz wrote:

 On Tuesday, 13 October 2015 at 19:13:07 UTC, Walter Bright 
 wrote:

 On 10/13/2015 6:36 AM, Daniel Kozak wrote:

 lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

 Maybe we could have something similar in D community


 No. People who need to be told what decent behavior is won't 
 pay attention to such a document.


 Yes, I such such codes of conduct not as a solution to, but and 
 indication of a problem.


It is inevitable that even in a nice and respectful community 
there are misunderstandings based on the lack of body language 
and audible tone of voice (e.g. in the case of irony, tongue in 
cheek remarks etc.). Not to mention the fact that different 
people and cultures have a different understanding of what's 
appropriate|insulting|disrespectful and what isn't.

A code of conduct might do more harm than good, when people keep 
pointing to it saying "Look ma, he said XYZ to me! Ban him!". I 
once was on a forum like that and it soon became unbearable with 
people taking offense at every answer they got and complaining to 
the admin of the forum demanding this or that user be banned. It 
eats up a lot of the admin's time too, you know, toys, pram, 
kindergarten.
Oct 14 2015
prev sibling next sibling parent reply logicchains <jonathan.t.barnard gmail.com> writes:
On Tuesday, 13 October 2015 at 19:13:07 UTC, Walter Bright wrote:

 On 10/13/2015 6:36 AM, Daniel Kozak wrote:

 lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

 Maybe we could have something similar in D community


 No. People who need to be told what decent behavior is won't 
 pay attention to such a document.


This is the most compelling reason I've yet seen to use D over 
Rust or Go.
Oct 14 2015
parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 14 October 2015 at 13:21:28 UTC, logicchains wrote:

 On Tuesday, 13 October 2015 at 19:13:07 UTC, Walter Bright 
 wrote:

 On 10/13/2015 6:36 AM, Daniel Kozak wrote:

 lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

 Maybe we could have something similar in D community


 No. People who need to be told what decent behavior is won't 
 pay attention to such a document.


 This is the most compelling reason I've yet seen to use D over 
 Rust or Go.


Wow, damning with faint praise, why is this so important?  I 
agree with Walter, but surely you see something else to like more 
about D? :)
Oct 14 2015
parent reply logicchains <jonathan.t.barnard gmail.com> writes:
On Wednesday, 14 October 2015 at 16:07:01 UTC, Joakim wrote:

 On Wednesday, 14 October 2015 at 13:21:28 UTC, logicchains 
 wrote:

 On Tuesday, 13 October 2015 at 19:13:07 UTC, Walter Bright 
 wrote:

 On 10/13/2015 6:36 AM, Daniel Kozak wrote:

 lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

 Maybe we could have something similar in D community


 No. People who need to be told what decent behavior is won't 
 pay attention to such a document.


 This is the most compelling reason I've yet seen to use D over 
 Rust or Go.


 Wow, damning with faint praise, why is this so important?  I 
 agree with Walter, but surely you see something else to like 
 more about D? :)


I didn't mean it as damning with faint praise, I'm just 
personally really unfond of Django-style COCs (and I'm not the 
only one, given by the response on the Go mailing list to their 
COC's introduction).

Since you asked, D's compile time metaprogramming facilities are 
in my view the best thing about D. I think though that D's 
marketing lacks sufficient focus on that. As someone who's been 
paid to write Go but not D, I think the Go's biggest advantage in 
capturing developer mindshare is aesthetic; it's simple to grasp 
and subjectively "neat" in some sense. D on the other hand seems 
perpetually unfinished; ref counting isn't finished, gc-free 
exceptions aren't finished, "shared" isn't finished, safe/ref 
isn't finished (at least I recall reading somewhere on this list 
that there are still some bugs in the implementation that allow 
memory-unsafe behaviour), integrating Vibe.D's co-routines isn't 
(as far as I'm aware) finished, improving the GC isn't finished, 
typecons.Unique isn't finished. Even if it's not entirely 
logical, all these unfinished aspects can add up to produce a 
less positive aesthetic impression of the language compared to a 
language that comes across as more polished.

Plus, Go has a much simpler pitch: looks kinda like Python but is 
faster (due to being compiled if nothing else) and doesn't screw 
up parallelism. There are/were a lot of Python devs using Python 
where it probably wasn't appropriate (such as where I work), so 
it's an easy niche to fill.
Oct 14 2015
parent reply Kagamin <spam here.lot> writes:
On Thursday, 15 October 2015 at 06:36:32 UTC, logicchains wrote:

 Even if it's not entirely logical, all these unfinished aspects 
 can add up to produce a less positive aesthetic impression of 
 the language compared to a language that comes across as more 
 polished.


If go is finished, why there's activity in its repository?
Oct 15 2015
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 15 October 2015 at 08:11:20 UTC, Kagamin wrote:

 On Thursday, 15 October 2015 at 06:36:32 UTC, logicchains wrote:

 Even if it's not entirely logical, all these unfinished 
 aspects can add up to produce a less positive aesthetic 
 impression of the language compared to a language that comes 
 across as more polished.


 If go is finished, why there's activity in its repository?


I agree with logicchains. The impression people have is exactly 
this. Go = neat and tidy, D = mess. This has nothing to do with 
whether Go is actually finished and tidy or not. Go also appeals 
to people, because it is highly prescriptive and leaves no room 
for doubt "You do it like this, because we think it's the best 
way to do it! Full stop." Weird, but this appeals to people.
Oct 15 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 15 October 2015 at 09:09:22 UTC, Chris wrote:

 I agree with logicchains. The impression people have is exactly 
 this. Go = neat and tidy, D = mess. This has nothing to do with 
 whether Go is actually finished and tidy or not.


The core Go language specification is finished, implemented and 
fully supported on Google App Engine, just like Java and Python. 
That is a strong signal for Go being production ready.

The fact that they continue optimizing the runtime and backend is 
another matter.
Oct 16 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Thursday, 15 October 2015 at 09:09:22 UTC, Chris wrote:

 I agree with logicchains. The impression people have is exactly 
 this. Go = neat and tidy, D = mess.


Do people have the same impression from generic code in Go?
Oct 16 2015
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 16 October 2015 at 08:29:18 UTC, Kagamin wrote:

 On Thursday, 15 October 2015 at 09:09:22 UTC, Chris wrote:

 I agree with logicchains. The impression people have is 
 exactly this. Go = neat and tidy, D = mess.


 Do people have the same impression from generic code in Go?


It doesn't matter. It _feels_ neat, tidy and finished. We're not 
talking about engineering, we're talking about subjective human 
impressions.

Apart from that, I think the fact that D is still not fit for 
mobile platforms is a huge drawback. Loads of people want apps, 
loads of people have some sort of smart phone, tablet or 
whatever. Sometimes I think that we're getting sucked in by the 
quick sand of language specs, pointers, GC etc. while important 
issues like targeting mobile platforms are second class citizens. 
Nim for example targeted mobile platforms right from the start. 
So did Go. I cannot recommend D wholeheartedly unless it also 
works on ARM at the click of a button. Please correct me if I'm 
wrong here, but mobile is not yet 100%.
Oct 16 2015
next sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 16 October 2015 at 10:25:07 UTC, Chris wrote:

 Please correct me if I'm wrong here, but mobile is not yet 100%.


Ah, that? But lack of support is not a mess, it's a clear, neat 
and tidy lack of 100% support for ARM.
Oct 16 2015
parent Chris <wendlec tcd.ie> writes:
On Friday, 16 October 2015 at 12:01:07 UTC, Kagamin wrote:

 On Friday, 16 October 2015 at 10:25:07 UTC, Chris wrote:

 Please correct me if I'm wrong here, but mobile is not yet 
 100%.


 Ah, that? But lack of support is not a mess, it's a clear, neat 
 and tidy lack of 100% support for ARM.


I didn't say that the lack of ARM support was a mess. I said it 
was a huge drawback that puts people off (and understandably so, 
if you wanna go mobile).

Again, I'm talking about the _impression_ people get from D, 
which has nothing to do with the facts. Go is wearing suit and 
tie, so people trust it, for better or for worse. Sad but true.
Oct 16 2015
prev sibling next sibling parent reply Laeeth Isharc <Laeeth.nospam nospam-laeeth.com> writes:
On Friday, 16 October 2015 at 10:25:07 UTC, Chris wrote:

 On Friday, 16 October 2015 at 08:29:18 UTC, Kagamin wrote:

 On Thursday, 15 October 2015 at 09:09:22 UTC, Chris wrote:

 I agree with logicchains. The impression people have is 
 exactly this. Go = neat and tidy, D = mess.


 Do people have the same impression from generic code in Go?


 It doesn't matter. It _feels_ neat, tidy and finished. We're 
 not talking about engineering, we're talking about subjective 
 human impressions.

 Apart from that, I think the fact that D is still not fit for 
 mobile platforms is a huge drawback. Loads of people want apps, 
 loads of people have some sort of smart phone, tablet or 
 whatever. Sometimes I think that we're getting sucked in by the 
 quick sand of language specs, pointers, GC etc. while important 
 issues like targeting mobile platforms are second class 
 citizens. Nim for example targeted mobile platforms right from 
 the start. So did Go. I cannot recommend D wholeheartedly 
 unless it also works on ARM at the click of a button. Please 
 correct me if I'm wrong here, but mobile is not yet 100%.


Fwiw I think it's okay on ARM linux.  I have compiled and run 
small programs on my phone (a oneplusone).  Thanks to dicebot you 
can just install with yaourt.  That's not what you meant of 
course, and Android ARM seems a little further away.  But in case 
anyone else sees this and doesn't bother trying.
Oct 16 2015
next sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 16 October 2015 at 14:36:55 UTC, Laeeth Isharc wrote:


 Fwiw I think it's okay on ARM linux.  I have compiled and run 
 small programs on my phone (a oneplusone).  Thanks to dicebot 
 you can just install with yaourt.  That's not what you meant of 
 course, and Android ARM seems a little further away.  But in 
 case anyone else sees this and doesn't bother trying.


Thanks for the information!
Oct 16 2015
prev sibling parent Adrian Matoga <epi atari8.info> writes:
On Friday, 16 October 2015 at 14:36:55 UTC, Laeeth Isharc wrote:

 On Friday, 16 October 2015 at 10:25:07 UTC, Chris wrote:

 On Friday, 16 October 2015 at 08:29:18 UTC, Kagamin wrote:

 On Thursday, 15 October 2015 at 09:09:22 UTC, Chris wrote:

 [...]


 Do people have the same impression from generic code in Go?


 It doesn't matter. It _feels_ neat, tidy and finished. We're 
 not talking about engineering, we're talking about subjective 
 human impressions.

 Apart from that, I think the fact that D is still not fit for 
 mobile platforms is a huge drawback. Loads of people want 
 apps, loads of people have some sort of smart phone, tablet or 
 whatever. Sometimes I think that we're getting sucked in by 
 the quick sand of language specs, pointers, GC etc. while 
 important issues like targeting mobile platforms are second 
 class citizens. Nim for example targeted mobile platforms 
 right from the start. So did Go. I cannot recommend D 
 wholeheartedly unless it also works on ARM at the click of a 
 button. Please correct me if I'm wrong here, but mobile is not 
 yet 100%.


 Fwiw I think it's okay on ARM linux.  I have compiled and run 
 small programs on my phone (a oneplusone).  Thanks to dicebot 
 you can just install with yaourt.  That's not what you meant of 
 course, and Android ARM seems a little further away.  But in 
 case anyone else sees this and doesn't bother trying.


I'm running a vibe.d app on Raspberry Pi without any trouble. 
Even something like 3 years ago I rebuilt some non-trivial app 
(an Atari XE disk drive emulator) with GDC for RPi and it 
compiled and worked fine out of the box.
So it seems it's just mobile OS support that is missing.
Oct 16 2015
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 16 October 2015 at 10:25:07 UTC, Chris wrote:

 Apart from that, I think the fact that D is still not fit for 
 mobile platforms is a huge drawback. Loads of people want apps, 
 loads of people have some sort of smart phone, tablet or 
 whatever. Sometimes I think that we're getting sucked in by the 
 quick sand of language specs, pointers, GC etc. while important 
 issues like targeting mobile platforms are second class 
 citizens. Nim for example targeted mobile platforms right from 
 the start. So did Go. I cannot recommend D wholeheartedly 
 unless it also works on ARM at the click of a button. Please 
 correct me if I'm wrong here, but mobile is not yet 100%.


Ldc binaries for iOS were announced in July, Dan's now working on 
64-bit support:

http://forum.dlang.org/thread/m2mvz57seb.fsf comcast.net

Android is pretty much done, just cleaning it up by integrating 
with ldc's CMake build system and other small details, 
announcement coming next week.
Oct 17 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/17/15 5:37 PM, Joakim wrote:

 On Friday, 16 October 2015 at 10:25:07 UTC, Chris wrote:

 Apart from that, I think the fact that D is still not fit for mobile
 platforms is a huge drawback. Loads of people want apps, loads of
 people have some sort of smart phone, tablet or whatever. Sometimes I
 think that we're getting sucked in by the quick sand of language
 specs, pointers, GC etc. while important issues like targeting mobile
 platforms are second class citizens. Nim for example targeted mobile
 platforms right from the start. So did Go. I cannot recommend D
 wholeheartedly unless it also works on ARM at the click of a button.
 Please correct me if I'm wrong here, but mobile is not yet 100%.


 Ldc binaries for iOS were announced in July, Dan's now working on 64-bit
 support:

 http://forum.dlang.org/thread/m2mvz57seb.fsf comcast.net

 Android is pretty much done, just cleaning it up by integrating with
 ldc's CMake build system and other small details, announcement coming
 next week.


Fantastic!

Could you please send a PR to upgrade http://dlang.org/download.html so 
it lists the iOS and (later) Android downloads? Even I didn't know ldc 
has an iOS download! -- Andrei
Oct 17 2015
parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 17 October 2015 at 16:38:29 UTC, Andrei Alexandrescu 
wrote:

 Fantastic!

 Could you please send a PR to upgrade 
 http://dlang.org/download.html so it lists the iOS and (later) 
 Android downloads? Even I didn't know ldc has an iOS download! 
 -- Andrei


Will do.  Support for both platforms is at the alpha stage, but 
doesn't hurt to get more hands on them, and the fact that pretty 
much all of the druntime and phobos tests pass mean they're in 
reasonably good shape.
Oct 17 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/17/15 7:55 PM, Joakim wrote:

 On Saturday, 17 October 2015 at 16:38:29 UTC, Andrei Alexandrescu wrote:

 Fantastic!

 Could you please send a PR to upgrade http://dlang.org/download.html
 so it lists the iOS and (later) Android downloads? Even I didn't know
 ldc has an iOS download! -- Andrei


 Will do.  Support for both platforms is at the alpha stage, but doesn't
 hurt to get more hands on them, and the fact that pretty much all of the
 druntime and phobos tests pass mean they're in reasonably good shape.


Great - thanks! -- Andrei
Oct 17 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/17/2015 2:03 PM, Andrei Alexandrescu wrote:

 On 10/17/15 7:55 PM, Joakim wrote:

 On Saturday, 17 October 2015 at 16:38:29 UTC, Andrei Alexandrescu wrote:

 Fantastic!

 Could you please send a PR to upgrade http://dlang.org/download.html
 so it lists the iOS and (later) Android downloads? Even I didn't know
 ldc has an iOS download! -- Andrei


 Will do.  Support for both platforms is at the alpha stage, but doesn't
 hurt to get more hands on them, and the fact that pretty much all of the
 druntime and phobos tests pass mean they're in reasonably good shape.


 Great - thanks! -- Andrei


This is all very good news!
Oct 17 2015
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Saturday, 17 October 2015 at 16:55:06 UTC, Joakim wrote:

 On Saturday, 17 October 2015 at 16:38:29 UTC, Andrei 
 Alexandrescu wrote:

 Fantastic!

 Could you please send a PR to upgrade 
 http://dlang.org/download.html so it lists the iOS and (later) 
 Android downloads? Even I didn't know ldc has an iOS download! 
 -- Andrei


 Will do.  Support for both platforms is at the alpha stage, but 
 doesn't hurt to get more hands on them, and the fact that 
 pretty much all of the druntime and phobos tests pass mean 
 they're in reasonably good shape.


I wish the extent of platform support for GDC and LDC was 
clearer. I decided not to list any platforms on D's download page 
unless support for those platforms was rock-solid and is expected 
to work.

At least at that time, iOS and Android support, as I understood 
it, was in the "well, if you download this thing some guy 
uploaded to his personal website and patch that file and don't do 
this thing which doesn't work yet, you might get a "hello world" 
that runs from the terminal if you SSH in" ballpark. I'm not sure 
we should be advertising support for any platform at that level. 
Personally, I feel that if a platform/architecture is listed on a 
language's download page, I should be able to download the 
compiler and build a fully-working application within a few 
minutes, and as I understand we are nowhere close to that yet. I 
don't feel particularly strong about this, but if we do decide to 
lower the bar, then we should reconsider all the other platforms 
that have been left out (such as the long list of GDC 
architectures which I understood Iain to say that, well, since 
the build succeeds and Debian successfully packages it, then it 
has to work. I might be wrong, though, which is my point exactly 
- there is really insufficient information about what exactly one 
can expect to work on each platform/architecture (and their 
combinations).
Oct 17 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/17/2015 2:24 PM, Vladimir Panteleev wrote:

 I wish the extent of platform support for GDC and LDC was clearer. I
 decided not to list any platforms on D's download page unless support
 for those platforms was rock-solid and is expected to work.

 At least at that time, iOS and Android support, as I understood it, was
 in the "well, if you download this thing some guy uploaded to his
 personal website and patch that file and don't do this thing which
 doesn't work yet, you might get a "hello world" that runs from the
 terminal if you SSH in" ballpark. I'm not sure we should be advertising
 support for any platform at that level. Personally, I feel that if a
 platform/architecture is listed on a language's download page, I should
 be able to download the compiler and build a fully-working application
 within a few minutes, and as I understand we are nowhere close to that
 yet. I don't feel particularly strong about this, but if we do decide to
 lower the bar, then we should reconsider all the other platforms that
 have been left out (such as the long list of GDC architectures which I
 understood Iain to say that, well, since the build succeeds and Debian
 successfully packages it, then it has to work. I might be wrong, though,
 which is my point exactly - there is really insufficient information
 about what exactly one can expect to work on each platform/architecture
 (and their combinations).


I think it'll be alright if these are clearly marked as unofficial and 
alpha quality, and perhaps with a blurb with some details on what it's 
state actually is, like "compiles hello world".
Oct 17 2015
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Saturday, 17 October 2015 at 23:42:01 UTC, Walter Bright wrote:

 On 10/17/2015 2:24 PM, Vladimir Panteleev wrote:

 I wish the extent of platform support for GDC and LDC was 
 clearer. I
 decided not to list any platforms on D's download page unless 
 support
 for those platforms was rock-solid and is expected to work.

 At least at that time, iOS and Android support, as I 
 understood it, was
 in the "well, if you download this thing some guy uploaded to 
 his
 personal website and patch that file and don't do this thing 
 which
 doesn't work yet, you might get a "hello world" that runs from 
 the
 terminal if you SSH in" ballpark. I'm not sure we should be 
 advertising
 support for any platform at that level. Personally, I feel 
 that if a
 platform/architecture is listed on a language's download page, 
 I should
 be able to download the compiler and build a fully-working 
 application
 within a few minutes, and as I understand we are nowhere close 
 to that
 yet. I don't feel particularly strong about this, but if we do 
 decide to
 lower the bar, then we should reconsider all the other 
 platforms that
 have been left out (such as the long list of GDC architectures 
 which I
 understood Iain to say that, well, since the build succeeds 
 and Debian
 successfully packages it, then it has to work. I might be 
 wrong, though,
 which is my point exactly - there is really insufficient 
 information
 about what exactly one can expect to work on each 
 platform/architecture
 (and their combinations).


 I think it'll be alright if these are clearly marked as 
 unofficial and alpha quality, and perhaps with a blurb with 
 some details on what it's state actually is, like "compiles 
 hello world".


Should all this really be on the download page, though? There's 
like a score platforms/architectures/combinations of such between 
all compilers combined.

Have you looked at the linked wiki page?

http://wiki.dlang.org/Compilers

I'm not sure we should essentially be copying that table to 
dlang.org.

I think we are good as we are right now. There is an "others" 
link on the download page, so people interested in support for 
less common or less supported platforms can find said information 
on the wiki.
Oct 17 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/18/15 2:57 AM, Vladimir Panteleev wrote:

 I think we are good as we are right now. There is an "others" link on
 the download page, so people interested in support for less common or
 less supported platforms can find said information on the wiki.


Mobile support is huge, and one of the first things people ask about D. 
If ldc supports mobile platforms, that tidbit should be mentioned FRONT 
AND CENTER.

Again: I didn't know it! People ask me about mobile support all the time 
and I'm telling them "not yet".


Andrei
Oct 17 2015
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 18 October 2015 at 04:05:59 UTC, Andrei Alexandrescu 
wrote:

 On 10/18/15 2:57 AM, Vladimir Panteleev wrote:

 I think we are good as we are right now. There is an "others" 
 link on
 the download page, so people interested in support for less 
 common or
 less supported platforms can find said information on the wiki.


 Mobile support is huge, and one of the first things people ask 
 about D. If ldc supports mobile platforms, that tidbit should 
 be mentioned FRONT AND CENTER.

 Again: I didn't know it! People ask me about mobile support all 
 the time and I'm telling them "not yet".


And we're not there yet.

Please correct me if I'm wrong, but as I understand, you'll get 
nowhere on mobile with any current official LDC releases. Saying 
that LDC supports iOS/Android out of the box on dlang.org would 
be false advertising at this point.

I'm not sure what expectations people have when they hear 
"language X supports iOS/Android", but at least as someone who 
hasn't done a lot of mobile development, I'd expect that the 
official compiler can emit code I can call from my app, and get 
it all working in minutes. This would include tutorials of how 
would I compile/link this D code and make it talk to my 
Java/Obj-C/Swift UI code. Again, please correct me if I'm wrong.

Don't get me wrong, I'm as excited about this as anyone, but at 
the same time I don't want people mocking us for claiming support 
when what we have is a proof-of-concept provided by a third-party 
fork.
Oct 17 2015
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 18 October 2015 at 04:13:56 UTC, Vladimir Panteleev 
wrote:

 Don't get me wrong, I'm as excited about this as anyone, but at 
 the same time I don't want people mocking us for claiming 
 support when what we have is a proof-of-concept provided by a 
 third-party fork.


To elaborate on this a bit... the information on the downloads 
page was written only two months ago, with the collaboration of 
both GDC and LDC maintainers:

https://github.com/D-Programming-Language/dlang.org/pull/1067

Now, unless mobile support has matured significantly in the past 
two months, the point here is that the maintainers themselves 
have not pointed out that they were ready to advertise mobile 
support for their compilers on dlang.org. I don't think we should 
change this without their consent, at least. As I understand, 
development for mobile support is still occurring in a fork, and 
this might result users pestering the maintainers regarding code 
that isn't even in the repository they are maintaining.
Oct 17 2015
prev sibling parent rsw0x <anonymous anonymous.com> writes:
On Sunday, 18 October 2015 at 04:05:59 UTC, Andrei Alexandrescu 
wrote:

 On 10/18/15 2:57 AM, Vladimir Panteleev wrote:

 I think we are good as we are right now. There is an "others" 
 link on
 the download page, so people interested in support for less 
 common or
 less supported platforms can find said information on the wiki.


 Mobile support is huge, and one of the first things people ask 
 about D. If ldc supports mobile platforms, that tidbit should 
 be mentioned FRONT AND CENTER.

 Again: I didn't know it! People ask me about mobile support all 
 the time and I'm telling them "not yet".


 Andrei


The mobile support in LDC is at best, shaky.
<insert rant about dmd being the default compiler and LDC/GDC 
being neglected here>
Oct 17 2015
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 17 Oct 2015 11:25 pm, "Vladimir Panteleev via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On Saturday, 17 October 2015 at 16:55:06 UTC, Joakim wrote:

 On Saturday, 17 October 2015 at 16:38:29 UTC, Andrei Alexandrescu wrote:

 Fantastic!

 Could you please send a PR to upgrade http://dlang.org/download.html so






it lists the iOS and (later) Android downloads? Even I didn't know ldc has
an iOS download! -- Andrei

 Will do.  Support for both platforms is at the alpha stage, but doesn't




hurt to get more hands on them, and the fact that pretty much all of the
druntime and phobos tests pass mean they're in reasonably good shape.

 I wish the extent of platform support for GDC and LDC was clearer. I


decided not to list any platforms on D's download page unless support for
those platforms was rock-solid and is expected to work.

 At least at that time, iOS and Android support, as I understood it, was


in the "well, if you download this thing some guy uploaded to his personal
website and patch that file and don't do this thing which doesn't work yet,
you might get a "hello world" that runs from the terminal if you SSH in"
ballpark. I'm not sure we should be advertising support for any platform at
that level. Personally, I feel that if a platform/architecture is listed on
a language's download page, I should be able to download the compiler and
build a fully-working application within a few minutes, and as I understand
we are nowhere close to that yet. I don't feel particularly strong about
this, but if we do decide to lower the bar, then we should reconsider all
the other platforms that have been left out (such as the long list of GDC
architectures which I understood Iain to say that, well, since the build
succeeds and Debian successfully packages it, then it has to work. I might
be wrong, though, which is my point exactly - there is really insufficient
information about what exactly one can expect to work on each
platform/architecture (and their combinations).


Essentially, the reason D has not been ported to X has nothing to do with
lack of compiler support.  A compiler can always be built to target X, and
if that wasn't enough, there are many ready built packages available that
target X.

It is now your job as porters to fix up druntime to allow a library to be
built by these compilers.

Iain.



 Oct 18 2015



  parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Sunday, 18 October 2015 at 07:37:55 UTC, Iain Buclaw wrote:

 Essentially, the reason D has not been ported to X has nothing 
 to do with lack of compiler support.  A compiler can always be 
 built to target X, and if that wasn't enough, there are many 
 ready built packages available that target X.

 It is now your job as porters to fix up druntime to allow a 
 library to be built by these compilers.


That's not very useful. LDC and GDC still include Phobos and 
Druntime.

You're essentially saying that once LDC gets Android/iOS support, 
GDC will automatically get it as well with no effort required 
from you?



 Oct 18 2015



  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 18 Oct 2015 9:45 am, "Vladimir Panteleev via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On Sunday, 18 October 2015 at 07:37:55 UTC, Iain Buclaw wrote:

 Essentially, the reason D has not been ported to X has nothing to do




with lack of compiler support.  A compiler can always be built to target X,
and if that wasn't enough, there are many ready built packages available
that target X.

 It is now your job as porters to fix up druntime to allow a library to




be built by these compilers.

 That's not very useful. LDC and GDC still include Phobos and Druntime.


It is infinitely more useful than having no compiler at all to test porting
changes.


 You're essentially saying that once LDC gets Android/iOS support, GDC


will automatically get it as well with no effort required from you?


In it's runtime? Correct - assuming no one invents any new predefined
version conditions in the process. :-)



 Oct 18 2015



 next sibling parent  Johannes Pfau <nospam example.com>  writes:


Am Sun, 18 Oct 2015 09:55:52 +0200
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 On 18 Oct 2015 9:45 am, "Vladimir Panteleev via Digitalmars-d" <
 digitalmars-d puremagic.com> wrote:

 On Sunday, 18 October 2015 at 07:37:55 UTC, Iain Buclaw wrote:  

 Essentially, the reason D has not been ported to X has nothing to
 do  




 with lack of compiler support.  A compiler can always be built to
 target X, and if that wasn't enough, there are many ready built
 packages available that target X.

 It is now your job as porters to fix up druntime to allow a
 library to  




 be built by these compilers.

 That's not very useful. LDC and GDC still include Phobos and
 Druntime. 


 
 It is infinitely more useful than having no compiler at all to test
 porting changes.
 

 You're essentially saying that once LDC gets Android/iOS support,
 GDC  


 will automatically get it as well with no effort required from you?

  


 
 In it's runtime? Correct - assuming no one invents any new predefined
 version conditions in the process. :-)
 


Generally speaking the nice thing about the GCC backend is that as
frontend developers we don't have to care much about the target
architecture. Porting the compiler to a new architecture is usually
trivial, the only exception being bugs in our frontend which only
manifest for specific backends.

I guess it's similar for LDC. Porting D to a new architecture is really
mostly porting druntime and phobos. Progress is slow however, as the
LDC and GDC teams don't really have the ressources to do this in
addition to compiler support and the DMD team OTOH only supports X86.

As the test suite requires drutime and phobos, there's however no
reliable way to estimate how stable a compiler really is without having
a druntime/phobos port.



Android is a kinda special case. I had another look at Android/ARM with
GDC some time ago and after fixing a few regressions (missing
version(Android) in the arm unwinder) it passed the druntime unittests
on my mobile phone. As Joakim has fixed most druntime parts and GDC
gained emulated TLS some time ago this is not surprising.

Phobos tests however, immediately segfaulted. The reason is the way we
detect data sections. The fix is complicated but as this code will be
rewritten once GDC has shared library support there's no need to fix
this now.

TLDR: We're not far from Android/ARM support in GDC. Once we have
shared library support there's not much left*. And there are some good
news: I recently learned something new about the binutils linker
from Martin Nowak (regarding _start/_end symbols for named
sections). This hopefully means we'll have shared library support soon
in GDC. I'll 'just' have to update my old pull request...


* From a compiler/runtime perspective. I agree that 'Android
  support' should also include bindings/wrappers for various android
  functions and tutorials. But that's not my department ;-)



 Oct 18 2015



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2015-10-18 09:55, Iain Buclaw via Digitalmars-d wrote:


 In it's runtime? Correct - assuming no one invents any new predefined
 version conditions in the process. :-)


I'm pretty sure Dan has added/is planning to add new version identifiers 
for iOS. It might be that the OSX version identifier is enabled as well.

-- 
/Jacob Carlborg



 Oct 18 2015



  parent  Joakim <dlang joakim.fea.st>  writes:


On Sunday, 18 October 2015 at 16:00:11 UTC, Jacob Carlborg wrote:

 On 2015-10-18 09:55, Iain Buclaw via Digitalmars-d wrote:


 In it's runtime? Correct - assuming no one invents any new 
 predefined
 version conditions in the process. :-)


 I'm pretty sure Dan has added/is planning to add new version 
 identifiers for iOS. It might be that the OSX version 
 identifier is enabled as well.


New predefined versions are not a problem for any of the D 
compilers.  There's just been some of the usual bikeshedding 
about how many to add for new platforms and what exactly to call 
them.



 Oct 18 2015



prev sibling  parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Sunday, 18 October 2015 at 07:56:02 UTC, Iain Buclaw wrote:

 On 18 Oct 2015 9:45 am, "Vladimir Panteleev via Digitalmars-d" 
 < digitalmars-d puremagic.com> wrote:

 On Sunday, 18 October 2015 at 07:37:55 UTC, Iain Buclaw wrote:

 Essentially, the reason D has not been ported to X has 
 nothing to do




 with lack of compiler support.  A compiler can always be built 
 to target X, and if that wasn't enough, there are many ready 
 built packages available that target X.

 It is now your job as porters to fix up druntime to allow a 
 library to




 be built by these compilers.

 That's not very useful. LDC and GDC still include Phobos and 
 Druntime.


 It is infinitely more useful than having no compiler at all to 
 test porting changes.


That's not what I meant. Aside from the compiler, LDC and GDC 
include the runtime, standard library, probably documentation 
etc. They come as a complete package.


 You're essentially saying that once LDC gets Android/iOS 
 support, GDC


 will automatically get it as well with no effort required from 
 you?


 In it's runtime? Correct - assuming no one invents any new 
 predefined version conditions in the process. :-)


No, not just the runtime. Surely the runtime contains some 
compiler/linker/toolchain-specific things... intrinsics, linker 
scripts, section names, predefined versions, assembler syntax... 
some of these might be platform/architecture-independent but 
surely not all?



 Oct 19 2015



 next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 19 Oct 2015 10:50 pm, "Vladimir Panteleev via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On Sunday, 18 October 2015 at 07:56:02 UTC, Iain Buclaw wrote:

 On 18 Oct 2015 9:45 am, "Vladimir Panteleev via Digitalmars-d" <




digitalmars-d puremagic.com> wrote:

 On Sunday, 18 October 2015 at 07:37:55 UTC, Iain Buclaw wrote:

 Essentially, the reason D has not been ported to X has nothing to do




 with lack of compiler support.  A compiler can always be built to target




X, and if that wasn't enough, there are many ready built packages available
that target X.

 It is now your job as porters to fix up druntime to allow a library to




 be built by these compilers.

 That's not very useful. LDC and GDC still include Phobos and Druntime.


 It is infinitely more useful than having no compiler at all to test




porting changes.

 That's not what I meant. Aside from the compiler, LDC and GDC include the


runtime, standard library, probably documentation etc. They come as a
complete package.

 You're essentially saying that once LDC gets Android/iOS support, GDC


 will automatically get it as well with no effort required from you?


 In it's runtime? Correct - assuming no one invents any new predefined




version conditions in the process. :-)

 No, not just the runtime. Surely the runtime contains some


compiler/linker/toolchain-specific things... intrinsics, linker scripts,
section names, predefined versions, assembler syntax... some of these might
be platform/architecture-independent but surely not all?


As a compiler (and only a frontend language at that) I care very little
about any of that.  Apart from predefined versions which are exposed to the
language user code, making the rest work is Someone Else's Problem=E2=84=A2

Iain.



 Oct 19 2015



  parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Monday, 19 October 2015 at 20:59:37 UTC, Iain Buclaw wrote:

 As a compiler (and only a frontend language at that) I care 
 very little about any of that.  Apart from predefined versions 
 which are exposed to the language user code, making the rest 
 work is Someone Else's Problem™


That's what I meant when I said "not very useful" :)

Well, if you say you're responsible for the compiler and the 
compiler only, then who is responsible for GDC the package, the 
one that contains Phobos and Druntime? Who tests these packages 
to make sure that they all work together? Who packages and 
uploads them to the website?



 Oct 19 2015



  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 19 Oct 2015 11:15 pm, "Vladimir Panteleev via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On Monday, 19 October 2015 at 20:59:37 UTC, Iain Buclaw wrote:

 As a compiler (and only a frontend language at that) I care very little




about any of that.  Apart from predefined versions which are exposed to the
language user code, making the rest work is Someone Else's Problem=E2=84=A2

 That's what I meant when I said "not very useful" :)

 Well, if you say you're responsible for the compiler and the compiler


only, then who is responsible for GDC the package, the one that contains
Phobos and Druntime? Who tests these packages to make sure that they all
work together? Who packages and uploads them to the website?


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.
Johannes packages and uploads them.

I wouldn't refer to them as official, but they are officially enough to use
where building yourself is difficult - Continuous integration platforms ,
Embedded targets, Windows in general, etc.



 Oct 19 2015



  parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


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!



 Oct 20 2015



  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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.



 Oct 20 2015



 next sibling parent  Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


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.



 Oct 20 2015



prev sibling  parent reply Johannes Pfau <nospam example.com>  writes:


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.



 Oct 21 2015



  parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


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



 Oct 21 2015



  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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.



 Oct 21 2015



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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



 Oct 21 2015



 next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


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



 Oct 21 2015



  parent  Kagamin <spam here.lot>  writes:


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.



 Oct 22 2015



prev sibling  parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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!



 Oct 21 2015



prev sibling  parent  Kagamin <spam here.lot>  writes:


On Monday, 19 October 2015 at 20:47:55 UTC, Vladimir Panteleev 
wrote:

 No, not just the runtime. Surely the runtime contains some 
 compiler/linker/toolchain-specific things... intrinsics, linker 
 scripts, section names, predefined versions, assembler 
 syntax... some of these might be 
 platform/architecture-independent but surely not all?


There also was a question how one can help knowing nothing about 
compiler development. Then a working compiler would make sense.



 Oct 20 2015



prev sibling  parent reply Chris <wendlec tcd.ie>  writes:


On Saturday, 17 October 2015 at 14:37:46 UTC, Joakim wrote:

 On Friday, 16 October 2015 at 10:25:07 UTC, Chris wrote:

 Apart from that, I think the fact that D is still not fit for 
 mobile platforms is a huge drawback. Loads of people want 
 apps, loads of people have some sort of smart phone, tablet or 
 whatever. Sometimes I think that we're getting sucked in by 
 the quick sand of language specs, pointers, GC etc. while 
 important issues like targeting mobile platforms are second 
 class citizens. Nim for example targeted mobile platforms 
 right from the start. So did Go. I cannot recommend D 
 wholeheartedly unless it also works on ARM at the click of a 
 button. Please correct me if I'm wrong here, but mobile is not 
 yet 100%.


 Ldc binaries for iOS were announced in July, Dan's now working 
 on 64-bit support:

 http://forum.dlang.org/thread/m2mvz57seb.fsf comcast.net

 Android is pretty much done, just cleaning it up by integrating 
 with ldc's CMake build system and other small details, 
 announcement coming next week.


Yeah, I remember the announcemment, I was very happy. Is it still 
2.066 or is it part and parcel of the latest LDC? Your efforts 
are very much appreciated! Thank you guys!



 Oct 17 2015



  parent reply Joakim <dlang joakim.fea.st>  writes:


On Saturday, 17 October 2015 at 16:49:44 UTC, Chris wrote:

 On Saturday, 17 October 2015 at 14:37:46 UTC, Joakim wrote:

 Ldc binaries for iOS were announced in July, Dan's now working 
 on 64-bit support:

 http://forum.dlang.org/thread/m2mvz57seb.fsf comcast.net

 Android is pretty much done, just cleaning it up by 
 integrating with ldc's CMake build system and other small 
 details, announcement coming next week.


 Yeah, I remember the announcemment, I was very happy. Is it 
 still 2.066 or is it part and parcel of the latest LDC? Your 
 efforts are very much appreciated! Thank you guys!


Dan has made available some source for his work on the latest 
LDC, including 64-bit support, but not binaries like he did for 
the previous 2.066 release:

https://github.com/smolt/ldc/tree/ios-merge-2.067

On Saturday, 17 October 2015 at 21:24:34 UTC, Vladimir Panteleev 
wrote:

 I wish the extent of platform support for GDC and LDC was 
 clearer. I decided not to list any platforms on D's download 
 page unless support for those platforms was rock-solid and is 
 expected to work.


Sure, makes sense that you did that at the time, we didn't even 
list the betas there till last week.


 At least at that time, iOS and Android support, as I understood 
 it, was in the "well, if you download this thing some guy 
 uploaded to his personal website and patch that file and don't 
 do this thing which doesn't work yet, you might get a "hello 
 world" that runs from the terminal if you SSH in" ballpark. I'm 
 not sure we should be advertising support for any platform at 
 that level. Personally, I feel that if a platform/architecture 
 is listed on a language's download page, I should be able to 
 download the compiler and build a fully-working application 
 within a few minutes, and as I understand we are nowhere close 
 to that yet. I don't feel particularly strong about this, but 
 if we do decide to lower the bar, then we should reconsider all 
 the other platforms that have been left out (such as the long 
 list of GDC architectures which I understood Iain to say that, 
 well, since the build succeeds and Debian successfully packages 
 it, then it has to work. I might be wrong, though, which is my 
 point exactly - there is really insufficient information about 
 what exactly one can expect to work on each 
 platform/architecture (and their combinations).


As Walter said, as long as we label it as alpha, we can get 
people playing with it and point out that mobile support is close.

On Saturday, 17 October 2015 at 23:57:06 UTC, Vladimir Panteleev 
wrote:

 Should all this really be on the download page, though? There's 
 like a score platforms/architectures/combinations of such 
 between all compilers combined.

 Have you looked at the linked wiki page?

 http://wiki.dlang.org/Compilers

 I'm not sure we should essentially be copying that table to 
 dlang.org.

 I think we are good as we are right now. There is an "others" 
 link on the download page, so people interested in support for 
 less common or less supported platforms can find said 
 information on the wiki.


Yes, we shouldn't copy that page, but as Andrei said, the giant 
PR value of mobile support means that even alpha stage support 
for mobile does make sense to add.  I wasn't planning on 
submitting such a PR for the download page, was only going to 
post in the Announce forum, but I think Andrei is right that 
mobile is too important.

On Sunday, 18 October 2015 at 04:13:56 UTC, Vladimir Panteleev 
wrote:

 And we're not there yet.

 Please correct me if I'm wrong, but as I understand, you'll get 
 nowhere on mobile with any current official LDC releases. 
 Saying that LDC supports iOS/Android out of the box on 
 dlang.org would be false advertising at this point.


We won't say anything about the official ldc/gdc releases.  
Rather, we'll provide links to Dan's iOS binary and one I'll 
provide for Android that'll be for experimental usage.


 I'm not sure what expectations people have when they hear 
 "language X supports iOS/Android", but at least as someone who 
 hasn't done a lot of mobile development, I'd expect that the 
 official compiler can emit code I can call from my app, and get 
 it all working in minutes. This would include tutorials of how 
 would I compile/link this D code and make it talk to my 
 Java/Obj-C/Swift UI code. Again, please correct me if I'm wrong.


For those willing to play with alpha/experimental code, I don't 
think such hand-holding is necessary.  Anyway, I'll write up 
another wiki page for ldc, just as I did for dmd:

http://wiki.dlang.org/Build_DMD_for_Android


 Don't get me wrong, I'm as excited about this as anyone, but at 
 the same time I don't want people mocking us for claiming 
 support when what we have is a proof-of-concept provided by a 
 third-party fork.


As I said, iOS and Android now pass essentially all tests from 
druntime and phobos.  That's a long way from "hello world."  Is 
it rock solid?  Of course not, but an alpha compiler doesn't need 
to be.

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.

On Sunday, 18 October 2015 at 04:27:19 UTC, Vladimir Panteleev 
wrote:

 To elaborate on this a bit... the information on the downloads 
 page was written only two months ago, with the collaboration of 
 both GDC and LDC maintainers:

 https://github.com/D-Programming-Language/dlang.org/pull/1067

 Now, unless mobile support has matured significantly in the 
 past two months, the point here is that the maintainers 
 themselves have not pointed out that they were ready to 
 advertise mobile support for their compilers on dlang.org. I 
 don't think we should change this without their consent, at 
 least. As I understand, development for mobile support is still 
 occurring in a fork, and this might result users pestering the 
 maintainers regarding code that isn't even in the repository 
 they are maintaining.


The ldc/gdc maintainers are not that involved with the 
iOS/Android work: they answer our questions when we ask and they 
did earlier work for linux/ARM that is useful for other ARM 
platforms also.  Anyway, they would not have to support it, we 
would.  I don't know about Dan, but I _want_ more feedback on the 
Android build.  I made available a test runner for 
druntime/phobos as an Android apk months ago and never got any 
feedback:

http://forum.dlang.org/post/erqxbcfyyxzviftmhyzp forum.dlang.org

Looking back at what I wrote now, perhaps part of it is my fault 
for not explicitly asking people to try it out and report back 
how it works for them.  That is what I was planning on doing for 
the upcoming announcement though, as I want to document any 
devices that have problems anywhere.  So far, I've found a couple 
small differences on the three Android devices I've tested, 
probably because most of my development was on a Nexus device 
with the latest Android, while the other two I tested later had 
older versions of Android.

Anyway, we can hash this out on the PR.  Mobile builds will be 
explicitly labeled alpha and feedback directed at me (we'll have 
to ask Dan if he wants to take part), not the official 
maintainers.



 Oct 17 2015



 next sibling parent reply 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



 Oct 17 2015



  parent reply Dan Olson <gorox comcast.net>  writes:


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



 Oct 25 2015



  parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Monday, 26 October 2015 at 05:34:05 UTC, Dan Olson wrote:

 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?


Hi Dan,

Regardless of what happens on http://dlang.org/download.html, 
please add it to the wiki. I've been chasing after compiler 
hackers to update the wiki with very little success (and then 
they complain how their projects are not getting enough attention 
etc.).



 Oct 25 2015



 next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 10/25/2015 11:05 PM, Vladimir Panteleev wrote:

 I've been chasing after compiler hackers to update the wiki with very
 little success (and then they complain how their projects are not getting
enough
 attention etc.).


Yeah, that's a perennial problem.



 Oct 26 2015



prev sibling  parent  Dan Olson <gorox comcast.net>  writes:


Vladimir Panteleev <thecybershadow.lists gmail.com> writes:


 On Monday, 26 October 2015 at 05:34:05 UTC, Dan Olson wrote:

 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".




(snip)


 Regardless of what happens on http://dlang.org/download.html, please
 add it to the wiki. I've been chasing after compiler hackers to update
 the wiki with very little success (and then they complain how their
 projects are not getting enough attention etc.).


Done



 Oct 26 2015



prev sibling  parent  Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Sunday, 18 October 2015 at 04:55:53 UTC, Joakim wrote:

 I made available a test runner for druntime/phobos as an 
 Android apk months ago and never got any feedback:

 http://forum.dlang.org/post/erqxbcfyyxzviftmhyzp forum.dlang.org


Posts buried deep in old threads are not very visible. I would 
suggest creating a new thread in the announce group (titled e.g. 
"D for Android alpha - testers needed").


 Anyway, we can hash this out on the PR.  Mobile builds will be 
 explicitly labeled alpha and feedback directed at me (we'll 
 have to ask Dan if he wants to take part), not the official 
 maintainers.


If I may suggest, I would recommend creating a wiki page first. 
Currently even http://wiki.dlang.org/Compilers says absolutely 
nothing about LDC for Android, so it's not surprising that your 
project is not discoverable. The page should make it clear that 
this is presently a fork of the official LDC project, and contain 
all the instructions on getting something to work. I'll be happy 
to add a link to it from dlang.org once it's up.



 Oct 17 2015



prev sibling  parent  Max Samukha <maxsamukha gmail.com>  writes:


On Friday, 16 October 2015 at 08:29:18 UTC, Kagamin wrote:

 On Thursday, 15 October 2015 at 09:09:22 UTC, Chris wrote:

 I agree with logicchains. The impression people have is 
 exactly this. Go = neat and tidy, D = mess.


 Do people have the same impression from generic code in Go?


Crutches help them move along: http://blog.golang.org/generate



 Oct 17 2015



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/15/15 11:11 AM, Kagamin wrote:

 On Thursday, 15 October 2015 at 06:36:32 UTC, logicchains wrote:

 Even if it's not entirely logical, all these unfinished aspects can
 add up to produce a less positive aesthetic impression of the language
 compared to a language that comes across as more polished.


 If go is finished, why there's activity in its repository?


I would agree that we're less polished than Go and other languages. This 
is something we need to work on - just show the world a completely 
defined and implemented language. -- Andrei



 Oct 15 2015



 next sibling parent reply Charles Pritchard <chuck jumis.com>  writes:


On Thursday, 15 October 2015 at 10:24:34 UTC, Andrei Alexandrescu 
wrote:

 On 10/15/15 11:11 AM, Kagamin wrote:

 On Thursday, 15 October 2015 at 06:36:32 UTC, logicchains 
 wrote:

 Even if it's not entirely logical, all these unfinished 
 aspects can
 add up to produce a less positive aesthetic impression of the 
 language






...

 I would agree that we're less polished than Go and other 
 languages. This is something we need to work on - just show the 
 world a completely defined and implemented language. -- Andrei


I'd like to see a roadmap, covering some of the pain points that 
logicchains brought up. It'd be nice to look at it, and get the 
impression that those issues will be resolved within an estimated 
time period; mainly around GC and ref.



 Oct 15 2015



  parent reply deadalnix <deadalnix gmail.com>  writes:


On Thursday, 15 October 2015 at 18:38:38 UTC, Charles Pritchard 
wrote:

 On Thursday, 15 October 2015 at 10:24:34 UTC, Andrei 
 Alexandrescu wrote:

 On 10/15/15 11:11 AM, Kagamin wrote:

 On Thursday, 15 October 2015 at 06:36:32 UTC, logicchains 
 wrote:

 Even if it's not entirely logical, all these unfinished 
 aspects can
 add up to produce a less positive aesthetic impression of 
 the language






 ...

 I would agree that we're less polished than Go and other 
 languages. This is something we need to work on - just show 
 the world a completely defined and implemented language. -- 
 Andrei


 I'd like to see a roadmap, covering some of the pain points 
 that logicchains brought up. It'd be nice to look at it, and 
 get the impression that those issues will be resolved within an 
 estimated time period; mainly around GC and ref.


Making a roadmap when you don't have people you pay to stick to 
it doesn't really work. It's like trying to transport frogs using 
a wheelbarrel.



 Oct 15 2015



  parent  John Colvin <john.loughran.colvin gmail.com>  writes:


On Thursday, 15 October 2015 at 19:16:08 UTC, deadalnix wrote:

 Making a roadmap when you don't have people you pay to stick to 
 it doesn't really work. It's like trying to transport frogs 
 using a wheelbarrel.


s/barrel/barrow/



 Oct 15 2015



prev sibling  parent reply German Diago <germandiago gmail.com>  writes:


On Thursday, 15 October 2015 at 10:24:34 UTC, Andrei Alexandrescu 
wrote:

 I would agree that we're less polished than Go and other 
 languages. This is something we need to work on - just show the 
 world a completely defined and implemented language. -- Andrei


Hello Andrei. A bit off-topic, but,
you are on that now, right? I saw in the media you
left Facebook to do D things and manage the D foundation.

As a proficient C++ coder for many years, but not as much as you 
:),
this was kind of the news of the year for me. I expect a push to 
the
language.

I have had high hopes for D, but C++ is also improving. I took a 
look at Nim and
Rust. I think D is more practical for real use at this point.
Though, did not try myself on a real scenario, I always end up 
choosing C++
for my taks because it has great support.

My main concerns to changing to D are:

- Garbage collector. I think there was a plan for Phobos without 
GC, but...
what about the run-time, can be disabled? I am not sure this 
meets the
requirements of some embedded devices I work/have worked with.
- Memory-control: Allocators. I saw this has been solved.
- Production-readiness: when I go to C++, the ecosystem is simply 
unbeatable.
This keeps me away from moving to D.
- Platform support: For C++, I can use it in phones, embedded, 
PCs... basically
everywhere.
What areas are considered "incomplete" as of now to consider D a 
production-ready product, in your opinion?


As a long-term C++ user, I understand D quite well but did not 
try it a lot
for real world use. The standard library
looks very good to me, though, I do not know how much it relies 
on GC at this
point. Something that, in C++, I do not need to worry about.



 Oct 16 2015



 next sibling parent reply John Colvin <john.loughran.colvin gmail.com>  writes:


On Friday, 16 October 2015 at 08:03:06 UTC, German Diago wrote:

 [...]


Just a small note FYI, there's an easy way to get a feel for the 
current state of GC reliance:

void main()  nogc
{
     // try stuff out
}



 Oct 16 2015



  parent reply German Diago <germandiago gmail.com>  writes:


On Friday, 16 October 2015 at 08:11:18 UTC, John Colvin wrote:

 On Friday, 16 October 2015 at 08:03:06 UTC, German Diago wrote:

 [...]


 Just a small note FYI, there's an easy way to get a feel for 
 the current state of GC reliance:

 void main()  nogc
 {
     // try stuff out
 }


Thanks for the tip. Is this 100% reliable?



 Oct 16 2015



  parent reply John Colvin <john.loughran.colvin gmail.com>  writes:


On Friday, 16 October 2015 at 08:43:12 UTC, German Diago wrote:

 On Friday, 16 October 2015 at 08:11:18 UTC, John Colvin wrote:

 On Friday, 16 October 2015 at 08:03:06 UTC, German Diago wrote:

 [...]


 Just a small note FYI, there's an easy way to get a feel for 
 the current state of GC reliance:

 void main()  nogc
 {
     // try stuff out
 }


 Thanks for the tip. Is this 100% reliable?


As far as I know, yes.  nogc can be put on any function and will 
guarantee that no GC code will run inside that function or 
anything else it calls.



 Oct 16 2015



  parent reply German Diago <germandiago gmail.com>  writes:


On Friday, 16 October 2015 at 08:58:25 UTC, John Colvin wrote:

 void main()  nogc
 {
     // try stuff out
 }


 Thanks for the tip. Is this 100% reliable?


 As far as I know, yes.  nogc can be put on any function and 
 will guarantee that no GC code will run inside that function or 
 anything else it calls.


Is this a static check that fails at compile-time, or it means 
that if, at
run-time, gc is invoked, an exception will be thrown? Sorry so 
many questions,
I do not have access to a compiler at the moment here.



 Oct 16 2015



  parent  John Colvin <john.loughran.colvin gmail.com>  writes:


On Friday, 16 October 2015 at 09:01:41 UTC, German Diago wrote:

 On Friday, 16 October 2015 at 08:58:25 UTC, John Colvin wrote:

 void main()  nogc
 {
     // try stuff out
 }


 Thanks for the tip. Is this 100% reliable?


 As far as I know, yes.  nogc can be put on any function and 
 will guarantee that no GC code will run inside that function 
 or anything else it calls.


 Is this a static check that fails at compile-time, or it means 
 that if, at
 run-time, gc is invoked, an exception will be thrown? Sorry so 
 many questions,
 I do not have access to a compiler at the moment here.


static check, at compile-time.

You can try things out from anywhere with with 
http://dpaste.dzfl.pl/



 Oct 16 2015



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/16/15 11:03 AM, German Diago wrote:

 - Garbage collector. I think there was a plan for Phobos without GC, but...
 what about the run-time, can be disabled? I am not sure this meets the
 requirements of some embedded devices I work/have worked with.
 - Memory-control: Allocators. I saw this has been solved.
 - Production-readiness: when I go to C++, the ecosystem is simply
 unbeatable.
 This keeps me away from moving to D.
 - Platform support: For C++, I can use it in phones, embedded, PCs...
 basically
 everywhere.
 What areas are considered "incomplete" as of now to consider D a
 production-ready product, in your opinion?


D is production ready for the simple reason it is being factually used 
in production by a variety of companies. That said the same definition 
does not work for all companies and clearly D does not currently pass 
muster to the extent more established languages are.

Reducing the use of GC (both in the standard library and in client code) 
is front and center among our priorities. Walter has done a lot of work 
on it and we hope others to follow the lead.

For platform support (e.g. mobile) we need the appropriate champions to 
take us from "it could be done" and "it experimentally works" all the 
way to deliverable tools.

The areas I consider incomplete:

* Language definition, e.g. "shared".
* Language definition _writeup_, we need to be a lot more precise than 
we currently are.
* Process for introducing new features, i.e. right now we seem to have 
some of the drawbacks of a large political organization and also the 
drawbacks of a small community.
* Parts of stdlib, e.g. no robust idioms for transferring complex 
objects across threads, unneeded use of the GC, insufficient support for 
safe garbage collection; also no extensive containers, file formats, 
etc. etc.
* Tutorials - there's no simple tutorial material that takes people from 
novice to initiated status.


Andrei



 Oct 16 2015



  parent  Jacob Carlborg <doob me.com>  writes:


On 2015-10-16 12:27, Andrei Alexandrescu wrote:


 The areas I consider incomplete:

 * Language definition, e.g. "shared".
 * Language definition _writeup_, we need to be a lot more precise than
 we currently are.
 * Process for introducing new features, i.e. right now we seem to have
 some of the drawbacks of a large political organization and also the
 drawbacks of a small community.
 * Parts of stdlib, e.g. no robust idioms for transferring complex
 objects across threads, unneeded use of the GC, insufficient support for
 safe garbage collection; also no extensive containers, file formats,
 etc. etc.
 * Tutorials - there's no simple tutorial material that takes people from
 novice to initiated status.


The module system? Perhaps not incomplete, but the wholes need to be 
plugged. Issue 313, 314 and all the issues that lately come up with 
local imports.

-- 
/Jacob Carlborg



 Oct 16 2015



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 10/13/2015 12:13 PM, Walter Bright wrote:

 On 10/13/2015 6:36 AM, Daniel Kozak wrote:

 lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

 Maybe we could have something similar in D community


 No. People who need to be told what decent behavior is won't pay attention to
 such a document.


Apparently I'm in good company:

"trying to come up with some ‘code of conduct’ that says that people should
be 
‘respectful’ and ‘polite’ is just so much crap and bullshit”

    -- Linus Torvalds, https://gumroad.com/l/prQdM#



 Oct 28 2015



 next sibling parent  John Colvin <john.loughran.colvin gmail.com>  writes:


On Wednesday, 28 October 2015 at 08:36:07 UTC, Walter Bright 
wrote:

 On 10/13/2015 12:13 PM, Walter Bright wrote:

 On 10/13/2015 6:36 AM, Daniel Kozak wrote:

 lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

 Maybe we could have something similar in D community


 No. People who need to be told what decent behavior is won't 
 pay attention to
 such a document.


 Apparently I'm in good company:

 "trying to come up with some ‘code of conduct’ that says that 
 people should be ‘respectful’ and ‘polite’ is just so much crap 
 and bullshit”

    -- Linus Torvalds, https://gumroad.com/l/prQdM#


Adding Linus to a discussion about Codes of Conduct is not so 
much opening a can of worms as upending a barrel of snakes.



 Oct 28 2015



prev sibling  parent reply Jakob Bornecrantz <wallbraker gmail.com>  writes:


On Wednesday, 28 October 2015 at 08:36:07 UTC, Walter Bright 
wrote:

 On 10/13/2015 12:13 PM, Walter Bright wrote:

 On 10/13/2015 6:36 AM, Daniel Kozak wrote:

 lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

 Maybe we could have something similar in D community


 No. People who need to be told what decent behavior is won't 
 pay attention to such a document.


 Apparently I'm in good company:

 "trying to come up with some ‘code of conduct’ that says that 
 people should be ‘respectful’ and ‘polite’ is just so much crap 
 and bullshit”

    -- Linus Torvalds, https://gumroad.com/l/prQdM#


You are not in good company tho. Even the page you link to says
nobody else could or should say stuff like that.

And attitudes like that will only disurage people from trying to
improve this community.

http://sarah.thesharps.us/2015/10/05/closing-a-door/
https://mjg59.dreamwidth.org/38136.html

These are different times.

Cheers, Jakob.



 Oct 28 2015



 next sibling parent reply deadalnix <deadalnix gmail.com>  writes:


On Wednesday, 28 October 2015 at 09:12:55 UTC, Jakob Bornecrantz 
wrote:

 You are not in good company tho. Even the page you link to says
 nobody else could or should say stuff like that.


Quick, call the thought police !


 And attitudes like that will only disurage people from trying to
 improve this community.


War is peace, freedom is slavery, ignorance is strength, 
censorship is improvement.


 http://sarah.thesharps.us/2015/10/05/closing-a-door/
 https://mjg59.dreamwidth.org/38136.html

 These are different times.


Yup, professional victim use to not be a viable career path.



 Oct 28 2015



 next sibling parent reply David DeWitt <dkdewitt gmail.com>  writes:


On Wednesday, 28 October 2015 at 17:13:27 UTC, deadalnix wrote:

 On Wednesday, 28 October 2015 at 09:12:55 UTC, Jakob 
 Bornecrantz wrote:

 You are not in good company tho. Even the page you link to says
 nobody else could or should say stuff like that.


 Quick, call the thought police !


 And attitudes like that will only disurage people from trying 
 to
 improve this community.


 War is peace, freedom is slavery, ignorance is strength, 
 censorship is improvement.


 http://sarah.thesharps.us/2015/10/05/closing-a-door/
 https://mjg59.dreamwidth.org/38136.html

 These are different times.


 Yup, professional victim use to not be a viable career path.


We just need PC Principle

https://www.youtube.com/watch?v=0-ZQED7bLhw



 Oct 28 2015



  parent  rsw0x <anonymous anonymous.com>  writes:


On Wednesday, 28 October 2015 at 17:38:49 UTC, David DeWitt wrote:

 On Wednesday, 28 October 2015 at 17:13:27 UTC, deadalnix wrote:

 On Wednesday, 28 October 2015 at 09:12:55 UTC, Jakob 
 Bornecrantz wrote:

 You are not in good company tho. Even the page you link to 
 says
 nobody else could or should say stuff like that.


 Quick, call the thought police !


 And attitudes like that will only disurage people from trying 
 to
 improve this community.


 War is peace, freedom is slavery, ignorance is strength, 
 censorship is improvement.


 http://sarah.thesharps.us/2015/10/05/closing-a-door/
 https://mjg59.dreamwidth.org/38136.html

 These are different times.


 Yup, professional victim use to not be a viable career path.


 We just need PC Principle

 https://www.youtube.com/watch?v=0-ZQED7bLhw


You PC, bro?



 Oct 28 2015



prev sibling  parent reply Jakob Bornecrantz <wallbraker gmail.com>  writes:


On Wednesday, 28 October 2015 at 17:13:27 UTC, deadalnix wrote:

 http://sarah.thesharps.us/2015/10/05/closing-a-door/
 https://mjg59.dreamwidth.org/38136.html

 These are different times.


 Yup, professional victim use to not be a viable career path.


What do you mean?

Cheers, Jakob.



 Oct 29 2015



  parent reply deadalnix <deadalnix gmail.com>  writes:


On Thursday, 29 October 2015 at 23:27:47 UTC, Jakob Bornecrantz 
wrote:

 On Wednesday, 28 October 2015 at 17:13:27 UTC, deadalnix wrote:

 http://sarah.thesharps.us/2015/10/05/closing-a-door/
 https://mjg59.dreamwidth.org/38136.html

 These are different times.


 Yup, professional victim use to not be a viable career path.


 What do you mean?

 Cheers, Jakob.


Adria Richard, Shanley Kane, Randi Harper, this is the never 
ending train...

Why would someone capable as Sarah Sharp would join the train is 
a mystery, but not all mystery are worth spending time solving.



 Oct 29 2015



  parent  Kagamin <spam here.lot>  writes:


On Friday, 30 October 2015 at 06:04:48 UTC, deadalnix wrote:

 Why would someone capable as Sarah Sharp would join the train 
 is a mystery, but not all mystery are worth spending time 
 solving.


Judging by her post, she tried to force her behavioral standards 
on the Linux kernel community and did it poorly. Not a mystery. 
How can one submit a whole community to his bidding?



 Oct 30 2015



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 10/28/2015 2:12 AM, Jakob Bornecrantz wrote:

 You are not in good company tho. Even the page you link to says
 nobody else could or should say stuff like that.

 And attitudes like that will only disurage people from trying to
 improve this community.

 http://sarah.thesharps.us/2015/10/05/closing-a-door/
 https://mjg59.dreamwidth.org/38136.html

 These are different times.


I did not mean that absence of a Code of Conduct is license to abuse others. 
Just that a CoC is itself insulting, paternalistic, and not a solution.



 Oct 28 2015



 next sibling parent  Kagamin <spam here.lot>  writes:


On Wednesday, 28 October 2015 at 17:36:03 UTC, Walter Bright 
wrote:

 I did not mean that absence of a Code of Conduct is license to 
 abuse others. Just that a CoC is itself insulting, 
 paternalistic, and not a solution.


I believe it can be understood, because asocial people are left 
to deal with social problems alone, they naturally learn to deal 
with it on their own, hence they see law as paternalistic, but 
this doesn't apply to social people, who already have law as an 
obvious solution to abuse. Lattner words it well in his message: 
CoC is not written for the community, it's written for the 
oppressive committee to enforce.



 Oct 29 2015



prev sibling  parent reply Jakob Bornecrantz <wallbraker gmail.com>  writes:


On Wednesday, 28 October 2015 at 17:36:03 UTC, Walter Bright 
wrote:

 On 10/28/2015 2:12 AM, Jakob Bornecrantz wrote:

 You are not in good company tho. Even the page you link to says
 nobody else could or should say stuff like that.

 And attitudes like that will only disurage people from trying 
 to
 improve this community.

 http://sarah.thesharps.us/2015/10/05/closing-a-door/
 https://mjg59.dreamwidth.org/38136.html

 These are different times.


 I did not mean that absence of a Code of Conduct is license to 
 abuse others. Just that a CoC is itself insulting, 
 paternalistic, and not a solution.


Fair enough. Its a shame you see it as insulting.

I pose you this question: if I as a new person coming to this
community and felt that I was being treated unfairly, badly or
any other form where should I turn to? Is this documented 
somewhere?

Building onto that how should I expect to be treated, you
mentioned decent, how do you define decent?

Cheers, Jakob.



 Oct 29 2015



 next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/29/15 7:49 PM, Jakob Bornecrantz wrote:

 On Wednesday, 28 October 2015 at 17:36:03 UTC, Walter Bright wrote:

 On 10/28/2015 2:12 AM, Jakob Bornecrantz wrote:

 You are not in good company tho. Even the page you link to says
 nobody else could or should say stuff like that.

 And attitudes like that will only disurage people from trying to
 improve this community.

 http://sarah.thesharps.us/2015/10/05/closing-a-door/
 https://mjg59.dreamwidth.org/38136.html

 These are different times.


 I did not mean that absence of a Code of Conduct is license to abuse
 others. Just that a CoC is itself insulting, paternalistic, and not a
 solution.


 Fair enough. Its a shame you see it as insulting.

 I pose you this question: if I as a new person coming to this
 community and felt that I was being treated unfairly, badly or
 any other form where should I turn to? Is this documented somewhere?


I'd say it's safe to just let this go. If you're treated unkindly by 
your neighbors or any community you're interacting with, there's no 
authority to go to as long as they don't break the law. Herein, the 
leader of this community has a strong opinion that this community 
shouldn't be policed, which makes things as cut and dried as it gets. No 
reply needed. Thanks. -- Andrei



 Oct 29 2015



prev sibling  parent  Joakim <dlang joakim.fea.st>  writes:


On Thursday, 29 October 2015 at 23:49:08 UTC, Jakob Bornecrantz 
wrote:

 On Wednesday, 28 October 2015 at 17:36:03 UTC, Walter Bright 
 wrote:

 On 10/28/2015 2:12 AM, Jakob Bornecrantz wrote:

 You are not in good company tho. Even the page you link to 
 says
 nobody else could or should say stuff like that.

 And attitudes like that will only disurage people from trying 
 to
 improve this community.

 http://sarah.thesharps.us/2015/10/05/closing-a-door/
 https://mjg59.dreamwidth.org/38136.html

 These are different times.


 I did not mean that absence of a Code of Conduct is license to 
 abuse others. Just that a CoC is itself insulting, 
 paternalistic, and not a solution.


 Fair enough. Its a shame you see it as insulting.

 I pose you this question: if I as a new person coming to this
 community and felt that I was being treated unfairly, badly or
 any other form where should I turn to? Is this documented 
 somewhere?


What do you expect to be done about it?  A code of conduct might 
make sense for a more formal organization like a business, where 
you can actually fire someone, but what power do you think 
anybody has over this completely volunteer community?  The forum 
is completely open, which has the benefit of engaging people from 
all over the world combined with the drawback of occasional bad 
behavior or spam.

This community is small and remarkably friendly while still 
containing withering criticism over technical issues, that's a 
fantastic and difficult mix that the early contributors have set 
the tone for.  You're trying to solve a problem that doesn't 
exist.  If you simply want someone to complain to if treated 
badly, it's well known that Walter runs the show here.


 Building onto that how should I expect to be treated, you
 mentioned decent, how do you define decent?


How could this possibly be defined, especially in an 
international community with many varied norms?  What you may 
find insulting, others may find mildly pejorative.  Worse, you 
will never be able to peg something so subjective as "insulting 
language" under legalese from a code of conduct.  All such a code 
provides is cover for those wanting to punish someone, while it 
will almost always be subjective if the actual behavior fits the 
legalese of the code.

The only possibility where a code of conduct might apply is the 
one Lattner mentioned for llvm, long before they ever had a code, 
where "an active contributor... was treating many people in an 
unacceptable way."  In that case, there is real punishment 
possible, excising the contributor as they did.  I don't think D 
has had that problem yet, nor would it be difficult to enforce 
for an open-source project where nobody's paid for contribution.  
Worst case, if there's an entire faction being abusive or 
supporting one abusive contributor, you tell them to fork.



 Oct 29 2015