Objective C in general:	Programming ObjectiveC
Intro to Cocoa:	Learning Cocoa with ObjectiveC
Getting your feet wet on the iPhone:	iPhone Open Application Development

And of course, when it comes to web pages, there’s the invaluable CocoaDev Wiki.

That’s rather annoying. Thankfully, that’s a solved problem. Many CPUs prefer non-branching code, too, and there’s a long history of creating non-branching version of code that technically should branch. The trick here is “creative” use of math and/or bit-logic functions. As a simple example, let’s say I have a threshold shader - values below the minimum value should have a brightness of 0, and values higher than the max value should have a brightness of 1.

step() function to the rescue: step(a,b) returns 0 if a < b, 1 if a > b. So to cut off the low range, we have

Very similarly, to check against the max value, we force brightness to be greater than 1 for pixels above the maximum threshold and then clamp to 1.0

That’s all there is to it. And in case you actually came for the filter code, here it is - with input sanitizing, nicer input values (midpoint/range), grayscale conversion, all the fun stuff.

It only seems that way, though. A quick look behind the scenes reveals that all that shell does is:

• start the ruby environment
• ‘require’ all included ruby scripts
• and runs NSApplicationMain

The first two, I can obviously do on my own. The third provides the main loop for all NSApplications. But you can’t simply call it from Ruby - it requires you to have an Info.plist. Again, too much baggage for quick & dirty prototypes. The goal is to have one ruby file to play around in.

That one is a bit trickier to find out, but after digging around in Apple’s documentation, it turns out there is a decent explanation in the overview for NSApplication

For future reference, this is what it does:

Now we’re getting somewhere. This can actually be completely duplicated in Ruby. Since I might want to quit my application, I’ve thrown in a window that shuts down the application when closed.

Or just download standalone.rb

To actually time the startup process, you can cause Visual Studio to write a log file - just specify /Log <logfile> at the command line. I’ve written a little Ruby script that actually does that for you, and measures the time taken for the startup.

When I started doing that, I just kept looking at the generated log file (which conveniently contains timing info) and considered the startup done once no new info showed up in the log file. That last line is the trigger point in the script. (Why so complicated? Because VS.NET still does stuff while it pretends it has started. Doesn’t help me, since it’s still not doing what I want it to do during that time)

Just running VS.NET “out of the box”, it takes on average 11.6 seconds to start up. (I’ve always tried it 10 times in a row and averaged, in case Windows file caching throws me a curveball).

Just by eyeballing, the biggest time eater seems to be the “Visual C++ Developer Center” start page. Let’s turn that off. (Tools/Options/Environment/General/Startup/Show empty Environment). And while I’m at it, let’s also turn off the download off content. Since I have VS2005, there has been about one interesting article on that page, so I’ll survive.

The surprising result: Visual Studio does not load the “Common IDE package” anymore - whatever that is. Startup time is now down to 2.4 seconds.

As a next step, I disable all the add-ins I don’t need. Some, you can just turn off via Tools/Add-In Manager(AMD Code Analyst). Others, you actually need to uninstall. (I’m looking at you, Solution Build Environment). That actually cut down the startup time to 2.0 seconds.

Next up - let’s get rid of the splash screen. Just start devenv with the /nosplash argument. It turns out that just feels faster, since you don’t have to stare at the startup screen. The startup time is still pretty much the same.

From here on out, we’re firmly in the realm of myth. I tested a few other suggestions, but none of them had a measurable effect on startup time. If you still want to try them, here they are:

• Turning off animated windows: Tools/Options/Environment/General/Animate Environment. Might help later in the project, when you have many windows open.

• Another frequently repeated tip is turning off dynamic help. That option is not available in VS2005 any more. However, the other tunings above seem to have accelerated the startup of the external help viewer a bit. I have no idea why, but I’ll certainly take the speedup.

• Cleaning MRU lists. Not really helpful. It might bring an extremely slight improvement, but variations between individual VS runs are way bigger than that improvement. That particular myth seems to be a holdover from a VS2003 bug with the MRU

After running it, v is set to (0,0,0) - can you spot why?

In case you couldn’t, here’s what happens. C++ encounters (0,3,0) and evaluates to 0 - because comma-separated expressions evaluate left-to-right and return the rightmost expression. That’s strike one right there - the comma operator is a completely useless leftover from the days of C and gets silently applied. I’ve never seen a case where the comma operator actually was the intent of the programmer and useful in any way except to obfuscate the code.

Next strike against C++ is that I’m trying to initialize a vector here - which would have required curly braces, not parentheses. But even if I had gotten that right, there’s a good chance it fails - if Vec3 has any constructors (even empty ones), this assignment would be a syntax error.

But back to the problem at hand. The expression now boiled down to

Now, clearly my vector class doesn’t allow alignment of a scalar. So what the heck is going on? That’s right - there is a convenience constructor that takes a single scalar and assigns it to all three components of the vector. Yes, it should have been marked as explicit. Which is yet another example of C++ defaulting to the more dangerous choice. (And really, in a code base maintained by more than one person, this will always be a problem)

Why, thank you, C++. I’ll never understand how anybody could call this language type-safe. In this simple statement, it has

• implicitly converted a list of integers to an integer

