We just have automatic tests that use the thing in every possible way. We have them because that's how we've developed and debugged the function. Best documentation ever.
Only if your testing framework allows those tests to be cleanly expressed and readable. Most of the tests I look at are inscrutable and the majority are for handling corner cases, with maybe a handful for common cases.
The best documentation your code can have is the docs written by paid applications engineers
History subject is actually making proper sense now. At school it was kinda tedious in some parts. (never had anything against biology, it's all technical stuff that we here like)
Yea, "looking into how guns work" isn't weird. It's just addictive: relative to other problems they're simple and physically intuitive, so for every new mechanism you get a kick from learning another easy thing you didn't need to know.
History started making sense a decade into adulthood, I hated it in school. I picked up a book on Cato and I was surprised some things existed in ancient Rome and modern India: bribing the electorate with money and gifts, people with diverse causes forming alliances and breaking up and again burying the hatchet, arranged marriages to cement bonds between men etc.
Your comment makes no sense at all. Both cmake and qmake are competing build systems, and qmake already lost and was superceded by cmake.
Cmake works as a high-level makefile generator, which pretty much outputs the DAG of a project's build targets in any of the supported lower-level systems. Right now it supports Make and also Ninja.
Cmake's support for ninja is a nice-to-have, just like it's support for Visual Studio and Xcode project generation. No cmake user was ever blocked by cmake's lack of support for ninja. In fact, no one barely notices any change if you replace make with ninja. In fact, I was surprised to know that Qt Creator started configuring Cmake projects to use Ninja by default because things just worked the same anyway, and honestly I didn't bothered to change anything because there was no discernible difference at all.
Propriatery drivers (especially nvidia), most likely has lots of similar game specific workarounds and optimizations (even going as far as overriding shaders in games with better ones they wrote). [1]
Leaving aside arguments about "what the drivers are", the kernel driver being discussed here generally doesn't have or need that kind of thing. The user-space drivers which talk to the kernel drivers are under the Mesa umbrella as part of Gallium for OpenGL and Direct3D support (e.g. https://github.com/mesa3d/mesa/tree/master/src/gallium/drive...) or as a standalone driver for Vulkan support (https://github.com/mesa3d/mesa/tree/master/src/amd/vulkan). That said, I haven't seen many app-specific hacks in the open source drivers, even in the user-space code.
If anyone wants to learn more about lower-level aspects of GPUs, the Vulkan driver code I linked is one of the best places to start. It directly implements the Vulkan API on one end and talks to the kernel drivers on the other end, so it's relatively easy to follow if you're a systems programmer with an API-level understanding of graphics. Just pick a Vulkan function of your choice and start tracing through the code, e.g. vkCmdDraw: https://github.com/mesa3d/mesa/blob/master/src/amd/vulkan/ra.... The Vulkan driver calls into some of the low-level radeonsi code I linked from the Gallium tree but it isn't a Gallium-based driver, so you don't have to deal with those extra layers of abstraction.
To expand on this there's these things called ion thrusters that use an electrically generated magnetic field to accelerate gas particles at extremely high velocities out the spacecraft thereby generating thrust. These are stupidly efficient but also very low thrust. Due to the high power usage I don't see much of an application for even incredibly dense batteries as you still need a sufficiently large power source anyway - though I'm no rocket scientist.
