Planet Linux Australia

Syndicate content
Planet Linux Australia -
Updated: 29 min 3 sec ago

Andre Pang: Starcraft: The Terran Campaign

Tue, 2014-07-08 05:26

One o’ me good mates, sent me an email recently with a rather chortle-worthy summary of the HumanTerran plot of Starcraft I. Without further ado:

Raynor: Oh shit, nasty alien things with big teeth. Let’s put our faith in the supremely experienced commander who will save us (after I teach him how to build a command center, barracks and use the ‘repair’ button).


Zergling: Grrrrowl! Yummm!

Raynor: (shoots gun from his cool looking vulture bike)

Zergling: Gah! (dies)

Duke: Raynor. You’re a bad bad man. Why did you kill that cute little Zergling?

Raynor: It tried to eat me.

Duke: Well, tough. You should’ve asked me permission first because I’m the big boss of the Confedration and on one can take a shit unless I say so. Off to prison with you!

Raynor: Help! Get me outa here!

Mengsk: I’ll help! (opens the door) Hi. I’ve got this terrorist label but actually I’m a nice guy. The Confederation are the REAL baddies. Just to prove it, let me introduce you to my hot babe assistant. Remember, only good guys have hot babe assistants.

Kerrigan: Hi!

Raynor: …

Kerrigan: Wha! you perv!


Raynor: Huh what? How did you you know that I was thinking about having hot monkey sex with you up against the side of my bike whilst wearing a ballerina’s tutu?


Mengsk: She’s a telepath.

Kerrigan: Well, yes. And you’re staring at my tits.

Duke: Erm… fellas? Sorry to bother you… my ship sorta crashed in the middle of all these Zerg and they want to eat me. 


Raynor: Suck ass!


Mengsk: I’ll save you.


Raynor: WHAT!?!?


Mengsk: Well… Raynor will save you.


Raynow: WHAT!?!?! Oh… ok. (saves Duke)


Duke: Mengsk? YOU! I hate you with the white hot intensity of a thousand suns. I teach children to eat the liver of your dogs. You are a blight on all humanity and the scourge of the universe. The Confederation will never rest until we destroy you entirely!


Mengsk: Join me!

Duke: Ok.

Mengsk: Cool… Duke, what’s say you and I go kill all your former buddies in the Confederation.


Duke: Ok.


Raynor: uh… what about the Zerg?

Mengsk: No no. Much more important to kill Confederates.


Raynor / Kerrigan: uh… why?


Mengsk: Just do as you’re told.


Tassadar: Hey guys. We Protoss honour, respect and revere all sentient life. Therefore, we’re going to incinerate your planet. 


Mengsk: Oh shit. That means we don’t get to kill Confederates. Kerrigan, go kill the Protoss so that I can use this Psi-transmitter gadget to lure Zerg to kill Confederates. 


Kerrigan / Raynor: Erm… is this making any sense?

Kerrigan: I must do as I’m told because I’m a hot babe assistant. Ok, off I go to kill Protoss and lure Zerg and plant this Psi thingy.

Zerg Overmind: Who’s the hot chick in the catsuit. She’d look even cooler with green blood. I”m going to infest her… this will be fun. (infests Kerrigan) (Then Zerg go on to kill all Confederates)

Mengsk: YAY! All the Confederates died!

Raynor: You suck Mengsk. You too Duke. I’m leaving and coming back in a later chapter filled with vengenace to whomp your sorry asses. I’ll probably fall in love with Kerrigan since I’m the obvious hero and she’s the obvious heroine, but she’s infested with Zerg blood now… but I’ll use love to reach into the depths of her heart and rescue her and turn her back to the light side.

Andrew, please finish the Zerg and Protoss campaigns soon; we’d love to hear more.

Andre Pang: MacDev 2009

Tue, 2014-07-08 05:26

I have the small honour of being a speaker at the maiden conference of MacDev 2009, a grass-roots, independently run, Mac developer conference in the UK that’s being held in April next year. MacDev looks like it’ll be the European equivalent of C4, which was absolutely the best Mac developer conference I’ve ever been to; I’d say it’s the Mac equivalent of If you’re a Mac developer at all, come along, it should be great fun, and give your liver a nice workout. Plus, how can you ignore such a sexy list of speakers?

Update: My talk abstract is now available…

One reason for Mac OS X’s success is Objective-C, combining the dynamism of a scripting language with the performance of a compiled language. However, how does Objective-C work its magic and what principles is it based upon? In this session, we explore the inner workings of the Objective-C runtime, and see how a little knowledge about programming language foundations—such as lambda calculus and type theory—can go a long way to tackling difficult topics in Cocoa such as error handling and concurrency. We’ll cover a broad range of areas such as garbage collection, blocks, and data structure design, with a focus on practical tips and techniques that can immediately improve your own code’s quality and maintainability.

I am a great believer in getting the foundations right. Similarly to how bad code design or architecture often leads to a ton of bugs that simply wouldn’t exist in well-designed code, building a complex system on unsteady foundations can produce a lot of unnecessary pain. What are the foundations of your favourite programming language?

It’s 2008 and we’re still seeing buffer overflows in C.

Andre Pang: Speaking at DevWorld 2008

Tue, 2014-07-08 05:26

For Mac developers in Australia, I’ll be speaking at the inaugural conference of DevWorld 2008, which will be held from September 29-30 this year in Melbourne. You can check out the full list of sessions; I’ll be giving the very last talk on that page: The Business of Development.

Coding is just one part of what makes a great product, but there’s always so much else to do and learn. So, what can you do to help ship a great product—besides coding—if you’re primarily a developer? In this talk, learn about important commercial and business issues that you, as a coder, can help to define and shape in your company, such as licensing and registration keys, adopting new technologies, software updates, handling support, your website, and crash reports.

Note that DevWorld 2008 is unfortunately only open to staff and students at an Australian university (“AUC member university”, to be exact), so unless you’re a student right now at one of those Unis, you’ll have to miss out on this incredibly exciting opportunity to hear me talk at you for an hour (snort). I hear the story behind this is that if this year’s DevWorld is successful, next year’s will be a more standard open conference. Anyway, hopefully catch some of you there in September!

Andre Pang: Solid State Society

