My C is quite rusty, so apologies for stupid questions.
In the hm_put function, when you overwrite, why do you malloc and copy the key again, and what happens with the old key pointer and the old value pointer? (no free for the key and the memset zeros everything?)
> Makes me wonder how much traffic planning and distributed systems could learn from each other
I don't know any concrete example, but since road engineers have been using queueing theory, originally invented for telecommunication networks, for more than 70 years, I would be surprised if models and tools designed for one use case had not been reused for the other.
Think it was the Tannebaum Networking book which has a chapter on queuing theory. Couple of lectures on that, only to find the chapter was concluded with something like: "Empirical evidence has shown that network traffic doesn't follow a possion distribution", so was left with a feeling that the chapter was only relevant for exams.
Ossobuco, the Italien defender of (checking their comment history) Russia, the Cuban government, the Iranian government,... (probably something else but I stopped checking)
That's a false analogy. We're not fighting the Nazis, and Russia has no intention of dominating the world. If waging war was enough to be like the Nazis, I believe the USA got there a long time ago.
Its the correct analogy. The russians are literally the same as the nazis. They are commiting genocide against the Ukrainians and they have already made clear that they intend to dominate europe.
The fact that the standard library works against you doesn't help (to_lower takes an int, but only kind of works (sometimes) correctly on unsigned char, and wchar_t is implicitly promoted to int).
to_lower is in the std namespace but is actually just part of the C89 standard, meaning it predates both UTF8 and UTF16. Is the alternative that it should be made unusable, and more existing code broken? A modern user has to include one of the c-prefix headers to use it, already hinting to them that 'here be dragons'.
But there are always dragons. It's strings. The mere assumption that they can be transformed int-by-int, irrespective of encoding, is wrong. As is the assumption that a sensible transformation to lower case without error handling exists.
> Is the alternative that it should be made unusable, and more existing code broken?
It should be marked [[deprecated]], yes. There is no good reason to use std::tolower/toupper anywhere - they can neither do unicode properly nor are they anywhere close to efficient for ASCII. And their behavior depends on the process-global locale.
Not at all. You need the right type of rice (and a rice cooker helps). There are many options for the filling, some of which don't even require a trip to the Asian grocery store.
On the Amiga and Atari, based on the Motorial 68000 like the NeoGeo, all 3D games used fixed point arithmetic.
At that time, such games were written in assembler, and you had to be very careful to place the instructions for scaling and descaling in the right places, not only to get the final result in the right units (i.e., screen coordinates), but also in intermediate calculations to preserve precision.
Give this man a node.js application with 100000 dependencies where an update from package version 34.2.4 to 34.2.5 breaks everything because the developers decided to change the order of parameters in one function just for fun.
> node.js application with 100000 dependencies where an update from package version 34.2.4 to 34.2.5 breaks everything because the developers decided to change the order of parameters in one function just for fun.
aka "totally unknown environment" which you "need feedback about what works and what doesn’t"
he was dealing with that situation already in the 01970s—he was using an extensible programming language that people kept extending, so the programs he wrote one day would break the next—which is why he designed τεχ in such a way that you can take any τεχ document from 40 years ago and render it in exactly the same way in current τεχ
one of the drop-dead showstopper tests in the τεχ release process since that time has been the 'τεχ torture test'; it's an enormous random τεχ document which has to produce byte-identical output on each new version of τεχ for it to be released, unless he can justify each difference. so he's not opposed to automated testing, he just tends to do it at a larger granularity
