Not according to my uHoo air quality monitor. I have had one running a few feet from the monitor for over a week and there hasn't been any notable increase in PM2.5 particles.
What's your PM2.5 baseline, and did you measure TDS in the water?
Not according to my uHoo air quality monitor. I have had one running a few feet from the monitor for over a week and there hasn't been any notable increase in PM2.5 particles.
What's your PM2.5 baseline, and did you measure TDS in the water?
Have you looked at EasyOCR?
When I was working on a fairly large TypeScript project it became the norm for dependencies to have type definitions in a relatively short space of time.
Count the amount of `Any` / `unknown` / `cast` / `var::type` in those codebases, and you'll notice that they aren't particularly statically typed.
The types in dynamic languages are useful for checking validity in majority of the cases, but can easily be circumvented when the types become too complicated.
It is somewhat surprising that dynamic languages didn't go the pylint way, i.e. checking the codebase by auto-determined types (determined based on actual usage).
With a physical SIM, I can pry my card out of one phone and put it into another, and expect it to work. With eSIM, every single eSIM has to be carrier approved and GSMA approved, and every single transfer from one eSIM to another has to be carrier approved too.
Is anything preventing the provider from denying a SIM swap based on IMEI?
That is, the client is not packaging up all its logic and sending a single blob that describes the fully-chained logic to the server on its initial request. Right?
When I first read it, I was thinking it meant 1 client message and 1 server response. But I think "one round trip" more or less message "1 server message in response to potentially many client messages". That's a fair use of "1 RTT", but took me a moment to understand.
Just to make that distinction clear from a different angle, suppose the client were _really_ _really_ slow and it did not send the second promise message to the server until AFTER the server had computed the result for promise1. Would the server have already responded to the client with the result? That would be a way to incur multiple RTTs, albeit the application wouldn't care since it's bottlenecked by the client CPU, not the network in this case.
I realize this is unlikely. I'm just using it to elucidate the system-level guarantee for my understanding.
As always, thanks for sharing this, Kenton!
See "But how do we solve arrays" part:
> > .map() is special. It does not send JavaScript code to the server, but it does send something like "code", restricted to a domain-specific, non-Turing-complete language. The "code" is a list of instructions that the server should carry out for each member of the array
gjtorikian/gh-actions-lockfile@v1
Presumably since it has to run first it must run unpinned?