• bearophile (20/20) Mar 23 2014 This kind of code sometimes is wrong, because you forget to cast
• Daniel Murphy (2/7) Mar 24 2014 Newbies have to realize that integers aren't real numbers eventually.
• bearophile (9/11) Mar 24 2014 Of course. But from reviewing plenty of code, I have seen that
• Chris Williams (12/15) Mar 24 2014 When doing math, I always use parentheses and casts to force a
• bearophile (10/16) Mar 24 2014 void main() {
• Abdulhaq (2/7) Mar 24 2014 This is the kind of area where an IDE can shine...
• Don (13/33) Mar 24 2014 It is indeed a common floating-point bug.
• Marco Leise (6/20) Mar 24 2014 Sounds awesome. Could that also be applied to this as well?:
• bearophile (5/6) Mar 24 2014 I have opened an ER:
• Temtaime (3/3) Mar 24 2014 It requires a little more attention and that's all.
• bearophile (6/9) Mar 24 2014 I don't agree they are fake :-) We have removed several classes
• Andrei Alexandrescu (4/15) Mar 24 2014 That seems a sensible thing to do. I've assigned
• Peter Alexander (7/12) Mar 24 2014 We are passed the initial stage of designing the language. D is
• H. S. Teoh (9/21) Mar 24 2014 Don't we have a wiki page for ideas for "future D" (or D3?)? These ideas
• bearophile (7/9) Mar 24 2014 I don't think Andrei will want a D3 language, so better to keep
• bearophile (16/23) Mar 24 2014 The original D design is to make a language that is "focused on
• Andrei Alexandrescu (11/19) Mar 24 2014 The single most impactful way to improve D some more at this point is,
• Andrej Mitrovic (8/11) Mar 24 2014 I've been through most Phobos pulls several times now in the last
• Steven Schveighoffer (8/16) Mar 24 2014 2 things:
• Brad Roberts (5/18) Mar 24 2014 Older than 2 weeks and they aren't likely to get tested either.. since a...
• Steven Schveighoffer (6/36) Mar 24 2014 OK, so it tests in reverse chronological? That makes the most sense. I w...
• Brad Roberts (4/22) Mar 24 2014 The sync between github and the tester isn't instant, so time is sometim...
• Steven Schveighoffer (6/10) Mar 24 2014 Brad, I wanted to just say that I don't follow the auto tester's
• Walter Bright (3/8) Mar 24 2014 Is it reasonable to, at least once a week, run the full queue? Like on S...
• Brad Roberts (6/13) Mar 24 2014 To do so for all platforms would take more than a morning (probably a fu...
• Daniel Murphy (3/8) Mar 24 2014 Pulls that haven't been touched in a while also don't get auto-tested.
• Andrei Alexandrescu (2/10) Mar 24 2014 Those should be closed. -- Andrei
• bearophile (8/14) Mar 24 2014 My time is more efficiently used suggesting people new ideas to
• Andrei Alexandrescu (3/8) Mar 24 2014 You and I have very different notions of what efficiency would mean
• Asman01 (4/24) Mar 24 2014 I think I've see a thread very similar to this... well, most

"bearophile" <bearophileHUGS lycos.com> writes:

This kind of code sometimes is wrong, because you forget to cast 
x to double before the division and you lose precision (but here 
the compiler knows that the result of the division will go inside 
a double):


void main() {
     int x = 15;
     double y = x / 10;
}

The cause is that unfortunately in D the integer division uses 
the same operator as the FP division. In Python there is the / 
and // operators. In OcaML there are the / and /., in Delphi 
there are the / and div operators, in Ada the two operands need 
to be of the same type.

Seasoned C/C++/D programmers watch for the types every time they 
perform a division, to avoid that trap. But less experienced 
programmers introduce bugs with divisions. Can D help the 
programmer reduce the frequency of similar bugs? And do we want 
to?

Bye,
bearophile

"Daniel Murphy" <yebbliesnospam gmail.com> writes:

"bearophile"  wrote in message news:nxfidkglrgkqtxdzgojt forum.dlang.org... 

 Seasoned C/C++/D programmers watch for the types every time they 
 perform a division, to avoid that trap. But less experienced 
 programmers introduce bugs with divisions. Can D help the 
 programmer reduce the frequency of similar bugs? And do we want 
 to?

Newbies have to realize that integers aren't real numbers eventually.

"bearophile" <bearophileHUGS lycos.com> writes:

Daniel Murphy:

 Newbies have to realize that integers aren't real numbers 
 eventually.

Of course. But from reviewing plenty of code, I have seen that 
unfortunately even programmers with some experience once in a 
while create this bug. Because you have to keep attention to the 
types of each division usage, and once in a while your attention 
slips (or perhaps some bugs of this kind are created by 
successive type changes).

Bye,
bearophile

"Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:

On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
                                                        Can D 
 help the programmer reduce the frequency of similar bugs? And 
 do we want to?

When doing math, I always use parentheses and casts to force a 
single possible outcome of the result, regardless of the order of 
evaluation and auto-casting. I also always write all my 
case/break statements as a set of matching pairs before writing 
any code in a switch, so the idea that something would fall 
through on accident seems like something that could never happen.

People should have habits like these (and putting constant values 
on the left side of a comparison), but I suspect that most people 
would be annoyed at being forced to do it by the compiler, even 
though if they were aware that this was a "good habit", they'd 
all start doing it and life would be perfect.

"bearophile" <bearophileHUGS lycos.com> writes:

Chris Williams:

 I also always write all my case/break statements as a set of 
 matching pairs before writing any code in a switch, so the idea 
 that something would fall through on accident seems like 
 something that could never happen.

Now D catches most of such implicit case fall-through bugs.


 People should have habits like these (and putting constant 
 values on the left side of a comparison),

void main() {
     int x;
     if (x = 5) {}
}


test.d(3,14): Error: assignment cannot be used as a condition, 
perhaps == was meant?

Bye,
bearophile

"Abdulhaq" <alynch4047 gmail.com> writes:

On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
 Seasoned C/C++/D programmers watch for the types every time 
 they perform a division, to avoid that trap. But less 
 experienced programmers introduce bugs with divisions. Can D 
 help the programmer reduce the frequency of similar bugs? And 
 do we want to?

This is the kind of area where an IDE can shine...

"Don" <x nospam.com> writes:

On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
 This kind of code sometimes is wrong, because you forget to 
 cast x to double before the division and you lose precision 
 (but here the compiler knows that the result of the division 
 will go inside a double):


 void main() {
     int x = 15;
     double y = x / 10;
 }

 The cause is that unfortunately in D the integer division uses 
 the same operator as the FP division. In Python there is the / 
 and // operators. In OcaML there are the / and /., in Delphi 
 there are the / and div operators, in Ada the two operands need 
 to be of the same type.

 Seasoned C/C++/D programmers watch for the types every time 
 they perform a division, to avoid that trap. But less 
 experienced programmers introduce bugs with divisions. Can D 
 help the programmer reduce the frequency of similar bugs? And 
 do we want to?

 Bye,
 bearophile

It is indeed a common floating-point bug.

I came up with a solution for this a couple of years ago, never 
got around to doing a pull request, but it's on the newsgroup 
somewhere. It's a little extension to the range propagation 
implementation. You add a boolean flag to the range, which 
indicates 'a fractional part has been discarded'. This flag gets 
set whenever you perform an integer division (or integer 
exponentiation with a negative power), and is cleared whenever 
there is a cast or a bitwise operation.

Then, disallow implicit casting from integer to floating point 
whenever the fractional bit is set. Catches all these kinds of 
bugs, doesn't require any changes to the language.

Marco Leise <Marco.Leise gmx.de> writes:

Am Mon, 24 Mar 2014 09:51:02 +0000
schrieb "Don" <x nospam.com>:

 It is indeed a common floating-point bug.
 
 I came up with a solution for this a couple of years ago, never 
 got around to doing a pull request, but it's on the newsgroup 
 somewhere. It's a little extension to the range propagation 
 implementation. You add a boolean flag to the range, which 
 indicates 'a fractional part has been discarded'. This flag gets 
 set whenever you perform an integer division (or integer 
 exponentiation with a negative power), and is cleared whenever 
 there is a cast or a bitwise operation.
 
 Then, disallow implicit casting from integer to floating point 
 whenever the fractional bit is set. Catches all these kinds of 
 bugs, doesn't require any changes to the language.

Sounds awesome. Could that also be applied to this as well?:

  mask = 1 << bitNum;

-- 
Marco

"bearophile" <bearophile HUGS lycos.com> writes:

Don:

 It is indeed a common floating-point bug.

I have opened an ER:
https://d.puremagic.com/issues/show_bug.cgi?id=12452

Bye,
bearophile

"Temtaime" <temtaime gmail.com> writes:

It requires a little more attention and that's all.
Please, stop creating such "fake" enchantments and go to fix real 
bugs. Thanks.

"bearophile" <bearophileHUGS lycos.com> writes:

Temtaime:

 It requires a little more attention and that's all.
 Please, stop creating such "fake" enchantments and go to fix 
 real bugs. Thanks.

I don't agree they are fake :-) We have removed several classes 
of common C bugs from D with those enhancements, and there is 
still some space left for improvements :-)

Bye,
bearophile

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/24/14, 2:51 AM, Don wrote:
 It is indeed a common floating-point bug.

 I came up with a solution for this a couple of years ago, never got
 around to doing a pull request, but it's on the newsgroup somewhere.
 It's a little extension to the range propagation implementation. You add
 a boolean flag to the range, which indicates 'a fractional part has been
 discarded'. This flag gets set whenever you perform an integer division
 (or integer exponentiation with a negative power), and is cleared
 whenever there is a cast or a bitwise operation.

 Then, disallow implicit casting from integer to floating point whenever
 the fractional bit is set. Catches all these kinds of bugs, doesn't
 require any changes to the language.

That seems a sensible thing to do. I've assigned 
https://d.puremagic.com/issues/show_bug.cgi?id=12452 to you for now.

Andrei

"Peter Alexander" <peter.alexander.au gmail.com> writes:

On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
 Seasoned C/C++/D programmers watch for the types every time 
 they perform a division, to avoid that trap. But less 
 experienced programmers introduce bugs with divisions. Can D 
 help the programmer reduce the frequency of similar bugs? And 
 do we want to?

We are passed the initial stage of designing the language. D is 
used now in lots of real code. The focus now has to be on 
completing the original design, and maybe making small 
non-breaking improvements where practical. Discussions about 
fundamental changes to the language like this, while interesting, 
are distracting and counterproductive.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Mon, Mar 24, 2014 at 07:19:58PM +0000, Peter Alexander wrote:
 On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
Seasoned C/C++/D programmers watch for the types every time they
perform a division, to avoid that trap. But less experienced
programmers introduce bugs with divisions. Can D help the programmer
reduce the frequency of similar bugs? And do we want to?

 
 We are passed the initial stage of designing the language. D is used
 now in lots of real code. The focus now has to be on completing the
 original design, and maybe making small non-breaking improvements
 where practical.  Discussions about fundamental changes to the
 language like this, while interesting, are distracting and
 counterproductive.

Don't we have a wiki page for ideas for "future D" (or D3?)? These ideas
can go on that page.


T

-- 
English is useful because it is a mess. Since English is a mess, it maps
well onto the problem space, which is also a mess, which we call
reality. Similarly, Perl was designed to be a mess, though in the
nicests of all possible ways. -- Larry Wall

"bearophile" <bearophileHUGS lycos.com> writes:

H. S. Teoh:

 Don't we have a wiki page for ideas for "future D" (or D3?)? 
 These ideas can go on that page.

I don't think Andrei will want a D3 language, so better to keep 
the focus on D2 first :-) And he is right because there are still 
some parts of D2 unfinished. The little type system improvement 
suggested in this thread is meant for D2.

