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.

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 otherwise just result in idle testers.  So, really #2 is a non-issue.

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

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

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 in activity would otherwise just result in idle testers.  So, really #2 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

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
>> activity would otherwise just result in idle testers.  So, really #2 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

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.

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

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?

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.

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