Python added "f strings" recently (read: in 2015)[1], which look like
f"{some_var}"
which evaluates "some_var" in the local scope. Sort of like Ruby's "#{...}" (if I'm remembering that syntax correctly). Rust supports named parameters in format strings[2] but that's not quite the same.
Note that you can do this in old version of Python, too, using the "format-locals" idiom:
some_var = ...
"{some_var}".format(**locals())
Although this does have some limitations regarding variables to strictly being in the local scope, this is a fine idiom if you need to be compatible with older Python versions.
Yes, you can't do something like this in Rust, you'd be doing what's in the quote above; named params are it. You have to do the attribute access/method call when binding the parameter, not applying it to a parameter somehow.
> Tests that only fail in CI are really annoying. I’ve had this a couple of times, and it’s always taken hours to sort out, because the “try something, get results, think about what they mean” cycle is so slow.
To address this, CircleCI has an interesting feature where you can enable SSH access to the build, so one can investigate locally (relative to the build) instead of repeatedly throwing code over the wall and waiting for something remotely meaningful to come back in logs.
Travis actually has this[1], too, if you ask their support to have the feature beta enabled for your repo. A while back, I was having a CI only test failure that was a massive pain to try and debug, and this helped enormously as I could explore the build state and try alternatives without waiting on the typical build time.
It's not a C# thing, it's a floating-point thing. Two numbers which mathematically "should" be equal, might not be due to rounding errors. (In python, 0.15 + 0.15 != 0.1 + 0.2.) So it's risky to compare them with ==, sometimes you'll get the result you expect (and sometimes you can be confident of that) but sometimes you won't. If you can't be sure, you should compare that they're the same within some threshold, but that has pitfalls as well.
(I feel a little silly saying "it's not a language thing" and then "in python", but there may (or may not) be various implementation details which other languages might use to get a different result.)
That's absolutely fine if they are set with explicit values or were assigned with the same double. The main issues used to be with the old x86 80 bit wide floating point registers which meant you could sometimes find x != x depending on whether the number went to memory and back.
There's also oddity around NaN - if x is NaN, then, on a compliant chip, x != x regardless of whether it's ever visited main memory.
If you find some reason to use a NaN inside one of these GeoPoints (at one of the poles, perhaps), and the equality of them depends on the equality of doubles, then you may give your users a bit of a surprise.
I ran into a similar issue years ago. Our tests, written on macos, were failing on linux, because pdftotext was producing different output.
I traced down the logic, added some debugging print statements, and it magically fixed itself.
Eventually, I figured out the issue that they were comparing floats with == and intel processors have a few extra internal bits that disappear when stored. Macos, which uses floats in its UI layer, defaults to adding -ffloat-store to the compile flags to get around similar issues.
I ended up just adding -ffloat-store to our Linux build of pdftotext. (I briefly thought about fixing the comparisons, but it turned out the code was full of them.)
> My next step is definitely to try to find some history of this issue
Well, you know exactly how to reproduce the issue, so git bisect it to find the exact commit that fixed it and how. Granted, it may take a very long time, given the size of .Net Core.
24 comments
[ 1.7 ms ] story [ 66.8 ms ] thread[1]: https://www.python.org/dev/peps/pep-0498/ [2]: https://doc.rust-lang.org/std/fmt/#named-parameters
> ("lhs=({}, {}); rhs=({}, {})", lhs.x, lhs.y, rhs.x, rhs.y)
Python 3.6 added "natively interpolated" f-strings, just replace C#'s `$` prefix by `f`, and even without f-strings you could write e.g.
Rust supports named parameters but IIRC not attribute access or method calls.Fun problem.
To address this, CircleCI has an interesting feature where you can enable SSH access to the build, so one can investigate locally (relative to the build) instead of repeatedly throwing code over the wall and waiting for something remotely meaningful to come back in logs.
[1]https://docs.travis-ci.com/user/running-build-in-debug-mode/
(I feel a little silly saying "it's not a language thing" and then "in python", but there may (or may not) be various implementation details which other languages might use to get a different result.)
If you find some reason to use a NaN inside one of these GeoPoints (at one of the poles, perhaps), and the equality of them depends on the equality of doubles, then you may give your users a bit of a surprise.
[0] https://randomascii.wordpress.com/2012/02/25/comparing-float... [1] https://randomascii.wordpress.com/2017/06/19/sometimes-float...
I traced down the logic, added some debugging print statements, and it magically fixed itself.
Eventually, I figured out the issue that they were comparing floats with == and intel processors have a few extra internal bits that disappear when stored. Macos, which uses floats in its UI layer, defaults to adding -ffloat-store to the compile flags to get around similar issues.
I ended up just adding -ffloat-store to our Linux build of pdftotext. (I briefly thought about fixing the comparisons, but it turned out the code was full of them.)
Well, you know exactly how to reproduce the issue, so git bisect it to find the exact commit that fixed it and how. Granted, it may take a very long time, given the size of .Net Core.