Jump to page: 1 2
Thread overview
[phobos] auto-tester update
Feb 20, 2011
Brad Roberts
Feb 20, 2011
Brad Roberts
Feb 21, 2011
Walter Bright
Feb 21, 2011
Walter Bright
Feb 21, 2011
Brad Roberts
Feb 21, 2011
David Simcha
Feb 21, 2011
Brad Roberts
Feb 21, 2011
Walter Bright
Feb 21, 2011
Brad Roberts
Feb 21, 2011
Sean Kelly
Feb 21, 2011
Jacob Carlborg
Feb 21, 2011
Jens Mueller
Feb 21, 2011
Jacob Carlborg
Feb 21, 2011
Brad Roberts
Feb 22, 2011
Jacob Carlborg
Feb 22, 2011
Jens Mueller
Feb 22, 2011
Jacob Carlborg
Feb 21, 2011
Brad Roberts
Feb 21, 2011
Sean Kelly
Feb 21, 2011
Brad Roberts
February 19, 2011
I just pushed out some changes to the way the auto-tester works.  Instead of sleeping for an hour (30 minutes for the windows build) between runs it watches checkins.  Essentially:

forever:
   if (a check in has occurred to dmd, druntime, or phobos since last run)
       do a run
   sleep 60

So, it ought to start new runs fairly fast after new checkins and won't produce lots of semi-useless test results.  I say semi since less runs means intermittent failures are less likely to be found.

Also, the look and feel have been updated, comments welcome.

   http://d.puremagic.com/test-results

On the todo list:
   failure emails
   osx/32 tester
   freebsd/32 tester

Later,
Brad
February 20, 2011
FreeBSD D2 auto tester active.  It's _slow_ due to being on a rather old box, but something is way better than nothing.

The only test I disabled is druntime's core.time (bug 5629).  Everything else passes which is pretty impressive for a platform that hasn't been getting routine testing.

I also filed bugs for all of the x86-64 disabled tests (bugs 5623-5628) so that they're at least sort of on the radar.

On 2/19/2011 8:39 PM, Brad Roberts wrote:
> I just pushed out some changes to the way the auto-tester works.  Instead of sleeping for an hour (30 minutes for the windows build) between runs it watches checkins.  Essentially:
> 
> forever:
>    if (a check in has occurred to dmd, druntime, or phobos since last run)
>        do a run
>    sleep 60
> 
> So, it ought to start new runs fairly fast after new checkins and won't produce lots of semi-useless test results.  I say semi since less runs means intermittent failures are less likely to be found.
> 
> Also, the look and feel have been updated, comments welcome.
> 
>    http://d.puremagic.com/test-results
> 
> On the todo list:
>    failure emails
>    osx/32 tester
>    freebsd/32 tester
> 
> Later,
> Brad

February 20, 2011

Brad Roberts wrote:
> FreeBSD D2 auto tester active.  It's _slow_ due to being on a rather old box, but something is way better than nothing.
>
> The only test I disabled is druntime's core.time (bug 5629).  Everything else passes which is pretty impressive for a platform that hasn't been getting routine testing.
>
> I also filed bugs for all of the x86-64 disabled tests (bugs 5623-5628) so that they're at least sort of on the radar.
>
> 

This is great news. Thanks, Brad!
February 20, 2011

Brad Roberts wrote:
> Everything else passes which is pretty impressive for a platform that hasn't been getting routine testing.
>
> 

I've been routinely testing D1 on FreeBSD. That kept at least some of the D2 bitrot away.


Anyhow, what do you think of adding NetBSD, OpenBSD and OpenSolaris into the mix?
February 20, 2011
On 2/20/2011 4:42 PM, Walter Bright wrote:
> 
> 
> Brad Roberts wrote:
>> Everything else passes which is pretty impressive for a platform that hasn't been getting routine testing.
>>
>> 
> 
> I've been routinely testing D1 on FreeBSD. That kept at least some of the D2 bitrot away.
> 
> 
> Anyhow, what do you think of adding NetBSD, OpenBSD and OpenSolaris into the mix?

Likely not hard to add, but I haven't seen a demonstrated community desire for them.  There was one person with a subset of patches for netbsd.  That said, if someone donates an account on a box, that'd be a step in the right direction.  I'm trying to avoid accumulating a box per platform, though mostly failing at it.

But honestly, my first instinct.. we've got a whole lotta things to concentrate on, and more platforms isn't really at the top of my list.

For the record, 3516 is still at the top of my list, but you're about the only man for that job.

