On 25 September 2014 22:27, Dylan Baker baker.dyla...@gmail.com wrote:
Hi Thomas,
I had a chance to run this (both this version and your original
version), and the performance hit is massive on both GL and CL testing.
I'm concerned with introducing a mechanism as generic when it made my
test
Interesting, the first time I ran these I saw a large slowdown, but I
can't see it now. So, I'll take it then
Reviewed-by: Dylan Baker baker.dyla...@gmail.com
On Friday, September 26, 2014 05:05:41 PM Thomas Wood wrote:
On 25 September 2014 22:27, Dylan Baker baker.dyla...@gmail.com wrote:
Hi
Hi Thomas,
I had a chance to run this (both this version and your original
version), and the performance hit is massive on both GL and CL testing.
I'm concerned with introducing a mechanism as generic when it made my
test runs so long that I gave up running them.
We really do want a generic
On 9 September 2014 20:07, Dylan Baker baker.dyla...@gmail.com wrote:
Hi Thomas. Sorry that I broke igt.
I have a few comments, some are stylistic comments, but some are
interface changes I'd like to see.
Thanks for working on this.
Dylan
On Tuesday, September 09, 2014 04:15:12 PM Thomas
The timeout mechanism within igt.py can no longer be used since
get_command_result was renamed and made private in commit 5e9dd69
(exectest.py: rename get_command_result to __run_command). Therefore,
move the timeout mechanism into exectest.py, allowing all test profiles
to use it if needed and
The timeout mechanism within igt.py can no longer be used since
get_command_result was renamed and made private in commit 5e9dd69
(exectest.py: rename get_command_result to __run_command). Therefore,
move the timeout mechanism into exectest.py, allowing all test profiles
to use it if needed and