On 09/03/2012 01:52 PM, Eric Wilhelm wrote:
> # from Mark Stosberg on Friday 31 August 2012:
>> I looked into the App/Prove.pm source code and immediately spotted the
>> issue. It hardcodes that all "rules" should run in parallel. Thus,
>> there would be no way to specify that something should never be run
>> in parallel with anything else.
> 
> Hi Mark,
> 
> See also: 'rules' in the TAP::Harness pod, the source/comment on 
> TAP::Parser::Scheduler (_set_rules() &c.), and t/scheduler.t.

Thanks for the reply, Eric. I did look in some detail at the related
scheduling code as part of preparing the documentation patch I submitted.

> There is a disconnect between command-line flags to prove and the data 
> structure there.  I haven't had time to totally grok the scheduler code, 
> but I think you need something different than what the --rules option 
> was written to do (though we would have to ask someone who is using it 
> whether your patch breaks that use case -- I think the usage was to 
> prevent just a few tests from running at the same time as each other, 
> not from all others.)
> 
> In your case, it might be better to be able to just pass a schedule of 
> nested arrays (maybe as json or something?)

At this point, I have confirmed that the right schedule is being
generated and used. However, it is triggering a bug elsewhere, perhaps
in the aggregation or multiplexing code.  At the end of the run, there
is simply no summary report generated.

However, I may not pursue this further soon at this point because of a
course change.

It's been so slow to get proper support for exceptions to parallel test
runs, that I decided to dig into the problematic tests to see if I could
make them parallel friendly. It turns out that was faster just to fix
the tests. :)

  Mark

Reply via email to