Bye,
bearophile

"bearophile" <bearophileHUGS lycos.com> writes:

Peter Alexander:

 We are passed the initial stage of designing the language. D is 
 used now in lots of real code.

I'd like D improve some more.


 The focus now has to be on completing the original design,

The original D design is to make a language that is "focused on 
safety", so we are still working to complete it :-)


 and maybe making small non-breaking improvements where 
 practical.

I think the problem raised in this thread could have a very 
limited negative impact on correct existing D code, and a 
positive impact in finding wrong code.


 Discussions about fundamental changes to the language like this,

It's not a fundamental change, I think it's a sufficiently 
limited change. As usual you can be sure only when you apply such 
ideas on real D code.


 are distracting and counterproductive.

It's not distracting, because it focuses on something you do 
often (divisions), and it's hopefully productive because it could 
avoid some bugs and decrease the time spent performing rote 
manual code review.

Bye,
bearophile

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/24/14, 12:51 PM, bearophile wrote:
 Peter Alexander:

 We are passed the initial stage of designing the language. D is used
 now in lots of real code.

 I'd like D improve some more.

The single most impactful way to improve D some more at this point is, 
without a shred of doubt, reviewing pull requests on github. Anyone who 
has any nontrivial interest in the future of D should help us turn the 
ratchet by reviewing pull requests. Anything - potential bugs found, 
safety suggestions, efficiency suggestions, LGTM - would help the core 
team drain that pipe.

 are distracting and counterproductive.

 It's not distracting, because it focuses on something you do often
 (divisions), and it's hopefully productive because it could avoid some
 bugs and decrease the time spent performing rote manual code review.

