101–110 of 129 posts
Earlier quoted context omitted.
I agree it’s not the prettiest, but I had no trouble clicking on “tree” to get to the folder and then “mod.ts” to see the code.
One has still to know that "tree" stands for "source code".
setTimeout is stranger than you think. We recently had a failed unit test because setTimeout(fn, 1000) triggered at 999ms. That test had ran more than a hundred times before just fine. Till one day it didn't.
setTimeout has no guarantees, and even if it did, your unit tests shouldn't depend on it. Flaky unit tests are a scourge. The top causes of flaky unit tests in my experience: - wall clock time ( and timezones ) - user time ( and timeouts ) - network calls - local I/O These are also, generally speaking, a cause of unnecessarily slow unit tests. If your unit test is waiting 1000ms, then it's taking 1000ms longer than i…
Not difficult if you build your code (not just the test suite) around scheduling APIs (and queues implementations, etc.) that can be implemented using virtual time instead of CPU/wall clock time (I call that soft vs hard time).
Actually I find it a breeze to create such fast and deterministic unit tests.
This makes me love having Go handy. I find working with signals and time based events so much nicer than other languages I use. This is fun, though. JS is a bucket of weird little details like this.
Earlier quoted context omitted.
This is not a sourcehut problem, it is a github problem. "Tree" is semantically correct.
What? Of course it's a Sourcehut problem. They chose to use that word and could choose to use a better one.
In response to this, I read the spec of setTimeout, bu I couldn't find the part where implementations may have an upper bound. Can someone more familiär with the specs point me in the right direction?
Just JS being JS: setTimeout(()=>{}, Infinity) executes immediately
Earlier quoted context omitted.
No, it pretty much just does exactly that. const subtractNextDelay = () => { if (typeof remainingDelay === "number") { remainingDelay -= MAX_REAL_DELAY; } else { remainingDelay -= BigInt(MAX_REAL_DELAY); } };
Oh yikes. Yeah; not ideal.
At least if your definition of “correct” is “does the thing most similar to the thing I’m extending/replicating”. In fact you might believe it’s a bug to do otherwise, and JS (I’m no expert) doesn’t give a way to run off the event loop anyway (in all implementations). Although I’d be amused to see someone running even a 90 day timer in the browser. :)
I’ve think a very precise timeout would want a different name, to distinguish it from setTimeout’s behavior.
The longer the delay, the more likely the process is to crash before the timer completes. Use a scheduler instead.