[phobos] [D-Programming-Language/phobos] 3cf671: Add std.parallelism.

[Brad Roberts]

On Wed, 27 Apr 2011, Don Clugston wrote:

> On 27 April 2011 20:06, Brad Roberts <braddr at puremagic.com> wrote:
> > On 4/27/2011 7:53 AM, David Simcha wrote:
> >>
> >>
> >> On Wed, Apr 27, 2011 at 12:10 AM, Brad Roberts <braddr at puremagic.com <mailto:braddr at puremagic.com>> wrote:
> >>
> >>     It's a dual core amd:
> >>
> >>     vendor_id       : AuthenticAMD
> >>     cpu family      : 15
> >>     model           : 75
> >>     model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
> >>     stepping        : 2
> >>     cpu MHz         : 1000.000
> >>     cache size      : 512 KB
> >>     flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht
> >>     syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic
> >>     cr8_legacy
> >>
> >>     Actually, showing up on one box but not another is strong evidence of a concurrency bug in my experience.  Different
> >>     cpu's at different speeds, with different speed memory and other side components change timings enough to expose bugs
> >>     that otherwise haven't occurred elsewhere.
> >>
> >>
> >> Also, is there a way I can trigger the auto tester to run a few more times w/o committing anything?  Everything passed
> >> on the latest run except Windows, which is broken for unrelated reasons, but I want to see whether I've solved the
> >> problem or the issue is non-deterministic and I just got lucky.  (On FreeBSD everything started working after a change
> >> that shouldn't have mattered, but my gut feeling is that the failure here was due to a codegen bug.)
> >
> > It's the easiest way for anyone other than me right now.  A commit to any of the three key packages triggers a rebuild
> > of all of them on every platform.
> 
> BTW: It seems to not do that in all cases. I made a change to Phobos'
> win32.mak almost immediately after the Windows test started running.
> It should have run the tests again as soon as it finished, but it
> didn't. It waited until the next commit.

I'll check to see why it didn't (was it today?).  There's a couple things 
that can go wrong.  What I've seen in the past one or two instances I've 
noticed is that github fails to send the notification for some reason.  
It's annoying, but non-fatal since each run syncs to current code.