If you diverted 1.0/10 (sic!) of the effort you put in these discussions 
in reviewing pull requests, that would help us all put up a lot better 
with the distraction.


Andrei

"Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:

On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu 
wrote:
 The single most impactful way to improve D some more at this 
 point is, without a shred of doubt, reviewing pull requests on 
 github.

I've been through most Phobos pulls several times now in the last 
few months, and from what I can tell a lot of pulls seem to be 
stalled by the pull authors themselves rather than a lack of 
reviewers. Someone makes a pull, it gets reviewed but turns out 
the pull needs more work, and then the author disappears from the 
face of the earth.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Mon, 24 Mar 2014 16:11:34 -0400, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote:
 The single most impactful way to improve D some more at this point is,  
 without a shred of doubt, reviewing pull requests on github.

 I've been through most Phobos pulls several times now in the last few  
 months, and from what I can tell a lot of pulls seem to be stalled by  
 the pull authors themselves rather than a lack of reviewers. Someone  
 makes a pull, it gets reviewed but turns out the pull needs more work,  
 and then the author disappears from the face of the earth.

2 things:

1. Pulls that are waiting for author changes, but haven't been touched in  
a week (maybe?) should be closed. They can always be reopened.
2. Pulls that are closed do not get tested, so they are not using up  
cycles on the auto tester.

