ECMAScript 2024, the 15th edition, added facilities for resizing and transferring ArrayBuffers and SharedArrayBuffers; added a new RegExp /v flag for creating RegExps with more advanced features for working with sets of strings; and introduced the Promise.withResolvers convenience method for constructing Promises, the Object.groupBy and Map.groupBy methods for aggregating data, the Atomics.waitAsync method for asynchronously waiting for a change to shared memory, and the String.prototype.isWellFormed and String.prototype.toWellFormed methods for checking and ensuring that strings contain only well-formed Unicode.
In more complex embedded software you are likely to see free lists used to manage pools of preallocated resources (like event structs etc) or pools of fixed sized memory buffers.
No memory allocation/reallocation, preallocated resources managed in e.g. a free list. Also for things like packetized networks, lists are handy for filling as you progress down the stack while using fixed sized packet buffers, or reassembling fragments.
In embedded world, memory often needs to be exactly controlled, and allocation failures are fatal without a more complex MMU. In kernel world, I believe the main reason is that allocations can block.
Sometimes the promo committee can't tell the difference, i.e. was the problem complex to warrant the complex solution. They just see the effort put into solving it.
I got a green card while on E-3. Make sure your visa doesn't expire while you are in a no-travel period, as you might not be able to renew it if you have a pending change of status (or so I hear - was not applicable in my case).
Without any claim to the accuracy of the data, there is no incentive to list a salary on the LCA that is higher than required. You can always pay more, never less, so it only limits future flexibility. I have certainly paid higher salaries to individuals than what's listed on their LCA, not to mention total packages which aren't stated on the LCA.
Not to disagree with the cumbersome process - just want to point out that TOTP codes are valid for 30 seconds after the "expire" (60 seconds total). So as long as you are able to remember / copy the digits, there is no need to wait for the next code even if you don't have enough time to type it in. It will still work.
Tangentially, I really wish authenticator apps continued to show the previous code for 30 seconds so I can continue to refer to it for apps that don't allow copy and paste.
TOTP codes are actually valid for 90 seconds, 30 seconds either side of when it’s supposed to be displayed (assuming the display device’s clock is accurate to the second), to allow for up to 30 seconds clock skew on either end, in either direction.
I definitely had no idea! Thanks for that knowledge.
I mean there's never been any UX indication at all that that would be the case. I like your idea of showing the previous code -- that would make it very clear.
To be fair, the reason for this is to account for clock desync between systems, so it wouldn't be correct to say it is still valid for 30 seconds where it might not be in reality. Knowing what this actually means requires understanding the implementation of TOTP, so that you are not surprised in situations where it does fail. The existing authenticator app UX is likely correct for the average user.
From: https://tc39.es/ecma262/2024/