• promoted that (silently, of course) to a float

• created a vector from that, again silently

At last count that’s four different types of data that have been used interchangeably. Yes, as an experienced C++ developer you find those gotchas quickly - but I’m really getting tired of having to suffer just because of an ill-conceived language. (Yes, I know why C++ does what it does here, what the design reasons were, etc. I read the ARM. It’s still a crappy result)

First challenge - just getting it to build on OSX. It seems like a trivial task, especially since people have already built it for OSX in general, but it unfortunately isn’t. There are a few pitfalls to avoid. The main Mapnik install documentation helps a lot, so I recommend reading that first. Especially the prerequisites part - you really need all the packages there. The port system helps a lot with this, but here are the issues I encountered:

• the build script requires libproj

• Before installing boost, you must install jam - there seems to be a dependency missing in the port file.

• When installing boost, make sure you install it with python support, specifically support for Python 2.5

Now that you’ve installed all the prerequisites, it’s time to fix up the buildscript

• libtiff doesn’t live where it’s expected to live. Use the patch.

  Or

and fix it by hand.

• Python site libraries on OSX are not installed in site-packages of the original python directory. They go to a completely separate path. Either figure it out yourself:

or use the patch.

• There’s a syntax error in calling unicode functions - here’s the patch.

• On machines that had a hand-install of python, mapnik will build but not run. To make sure that doesn’t hit you, make sure you never had a home-built version of python on your machine or remove its remnants. If there are python libraries in

/Library/Frameworks/Python.framework

, remove that folder.

Once all that is done, you just need to make & install:

history|awk '{a[$2]++} END{for(i in a){printf “%5d\t%s \n”,a[i],i}}’|sort -rn|head

55  sudo 
45  ls 
42  git 
32  cd 
25  gem 
23  vi 
21  ruby 
15  man 
13  echo 
 7  /bin/rm 

Heh. Turns out most of my work on the command line involves making changes as the actual super user. Further digging reveals that most of that are calls to port and gem. (And yes, I call gem a lot as local user to. Not everything requires privilege escalation).

The rest just proves that I’m a ruby/vi person, not python/emacs. (Although, honestly, I’m a textmate user. Just forgot to install the mate script…)

The power they offer you as a developer is amazing, especially if you use them with a patch management solution like quilt. The ability to juggle branches and patches with almost zero cost is extremely empowering. (At the same time, it’s also dangerous. It’s a power tool, so don’t use it if you’re not feeling your current version control is limiting you).

Obviously, I like using the most powerful tools for my professional work, too. There are two limiting factors here. One, everybody is using Perforce. Two, we’re running under Windows.

Obstacle #1 can be overcome by running a tool like Tailor which allows you to migrate changes between version control tools. #2 is a much bigger hurdle. Let’s take a look, shall we:

The three main options for Windows are git,Mercurial and darcs. All three of them have Windows versions. With a big but:

• GIT While it does have Windows executables, it relies a lot on shell scripts. Which means it needs to run in a cygwin environment, which is sort of the worst of both the Unix and the Windows worlds. In other words, it’s a pain to actually run it.

• Darcs

  Seems to run fine under Windows, but sometimes relies on external programs. (WGet/Curl being one). And there’s no list of external dependencies. I’m certainly not basing my daily work on a tool that suddenly might stop to work, just because I’m missing a dependency

• Mercurial

  Seems fine. It has a Windows executable and works out of the box.

So it seems like Mercurial should be the tool of choice. Except, we need Tailor to run. Now, it does support Mercurial out of the box, but it expects the Python version of Mercurial - not a precompiled executable.

Sounds easy, right? Just get python, get Mercurial source, and install it. Except…

Mercurial wants to compile some native modules, and they need to be compiled using the same compiler that the Python interpreter was compiled with. And wouldn’t you know it, in the year 2008 Python is still not compiled with VS.NET 2005 - we’re stuck with VS2003. (What the heck?)

So basically, I’m stuck. Advice so far: If you’re on Windows and don’t need Tailor, get Mercurial - it’s the least amount of hassle. If you need to interop with Perforce or another VCS, you’re completely out of luck.

However, there is an officially approved way to set a thread name:

Who is the genius responsible for that idea???

After quite a bit of reading up, I finally got the idea that all this is is a gradient descent - but my math is rusty enough that I really like to see a visual explanation of it, too. (Yes, I get the math. I just want the pictures, by now). So I decide to create them myself - if something’s missing on the web, you go and add it.

Except I want to do it programatically, since my art skills are close to non-existent. And my mind is focused on Ruby, so that’s the language I want to do it with. Turns out that searching for ‘]ruby osx opengl](http://www.google.com/search?hl=en&client=safari&rls=en-us&q=ruby+osx+opengl&btnG=Search)’ is not that helpful. A few searches later, I finally figure out that the proper serch term would have been ‘rubycocoa opengl‘ instead. Which tells me right in the first hit that Apple is actually kind enough to ships a sample application with RubyCocoa.

So to get started with Ruby, OSX, and OpenGL, just take a look at /Developer/Examples/Ruby/RubyCocoa/CocoaGL - and you’re set to go. Now I’m off to do some heightfield rendering in OpenGL - unless I get sidetracked again.