More of a programming nerd than is strictly healthy. See also {nevyn.nu, thirdcog.eu, twitter}
Reblogged from Andrey Subbotin
We were updating our app’s graphics for the gorgeous screen of iPhone 4 the other day and it was a pain to update all the 163 PNG files we had and not to miss a thing.
So, I’ve come up with a simple Ruby script that checks that for each @1x image you have a properly sized @2x image.
Man, such a life saver. sudo gem install ios-png-check is the path to bliss.
Objective-C is wonderfully dynamic. One of my favorite wonders is the invocation grabber. I never paid them much attention at first, only using them when I explicitly needed an NSInvocation for some API. Then, I started working at Spotify and found a certain header file; suddenly, I saw the light.
If you know what that an invocation grabber is, you can just skip down to the code. For the rest, I’ll elaborate.
Shortcut: Just gimme the juicy bits, I’m impatient!
An NSInvocation is a standard Foundation class that wraps four pieces of information all related to calling a method:
target, the object on which to call the methodselector, the name of the method to be calledmethodSignature, a class that describes the return type, and the type of all the arguments, of a method.Or, in the form you are used to see these parts in code:
[target partOfSelector:argument1 secondPartOfSelector:argument2]
Normally, these are kind of tricky to construct, particularly the method signature. However, Objective-C’s message forwarding mechanism practically gives them to us for free!
(Short clarification detour: In Objective-C, you almost never call methods directly; instead, you send messages to objects, and the receiver almost always responds to the message by calling the method corresponding to that message on itself. This is why the terms ‘method calling’ and ‘messaging’ are often used interchangeably in ObjC, but they are not the same thing.)
When you call a method on an instance whose class does not define that method, you don’t get a compiler error as in C++. When you then run your code, the runtime assumes that you’re trying to do message forwarding. Message forwarding means that the receiver of the message will not itself handle the message, but is only a proxy for some other object. One common example is Distributed Object, where you’re sending messages (calling methods) on objects in other applications, or even other applications on other computers.
This is where the invocation grabber comes in. We can create a class that does nothing but listen for message forwarding requests, and when it receives one, asks the target what it would respond to such a request. Given this answer, an NSInvocation can be created which matches the invocation of the message we sent to it.
Consider the following example:
We define a MyClass, create an instance of it, then create an invocationGrabber with that new MyClass as its target, and then try to call -[MyClass areTheNewViewersGoneYet:] on the grabber. Finally, we fetch the result of the invocation grabbing.
Note that line 9 does not call areTheNewViewersGoneYet: on your new MyClass. Instead, the grabber intercepts that call and gives us an NSInvocation that would have called that line just as we wrote it, but some time in the future instead of now. This is like a one-line closure, as the code, state and variables you send to the grabber are saved until later, just waiting to be executed.
Our invocation grabber does not implement a method with the selector areTheNewViewersGoneYet:. Given just the invocation grabber and that selector, the runtime would have no idea how to call it. Does it return a bool, in which case it will need to reserve four bytes for the return value? Or maybe a CGRect, in which case 16 bytes are needed.
So to figure this (and related things) out, the runtime will begin by asking for the method signature for the selector being sent with the message with -[NSObject methodSignatureForSelector:(SEL)]. Our SPInvocationGrabber itself has no idea, so we implement that method to ask the target:
- (NSMethodSignature *)methodSignatureForSelector:(SEL)inSelector {
return [_target methodSignatureForSelector:inSelector];
}
With the signature in hand, the runtime will now give you an NSInvocation and ask you to take care of invocation with -[NSObject forwardInvocation:]. In our case, we’ll just stash away the invocation for later use. In the example above, we created a yellowDuck and sent it as an argument to areTheNewViewersGoneYet:, and if we delay our execution of the NSInvocation, that duck might be released with the nearest NSAutoreleasePool. Thus, in forwardInvocation, we ask the NSInvocation to retain all its arguments. Don’t worry, when we release the NSInvocation, it will release those arguments too.
- (void)forwardInvocation:(NSInvocation *)anInvocation {
[anInvocation retainArguments];
anInvocation.target = _target;
self.invocation = anInvocation;
}
That’s basically all there is to it! Some memory management and accessor methods, and we have our own invocation grabber.
Let’s start out with some code.
That’s the header. It has a few categories on NSObject, which is where it’s at. (A category on NSObject means that we are adding methods on almost all other classes; these three methods can be called on any instance of a class inheriting from NSObject.)
-[NSObject grab] gives you an invocation grabber for the receiver, so that instead of [[[SPInvocationGrabber alloc] initWithObject:foo] autorelease] we can just say [foo grab]. It doesn’t sound like much, but it goes a long way toward taking the hassle out of doing magic.
-[NSObject invokeAfter:] will give you a proxy object that, instead of performing the method you call on it right away, instead invokes it later. Again, doesn’t sound like much, but man, -[NSObject performSelector:withObject:afterDelay:] is a mouthful, and it doesn’t work with non-object arguments or calls that take more than two arguments. Suddenly delayed execution is simple.
-[NSObject nextRunloop] is the same as invokeAfter: with a zero second delay. This is the common idiom for having something executed the next runloop (or at least as soon as possible after the current runloop).
I’ll show you what it can do with some examples:
A: Yeah yeah, we could have set an animation delegate, and animation did finish selector, and from there called removeFromSuperview. That’s at least six lines of code. Now we did it with one: [[flash invokeAfter:duration+0.1] removeFromSuperview].
B: Some things work better if you call them very soon instead of right away. Sometimes it’s an animation that needs to have started before we can begin modifying it. Other times it’s a timing issue and creating a delegate or notification is a lot of hassle for something that will just work one runloop from now.
C: Hey, who thought animations could be so simple? Don’t worry if the view controller that owns that table goes away before the animation finished: the invocation grabber retains both the table view and the arguments, so for 450 milliseconds, those objects *will* remain.
There’s more magic, but I’ll go through that after the implementation:
First, stack trace saving. You have no idea how useful this is. If you do the old -[NSObject performSelector:withObject:afterDelay:] trick, you’ll note that sometimes you crash. You’ll also note that below the method you just delayed execution of, you have no useful backtrace. Fret not, for execinfo.h is here to save your day! When an SPInvocationGrabber is created, the names of the symbols on the stack are saved away with -[saveBacktrace]. Then, if you use the grabber’s invoke instead of -[NSInvocation invoke], the invocation will be wrapped in a try-catch, and in the event of an exception, the old backtrace will be printed, showing you the culprit that scheduled this broken future invocation.
As for those convenient categories on NSObject, they are ridiculously simple. All -[invokeAfter:] does is to create a grabber, schedule it for execution later with an NSTimer (before it has grabbed anything, even!), and then returns it, ready to grab something for later execution.
I’ve tried to create -[NSObject invokeOnMainThread] and -[NSObject invokeOnBackgroundThread], but those are trickier, because you can’t just schedule the invocation and then return the grabber, as -[NSObject performSelectorOnMainThread:withObject:waitUntilDone:] would perform -[invoke] immediately, giving us no time to do the invocation grabbing, as with -[invokeAfter:]. It’s easy to do on your own though, even without a convenience method:
id grabber = [foo grab];
[grabber doSomethingFancyThatMustBeDoneOnMainThread:object someArg:wohoo];
[grabber performSelectorOnMainThread:@selector(invoke) withObject:nil waitUntilDone:NO];
Enjoy, and do post your own invocation tricks in the comments and reblogs.
Update 20100828: As you can see from the gist, I’ve updated it with background and main thread invocation (example usage below); thanks to Adam Crume in the comments for the idea and half of the code.
Reblogged from The Daily What
Nerdy Animation of the Day: “Sidewalk Mario Bros” — A graffiti-style animated Super Mario Bros. speedrun “played” alongside a concrete crash barrier.
Reblog 4 awesomeness! How did they even do that?!
Reblogged from rentzsch.tumblr.com
The experiment:
Step on a nail. Make sure it punctures your shoe and penetrates your foot.
(You probably want to make sure you’re up-to-date on your tetanus shot first.)
Do it again. Yes, with the blood. Doesn’t matter if you wait a week or a couple of years in-between runs.
Now the fun starts.
On the third run, you’ll catch yourself.
You’ll develop what roofers call “magic feet” — you’ll learn to recognize the sensation of a nail driving through the sole of your shoe.
I have magic feet.
And I just took a screenshot of my unsaved work as an app crashed.
That’s probably the closest software analog to magic feet.
Sometimes, an app starts to beachball mysteriously. Most often it’s Safari. It’s a special kind of beachball. You can feel that it will lead to a crash. Cmd-shift-3, open TextEdit, start typing whatever you were typing in Safari into TextEdit manually copying the text, watch Safari crash, reopen, open windows from last session, paste from TextEdit. The only thing that saved your work was an ungodly slow cache miss because your harddrive sucks.
I should just get MarsEdit. And a harddrive with a speed switch.
You’re syncing from another computer. You’re restoring from a backup. iTunes has a bad day. Whatever reason, iTunes decided to resync all your apps, and replace them in your springboard in alphabetical order. I don’t know about you, but I don’t find that particularly helpful. I don’t know *how* many times I’ve meticulously sorted at least the three first Springboard pages with my most often used apps (which doesn’t sound like much, but *damn* does that UI suck!).
Expert instructions
Get your ~/Library/Preferences/com.apple.springboard.plist from your old device or a backup, and replace the plist on your new device or new install. Nothing of much importance is in that file, so it should be fine to just replace. If you’re worried, just open the two files in Property List Editor and copy the array over; it’s just an array of array of application identifiers under the keypath iconState.iconLists. Respring/`killall SpringBoard` when done.
Noobie instructions
Scenario: You have a recent backup of your phone/pod/pad in Time Machine. You have your device with the botched icon ordering. You want to fix things.
I haven’t tested the noobie instructions; just mail me at joachimb@gmail.com if they don’t work and we’ll figure it out.
Reblogged from science tumbled
Irregular Webcomic:
Imagine you are James Clerk Maxwell, in 1865, formulating your theory of electricity and magnetism, and writing down your four equations for the first time in history. You write down the terms of these equations based on your experiments with electric batteries, bits of wire, and magnets. (…) You take the values you measured for εo and μo, multiply them together, take the square root, and then take the reciprocal. The answer is a speed, so it has units of speed, in this case metres per second. And the answer is very close to 300,000,000 metres per second. Converted into miles, that’s a tad over 186,000 miles per second. Being James Clerk Maxwell, and a brilliant physicist, you immediately recognise what this number is.
The speed of light. (…)
When you were writing down your equations, you were thinking about electricity and magnetism. Light was the farthest thing from your mind. You had not the slightest clue (and nor did anyone else) that light was related to elecricity or magnetism. But there it is, falling out of your equations.
You realise that you are the first person in all of history to know what light is made of. Can you imagine that feeling?
[Flash 9 is required to listen to audio.]
As you could probably tell, the previous song wasn’t quite finished. Here’s the final version.
[Flash 9 is required to listen to audio.]
We’re having a coding party at Voxar’s place. Sterd got bored of his game. I trololol’d him. He fired up Live and trololol’d me harder than I’ve ever been trololol’d before. (I can’t stop looping!)
Reblogged from rentzsch.tumblr.com
It’s not about Adobe.
It’s not about Flash.
It’s not about cross-platform.
It’s about less code.
It’s about fewer crashes.
It’s about faster-than-C runtime.
It’s about faster development time.
It’s about distributed computing.
It’s about pervasive multicore.
It’s about REPLs and live software.
It’s about software that preemptively exposes my coding errors.
It’s about better software.
Reblogged from So in, so out...
Every time you do something that’s hard for you, every time you transcend some personal boundary or cross some goalpost you thought uncrossable or work really fucking hard at something (even — especially — if you fail) or do something you thought you couldn’t do, it is an accomplishment, and it’s important to acknowledge it. Every time you receive a compliment and say “thank you” instead of “oh, it’s nothing”, you are striking a blow against a poisonous, toxic, and dangerous social model. And every time you do that publicly, you give strength to someone else who sees you do it, because by accurately valuing your accomplishments and achievements as accomplishments and achievements, you teach others that their similar accomplishments and achievements are things to be valued — and thus, by extension, that they are to be valued.
And every time you see someone trying to downplay their achievements, especially compared against someone else’s, remind them that accomplishment is not a zero sum game: your achievement doesn’t reflect upon another’s, and another’s doesn’t reflect upon you. Measure against yourself. That’s the only standard that matters.
And if you’re one of those people who are policing the social appropriateness of claiming one’s accomplishments and placing value upon them in public, just fucking stop it already.
”