Redkey
What's the word? I started looking but realized I have better things to do. Before I stopped I did find "nips" and "chow", both of which have completely unrelated, normal meanings. Hell, I didn't even know "chow" could mean anything other than food until I read the definition in the dictionary file.
There are several other racist, sexist, and generally rude words in there too. There is even a slur which has been used against me, and it's defined as such (one meaning among many), but I say leave them. Well, maybe "cunt" could go without being missed.
I don't think that even C++ is that bad. Like a lot of shows and music acts, I think it's more the toxic fan base than the thing itself that really sucks. I've had the same feeling with a certain kind of JavaScript programmer.
*Edit for clarity: I'm not saying that the entire C++ community is toxic, just a vocal segment of it, in line with the other examples I gave.
The added difficulty with this in programming is that it can be much harder simply to ignore them, because you may be forced to work with them, or stuck needing to learn something from them (shudder).
I wouldn't be surprised if book readers spend 92% of their time on older books. Or if music listeners spend 92% of their time on older pieces.
Tail recursion in particular is usually just turned back into a loop at the compiler, and typical modern architectures implement a call stack at the hardware level, which allows you to do limited-depth recursion, but breaks like in OP if you try to go too deep.
Yes, in my experience this is what the term "recursion" means in a programming context; it doesn't usually refer to a mathematical ideal. That was what tripped me up.
Could someone expand a little on this statement, or point me toward an applicable resource? How do "real" (modern?) CPUs prevent unwanted recursion? As in, not the compiler or the OS, but the CPU itself? I've been searching for a while now but I haven't found anything that clears this up for me.
TL;DR: The clock oscillator for the sound chip (separate from the main CPU clock, which does not have this issue) appears to be speeding up over time as it ages. Games from that era use video signal synchronization to regulate their overall speed, so this will not affect game times. It may cause audio glitches or crashes, but it won't make games run faster. However, it has the potential to cause (and probably has caused) desynchronization issues with tool-assisted speedruns on original hardware.
(I looked into this a bit for another post of this same article.)
AFAIK the overall execution speed of the old consoles was always intimately tied to the video refresh rate, not audio. I don't have much experience programming the SNES specifically, but from what I do know about it and my experience with other retro consoles, I don't imagine that the sound processor running ever so slightly faster will change the speed of the game overall. Not even to the degree of "less than one second over an entire playthrough" as suggested by the article.
If the oscillator goes far enough out of spec, it may lead to audio glitches and possibly even complete crashes, but I doubt that many games -- frankly, any games at all -- are busy-waiting on the sound processor as their main way of keeping time.
...
OK, I just took a short break. I've done a little reading about the potential issue from first sources, and brushed up on the SNES hardware. To reiterate, I still don't believe that any game will run even one frame faster due to this issue. However, what does seem to be at stake is tool-assisted spreedruns on original hardware. If this oscillator speeds up just a little, but not enough to cause software issues, there's a chance that controller inputs may be read slightly earlier than otherwise expected (due to the slightly faster audio system finishing earlier), potentially causing a desynchronization with sub-frame accurate hardware input tools, meaning that a TAS may run correctly on one console but not another.
While this is an important issue in the TAS community, I don't see how this could result in an otherwise "correct" run finishing even one frame faster, as the inputs will still only be read by the game once (or however many times the game normally reads them) per field ("frame"), and the game will still be using the video vertical blank for main timing.
Seconding Markor for Android. I originally installed it because I was sick of all the note-taking apps that store your notes away in hidden directories and proprietary formats. I've been using it for years and it's not let me down yet.
Only Winsocks.