At my local hackerspace, people sometimes laser cut solder stencils out of transparencies -- the plastic sheets you use with overhead projecters. The trick is to put a piece of paper under the transparency when laser cutting, otherwise they tend to melt too much and deform, but somehow the piece of paper prevents this, maybe the laser needs something non-transparent to interact with to get the heat in quickly and move on quickly. Anyway they worked pretty well, but obviously not as durable as steel, so after some number of uses they start to wear out. (Can't remember how many really, but probably something like 20? more than just 3 or 4 I think. Probably also depends on the density of holes, a big swiss cheesed area will fail sooner.) If the circuit's not too big you can cut several stencils out of one transparency all in one go.
No, you don't commit trash to a public branch, EVER, if you can help it. Your commits are as perfect as you can make them, and that does not mean squashed in a trash compactor. That means one logical idea per commit, compiles and works as perfectly as you can make it. Use stgit, and this is easy. You do not break git bisect. No need to squash your trash in a trash compactor. Your standards are lower than mine, not higher.
> Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze.
I mean, just use stgit[1] to maintain a stack of patches instead of parallel branches, it's so much better. You can easily wrangle thousands of patches (aka commits) with stgit.
A lot of people, on first encountering stgit, read a bit about it, think "why do I need this? I can do the same thing with just plain ol' git.". Yeah, you can. But not at scale. Not practically. Not with thousands of commits. And it makes the case when you just have a few tens of commits absolutely trivial. Try it for awhile and you'll find it indispensible.
He's a mathematician, so what he means by "in general", is "in every possible case", or "without exception", so what I think he means is, "not all bugs will be found by code review." I agree it probably could have been made more clear.
But a) that's not what his words mean in English and b) that's irrelevant.
"in general" quantifies over all occasions, not over all bugs on one occasion.
To quote my own response:
===
Apparently the mathematician author doesn't understand the meaning of his own natural language quantifiers. “it is not in general possible to find bugs by examining the code” means “it is not in general possible to find ANY bugs by examining the code”, not “it is not in general possible to find ALL bugs by examining the code”.
And the first interpretation is relevant but wrong, whereas the second interpretation is true but irrelevant.
P.S. It seems that the author meant to say “it is not in general possible to find a given bug by examining the code”, i.e., "not (for all bugs B it is possible to find B)", which again is true but not relevant.
Curl Noise[1] is also cool. I've used it to create some gas giant planets for video games [2] though I used opensimplex noise [3] rather than perlin as the base noise, but either will work.
My own efforts in this area amount to creating the game, Space Nerds in Space[1], which is a LAN game in which everyone gathers in a room with their computers, and each computer acts as one of the stations on the bridge of a starship: navigation, weapons, science, comms, engineering, damage control, etc. Multi-bridge is supported as well, so if you can overcome the insurmountable task of gathering enough people together, you can indulge in that luxury. This is in the same genre as such games as Artemis: spaceship bridge simulator and Empty Epsilon, but with the additional hurdle that it's linux only. Good luck mustering enough spacenerds. If there are missing features, well, it's open source, so it's got that going for it, which is nice.
[1] https://github.com/gmn/nanotts