Readit News logoReadit News
tomn commented on The Effect of Noise on Sleep   empirical.health/blog/eff... · Posted by u/brandonb
sidewndr46 · 6 months ago
You just believe you can sense the direction of loud noises in urban environments. Our nervous system has no "404 not found" for positional awareness. Even after severe head trauma, you have a sense of position for everything. It's so wrong as to be useless, but you have it.

Ask anyone who's been at a shooting in a city. Everyone gives a different answer for where the shooter was at. It's such a severe issue the US Army has microphone arrays they equip urban combat vehicles with. Even with bullets actually bouncing off the armor the troops cannot accurately locate the direction of the shooter(s).

tomn · 6 months ago
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.

tomn commented on The Effect of Noise on Sleep   empirical.health/blog/eff... · Posted by u/brandonb
sidewndr46 · 6 months ago
They have to be loud enough to be heard through hearing protection. The amplitude is a feature.

It's a "solved problem" in the sense that nuclear energy is a solved problem. There's no mandate to actually see widespread roll out of anything that may be a better solution.

There's a construction site near me at present. There is always 1 machine in reverse, at all times. The utility of having a backup beeper or any noise making device on that site is thus zero. It is the single largest source of noise pollution, larger than the roadway

tomn · 6 months ago
> 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.

tomn commented on Jokes and Humour in the Public Android API   voxelmanip.se/2025/06/14/... · Posted by u/todsacerdoti
yomimiva · 6 months ago
tomn · 6 months ago
looking around a bit, it's used as an example in the documentation:

https://github.com/haiku/haiku/blob/7d07c4bc739dbf90159a5c02...

This is actually a great reason to keep it around; it's as simple as possible, and nothing uses it so it's easy to find the relevant bits of code.

tomn commented on Building a Tiny CNC Router for Making Circuit Boards   tomn.co.uk/posts/2025/May... · Posted by u/eldog_
yetihehe · 7 months ago
> The support for using a camera on the spindle is fun, though also fiddly. Once calibrated, it can be used to find the position of features, in order to set a zero position, or even correct for rotation. In theory, this offers a nice workflow for making double-sided circuit boards, by isolation routing and drilling the first side, and using the drilled holes to align the second side.

Drill two holes in base plate with known distance, then drill the same two holes in pcb. Mount board with some steel pins. When you need to rotate, you have reliable indexing.

tomn · 6 months ago
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.

tomn commented on Making a smart bike dumb so it works again   francisco.io/blog/making-... · Posted by u/franciscop
alanfranz · 8 months ago
I suppose you’re a casual cyclist and you don’t commute on a daily basis.

If you commute on a daily basis, a hub dynamo and light system is a bliss. Just hop on the bike and go. I have used bikes with Shimano, SP and Son for thousands of kms in all kind of weather and never really experienced a fault. It’s as simple as car lights - you just take them for granted.

With battery powered lights you need to take them off and put them back; recharge them; remember to bring them with you and not lose them. A spare battery pack is not enough (front and rear) and may not work during cycling (not all lights can be charged while turned on). And, low quality battery powered lights tend to quickly break (2-3 years) while I now realize one of my b+m systems is 10y old already. Good battery powered lights will probably last more, but they’re as expensive as dynamo powered ones.

So yeah, battery is ok and cheap for casual cycling, but very suboptimal if you want reliable lights every day throughout the year.

tomn · 8 months ago
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.

tomn commented on Advanced Python Features   blog.edward-li.com/tech/a... · Posted by u/BerislavLopac
red_admiral · 8 months ago
This sounds fun if you have 10x programmers or at least IQ > 140 programmers in charge. Last place I worked, I was told never use "smart" tricks if you can do the same thing in a simpler way. For-else and f-strings and := sound like harmless enough (though the last one is controversial); "with" is useful for resources that need to be deallocated but "yield"? Really? "more readable" when you slap a decorator on the thing? Why are we packing the enter and exit operations into a single function?

Playing with the typesystem and generics like this makes me worry I'm about to have a panic attack.

Give me code that I can understand and debug easily, even when I didn't write it; don't do implicit magical control flow changes unless you have a very good excuse, and then document both the how and the why - and you'll get a product that launches earlier and has fewer bugs.

Sometimes, a few more if statements here and there make code that is easier to understand, even if there's a clever hack that could cut a line or two here and there.

tomn · 8 months ago
The simple contextlib.contextmanager example doesn't really sell the benefits.

The main one is that it makes error handling and clean-up simpler, because you can just wrap the yield with a normal try/catch/finally, whereas to do this with __enter__ and __exit__ you have to work out what to do with the exception information in __exit__, which is easy to get wrong:

https://docs.python.org/3/reference/datamodel.html#object.__...

Suppressing or passing the exception is also mysterious, whereas with contextlib you just raise it as normal.

Another is that it makes managing state more obvious. If data is passed into the context manager, and needs to be saved between __enter__ and __exit__, that ends up in instance variables, whereas with contextlib you just use function parameters and local variables.

Finally, it makes it much easier to use other context managers, which also makes it look more like normal code.

Here's a more real-world-like example in both styles:

https://gist.github.com/tomjnixon/e84c9254ab6d00542a22b7d799...

I think the first is much more obvious.

You can describe it in english as "open a file, then try to write a header, run the code inside the with statement, write a footer, and if anything fails truncate the file and pass the exception to the caller". This maps exactly to the lines in the contextlib version, whereas this logic is all spread out in the other one.

It's also more correct, as the file will be closed if any operation on it fails -- you'd need to add two more try/catch/finally blocks to the second example to make it as good.

tomn commented on Making a smart bike dumb so it works again   francisco.io/blog/making-... · Posted by u/franciscop
tomsmeding · 8 months ago
Not having to take the light off the bike and charge it and then forget to take it back to the bike, not to mention forgetting charging it and finding out when it's dark, is completely worth having a dynamo.
tomn · 8 months ago
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.

tomn commented on Making a smart bike dumb so it works again   francisco.io/blog/making-... · Posted by u/franciscop
dobladov · 8 months ago
I can't state how convenient hub dynamos are, no noise, no maintenance, unlikely to be robbed without stealing the whole bike, it just works, perfect for a city bike.
tomn · 8 months ago
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.

tomn commented on Apple M3 Ultra   apple.com/newsroom/2025/0... · Posted by u/ksec
pmarreck · 10 months ago
> mostly just work

that's not good enough. If I'm in the business of writing Python code, I (ideally) don't want to _also_ be in the business of working around Python design deficiencies. Either solve the problem definitively, or do not try to solve the problem at all, because the middle road just leads to endless headaches for people WHILE ALSO disincentivizing a better solution.

Node has better dependency management than Python- And that's really saying something.

tomn · 10 months ago
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.

tomn commented on Improving on std:count_if()'s auto-vectorization   nicula.xyz/2025/03/08/imp... · Posted by u/nicula
gblargg · 10 months ago
I was hoping you could just provide an iterator_traits with a uint8_t difference type, but this is tied to the iterator type rather than specified separately, so you'd need some kind of iterator wrapper to do this.
tomn · 10 months ago
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.

u/tomn

KarmaCake day368November 12, 2009
About
hn@tomn.co.uk

https://www.tomn.co.uk/

https://github.com/tomjnixon

View Original