tomn

Bullets are a bad example because they have multiple properties which makes them much harder to localise than many other sounds.

I'm pretty sure most people can localise a vehicle emitting broadband noise (engine or white reversing sound) in the conditions that matter.

> They have to be loud enough to be heard through hearing protection.

It's kind of a nit-pick, but this is not really true.

Very approximately, you will perceive a sound if it is above your threshold of hearing, and also not masked by other sounds.

If you're wearing the best ear defenders which attenuate all sounds by about 30dB, and you assume your threshold of hearing is 10dBSPL (conservative), any sound above 40dBSPL is above the threshold of hearing. That's the level of a quiet conversation.

And because your ear defenders attenuate all sounds, masking is not really affected -- the sounds which would be masking the reversing beepers are also quieter.

There are nuances of course (hearing damage, and all the complicated effects that wearing ear defenders cause), but none of them are to the point that loud reversing noises are required because of hearing protection -- they are required to be heard over all the other loud noises on a construction site.

> The utility of having a backup beeper or any noise making device on that site is thus zero.

The inverse square law says otherwise; on site the distances will be much more apparent.

Yeah, it's certainly doable, just a bit tricky because the spoil-board is not attached to the base, and is replaced nearly every time. It also needs at least one extra tool set-up.

If I needed a lot of double-sided boards it would be worth optimising this, but I don't really, single-sided (or the second side being 100% ground) is generally sufficient.

You're comparing a hub dynamo with cheap low-capacity rechargeable lights.

Rechargeable lights from the usual suspects are generally not good, they are expensive for what they are, have low capacity, and don't have swappable standard-size batteries.

They make dynamo systems look like a good deal, but if typical battery-powered lights were even close to their theoretical optimum I think people would be much less enthusiastic about dynamos.

A spare battery in your saddle-pack solves most of those problems.

If you're worried about being without light, a (typical) dynamo system is more complicated and exposed than a battery system, so will be more prone to failure.

I get why people like them, but they make way less sense when you work out the capacity of an equivalent weight (not to mention cost) of lithium cells.

It's easy to get to about 90Wh, which will run a dynamo-powered light for 30 hours on max (most dynamos seem to be rated 3W).

There are definitely cases where it makes sense, and not having to keep batteries charged is nice, it's just easy to miss how good batteries are these days.

I don't see why it should be so binary. I said it "mostly" just works because there are no packaging systems which do exactly what you want 100% of the time.

I've had plenty of problems with node, for example. You mentioned nix, which is much better, but also comes with tons of hard trade-offs.

If a packaging tool doesn't do what i wanted, but I can understand why, and ultimately the tool is not to blame, that's fine by me. The issues I can think of fit reasonably well within this scope:

- requirement version conflicts: packages are updated by different developers, so sometimes their requirements might not be compatible with each other. That's not pip's fault, and it tells you what the problem is so you can resolve it.

- code that's not compatible with updated packages: this is mainly down to requirement versions which are specified too loosely, and not the fault of pip. If you want to lock dependencies to exact versions (like node does by default) you can do this too (with requirements.txt). It's a bit harsh to blame pip for not doing this for you, it's like blaming npm for not committing your package.lock. It would be better if your average python developer was better at this.

- native library issues: some packages depend on you having specific libraries (and versions thereof) installed, and there's not much that pip can do about that. This is where your "ssl issues" come from. This is pretty common in python because it's used so much as "glue" between native libraries -- all the most fun packages are wrappers around native code. This has got a lot better in the past few years with manylinux wheels (which include native libraries). These require a lot of non-python-specific work to build, so i don't blame pip where they don't exist.

It's not perfect, but it's not a big enough deal to rant about or reject entirely if you would otherwise get a lot of value out of the ecosystem.

Yeah, I thought about that too, but if you want to process more than 255 values this might not be valid, depending on the implementation of count_if.

Just to correct my own comment:

> with an uint8_t local variable and size_t return value, an earlier optimisation removes the cast to uint8_t, because it only has an effect when undefined behaviour has been triggered

In this case, there is no undefined behaviour, because a narrowing cast to an unsigned type is well-defined. So, this could never have been a good explanation.

I'm not sure how "it can go the other way around too" -- in that case (assigning to a uint8_t local variable), it seems like that particular optimisation is just not being applied.

Interestingly, if the local variable is "volatile uint8_t", the optimisation is applied. Perhaps with an uint8_t local variable and size_t return value, an earlier optimisation removes the cast to uint8_t, because it only has an effect when undefined behaviour has been triggered? It would certainly be interesting to investigate further.

In general I agree that being more explicit is better if you really care about performance. It would be great if languages provided more ways to specify this kind of thing. I tried using __builtin_expect to trigger this optimisation too, but no dice.

Anyway, thanks for the interesting article.

Oh right, I didn't see it in a couple of passes (and searching for cast); for anyone else looking it's in the 3rd footnote. Thanks.