digitalmars.D - Bug reports [Was: Re: About Andrei's interview, part 3]
- bearophile (84/85) Aug 26 2010 Most of of my bugzilla entries are normal bugs, suggestions for improved...
- Jonathan M Davis (9/19) Aug 26 2010 Regardless of what type of bug reports they are, it takes time to deal w...
- bearophile (6/6) Aug 28 2010 Among the Bugzilla entries added by me, I suggest Don to focus his effor...
-
Yao G.
(5/13)
Aug 28 2010
What stops you from creating patches for these bugs? - Jonathan M Davis (7/23) Aug 28 2010 He's too busy finding other bugs. ;)
- Yao G. (6/15) Aug 28 2010 Yeah. I was joking. Forgot to put the smile tho'. It was just that I fou...
- Jonathan M Davis (3/20) Aug 28 2010 Oh, I realized you were joking. I just gave a semi-serious answer anyway...
- bearophile (4/8) Aug 29 2010 Right. And I have never studied compiler formally, yet, and I am not bol...
- Justin Johansson (4/27) Aug 29 2010 Still, I think he (bearophile) is deserving of an Honorary Doctorate of
- Andrej Mitrovic (71/74) Aug 31 2010 Wouldn't it be better if we had some kind of compile-time block
Walter Bright:I just hope you can be realistic about how much can be done about them in the short term.<Most of of my bugzilla entries are normal bugs, suggestions for improved error messages and diagnostic, Phobos bugs, enhancement requests, _additive_ changes, etc, that don't require any D spec/design change. Only a small percentage of them are "interesting" little not-additive (breaking) changes for D. The ones that I have listed some time ago: Syntax & semantics for array assigns http://d.puremagic.com/issues/show_bug.cgi?id=3971 [module system] Tiding up the imports http://d.puremagic.com/issues/show_bug.cgi?id=3819 Signed lengths (and other built-in values) http://d.puremagic.com/issues/show_bug.cgi?id=3843 [missing error] Array literal length doesn't match Array literal assign to array of different length http://d.puremagic.com/issues/show_bug.cgi?id=3849 http://d.puremagic.com/issues/show_bug.cgi?id=3948 opCast(bool) in classes is bug-prone http://d.puremagic.com/issues/show_bug.cgi?id=3926 Require opEquals/opCmp in a class the defines toHash http://d.puremagic.com/issues/show_bug.cgi?id=3844 automatic joining of adjacent strings is bad http://d.puremagic.com/issues/show_bug.cgi?id=3827 pure/nothrow functions/delegates are a subtype of the nonpure/throw ones http://d.puremagic.com/issues/show_bug.cgi?id=3833 const arguments/instance attributes in conditions/invariants http://d.puremagic.com/issues/show_bug.cgi?id=3856 bool opEquals() for structs instead of int opEquals() http://d.puremagic.com/issues/show_bug.cgi?id=3967 byte ==> sbyte http://d.puremagic.com/issues/show_bug.cgi?id=3936 http://d.puremagic.com/issues/show_bug.cgi?id=3850 A bug-prone situation with AAs http://d.puremagic.com/issues/show_bug.cgi?id=3825 Arguments and attributes with the same name http://d.puremagic.com/issues/show_bug.cgi?id=3878 More useful and more clean 'is' http://d.puremagic.com/issues/show_bug.cgi?id=3981 ----------------------- Few more added in the meantime: Deferencing a dynamic array as pointer http://d.puremagic.com/issues/show_bug.cgi?id=3990 Enum equality to an int http://d.puremagic.com/issues/show_bug.cgi?id=3999 Function pointer/delegate covariance http://d.puremagic.com/issues/show_bug.cgi?id=4000 Tidier management of static variables in pure functions http://d.puremagic.com/issues/show_bug.cgi?id=4031 To avoid struct ctor/opCall conflicts http://d.puremagic.com/issues/show_bug.cgi?id=4053 Steps toward a static foreach (just the first point is enough for now) http://d.puremagic.com/issues/show_bug.cgi?id=4085 Class method hidden by another one warning http://d.puremagic.com/issues/show_bug.cgi?id=4216 x.typeof syntax http://d.puremagic.com/issues/show_bug.cgi?id=4272 Deprecate automatic case fallthrough http://d.puremagic.com/issues/show_bug.cgi?id=4349 Require explicit braces when 'else' is ambiguous http://d.puremagic.com/issues/show_bug.cgi?id=4375 Catch wrong argument<->attribute assignments in methods http://d.puremagic.com/issues/show_bug.cgi?id=4407 Improving the compiler 'in' associative array can return just a bool http://d.puremagic.com/issues/show_bug.cgi?id=4475 "in" operator for AAs in SafeD code http://d.puremagic.com/issues/show_bug.cgi?id=4625 Contravariance problem http://d.puremagic.com/issues/show_bug.cgi?id=4511 Tidier function types http://d.puremagic.com/issues/show_bug.cgi?id=4530 Non-null class references/pointers http://d.puremagic.com/issues/show_bug.cgi?id=4571 Compiler option to port C code or disallow some duplicated C syntax http://d.puremagic.com/issues/show_bug.cgi?id=4580 Lambdas default arguments problems http://d.puremagic.com/issues/show_bug.cgi?id=4664 Troubles with 'auto ref' http://d.puremagic.com/issues/show_bug.cgi?id=4668 Built struct is callable without opCall http://d.puremagic.com/issues/show_bug.cgi?id=4678 Ambiguously designed array syntax http://d.puremagic.com/issues/show_bug.cgi?id=4703 Possible bugs caused by dynamic arrays in boolean evaluation context http://d.puremagic.com/issues/show_bug.cgi?id=4733 Bye, bearophile
Aug 26 2010
Jonathan M Davis <jmdavisprog gmail.com> On Thursday, August 26, 2010 17:42:18 bearophile wrote:Walter Bright:Regardless of what type of bug reports they are, it takes time to deal with them. Yes, some will take longer than others, but if you report them faster than the dev team can deal with them, then it's obviously going to take a while to get through everything that you report (and actually, if you always report them faster than they can deal with them, they'll _never_ get through them all). Now, as Walter said, that doesn't mean that you shouldn't report them, but Walter and company can only do so much so fast. - Jonathan M DavisI just hope you can be realistic about how much can be done about them in the short term.<Most of of my bugzilla entries are normal bugs, suggestions for improved error messages and diagnostic, Phobos bugs, enhancement requests, _additive_ changes, etc, that don't require any D spec/design change. Only a small percentage of them are "interesting" little not-additive (breaking) changes for D.
Aug 26 2010
Among the Bugzilla entries added by me, I suggest Don to focus his efforts on (and try to create patches for): 3971 3849 3948 3856 3825 3878 3981 3990 3999 4053 4085 4216 4349 4375 4407 4475 4625 4511 4530 4580 4664 4668 4678 4703 4733 Entries in that list often don't contain normal bugs or additive enhancements. Bye, bearophile
Aug 28 2010
On Sat, 28 Aug 2010 20:59:02 -0500, bearophile <bearophileHUGS lycos.com> wrote:Among the Bugzilla entries added by me, I suggest Don to focus his efforts on (and try to create patches for): 3971 3849 3948 3856 3825 3878 3981 3990 3999 4053 4085 4216 4349 4375 4407 4475 4625 4511 4530 4580 4664 4668 4678 4703 4733 Entries in that list often don't contain normal bugs or additive enhancements. Bye, bearophile<g> What stops you from creating patches for these bugs? -- Yao G.
Aug 28 2010
On Saturday 28 August 2010 19:06:42 Yao G. wrote:On Sat, 28 Aug 2010 20:59:02 -0500, bearophile <bearophileHUGS lycos.com> wrote:He's too busy finding other bugs. ;) Though seriously, given the large scope of bugs that he reports, I doubt that he knows enough to fix very many of them. Particularly if they're compiler bugs, it can take a lot of knowledge about exactly how dmd, druntime, and phobos work to be able to come up with appropriate fixes. - Jonathan M DavisAmong the Bugzilla entries added by me, I suggest Don to focus his efforts on (and try to create patches for): 3971 3849 3948 3856 3825 3878 3981 3990 3999 4053 4085 4216 4349 4375 4407 4475 4625 4511 4530 4580 4664 4668 4678 4703 4733 Entries in that list often don't contain normal bugs or additive enhancements. Bye, bearophile<g> What stops you from creating patches for these bugs?
Aug 28 2010
On Sat, 28 Aug 2010 21:27:27 -0500, Jonathan M Davis <jmdavisprog gmail.com> wrote:He's too busy finding other bugs. ;) Though seriously, given the large scope of bugs that he reports, I doubt that he knows enough to fix very many of them. Particularly if they're compiler bugs, it can take a lot of knowledge about exactly how dmd, druntime, and phobos work to be able to come up with appropriate fixes. - Jonathan M DavisYeah. I was joking. Forgot to put the smile tho'. It was just that I found funny when he asked Don to look those bugs and create patches. -- Yao G.
Aug 28 2010
On Saturday 28 August 2010 19:44:36 Yao G. wrote:On Sat, 28 Aug 2010 21:27:27 -0500, Jonathan M Davis <jmdavisprog gmail.com> wrote:Oh, I realized you were joking. I just gave a semi-serious answer anyway. - Jonathan M DavisHe's too busy finding other bugs. ;) Though seriously, given the large scope of bugs that he reports, I doubt that he knows enough to fix very many of them. Particularly if they're compiler bugs, it can take a lot of knowledge about exactly how dmd, druntime, and phobos work to be able to come up with appropriate fixes. - Jonathan M DavisYeah. I was joking. Forgot to put the smile tho'. It was just that I found funny when he asked Don to look those bugs and create patches.
Aug 28 2010
Jonathan M Davis:Though seriously, given the large scope of bugs that he reports, I doubt that he knows enough to fix very many of them. Particularly if they're compiler bugs, it can take a lot of knowledge about exactly how dmd, druntime, and phobos work to be able to come up with appropriate fixes.Right. And I have never studied compiler formally, yet, and I am not bold. But I am learning still. Bye, bearophile
Aug 29 2010
On 29/08/10 11:57, Jonathan M Davis wrote:On Saturday 28 August 2010 19:06:42 Yao G. wrote:Still, I think he (bearophile) is deserving of an Honorary Doctorate of Test and Analysis given his prolific filing of D bug reports. :-) - Justin JohanssonOn Sat, 28 Aug 2010 20:59:02 -0500, bearophile<bearophileHUGS lycos.com> wrote:He's too busy finding other bugs. ;) Though seriously, given the large scope of bugs that he reports, I doubt that he knows enough to fix very many of them. Particularly if they're compiler bugs, it can take a lot of knowledge about exactly how dmd, druntime, and phobos work to be able to come up with appropriate fixes. - Jonathan M DavisAmong the Bugzilla entries added by me, I suggest Don to focus his efforts on (and try to create patches for): 3971 3849 3948 3856 3825 3878 3981 3990 3999 4053 4085 4216 4349 4375 4407 4475 4625 4511 4530 4580 4664 4668 4678 4703 4733 Entries in that list often don't contain normal bugs or additive enhancements. Bye, bearophile<g> What stops you from creating patches for these bugs?
Aug 29 2010
Wouldn't it be better if we had some kind of compile-time block
statement instead of making separate compile-time keywords for every
run-time keyword?
For example, we could reuse static, and instead of code like this from
std.range:
private template MostDerivedInputRangeImpl(R) {
private alias ElementType!R E;
static if(isRandomAccessRange!R) {
static if(isInfinite!R) {
alias RandomAccessInfinite!E ret;
} else static if(hasAssignableElements!R) {
alias RandomFiniteAssignable!E ret;
} else {
alias RandomAccessFinite!E ret;
}
} else static if(isBidirectionalRange!R) {
static if(hasAssignableElements!R) {
alias BidirectionalAssignable!E ret;
} else {
alias BidirectionalRange!E ret;
}
} else static if(isForwardRange!R) {
static if(hasAssignableElements!R) {
alias ForwardAssignable!E ret;
} else {
alias ForwardRange!E ret;
}
} else {
static if(hasAssignableElements!R) {
alias InputAssignable!E ret;
} else {
alias InputRange!E ret;
}
}
}
We would have this:
private template MostDerivedInputRangeImpl(R) {
private alias ElementType!R E;
static {
if(isRandomAccessRange!R) {
if(isInfinite!R) {
alias RandomAccessInfinite!E ret;
} else if(hasAssignableElements!R) {
alias RandomFiniteAssignable!E ret;
} else {
alias RandomAccessFinite!E ret;
}
} else if(isBidirectionalRange!R) {
if(hasAssignableElements!R) {
alias BidirectionalAssignable!E ret;
} else {
alias BidirectionalRange!E ret;
}
} else if(isForwardRange!R) {
if(hasAssignableElements!R) {
alias ForwardAssignable!E ret;
} else {
alias ForwardRange!E ret;
}
} else {
if(hasAssignableElements!R) {
alias InputAssignable!E ret;
} else {
alias InputRange!E ret;
}
}
}
}
Or maybe use a different name for a compile-time block to not conflict
with static.
On Fri, Aug 27, 2010 at 2:42 AM, bearophile <bearophileHUGS lycos.com> wrote:
Steps toward a static foreach
(just the first point is enough for now)
http://d.puremagic.com/issues/show_bug.cgi?id=4085
Aug 31 2010