This might have something to do with how data on GCP will be encrypted at rest. US law treats encryption effectively as a weapon and restricts where products that include encryption can be shared.
It’s a shame iOS just doesn’t seem to provide this level of data using public APIs as far as I can tell. I’d love to be proven wrong, or for Apple to be a bit more transparent regarding how they perform similar enhancements to location data.
Turns out it's two, not four VMs. From macOS Sierra's EULA[0]:
> (iii) to install, use and run up to two (2) additional copies or instances of the Apple Software
within virtual operating system environments on each Mac Computer you own or control that is
already running the Apple Software, for purposes of: (a) software development; (b) testing during
software development; (c) using macOS Server; or (d) personal, non-commercial use.
This post makes no mention of the macOS part of the CircleCI infrastructure, which is one of the trickiest parts of infrastructure IMHO. Tricky because Apple's EULA prevents virtualizing on anything other than its hardware, never more than 4 VMs per host, and not for commercial purposes...
llvm-diff is indeed pretty great, but having the IR structure as an AST that you could programmatically access and manipulate would allow more semantic diffing, or integration into workflows that would benefit from structured representations of a diff.
Maybe this would lend itself well to parsing bitcode slices (serialized LLVM IR). I've often wanted to diff bitcode produced by different compiler versions.
Curious choice to name a company & product with a name that sounds like "Liar Bird" when spoken. To me, that looks like they're fully embracing the concept that this can be used for nefarious purposes. If one of their goals is to bring attention that this technology exists and can be misused, the name reinforces that.
Came here to say this. I wasn't sure about the steadicam approach at first, but after watching one of the videos, it felt like I was there! Looking forward to seeing the upcoming ones.
It certainly forces you to think about threading (which is a good thing IMO). I just responded to a similar comment[0], and there are always our docs on threading[1] which I'd encourage you to read.
Realm's transactions are entirely ACID, and all transactions are thread safe. This means you can't get "faults" like you would in Core Data if one thread deletes an object being accessed in another.
On the flip side of this, it makes it difficult to share mutable object graphs across threads, mostly because then you'd need to know which Realm and which object is at what version of the db. Realm's underlying db engine supports this, but it's difficult to expose/enforce at the API level.
We have some designs in mind to allow scoping around passing objects between threads (see #3136[0]), and some other ideas for passing immutable Realms across threads, so you can expect to see some improvements there in the future.
About improving our documentation around threading, we're always open to feedback. I'd appreciate if you could read through the "Threading" section of our docs[1] and share how you think it could be improved.
I'm not sure what you mean here. If you mean "why would I ever use Int8 or Int32, etc. if Int64 won't take up more space in the file" the answer would be memory considerations when you take that data out of the Realm... you should just use the size you need and you'll be ok.