Overooped

Fantastic and beautiful conclusion to Everything is a Remix, by...

Sun, 19 Feb 2012 20:28:13 +0100

Fantastic and beautiful conclusion to Everything is a Remix, by Kirby Ferguson.

You can't discover anything if you can't see what you're doing.

Sat, 18 Feb 2012 00:46:00 +0100

The above presentation by Bret Victor is amazing, and I couldn’t stop tweeting about it the other day. My mind was blown at:

4:20. cool! I mean, I’ve seen live editors before, but I never thought of actually using sliders on numbers. Clever! I remember now though, that this has been done by Codea (and probably others) before.

5:25. What. That changes the way I think about programming visual things. I keep thinking of all the times I’ve tweaked an animation or gradient, recompiled, redeployed to device, and get to experience my change maybe a full minute later. How many solutions have I missed, had I just been able to drag a slider to try variations?

I’ve tried to come up with solutions to this problem several times before. My first try was RemoteParameter. However, it is incredibly clumsy to integrate into the code being modified: modified variable must be KVO compliant, it only works for a single spot in the code (so it will fail if you’re e g modifying the background color for all cells in a list), and the editor UI is atrociously bad.

My second try was with NuRemoter. This tool I still actually use, and is somewhat useful in working with living code (sending calls in the middle of animations, debugging time sensitive operations, etc). However, it is not at all visual, and any code I improvise in the NuRemoter UI will be in Nu, which I can’t use as-is in my project without rewriting it into ObjC. I have a few thoughts here, though: first off, I should make it easier to hook Nu code into our code base, so that things that are naturally expressed in a script-y langage, can be. Secondly, the NuRemote protocol can be used as a payload delivery system for other tools. For example, if I ever write an animation construction kit, I could use NuRemoter to upload and inject animation descriptions into the app, and immediately try them out. (I’ve thought of integrating it into my Localizer localization app, too).

Wait, animation construction kit? Well, Core Animation is incredibly powerful and easy to use, but expressing animations in code is both unintuitive and slow (see: write/compile/deploy/test cycle), and maybe tobi is a better animator than me? I want something like the GLSL Shader editor: define input parameters (perhaps start and end locations, duration, intensity) and a sample image as a placeholder for the UIView being animated, and then define animations Keynote-style, possibly with values substituted for parameters. Output a json file, load it at runtime and use it instead of all the animation code. Shouldn’t be THAT hard to build?

6:10. My jaw drops just a tiny bit further, but enough to mark the time. Well, typing autocompletions into the autopreviewing document so that they run automatically is pretty obvious, but I love the idea of showing you what the thing does, rather than having you read documentation. Maybe the right sidebar in Xcode should have movies instead of help snippets?

7:43 and 8:12. How the hell did he do that‽

11:30. Again, how did he do that‽ He’s obviously not re-evaluating the whole file on each change. Maybe he’s been careful when writing the file so that it can be re-evaluated in the context of the currently “running” web page/js-vm? It looks like an incredibly nice way to code games, though. A little bit like Unity I guess; I remember having my mind blown the first time I saw that editor, too.

13:00 and 14:10. Now he’s just showing off. Surely this editor must be specifically written for this game engine he has constructed, and not something generic. Still want that code+editor, though!

Around 16:00 he re-iterates again how easy it is to be creative when you can visualize your results live, and how it doesn’t just apply to visuals or animations, but entire gameplay ideas. I’m so very sold on the idea.

Around 20:00, I really love the idea of supplying sample input data and see how that affects the code you just wrote.

Around 26:00, I should’ve realized that this is the same guy as the one who made That Math Video that blew my mind pretty thoroughly last year. I didn’t, until I checked his web site in preparation for this blog entry. He has plenty of new interesting entries there, if you haven’t checked them out lately.

However, out of all of these, the moment that perhaps isn’t the most interesting to me as a programmer, but never the less tipped me over from “yes, I am impressed” into a squealing, giggling pile of fanboyism, is 31:30. Probably the most amazing animation editor I’ve seen, and probably the most intuitive power user UI I’ve seen, and it’s just an experiment he made? MIND BLOWN.

