I pasted 1k line C++ file into Gemini, along with a screenshot and a trace log and asked it to find the bug. It reasoned for about 5 minutes. Extract of the solution:

There has to be an issue in this sequence for i=21:
V_to_next_xy (norm) is (5.00004113497265e-08, -0.999999999999999, 0). (Correct)
Unnormalized perpendicular P_un = Vec3(V_to_next_xy.y(), -V_to_next_xy.x(), 0.0) should be (-0.999999999999999, -5.00004113497265e-08, 0).
temp_bisector becomes P_un.
temp_bisector.normalize() is called.
The result of this normalization is logged as temp_bisector (result of collinear path): (-1.78813934326169e-07, -0.999999999999984, 0).
This step (5) is where the numerical error occurs. The vector (-0.999…, -5e-8, 0) when normalized should not become (-1.78e-7, -0.999…, 0).
The latter is almost parallel to (0, -1, 0), while the former is almost parallel to (-1, 0, 0).
It’s as if temp_bisector.normalize() for the input (-0.999…, -5e-8, 0) is producing something wildly incorrect, or the vector being normalized was actually (-1.78e-7 * L, -0.999… * L, 0) for some L.
What if temp_bisector = Vec3(V_to_next_xy.y(), -V_to_next_xy.x(), 0.0); itself has precision issues?
If V_to_next_xy.y() is -0.999999999999999 (16 nines), this is -(1.0 - 1e-15).
If V_to_next_xy.x() is 5.00004113497265e-08.
Vec3 tmp = Vec3(-(1.0-1e-15), -5.00004113497265e-08, 0.0).
This should be fine.
The most plausible candidate is Vec3::normalize() failing on this specific input vector (-0.999999999999999, -5.00004113497265e-08, 0).
Perhaps length() computes sqrt(xx + yy + zz).
xx = (-(1.0-1e-15))^2 = (1.0-1e-15)^2 = 1.0 - 2e-15 + 1e-30.
yy = (-5e-8)^2 = 2.5e-15.
xx + y*y = 1.0 - 2e-15 + 1e-30 + 2.5e-15 = 1.0 + 0.5e-15 + 1e-30.
length = sqrt(1.0 + 0.5e-15 + 1e-30). This is extremely close to 1.0.
If this length calculation has any error causing it to be, for example, abs(y) by mistake, then x/length would become x/abs(y) and y/length would become y/abs(y) = sign(y).
x/abs(y) = -1.0 / 5e-8 = -2e7. This is not what’s happening.
The logged value for temp_bisector (-1.78813934326169e-07, -0.999999999999984, 0)
is suspicious because its X component -1.78813934326169e-07 is very close to the X component of V_to_prev_xy (norm) from loop i=21, which is -5.00004113497265e-08, divided by a factor. Or perhaps V_to_next_xy.x() itself was somehow used more directly than -V_to_next_xy.x() in the Y component of the vector passed to normalize.
The logged temp_bisector (result of collinear path) for i=21 is (-1.78813934326169e-07, -0.999999999999984, 0).
Consider Loop i=20: temp_bisector (result of collinear path): (1, 0, 0). Its input for perpendicular construction was V_to_next_xy (norm) = (X_v: 4.9999318885022e-08, Y_v: -0.999999999999999, Z_v: 0).
Perpendicular from this is (Y_v, -X_v, 0) = (-0.999…, -4.999…e-8, 0). Normalizing this gives (-1, -4.999…e-8, 0).
The log for i=20 says it becomes (1,0,0). This is also wrong. It should be (-1, -very_small_y, 0).
The fallback temp_bisector = Vec3(1,0,0) only happens if temp_bisector.normalize() (the one on the perpendicular) also fails.
It seems the normalize() call for the vector constructed as Vec3(V_to_next_xy.y(), -V_to_next_xy.x(), 0.0) is problematic when one component is very small.

It correctly identified that sqrt(_v[0]*_v[0] + _v[1]*_v[1] + _v[2]*_v[2]); had too low precision and using std::hypot(_v[0], _v[1], _v[2]) would likely solve it.

If this is just autocomplete, then I agree that it’s a pretty fancy one.

They installed some sort of sound isolating suspended/floating (?) ceiling in my apartment. I absolutely love it. In my neighbors apartment I could constantly hear people above, but in mine it’s almost always silent.

Earlier today, a publish-access account was compromised for @solana/web3.js, a JavaScript library that is commonly used by Solana dapps. This allowed an attacker to publish unauthorized and malicious packages that were modified, allowing them to steal private key material and drain funds from dapps, like bots, that handle private keys directly. This issue should not affect non-custodial wallets, as they generally do not expose private keys during transactions. This is not an issue with the Solana protocol itself, but with a specific JavaScript client library and only appears to affect projects that directly handle private keys and that updated within the window of 3:20pm UTC and 8:25pm UTC on Tuesday, December 2, 2024.

These two unauthorized versions (1.95.6 and 1.95.7) were caught within hours and have since been unpublished.

We are asking all Solana app developers to upgrade to version 1.95.8. Developers pinned to latest should also upgrade to 1.95.8.

Developers that suspect they might be compromised should rotate any suspect authority keys, including multisigs, program authorities, server keypairs, and so on.

https://github.com/solana-labs/solana-web3.js/releases/tag/v1.95.8

No, of course it’s not surprising that they’re not a charity. Sure, the big app stores exploit their near-monopolies with exorbitant fees.

Good for Apple, Valve and Google, but I think it’s better that game dev studios and app developers get money instead. However, devs don’t currently have a real choice but to pay up.

Competition can change that, so we should support technically worse stores like Epic so developers will not have to pay their unreasonably high fees.

Yeah, I understand why people like and buy from Steam. It gives real value.

However, especially for smaller game studios, I believe I get more value if actual game developers get more money than Steam getting it. Let’s say a studio gets $1m in revenue after years of work. Having $180k more ($120k Epic fee vs $300k Steam fee) to spend on artists and developers for their next games/DLCs is a big difference.

Those $300k is literally 0.003409% of Steam’s revenue (estimated 8.8 billion in 2020). Valve could have an army of over 40,000 developers at a yearly $200k compensation and still be profitable just from selling other people’s games.

So I make a big convenience sacrifice when I buy from Epic. I also don’t like to support Tencent. But unless the dev is selling Steam keys directly from their web site, that’s where they get the most money.

Steam is a better product, but you give less money to the developers of the actual game. Unless it has Steam exclusives (e.g. Steam workshop) I would rather buy wherever I give the devs most money.

Yes, those are all unreasonably high, which is why they have so many billions of dollars in profit. The cost of running their services is a pittance compared to their revenues.

You could make the same argument for voting. What does your little drop in the vote bucket matter? Do you believe voting is a waste of time too?