Later,
Brad
February 20, 2011
On 2/20/2011 8:20 PM, Brad Roberts wrote:
> Likely not hard to add, but I haven't seen a demonstrated community desire for them.  There was one person with a subset of patches for netbsd.  That said, if someone donates an account on a box, that'd be a step in the right direction.  I'm trying to avoid accumulating a box per platform, though mostly failing at it.
>
>

What's wrong with virtualization as a solution to the one-box-per-platform problem?  Just use your favorite OS as your host, get a ton of RAM, and run all the rest in VMs.

February 20, 2011
On 2/20/2011 5:25 PM, David Simcha wrote:
> On 2/20/2011 8:20 PM, Brad Roberts wrote:
>> Likely not hard to add, but I haven't seen a demonstrated community desire for them.  There was one person with a subset of patches for netbsd.  That said, if someone donates an account on a box, that'd be a step in the right direction.  I'm trying to avoid accumulating a box per platform, though mostly failing at it.
>>
>>
> 
> What's wrong with virtualization as a solution to the one-box-per-platform problem?  Just use your favorite OS as your host, get a ton of RAM, and run all the rest in VMs.

It's a solution, but not a great one.  The build runs are already cpu bound, so diving up the cpu's just means everything goes slower.
February 20, 2011

Brad Roberts wrote:
> On 2/20/2011 5:25 PM, David Simcha wrote:
> 
>> What's wrong with virtualization as a solution to the one-box-per-platform problem?  Just use your favorite OS as your
>> host, get a ton of RAM, and run all the rest in VMs.
>> 
>
> It's a solution, but not a great one.  The build runs are already cpu bound, so diving up the cpu's just means everything goes slower.
>
> 

My experience with virtual boxes is they get wiped out every time you do an update on the host. Extremely annoying. I use a separate box per OS. Something to do with the old machines around here :-)
February 20, 2011
On 2/20/2011 6:00 PM, Walter Bright wrote:
> 
> 
> Brad Roberts wrote:
>> On 2/20/2011 5:25 PM, David Simcha wrote:
>> 
>>> What's wrong with virtualization as a solution to the one-box-per-platform problem?  Just use your favorite OS as your
>>> host, get a ton of RAM, and run all the rest in VMs.
>>> 
>>
>> It's a solution, but not a great one.  The build runs are already cpu bound, so diving up the cpu's just means everything goes slower.
>>
>> 
> 
> My experience with virtual boxes is they get wiped out every time you do an update on the host. Extremely annoying. I use a separate box per OS. Something to do with the old machines around here :-)

Your experience, of once.  Let's just say that I've got a bit of experience running virtualized environments (I do work in amazon's ec2 org after all).  I'd consider it if I had boxes large enough to be worth subdividing.  On the other hand, freebsd until 8.2-rc1 (and pre-releases of 9, ie, no released) doesn't support running on xen.  osx's license doesn't allow running it virtualized, if I remember right.  That just leaves opensolaris which does run on top of xen, but I've never tried it myself.

Anyway.. just need to add osx, which Sean is helping with, and we'll have all of our primary platforms auto-testing d2.

February 20, 2011
OSX desktop won't virtualize--the vm vendors enforce the license. Could use OSX server instead, but...

I'll sort out OSX testing this week with brad. It will just be a matter of some setup on my end.

Sent from my iPhone

On Feb 20, 2011, at 6:16 PM, Brad Roberts <braddr at puremagic.com> wrote:

> On 2/20/2011 6:00 PM, Walter Bright wrote:
>> 
>> 
>> Brad Roberts wrote:
>>> On 2/20/2011 5:25 PM, David Simcha wrote:
>>> 
>>>> What's wrong with virtualization as a solution to the one-box-per-platform problem?  Just use your favorite OS as your host, get a ton of RAM, and run all the rest in VMs.
>>>> 
>>> 
>>> It's a solution, but not a great one.  The build runs are already cpu bound, so diving up the cpu's just means everything goes slower.
>>> 
>>> 
>> 
>> My experience with virtual boxes is they get wiped out every time you do an update on the host. Extremely annoying. I use a separate box per OS. Something to do with the old machines around here :-)
> 
> Your experience, of once.  Let's just say that I've got a bit of experience running virtualized environments (I do work in amazon's ec2 org after all).  I'd consider it if I had boxes large enough to be worth subdividing.  On the other hand, freebsd until 8.2-rc1 (and pre-releases of 9, ie, no released) doesn't support running on xen.  osx's license doesn't allow running it virtualized, if I remember right.  That just leaves opensolaris which does run on top of xen, but I've never tried it myself.
> 
> Anyway.. just need to add osx, which Sean is helping with, and we'll have all of our primary platforms auto-testing d2.
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
« First   ‹ Prev
1 2