wicked

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.

The mean IQ level was more in the region with medium fluoride concentration in drinking water (56.68) compared to areas with low fluoride concentration (41.03) and high fluoride concentration (31.59).

So according to that study, having "medium levels" (1.2-2ppm) of fluoride is much better. I checked three random water reports in Florida which had 0.5, 0.7 and 0.9 ppm.

Which is why I think sensitivity is the wrong word.

"It depends on the day whether more pleasure would be a good or bad thing for me"

That's a more precise version of your statement, I think.

It's pretty simple to rate limit requests yourself.

Your answer doesn't give confidence that you care about how the code looks. Could imply that you're sloppy. Some people are very opiniated about style and think it matters a lot. They would be unhappy with people who say it doesn't really matter.

They'd likely welcome fixes or comments on style. Other people would be very angry if you held up their PR with such trivialities.

I had strong style preferences when I was younger, but after working on so many projects with different styles I really don't care anymore about any particular style. I just make sure to seamlessly match the style of the code around it.

Use ccache.

Not enough information.

New team member? Show them the style guide and where it doesn't match.

Is the style guidelines consistently followed elsewhere? If not, I'd just approve it.

Do I have a good relationship with the other developer, and can they handle criticism? If not, I probably would not want to be the one reviewing it, but if I did I would likely let it go and fix it later. Fight more important battles.

Otherwise, how important is that piece of code? I'd immediately approve a one-off script, but if it's an core piece of code, I assume the dev missed it and point it out. Happens to everyone.

etc. etc.

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

https://en.wikipedia.org/wiki/Poe%27s_law

Never say never. 1/0 = 0

The US started using mailboxes 14 years after the UK

In 1849, the Royal Mail first encouraged people to install letterboxes to facilitate the delivery of mail. Before then, letterboxes of a similar design had been installed in the doors and walls of post offices for people to drop off outgoing mail.

In 1863, with the creation of Free City Delivery, the US Post Office Department began delivering mail to home addresses.