1,988 karma · joined December 1, 2014
No, you just have to cook meals that freeze well and learn to use your freezer.
Why would you put uncopyrightable code into your codebase?
Nah, in my experience, if you've got good commit hygiene you can often merge even ancient commits.
Here's a pretty hefty commit I merged five years after it was originally written, converting a ~100k line codebase from GTK to SDL2, written in 2015, committed in 2020, with tons of development in between, with "10 files changed, 777 insertions(+), 804 deletions(-)"
https://github.com/smcameron/space-nerds-in-space/commit/4ab...
I was expecting it to be a bit of a nightmare, but it really wasn't bad at all.
So you're the one breaking git bisect all the time. Grrrr.
Use stgit and make decent commits instead of rolling in the dirt like an animal.
This shows up in the Aerosmith song, "Sweet Emotion"
Use something like stacked git[1], and then it's just one "stg pop" and poof, they're gone.
I worked for HP on storage drivers for a decade or so, and had their been a stable ABI, HP would have shipped proprietary storage drivers for everything. Even without a stable ABI, they shipped proprietary drivers at considerable effort, compiling for myriad different distro kernels. It was a nightmare, and good thing too, or there wouldn't be any open source drivers.
In both Lisp, and C++, taking some isolated snippet from a codebase, you can't quite really be sure what it's doing without reading the rest of the program because of what might be called the "excessive" power of the languages.
In C, it is much more likely that you can look at an isolated snippet of code from some codebase and be reasonably sure about what it is doing, and be able to extract this snippet more or less as-is, and re-use it in some other, unrelated code base. At least, this has been my experience, ymmv.
[1] https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh
I disagree with this premise. I suspect that 20 to 30% success rate is not at all bad, but rather excellent. Compare to artillery with shells costing a few thousand each on the low end, to $100k+ for more advanced rounds, with 100s or 1000s fired per casualty.
[1]https://www.atarimagazines.com/creative/v9n12/82_MemoryShift...
I wrote the program that creates that. When I wrote it, my goal was to make a procedurally generated gas giant planet of some sort, but I didn't even know if what I was attempting would work (and for a period of about a month, it didn't work). I had/have only rudimentary control over the output. I can control the colors that go into it. I can control, to some degree, the scale of the "swirliness", but not the details of the swirliness. I can control how long I let the "swirliness" progress, and a few other things. But, I never know ahead of time how it's going to come out, and it's hard to escape the obvious fact that the computer has done nearly all of the work, and I only gave it the vaguest of directions in terms of aesthetics, although I did give it very specific instructions about how to do everything it did, those instructions were so complicated and so many, that I had next to no idea what specific output those instructions might produce, except in the most general terms. When I run the program, there's an anticipation ... "oooh, I hope this one comes out good!" but I don't know ahead of time whether it will or not.
And I think you may underestimate the power of stgit. You can manage thousands of patches concurrently, no problem. If you're a maintainer getting patches from loads of people all the time, this is valuable. stgit has it's origins in quilt, which in turn has its origins in Andrew Morton's patch scripts[1], and I know for a fact that Andrew Morton actually managed thousands of patches at a time for years in his work on the linux kernel, because I once sent him a patch against those scripts, and he complained it was slow because I used an O(n^2) algorithm, which worked fine with a handful of patches, and I asked him how many patches he had, and he told me a number that was multiple thousands, so this isn't a hypothetical example.
feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW);
will cause your code to get a SIGFPE whenever a NaN crawls out from under a rock. Of course it doesn't work with fast-math enabled, but if you're unknowingly getting NaNs without fast-math enabled, you obviously need to fix those before even trying fast-math, and they can be hard to find, and feenableexcept() makes finding them a lot easier.https://github.com/neilbrown/wiggle
although on debian based systems I think you can just "apt install wiggle"