I just want to say, I'm thoroughly impressed by the speed and effort
Daniel Murphy is putting into fixing bugs with the compiler. Not to
mention, he is closing already fixed bugs (an important, but tedious task).
Bravo, Daniel!
-Steve

I just want to say, I'm thoroughly impressed by the speed and effort
Daniel Murphy is putting into fixing bugs with the compiler. Not to
mention, he is closing already fixed bugs (an important, but tedious task).
Bravo, Daniel!
-Steve

Yes, he's doing quite heavyweight stuff. I'd add that the other
contributors are no slouches either.
Generally I must say the door of opportunity has not just opened - it's
been blown off its hinges ever since we migrated on github. Since Jan 14
when we started there, we've had on average more than two pull requests
PER DAY, and that's not properly reflecting the accelerating pace in the
recent couple of months.
This momentum is stronger than the most optimistic expectations. It
seems to me that at this point it is crucial for the core team to be
effective at reviewing merging pull requests quickly, with the help of
the community. By this I'm suggesting anyone who has an interest in D to
give a hand with reviewing and improving pull requests, and of course to
create more of them.
Thanks,
Andrei

I just want to say, I'm thoroughly impressed by the speed and effort
Daniel Murphy is putting into fixing bugs with the compiler. Not to
mention, he is closing already fixed bugs (an important, but tedious task).
Bravo, Daniel!
-Steve

Indeed - I came home one day and saw ~100 new messages to the bug
tracker newsgroup, thought someone had spammed the bug tracker or
something. Turned out loads of old bugs were getting patched and closed!
Needless to say I :D'd. I just hope Walter can cope with the
ever-increasing size of the pull request list - I'd hate for development
to stagnate due to there being too many pull requests. This said, the
more the better! :D
--
Robert
http://octarineparrot.com/

I just want to say, I'm thoroughly impressed by the speed and effort
Daniel Murphy is putting into fixing bugs with the compiler. Not to
mention, he is closing already fixed bugs (an important, but tedious
task).
Bravo, Daniel!
-Steve

Indeed - I came home one day and saw ~100 new messages to the bug
tracker newsgroup, thought someone had spammed the bug tracker or
something. Turned out loads of old bugs were getting patched and closed!
Needless to say I :D'd. I just hope Walter can cope with the
ever-increasing size of the pull request list - I'd hate for development
to stagnate due to there being too many pull requests. This said, the
more the better! :D

Walter is continuously working on improving speed of pull request
integration. The bottleneck right now is the compiler test suite, which
takes hours to run.
Andrei

Walter is continuously working on improving speed of pull request
integration. The bottleneck right now is the compiler test suite, which
takes hours to run.
Andrei

Is there some way we could speed this up? Obviously it can't be run for
multiple pull requests at once, as they requests could affect each
other, so it'll need a third run if they're run at the same time. Is
there some way we could work around that?
What hardware does it take hours to run on? Could a donation of some
faster hardware help? Perhaps something like Google does could be useful
to decrease the amount of time the suite takes (see my post about
continuous integration at Google not too long ago).
--
Robert
http://octarineparrot.com/

Walter is continuously working on improving speed of pull request
integration. The bottleneck right now is the compiler test suite, which
takes hours to run.
Andrei

Is there some way we could speed this up? Obviously it can't be run for
multiple pull requests at once, as they requests could affect each
other, so it'll need a third run if they're run at the same time. Is
there some way we could work around that?
What hardware does it take hours to run on? Could a donation of some
faster hardware help? Perhaps something like Google does could be useful
to decrease the amount of time the suite takes (see my post about
continuous integration at Google not too long ago).
--
Robert
http://octarineparrot.com/

I think the easiest way to speed it up would be to run it distributed on
multiple
PCs of different devs or trusted members of the community.
Timon

Walter is continuously working on improving speed of pull request
integration. The bottleneck right now is the compiler test suite, whic=

h

takes hours to run.
Andrei

Is there some way we could speed this up? Obviously it can't be run for
multiple pull requests at once, as they requests could affect each
other, so it'll need a third run if they're run at the same time. Is
there some way we could work around that?
What hardware does it take hours to run on? Could a donation of some
faster hardware help? Perhaps something like Google does could be usefu=

l

