On Sun, Jun 05, 2016 at 01:00:03AM +0200, Zope tests summarizer wrote:
[1] winbot / ZODB_dev py_270_win32 [2] winbot / ZODB_dev py_270_win64 [3] winbot / ZODB_dev py_330_win32 [4] winbot / ZODB_dev py_330_win64 [5] winbot / ZODB_dev py_340_win32 [6] winbot / ZODB_dev py_340_win64
Looking closer at this maybe the issue is with the clock resolution? AssertionError: 1465090499.6140003 not less than 1465090499.614 All the failures are raised by the _checkHistory helper in ZODB/tests/HistoryStorage.py. The value on the left comes from time.time(). The value on the right comes from storage.history()[-1]['time'], which comes from TimeStamp(tid).timeTime(). Hmmm. I spy a second = round(b * _SCONV, 6) #microsecond precision in timestamp.py, but a simple return SCONV * v; in _timestamp.c. Could this be it? The C module fails to build, we fall back to pyTimeStap, which artificially reduces the precision of timestamps to microseconds? Let's experiment! (Digression: https://github.com/zopefoundation/persistent/issues/41) Ok, that's not it. But look here: >>> t = time.time() >>> t - TimeStamp(*time.gmtime(t)[:5] + (t % 60,)).timeTime() 2.384185791015625e-07 AFAICT the test is incorrect: it assumes that t1 = time.time() # some small time passes doing stuff t2 = time.time(), converted to TimeStamp(), then converted back assert t1 < t2 but this can fail due to the above. Only if that's the case, why doesn't the test fail on Linux?
[7] winbot / z3c.batching_py_330_win32 [8] winbot / z3c.batching_py_330_win64
Should be fixed now.
[27] winbot / z3c.table_py_330_win32 [28] winbot / z3c.table_py_330_win64 [29] winbot / z3c.table_py_340_win32 [30] winbot / z3c.table_py_340_win64
Should be fixed now because of the z3c.batching fix. Marius Gedminas -- BYTE editors are people who separate the wheat from the chaff, and then carefully print the chaff.