Since we have achieved the single largest feasible speedup discussed in
this thread -- consolidation of the steps in t/steps/ -- I am going to
mark this ticket resolved.
I am opening a new RT, 57492, calling for exploration of the feasibility
of consolidating or otherwise speeding up the tests in
On Wed, Jul 30, 2008 at 4:25 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> On Tue Jul 29 11:01:12 2008, particle wrote:
>
>>
>>
>> the failing test:
>> t/steps/auto_ctags-01ok 1/31
>> # Failed test 'Got expected result'
>> # at t/steps/auto_ctags-01.t line 65.
>>
On Tue Jul 29 11:01:12 2008, particle wrote:
>
>
> the failing test:
> t/steps/auto_ctags-01ok 1/31
> # Failed test 'Got expected result'
> # at t/steps/auto_ctags-01.t line 65.
> t/steps/auto_ctags-01NOK 17/31# got:
> 'yes'
> # ex
On Tue, 29 Jul 2008, James Keenan via RT wrote:
> On Tue Jul 29 11:04:59 2008, doughera wrote:
> > On Tue, 29 Jul 2008, James Keenan via RT wrote:
> > The parallel branch does seem to run in about half the time. This is
> > with
> > perl-5.8.8 on Solaris/SPARC, where perl was built with Sun's cc,
On Tue Jul 29 11:01:12 2008, particle wrote:
>
> overall, i'm impressed at the 50% speedup. given that these are
> relatively fast tests, it makes sense that since there are half as
> many files (and therefore half as many invocations of perl), the tests
> take half the time to run. other than my
On Tue Jul 29 11:04:59 2008, doughera wrote:
> On Tue, 29 Jul 2008, James Keenan via RT wrote:
> The parallel branch does seem to run in about half the time. This is
> with
> perl-5.8.8 on Solaris/SPARC, where perl was built with Sun's cc, but
> I'm
> trying to build parrot with gcc. Here are the
On Tue Jul 29 11:01:12 2008, particle wrote:
>
> the failing test:
> t/steps/auto_ctags-01ok 1/31
> # Failed test 'Got expected result'
> # at t/steps/auto_ctags-01.t line 65.
> t/steps/auto_ctags-01NOK 17/31# got:
> 'yes'
> # expect
On Tue, 29 Jul 2008, James Keenan via RT wrote:
> For those of you who are interested in benchmarking the difference, I
> recommend you do a checkout of the parallel branch and run 'perl
> Configure.pl --test=configure', as I've included a line reporting the
> elapsed time. Then do a fresh checko
On Tue, Jul 29, 2008 at 4:28 AM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> I have prepared a patch which represents an 'svn diff' between trunk and
> the 'parallel' branch at the point of the branch's inception. Rather
> than swamp your inboxes, I'm posting it here:
>
> http://thenceforward
I have prepared a patch which represents an 'svn diff' between trunk and
the 'parallel' branch at the point of the branch's inception. Rather
than swamp your inboxes, I'm posting it here:
http://thenceforward.net/parrot/diff.trunk.parallel.txt
This patch is more for review than application. Bec
I've added references to 7 tickets opened last year focusing on tests
for the 'gen' step classes.
As part of my work on this ticket in the 'parallel' branch, I have
finally begun writing some basic tests for the 'gen' configuration
steps: config/gen/*.pm. These steps -- which are the final
configuration steps -- primarily look data up in source files, files
generated earlier in the configurati
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 concerne
On Sun Jul 13 19:25:11 2008, pmichaud wrote:
> On Sat, Jul 12, 2008 at 11:00:29AM -0700, James Keenan via RT wrote:
>
> Here's a question I have -- what are the various use cases for running
> the various test targets? Perhaps if we enumerate the use cases we
> could understand it better and make
On Sat, Jul 12, 2008 at 11:00:29AM -0700, James Keenan via RT wrote:
> On Sat Jul 12 09:33:35 2008, coke wrote:
> >
> > Another solution here would be to not run them by default. The purpose
> > of 'make test'
> > should be to verify that the parrot functionality works on the target
> > system.
>
On Sat Jul 12 09:33:35 2008, coke wrote:
>
> Another solution here would be to not run them by default. The purpose
> of 'make test'
> should be to verify that the parrot functionality works on the target
> system.
If speed is your concern, you can call 'make coretest'. We've had that
functional
On Tue Jul 08 22:59:40 2008, particle wrote:
> the configure tests take too much time to run, and should be sped up
> by whatever means necessary so as to take a much smaller percentage of
> the overall time for the test suite.
Another solution here would be to not run them by default. The purpose
17 matches
Mail list logo