to decrease the amount of time the suite takes (see my post about
continuous integration at Google not too long ago).
--
Robert
http://octarineparrot.com/

=20
I think the easiest way to speed it up would be to run it distributed on =

multiple

PCs of different devs or trusted members of the community.

Isn't this what Jenkins (aka Hudson) and Buildbot are good for. People
can offer up machines that are permanently connected as slaves and then
it is a question of programming up the central master to spawn runs of
tests of appropriate feature branches?
Or am I missing something about the DMD situation?
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

Walter is continuously working on improving speed of pull request
integration. The bottleneck right now is the compiler test suite, which
takes hours to run.
Andrei

Is there some way we could speed this up? Obviously it can't be run for
multiple pull requests at once, as they requests could affect each
other, so it'll need a third run if they're run at the same time. Is
there some way we could work around that?

Actually I suggested him to optimistically integrate several requests at
once and then run the test suite. Only if the suite fails, fall back on
integrating one at a time.

What hardware does it take hours to run on? Could a donation of some
faster hardware help? Perhaps something like Google does could be useful
to decrease the amount of time the suite takes (see my post about
continuous integration at Google not too long ago).

Walter is continuously working on improving speed of pull request
integration. The bottleneck right now is the compiler test suite, which
takes hours to run.
Andrei

Is there some way we could speed this up? Obviously it can't be run for
multiple pull requests at once, as they requests could affect each
other, so it'll need a third run if they're run at the same time. Is
there some way we could work around that?

Actually I suggested him to optimistically integrate several requests at
once and then run the test suite. Only if the suite fails, fall back on
integrating one at a time.

Well, to run a minimal test ( (a) no flags; (b) -O -inline -release )
takes about two minutes, and I've personally never seen a bug which was
caught by the full test, but not by the minimal test. (I believe that
such bugs do exist, but they're rarer than one in a thousand). OTOH it's
quite common to have a bug which passes the full test on one OS while
the minimal test fails on another.
I think it would be adequate to just run Phobos unittests + the minimal
test on both Windows-32 and Linux-64, (and maybe Mac as well) and then
rely on the auto-tester to catch the one-in-a-thousand bugs.

What hardware does it take hours to run on? Could a donation of some
faster hardware help? Perhaps something like Google does could be useful
to decrease the amount of time the suite takes (see my post about
continuous integration at Google not too long ago).

I just want to say, I'm thoroughly impressed by the speed and effort Daniel
Murphy is putting into fixing bugs with the compiler. Not to mention, he is
closing already fixed bugs (an important, but tedious task).
Bravo, Daniel!

I agree. Other prolific dmd contributors to getting the backlog of old compiler
bugs addressed are 9rnsr (Hara Kenji), kennytm, and Don Clugston. Several
others
are also stepping up with significant contributions
https://github.com/D-Programming-Language/dmd/pulls
It's an embarrassment of riches.
It makes it abundantly clear that the best thing we ever did for improving the
quality of dmd was put it on github.

I am interested in more proper language features to implement.
Github is good tool for contributing to D community.
Kenji Hara (9rnsr)
2011/6/14 Walter Bright <newshound2 digitalmars.com>:

On 6/12/2011 7:22 PM, Steven Schveighoffer wrote:

I just want to say, I'm thoroughly impressed by the speed and effort
Daniel
Murphy is putting into fixing bugs with the compiler. Not to mention, he
is
closing already fixed bugs (an important, but tedious task).
Bravo, Daniel!

I agree. Other prolific dmd contributors to getting the backlog of old
compiler bugs addressed are 9rnsr (Hara Kenji), kennytm, and Don Clugston.
Several others are also stepping up with significant contributions
https://github.com/D-Programming-Language/dmd/pulls
It's an embarrassment of riches.
It makes it abundantly clear that the best thing we ever did for improving
the quality of dmd was put it on github.

I just want to say, I'm thoroughly impressed by the speed and effort
Daniel Murphy is putting into fixing bugs with the compiler. Not to
mention, he is closing already fixed bugs (an important, but tedious task).
Bravo, Daniel!

I'm having lots of fun!
I was originally just looking through bugzilla for interesting bugs to fix,
but now I'm about a third of the way through a quick (!) pass, after a
couple of days on it.