Tue, 2014-07-08 05:26
The traditional hard disk that’s likely to be in your computer right now is made out of a few magnetic circular platters, with a head attached to an actuator arm above the platter that reads and writes the data to it. The head’s such a microscopic distance away from the platter that it’s equivalent to a Boeing 747 flying at 600 miles per hour about six inches off the ground. So, when you next have a hard disk crash (and that’s when, not if), be amazed that the pilot in the 747 flying six inches off the ground didn’t crash earlier.

Enter solid-state drives (SSDs). Unlike hard disks, SSDs contain no moving parts, and are made out of solid-state memory instead. This has two big advantages: first, SSDs don’t crash (although this is a small lie—more on that later). Second, since SSDs are made out of memory, it’s much faster than a hard disk to get to a particular piece of data on the disk. In other words, they have a random access time that are orders of magnitude faster than their magnetic cousins. Hard disks need to wait for the platter to rotate around before the head can read the data off the drive; SSDs simply fetch the data directly from a memory column & row. In modern desktop computers, random access I/O is often the main performance bottleneck, so if you can speed that up an order of magnitude, you could potentially make things a lot faster.

Unfortunately, while SSDs are orders of magnitude faster than a hard disk for random access, they’re also an order of magnitude more expensive. That was until May this year, when this thing appeared on the scene:

