On Sat Jul 12 11:00:27 2008, [EMAIL PROTECTED] wrote: > > particle's original post was one I requested he make as follow-up to a > discussion that he, chromatic and I had concerning configuration at > YAPC::NA::2008 in Chicago (with additional input from Steve Lembark). > That discussion concerned both how Parrot configuration might evolve and > how it should be tested. particle's specific comments about processes > on Win32 were the first good argument I had heard for fewer (but > inherently more sprawling) test files rather than more (but more sharply > focused) test files. > [snip]
> I have, however, begun to develop a way of running tests for a > particular step class, then gutting the P::C object's data structure and > restoring it to its state at an earlier point in the test file. This > will permit consolidation of multiple test files within a single file. > I've begun that work in the 'parallel' branch in our repository. > particle: Can you do a check out of the 'parallel' branch from our repository and call perl Configure.pl --test=configure? That should give you some speedup in the preconfiguration tests (or, more precisely, in the t/steps/*.t tests -- the t/configure/*.t tests are as yet unchanged). The version of lib/Parrot/Configure/Options/Test.pm found in the 'parallel' branch has been hacked to tell you how long the preconfiguration tests took. You may wish to copy this to trunk so that you get the same feedback when running 'perl Configure.pl --test=configure' in trunk. In my experimentation I have noticed *considerable* variance in the time a given machine takes to run exactly the same set of preconfiguration tests. For example, on my Linux server, the preconfiguration tests currently found in 'parallel' can take between 30 and 36 seconds to complete, while on my pokey iBook G4, nearly the same set of configuration tests can take between 175 and 306 second to complete. So you should probably run the preconfiguration tests in trunk several times in order to get an estimate of how long the tests currently take, then run them several times in 'parallel' branch to see how much improvement has been made. Thank you very much. kid51
