On Jul 14, 2009, at 10:09 AM, Francis J. Lacoste wrote:
> On July 14, 2009, Gary Poster wrote:
>> I actually left out the time.sleep as a policy-ish decision, wanting
>> the tests to go as fast as possible, but it was an experiment, and
>> I'm
>> happy to switch back to the time.sleep approach.
>>
>
> Right, but know that busy waiting is bad in general because it makes
> it harder
> for the OS to schedule other task (since you are competing for the
> CPU).
Bah, get more cores. :-)
>> Index: z3c/recipe/filetemplate/tests.py
>> ===================================================================
>> --- z3c/recipe/filetemplate/tests.py (revision 101900)
>> +++ z3c/recipe/filetemplate/tests.py (revision 101901)
>> @@ -13,14 +13,21 @@
>>
>> ###########################################################################
>> ###
>>
>> import os
>> +import time
>> import zc.buildout.testing
>> import zc.buildout.tests
>> from zope.testing import doctest
>>
>> -def write_and_wait(dir, *args):
>> +def update_file(dir, *args):
>> + """Update a file.
>> +
>> + Make sure that the mtime of the file is updated so that buildout
>> notices
>> + the changes. The resolution of mtime is system dependent, so we
>> keep
>> + trying to write until mtime has actually changed."""
>> path = os.path.join(dir, *(args[:-1]))
>> original = os.stat(path).st_mtime
>> while os.stat(path).st_mtime == original:
>> + time.sleep(0.2)
>> f = open(path, 'w')
>> f.write(args[-1])
>> f.flush()
>
>
> If you want the test to run as fast as possible I suggest:
>
> while True:
> # Write the change
> # ...
> if os.stat(path).st_mtime != original:
> break
> time.sleep(0.2)
>
> Use it if you like it.
On Jul 14, 2009, at 10:09 AM, Francis J. Lacoste wrote:
> On July 14, 2009, Gary Poster wrote:
>> I actually left out the time.sleep as a policy-ish decision, wanting
>> the tests to go as fast as possible, but it was an experiment, and
>> I'm
>> happy to switch back to the time.sleep approach.
>>
>
> Right, but know that busy waiting is bad in general because it makes
> it harder
> for the OS to schedule other task (since you are competing for the
> CPU).
Bah, get more cores. :-)
>> Index: z3c/recipe/ filetemplate/ tests.py ======= ======= ======= ======= ======= ======= ======= ======= ==== filetemplate/ tests.py (revision 101900) filetemplate/ tests.py (revision 101901) ####### ####### ####### ####### ####### ####### ####### ####### ####### ##### path).st_ mtime path).st_ mtime == original: path).st_ mtime != original:
>> =======
>> --- z3c/recipe/
>> +++ z3c/recipe/
>> @@ -13,14 +13,21 @@
>>
>> #######
>> ###
>>
>> import os
>> +import time
>> import zc.buildout.testing
>> import zc.buildout.tests
>> from zope.testing import doctest
>>
>> -def write_and_wait(dir, *args):
>> +def update_file(dir, *args):
>> + """Update a file.
>> +
>> + Make sure that the mtime of the file is updated so that buildout
>> notices
>> + the changes. The resolution of mtime is system dependent, so we
>> keep
>> + trying to write until mtime has actually changed."""
>> path = os.path.join(dir, *(args[:-1]))
>> original = os.stat(
>> while os.stat(
>> + time.sleep(0.2)
>> f = open(path, 'w')
>> f.write(args[-1])
>> f.flush()
>
>
> If you want the test to run as fast as possible I suggest:
>
> while True:
> # Write the change
> # ...
> if os.stat(
> break
> time.sleep(0.2)
>
> Use it if you like it.
Sure, cool. Done.
Thanks
Gary