digitalmars.D - What do you want to see for a mature DLang?
- IM (16/16) Dec 28 2017 I will start:
- Daniel Kozak (5/20) Dec 29 2017 You should fill an issue on issues.dlang.org for this particular case.
- codephantom (10/11) Dec 29 2017 I will add:
- vit (37/53) Dec 29 2017 Similar problem is when some template with alias callback fail to
- JN (5/5) Dec 29 2017 AFAIK Rust doesn't have templates, but generics. Generics usually
- I Love Stuffing (6/11) Dec 29 2017 Templates are bad because they write code for you. And it's that
- Elronnd (4/6) Dec 29 2017 std.container.dlist
- rumbu (5/11) Dec 29 2017 The queue or stack usage is not obvious at all. One would expect
- Patrick Schluter (18/29) Dec 30 2017 Yes, it's the same issue in C when using complicated macros. You
- Dylan Graham (4/20) Dec 29 2017 I'd like to see proper DLL (shared library) support and DIP45
- angel (3/19) Dec 29 2017 Built-in tuples:
- maarten van damme (5/33) Dec 29 2017 I'm making a project that I hope in the future will be extendable with D
- rikki cattermole (3/9) Dec 29 2017 The starting problem is TypeInfo doesn't cross the dll/host binary
- Basile B. (9/15) Dec 29 2017 I casually encountered D issues that i qualified as "major" but
- Satoshi (15/31) Dec 29 2017 This topic was there for so many times.
- Arek (4/9) Dec 29 2017 I would like to have a complete and well-defined memory model.
- Adam D. Ruppe (3/5) Dec 29 2017 This is the only thing I greatly care about anymore. Biggest
- Walter Bright (3/9) Dec 29 2017 This is not actionable. What is actionable is filing bugzilla enhancemen...
- Adam D. Ruppe (9/11) Dec 29 2017 I've done better than that: I've written pull requests.
- Walter Bright (6/18) Dec 29 2017 That's been closed for a while now.
- Adam D. Ruppe (22/23) Dec 29 2017 Well, take your pick:
- IM (22/47) Dec 29 2017 Just curious, why Bugzilla and not something else? I can guess
- Adam D. Ruppe (4/5) Dec 29 2017 Bugzilla was the most well-known solution at the time. Keep in
- Seb (28/33) Dec 31 2017 No it wouldn't be a big pain. There are many tools for
- Meta (13/45) Dec 31 2017 I wholeheartedly agree. The customer is always right, especially
- Mengu (15/70) Dec 31 2017 there are three things that i've noticed:
- rjframe (10/14) Dec 31 2017 That's probably not the best method of effecting change.
- Pjotr Prins (25/26) Jan 01 2018 It killed off the discussion nicely, indeed.
- Patrick Schluter (2/28) Jan 02 2018 +10000
- H. S. Teoh (6/33) Jan 02 2018 +10000 * 2
- IM (13/47) Jan 03 2018 To clarify, I too like D. It is certainly very pleasant to work
- codephantom (15/27) Jan 03 2018 D is one of the most interesting and easy to use languages I've
- Mike Parker (20/22) Jan 03 2018 Several bugs get wiped in each release, as the changelogs clearly
- codephantom (3/5) Jan 03 2018 This is the mystery behind everything in the universe.
- codephantom (14/24) Jan 03 2018 I think this might also be a good project for one of Andrei's
- H. S. Teoh (34/38) Jan 03 2018 [...]
- Paolo Invernizzi (2/3) Jan 04 2018 I'm missing Kenji...
- codephantom (27/30) Jan 04 2018 I think that view really needs to be challenged.
- rjframe (14/25) Jan 04 2018 At the time of writing:
- codephantom (15/22) Jan 04 2018 Whether D is usable, reliable or whatever was not my argument.
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (5/6) Jan 05 2018 Most appears to be library related or improvement requests…
- Jonathan M Davis (52/86) Dec 31 2017 I honestly am unaware of any reason why using github issues would be
- rjframe (6/20) Dec 31 2017 If only one person has access to Bugzilla, we're actually at a greater
- Walter Bright (5/5) Dec 29 2017 Creating a bugzilla account takes a couple minutes. It is enough frictio...
- Muld (20/22) Dec 30 2017 Yah there are a ton of Bugzilla issues, that's the problem. More
- Iain Buclaw (27/48) Dec 30 2017 There's nothing unmanageable about the issue tracker, nor are the
- codephantom (12/22) Dec 30 2017 Is this a problem with triage?
- Iain Buclaw (11/27) Dec 30 2017 Either:
- codephantom (5/8) Dec 30 2017 "This list is too long for Bugzilla's little mind"
- Muld (4/16) Dec 31 2017 I haven't been looking recently. At least there's one vigilante
- Walter Bright (5/11) Dec 30 2017 Anyone can contribute to bugzilla with reasoned advice about what to do ...
- IM (7/20) Dec 30 2017 While we are discussing it here, could you please let me know
- Walter Bright (5/10) Dec 30 2017 Bugs are ranked by severity, but generally what gets fixed are bugs that...
- IM (15/29) Dec 31 2017 I hope that you could see that this doesn't scale very well, and
- Walter Bright (6/7) Dec 31 2017 We've tried adding process before. It does not work, for the simple reas...
- codephantom (17/24) Dec 31 2017 Well, I've spent the last few months just learning the language,
- IM (22/30) Jan 01 2018 Something should work. It just needs to be found. People are
- Muld (11/20) Dec 31 2017 I already have, and like I said there are problems with with the
- Walter Bright (4/5) Dec 31 2017 A word to the wise. Being rude will just get you ignored by most everyon...
- Binghoo Dang (17/18) Jan 05 2018 Stop making noise except one-day you make another well-known
- Meta (18/32) Dec 31 2017 This is a problem that many of us are working on fixing. The main
- Walter Bright (3/4) Dec 29 2017 PRs to fix bugzilla issues get submitted every day. I don't see a better...
- Muld (17/27) Dec 29 2017 Bugzilla is a huge mess tbh, creating a request in bugzilla won't
- Walter Bright (5/8) Dec 29 2017 It's not a big deal to create a duplicate of existing entries. As to bug...
- Muld (10/21) Dec 30 2017 This does not mean anything, just cause fixes for Bugzilla issues
- IM (34/39) Dec 29 2017 Please allow me to give an example of how first impressions of
- Walter Bright (3/10) Dec 29 2017 I'm sorry, there is literally nothing I can do with that. To get action,...
- ag0aep6g (4/7) Dec 30 2017 As far as I'm aware, the foundation isn't too active in those areas;
- Laeeth Isharc (93/140) Jan 04 2018 Then probably you did the right thing in not suggesting they move
- Paolo Invernizzi (11/16) Jan 05 2018 +1000
- Neia Neutuladh (18/20) Dec 29 2017 Very much so.
- Walter Bright (5/8) Dec 29 2017 Diverging from the:
- Seb (5/14) Dec 29 2017 It's easy to detect whether the compiler is invoked in a TTY.
- Atila Neves (3/21) Dec 29 2017 Being in an editor does not imply being in a TTY.
- rjframe (14/25) Dec 29 2017 I think the idea of the OP is that the message should be better; not tha...
- Walter Bright (9/17) Dec 29 2017 Many compilers produce such error codes. I've considered it many times, ...
- codephantom (4/8) Dec 29 2017 No URLs! (unless they point to 'local' documentation).
- radagast (12/28) Dec 30 2017 * R-value references.
I will start: -- Better compiler errors, better compiler errors, better compiler errors. I really wish that the compiler errors could receive some refinement. Mostly it feels like some error text just being thrown at me. It needs to be better formatted, more helpful, with suggestions about how to fix (if possible). To illustrate my point: - See the compile errors I've just encountered with DMD: https://cdn.pbrd.co/images/H0q609l.png - Now compare that with an error produced by rustc: https://cdn.pbrd.co/images/H0q6bLi.png Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.
Dec 28 2017
You should fill an issue on issues.dlang.org for this particular case. Compile should give you some hint, that you should use lvalue instead of rvalue. On Fri, Dec 29, 2017 at 8:53 AM, IM via Digitalmars-d < digitalmars-d puremagic.com> wrote:I will start: -- Better compiler errors, better compiler errors, better compiler errors. I really wish that the compiler errors could receive some refinement. Mostly it feels like some error text just being thrown at me. It needs to be better formatted, more helpful, with suggestions about how to fix (if possible). To illustrate my point: - See the compile errors I've just encountered with DMD: https://cdn.pbrd.co/images/H0q609l.png - Now compare that with an error produced by rustc: https://cdn.pbrd.co/images/H0q6bLi.png Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.
Dec 29 2017
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:I will start:I will add: // ---------- module test; import std.stdio; safe void main() { writeln("I'd like to see safe as being the default"); } // ------------
Dec 29 2017
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:I will start: -- Better compiler errors, better compiler errors, better compiler errors. I really wish that the compiler errors could receive some refinement. Mostly it feels like some error text just being thrown at me. It needs to be better formatted, more helpful, with suggestions about how to fix (if possible). To illustrate my point: - See the compile errors I've just encountered with DMD: https://cdn.pbrd.co/images/H0q609l.png - Now compare that with an error produced by rustc: https://cdn.pbrd.co/images/H0q6bLi.png Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.Similar problem is when some template with alias callback fail to instantiate because callback contains error. Example: void foo(){ string str = 1; /++ nice error message: Error: cannot implicitly convert expression `1` of type `int` to `string` +/ import std.algorithm; [1, 2, 3].each!((x){ string str = 1 ///same error }); /++ horrible error message without root cause: source\app.d(660,14): Error: template app.foo.each!((x) { string str = 1; } ).each cannot deduce function from argument types !()(int[]), candidates are: C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\iteration.d(899,10): app.foo.each!((x) { string str = 1; } ).each(Range)(Range r) if (!isForeachIterable!Range && (isRangeIterable!Range || __traits(compiles, typeof(r.front).length))) C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\iteration.d(934,10): app.foo.each!((x) { string str = 1; } ).each(Iterable)(auto ref Iterable r) if (isForeachIterable!Iterable || __traits(compiles, Parameters!(Parameters!(r.opApply)))) +/ }
Dec 29 2017
AFAIK Rust doesn't have templates, but generics. Generics usually have much cleaner error messages because they are mostly used for generic functions and classes, meanwhile templates can do that too but much, much more, but when they break, you get entire paragraphs of template errors.
Dec 29 2017
On Friday, 29 December 2017 at 09:46:05 UTC, JN wrote:AFAIK Rust doesn't have templates, but generics. Generics usually have much cleaner error messages because they are mostly used for generic functions and classes, meanwhile templates can do that too but much, much more, but when they break, you get entire paragraphs of template errors.Templates are bad because they write code for you. And it's that code you don't write that could have errors. It's a double edge sword. Also, for a mature D, some damn collections. Queues, Stacks, Deques, etc...
Dec 29 2017
On Friday, 29 December 2017 at 22:05:31 UTC, I Love Stuffing wrote:Also, for a mature D, some damn collections. Queues, Stacks, Deques, etc...std.container.dlist (https://dlang.org/phobos/std_container_dlist.html)?
Dec 29 2017
On Saturday, 30 December 2017 at 07:30:39 UTC, Elronnd wrote:On Friday, 29 December 2017 at 22:05:31 UTC, I Love Stuffing wrote:The queue or stack usage is not obvious at all. One would expect something like stack.push, stack.pop or queue.enque, queue.deque and may be a peek(). Instead one will get 33 functions that can be used with a doubly-linked list.Also, for a mature D, some damn collections. Queues, Stacks, Deques, etc...std.container.dlist (https://dlang.org/phobos/std_container_dlist.html)?
Dec 29 2017
On Friday, 29 December 2017 at 22:05:31 UTC, I Love Stuffing wrote:On Friday, 29 December 2017 at 09:46:05 UTC, JN wrote:Yes, it's the same issue in C when using complicated macros. You have to do all substitutions by hand to understand the real error message. D templates have more information so there's hope to get a better resolution of the error cause. But, the error message thing is a double edge sword, the more information is given the more difficult it gets to quickly find what the issue is. Again to illustrate with my C experience (sorry I'm paid for programming C, D is hobby that I try to sneakily introduce). The gcc 4 error messages were simple 1 lines errors, from gcc 5 on they introduced the multi-line errors with positioning like in that Rust example above. At the beginning I was quite happy with that as the error messages are so much more detailed, but now after some time, I find them really annoying as it is much more eye straining to find the real error message in between the positioning text.AFAIK Rust doesn't have templates, but generics. Generics usually have much cleaner error messages because they are mostly used for generic functions and classes, meanwhile templates can do that too but much, much more, but when they break, you get entire paragraphs of template errors.Templates are bad because they write code for you. And it's that code you don't write that could have errors. It's a double edge sword. Also, for a mature D, some damn collections. Queues, Stacks, Deques, etc...
Dec 30 2017
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:I will start: -- Better compiler errors, better compiler errors, better compiler errors. I really wish that the compiler errors could receive some refinement. Mostly it feels like some error text just being thrown at me. It needs to be better formatted, more helpful, with suggestions about how to fix (if possible). To illustrate my point: - See the compile errors I've just encountered with DMD: https://cdn.pbrd.co/images/H0q609l.png - Now compare that with an error produced by rustc: https://cdn.pbrd.co/images/H0q6bLi.png Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.I'd like to see proper DLL (shared library) support and DIP45 implemented. I'm making a project that I hope in the future will be extendable with D plugins.
Dec 29 2017
Built-in tuples: {val1, val2} = func(); On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:I will start: -- Better compiler errors, better compiler errors, better compiler errors. I really wish that the compiler errors could receive some refinement. Mostly it feels like some error text just being thrown at me. It needs to be better formatted, more helpful, with suggestions about how to fix (if possible). To illustrate my point: - See the compile errors I've just encountered with DMD: https://cdn.pbrd.co/images/H0q609l.png - Now compare that with an error produced by rustc: https://cdn.pbrd.co/images/H0q6bLi.png Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.
Dec 29 2017
I'd like to see proper DLL (shared library) support and DIP45 implemented.I'm making a project that I hope in the future will be extendable with D plugins. Out of curiousity, what's wrong with the current dll support? 2017-12-29 11:36 GMT+01:00 angel via Digitalmars-d < digitalmars-d puremagic.com>:Built-in tuples: {val1, val2} = func(); On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:I will start: -- Better compiler errors, better compiler errors, better compiler errors. I really wish that the compiler errors could receive some refinement. Mostly it feels like some error text just being thrown at me. It needs to be better formatted, more helpful, with suggestions about how to fix (if possible). To illustrate my point: - See the compile errors I've just encountered with DMD: https://cdn.pbrd.co/images/H0q609l.png - Now compare that with an error produced by rustc: https://cdn.pbrd.co/images/H0q6bLi.png Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.
Dec 29 2017
On 29/12/2017 11:03 AM, maarten van damme wrote:>I'd like to see proper DLL (shared library) support and DIP45 implemented. I'm making a project that I hope in the future will be extendable with D plugins. Out of curiousity, what's wrong with the current dll support?The starting problem is TypeInfo doesn't cross the dll/host binary boundary. Meaning no classes/exceptions.
Dec 29 2017
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:I will start: [...] Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.I casually encountered D issues that i qualified as "major" but with the time passing i don't really care anymore. D has probably reached the point where improving quality has become harder and harder. Improving the quality does not scale linearly and i'd say so what you qualify as "Simple things like these" are harder to accomplish than that you think. the devil is in the details.
Dec 29 2017
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:I will start: -- Better compiler errors, better compiler errors, better compiler errors. I really wish that the compiler errors could receive some refinement. Mostly it feels like some error text just being thrown at me. It needs to be better formatted, more helpful, with suggestions about how to fix (if possible). To illustrate my point: - See the compile errors I've just encountered with DMD: https://cdn.pbrd.co/images/H0q609l.png - Now compare that with an error produced by rustc: https://cdn.pbrd.co/images/H0q6bLi.png Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.This topic was there for so many times. Tuples, async/await, maybe monad (eg. int?), conditional dereferencing qualifier?.identifier, coalescence operator return x ?? 42; better properties, default safety, explicit throw funcs, runtime reflection, ARC instead of GC, so support, ... The community is quite conservative about implementing new stuff in D. Look at for more info: http://forum.dlang.org/thread/sapqaonpjseeykdczmvw forum.dlang.org?page=1 http://forum.dlang.org/thread/ot1q8b$23pt$1 digitalmars.com?page=1 BTW: I decided to make my own language rather than forcing the community to implement something what I would like to see in the lang. https://github.com/Rikarin/Rin
Dec 29 2017
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:I will start:cut...Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.I would like to have a complete and well-defined memory model. And its proper implementation in the compiler.
Dec 29 2017
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:-- Better compiler errors, better compiler errors, better compiler errors.This is the only thing I greatly care about anymore. Biggest problem D has in real world use.
Dec 29 2017
On 12/29/2017 9:29 AM, Adam D. Ruppe wrote:On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:This is not actionable. What is actionable is filing bugzilla enhancement requests with specific examples.-- Better compiler errors, better compiler errors, better compiler errors.This is the only thing I greatly care about anymore. Biggest problem D has in real world use.
Dec 29 2017
On Friday, 29 December 2017 at 21:30:35 UTC, Walter Bright wrote:This is not actionable. What is actionable is filing bugzilla enhancement requests with specific examples.I've done better than that: I've written pull requests. https://github.com/dlang/dmd/pull/6806 There's also existing bugzilla entries such as https://issues.dlang.org/show_bug.cgi?id=7841 These things come up almost every day in user support requests (learn forum, irc, or stack overflow). You want my advice for what to fix on D? Just follow those places and focus on stuff people ask for help on.
Dec 29 2017
On 12/29/2017 2:31 PM, Adam D. Ruppe wrote:On Friday, 29 December 2017 at 21:30:35 UTC, Walter Bright wrote:Thank you!This is not actionable. What is actionable is filing bugzilla enhancement requests with specific examples.I've done better than that: I've written pull requests. https://github.com/dlang/dmd/pull/6806There's also existing bugzilla entries such as https://issues.dlang.org/show_bug.cgi?id=7841That's been closed for a while now.These things come up almost every day in user support requests (learn forum, irc, or stack overflow). You want my advice for what to fix on D? Just follow those places and focus on stuff people ask for help on.As a matter of pragmatism and time management, I give priority to helping people who have expended the effort to document a problem and post it on bugzilla. There's enough there to fill all the time of many people.
Dec 29 2017
On Friday, 29 December 2017 at 23:24:45 UTC, Walter Bright wrote:That's been closed for a while now.Well, take your pick: https://issues.dlang.org/show_bug.cgi?id=12694 https://issues.dlang.org/show_bug.cgi?id=13340 https://issues.dlang.org/show_bug.cgi?id=16059 You always tell people to post to bugzilla, but many of these things have been posted over and over again. Bugzilla search is terrible, so it is frequently hard to find, but there are many examples there. The benefit though of watching support requests is you see what people actually deal with day-to-day, and error messages, especially multiple overload matches of functions and templates and no template matches ones come up all the time. ALL THE TIME. From new users and experienced users alike. Most won't put it in bugzilla though: they just see it as their own personal failure instead of a technical problem we can fix. But any repeated support request should be seen as a user experience problem that we try to fix. This is where we'd get the most productivity - taking little bumps out of the road. D has no roadblocks; we can get a lot of stuff done with it exactly the way it is, but if you watch users actually try to use it, you'll see the road isn't as smooth as it could and should be.
Dec 29 2017
On Saturday, 30 December 2017 at 01:40:39 UTC, Adam D. Ruppe wrote:On Friday, 29 December 2017 at 23:24:45 UTC, Walter Bright wrote:Just curious, why Bugzilla and not something else? I can guess the following: - A centralized place for all dmd, druntime, and phobos was needed. - GitHub issues are probably more limited in features and functionality than Bugzilla. But think about it. Filing a bug on Bugzilla is not friction-free. One has to create an account, if s/he has one already, good luck remembering the username and password for something you rarely use, so spend sometime trying to remember and when you fail, spend time resetting your account or creating a new one. Finally file a bug and pray that someone will actually notice it and triage it to the appropriate owner! Not to mention that Bugzilla's UI is not pleasant. For GitHub issues, most probably you already have an account there that you use often. Issues are close to where the code is. It's easy to see potential owners from the code's blame or git log. .. etc. For better community participation, friction needs to be minimized as much as possible.That's been closed for a while now.Well, take your pick: https://issues.dlang.org/show_bug.cgi?id=12694 https://issues.dlang.org/show_bug.cgi?id=13340 https://issues.dlang.org/show_bug.cgi?id=16059 You always tell people to post to bugzilla, but many of these things have been posted over and over again. Bugzilla search is terrible, so it is frequently hard to find, but there are many examples there. The benefit though of watching support requests is you see what people actually deal with day-to-day, and error messages, especially multiple overload matches of functions and templates and no template matches ones come up all the time. ALL THE TIME. From new users and experienced users alike. Most won't put it in bugzilla though: they just see it as their own personal failure instead of a technical problem we can fix. But any repeated support request should be seen as a user experience problem that we try to fix. This is where we'd get the most productivity - taking little bumps out of the road. D has no roadblocks; we can get a lot of stuff done with it exactly the way it is, but if you watch users actually try to use it, you'll see the road isn't as smooth as it could and should be.
Dec 29 2017
On Saturday, 30 December 2017 at 02:37:24 UTC, IM wrote:Just curious, why Bugzilla and not something else?Bugzilla was the most well-known solution at the time. Keep in mind the D bugzilla has been around since 2006. As far as I understand it, migration at this point is deemed a big pain.
Dec 29 2017
On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe wrote:On Saturday, 30 December 2017 at 02:37:24 UTC, IM wrote:No it wouldn't be a big pain. There are many tools for automatically migrating issues from Bugzilla. The only thing depending on Bugzilla is the changelog generator, but it's API calls to Bugzilla can be replaced with GitHub API calls within an hour. So the entire migration could be easily done in a lot less than a day. The only reason we still use Bugzilla is that the core people are used to it. Here are a couple of the common arguments: 1) Bugzilla is our, we don't want to depend on GitHub The D ecosystem already heavily depends on GitHub. Exporting the issues from GitHub would be easy. Besides there is only one person with access to the Bugzilla server. 2) GitHub only has per registry issues Bugzilla uses components too, they don't support global issues either. Besides if that's required one could easily create a meta repository for such global tasks. 3) Bugzilla's issue tracker is more sophisticated Sure, but does this help when you loose out on many contributors? GitHub even has build tools and sites that let anyone discover "easy" issues if they are labeled accordingly. It's free marketing. FYI I asked the same question 1 1/2 years ago: https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi forum.dlang.org Since then, for example, GitHub got voting for issues, but Bugzilla lost it.Just curious, why Bugzilla and not something else?Bugzilla was the most well-known solution at the time. Keep in mind the D bugzilla has been around since 2006. As far as I understand it, migration at this point is deemed a big pain.
Dec 31 2017
On Sunday, 31 December 2017 at 11:18:26 UTC, Seb wrote:On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe wrote:I wholeheartedly agree. The customer is always right, especially when you're trying to get them to donate their time to an open source project. It's more essential than ever that we lower barriers to participation; if Github issues is the hip new thing all the kids like, then we need to switch to that. We shouldn't be constantly switching to the shiniest new toy, but nor should we stubbornly stick to a piece of software that was built (and it looks it) in '90s. Or at least we should if we're trying to attract the kind of people for whom not using Github is a deal breaker. Older C++/Java programmers likely don't care, but younger Python/Ruby/JS users will.Bugzilla was the most well-known solution at the time. Keep in mind the D bugzilla has been around since 2006. As far as I understand it, migration at this point is deemed a big pain.No it wouldn't be a big pain. There are many tools for automatically migrating issues from Bugzilla. The only thing depending on Bugzilla is the changelog generator, but it's API calls to Bugzilla can be replaced with GitHub API calls within an hour. So the entire migration could be easily done in a lot less than a day. The only reason we still use Bugzilla is that the core people are used to it. Here are a couple of the common arguments: 1) Bugzilla is our, we don't want to depend on GitHub The D ecosystem already heavily depends on GitHub. Exporting the issues from GitHub would be easy. Besides there is only one person with access to the Bugzilla server. 2) GitHub only has per registry issues Bugzilla uses components too, they don't support global issues either. Besides if that's required one could easily create a meta repository for such global tasks. 3) Bugzilla's issue tracker is more sophisticated Sure, but does this help when you loose out on many contributors? GitHub even has build tools and sites that let anyone discover "easy" issues if they are labeled accordingly. It's free marketing. FYI I asked the same question 1 1/2 years ago: https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi forum.dlang.org Since then, for example, GitHub got voting for issues, but Bugzilla lost it.
Dec 31 2017
On Sunday, 31 December 2017 at 19:49:07 UTC, Meta wrote:On Sunday, 31 December 2017 at 11:18:26 UTC, Seb wrote:there are three things that i've noticed: - in this thread, there is not a single positive post by walter. none. nada. zilch. it'd have been much better if he just did not post anything. - d leadership is dusty and so are their tools. we are no js community and hope we never become anything like them but bugzilla is a hundred years old. i am on github, i am on this ml and i also need a bugzilla account? what else do i need to be a part of this community? why can't you provide me a seamless travel in between? have a forum software, allow me to sign in via github and i am a member of the community. but no, they love their ugly bugzilla, they love their mailing list. - has anyone realized we do not attract anyone who has just started to learn programming? what are we going to do about it?On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe wrote:I wholeheartedly agree. The customer is always right, especially when you're trying to get them to donate their time to an open source project. It's more essential than ever that we lower barriers to participation; if Github issues is the hip new thing all the kids like, then we need to switch to that. We shouldn't be constantly switching to the shiniest new toy, but nor should we stubbornly stick to a piece of software that was built (and it looks it) in '90s. Or at least we should if we're trying to attract the kind of people for whom not using Github is a deal breaker. Older C++/Java programmers likely don't care, but younger Python/Ruby/JS users will.Bugzilla was the most well-known solution at the time. Keep in mind the D bugzilla has been around since 2006. As far as I understand it, migration at this point is deemed a big pain.No it wouldn't be a big pain. There are many tools for automatically migrating issues from Bugzilla. The only thing depending on Bugzilla is the changelog generator, but it's API calls to Bugzilla can be replaced with GitHub API calls within an hour. So the entire migration could be easily done in a lot less than a day. The only reason we still use Bugzilla is that the core people are used to it. Here are a couple of the common arguments: 1) Bugzilla is our, we don't want to depend on GitHub The D ecosystem already heavily depends on GitHub. Exporting the issues from GitHub would be easy. Besides there is only one person with access to the Bugzilla server. 2) GitHub only has per registry issues Bugzilla uses components too, they don't support global issues either. Besides if that's required one could easily create a meta repository for such global tasks. 3) Bugzilla's issue tracker is more sophisticated Sure, but does this help when you loose out on many contributors? GitHub even has build tools and sites that let anyone discover "easy" issues if they are labeled accordingly. It's free marketing. FYI I asked the same question 1 1/2 years ago: https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi forum.dlang.org Since then, for example, GitHub got voting for issues, but Bugzilla lost it.
Dec 31 2017
On Sun, 31 Dec 2017 23:50:04 +0000, Mengu wrote:- d leadership is dusty and so are their tools. we are no js community and hope we never become anything like them but bugzilla is a hundred years old. i am on github, i am on this ml and i also need a bugzilla account?That's probably not the best method of effecting change. With the exception of the "Add me to CC list" interface (which is inexcusable) I like Bugzilla. It might be possible to clean things up a bit to better utilize it, but it offers more flexibility than Github's simple issue tracker does (there's a reason Atlassian is able to sell Jira to Bitbucket users even with a tracker integrated into Bitbucket). Druntime and Phobos are so closely integrated that being able to search for issues on both of them at once can be helpful; I would sometimes require two separate searches if they were on Github.
Dec 31 2017
On Monday, 1 January 2018 at 02:02:03 UTC, rjframe wrote:That's probably not the best method of effecting change.It killed off the discussion nicely, indeed. I am just going to share my thoughts a little. Github, in my opinion, is hype and even though I depend on it today, I am trying to decrease that dependency. We should build a world that is not dependent on single companies. I am not downplaying what github has done for us (I am one of the early users) - but they have just become a little too important for free software to be comfortable. The github issue tracker is wanting anyway. D is a great language. I just spent 6 months in C++ and the last month worked on a D multi-threaded project again. I'll blog about this soon, but the short of it is that I am very grateful to Walter, Andrei, Kai, Ian, Johan and others for creating a language that fits our needs so well! D software is doing critical work around the world every second. D is probably not a language for the hype community - let them have Go and Rust. I honestly don't care. And D should not care. Great programmers gyrate to powerful languages and toolboxes. I love I can read the source code of Phobos and understand it. I love I get low level access to stack variables. I love I can manipulate the heap in any way I want. I love we can target GPU and KNL. I love we have Maybe even though it is called Nullable... A great programmer can handle D fine. As it is. Let's not try to be the next hype. Let's keep writing great software. Pj.
Jan 01 2018
On Monday, 1 January 2018 at 18:32:37 UTC, Pjotr Prins wrote:On Monday, 1 January 2018 at 02:02:03 UTC, rjframe wrote:+10000That's probably not the best method of effecting change.It killed off the discussion nicely, indeed. I am just going to share my thoughts a little. Github, in my opinion, is hype and even though I depend on it today, I am trying to decrease that dependency. We should build a world that is not dependent on single companies. I am not downplaying what github has done for us (I am one of the early users) - but they have just become a little too important for free software to be comfortable. The github issue tracker is wanting anyway. D is a great language. I just spent 6 months in C++ and the last month worked on a D multi-threaded project again. I'll blog about this soon, but the short of it is that I am very grateful to Walter, Andrei, Kai, Ian, Johan and others for creating a language that fits our needs so well! D software is doing critical work around the world every second. D is probably not a language for the hype community - let them have Go and Rust. I honestly don't care. And D should not care. Great programmers gyrate to powerful languages and toolboxes. I love I can read the source code of Phobos and understand it. I love I get low level access to stack variables. I love I can manipulate the heap in any way I want. I love we can target GPU and KNL. I love we have Maybe even though it is called Nullable... A great programmer can handle D fine. As it is. Let's not try to be the next hype. Let's keep writing great software.
Jan 02 2018
On Tue, Jan 02, 2018 at 09:57:08AM +0000, Patrick Schluter via Digitalmars-d wrote:On Monday, 1 January 2018 at 18:32:37 UTC, Pjotr Prins wrote:[...]+10000 * 2 T -- It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry FordI am just going to share my thoughts a little. Github, in my opinion, is hype and even though I depend on it today, I am trying to decrease that dependency. We should build a world that is not dependent on single companies. I am not downplaying what github has done for us (I am one of the early users) - but they have just become a little too important for free software to be comfortable. The github issue tracker is wanting anyway. D is a great language. I just spent 6 months in C++ and the last month worked on a D multi-threaded project again. I'll blog about this soon, but the short of it is that I am very grateful to Walter, Andrei, Kai, Ian, Johan and others for creating a language that fits our needs so well! D software is doing critical work around the world every second. D is probably not a language for the hype community - let them have Go and Rust. I honestly don't care. And D should not care. Great programmers gyrate to powerful languages and toolboxes. I love I can read the source code of Phobos and understand it. I love I get low level access to stack variables. I love I can manipulate the heap in any way I want. I love we can target GPU and KNL. I love we have Maybe even though it is called Nullable... A great programmer can handle D fine. As it is. Let's not try to be the next hype. Let's keep writing great software.+10000
Jan 02 2018
On Tuesday, 2 January 2018 at 16:32:50 UTC, H. S. Teoh wrote:On Tue, Jan 02, 2018 at 09:57:08AM +0000, Patrick Schluter via Digitalmars-d wrote:To clarify, I too like D. It is certainly very pleasant to work with. This post wasn't about GitHub issues vs Bugzilla. That was a get-off-at-a-tangent topic. This post is about what's needed for a more mature D; mature enough for extremely big companies to build bigger and more critical parts of their tech stacks in D (this *is* a huge investment)! The goal is never about making D a hype language. I agree, a great programmer can handle anything, not just D as it is, but that's never an excuse to be complacent, it's never an excuse not aim for a higher quality in the D compiler and the infrastructure. Hope you understand. Thanks.On Monday, 1 January 2018 at 18:32:37 UTC, Pjotr Prins wrote:[...]+10000 * 2 TI am just going to share my thoughts a little. Github, in my opinion, is hype and even though I depend on it today, I am trying to decrease that dependency. We should build a world that is not dependent on single companies. I am not downplaying what github has done for us (I am one of the early users) - but they have just become a little too important for free software to be comfortable. The github issue tracker is wanting anyway. D is a great language. I just spent 6 months in C++ and the last month worked on a D multi-threaded project again. I'll blog about this soon, but the short of it is that I am very grateful to Walter, Andrei, Kai, Ian, Johan and others for creating a language that fits our needs so well! D software is doing critical work around the world every second. D is probably not a language for the hype community - let them have Go and Rust. I honestly don't care. And D should not care. Great programmers gyrate to powerful languages and toolboxes. I love I can read the source code of Phobos and understand it. I love I get low level access to stack variables. I love I can manipulate the heap in any way I want. I love we can target GPU and KNL. I love we have Maybe even though it is called Nullable... A great programmer can handle D fine. As it is. Let's not try to be the next hype. Let's keep writing great software.+10000
Jan 03 2018
On Thursday, 4 January 2018 at 05:28:40 UTC, IM wrote:To clarify, I too like D. It is certainly very pleasant to work with. This post wasn't about GitHub issues vs Bugzilla. That was a get-off-at-a-tangent topic. This post is about what's needed for a more mature D; mature enough for extremely big companies to build bigger and more critical parts of their tech stacks in D (this *is* a huge investment)! The goal is never about making D a hype language. I agree, a great programmer can handle anything, not just D as it is, but that's never an excuse to be complacent, it's never an excuse not aim for a higher quality in the D compiler and the infrastructure. Hope you understand. Thanks.D is one of the most interesting and easy to use languages I've seen in a very long time, and I really enjoy 'playing' with it. However...what D needs, IMHO, is a strategy to better handle defects - as opposed to wishfully hoping that something will arise out of the chaos of bugzilla. This is not my area of experise, but, if I were a manager evaluating the merits of D for use in a corporate software project, and then I went off to bugzilla and looked at the items for D.. I'd pause and think.....wtf is going on here. I don't know how other open source projects manage this, or how other mainstream languages manage this, but I would assume there are 'best practices' out there...somewhere. I doubt very much whether just allowing stuff to pile up in some bugzilla repository, is a best practice.
Jan 03 2018
On Thursday, 4 January 2018 at 06:16:45 UTC, codephantom wrote:I doubt very much whether just allowing stuff to pile up in some bugzilla repository, is a best practice.Several bugs get wiped in each release, as the changelogs clearly show. It's not as if they're being ignored. If you know how to get a bunch of volunteers with such varied interests to work in a concerted direction, please do tell. And I'm not being facetious here. There have been attempts in the past to bring some sort of order to the chaos so that the perception matches the reality, but it's not something that has yet proven sustainable. As a result, bugs that no one steps up to fix get left in bugzilla for ages. I have an idea I'm working on to potentially help get older bugs squashed and older PRs merged. I need to hash out the details before getting it going, but I'll blog about when (and if) it comes to fruition. There are no guarantees it will be effective, but it's worth a shot. In the meantime, you could help reduce the pile by picking a bug to fix today. Multiple people, particularly those concerned about the number of old issues still open, who donate one or two days a month to fixing old bugs could go along way. The same goes for reviewing PRs.
Jan 03 2018
On Thursday, 4 January 2018 at 06:39:24 UTC, Mike Parker wrote:If you know how to get a bunch of volunteers with such varied interests to work in a concerted direction, please do tell.This is the mystery behind everything in the universe. Why haven't you solved it yet?
Jan 03 2018
On Thursday, 4 January 2018 at 06:39:24 UTC, Mike Parker wrote:I have an idea I'm working on to potentially help get older bugs squashed and older PRs merged. I need to hash out the details before getting it going, but I'll blog about when (and if) it comes to fruition. There are no guarantees it will be effective, but it's worth a shot.I think this might also be a good project for one of Andrei's students ;-) i.e a detailed analysis of D's bugzilla repository. Present the findings and recommendations.In the meantime, you could help reduce the pile by picking a bug to fix today. Multiple people, particularly those concerned about the number of old issues still open, who donate one or two days a month to fixing old bugs could go along way. The same goes for reviewing PRs.I'm too much of 'big picture' person to get into such details ;-) Fortunately, not all are like me ;-) The problem, I suspect, is more to do with people wanting to contribute to things that matter most, and, that their contribution will be considered in a timely manner, by people with suitable expertise. If such a process exists, I am not aware of it. I don't think just saying to people, 'go and find some bug that interests you' is sufficient to get people motivated, IMHO.
Jan 03 2018
On Thu, Jan 04, 2018 at 06:39:24AM +0000, Mike Parker via Digitalmars-d wrote: [...]In the meantime, you could help reduce the pile by picking a bug to fix today. Multiple people, particularly those concerned about the number of old issues still open, who donate one or two days a month to fixing old bugs could go along way. The same goes for reviewing PRs.[...] Back when I had more free time, I used to trawl bugzilla for low-numbered bugs to find low-hanging fruit to fix. It's not hard to setup various prebaked custom queries that allow me to, for example, find all bugs 1 month / 2 months / 1 year / 2-5 years old with just one mouse click. Bugzilla is actually highly configurable and can be made to do quite useful things, as long as people get past the fallacious preconception that no eye candy == lousy. Over time, at least while I was active, I have noticed that the number of trivial bugs has shrunk significantly, and most of the lingering old issues are the ones that are actually very difficult to fix. So the talk about stuff rotting in bugzilla and forgotten is mostly unfounded speculation of people who haven't even bothered to look deeper than the superficial appeatance, rather than a reflection of reality. Nowadays I've less time to trawl through bugzilla but every now and then an issue comes up that can be fixed in the few spare minutes that I have, and I still try to contribute when I can. And I've noticed that the number of bugs fixed per release seems to have increased, so progress *is* being made in this area. What's lacking right now is more people to direct more energy to fixing bugs and reviewing PRs rather than wasting that energy complaining in the forums. For the sheer amount of energy spent arguing on the forum, so many more bugs could have been fixed, and so many more PRs reviewed. We don't even require you to have commit access in order to be able to give useful feedback to a PR. I don't know how much lower the barrier can get. Heck, *I* got commit access because I was actively submitting and reviewing Phobos PRs as a non-committer. It all comes down to who's doing the actual work vs. who's just telling others what they think they should be doing, which rarely, if ever, works. T -- Don't get stuck in a closet---wear yourself out.
Jan 03 2018
On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:[...]I'm missing Kenji...
Jan 04 2018
On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:It all comes down to who's doing the actual work vs. who's just telling others what they think they should be doing, which rarely, if ever, works.I think that view really needs to be challenged. Those who might be willing to contribute are probably not sitting around waiting for someone to tell them what to do. On the other hand, there may be legitmate reasons why they are not just getting involved and doing things. I suspect, and I could be wrong, that a lack of clear process could be a matter of concern. I also suspect, and I could be wrong, that working out where best to exert their effort is not as simple as just finding something that interest them. I also expect, that not everyone using D, or using these forums, need to be, or are equipped to be, contributors to resolving D's bugs. Such people should still feel free to express their concerns, without being told that they should go and do something. Software quality is more important than ever, as it can impact us in dramatic ways these days. D needs to have quality assurance process in place to ensure that D's repository of bugs are appropriately being assessed, categorised, prioritised, and actioned - and this needs to evident to all. Then and only then, wil willing contributors be better positioned to make decisions about where to exert their effort. I see this a problem for the D Foundation to address, and not something left up to the randomness of the open source development model. btw. (although I don't see this as 'the' solution)... I do like this idea of labeling stuff more clearly.. http://issuehub.io/label-guide
Jan 04 2018
On Thu, 04 Jan 2018 06:16:45 +0000, codephantom wrote:This is not my area of experise, but, if I were a manager evaluating the merits of D for use in a corporate software project, and then I went off to bugzilla and looked at the items for D.. I'd pause and think.....wtf is going on here. I don't know how other open source projects manage this, or how other mainstream languages manage this, but I would assume there are 'best practices' out there...somewhere. I doubt very much whether just allowing stuff to pile up in some bugzilla repository, is a best practice.At the time of writing: Ansible has 3391 open bugs[1] (and ~master is often used in production). Python has more than 6000, 2000+ with patches[2]. GCC (C and C++ components only) has 3119[3]. Bugs are part of software. That's just life. It doesn't mean the software is unreliable/unusable, just that it can be better. [1]: https://github.com/ansible/ansible/issues [2]: https://bugs.python.org/issue? template=stats [3]: https://gcc.gnu.org/bugzilla/report.cgi? x_axis_field=&y_axis_field=bug_status&z_axis_field=&no_redirect=1&query_format=report- table&short_desc_type=allwordssubstr&short_desc=&product=gcc&component=c&component=c %2B% 2B&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&cf_gcchost_type=allwordssubstr&cf_gcchost=&cf_gcctarget_type=allwordssubstr&cf_gcctarget=&cf_gccbuild_type=allwordssubstr&cf_gccbuild=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1=&format=table&action=wrap
Jan 04 2018
On Thursday, 4 January 2018 at 12:11:36 UTC, rjframe wrote:At the time of writing: Ansible has 3391 open bugs[1] (and ~master is often used in production). Python has more than 6000, 2000+ with patches[2]. GCC (C and C++ components only) has 3119[3]. Bugs are part of software. That's just life. It doesn't mean the software is unreliable/unusable, just that it can be better.Whether D is usable, reliable or whatever was not my argument. My argument is more broader, and is about how an opensource project, like D for example, looks out for the interests of its users. i.e quality assurance. 1000's of bugs suggest to me, a lack of QA. A lack of QA suggests to me, a lack of concern for the interests of users. There are numerous research papers in this area, some of which I am in the process of reading, to gain a better understanding of QA in open source projects - and apparently it's a real issue of concern to those researching this topic. Anyway, as I go through these research papers, I suspect that it is unlikely they will conclude that bugs are just a part of software, and that's just life.. and least.. I hope not.
Jan 04 2018
On Thursday, 4 January 2018 at 12:11:36 UTC, rjframe wrote:Python has more than 6000, 2000+ with patches[2].Most appears to be library related or improvement requests… I don't think numbers is the right metric. Tools with as many users as Python will get a lot of issues reported irrespective of severity or frequency.
Jan 05 2018
On Sunday, December 31, 2017 11:18:26 Seb via Digitalmars-d wrote:On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe wrote:I honestly am unaware of any reason why using github issues would be superior to bugzilla except that some folks expect projects on github to use github issues for bug reports. And plenty of projects on github don't use github issues. If we were starting from scratch, then maybe it would make sense to use github issues instead of our own bugzilla, but given that we already have bugzilla, it works just fine, and github issues really don't seem to offer anything significant that would make them superior to using bugzilla, I really don't see any reason to switch.On Saturday, 30 December 2017 at 02:37:24 UTC, IM wrote:No it wouldn't be a big pain. There are many tools for automatically migrating issues from Bugzilla. The only thing depending on Bugzilla is the changelog generator, but it's API calls to Bugzilla can be replaced with GitHub API calls within an hour. So the entire migration could be easily done in a lot less than a day. The only reason we still use Bugzilla is that the core people are used to it. Here are a couple of the common arguments:Just curious, why Bugzilla and not something else?Bugzilla was the most well-known solution at the time. Keep in mind the D bugzilla has been around since 2006. As far as I understand it, migration at this point is deemed a big pain.1) Bugzilla is our, we don't want to depend on GitHub The D ecosystem already heavily depends on GitHub. Exporting the issues from GitHub would be easy. Besides there is only one person with access to the Bugzilla server.Yes, it would be a pain to switch away from github at this point, but if github went down permanently tomorrow, it would just be an annoying roadblock. We almost certainly wouldn't lose any code (at most, a few commits, if no one pulled recently enough), and we wouldn't lose any bug reports. We'd have to go to the trouble of setting up our own gitlab or switching to bitbucket or something like that and pointing all of the automated stuff to the new place, and it would be a royal pain, but we wouldn't lose any information. If all of the issues were on github, and github went away, we'd lose them. Sure, github is unlikely to go away, but I see no reason to tie ourselves to it thoroughly enough that we're going to lose data if they go away - especially since I don't actually see any benefit in switching to github issues.2) GitHub only has per registry issues Bugzilla uses components too, they don't support global issues either. Besides if that's required one could easily create a meta repository for such global tasks.Well, it wouldn't be the end of the world if the issues were separated by repos, but having them in a single place where they can be searched together is beneficial, and it makes it easier to switch an issue between components when it turns out that it was assigned to the wrong component. Certainly, switching to github would be negative in this regard, even if it wouldn't be a deal breaker.3) Bugzilla's issue tracker is more sophisticated Sure, but does this help when you loose out on many contributors? GitHub even has build tools and sites that let anyone discover "easy" issues if they are labeled accordingly. It's free marketing.I seriously doubt that we've lost many (if any) contributors because we don't use github issues, and plenty of other projects use github without using it as their issue tracker.FYI I asked the same question 1 1/2 years ago: https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi forum.dlang.org Since then, for example, GitHub got voting for issues, but Bugzilla lost it.To be honest, no one seems to pay attention to voting on issues. Having a voting system is theoretically beneficial, but in practice, it doesn't seem to have generally had much effect on what gets fixed (not for us anyway). Almost inevitably, the stuff that actually gets many votes is the hard stuff that is likely to be sitting around whether folks vote on it or not. Plenty of those issues really should be fixed sooner, but having a lot of votes on everyone agreeing that it needed to be fixed, because it a was a hard problem, and no one stepped up to the plate to take care of it. The fact that it had a bunch of votes really didn't matter. In any case, I have yet to see much on argument for why we would even want to switch to github issues. It just seems like some folks think that for some reason, the fact that we have our code up on github means that we should have our issue tracker there too and that it's weird that we don't. Personally, I don't see any reason to go to the trouble of searching and invalidating years worth of links just because using github issues seems to be the hip thing to do. It needs to provide serious value over using our own bugzilla, and I am unaware of anything that it does that is significantly better than using bugzilla. - Jonathan M Davis
Dec 31 2017
On Sun, 31 Dec 2017 17:19:22 -0700, Jonathan M Davis wrote:Yes, it would be a pain to switch away from github at this point, but if github went down permanently tomorrow, it would just be an annoying roadblock. We almost certainly wouldn't lose any code (at most, a few commits, if no one pulled recently enough), and we wouldn't lose any bug reports. We'd have to go to the trouble of setting up our own gitlab or switching to bitbucket or something like that and pointing all of the automated stuff to the new place, and it would be a royal pain, but we wouldn't lose any information. If all of the issues were on github, and github went away, we'd lose them. Sure, github is unlikely to go away, but I see no reason to tie ourselves to it thoroughly enough that we're going to lose data if they go away - especially since I don't actually see any benefit in switching to github issues.If only one person has access to Bugzilla, we're actually at a greater risk now than if we used Github for issues. If we don't have regular backups to a location accessible to multiple members of the core team, we shouldn't consider Bugzilla to be a reliable data repository. --Ryan
Dec 31 2017
Creating a bugzilla account takes a couple minutes. It is enough friction to serve as a reasonable filter against spammers and junk postings. It's not like we have a shortage of bugzilla issues and are wondering what to do next. It's working well enough for those who care enough to make an effort.
Dec 29 2017
On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright wrote:It's not like we have a shortage of bugzilla issues and are wondering what to do next.Yah there are a ton of Bugzilla issues, that's the problem. More than half of them aren't "actionable" as you put it. Here's the problem, look at something like Rust: Pull requests? 95 open, it's about the same as Dlang, But if you go to the last page... https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen Look at that the oldest one is from October 15th, 20_17_. Now we go to DMD... https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen Oldest one is from January 17, 20_13_. In contrast this same problem exists for Bugzilla. You say it's working cause it's better than using notepad or some other stupid shit. Bugzilla isn't the issue, it's the fact the people maintaining it aren't willing to commit to anything and leave issues open that shouldn't be left open. That just results in noise making it difficult to see what actual issues are. I'm not even talking about duplicate entries as you seem to have have misunderstood.
Dec 30 2017
On 30 December 2017 at 15:42, Muld via Digitalmars-d <digitalmars-d puremagic.com> wrote:On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright wrote:There's nothing unmanageable about the issue tracker, nor are the number of open bugs even a reliable measure of anything. For instance, Python has more than twice as many open bugs than D.It's not like we have a shortage of bugzilla issues and are wondering what to do next.Yah there are a ton of Bugzilla issues, that's the problem. More than half of them aren't "actionable" as you put it.Here's the problem, look at something like Rust: Pull requests? 95 open, it's about the same as Dlang, But if you go to the last page... https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen Look at that the oldest one is from October 15th, 20_17_. Now we go to DMD... https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen Oldest one is from January 17, 20_13_.Hey, I take offence to that. https://issues.dlang.org/show_bug.cgi?id=17839 https://github.com/dlang/dmd/pull/7503 https://github.com/dlang/dmd/pull/7508 https://github.com/dlang/dmd/pull/7509 https://github.com/dlang/dmd/pull/7510 https://github.com/dlang/dmd/pull/7527 https://github.com/dlang/dmd/pull/7536 And many more closed that were even older, and I'm not the only one reviving these patches, all of which are either abandoned, incomplete, or too controversial (there is always a valid reason why open PRs were left to rot).In contrast this same problem exists for Bugzilla. You say it's working cause it's better than using notepad or some other stupid shit. Bugzilla isn't the issue, it's the fact the people maintaining it aren't willing to commit to anything and leave issues open that shouldn't be left open. That just results in noise making it difficult to see what actual issues are. I'm not even talking about duplicate entries as you seem to have have misunderstood.All open issues are actionable, and require some action. They are not noise, and many issues whose fix requires a change in language specification or semantics are understandably left to the few who have the authoritative to make such final decisions on whether it should be accepted or rejected. Age of issue is not a big deal. In fact I see it as a good sign that at least issues are left to breathe while we wait and understand the impact or urgency of it. As opposed to jumping in and fixing issues immediately without taking due diligence on the wider picture it affects.
Dec 30 2017
On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote:All open issues are actionable, and require some action. They are not noise, and many issues whose fix requires a change in language specification or semantics are understandably left to the few who have the authoritative to make such final decisions on whether it should be accepted or rejected. Age of issue is not a big deal. In fact I see it as a good sign that at least issues are left to breathe while we wait and understand the impact or urgency of it. As opposed to jumping in and fixing issues immediately without taking due diligence on the wider picture it affects.Is this a problem with triage? i.e. like a hositpital emergency ward chaos rules, cause nobody is on duty triaging. How does a contributor prioritise their contribution to items in bugzilla? Or is it perhaps a tooling problem? (i.e. bugzilla lacks features that are needed). Or is it a problem with not having enough people on duty, triaging? Or is it a problem with just too many patients coming in? Or .. ??
Dec 30 2017
On 31 December 2017 at 02:07, codephantom via Digitalmars-d <digitalmars-d puremagic.com> wrote:On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote:Either: 1. By picking up an issue that you have a vested interest in seeing fixed. 2. Feel free to look at the list of regressons. https://issues.dlang.org/buglist.cgi?bug_severity=regression&component=dmd&list_id=218477&query_format=advanced&resolution=--- Bigger projects or features are delegated between the core maintainers, or if a champion comes to take the reigns, then they have the freedom to go ahead. For everything else, it is pretty much a free-for-all in terms of what you want to get fixed. Almost nobody is being paid to contribute to the language here.All open issues are actionable, and require some action. They are not noise, and many issues whose fix requires a change in language specification or semantics are understandably left to the few who have the authoritative to make such final decisions on whether it should be accepted or rejected. Age of issue is not a big deal. In fact I see it as a good sign that at least issues are left to breathe while we wait and understand the impact or urgency of it. As opposed to jumping in and fixing issues immediately without taking due diligence on the wider picture it affects.Is this a problem with triage? i.e. like a hositpital emergency ward chaos rules, cause nobody is on duty triaging. How does a contributor prioritise their contribution to items in bugzilla?
Dec 30 2017
On Sunday, 31 December 2017 at 02:06:03 UTC, Iain Buclaw wrote:2. Feel free to look at the list of regressons. https://issues.dlang.org/buglist.cgi?bug_severity=regression&component=dmd&list_id=218477&query_format=advanced&resolution=---"This list is too long for Bugzilla's little mind" Mmm..just imagine how our human mind reacts then ;-) But... as you point out...some 'filtering' makes it 'seem' a little less daunting ;-)
Dec 30 2017
On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote:Hey, I take offence to that. https://issues.dlang.org/show_bug.cgi?id=17839 https://github.com/dlang/dmd/pull/7503 https://github.com/dlang/dmd/pull/7508 https://github.com/dlang/dmd/pull/7509 https://github.com/dlang/dmd/pull/7510 https://github.com/dlang/dmd/pull/7527 https://github.com/dlang/dmd/pull/7536 And many more closed that were even older, and I'm not the only one reviving these patches, all of which are either abandoned, incomplete, or too controversial (there is always a valid reason why open PRs were left to rot).I haven't been looking recently. At least there's one vigilante working in the shadows, doing the things no one else is willing to.
Dec 31 2017
On 12/30/2017 6:42 AM, Muld wrote:In contrast this same problem exists for Bugzilla. You say it's working cause it's better than using notepad or some other stupid shit. Bugzilla isn't the issue, it's the fact the people maintaining it aren't willing to commit to anything and leave issues open that shouldn't be left open. That just results in noise making it difficult to see what actual issues are. I'm not even talking about duplicate entries as you seem to have have misunderstood.Anyone can contribute to bugzilla with reasoned advice about what to do with various issues, and can review PRs. The people responsible are, well, anyone who wants to be. Please join and help out.
Dec 30 2017
On Sunday, 31 December 2017 at 05:43:57 UTC, Walter Bright wrote:On 12/30/2017 6:42 AM, Muld wrote:While we are discussing it here, could you please let me know what the bug triage process for each release cycle is? Is it random that anyone picks up whatever bug s/he feels like fixing? Or is it that if contributors will contribute X number of patches this cycle, then there is some sort of guidance and direction of this effort towards fixing some high priority bugs?In contrast this same problem exists for Bugzilla. You say it's working cause it's better than using notepad or some other stupid shit. Bugzilla isn't the issue, it's the fact the people maintaining it aren't willing to commit to anything and leave issues open that shouldn't be left open. That just results in noise making it difficult to see what actual issues are. I'm not even talking about duplicate entries as you seem to have have misunderstood.Anyone can contribute to bugzilla with reasoned advice about what to do with various issues, and can review PRs. The people responsible are, well, anyone who wants to be. Please join and help out.
Dec 30 2017
On 12/30/2017 11:23 PM, IM wrote:While we are discussing it here, could you please let me know what the bug triage process for each release cycle is? Is it random that anyone picks up whatever bug s/he feels like fixing? Or is it that if contributors will contribute X number of patches this cycle, then there is some sort of guidance and direction of this effort towards fixing some high priority bugs?Bugs are ranked by severity, but generally what gets fixed are bugs that a particular person self-selects an interest in fixing it. Often people who just want to help out will peruse the buglist looking for issues that match their skill levels that they can fix.
Dec 30 2017
On Sunday, 31 December 2017 at 07:43:35 UTC, Walter Bright wrote:On 12/30/2017 11:23 PM, IM wrote:I hope that you could see that this doesn't scale very well, and some kind of a process needs to be established to shape and direct the efforts. Some thoughts/suggestions: - Weekly meeting to review open bugs, adjust their components and priority appropriately, and assign to potential owners (those who can or likely to fix the bugs. Owners can then reassign or unassign if not interested). - Maybe ask someone to volunteer for triaging bugs in each component. So every component has an owner. - If a bug has been assigned to someone and hasn't received any attention (i.e. remained open for say 3 months), a bot should unassign it so that it returns back to the triage pool, hoping that it will catch the attention of the triage volunteers. What do you think? Do you agree that a process is needed?While we are discussing it here, could you please let me know what the bug triage process for each release cycle is? Is it random that anyone picks up whatever bug s/he feels like fixing? Or is it that if contributors will contribute X number of patches this cycle, then there is some sort of guidance and direction of this effort towards fixing some high priority bugs?Bugs are ranked by severity, but generally what gets fixed are bugs that a particular person self-selects an interest in fixing it. Often people who just want to help out will peruse the buglist looking for issues that match their skill levels that they can fix.
Dec 31 2017
On 12/31/2017 8:18 AM, IM wrote:What do you think? Do you agree that a process is needed?We've tried adding process before. It does not work, for the simple reason that it requires a dedicated group of people to dedicate time to it. Are you willing to do that? We have added process when someone has stepped up to do the thankless job of administering it.
Dec 31 2017
On Sunday, 31 December 2017 at 21:16:35 UTC, Walter Bright wrote:On 12/31/2017 8:18 AM, IM wrote:Well, I've spent the last few months just learning the language, debating issues on this forum, and fending off the occasional attack. This is probably what most newcomers will go through too.. For the most part, I think D is a really nice language to 'play' with, and thanks to all those that have made it happen. Now as I think about moving from just playing with D, to making serious use of it, this lack of 'process' you mention, could become a real deal breaker. The D Foundation should take this matter very seriously, in my opinion, and invest in process, rather than just hoping it will emerge out of the chaos of bugzilla. By not focusing your attention on this more, I believe you risk a lot of people refusing to contribute to D, and even turning away from D. You also risk fragmentation in the D community. Now, that asisde, happy New Year to you, and all. Lets' make it a great year to advance D even further...What do you think? Do you agree that a process is needed?We've tried adding process before. It does not work, for the simple reason that it requires a dedicated group of people to dedicate time to it. Are you willing to do that? We have added process when someone has stepped up to do the thankless job of administering it.
Dec 31 2017
On Sunday, 31 December 2017 at 21:16:35 UTC, Walter Bright wrote:On 12/31/2017 8:18 AM, IM wrote:Something should work. It just needs to be found. People are already dedicating time to D by contributing fixes and filing issues, responding on the forums, ... etc. Organizing work and priorities is not an exception. It doesn't take that long by the way, only 30 ~ 60 minutes per week max should be more than enough. I hope you could take the upcoming DConf as an opportunity to discuss with others ways to enhance the process and minimize friction.What do you think? Do you agree that a process is needed?We've tried adding process before. It does not work, for the simple reason that it requires a dedicated group of people to dedicate time to it.Are you willing to do that?I'd be happy to do it, but I'm not the right person for it. This needs someone who knows D very well, knows the bigger picture, and is familiar with the contributors and who mostly works on what to be able to adjust priorities and ownership appropriately. I've been learning and experimenting with D only for a few months. Also, I'm worried about - though unlikely - to put myself in a conflict-of-interest situation; we don't use D at work, and as far as I know there are neither interest nor plans to do so. I hope this will change one day, and that's why I started this post, because quality and maturity are very important.We have added process when someone has stepped up to do the thankless job of administering it.I think it is thankful and as important as submitting PRs and DIPs. Shaping, organizing, and directing human effort are just as important as the human effort itself.
Jan 01 2018
On Sunday, 31 December 2017 at 05:43:57 UTC, Walter Bright wrote:Please join and help out.I already have, and like I said there are problems with with the current system. I don't feel like helping anymore cause anything time I do my work just get dumped, and I've simply wasted my time.Bugs are ranked by severity, but generally what gets fixed are bugs that a particular person self-selects an interest in fixing it. Often people who just want to help out will peruse the buglist looking for issues that match their skill levels that they can fix.You've just admitted to the problem. And those that want to "help out" will "persue the buglist looking for issues". Then you drop this quote, "it's fine for those that want to put in a wasteful time of effort, cause they care enough".It's working well enough for those who care enough to make an effort.Fix your shit if you want help, it's broken and just wastes people's time. Saying that people don't care enough is not helping with a solution.
Dec 31 2017
On 12/31/2017 12:53 PM, Muld wrote:Fix your shitA word to the wise. Being rude will just get you ignored by most everyone on this n.g. We insist on professional demeanor and courtesy at all times. Egregious behavior will get posts unceremoniously removed.
Dec 31 2017
On Sunday, 31 December 2017 at 20:53:37 UTC, Muld wrote:...Stop making noise except one-day you make another well-known language popular in the world called E. What a kind of people who you are ? and can make such a noise to well known and famous person who made such a great language? And, everyone who's making noise just stop. If you don't like D, just go to Go or Rust. The community is just kindly making opensource project which means they are contributing times and life to the human. and what you do except making noise? And Dear Walter is working for D all the time, Didn't anyone seen he is merging PRs on github? So, let's be calm and graceful, that is if you consider there's problem, just fix it. Or provides more detailed information for the core team to fix it. Not just saying "D is bad on this or that". And at least, keep polite if you're not a guy like Bill Gates or Jobs.
Jan 05 2018
On Saturday, 30 December 2017 at 14:42:45 UTC, Muld wrote:On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright wrote:This is a problem that many of us are working on fixing. The main reason many of these old zombie PRs stick around is that historically, people are hesitant to close things (for a variety of social reasons, I feel). While there is still the slightest chance that something might someday be merged, it is kept open. Rust is a lot more aggressive about closing bad or outdated PRs and either guiding PRs that need work to get to a mergeable state, or closing them and communicating that this is not the correct way to go. I watched a talk by a Rust contributor specifically on this point awhile ago - they have a bot that does a lot of the PR closure work to get around the fact that people are hesitant to be the "bad guy" and tell someone that their work is not good enough. D needs to get much better at this, and I think things are happening - slowly. The bad optics and demoralizing effect of letting things sit forever without definitive action outweighs the potential loss from being more aggressive about closing or merging.It's not like we have a shortage of bugzilla issues and are wondering what to do next.Yah there are a ton of Bugzilla issues, that's the problem. More than half of them aren't "actionable" as you put it. Here's the problem, look at something like Rust: Pull requests? 95 open, it's about the same as Dlang, But if you go to the last page... https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen Look at that the oldest one is from October 15th, 20_17_. Now we go to DMD... https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen Oldest one is from January 17, 20_13_.
Dec 31 2017
On Sunday, 31 December 2017 at 09:37:35 UTC, Meta wrote:On Saturday, 30 December 2017 at 14:42:45 UTC, Muld wrote:Yes, Dlang-bot was able to detect stalled issues for a while, but we didn't turn this on for all repositories. I have just enabled it: https://github.com/dlang-bots/dlang-bot/pull/153 For the moment, it is just labelling issues with e.g. "needs work", "needs rebase", "stalled", "stalled-stable". In a next stage it will start to actively ping people or close PRs. Also automatically rebasing PRs if there are no conflicts is on the radar (the GitHub UI is quite conservative in this regard).On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright wrote:This is a problem that many of us are working on fixing. The main reason many of these old zombie PRs stick around is that historically, people are hesitant to close things (for a variety of social reasons, I feel). While there is still the slightest chance that something might someday be merged, it is kept open. Rust is a lot more aggressive about closing bad or outdated PRs and either guiding PRs that need work to get to a mergeable state, or closing them and communicating that this is not the correct way to go. I watched a talk by a Rust contributor specifically on this point awhile ago - they have a bot that does a lot of the PR closure work to get around the fact that people are hesitant to be the "bad guy" and tell someone that their work is not good enough. D needs to get much better at this, and I think things are happening - slowly. The bad optics and demoralizing effect of letting things sit forever without definitive action outweighs the potential loss from being more aggressive about closing or merging.It's not like we have a shortage of bugzilla issues and are wondering what to do next.Yah there are a ton of Bugzilla issues, that's the problem. More than half of them aren't "actionable" as you put it. Here's the problem, look at something like Rust: Pull requests? 95 open, it's about the same as Dlang, But if you go to the last page... https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen Look at that the oldest one is from October 15th, 20_17_. Now we go to DMD... https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen Oldest one is from January 17, 20_13_.
Dec 31 2017
On Sunday, 31 December 2017 at 11:27:41 UTC, Seb wrote:Yes, Dlang-bot was able to detect stalled issues for a while, but we didn't turn this on for all repositories. I have just enabled it: https://github.com/dlang-bots/dlang-bot/pull/153 For the moment, it is just labelling issues with e.g. "needs work", "needs rebase", "stalled", "stalled-stable". In a next stage it will start to actively ping people or close PRs. Also automatically rebasing PRs if there are no conflicts is on the radar (the GitHub UI is quite conservative in this regard).Awesome. Thanks for all your hard work on the automation side of things, by the way. It's not glamorous but it's a huge force multiplier.
Dec 31 2017
On 12/29/2017 5:40 PM, Adam D. Ruppe wrote:[...]PRs to fix bugzilla issues get submitted every day. I don't see a better way. I can't monitor every forum, I rely on you and others to do so and submit the issues.
Dec 29 2017
On Friday, 29 December 2017 at 21:30:35 UTC, Walter Bright wrote:On 12/29/2017 9:29 AM, Adam D. Ruppe wrote:Bugzilla is a huge mess tbh, creating a request in bugzilla won't lead anywhere. There's so many pointless entries in there people have to waste their time looking through just to see what is and isn't "actionable" (as you put it). I was thinking of making a senseless entry that had some fake example code and see how long it would take for the entry to be closed/removed. Something tells me it would never be closed/removed. The barrier for what constitutes a bugzilla entry and why it can remain open should be stricter. For example anything that is an "enhancement" and would require a DIP should not remain open. Bugzilla shouldn't be a "wishlist" for Dlang. This just adds needless bloat, what's worse is when an enchantment is not labelled that it needs a DIP and someone goes wasting their time implementing it. It's so bad honestly it'd probably be less work just to create a new bugzilla and port any relevant entries from the current one.On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:This is not actionable. What is actionable is filing bugzilla enhancement requests with specific examples.-- Better compiler errors, better compiler errors, better compiler errors.This is the only thing I greatly care about anymore. Biggest problem D has in real world use.
Dec 29 2017
On 12/29/2017 3:15 PM, Muld wrote:Bugzilla is a huge mess tbh, creating a request in bugzilla won't lead anywhere.Fixes for bugzilla issues are posted on github nearly every day.It's so bad honestly it'd probably be less work just to create a new bugzilla and port any relevant entries from the current one.It's not a big deal to create a duplicate of existing entries. As to bugzilla itself, despite its issues, it is far far far better and more organized than randomly looking in chat rooms, stack overflow, newsgroups, etc.
Dec 29 2017
On Friday, 29 December 2017 at 23:27:38 UTC, Walter Bright wrote:On 12/29/2017 3:15 PM, Muld wrote:This does not mean anything, just cause fixes for Bugzilla issues are being fixed "nearly every day" is not part of the larger problem. The people that are pushing fixes for those issues tend to be the same people that are creating them. Sure I can create a bugzilla issue, but unless I'm the one that creates a fix for it, it probably won't be fixed unless it is a regression.Bugzilla is a huge mess tbh, creating a request in bugzilla won't lead anywhere.Fixes for bugzilla issues are posted on github nearly every day.Living on Mars is far far better than trying to live on the surface of the Sun. Just cause that's the case doesn't mean you should stop looking for a place called Earth.It's so bad honestly it'd probably be less work just to create a new bugzilla and port any relevant entries from the current one.It's not a big deal to create a duplicate of existing entries. As to bugzilla itself, despite its issues, it is far far far better and more organized than randomly looking in chat rooms, stack overflow, newsgroups, etc.
Dec 30 2017
On Friday, 29 December 2017 at 17:29:47 UTC, Adam D. Ruppe wrote:On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:Please allow me to give an example of how first impressions of maturity really matter! Recently at some company, a group of engineers started advocating for using Rust. They wrote a doc explaining the differences and benefits of Rust over C++ (which is heavily used). People started experimenting, and immediately the maturity and good user experience of rustc and cargo were quite obvious. The result was that Rust is now more appealing, some new projects were written in Rust, some old ones have or are being migrated from C++ to Rust. (**This is a real story by the way**) Now, given the fact that I love D despite some of the annoying issues I encounter with it frequently, I would like to call my colleagues to give it a try and experiment with it. People start getting interested. They start writing some code, and eventually they hit one of those unhelpful compile error messages, which could indicate one of the following: - An error in the engineer's knowledge of the language which the compiler didn't help to understand what it is so that s/he goes to look it up. - A bug in Phobos. - An actual compiler bug or inconsistency. Remember, those engineers are experimenting with D to use it for serious projects at work, not personal toy projects. What do you think? Is it likely that they decide to invest a lot of time and resources migrating projects to D? Maturity (or at least approaching it as much as possible) is VERY VERY VERY important. I like what the D foundation did to the website, the language and library docs, the Learn section, the forums, the resources ... etc. That definitely gives the impression of maturity. Looking forward to seeing more of that in the compiler, which is the single most important thing in a programming language, the reason it exists, the thing I interface with most of the time.-- Better compiler errors, better compiler errors, better compiler errors.This is the only thing I greatly care about anymore. Biggest problem D has in real world use.
Dec 29 2017
On 12/29/2017 7:07 PM, IM wrote:They start writing some code, and eventually they hit one of those unhelpful compile error messages, which could indicate one of the following: - An error in the engineer's knowledge of the language which the compiler didn't help to understand what it is so that s/he goes to look it up. - A bug in Phobos. - An actual compiler bug or inconsistency.I'm sorry, there is literally nothing I can do with that. To get action, you need to be specific.
Dec 29 2017
On 12/30/2017 04:07 AM, IM wrote:I like what the D foundation did to the website, the language and library docs, the Learn section, the forums, the resources ... etc. That definitely gives the impression of maturity.As far as I'm aware, the foundation isn't too active in those areas; unless Vladimir or Seb are on their payroll now. Maybe the foundation pays the electricity bills, but the work is done by volunteers.
Dec 30 2017
On Saturday, 30 December 2017 at 03:07:57 UTC, IM wrote:On Friday, 29 December 2017 at 17:29:47 UTC, Adam D. Ruppe wrote:On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:Please allow me to give an example of how first impressions of maturity really matter! Recently at some company, a group of engineers started advocating for using Rust. They wrote a doc explaining the differences and benefits of Rust over C++ (which is heavily used). People started experimenting, and immediately the maturity and good user experience of rustc and cargo were quite obvious. The result was that Rust is now more appealing, some new projects were written in Rust, some old ones have or are being migrated from C++ to Rust. (**This is a real story by the way**) Now, given the fact that I love D despite some of the annoying issues I encounter with it frequently, I would like to call my colleagues to give it a try and experiment with it. People start getting interested. They start writing some code, and eventually they hit one of those unhelpful compile error messages, which could indicate one of the following: - An error in the engineer's knowledge of the language which the compiler didn't help to understand what it is so that s/he goes to look it up. - A bug in Phobos. - An actual compiler bug or inconsistency. Remember, those engineers are experimenting with D to use it for serious projects at work, not personal toy projects. What do you think? Is it likely that they decide to invest a lot of time and resources migrating projects to D? Looking forward to seeing more of that in the compiler, which is the single most important thing in a programming language, the reason it exists, the thing I interface with most of the time.-- Better compiler errors, better compiler errors, better compiler errors.This is the only thing I greatly care about anymore. Biggest problem D has in real world use.Remember, those engineers are experimenting with D to use it for serious projects at work, not personal toy projects. What do you think? Is it likely that they decide to invest a lot of time and resources migrating projects to D?Then probably you did the right thing in not suggesting they move to using D at work at the current time. There are all kinds of coordination costs in adopting D immediately for serious projects where the people involved don't know the language yet and where the benefits of D don't seem compelling at this point. It's much better if the people involved start using D on the side for things that aren't mission critical or that don't have a tight deadline, unless D solves a particular sort of problem you have or theres much receptivity to it. I don't think D is at a point where it should be sold. People need to be receptive and ready to move towards you. And they need to be able to take decisions on the basis of intrinsic merits and not have to consider social factors. They means that the natural sphere of adoption is startups run by creative and independent minded people, smaller firms and small groups within large firms where people have autonomy. That's really quite okay - in the US, more than 100% of new jobs are created by smaller firms. Its a mistake to use a language you don't know for a mission critical project with a tight deadline, unless it solves so many problems that it is worth the inevitable teething problems. Doing so is a recipe for brittleness because it's hard to anticipate any difficulties and hard to plan for them. D naturally is spread much thinner than many other languages because it's more ambitious and is useful for many different domains, so if you're in a particular one of them then you will know many fewer people using D then would be the case for languages that are more adapted for particular domains. Also, there's much difference in how much people in different areas tend to talk about what they are doing. Web guys talk a lot; finance guys not do much. The people I have met who use D at work mostly don't develop open source stuff at work and they don't post all that much in the forums. We are rewriting our core analytics used across the firm (about 95 people) to D. Why? Because they need to be accessible from other languages so C ABI is necessary and it's not even a contest, D vs C++. And the person in charge of that project is a Fellow in Maths at Cambridge, and the one helping him is also a Cambridge mathematician so they realise how important beauty is in taming complexity, and D does exceptionally well on that front. We can then programmatically generate wrappers for other languages and we can connect the analytics and some micro services with a little domain specific language written using pegged. So it's highly unusual sets of people like that, or like the founders of Sociomantic, or like the EMSI guys, or Liran's guys at Weka that are likely to be D adopters in the next wave. Not people who can't see through error messages (which are much better than C++ anyway).I like what the D foundation did to the website, the language and library docs, the Learn section, the forums, the resources ... etc. That definitely gives the impression of maturity.I'm not sure those changes were primarily a consequence of things the D Foundation did, though maybe I'm wrong. You know how the runnable examples appeared? Seb Wilzbach, who appeared out of nowhere, decided to make them happen. Initially people didn't even see the point of them and there was some modest resistance.Maturity (or at least approaching it as much as possible) is VERY VERY VERY important.D is rough around the edges as an ecosystem. That's because the people involved care deeply about technical things and less so about making things incredibly comfortable for new users. Language ecosystems have difjferent values - when you pick a language you're marrying into that ecosystem, and whether it's right for you depends on the values you hold. The cost of that is obvious, but the benefit comes in other ways, including the capabilities of the set of people involved with D. That D isn't a shiny thing for now does act as a filter to discourage people who can't see through that. I don't think you can act mature when you aren't. In time D ecosystem will be mature and we will be reminiscing about those days when one could know the people involved and it was intrinsic rather than career motivation that attracted newcomers. For the time being that isn't the case, so one has to pick one's poison and decide what's important. Maybe for those who can't recognise what D offers at this point, D isn't the language for them and they should try Rust or Go. Maturity for the ecosystem will come.. In the meantime taking action or giving money is a much more effective way to shape things than saying "you know what you should do if you were a billionaire is this". It would be nice to have more resources - one could do things with them, but for the time being one is where one is, so suggesting that the Foundation should do X or Y isn't likely to have nearly as much impact as figuring out one tiny step towards it and becoming in part the change you wish to see. Maturity of the language is something else. The compilers seem quite usable - in 2014 I would regularly have segfaults and that's rare these days. The documentation has gone from being terrifying to non sophisticated programmers to my being able to say to colleagues we should have documentation as good as this,and runnable examples is good motivation to write unit tests too. I agree that better error messages would be nice. They're already a lot better, and I guess that will continue.
Jan 04 2018
On Friday, 5 January 2018 at 01:29:04 UTC, Laeeth Isharc wrote:So it's highly unusual sets of people like that, or like the founders of Sociomantic, or like the EMSI guys, or Liran's guys at Weka that are likely to be D adopters in the next wave. Not people who can't see through error messages (which are much better than C++ anyway).+1000 I would add that D should leverage the fact that is a "company friendly" language: the core team cares about problems raised by commercials that are using it (or, at least, it try hard to do it! :-P). That's pretty unique, in that phase of his history, compared to what we can see around. Well, it should do this in a more structured way, as I've suggested to Andrei, but it's definitely a big plus. /Paolo
Jan 05 2018
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:-- Better compiler errors, better compiler errors, better compiler errors.Very much so. I actually made a list a day or two ago. Some of it is more speculative than concrete, though: * unicode categories to determine what can be an identifier (there's no reason not to support, say, Canadian aboriginal syllabaries; it would just be too much work to list out each range of glyphs) * concepts / compile-time interfaces (makes ranges easier to deal with and document) * safe by default * function parameters are const scope by default (I recall this was a major request when const was first introduced) * mixin templates (a template designed to be mixed in is likely not to work if simply invoked; this also gets us most of what people have been asking for with macros) * possibly, block syntax for functions and templates whose last parameter is a function or alias
Dec 29 2017
On 12/28/2017 11:53 PM, IM wrote:Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.Diverging from the: file(line): message format is problematic because a lot of editors rely on that to position the editor on the offending line.
Dec 29 2017
On Friday, 29 December 2017 at 21:34:14 UTC, Walter Bright wrote:On 12/28/2017 11:53 PM, IM wrote:It's easy to detect whether the compiler is invoked in a TTY. Even if this turns out to be tricky, showing more helpful information to the user with a special flag (e.g. `--explain` or `--detailed`) is a way to go forward.Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.Diverging from the: file(line): message format is problematic because a lot of editors rely on that to position the editor on the offending line.
Dec 29 2017
On Friday, 29 December 2017 at 21:56:26 UTC, Seb wrote:On Friday, 29 December 2017 at 21:34:14 UTC, Walter Bright wrote:Being in an editor does not imply being in a TTY. AtilaOn 12/28/2017 11:53 PM, IM wrote:It's easy to detect whether the compiler is invoked in a TTY. Even if this turns out to be tricky, showing more helpful information to the user with a special flag (e.g. `--explain` or `--detailed`) is a way to go forward.Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.Diverging from the: file(line): message format is problematic because a lot of editors rely on that to position the editor on the offending line.
Dec 29 2017
On Fri, 29 Dec 2017 13:34:14 -0800, Walter Bright wrote:On 12/28/2017 11:53 PM, IM wrote:I think the idea of the OP is that the message should be better; not that it should have an identical format to the Rust error. file(line): better message isn't going to mess with anybody's tools. I noticed the Rust error has a code, too (E0308); if better error messages are too difficult to implement, assigning codes to error types and documenting them on the wiki could be helpful. Once you've dealt with an error type, the messages aren't that bad, but having documentation for the first time you run into it would be nice. Somewhat-related question out of curiosity: is there ever a time the error message "template instance foo!(bar) error instantiating" is actually needed? I've always seen it paired with a message that actually describes the problem, so is just noise.Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.Diverging from the: file(line): message format is problematic because a lot of editors rely on that to position the editor on the offending line.
Dec 29 2017
On 12/29/2017 1:57 PM, rjframe wrote:I noticed the Rust error has a code, too (E0308); if better error messages are too difficult to implement, assigning codes to error types and documenting them on the wiki could be helpful. Once you've dealt with an error type, the messages aren't that bad, but having documentation for the first time you run into it would be nice.Many compilers produce such error codes. I've considered it many times, but eventually concluded it added negative value. 1. Typing in an error code is so 1980's :-) People expect better these days. 2. A list of error messages with explanations can be trivially searched with a simple 'find text' command, which is much easier than typing in an error code. 3. Ideally there'd be a url one could click on, not an error code. 4. It's ugly.Somewhat-related question out of curiosity: is there ever a time the error message "template instance foo!(bar) error instantiating" is actually needed?Yes. It shows where the error originates in the user's code.
Dec 29 2017
On Friday, 29 December 2017 at 23:32:45 UTC, Walter Bright wrote:... 3. Ideally there'd be a url one could click on, not an error code. ....No URLs! (unless they point to 'local' documentation). I do not want to become even more dependent on having access to the internet, in order to debug programs.
Dec 29 2017
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:I will start: -- Better compiler errors, better compiler errors, better compiler errors. I really wish that the compiler errors could receive some refinement. Mostly it feels like some error text just being thrown at me. It needs to be better formatted, more helpful, with suggestions about how to fix (if possible). To illustrate my point: - See the compile errors I've just encountered with DMD: https://cdn.pbrd.co/images/H0q609l.png - Now compare that with an error produced by rustc: https://cdn.pbrd.co/images/H0q6bLi.png Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager.* R-value references. * More "Hands free" package/dependency management (See Cargo(Rust)) * GC dependency free stdlib, with built-in general purpose async i/o library * More sophisticated, official language server * Better IDE support * Full-fledged smart pointer (resembling std::unique_ptr<T>, std::shared_ptr<T>, std::weak_ptr<T> in the standard * Riddance of `object`, and being able to hand-make rootobject. No common root class.
Dec 30 2017