-Steve

Brad Roberts <braddr puremagic.com> writes:

On 3/24/14, 1:48 PM, Steven Schveighoffer wrote:
 On Mon, 24 Mar 2014 16:11:34 -0400, Andrej Mitrovic
<andrej.mitrovich gmail.com> wrote:

 On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote:
 The single most impactful way to improve D some more at this point is, without
a shred of doubt,
 reviewing pull requests on github.

 I've been through most Phobos pulls several times now in the last few months,
and from what I can
 tell a lot of pulls seem to be stalled by the pull authors themselves rather
than a lack of
 reviewers. Someone makes a pull, it gets reviewed but turns out the pull needs
more work, and then
 the author disappears from the face of the earth.

 2 things:

 1. Pulls that are waiting for author changes, but haven't been touched in a
week (maybe?) should be
 closed. They can always be reopened.
 2. Pulls that are closed do not get tested, so they are not using up cycles on
the auto tester.

Older than 2 weeks and they aren't likely to get tested either.. since any
change to the branch (ie, 
a pull being merged) restarts testing, so they're effectively just dead weight
down the queue.  Only 
a lull in pull merging would allow them to be tested, which is fine since a
lull in activity would 

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Mon, 24 Mar 2014 16:53:36 -0400, Brad Roberts <braddr puremagic.com>  
wrote:

 On 3/24/14, 1:48 PM, Steven Schveighoffer wrote:
 On Mon, 24 Mar 2014 16:11:34 -0400, Andrej Mitrovic  
 <andrej.mitrovich gmail.com> wrote:

 On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote:
 The single most impactful way to improve D some more at this point  
 is, without a shred of doubt,
 reviewing pull requests on github.

 I've been through most Phobos pulls several times now in the last few  
 months, and from what I can
 tell a lot of pulls seem to be stalled by the pull authors themselves  
 rather than a lack of
 reviewers. Someone makes a pull, it gets reviewed but turns out the  
 pull needs more work, and then
 the author disappears from the face of the earth.

 2 things:

 1. Pulls that are waiting for author changes, but haven't been touched  
 in a week (maybe?) should be
 closed. They can always be reopened.
 2. Pulls that are closed do not get tested, so they are not using up  
 cycles on the auto tester.

 Older than 2 weeks and they aren't likely to get tested either.. since  
 any change to the branch (ie, a pull being merged) restarts testing, so  
 they're effectively just dead weight down the queue.  Only a lull in  
 pull merging would allow them to be tested, which is fine since a lull  

 is a non-issue.

