• Steven Schveighoffer (5/5) Jun 12 2011 I just want to say, I'm thoroughly impressed by the speed and effort
• Andrei Alexandrescu (16/21) Jun 12 2011 Yes, he's doing quite heavyweight stuff. I'd add that the other
• Andrej Mitrovic (3/3) Jun 12 2011 It looks like accessibility is everything. From the other discussions
• Robert Clipsham (11/16) Jun 13 2011 Indeed - I came home one day and saw ~100 new messages to the bug
• Andrei Alexandrescu (5/21) Jun 13 2011 Walter is continuously working on improving speed of pull request
• Robert Clipsham (12/16) Jun 13 2011 Is there some way we could speed this up? Obviously it can't be run for
• Timon Gehr (4/21) Jun 13 2011 I think the easiest way to speed it up would be to run it distributed on...
• Russel Winder (19/43) Jun 13 2011 l
• Andrei Alexandrescu (6/20) Jun 13 2011 Actually I suggested him to optimistically integrate several requests at...
• Andrej Mitrovic (2/2) Jun 13 2011 How do you run the DMD unittests, is it just "make -fwin32.mak debdmd"
• Don (10/36) Jun 14 2011 Well, to run a minimal test ( (a) no flags; (b) -O -inline -release )
• Walter Bright (8/12) Jun 13 2011 I agree. Other prolific dmd contributors to getting the backlog of old c...
• kenji hara (4/20) Jun 13 2011 I am interested in more proper language features to implement.
• Daniel Murphy (6/10) Jun 13 2011 I'm having lots of fun!

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

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

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 6/12/11 9: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!

 -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

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

It looks like accessibility is everything. From the other discussions
I wonder if a D package/library manager would make a similar impact to
adoption rates and productivity of D.

Robert Clipsham <robert octarineparrot.com> writes:

On 13/06/2011 03:22, 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!

 -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/

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 6/13/11 6:43 AM, Robert Clipsham wrote:
 On 13/06/2011 03:22, 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!

 -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

Robert Clipsham <robert octarineparrot.com> writes:

On 13/06/2011 14:39, Andrei Alexandrescu wrote:
 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/

Timon Gehr <timon.gehr gmx.ch> writes:

Robert Clipsham wrote:
 On 13/06/2011 14:39, Andrei Alexandrescu wrote:
 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

Russel Winder <russel russel.org.uk> writes:

On Mon, 2011-06-13 at 14:41 +0000, Timon Gehr wrote:
 Robert Clipsham wrote:
 On 13/06/2011 14:39, Andrei Alexandrescu wrote:
 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

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 6/13/11 9:12 AM, Robert Clipsham wrote:
 On 13/06/2011 14:39, Andrei Alexandrescu wrote:
 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?


Andrei

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

How do you run the DMD unittests, is it just "make -fwin32.mak debdmd"
? I'd like to test it on my hardware.

Don <nospam nospam.com> writes:

Andrei Alexandrescu wrote:
 On 6/13/11 9:12 AM, Robert Clipsham wrote:
 On 13/06/2011 14:39, Andrei Alexandrescu wrote:
 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).

 
 Walter?
 
 
 Andrei

Walter Bright <newshound2 digitalmars.com> writes:

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.

kenji hara <k.hara.pg gmail.com> writes:

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.

"Daniel Murphy" <yebblies nospamgmail.com> writes:

"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vwzsvfkyeav7ka localhost.localdomain...
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.