asarazan

Does this mean we have to get rid of Speechless at Google IO?

I'm really hoping somebody at Oculus/HTC/Microsoft sees this and wants to develop it, because I agree the hardware industry needs to step up its game to make this a reality.

Android Lead from Capital One SF here. I did and it was one of the best hires I ever made. He's the most enthusiastic and motivated person on my entire team, and is also amazing at UI and performance optimization. I've been begging them to send me more candidates ever since.

Did this get killed? I can't find it on the list

I failed pretty hard. 1/5

If "most cases" means the average small team (2-3 developers), then you probably have a point. Once you have more than that, I think it's absolutely necessary to enforce code style in this way.

Thanks for reading the article so thoroughly.

Yeah this is the general idea we went with. We did our best to synchronize around it, but unfortunately we can never have total control, which necessarily introduces race conditions.

I would imagine this is what leads to the 0.4% crash rate I mentioned at the top of the article :-(

I was going for more of a sly joke with the title, but it appears to have not gone over well. I now regret my decision.

I agree. Would be nice to stop having to worry about this crap at every turn when developing on iOS.

We do this for various other reasons (clearing possibly corrupted state, etc), but we've never uploaded the statistics to the servers. We may begin doing this in the future.

We've been using Crittercism in the past and recently switched to Crashlytics, unfortunately memory crashes are one of the few exceptions (hah) to the rule, as they are SIGKILLs from the OS.

Another commenter recommended touching a file at launch and at sleep to track untraceable crashes, which we do for various other reasons, but don't upload the stats. We may begin doing this.

I won't argue too strongly on this, as you're far more knowledgable about it than I am.

However, imo the intention and semantics behind a call like CFMakeCollectable implies a transfer of ownership to an external system. A newbie Apple coder could be forgiven for thinking it would still transfer ownership in RC environments, just to the autorelease pool instead of a collector. In all likelihood this is what happened. An intern got at the code and didn't know the details about GC.

Obviously the point stands that this interpretation is well-documented to be false, but its naming is definitely misleading.

Double edit: I see from your edit that some of my basic assumptions about CFMakeCollectable were wrong, having never actually worked with it. My bad.

I would disagree pretty strongly with that. The function CFMakeCollectable is explicitly a function for dealing with the garbage collector, and its unpredictability in non-garbage-collected code is the direct cause of the bug.

Doesn't it make sense to say that without the existence of Apple GC, the bug never would have existed? Doesn't that at least somewhat justify the title?

edit: Furthermore the original intent of including garbage collection in the title was as an ironic twist based on the fact that ios has never had garbage collection. Maybe that didn't convey as well as I would have liked.

I should clarify. iOS does not have garbage collection and has never had garbage collection. The root of this bug is in old legacy cruft from the garbage collected days of OSX. The code is dormant in a lot of old CoreFoundation classes, and still causes unexpected behavior from time to time.

I should note that, while we saw something like 0.4% increased crash rate, we actually don't have a number to compare it against for memory crashes.

This is because if memory usage gets too high, the OS will send a kill signal to the process, which can be neither detected nor caught.

This means that in our original decision to use this fix, all we had was anecdotal evidence of untraceable crashes. Luckily we had dedicated QA that was keeping pretty solid track of them all, and they piled up.

In our case I think it was worth it.

Worked quite well for me, then started 404'ing. Load issues I presume.

Either way bravo, great idea.

I've been thinking about this since yesterday, and it seems like a really good solution for some use cases, but isn't there quite a bit of overhead to using a dispatche queue for fine-grained operations? I mean it seems like the overhead of cross-thread communication would severely outweigh a simple synchronous lock call.

Then again, if you can do things like background non-essential operations, then the higher-level benefits can probably outweigh that.

Hah, good catch! Fixing.

That would certainly be an interesting project, although the performance implications on a mobile platform may be an issue (although that's becoming more moot with each generation).

In this case, however, our goal was to take common, familiar interfaces and idioms in Objective C, and make them safer/more powerful.

Something more like channels-like would be quite useful, but it would likely be published under a different project.

Fascinating. I'll have to give that a shot. Thanks!

As opposed to using a simple or recursive mutex while forgoing concurrent reads, in this case. There was an order of magnitude speed difference in raw lock/unlock performance.

Obviously this can still be useful in read-heavy systems where the lock has to be held for long spans, but for our synchronized collections, we switched to std::mutex, which was massively faster.

As a small post-mortem, one interesting thing we learned while building this library: The reason Apple never included a read/write lock.

They're hard to get right (probably not a problem for Apple), and their overhead usually counterbalances any potential performance gains (possibly a problem for the unwary developer).

We've got some optimization work to do :-)

My fiance and I had to tag team the site to finally get an 8GB after the 16GBs ran out. Got a confirmation number and receipt, but haven't received the confirmation email yet.

It's like trying to get a bag o crap, but with a phone!(tm)

I'm a big fan of Minefold.

Also, being no stranger to... "problematic" launches, I can totally sympathize here.

Can't wait to see what you guys have in store with the new update, and as long as Cook or Schiller doesn't suddenly kick the bucket, I think you'll be fine with this one :-)

Will this check in both people travelling under the same confirmation number?

Square employs a significant number of ex-Apple guys. That might have something to do with it :-)

I think you're both underestimating how long it takes to really get settled in and take charge of a huge corporation, as well as overestimating just how long 5 months really is.

Seems like about the right amount of time for him to start really kicking things into high gear imo.

Thank you!

The fact that this "Look I'm a woman" and "Stuck up bitch" crap has been sitting here not getting downvoted (and even getting upvoted evidently), is a glaring indictment of the HN community overall. This is the kind of malicious shit people value, I guess.

I think it's just a difference in the way the two companies do "public".

Because Facebook hates Google, you're far less likely to see public posts turn up in Google results.

Google, on the other hand, created their network for the sole purpose of bolstering their search results. This leads to a much more adversarial relationship with the service, where you have to constantly fight to keep yourself out of the spotlight.