Re: Daniel Murphy (yebblies)

2011-06-14 Thread Don

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


Re: Daniel Murphy (yebblies)

2011-06-13 Thread Robert Clipsham

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/


Re: Daniel Murphy (yebblies)

2011-06-13 Thread Andrei Alexandrescu

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


Re: Daniel Murphy (yebblies)

2011-06-13 Thread Robert Clipsham

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/


Re: Daniel Murphy (yebblies)

2011-06-13 Thread Timon Gehr
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


Re: Daniel Murphy (yebblies)

2011-06-13 Thread Andrei Alexandrescu

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


Re: Daniel Murphy (yebblies)

2011-06-13 Thread Andrej Mitrovic
How do you run the DMD unittests, is it just make -fwin32.mak debdmd
? I'd like to test it on my hardware.


Re: Daniel Murphy (yebblies)

2011-06-13 Thread Russel Winder
On Mon, 2011-06-13 at 14:41 +, 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, 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.

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?

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part


Re: Daniel Murphy (yebblies)

2011-06-13 Thread Walter Bright

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.


Re: Daniel Murphy (yebblies)

2011-06-13 Thread Daniel Murphy
Steven Schveighoffer schvei...@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. 




Re: Daniel Murphy (yebblies)

2011-06-13 Thread kenji hara
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 newshou...@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)

2011-06-12 Thread Steven Schveighoffer
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


Re: Daniel Murphy (yebblies)

2011-06-12 Thread Andrei Alexandrescu

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


Re: Daniel Murphy (yebblies)

2011-06-12 Thread Andrej Mitrovic
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.