This is causing the the test to be largely ignored, and disrupts regular testing
(including in continuous integration) where an integration can fail just
because this tests fails for "expected" reasons.
We should re-enable the test once it is has a way to tolerate the
"expected" failure, perhaps using some notion of statistical confidence
to determine if the failure is real.
We are still hitting what looks like a compiler bug:
error: type alias 'SubSequence' circularly references itself
which is emitted for every minimal collection type.
We don't want to be at the whims of the system on what to do with an
uncaught exception; we need to make sure its message gets printed to
stderr so that the parent process can check it.
(There's a bit of trickery here to see if the class looks like an
NSException; otherwise we lose the name of the exception and just get
the reason.)
Generalized bridging has fully subsumed most of these. NSError is
still special, and _convertStringToNSString remains for the the
runtime's implementation of SwiftObject's -description method.
Bump the number of trials from 10 to 14, which makes the test orders of
magnitude less likely to fail. For a range of size 10, doing 10 trials
meant that a single call to checkRange would fail ~0.03% of the time;
with 14 trials the spurious failure rate is ~0.0003%. We have 10 calls
to checkRange in this test with ranges of size <= 10.
While this test didn't fail that often before, we have a very large
number of automated builds and it has been a constant low-level source
of friction that this test fails and we have to look at and then ignore
the results.
The repo contains roughly 80 Python scripts. "snake_case" naming is used for
local variables in all those scripts. This is the form recommended by the PEP 8
naming recommendations (Python Software Foundation) and typically associated
with idiomatic Python code.
However, in nine of the 80 scripts there were at least one instance of
"camelCase" naming prior to this commit.
This commit improves consistency in the Python code base by making sure that
these nine remaining files follow the variable naming convention used for
Python code in the project.
References:
* PEP 8: https://www.python.org/dev/peps/pep-0008/
* pep8-naming: https://pypi.python.org/pypi/pep8-naming
