Wed, 24 Aug 2016 05:04:46 +0200 bisect: factor commonly update sequence
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 24 Aug 2016 05:04:46 +0200] rev 30127
bisect: factor commonly update sequence For now, This remains a closure in the module to avoid circular import with used module.
Wed, 24 Aug 2016 04:25:20 +0200 bisect: move check_state into the bisect module
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 24 Aug 2016 04:25:20 +0200] rev 30126
bisect: move check_state into the bisect module Now that the function is simpler, we resume our quest to move the logic into the bisect module. In the process, we add basic documentation.
Wed, 24 Aug 2016 04:23:13 +0200 bisect: simplify conditional in 'check_state'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 24 Aug 2016 04:23:13 +0200] rev 30125
bisect: simplify conditional in 'check_state' Now that extra code about "updating" flag have been removed, we can simplify the condition flow and remove a level.
Wed, 24 Aug 2016 04:22:40 +0200 bisect: remove code about "update-flag" in check_state
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 24 Aug 2016 04:22:40 +0200] rev 30124
bisect: remove code about "update-flag" in check_state Now that the flag dedicated to updating the flag are handled earlier, we do not need to handle them in the 'check_state' function.
Sun, 09 Oct 2016 03:50:55 +0200 bisect: rename 'check_code' to match our naming scheme
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 09 Oct 2016 03:50:55 +0200] rev 30123
bisect: rename 'check_code' to match our naming scheme We need to do it early, otherwise 'check-commit' will complain every time we touch it.
Wed, 24 Aug 2016 04:48:17 +0200 bisect: minor movement of code handle flag updating state
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 24 Aug 2016 04:48:17 +0200] rev 30122
bisect: minor movement of code handle flag updating state The code flag handling is quite complicated, we are moving code around to prepare further simplification.
Sun, 09 Oct 2016 04:37:02 -0400 test-clone: discard lock-related messages
Augie Fackler <augie@google.com> [Sun, 09 Oct 2016 04:37:02 -0400] rev 30121
test-clone: discard lock-related messages We can't predict where those will show up and they're not super-important for the contents of this particular test, so just drop them. Further reduces the flakiness of the test to zero.
Sun, 09 Oct 2016 04:25:22 -0400 test-clone: fix some instability in pooled clone race condition test
Augie Fackler <augie@google.com> [Sun, 09 Oct 2016 04:25:22 -0400] rev 30120
test-clone: fix some instability in pooled clone race condition test Healthy output (one log file mentioning "existing pooled" and one mentioning "new pooled") will now print in a stable order, but unhealthy output will print some sort of error. This reduces the flakiness of the test from 55% to 38%. My next patch makes it completely stable.
Sun, 09 Oct 2016 17:44:23 +0200 py3: add an os.fsencode backport to ease path handling
Martijn Pieters <mjpieters@fb.com> [Sun, 09 Oct 2016 17:44:23 +0200] rev 30119
py3: add an os.fsencode backport to ease path handling
Sun, 09 Oct 2016 14:10:01 +0200 py3: a second argument to open can't be bytes
Martijn Pieters <mjpieters@fb.com> [Sun, 09 Oct 2016 14:10:01 +0200] rev 30118
py3: a second argument to open can't be bytes This fixes open(filename, 'r'), open(filename, 'w'), etc. calls. In Python 3, that second argument *must* be a string, you can't use bytes. The fix is the same as used with getattr() (where the second argument must also always be a string); in the tokenizer, where we detect calls, if there is something that looks like a call to open (and is not an attribute, so the previous token is not a "." dot) then make sure that that second argument is not converted to a `bytes` object instead. There is some remaining issue where the current transformer will also rewrite open(f('foo')). However this also affect function for which we perform similar rewrite ('getattr', 'setattr', 'hasattr', 'safehasattr') and will be dealt with in a follow up.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip