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