Is there a list of supported languages or environments for this yet?
HN user
jpsim
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.
Anyone know of an equivalent for Ruby? I’d love to add this as an integration test for jazzy[0].
Separately, it’d be awesome if this also checked that anchor links resolve to id values to validate linking to specific elements on a page.
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.
Someone should make a collection of these for all languages. I’d love to see an equivalent for Swift.
Very similar to Realm (also syncing CRDTs), though this seems more lightweight and works in client-side web apps. https://realm.io
My comment wasn't a question, but rather highlighting that a major part of their stack wasn't so much as mentioned in an article about their stack.
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...
Is there a write-up somewhere explaining why this was a technical hurdle compared to base domain certs? Very curious.
I can 100% vouch for Peter and his team. They got me my EB1A which led to my green card. Thanks Peter!
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.
It's a little funny that GVFS itself is hosted on GitHub which means you won't be able to pull it as a GVFS repo.
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.
(JP from Realm here)
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.
[0] https://news.ycombinator.com/item?id=11771558 [1]: https://realm.io/docs/swift/latest#threading
(JP from Realm here)
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.
[0] https://github.com/realm/realm-cocoa/issues/3136 [1]: https://realm.io/docs/swift/latest#threading
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.
don't forget watchOS ;)
FWIW you can use Realm Objective-C or Realm Swift on Mac OS X.
I'll let someone else clarify why Java outside Android isn't supported.
(JP from Realm here)
Unless I'm missing something, what you're describing could easily be done by having the version number or branch in the Realm path, or whatever identifier you want. You should open an issue[0] so we can explore that more.
Strings are indexed, but I think you're referring to something like "full text search"? That's on the roadmap[1].
[0] https://github.com/realm/realm-cocoa/issues/new [1]: https://github.com/realm/realm-cocoa/issues/3650
(JP from Realm here)
Yes, it's all bits, but those bits matter :). The internal query engine is extremely optimized based on the layout of those bits, on a per-architecture basis.
Also, integers are adaptively bit-packed, so you shouldn't worry about the size of your integers, as Realm will intelligently use the appropriate widths.
I'd suggest continuing to use this computed property pattern and to keep track of #651[0] where we're tracking better support for this.
(JP from Realm here) Yes, that's something we're hoping to add! We're tracking that feature as #3384[0]. Still needs some design work though.
Thanks for that, although it similarly hasn't swayed me :D
I'm sure I'm missing iTerm2's big appeal, but every time I try to use it, I find myself going back to Terminal.app, which I find more responsive and just as featureful, especially when combined with zsh and a windowing manager. That's probably just because I'm familiar with it and I didn't come from tmux or anything similar, but I keep hoping I'll be "enlightened" at some point and realize the error of my ways ;)
I look forward to trying this out on the TV once the hardware starts shipping. However, I wonder why the Apple TV compatibility wasn't just contributed back upstream to OpenEMU rather than creating a whole new repo for this.
We recently had respected independent security firm Matasano do a security audit
Strangely, they don't mention the results of this audit, which struck me as odd, but then I found this:
Our most recent security audit, conducted by Matasano in October 2014, found no significant issues. (Source[0])
I just thought I'd share in case anyone else was wondering.
[0] https://www.fastmail.com/help/ourservice/security.html?domai...
With both iOS & OSX now supporting frameworks, CocoaPods has the potential of becoming much more elegant. See progress on this here: https://github.com/CocoaPods/CocoaPods/pull/2222
SQLite ships with iOS and OSX too, just like Core Data. All you have to do is link libsqlite3.dylib instead of CoreData.framework.