I love how, instead of trying to solve the problem of tiny hit targets with giant thumbs, he has the user select the layer with her left hand, while manipulating it with her right. It’s a touch surface, and the user has two hands: why is nobody else using this fact‽ (my mind was similarly blown in ‘05 by the same multi-hand usage by TactaPad, which sadly never became an actual product).

Compositing all the different animations the user wants to get into the scene by just scrolling back time and immediately performing the next animation is equally genius (also seen, but not at all as well implemented, in Garageband.). Just look at the amazing speed at which he composes that scene!

However, out of all the amazing things Bret is showing us, none are as inspiring as his outro. Ever since I started programming, I’ve felt an idea or principle just at the edge of my consciousness. I know it’s related to creating a user interaction paradigm that is more natural, but I can’t describe it more clearly than that. I just know, for example, that multitouch is a step in the right direction. I haven’t thought about it too much in the past two years as I’ve been busy at Spotify, and Bret’s note at the end that doing only one thing will not give you insights really hit home.

Alright, enough gushing. I hope that after all that, you did actually watch the video, and that you found as much inspiration as I did. Right now, I just want to stop everything I’m doing and take a few months off life and make tools. I should probably finish a few projects first though…

Rapid network protocol prototyping with TCAsyncHashProtocol

Wed, 28 Dec 2011 23:12:00 +0100

github:TCAsyncHashProtocol. I like constructing simple network protocols from plist/json-safe dicts, and transmit them over the wire as json. Easy to prototype with, easy to debug. Give TCAHP an AsyncSocket, and this is what it’ll do for you, plus support for request-response, and arbitrary NSData attachments.

It is an embarrassment and almost an insult that my example project is a massive 200 lines. I hope to be able to reduce the verbosity and boilerplate clutter of using TCAHP without making it heavy-weight. At the very least, I recommend that you use SPLowVerbosity.

An example of using TCAHP to send a request to update the server’s MOTD:

[_proto requestHash:$dict(
    @"command", @"setMessage", // the command is 'setMessage'
    @"contents", msg // Send 'msg' as the new message to set.
) response:^(NSDictionary *response) {
    // The server has replied.
    if([[response objectForKey:@"success"] boolValue])
        NSLog(@"Successfully updated message!");
    else
        NSLog(@"Couldn't set message, because %@", [response objectForKey:@"reason"]);
}];

And on the receiving side:

-(void)request:(TCAsyncHashProtocol*)proto setMessage:(NSDictionary*)hash responder:(TCAsyncHashProtocolResponseCallback)respond;
{
    NSString *newMessage = [hash objectForKey:@"contents"];
    if([newMessage rangeOfString:@"noob"].location != NSNotFound)
        respond($dict(
            @"success", (id)kCFBooleanFalse,
            @"reason", @"you should be kind!"
        ));
    else {
        _message = newMessage;
        respond($dict(
            @"success", (id)kCFBooleanTrue
        ));
    }
}

(Note the latest piece of magic that I added, where the selector of the delegate method is created based on the value of the key ‘command’ in the message. I quite like it.)

As you can see, the resulting protocol is very weakly typed. In theory, this means you will be making typos and not understanding why the hell your network seems broken; in reality, I’ve never had that problem.

"If you are going to end up with a crappy to mediocre blender anyway, then why bother spending more..."

Mon, 21 Nov 2011 22:47:14 +0100

“If you are going to end up with a crappy to mediocre blender anyway, then why bother spending more or availing yourself of the advice and service of a specialty retailer? Reducing the overall quality of products thus destroys a key competitive advantage of Walmart’s smaller rivals.”

- Is your stuff falling apart? Thank Walmart (grist.org). yay for progress?

"By categorizing our cognitive flaws, documenting not just our errors but also their embarrassing..."

Wed, 26 Oct 2011 23:13:55 +0200

“By categorizing our cognitive flaws, documenting not just our errors but also their embarrassing predictability, he has revealed the hollowness of a very ancient aspiration. Knowing thyself is not enough. Not even close.”

- Is Self-Knowledge Overrated? at the new yorker. not very surprising, but sort of confirms that everyone’s an idiot, not just me :P

I’ve been trying to build a wearable computer since...

Wed, 19 Oct 2011 23:34:00 +0200