(Image courtesy of

That boring-looking black box is a 120GB Super Talent Masterdrive MX. As far as SSD drives go, the Masterdrive MX is not particularly remarkable for its performance: it has a sustained write speed of just 40MB per second, which is a lot lower than many other SSDs and typical hard disks.

However, it’s a lot cheaper than most other SSDs: the 120GB drive is USD$699. That’s not exactly cheap (you could easily get a whopping two terabytes of data if you spent that money on hard disks), but it’s cheap enough that people with more dollars than sense might just go buy it… people like me, for instance. I’ve had that SSD sitting in my lovely 17” MacBook Pro for the past two months, as an experiment with solid-state drives. So, how’d it go?

I’ll spare you the benchmarks: if you’re interested in the raw numbers, there are a number of decent Masterdrive MX reviews floating around the Web now. I was more interested in the subjective performance of the drive. Does it feel faster for everyday tasks? Is it simply a better experience?

The overall answer is: yes, it’s better, but it’s not so much better that I’d buy the SSD again if I could go back in time. With a hard disk, things occasionally get slow. I’m sure I’m not the only one to witness the Spinning Beachball of Death while I wait 5-10 seconds for the hard disk to finally deliver the I/O operations to the programs that want them completed. With a hard disk, launching a program from the dock would sometimes take 20-30 seconds under very heavy I/O load, such as when Spotlight’s indexing the disk and Xcode’s compiling something. With the SSD, those delays just went away: I can’t even remember a time where I saw the evil Beachball due to system I/O load.

The most notable difference was in boot time. A lot of people love how Mac OS X is pretty fast to boot (and I agree with them), but when you go to log in, it’s a very different story. If, like me, you’ve got about ten applications and helper programs that launch when you log in, it can take literally minutes before Mac OS X becomes responsive. I clocked my MacBook Pro at taking just over a minute to log in with my current setup on a hard disk (which launches a mere half a dozen programs); the SSD took literally about 5 seconds. 5… 4… 3… 2… 1done. What is thy bidding, my master? I wish I’d made a video to demonstrate the difference, because it’s insanely faster when you see it. 10x faster login speed is nothing to sneeze at.

However, aside from boot up time, normal day-to-day operation really was about the same. Sure, it was nice that applications launched faster and it booted so fast that you don’t need to make a coffee anymore when logging in, but those were the only major performance differences that I saw. Mac OS X and other modern operating systems cache data so aggressively that I guess most of the data you’ll read and write will usually hit the cache first anyway. The lower sustained write performance didn’t end up being a problem at all: the only time I noticed it was when I was copying large torrented downloadsfiles around on the same drive, but that wasn’t slow enough for me to get annoyed. The one benchmark that I really cared about—compiling—turned out to take exactly as long on the SSD as the hard disk. I thought that maybe it was possible that random I/O write speed was a possible bottleneck with gcc; it turns out that’s not true at all. (I’ll also point out that I was using Xcode to drive most of the compilation benchmarks, which is one of the fastest build systems I’ve seen that uses gcc; no spastic libtool/automake/autoconf/autogoat insanity here.) Sorry to disappoint the other coders out there.

Aside from performance, the total silence of the SSD was a nice bonus, but it’s not something that you can’t live without once you’ve experienced it. In most environments, there’s enough background noise that you usually don’t hear the quiet hard disk hum anyway, so the lack of noise from the SSD doesn’t really matter. It was, however, very cool knowing that you could shake your laptop while it was on without fear of causing damage to your data. I’m usually pretty careful about moving my laptop around while it’s on, but with an SSD in there, I was quite happy to pick up the machine with one hand and wave it around in the air (as much as you can with a 17” MacBook Pro, anyway).

So, with all the nice small advantages of the SSD, you may be wondering why it’s no longer in my MacBook Pro. Here’s some reviews of the disk on that may give you a hint:

It turns out those reviewers were right. Two months after I bought it, the Masterdrive MX completely died, which seemed like a pretty super talent for an SSD. The Mac didn’t even recognise the disk; couldn’t partition it; couldn’t format it. So much for SSDs not crashing, eh?

While SSDs don’t crash in the traditional manner that a hard disk may, there’s a whole number of other reasons why it might crash. RAM’s known to go wonky; there’s no reason why that can’t happen to solid-state memory too. Maybe the SATA controller on the disk died. No matter what the cause, you have the same problem as a traditional hard disk crash: unless you have backups, you’re f*cked. Plus, since I was on holiday down at Mount Hotham, my last backup was two weeks ago, just before I left for holiday. All my Mass Effect saved games went kaboom, and I just finished the damn game. André not very happy, grrr.

So, what’s the PowerPoint summary?

  • The Super Talent Masterdrive MX would be great buy if it didn’t friggin’ crash and burn your data with scary reliability. Even if you’re a super storage geek, avoid this drive until they have the reliability problems sorted out.
  • The Powerbook Guy on Market St in San Francisco is awesome. They were the guys to install the SSD in my MacBook Pro, and were extremely fast (two-hour turnaround time), professional, and had reasonable prices. (I would’ve done it myself, but I’d rather keep the warranty on my A$5000 computer, thanks.) Plus, they sold me the coolest German screwdriver ever for $6. (“This one screwdriver handles every single screw in a MacBook Pro”. Sold!)
  • The MacCentric service centre in Chatswood in Sydney is equally awesome. When the SSD died, they quoted me the most reasonable price I had ever seen for a hard disk swap in a MacBook Pro (have you seen how many screws that thing has?), and also had a two-hour turnaround time. Yeah, I know, decent Mac service in Australia! Woooooah.
  • Back up.
  • SSDs are great. I think they’ll complement rather than replace hard disks in the near future, and possibly replace them entirely if the price tumbles down enough. Next-generation SSDs are going to completely change the storage and filesystem games as they do away with the traditional stupid block-based I/O crap, and become directly addressable like RAM is today. Just don’t believe the hype about SSDs not crashing.

I, for one, welcome the solid state society. Bring on the future!

Andre Pang: Six Months in San Francisco

Tue, 2014-07-08 05:26

I feel like there’s been four stages to my life. The first stage was being a youngling at primary school: I don’t remember much from there except that I fantasised about handball being an olympic sport. The second stage was the PC demoscene, where I grew interested in many things that I love today about computing: art, music, and my first experience with a community and culture that you could love and immerse yourself in. The third stage was my twenties: an introduction to university, Linux, coding, the Mac, Haskell, research conferences, industry conferences, the working life, and balancing it all with healthy doses of relaxation, food and the beautiful world that Sydney had to offer. The fourth stage was tearing myself away from that fairly sheltered life and my emotional base, and moving to San Francisco.

I’ve been here for six months. It’s felt like two years. It has been a truly wonderful experience: making new friends, learning a new culture that’s both significantly but subtly different, and doing it all without my family nearby, who’ve been my anchor and support for the past three decades. Part of the motivation was proving to myself that I could make it on my own: prove myself worthy in the eyes of my peers, be social enough to make genuine friends here who I cared about and who cared about me, living on my own and simply paying the rent. Part of the motivation was to shake things up from a cruisy life in Sydney and experience new things. I’m glad to report that the experiment’s going pretty well so far.

San Francisco is a city of immense contrast. For every stupid hipster who thinks that owning a Prius absolves them of their environmental debt to society, there are remarkable individuals who understand and challenge the daunting realism of politics, lobbying, energy, transformity and limits to growth. For every poser upstart get-rich-quick guy chasing after VC funding for Facebook apps, there are the quiet anonymous developers at Apple, Google, and startups you’ve never heard of who work on all the amazing technologies that the entire world takes for granted today. The Tenderloin, so unpleasant to walk through, has some of the very best restaurants and bars that the city has to offer. The nouveau shiny high-rises of South Beach contrast with the destitute run-down feel of western SoMa, only a few blocks away.

It’s a make-or-break city: rents are insanely high despite the rent control laws, and there’s no lower-middle class population here because either you’re flying high, or you’re not flying at all. It’s natural selection in action: either you keep up with the pack and continue being successful, or you fall and become left behind. And so, in contrast to the relaxed lifestyle of Sydney, San Francisco is full of ambition. While it lacks the non-stop pace of New York or the late-night industry of Detroit and Chicago, the people here want to change the world, and they have the innovation, the smarts and the determination to do so.

The tech industry here is simply amazing. Despite being here for half a year, I’m still floored when I go to a party and every person I meet there ends up being a Web designer, or a coder, or a sysadmin, or a DBA, or a network engineer, or a manager of a bunch of coders, or a VC funding a tech company, or a lawyer or accountant or marketing or PR person working for a tech company, or a level designer or artist working for a games company. Even the girls. It boggles me. It’s like the entire Bay Area simply exists to build software and iPhones and tech solutions. I was truly daunted in the first few months to find out that everyone around me was, well, just like me. A few months ago, I was at my favourite little tea shop in San Francisco decompressing and minding my own business, when three people sat down next to me and started talking about VGA BIOS exploits. (Turns out that they work for VMware.) I mean, seriously?

I wouldn’t say that I’m totally acclimated to the Bay Area yet, and perhaps I never will be. Visiting Australia just a month ago reminded me just how different the two cities are in their lifestyles. People are always doing something in San Francisco: there’s so many interesting people there that you feel like need to divide your time between groups, let alone having time to yourself. Even the serious introverts there are out on most schoolnights. The people here are always switched on; even at a party, there’s an air of networking going on and the feeling of opportunities to be seized. You almost always end up talking shop at any event, because people here are defined by what they do: one of the very first questions you’re usually asked is “Where do you work?” or “What do you do for a living?”. In Sydney, asking that question so soon would just be a little bit weird. You usually save that for far later in the conversation, when you’re running out of things to say to the pretty girl to try to hook up with her. (And don’t even get me started about the American dating scene.)

And so, for all the wonderful parks, bars, tacos, restaurants, pirate shops and museums of the city; the incredible beauty and varied terrain of the North Bay; the charm and chilled suburbia of North Berkeley in the East; and the innovation and serenity of Silicon Valley just south, I still miss Sydney and the culture I grew up with for twenty years. I don’t mean that in a yearning way or mean to imply that San Francisco is somehow inadequate, because it rocks: I’m having a wonderful time experiencing new things, and it was the right decision to move here. This is where I should be at this stage in my life. Sydney will always be where my heart is, but right now, San Francisco is home, and it’s as fantastic as I hoped it would be.

Andre Pang: Self-Reflection

Tue, 2014-07-08 05:26

R. A. Salvatore, Road of the Patriarch, p. 280:

The point of self-reflection is, foremost, to clarify and to find honesty. Self-reflection is the way to throw self-lies out and face the truth—however painful it might be to admit that you were wrong. We seek consistency in ourselves, and so when we are faced with inconsistency, we struggle to deny.

Denial has no place in self-reflection, and so it is incumbent upon a person to admit his errors, to embrace them and to move along in a more positive direction.

We can fool ourselves for all sorts of reasons. Mostly for the sake of our ego, of course, but sometimes, I now understand, because we are afraid.

For sometimes we are afraid to hope, because hope breeds expectation, and expectation can lead to disappointment.

… Reality is a curious thing. Truth is not as solid and universal as any of us would like it to be; selfishness guides perception, and perception invites justification. The physical image in the mirror, if not pleasing, can be altered by the mere brush of fingers through hair.

And so it is true that we can manipulate our own reality. We can persuade, even deceive. We can make others view us in dishonest ways. We can hide selfishness with charity, make a craving for acceptance into magnanimity, and amplify our smile to coerce a hesitant lover.

… a more difficult alteration than the physical is the image that appears in the glass of introspection, the pureness or rot of the heart and the soul.

For many, sadly, this is not an issue, for the illusion of their lives becomes self-delusion, a masquerade that revels in the applause and sees in a pittance to charity a stain remover for the soul.

… There are those who cannot see the stains on their souls. Some lack the capacity to look in the glass of introspection, perhaps, and others alter reality without and within.

It is, then, the outward misery of Artemis Entreri that has long offered me hope. He doesn’t lack passion; he hides from it. He becomes an instrument, a weapon, because otherwise he must be human. He knows the glass all too well, I see clearly now, and he cannot talk himself around the obvious stain. His justifications for his actions ring hollow—to him most of all.

Only there, in that place, is the road of redemption, for any of us. Only in facing honestly that image in the glass can we change the reality of who we are. Only in seeing the scars and the stains and the rot can we begin to heal.

For Rebecca, who holds that glass of introspection higher than anyone else I’ve ever known. Thank you for everything.

Andre Pang: rcp in Erlang in 5 lines of code

Tue, 2014-07-08 05:26

Joe Armstrong, the Main Man behind Erlang, shows how to write an FTP client in Erlang in a couple of lines of code. Some of my own points:

  • People on his blog who comment that “what operating system comes without an FTP server?” are totally missing the point, which is that Erlang makes it easy to write network programs. How many lines of code do you think it would have taken to do that in C? That file transfer program he wrote is less than half a dozen lines.
  • Yes, it’s not a real FTP client, duh. Erlang does actually come with an FTP module which you can use in your own program, though.

Andre Pang: Markup Plugin for RapidWeaver 5

Tue, 2014-07-08 05:26

For the RapidWeaver users out there, I’ve updated my antique Markup plugin to work with RapidWeaver 5 (slow clap). It also now lives on GitHub, like all the other cool open-source projects published after about 1970. (BitBucket is so 1969.)

As an aside, ohmigosh, there still isn’t anything out there that’s as good as RapidWeaver for building websites. I wanted to redo my site, and looked into a bunch of RapidWeaver alternatives, especially Web apps. Tumblr, Wordpress, Blogger and all that are great for just blogs, but useless for building anything more than a blog. Online site-builders like Squarespace, Weebly, and Virb are either way too dumbed down, too complex, have the most boring themes, or more likely, are all of the above. Despite RapidWeaver still being compiled for ppc and i386 only (it’s not a 64-bit app yet), and using the Objective-C 1.0 runtime (my Markup plugin uses +[NSObject poseAsClass:]!), it is still the best thing going for building sites. Amazing.

Anyway, Markup plugin, go get it.

Andre Pang: Raganwald on Geek Attitude

Tue, 2014-07-08 05:26

Reg Braithwaite has said very eloquently something I’ve been meaning to express for a long time:

When someone says something outrageous, like “f*ck compilers and their false sense of security”, it is not important whether I happen to think that programming languages with strong, expressive type systems are valuable (hint: I do). What is important is to look at this statement and ask yourself: Is there just one thing in there, one kernel of wisdom that I can extract and use to be a better programmer?

I wrote about geek culture and criticism earlier, but Braithwaite knocks it up a notch and hammers the point home in a single paragraph. To use an analogy, being a good geek is like being a good partner in a relationship… step one: listen. Step two: empathise. (Step three: profit!)

Andre Pang: Quicksilver for Developers

Tue, 2014-07-08 05:26

If you are:

  1. a Mac OS X user,
  2. a coder, web developer, or hacker of some sort (C/C++, Cocoa, Python, Ruby, Web dude(tte),

I just found a mighty good use of Quicksilver that I wanted to share—getting at reference documentation when you’re coding. Now, I hit Cmd-Space to invoke Quicksilver, and then type in, say:

  • NSString to bring up the Cocoa Foundation documentation about the NSString class,
  • sscanf to bring up the sscanf(3) manpage, or
  • dict to bring up the Erlang dict module.

Nice, no?

Quicksilver uses a number of catalogs to create its big list of items that you can search. For example, there’s a Quicksilver plugin that catalogs applications on your hard disk, so that when you start typing iTun, Quicksilver searches the applications catalog to find iTunes. If you start typing in a person’s name, the Address Book plugin has catalogued your Address Book and will search on that.

The neat thing is, you can add your own custom catalogs pretty easily, by indexing text files and HTML files. Quicksilver comes with a File and Folder scanner plugin that you can use to index reference documentation. Adding a custom catalog is easy:

  1. go to Quicksilver’s Preferences,
  2. select the Catalog tab,
  3. select the Custom catalog type on the left-hand pane,
  4. click the + button and pick “File & Folder Scanner”,
  5. add the text/HTML file to be used as a catalog, and
  6. set the “Include Contents” pop-up button in the Inspector pane (the i button in the bottom-right hand corner) to HTML Links or Text Lines, as appropriate.

You probably want to also set Quicksilver to rescan your catalog once in a while: I’ve set mine to rescan every hour.

Here’s some example usage scenarios:

  • Cocoa developers: Add /Developer/ADC Reference Library/documentation/Cocoa/Reference/Foundation/ObjC_classic/index.html as a catalog to index the Foundation kit classes, and /Developer/ADC Reference Library/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/index.html to index the AppKit classes. Now, you can type any class name (such as NSString or NSWindow) at the Quicksilver prompt to immediately bring up the Cocoa documentation in your preferred Web browser.
  • UNIX developers: Install Bwana, which provides a kickass HTML version of your system’s manpages. (It dynamically generates them on demand, so don’t worry, it won’t take up another 100MB of space.) An an aside, Bwana’s the very first manpage viewer I’ve liked besides running man(1) itself in a shell. Run Bwana once and hit the Index button so it can index all the manpages. Add ~/Library/Caches/Bwana/manindex-.html to your Quicksilver catalog, and all of your manpages will now be indexed. Bam, type in printf at a Quicksilver prompt, and behold as all those formatting specifiers you forgot magically appear in your Web browser.
  • Erlang developers: Download the Erlang documentation and keep it somewhere on your local hard disk. Add the doc/index.html file as a catalog, and bam, type in dict to bring up the Erlang dict module functions in your Web browser.

Of course, this works for any HTML documentation, so whether you’re a Java, Python, Ruby, C++ weenie or whatever, just grab some HTML documentation and let Quicksilver index it for you. Bam! (With kudos to Zapp Brannigan, my hero.)

Andre Pang: Pushing the Limits

Tue, 2014-07-08 05:26

OK, this is both ridiculous and cool at the same time. I need to write code for Mac OS X, Windows and Linux for work, and I like to work offline at cafes since I actually tend to get more work done when I’m not on the Internet (totally amazing, I know). This presents two problems:

  1. I need a laptop that will run Windows, Mac OS X and Linux.
  2. I need to work offline when we use Subversion for our revision control system at work.

Solving problem #1 turns out to be quite easy: get a MacBook (Pro), and run Mac OS X on it. Our server runs fine on Darwin (Mac OS X’s UNIX layer), and I can always run Windows and Linux with Parallels Desktop if I need to.

For serious Windows coding and testing, though, I actually need to boot into real Windows from time to time (since the program I work on, cineSync, requires decent video card support, which Parallels doesn’t virtualise very well yet). Again, no problem: use Apple’s Boot Camp to boot into Windows XP. Ah, but our server requires a UNIX environment and won’t run under Windows! Again, no problem: just install coLinux, a not very well known but truly awesome port of the Linux kernel that runs as a process on Windows at blazing speeds (with full networking support!).

Problem #2 — working offline with Subversion — is also easily solved. Download and install svk, and bingo, you have a fully distributed Subversion repository. Hack offline, commit your changes offline, and push them back to the master repository when you’re back online. Done.

Where it starts to get stupid is when I want to:

  • check in changes locally to the SVK repository on my laptop when I’m on Mac OS X…
  • and use those changes from the Mac partition’s SVK repository while I’m booted in Windows.

Stumped, eh? Not quite! Simply:

  • purchase one copy of MacDrive 6, which lets you read Mac OS X’s HFS+ partitions from Windows XP,
  • install SVK for Windows, and
  • set the %SVKROOT% environment variable in Windows to point to my home directory on the Mac partition.

Boom! I get full access to my local SVK repository from Windows, can commit back to it, and push those changes back to our main Subversion server whenever I get my lazy cafe-loving arse back online. So now, I can code up and commit changes for both Windows and the Mac while accessing a local test server when I’m totally offline. Beautiful!

But, the thing is… I’m using svk — a distributed front-end to a non-distributed revision control system — on a MacBook Pro running Windows XP — a machine intended to run Mac OS X — while Windows is merrily accessing my Mac HFS+ partition, and oh yeah, I need to run our server in Linux, which is actually coLinux running in Windows… which is, again, running on Mac. If I said this a year ago, people would have given me a crazy look. (Then again, I suppose I’m saying it today and people still give me crazy looks.) Somehow, somewhere, I think this is somewhat toward the evil end of the scale.

Andre Pang: Parallels Desktop adds Boot Camp, native window support

Tue, 2014-07-08 05:26

Build 3036 of Parallels Desktop has been announced for all you Linux-on-Mac and Windows-on-Mac fans, and it comes with two very cool new features:

  • You can use your Windows XP Boot Camp partition directly in Parallels. No more disk-space-killing installs of Windows XP as a Parallels disk image alongside Boot Camp! This will save me a good 8GB or so of disk space, which is badly needed on a laptop. A side-effect of this is that it should speed up Parallels’s I/O performance, since it now uses a raw block device for its virtual disk access rather than simply using a large file on a partition.
  • Coherency: Shows Windows applications as if they were Mac ones. I’m guessing that Parallels can overtake Windows’s window manager and somehow displays the window as a native Aqua one. There are some pretty cool screenshots of this feature around.

There’s a ton of other cool new features as well. Delicious!

Andre Pang: Insights into AppleScript

Tue, 2014-07-08 05:26

I recently encountered a paper written by William Cook about a mysterious little programming language that even many programming languages researchers don’t know about: AppleScript. Yep, that’d be the humble, notoriously English-like Mac scripting language that’s renown to be slow and annoying more than anything else. The paper is a fascinating look at the history of AppleScript, and details many insights and innovations that were largely unknown. Here’s some things that I was pleasantly surprised about.

Cook had never used a Mac before he was employed to work on AppleScript: in fact, he had a very strong UNIX background, and had a great amount of experience with UNIX shell scripting. So, one can instantly dismiss the notion that whoever designed AppleScript had “no idea about the elegance of interoperating UNIX tools”: a remark that I’m sure many would have made about the language (myself included). Cook even remarks that Apple’s Automator tool, introduced in Mac OS 10.4 Tiger, was quite similar to UNIX pipes:

The most interesting thing about Automator is that each action has an input and an output, much like a command in a Unix pipe. The resulting model is quite intuitive and easy to use for simple automation tasks.

More on UNIX pipes, he writes that

the sed stream editor can create the customized text file, which is then piped into the mail command for delivery. This new script can be saved as a mail-merge command, which is now available for manual execution or invocation from other scripts.

He then continues with something seemingly obvious, but is nevertheless something I have never thought about UNIX scripts:

One appealing aspect of this model is its compositionality [emphasis mine]: users can create new commands that are invoked in the same way as built-in commands.”

Indeed! In a way, the ability to save executable shell scripts is the equivalent of writing a named function to denote function composition in a functional programming language: it enables that composed code to be re-used and re-executed. It’s no coincidence that the Haskell scripts used in Don Stewart’s h4sh project are semantically quite similar to their equivalent Bourne shell scripts, where Haskell’s laziness emulates the blocking nature of pipes.

More on UNIX: Cook later writes that

A second side effect of pervasive scripting is uniform access to all system data. With Unix, access to information in a machine is idiosyncratic, in the sense that one program was used to list print jobs, another to list users, another for files, and another for hardware configuration. I envisioned a way in which all these different kinds of information could be referenced uniformly… A uniform naming model allows every piece of information anywhere in the system, be it an application or the operating system, to be accessed and updated uniformly.

The uniform naming model sounds eerily familiar who had read Hans Reiser’s white paper about unified namespaces. Has the UNIX world recognised yet just how powerful a unified namespace can be? (For all the warts of the Windows registry, providing the one structure for manipulating configuration data can be a huge benefit.)

Cook was also quite aware of formal programming language theory and other advanced programming languages: his Ph.D thesis was in fact on “A Denotational Semantics of Inheritance”, and his biography includes papers on subtyping and F-bounded polymorphism. Scratch another urban myth that AppleScript was designed by someone who had no idea about programming language theory. He makes references to Self and Common LISP as design influences when talking about AppleScript’s design. However,

No formal semantics was created for the language, despite an awareness that such tools existed. One reason was that only one person on the team was familiar with these tools, so writing a formal semantics would not be an effective means of communication… Sketches of a formal semantics were developed, but the primary guidance for language design came from solving practical problems and user studies, rather than a-priori formal analysis.

(There’s some interesting notes regarding user studies later in this post.) Speaking of programming language influences,

HyperCard, originally released in 1987, was the most direct influence on AppleScript.

Ah, HyperCard… I still remember writing little programs on HyperCard stacks in high school programming camps when I was a young(er) lad. It’s undoubtedly one of the great programming environment gems of the late 80s (and was enormously accessible to kids at the same time), but that’s an entire story unto itself…

The Dylan programming language is also mentioned at one point, as part of an Apple project to create a new Macintosh development environment (named Family Farm). ICFPers will be familiar with Dylan since it’s consistently in the top places for the judge’s prize each year; if you’re not familiar with it, think of it as Common LISP with a saner syntax.

AppleScript also had a different approach to inter-appication messaging. Due to a design flaw in the classic MacOS, AppleScript had to package as much information into its inter-application data-passing as possible, because context switches between applications on early MacOS systems were very costly:

A fine-grained communication model, at the level of individual procedure or method calls between remote objects, would be far too slow… it would take several seconds to perform this script if every method call required a remote message and process switch. As a result, traditional RPC and CORBA were not appropriate… For many years I believed that COM and CORBA would beat the AppleScript communication model in the long run. However, COM and CORBA are now being overwhelmed by web services, which are loosely coupled and use large granularity objects.

Web Services, eh? Later in the paper, Cook mentions:

There may also be lessons from AppleScript for the design of web services. Both are loosely coupled and support large-granularity communication. Apple Events data descriptors are similar to XML, in that they describe arbitrary labeled tree structures without fixed semantics. AppleScript terminologies are similar to web service description language (WDSL) files. One difference is that AppleScript includes a standard query model for identifying remote objects. A similar approach could be useful for web services.

As for interesting programming language features,

AppleScript also supports objects and a simple transaction mechanism.

A transaction mechanism? Nice. When was the last time you saw a transaction mechanism built into a programming language (besides SQL)? Speaking of SQL and domain-specific languages, do you like embedded domain-specific languages, as is the vogue in the programming language research community these days? Well, AppleScript did it over a decade ago:

The AppleScript parser integrates the terminology of applications with its built-in language constructs. For example, when targeting the Microsoft Excel application, spreadsheet terms are known by the parser—nouns like cell and formula, and verbs like recalculate. The statement tell application “Excel” introduces a block in which the Excel terminology is available.

Plus, if you’ve ever toyed with the idea of a programming language that could be written with different syntaxes, AppleScript beat you to that idea as well (and actually implemented it, although see the caveat later in this note):

A dialect defines a presentation for the internal language. Dialects contain lexing and parsing tables, and printing routines. A script can be presented using any dialect—so a script written using the English dialect can be viewed in Japanese… Apple developed dialects for Japanese and French. A “professional” dialect which resembled Java was created but not released… There are numerous difficulties in parsing a programming language that resembles a natural language. For example, Japanese does not have explicit separation between words. This is not a problem for language keywords and names from the terminology, but special conventions were required to recognize user-defined identifiers. Other languages have complex conjugation and agreement rules, which are difficult to implement. Nonetheless, the internal representation of AppleScript and the terminology resources contain information to support these features. A terminology can define names as plural or masculine/feminine, and this information can be used by the custom parser in a dialect.

Jesus, support for masculine and feminine nouns in a programming language? Hell yeah, check this out:

How cool is that? Unfortunately, Apple dropped support for multiple dialects in 1998:

The experiment in designing a language that resembled natural languages (English and Japanese) was not successful. It was assume that scripts should be presented in “natural language” so that average people could read and write them. This lead to the invention of multi-token keywords and the ability to disambiguate tokens without spaces for Japanese Kanji. In the end the syntactic variations and flexibility did more to confuse programmers than help them out. The main problem is that AppleScript only appears to be a natural language on the surface. In fact is an artificial language, like any other programming language… It is very easy to read AppleScript, but quite hard to write it… When writing programs or scripts, users prefer a more conventional programming language structure. Later versions of AppleScript dropped support for dialects. In hindsight, we believe that AppleScript should have adopted the Programmerís Dialect that was developed but never shipped.

A sad end to a truly innovative language feature—even if the feature didn’t work out. I wonder how much more AppleScript would be respected by programmers if it did use a more conventional programming language syntax rather than being based on English. Cook seems to share these sentiments: he states in the closing paragraph to the paper that

Many of the current problems in AppleScript can be traced to the use of syntax based on natural language; however, the ability to create pluggable dialects may provide a solution in the future, by creating a new syntax based on more conventional programming language styles.

Indeed, it’s possible to write Perl and Python code right now to construct and send AppleEvents. Some of you will know that AppleScript is just one of the languages supported by the Open Scripting Architecture (OSA) present in Mac OS X. The story leading to this though, is rather interesting:

In February of 1992, just before the first AppleScript alpha release, Dave Winer convinced Apple management that having one scripting language would not be good for the Macintosh… Dave had created an alternative scripting language, called Frontier… when Dave complained that the impending release of AppleScript was interfering with his product, Apple decided the AppleScript should be opened up to multiple scripting languages. The AppleScript team modified the OSA APIs so that they could be implemented by multiple scripting systems, not just AppleScript… Frontier, created by Dave Winer, is a complete scripting and application development environment. It is also available as an Open Scripting component. Dave went on to participate in the design of web services and SOAP. Tcl, JavaScript, Python and Perl have also been packaged as Open Scripting components.

Well done, Dave!

As for AppleScript’s actual development, there’s an interesting reference to a SubEthaEdit/Gobby/Wiki-like tool that was used for their internal documentation:

The team made extensive use of a nearly collaborative document management/writing tool called Instant Update. It was used in a very wiki-like fashion, a living document constantly updated with the current design. Instant Update provides a shared space of multiple documents that could be viewed and edited simultaneously by any number of users. Each userís text was color-coded and time-stamped.

And also,

Mitch worked during the entire project to provide that documentation, and in the process managed to be a significant communication point for the entire team.

Interesting that their main documentation writer was the communication point for the team, no?

Finally, AppleScript went through usability testing, a practice practically unheard of for programming languages. (Perl 6’s apocalypses and exegeses are probably the closest thing that I know of to getting feedback from users, as opposed to the language designers or committee simply deciding on everything without feedback from their actual userbase!)

Following Appleís standard practice, we user-tested the language in a variety of ways. We identified novice users and asked them “what do you think this script does?” As an example, it turned out that the average user thought that after the command put x into y the variable x no longer retained its old value. The language was changed to use copy x into y instead.

Even more interesting:

We also conducted interviews and a round-table discussion about what kind of functionality users would like to see in the system.

The survey questions looked like this:

The other survey questions in the paper were even more interesting; I’ve omitted them in this article due to lack of space.

So, those were the interesting points that I picked up when I read the paper. I encourage you to read it if you’re interested in programming languages: AppleScript’s focus on pragmatics, ease of use for non-programmers, and its role in a very heavily-based GUI environment makes it a very interesting case study. Thankfully, many Mac OS X applications are now scriptable so that fluent users can automate them effectively with Automator, AppleScript, or even Perl, Python and Ruby and the UNIX shell these days.

Honestly, the more I discover about Apple’s development technologies, the more impressed I am with their technological prowess and know-how: Cocoa, Carbon, CoreFoundation, CoreVideo, QuickTime, vecLib and Accelerate, CoreAudio, CoreData, DiscRecording, SyncServices, Quartz, FSEvents, WebKit, Core Animation, IOKit… their developer frameworks are, for the most part, superbly architectured, layered, and implemented. I used to view AppleScript as a little hack that Apple brought to the table to satisfy the Mac OS X power users, but reading the paper has changed my opinion on that. I now view AppleScript in the same way as QuickTime: incredible architecture and power, with an outside interface that’s draconian and slightly evil because it’s been around and largely unchanged for 15 freaking years.

Andre Pang: On D&D and C++

Tue, 2014-07-08 05:26

Quoteth Manuel Chakravarty:

Dungeons and Dragons is the C++ of role-playing games.

Andre Pang: On Civil Debate

Tue, 2014-07-08 05:26

Compare the response given by David Heinemeier Hansson to Alex Payne in the recent Rails and scaling controversy, to Ingo Molnar’s response to Con Kolivas regarding the new Modular Schedule Core in Linux. Which community would you rather be part of based on this little sample?

(Somewhat ironic since it was Hansson himself that said “It’s no[t] the event that matters, but the reaction to it”, as well as being an evangelist for the It Just Doesn’t Matter principle.)

Andre Pang: Objective-C Internals

Tue, 2014-07-08 05:26

Just before I left Sydney, I gave one last talk at the revived Sydney Cocoaheads user group about Objective-C Internals. It’s similar to the presentation that I gave at fp-syd a few months ago about Objective-C and Mac OS X programming, but was tailored for a Mac audience rather than a functional programming audience. As a result, the Cocoaheads talk has a lot more detail on the object model, memory layout, and how message-sending works, and less info on higher-order messaging and language features (e.g. I didn’t talk about categories at all.)

If you’re a Mac coder, hopefully you’ll find something new in there. As always, drop me an email if you have any questions!

P.S. For all the voyeurs out there, the San Francisco move & Pixar are both going great! More news on that soon, too.

Andre Pang: Objective-C 2.0 Accessors & Memory Management

Tue, 2014-07-08 05:26

Quite often, you may have simple setter methods that need to do a just a tiny bit of work before or after setting an instance variable. For example, maybe you need to redraw something after setting the property of an object. So, instead of writing this:

[self setBackgroundColor:[NSColor blueColor]]; [view setBackgroundColor:[NSColor blueColor]];

You’d probably want to move the relevant code to your -setBackgroundColor: accessor instead:

- (void)setBackgroundColor:(NSColor*)color { // Assuming that _backgroundColor is the ivar you want to set if(_backgroundColor != color) { [_backgroundColor release]; _backgroundColor = [color retain]; // Update the view's background color to reflect the change [view setBackgroundColor:_backgroundColor]; } }

Then you can simply call -setBackgroundColor: and expect it all to work nicely:

// -setBackgroundColor: updates the view's background color // automatically now [self setBackgroundColor:[NSColor blueColor]];

(You could use Key-Value Observing to do this, but I generally avoid KVO for simple intra-class property dependencies like this. I don’t think the overhead of maintaining all the KVC dependencies and KVO-related methods is worth the cost.)

Of course, the above method requires that you write all that stupid boilerplate memory management code in the accessor. Instead of doing that, I tend to declare a private _backgroundColor property in the class, @synthesize a method for the private property, and then use the private property’s generated accessors instead:

@interface MyClass () // Declare a _private_ _backgroundColor property (thus the underscore // in front, and why it's declared in a class continuation rather than // in the public header) @property (copy, setter=_setBackgroundColor:) NSColor* _backgroundColor; @end // @implementation MyClass @synthesize _backgroundColor; - (NSColor*)backgroundColor { return [self _backgroundColor]; } - (void)setBackgroundColor:(NSColor*)color { // Use the private property to set the background colour, so it // handles the memory management bollocks [self _setBackgroundColor:color]; [view setBackgroundColor:[self _backgroundColor]]; } ... @end

With that technique, it’s possible to completely directly setting ivars, and thus avoid -retain and -release altogether. (You’ll still need to use -autorelease at various times, of course, but that’s reasonably rare.) We have some source code files that are well over 2000 lines of code without a single explicit [_ivar retain]; or [_ivar release]; call thanks to this technique. (Yeah, 2000 lines is also large and the class needs refactoring, but that’s another story.)

Of course, you could just use garbage collection which avoids 99% of the need for this bollocks:

- (void)setBackgroundColor:(NSColor*)color { // Yay GC! self->_backgroundColor = color; [view setBackgroundColor:self->_backgroundColor]; }

But plenty of us don’t have that luxury yet. (iPhone, ahem.)

Andre Pang: Objective-C Accessors

Tue, 2014-07-08 05:26

I like Objective-C. It’s a nice language. However, having to write accessor methods all day is boring, error-prone, and a pain in the ass:

- (NSFoo*) foo{ return foo;}- (void) setFoo:(NSFoo* newFoo){ [foo autorelease]; foo = [newFoo retain];}

I mean, c’mon. This is Objective-C we’re talking about, not Java or C++. However, until Objective-C 2.0’s property support hits the streets (which, unfortunately, will only be supported on Mac OS X 10.5 and later as far as I know), you really have to write these dumb-ass accessors to, well, access properties in your objects correctly. You don’t need to write accessors thanks to the magic of Cocoa’s Key-Value Coding, but it just feels wrong to access instance variables using strings as keys. I mean, ugh—one typo in the string and you’ve got yourself a problem. Death to dynamic typing when it’s totally unnecessary.

As such, I got totally fed up with this and wrote a little script to generate accessor methods. I’m normally not a fan of code generation, but in this case, the code generation’s actually designed to be one-shot, and it doesn’t alter the ever-picky build process. It’s meant to be used in Xcode, although you can run it via the commandline too if you like.

Given the following input:

int integerThing;NSString* _stringThing;IBOutlet NSWindow* window;

It will spit out the following:

#pragma mark Accessors- (int) integerThing;- (void) setIntegerThing:(int)anIntegerThing;- (NSString*) stringThing;- (void) setStringThing:(NSString*)aStringThing;- (NSWindow*) window;- (void) setWindow:(NSWindow*)aWindow;%%%{PBXSelection}%%%#pragma mark Accessors- (int) integerThing{ return integerThing;}- (void) setIntegerThing:(int)anIntegerThing{ integerThing = anIntegerThing;}- (NSString*) stringThing{ return _stringThing;}- (void) setStringThing:(NSString*)aStringThing{ [_stringThing autorelease]; _stringThing = [aStringThing copy];}- (NSWindow*) window{ return window;}- (void) setWindow:(NSWindow*)aWindow{ [window autorelease]; window = [aWindow retain];}

There’s a couple of dandy features in the script that I find useful, all of which are demonstrated in the above output:

  1. It will detect whether your instance variables start with a vowel, and write out anInteger instead of aInteger as the parameter names for the methods.
  2. It will copy rather than retain value classes such as NSStrings and NSNumbers, as God intended.
  3. For all you gumbies who prefix your instance variables with a leading underscore, it will correctly recognise that and not prefix your accessor methods with an underscore.1
  4. IBOutlet and a few other type qualifiers (__weak, __strong, volatile etc) are ignored correctly.
  5. It will emit Xcode-specific #pragma mark places to make the method navigator control a little more useful.
  6. It will emit Xcode-specific %%%{PBXSelection}%%% markers so that the accessor methods meant to go into your .m implementation file are automatically selected, ready for a cut-and-paste.

Download the objc-make-accessors script and throw it into your “~/Library/Application Support/Apple/Developer Tools/Scripts” folder. If you don’t have one yet:

mkdir -p ~/Library/"Application Support"/Apple/Developer Tools/Scripts/10-Scriptsln -sf "/Library/Application Support/Apple/Developer Tools/Scripts/10-User Scripts/" ~/Library/"Application Support"/Apple/Developer Tools/Scripts/10-Scripts/cp ~/Desktop/objc-make-accessors ~/Library/"Application Support"/Apple/Developer Tools/Scripts/10-Scripts/

Done. You should now have a Scripts menu in Xcode with a new menu item named “IVars to Accessor Methods”. Have fun.

1 Note that older versions of the Cocoa Coding Guidelines specified that prefixing instance variables with underscores is an Apple-only convention and you should not do this in your own classes. Now the guidelines just don’t mention anything about this issue, but I still dislike it because putting underscores every time you access an instance variable really lowers code readability.

Andre Pang: Neverwinter Nights 2 Is Here

Tue, 2014-07-08 05:26

Well, it seems that Neverwinter Nights 2, Obsidian1’s next kick-ass roll-playing game, is out in the USA. Unfortunately, it’s been delayed in Australia until November the 16th. Whaaaa? That’s… like… next year! Muaahaha, thankfully I’ve managed to wrangle some contacts and download the thing from Direct2Drive, so I’ve been gleefully playing it for the past few nights. Well, OK, make that the past few days, nights, and early mornings…

First impressions are good, although the game engine isn’t particularly medal-worthy: Obsidian could use some better game engines programmers, that’s for sure. It’s not in the same league as Oblivion, for instance. The user interface also isn’t quite up to NWN1 standards. However, the spell effects do look very pretty, and more importantly, the story looks quite promising, and possesses the same moral and ethical ambiguity that is the hallmark of Obsidian games. None of this bozo so-obvious black-and-white good-vs-evil crap. (Mind you, I’m playing a slightly evil character at the moment — slaughtering the Neverwinter City Watch might be somewhat evil… but it is so much fun. Besides, the Watch is weak and not doing its job, so I don’t see anything wrong with the Thieves’ Guild controlling the city streets since they actually have the resources to maintain peace and order better than the Watch. Just ensure the local shop keepers pay their taxes to the Guild and everyone’s happy… )

It also looks like an even more hackable game than the original NWN, although I’m unhappy with the toolset using the same dock-o-rama type of user interface that Visual Studio is famous for. Dockable windows are OK, but I still think it’s far inferior to using multiple windows and a decent window management tool such as Exposé. Still, it took me about 30 minutes to write some small chea… uhh, scripts, to help with some in-game things.

So far I’ve probably pumped about 20 to 30 hours into the game, and I think I’m about 3/4 of the way through Chapter One, with there being three chapters in total. If I don’t reply to any emails for the week or two, uhhh, I guess you know what I’ll be doing!

1 Obsidian are makers of the best computer role-playing games in existence, end of story. (None of this World of Warcraft or Final Fantasy VII crap, thank you very much.) If you disagree with me on this, that’s OK, I’m not really into Pokemon anyway.

Andre Pang: Welcome!

Tue, 2014-07-08 05:26

Welcome to the new-look, redone from scratch. I’m now using RapidWeaver to do the web site rather than my 5-year-old installation of Movable Type; thank you MT, you served me well for that time! All my old blog entries have been imported across, although the URLs for the entries have all changed, sorry.

Apart from the obvious look’n’feel changes to the blog, I’ve finally put all my mixes online in the Music section, and added a small section on the code that I’ve released. (It’s not much code, so don’t be too disappointed when you visit there — but there’s lots more coming in the future!) So, have a look around if you’re bored, kill some time, and have the appropriate amount of fun.