Archive for September 24, 2015

Thursday, September 24, 2015

Rosyna Needs Help

Rosyna Keller:

I’ve only got a total of $0.06 left to my name and I only have a room here until 11am (Phoenix) on Thursday, September 24th, 2015. I have no idea what to do, I’m broke, and I’m hiding from extremely abusive family.

Dave DeLong:

If you can spare anything, @rosyna’s PayPal is rosyna@mac.com.

Brent Simmons:

A necessary mark of a good community is that we help people who need help. Rosyna needs help.

Jesper:

Rosyna Keller, this guy I’ve seen around for years, from back in the day where Unsanity and Haxies and the Cocoa-Carbon wars were a thing, uses [a pseudonym] of necessity. He’s on the run and the subject of extreme misfortune and hardship that makes me feel really titchy about my own problems.

Rosyna is an enigma. I don’t really know who he is or what he’s been up to since the haxie days. But I do know that he’s long been a important part of our community, figuring out how things work, locating bugs, and making insightful comments.

Update (2015-09-24): Edward Marczak:

Know it or not, you’ve used @rosyna’s software in some form.

Gwynne Raskind (tweet):

In short, while Rosyna can’t be said to be solely responsible for my career, his work was a major factor in making what I’ve accomplished so far possible.

[…]

I learned in that time that it wasn’t just Unsanity that Rosyna was known for. He is a diligent researcher, a person of great insight into the workings of these machines. He has solved problems no one else could. He has helped any number of fellow developers and fellow people when he could, and with more patience and compassion than some of the most famous minds of our generation.

Swift 2.1

Russ Bishop (comments):

If you thought Apple was slowing down with Swift, think again. Xcode 7.1 Beta 2 includes Swift 2.1. As always you can check the release notes for yourself because I don’t necessarily address everything here.

[…]

If only private things are modified in a file then it does not trigger recompilation of all files that depend on it. In some cases this can have a huge performance benefit

[…]

Function/closure types now have covariance and contravariance.

Update (2015-10-14): Russ Bishop covers Swift 2.1 Beta 3.

Swift 2 Bloat in the Twitter App

Nolan O’Brien:

Twitter app sizes:
w/ Swift 1.2 = 65MB
w/ Swift 2.0 = 125 MB
Thinned w/ Swift 2 = 77 MB

Epiphany: App thinning counters Swift 2.0 bloat

It’s not clear to me why this is happening, but it sounds like both the Swift libraries and the compiled code for the app itself are larger than before.

It seems entirely possible that overall system performance would decrease if more apps used Swift. The binaries are larger, so they’ll take up more storage space and RAM. They’re calling back and forth to Objective-C a lot, so they won’t see many benefits from pure Swift not doing message sending, and they may incur extra overhead due to bridging. Writing the code may be faster, though.

Update (2015-09-24): Apple:

App slicing is currently unavailable for iOS 9 apps due to an issue affecting iCloud backups created from iOS 9 where some apps from the App Store would only restore to the same model of iOS device.

When a customer downloads your iOS 9 app, they will get the Universal version of your app, rather than the variant specific for their device type.

The iOS Status Bar

The Status Bar is a Tumblr blog of screenshots showing buggy iOS status bars (via Cédric Luthi). An iOS app should properly handle different sizes, rotation, transparency, and more.

Custom Swift Pattern Matching Operators

Ole Begemann:

We know that greaterThan(0) must produce a function that takes a value and returns Bool. So in turn, greaterThan must be a function that takes another value and returns the first function.

[…]

Swift provides a special syntax for the definition of curried functions that mimics how they are called.

[…]

It’s impossible with this solution to give the compiler any hints for exhaustiveness checking, so it will always force us to provide a default case. If you are certain that your patterns cover every possible value, it is a good idea to put a fatalError() call into the default case to document your expectation that this code path should never get hit.

[…]

Again, note that the missing whitespace between operators and operands is significant.

[…]

As a more practical example, suppose you want to check a string against several prefixes and suffixes.

Update (2015-10-14): Ole Begemann:

Ranges and intervals in Swift serve similar purposes but have different implementations and generic constraints. Ranges are based on indexes and are used most often in the context of collections. The fact that a range can’t contain the maximum value of a type can make them unsuitable for working with intervals of numbers. Intervals work with all Comparable types and don’t have the maximum-value limitation.

While custom operators should be used very sparingly, I’d argue that in this case they significantly improve readability without harming comprehensibility – the prefix and postfix operators are so close in meaning to their binary counterparts that even readers unfamiliar with the code should have no trouble understanding them.

Ole Begemann:

This works, but doing this for every method we want to use in this way quickly becomes tedious. So let’s write a generic function, flip, that moves the first argument of a curried function to the back, right before the final return value.

Counting Git Objects With Bitmap Indexes

Vicent Martí:

The result is a highly dense forest of interlinked nodes stored in the shape of a graph, but essentially accessed as a key-value store (each object in the database is only indexed by the SHA1 of its contents).

[…]

Git doesn’t keep a definite list of all objects reachable from the graph, and it cannot send every single object in its database as a whole, because it could very well be that some of those objects are not reachable at all in the repository and should be thrown away instead of sent to the client. The only thing Git knows are the tips of all branches, so its only option is to walk down the graph, all the way to the beginning of the history, listing every single object that needs to be sent.

[…]

Generally speaking, caching specific results to queries is a weak approach to performance in complex systems. What you want to do instead is caching intermediate steps of the computation, to be able to efficiently answer any kind of query.

[…]

For any given commit, its bitmap index marks all the objects that can be reached from it. To find the objects that can be reached from a commit, we simply look up its bitmap and check the marked bits on it; the graph doesn’t need to be traversed anymore, and an operation that used to take several minutes of CPU time (loading and traversing every single object in the graph) now takes less than 3ms.

[…]

When Git noticed that none of the objects on the list could be sent because they were delta’ed against other objects that were not in the list, it was forced to re-delta these objects. […] This is how we were losing all the benefits of our optimization, and in fact making the process of generating a packfile 40% slower than it was before, despite the fact that the most expensive phase of the process was essentially optimized away.

Apple Music for Android

Russell Ivanovic:

Remember back in June when Apple promised to bring their music app to Android in September? No? I do, because I was sitting in the keynote room at the time. My prevailing thought at the time was a simple one: “This is going to be fascinating. Will Apple try to clone their iOS app, or embrace Material Design, rise above pettiness and make something amazing?”.

[…]

I don’t know how much of an indication it gives you, but here’s their first ever Android app, released today […] It’s a poor attempt at making an Android app look like an iOS app. If you’re being generous, you might think Apple did this to make you more comfortable about moving to iOS.

Russell Ivanovic:

Apple Music on Android has the potential to be the best music app Apple has ever made.

[…]

They won’t be burdened by any legacy implementation: they could literally build it from scratch, with all the lessons they’ve learnt to date.

They don’t have the burden of having to play your local music like the iOS app, it could be a dedicated app for Apple sourced music only.

They can update the app as often as they want, iterating on things fast, since unlike iOS it’s not tied to OS releases.