I’ve been trying to build a wearable computer since forever, but I sort of got stuck because there aren’t (or I can’t find) any good HMDs (head-mounted displays) that don’t cover your entire field of vision (covering just one eye is fine, but being see-through would be the best, of course). I’ve had a Google Alert on the AirScouter for a year or so, and it seems they’re finally releasing them in some sort of product. I want one *so badly*, but they’re targeted at industrial application and priced thereafter, at $5200 :( I may be a huge frickin’ nerd, but I can’t really justify spending that kind of money on yet another hobby project…

Photo

Thu, 06 Oct 2011 20:23:40 +0200

"Your brain begins to know that you are “enjoying” yourself, even if you hate this insipid thing. In..."

Tue, 27 Sep 2011 20:21:45 +0200

“Your brain begins to know that you are “enjoying” yourself, even if you hate this insipid thing. In spite of a love-shaped hole in the center of your spirit re: this electronic monster, you will not turn away. […] What gruesome psychomathematiconomist devised this heart-labyrinth?”

- insertcredit (4 chapters) reminds me why I hate “social games” more than TV. Memetic T-Viruses, turning human beings into zombies.

How To Fix Xcode 4

Sat, 03 Sep 2011 20:59:00 +0200

People are sort of tired of me complaining; I’ve been saying I hate Xcode 4 since the first time I used it. “You’ll get used to it!”, “Learn Behaviors and everything will be well”, “Embrace the new UI model”, they said. I’ve been using it exclusively for several months now, trying to explore and use every feature of it; make sure to try to find a way in which I can confidently work in it. I failed. Launching Xcode 3 is a fresh breeze every time.

Just a note up front: I’m not saying Xcode 4 sucks. It is light-years ahead of Xcode 3 in many ways, particularly autocompletion and the IDEs idea of what the code contains (inline warnings and errors as you type is wonderful). This is just about the way it manages windows and tabs. And even then, maybe there is some mode or usage pattern that I don’t know about and would fit me better — if so, please shout in the comment or to my twitter!

Spatial Thinking

Xcode 4 works fantastically for a lot of people. How am I special? Why do I have to try to be so different all the time? Apart from just generally being an annoying sod, I imagine myself being a spatial thinker; I like to think in terms of spatially organizing whatever concepts I’m working with. I loved Classic Mac OS’ spatial Finder, where windows always appeared at the same location were it did last time, and there was a one-to-one mapping between folder and window.

The same goes for me and source code files. I used to work in Condensed Mode in XC 3; a single thin window with a project file listing, all source windows separate, and then dedicated slots for Build and Run windows on a separate screen (together with a terminal or two). I would work with a dozen source files at the same time, placing them around the screen. When I needed one I used recently, I would know where it would be spatially, and could just click a tiny corner or edge peeking out beneath whatever I was working on(1). This way I could also layer other applications in between windows, and have a rather deep pile of things I’m working on. It’s the classic desktop metaphor, and the main argument against Multiple Document Interfaces (MDIs) that we Mac nerds would ridicule Windows users for having to use every day(2).

You might be able to imagine why XC4 would then be a problem for me, with everything in a single window, everything appearing in the exact same location on screen as you instead switch between modes of operation in one screen area, rather than switching between locations and zones on the screen. It was — and is — a complete disaster for my productivity. I spend so much time switching between contexts nowadays, trying to reorient myself.

Staying In the Past?

Trying to work in an Xcode 3 manner in Xcode 4 is worse than just trying to adapt.

One of the best features of Xcode 3 is that it would remember all the open windows of a project when you closed it. In Xcode 4, closing a window is terminating it and its layout forever, and the last window you happen to close will become the main project window. Oh, you accidentally closed the window *you* consider the main window first, and then you had a reference header in a window configured for reading reference headers still open on another screen? Well, I guess that’s your main window now, and you’ll just need to reconfigure it as your main. (Update: There is in fact “Close project” in File which will remember all the windows. This doesn’t help in the situation where you close one window forgetting that you had two open though, which is quite common.)

Want a separate window for your build progress so you can keep track of what’s actually happening in your builds? That’s in a sidebar now, and if you actually want build details, you have to manually choose the latest build results in *another* sidebar, and then switch back to the first sidebar.

Want a separate window for your console output? Hey, there’s this hack where you can name a tab “console”, bring up the debug lower-pane, set that pane to console output, make the pane fill the window, turn off the left-and-right sidebars, drag the tab out to its on window. Remember to put it back in its tab before closing the window though, or it’ll become your project!

OK, this is not working.

Trying To Adapt

The way I work now is to have everything I used to have in separate windows, in separate tabs; and have Behaviors set to switch to them at appropriate times. I have one Build tab and one Debug tab, set up in a pretty nice way. I mean, this is okay, I can work this way. However, I do lose my focus a lot of the time, and I get lost trying to context switch between tabs. And I need to set this up for every project I start working on. And I can’t really use my secondary monitor for the things I like and used to do. And it’s just a pain.

Fixing Shit

Why alienate all spatial thinking developers from the Mac and iOS developer communies? I can absolutely imagine Condensed Mode working in Xcode 4. The concept of optional sidebars everywhere could still work. I’d just want to pull out the Project navigator sidebar into its own window which becomes the ‘project main’ (closing it closes all related windows); allow some of the more awkward sidebars like the Object Library to be a panel like in IB; have dedicated Build and Console windows; and have the IDE try to suggest the “one file per window” concept (but possibly allow browsing different files within one window is the user really wants to). I mocked up a horrible concept in Acorn, for your viewing pleasure:

This would make me very, very happy. Sure, it’d be half as “fast” as Xcode 3, it’d still forget how to autocomplete once a day, and crash pretty much every minute, but at least I could work with it.

Thanks to Brent Simmons for writing “The part of Xcode 4 that tires me out”, finally triggering me to write this post.

(1): This is why I hate Exposé in 10.6 and 10.7. 10.5 and earlier would lay out Exposé windows with the same relative position of windows as they were when non-exposéd. 10.6 started organizing windows in a frickin’ grid, destroying important information about where a window came from and what role it had. (rdar://7044208)

(2): It’s worth to note that the prevalence of MDI on Windows is a symptom of not having a real application metaphor, and thus having to group all windows in a meta-window in order to regain an actual application context. Mac OS never had this problem, as an application is the primary unit of operation and the main metaphor there, and not the window.

"Software today is not engineering. Building the Empire State Building with three thousand people in..."

Sun, 07 Aug 2011 15:55:00 +0200

“Software today is not engineering. Building the Empire State Building with three thousand people in a year is engineering. Programming today is more like the Egyptians piling blocks on each other and hoping it doesn’t fall over.”

- Paraphrasing Dr Alan Kay in his talk “Programming and Scaling”. I got the same sense of depression over the state of our industry when I read about Doug Engelbart’s amazing NLS system from ‘68 and the Hypertext Editing System in ‘67. Yes, we have millions and millions times faster computers today, but what we’re doing today is not news. They realized already in ‘68 that you want direct manipulation and collaborative computing.

Every day, I spend so much time building almost trivial functionality in thousands of lines of code, with brittle APIs that hook into other people’s brittle APIs, because that’s the code base we have, and every other code base seems to be roughly looks like that, too. I spend my weekends learning about C and C-like systems because that’s what I know; I don’t go around learning about compiler-compilers, I’m stuck in what my brain already “knows” that programming is like. I didn’t know twenty minutes ago that you could write a complete compositing 2d graphics environment with 26 compositing method in under 400 lines of code.

My very good friend Martin once told me how different it is to even think in Japanese and Chinese, how those thoughts can’t even be translated into English. Kay’s realization that the same holds true for programming is profound in a way I didn’t realize before.

Back in uni I unwittingly participated in an experiment. One of the teachers arranged two lab sessions with the exact same content, and put Java programmers in one and C++ programmers in the other. We were given some UML and were asked to implement it. The real task had actually been to see how fast we could build it (but were of course not told in beforehand that we were being timed); and while I was fastest in my group and it felt like the C++ came out pretty naturally, the result showed that it took me twice as long to write the code than it took on average for the Java coders.

Ever since then, I’ve been worried that even though I feel like I’m really fast with my tools, those very tools are holding me back, and I’m *really* just a tenth as fast as I could have been with another set of tools. I love ObjC, but it’s still C, it still got non-object types, there’s still manual memory management, everything is viciously verbose, and meta programming is still more limited than in some non-C languages.

Bret Victor, beast of burden

Sun, 07 Aug 2011 12:54:00 +0200

Bret Victor, beast of burden:

Remember that amazing UI math video I posted a while back? He got a nice interview and article in nicecodesign.com. Apparently it was made by Bret Victor. I didn’t know who Bret Victor was until a few moments ago, but it seems he’s pretty much awesome. His web site is rather amazing, and his portfolio page about his work at Apple is very funny and very sad at the same time. He also worked at Push Pop Press; you know, that amazing publishing-revolutionizing company that got black-holed by Big Blue? No, not that Big Blue, the new Big Blue.

"Design patterns in general are a recipe for failure, as they are indicators of flaws in your..."

Sat, 30 Jul 2011 23:38:00 +0200

“Design patterns in general are a recipe for failure, as they are indicators of flaws in your language. A design pattern inherently violates DRY as it means that many people have written something very similar, but it has not been abstracted out.”

- Matthew Maurer in a thread by Andy Matuschak. Whole comment thread is interesting.

Low Verbosity KVO

Sun, 10 Jul 2011 18:50:00 +0200

DRY Cocoa: SPLowVerbosity

I love Objective-C. It’s a very explicit language: there is no magic in the language. If you want such magic as distributed objects, model classes generated at runtime, generic change notification, or heck, even referenced counted memory management, you can implement it yourself in a library. It’s also by convention a very verbose language. If the method name doesn’t say exactly what the method does, the author is doing it wrong.

However, there are some things we type over and over again every day, whose verbosity does not make the code more readable but only serves to pad the code file with useless characters. These are in particular array and dictionary literals, and formatted strings.

ObjC wizard Jens Alfke wrote MYUtilities quite a while ago, and in particular CollectionUtils. This header defines a few very handy macros such as $array(...), $dict(...) and $sprintf(...). $array is simply a shorthand for [NSArray arrayWithObjects:..., nil] (note the extra nil, freeing you from typing that yourself every time, and also avoiding a possible crash). $dict is NSDictionary’s constructor, with the arguments in the right order (key, value, key, value, …). $sprintf is [NSString stringWithFormat:]. It may seem trivial, but this simple header has saved me tons and tons of typing, and surely from some silly bugs as well.

For more C++ friendliness, and to not have to depend on the rest of MYUtilities, I wrote my own, called SPLowVerbosity, with mostly the same things. The details are not interesting, so I won’t list the code; click through if you are curious.

This is a hack, and while it is very convenient, it is not pretty. Objective-C needs in-language literals for arrays, sets, dictionaries and number objects.

I do believe that such literals are now inevitable, though. With ARC, what I wrote in the first paragraph is no longer entirely true. Dealloc now magically calls super. Memory management is implicit and part of the language, not explicit and manual. The sanctity of Objective-C’s simplicity has been violated, parts of Cocoa has been moved into the language. Moving more parts of Cocoa into the language (e g exposing APIs saying ‘this is the class that should be instantiated when I use a dictionary literal’) no longer has a high religious price, and I bet we’ll see it at next year’s WWDC.

Object-Oriented KVO: SPKVONotificationCenter

During the past few years, my nose has started to really pick up on a code smell I didn’t feel before: unencapsulated concepts. What I mean by that is an API concept or contract that is only visible in comments and documentation, thus only implicit by knowledge of that documentation when you read code using the API, instead of exposing the concept as a construct the language can help you manage.

Examples:

Mutex locking as two separate functions that must always be paired. This is an easy to make mistake, and can be very difficult to fix in complexly branching code. Static analyzation can find such errors, but is in my opinion the wrong approach.
UITableView’s beginUpdates/endUpdates must always be called in a pair, and all the updates you make in that pair must match the changes you are doing to the data source.
NSNotificationCenter requires you to register for a notification with a {sender, receiver, name} triplet, and reuse that triplet to destroy the subscription. In practice what you have here is an implicit object that you must manage using an awkward object triplet, rather than an actual object.
Key-Value Observing, with the same defect as with notifications, plus that callbacks are dispatched to the same instance method, forcing you to use the triplet plus a context pointer as the identifier again.

Instead of the above concepts being implicit and only visible in documentation, several of them can be represented as objects and closures, thus making it impossible to do wrong.

The realization is not new, of course. It’s quite common to use RAII patterns in C++ to encapsulate concepts in code, giving them an explicit start point and a managed (and deterministic) end point.

But this is Objective-C, not C++, so we don’t have RAII. We do have objects, however, and if we use them to actually represent our objects, we can clean up so much code.

SPKVOObservation is an object that represents a KVO subscription. When this object is created, you know you have your subscription. When this object disappears, you know the subscription is gone. By managing instances of this class like I would any other instance variable, I know I’m following KVO’s subscribe/unsubscribe contract. (With ARC, I don’t even have to manage the ivar).

SPKVONotificationCenter also has dispatch to a given selector instead of the catch-all -[NSObject observeValueForKeyPath:ofObject:change:context:].

(As for solutions for the rest of the examples: a closure can be used for the mutex case if in the current scope, otherwise you might want RAII (which is possible with GNU extensions even in C). For the table view, I’d prefer bindings, but doing to-many KVO and bindings can be really hard, so I doubt we’ll be seeing it on iOS in the near future.)

DRY KVO: SPDepends

I love KVO. Basically every library I’ve ever used has their own implementation of notifications on attribute changes. Such an implementation is of course not difficult, but because there is no generic system for it in other languages/platforms, you can’t build a framework for working with change notifications generically. Recognizing that this is a generic concept, and then as good as building it into the language is genius, and has given us wonders such as bindings.

Outside of their use in bindings where you have tool help, KVO’s API is pretty bad, and working with it is almost painfully verbose (made worse by the single callback point, spreading your code out all over the file). What I really wanted to do was to unify the two above sections for a very simple, non-verbose and object oriented approach to KVO. The result is SPDepends. Magic is taken to the next level; we are approaching dark arts. Whether what I’m about to present is actually a good idea or not, I leave as an exercise for the reader. First, the header:

tl;dr: SPDepends lets you give it a list of {object, key path(s)} pairs that one of your properties depend on. When the value of any of the given key paths changes, a given closure is called, letting you recalculate the dependent property (or whatever you want to do). It’s about as far as you can go with KVO without actually building bindings.

There is one additional piece of magic related to memory management (this was before ARC). By providing an owner and associationName, the dependency is assigned as an associatedObject, so that it will automatically be cleaned up when the owner object dies. Defining a dependency again with the same name will also throw away the old dependency. If this is not desired, you can just not provide the association name, and instead manage the returned SPKVOObservation object on your own.

Example:

Output:

Note how short the $depends macro makes all your KVO work. The macro also defines a block-safe self variable selff that won’t create a reference cycle.

The equivalent classical KVO code would be many lines longer. However, this macro takes several steps away from how Cocoa code is normally written. Is the syntax too obscure? Is the code still readable for normal human beings?

THIS. This is how to teach math. The contrast between the...

Wed, 18 May 2011 23:35:21 +0200

THIS. This is how to teach math. The contrast between the Wikipedia page and this application’s UI is striking.

File format plugin API for Spotify?

Sun, 15 May 2011 11:20:00 +0200

At Spotify, we have one and a half day of ‘hackday’ (‘code whatever you want’, the ‘20% time’ concept from Google) every sprint. Since the past few months have been a bit hectic finishing up the new 0.5.0 release, we haven’t really had time for that in a while, and thus compensated by having a whole week of crazy hacking this week. I managed to finish two features in that time; one in the iOS client (of which I will only say: Loren Brichter is my hero!), and one in the desktop client: file format plugins.

Last year, one of my hackday projects was integrating blargg’s Game Music Emu into Spotify, thus letting you play NES, GameBoy, SNES, Genesis, PC Engine and other console’s music files in Spotify. Just a few days of work, and suddenly I had the best console music player app in the world, with playqueue, playlists and whatnot. However, GME is LGPL and we statically link our dependencies, so there was no way I could release it :(

Thus, I aimed to hit two birds with one stone: by adding a file format plugin API to Spotify, I could a) enable anyone to add support for their favorite file format in Spotify (flac, mikmod, sid, …) b) let me release the GME support as an open source plugin!

However, I’ve never designed a plugin API in C before, and if we’re going to release it and support it for quite a while, it should be well designed, easy to use, and cover all the basic needs. It’s versioned, so it should be simple to add new things to the API, but changing the existing ones might be tricky. So, my question is: do you have any feedback for me on this api?

"When you hand a recursive mutex down from one routine to another, the callee cannot know the state..."

Fri, 15 Apr 2011 00:08:59 +0200

“When you hand a recursive mutex down from one routine to another, the callee cannot know the state of predicates in the caller. It has to assume there are some, because it cannot verify there aren’t; and if the caller had known that there were no broken predicates, it should have allowed concurrency by unlocking.”

- So, late night hacking trying to fix a stupid bug in Spotify. Find out that all mutexes in the Spotify codebase are recursive. Googleathon about recursive locks. Find interesting stackoverflow answers and blog posts and stuff. Some say recursive locks are Evil, but their arguments aren’t super-solid. Find the guy who wrote recursive locks in pthreads. He has good arguments.

Basically: If you don’t know exactly the state of the stuff the lock is locking, how can you ever dare to call out to other code that would modify the stuff by taking the recursive lock? If you DO know exactly the state of the stuff the lock is locking, why are you holding the lock?! In other words, don’t use recursive locks.

"On the plus side, it’s now easier to add a new contact, and I can decide whether to call somebody or..."

Wed, 30 Mar 2011 21:58:23 +0200

“On the plus side, it’s now easier to add a new contact, and I can decide whether to call somebody or start a chat by hovering over a contact. On the minus side, everything else.”

- ignorethecode on the atrocity that is Skype 5. It really is a bloated, ugly, misbehaving piece of crap software. It’s even worse than the original MSN Messenger for Mac OS, and that’s quite an achievement. (Bloated chat UIs are a pet peeve of mine; I had an argument with my friend Sterd about it back before I had successfully converted him to a Mac user (:P) using this picture comparing the space efficiency of an MSN for Windows chat window with that of Adium, and not even using one of the minimalistic Adium themes.)

iOS 4.3: imp_implementationWithBlock()

Tue, 29 Mar 2011 10:32:36 +0200

iOS 4.3: imp_implementationWithBlock():

iOS 4.3 has a new objc api: adding method implementations using blocks. I tried to do the same once using libffi but never had the patience to finish it. This is a prettier solution anyway.

"Eskil Steenberg (creator of Indie MMO “Love” - which is also a Voxel world engine of sorts) has told..."

Fri, 18 Mar 2011 10:27:48 +0100

“Eskil Steenberg (creator of Indie MMO “Love” - which is also a Voxel world engine of sorts) has told me that he doesn’t bother with small chunks – he just has a single Vertex Array that represents an entire quadrant of his spherical world, and to get around the massive waste of space he actually has to _defrag_ his graphics memory using his own memory management functions running on his GPU, effectively pushing all the active visible triangles together, and leaving a single large clear area of graphics memory for future triangles to be placed. This is the kind of batshit crazy engine programming I’ve come to expect from Eskil, and is not for the faint of heart.”

- Defcon - Minecraft + Physics = Awesome (how can you not read an article with that title?)

UIKit: Hide the keyboard without a reference to the currently focused text field

Wed, 16 Mar 2011 15:14:21 +0100

Googling for answers to UIKit or iOS/iPhone programming problems today resembles googling for answers to JavaScript problems. There is so much horribly, horribly broken code out there, being promoted as the way to do things. Ranting aside, today’s problem is writing your own view controller container, and noticing that focused UI elements don’t dismiss their keyboard in response to viewWillDisappear: or similar. If this was MacOS, or AppStore approval didn’t exist, you’d just do [self.view.window.firstResponder resignFirstResponder]. You can’t do that though, firstResponder is private on window, don’t ask me why. cdyson37 on StackOverflow however, found the public API -[UIView(UITextField) endEditing:] hidden in a category in UITextField.h, that supposedly looks recursively through the receiver’s children for the first responder, and if found, resigns it. Perfect! A copy-pasteable code snippet for lazy googlers:

[self.view endEditing:YES]