Ah, yeah, I took 10*log(...) just forgot to reflect it in the formula. That's how I ended up with 40. Understandably, the formula won't quite work with blinds, walls, or other obstacles.

Filed a bug report: https://feedbackassistant.apple.com/feedback/11945405

A debugging tool. Part of the puzzle is knowing upfront if I can safely read N bytes of memory from a given address, or somehow try/catch reading from memory that can fail with, say, address error when I am reading past the heap, etc. I can drop down to C if that's not easy in Swift.

"seems… well… creative" 🤣

I see, thank you

"The next leap second will be added to the world’s clocks on December 31, 2016, at 23 hours, 59 minutes and 59 seconds Coordinated Universal Time (UTC). ... For anyone in the UTC±00:00 time zone, which includes London and the UK, the official clock will read 23.59.60 right before clicking over into 12.00.00 at midnight. (Normal clocks go from 23.59.59 to midnight.)" https://www.businessinsider.com/leap-second-added-december-31-2016-12

thanks for your valuable insights. for me the most intriguing aspect of streams is their ability of customization and wrapping around arbitrary sources/sinks. whether this is a stream of bytes from a file or network or temperature readings / random numbers from a physical device, or a stream of some values generated in your app - stream api can express everything. network framework is cool but that's just for network resources, fileHandle is also cool but that's just for files (unless as in good old unix days file handle can now express anything). obviously stream api needs some facelift like async/await to not fall into obliteration completely.

fair enough. i probably ought to file the relevant bug reports / feature requests for the above (look like 4 in total). you said that "there’s generally not a lot of point calling the streaming API", regarding JSONObjectWithStream. do you know any use cases when JSONObjectWithStream would be useful? if not why does this API exist at all and not deprecated? imho, the streaming api should be at the very bottom of everything and all other flavours (like file, url, data - whether the whole data block of piecewise data chunks, etc) shall be implemented as wrappers on top of streaming api, but maybe that's just old school myself.

as you can see above in the "didBecome streamTask" i'm calling captureStreams to convert URLSessionStreamTask into a stream. sure i can read data directly from URLSessionStreamTask (and if i wanted just the "data from url" - there are simpler ways to do that). here i want to "decode json from a stream".