OK, so it tests in reverse chronological? That makes the most sense. I was  
worried it was taking away time from other test runs.

If a test has been started, and a merge occurs, does it stop the test?

-Steve

Brad Roberts <braddr puremagic.com> writes:

On 3/24/14, 2:26 PM, Steven Schveighoffer wrote:
 On Mon, 24 Mar 2014 16:53:36 -0400, Brad Roberts <braddr puremagic.com> wrote:

 On 3/24/14, 1:48 PM, Steven Schveighoffer wrote:
 On Mon, 24 Mar 2014 16:11:34 -0400, Andrej Mitrovic
<andrej.mitrovich gmail.com> wrote:

 2 things:

 1. Pulls that are waiting for author changes, but haven't been touched in a
week (maybe?) should be
 closed. They can always be reopened.
 2. Pulls that are closed do not get tested, so they are not using up cycles on
the auto tester.

 Older than 2 weeks and they aren't likely to get tested either.. since any
change to the branch
 (ie, a pull being merged) restarts testing, so they're effectively just dead
weight down the
 queue.  Only a lull in pull merging would allow them to be tested, which is
fine since a lull in

non-issue.

 OK, so it tests in reverse chronological? That makes the most sense. I was
worried it was taking
 away time from other test runs.

 If a test has been started, and a merge occurs, does it stop the test?

 -Steve

The sync between github and the tester isn't instant, so time is sometimes
wasted on an already 
merged pull.  However, it does check between steps to see if the run has been
marked as old.  If so, 
it stops working on it.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Mon, 24 Mar 2014 19:33:47 -0400, Brad Roberts <braddr puremagic.com>  
wrote:

 The sync between github and the tester isn't instant, so time is  
 sometimes wasted on an already merged pull.  However, it does check  
 between steps to see if the run has been marked as old.  If so, it stops  
 working on it.

Brad, I wanted to just say that I don't follow the auto tester's  
development closely (obviously), but it's one of the best things I think  
has ever happened to D. Thanks for all your hard work.

-Steve

Walter Bright <newshound2 digitalmars.com> writes:

On 3/24/2014 1:53 PM, Brad Roberts wrote:
 Older than 2 weeks and they aren't likely to get tested either.. since any
 change to the branch (ie, a pull being merged) restarts testing, so they're
 effectively just dead weight down the queue.  Only a lull in pull merging would
 allow them to be tested, which is fine since a lull in activity would otherwise
 just result in idle testers.

