HN user

jpsim

128 karma
Posts18
Comments53
View on HN

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.

[0] http://images.apple.com/legal/sla/docs/macOS1012.pdf

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.

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.

More on GVFS 9 years ago

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.

The Startup Tapes 10 years ago

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.

Realm 1.0 10 years ago

(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

Realm 1.0 10 years ago

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.

Realm 1.0 10 years ago

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.

Realm 1.0 10 years ago

(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.

[0] https://github.com/realm/realm-cocoa/issues/651

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.