Archive for June 18, 2015

Thursday, June 18, 2015

Core Data Bugs

Almost four years ago, Dev reported a bug with Core Data’s NSOrderedSet generated accessors (via Ling Wang).

DaGaMs, in 2013:

I just brought this up with an Apple engineer during one of the CoreData Lab sessions at WWDC. They acknowledge the issue and that it’s a genuine bug, and from what I’ve seen it has the “critical” status, but of course there’s no promise as to when they’ll fix it. I don’t think it’ll be fixed in iOS6/Mountain Lion. I think it’d be good to duplicate this radar further. Currently it has about 25 dup’s, the more the better!

It seems like an important and straightforward bug to fix, but it’s still present in iOS 9.

Another bug, reported by Michael Gorbach (tweet):

We have found a reproducible CD deadlock that can occur when using a fetched results controller with a “complex” (i.e. either multi-level or “synthesized” (not in the database) sectionNameKeyPath). This occurs specifically with a stack that has a top-level background (private queue) writing context, where the main thread context is a child of this context.

Changes to CD (object creations and updates) as well as fetch requests, are taking place sequentially on background “import” contexts (private queue contexts). These contexts are also children of the top-level private queue writing context. If, while these CD changes and fetch requests are taking place in the background, the main thread Fetched Results Controller is asked to perform it’s initial fetch, a deadlock results.

Editorial 1.2

Gabe Weatherhead:

Now you can manage tasks in Editorial like a boss. Editorial provides built-in support for the TaskPaper format with handling of projects, tag highlighting and completing tasks for files saved with the .taskpaper extension. The iPhone version now has feature parity of the task management features, including check boxes and drag handles to move tasks up and down a list.

First, jump into the Editorial preferences and make a few tweaks. Editorial will highlight lines with user configured tags.

[…]

This is an Editorial script that I use many times a day. I’ve added it as an action on almost all of my Taskpaper macros. The script processes every line of the Taskpaper looking for @due tags that contain dates with the format YYYY-MM-DD and evaluating those against today’s date. If the date is equal to or less than today, it changes the tag to @today.

[…]

Document Templates in Editorial 1.2 are really just macros that execute before you open a document. Out of the box, there are some simple templates that create new documents with different file extensions. But this is the least a template can do.

Editorial (App Store) is my favorite iOS text editor. There’s also a new feature for highlighting all occurrences of a word at once.

Update (2015-06-22): Gabe Weatherhead:

If you use it as much as I do, you may find these additional macros useful. Editorial is a means for working with text and often it can seem like a heavy IDE that requires a huge time investment. Most of the macros below are simple or use basic “actions” in a logical way.

App Store Search Is Still Depressing

Jared Sinclair:

Only two apps are visible, neither of which are a) Twitter clients or b) made by Twitter or c) even remotely related to Twitter.

The most important store front on the most important mobile device is seven years old and still has the worst search experience I’ve ever used.

Previously: How Broken is Discovery on the App Store?

Introduction to WebKit Content Blockers

Benjamin Poulain:

The reason we are unhappy about the JavaScript-based content blocking extensions is they have significant performance drawbacks. The current model uses a lot of energy, reducing battery life, and increases page load time by adding latency for each resource. Certain kinds of extensions also reduce the runtime performance of webpages. Sometimes, they can allocate tremendous amounts of memory, which goes against our efforts to reduce WebKit’s memory footprint.

It is an area were we want to do better. We are working on new tools to enable content blocking at a fraction of the cost.

One new feature, we are developing allows describing content blocking rules in a structured format ahead-of-time, declaratively, rather than running extension-provided code at the moment a decision about blocking needs to be made. This model allows for WebKit to compile the ruleset into a format that’s very efficient to apply to loads and page content.

Nick Heer:

This new extension point seems to smooth over these issues in a really nice way. Not only will this improve performance, I can now have ShutUp on my iPhone, too, and block the humungous JavaScript files so many sites use these days.

How Crash Bandicoot Was Fit Into 2MB of RAM

Dave Baggett (via John Carmack):

The PS1 had 2MB of RAM, and we had to do crazy things to get the game to fit. We had levels with over 10MB of data in them, and this had to be paged in and out dynamically, without any “hitches”—loading lags where the frame rate would drop below 30 Hz.

It mainly worked because Andy wrote an incredible paging system that would swap in and out 64K data pages as Crash traversed the level. This was a “full stack” tour de force, in that it ran the gamut from high-level memory management to opcode-level DMA coding. Andy even controlled the physical layout of bytes on the CD-ROM disk so that—even at 300KB/sec—the PS1 could load the data for each piece of a given level by the time Crash ended up there.

I wrote the packer tool that took the resources—sounds, art, lisp control code for critters, etc.—and packed them into 64K pages for Andy’s system.