Is it reasonable to, at least once a week, run the full queue? Like on Sunday 
morning?

Brad Roberts <braddr puremagic.com> writes:

On 3/24/14, 4:50 PM, Walter Bright wrote:
 On 3/24/2014 1:53 PM, Brad Roberts wrote:
 Older than 2 weeks and they aren't likely to get tested either.. since any
 change to the branch (ie, a pull being merged) restarts testing, so they're
 effectively just dead weight down the queue.  Only a lull in pull merging would
 allow them to be tested, which is fine since a lull in activity would otherwise
 just result in idle testers.

 Is it reasonable to, at least once a week, run the full queue? Like on Sunday
morning?

To do so for all platforms would take more than a morning (probably a full
day).  I don't, 
personally, think it'd be all that useful.  As soon as it finished, the results
would be deprecated 
and fresh builds started.  That the queue focuses on pull requests that are
actually the active 
requests seems pretty much ideal, imho.

Also, for what it's worth, the 1 millionth test run was executed some time this
past weekend.

"Daniel Murphy" <yebbliesnospam gmail.com> writes:

"Steven Schveighoffer"  wrote in message 
news:op.xc8uqgsneav7ka stevens-macbook-pro.local...

 2 things:

 1. Pulls that are waiting for author changes, but haven't been touched in 
 a week (maybe?) should be closed. They can always be reopened.
 2. Pulls that are closed do not get tested, so they are not using up 
 cycles on the auto tester.

Pulls that haven't been touched in a while also don't get auto-tested. 

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/24/14, 1:11 PM, Andrej Mitrovic wrote:
 On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote:
 The single most impactful way to improve D some more at this point is,
 without a shred of doubt, reviewing pull requests on github.

 I've been through most Phobos pulls several times now in the last few
 months, and from what I can tell a lot of pulls seem to be stalled by
 the pull authors themselves rather than a lack of reviewers. Someone
 makes a pull, it gets reviewed but turns out the pull needs more work,
 and then the author disappears from the face of the earth.

Those should be closed. -- Andrei

"bearophile" <bearophileHUGS lycos.com> writes:

Andrei Alexandrescu:

 The single most impactful way to improve D some more at this 
 point is, without a shred of doubt, reviewing pull requests on 
 github.

My time is more efficiently used suggesting people new ideas to 
create new pull requests :-)


 If you diverted 1.0/10 (sic!) of the effort you put in these 
 discussions in reviewing pull requests, that would help us all 
 put up a lot better with the distraction.

Instead of ignoring my arguments of this thread, if you want 
please comment regarding the merits of the idea of catching some 
of the division-related problems.

Bye,
bearophile

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/24/14, 1:21 PM, bearophile wrote:
 Andrei Alexandrescu:

 The single most impactful way to improve D some more at this point is,
 without a shred of doubt, reviewing pull requests on github.

 My time is more efficiently used suggesting people new ideas to create
 new pull requests :-)

You and I have very different notions of what efficiency would mean 
here. -- Andrei

"Asman01" <jckj33 gmail.com> writes:

On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
 This kind of code sometimes is wrong, because you forget to 
 cast x to double before the division and you lose precision 
 (but here the compiler knows that the result of the division 
 will go inside a double):


 void main() {
     int x = 15;
     double y = x / 10;
 }

 The cause is that unfortunately in D the integer division uses 
 the same operator as the FP division. In Python there is the / 
 and // operators. In OcaML there are the / and /., in Delphi 
 there are the / and div operators, in Ada the two operands need 
 to be of the same type.

 Seasoned C/C++/D programmers watch for the types every time 
 they perform a division, to avoid that trap. But less 
 experienced programmers introduce bugs with divisions. Can D 
 help the programmer reduce the frequency of similar bugs? And 
 do we want to?

 Bye,
 bearophile

I think I've see a thread very similar to this... well, most 
willn't like but a possible solution to help programmer reduce 
this is do what python did: a new operator.