.::output >> /dev/null::.

Over these past few months, I have been working on a long-term class project using OS X technologies in both Objective-C and Javascript. Overall, the experience was pretty good (except for the Javascript part) -- and I suspect much easier compared to having to use Java. Using Java would require us to hunt down various libraries and then filter through them since there are probably 10++ different libraries for each thing that we need to do. So using OS X was a good choice.

However, there are a few tools that I wished I had known earlier....

GHUnit

Unit testing using Cocoa is pretty complicated. In fact, it's unnecessarily more complicated than Java, Ruby or Smalltalk. It's only less complicated than unit testing C++ (which doesn't say much)! There are two things that particularly irk me:

• Not seeing green/red! - You have to actually read the text in the build log to see which of your tests pass and fail. This is completely ridiculous - it's so easy to miss a failing test case because of this. Anyone who has used the Xunit testing framework family is accustomed to seeing green for passing tests and red for failing tests.
  
  
  A Failed Test Logged in the Xcode Build Results Window
  
  
• Not being able to debug your unit tests - You have to perform some boilerplate steps on your own. Such steps should be automated for you!

Fortunately, GHUNit comes along. And at least solves those two problems. It has become my choice for unit testing in Cocoa and all my future projects will use it. It's released under a very liberal open source license so using it in your own project shouldn't be a problem. Apple and the Xcode team should integrate this directly into Xcode.

F-Script

The cocoa libraries are nice. But sometimes the documentation can be a bit confusing. So, the best way to find out what a method or class does it to write some code for it and try it out. But honestly, would you like writing a small program each time to try a method or class out?

That's when you need F-Script which allows you to call run Objective-C like you would run a scripting language. Need to find out how that NSString method behaves? Just type in into the F-Script REPL workspace. You can even play around with Core Image easily in the F-Script workspace!

But wait! F-Script has even more to offer. Using F-Script Anywhere allows you to inject the F-Script environment into any Cocoa application. That way you can quickly figure out and play around with other people's application!

The only thing you need to do is spend about 20 minutes learning the F-Script syntax which is very similar to Smalltalk's - so it only took me about 5 minutes.

Clang Static Analyzer

One area where Java really shines is the abundance of high-quality tools for static analysis. Using these tools allow you to avoid a lot of silly mistakes before you even compile or run your Java code.

Previously, Objective-C was definitely lacking in this area. However, the Clang Static Analyzer hopes to change that. In fact, if you are using the latest version of Xcode under Snow Leopard, it should be integrated already. Here's the static analyzer in action:

For our particular project, we needed to use OS X Leopard so followed these steps to get the static analyzer to work. Even though it took a few more steps, the extra trouble is worth it since it catches a lot of garbage collection issues that we might have missed otherwise.

The Clang Static Analyzer is based on the LLVM compiler infrastructure developed here the University of Illinois at Urbana-Champaign.

BWToolkit

Interface Builder is awesome. It definitely beats any other interface builder that I have tried. However, it can be too basic at times. It works very well, if you are doing a simple UI. But it lacks the palettes for some of the more advanced (but pretty commonplace) UI that you see in Mail.app, iCal.app, etc.

That's when BWToolkit comes in. It offers a plethora of different palettes which makes designing your UI extremely easy. And you can use all of them using drag-and-drop from Interface Builder.

It's released under the liberal BSD license so you don't need to worry about using it for your projects. GHUnit itself uses it and that's actually how I discovered this wonderful toolkit.

---

Overall, OS X has a lot to offer in both libraries and tools. And when it falls short, some other developer out there is usually passionate enough to create and share their tools with you. It just takes too long sometimes to find those tools. So hopefully, this list will be useful to some other aspiring OS X developer.

I have always been fascinated by application virtual machines. And I have been trying to find a simple but well-documented one to work on for fun. There is a proliferation of Javascript VMs out there but they are pretty big (V8 is the latest kid on the block and it's about 100 000 lines of C++, not my favorite language) and aren't as well documented.

There are some smaller ones like tinyrb and tinypy but the goal of such projects aren't really clear. I am not sure how much of Ruby/Python they are trying to support. They are great for hacking on if you have some experience with VMs already and can contribute to the design/implementation. But otherwise, it can be pretty hard to comprehend what is going on.

Both tinyrb and tinypy did mention that they were trying to emulate the Lua VM. So I decided to check it out. The Lua VM (like the Parrot VM) is a register-based VM, which is pretty unusual since most VMs are stack-based. Its use of registers instead of a stack makes it more fascinating to study.

And I like what I have seen so far. There is good documentation on multiple levels: the language itself, the architecture of the VM and plenty of examples. Also, the code is in C which is less messy than C++. The Makefile is simple and isn't using any cryptic tricks. And Lua itself seems like a simple language to learn.

So my plan is to dive into the source for Lua and then see what can be done to improve tinyrb. But first, I need to set up an environment to develop in.

I could certainly continue to use vim/TextMate, but I have been using Xcode more because I am doing some iPhone development and have gotten use to some of its features. And I like its built-in debugger which saves me from having to interact with gdb directly for the common tasks. In fact, I am not sure if there are better C/C++ IDEs for OS X. The Eclipse CDT project is the closest that I can think of but I haven't used it much.

So here are my steps for doing this: from getting the source into Xcode and also starting a debugging session. I am using the All-in-one look for Xcode so your UI might look different.

Grab the source for Lua-5.1.4 from http://www.lua.org/ftp/lua-5.1.4.tar.gz. Unarchive it. For this article, I will be unarchiving it in ~/Xcode.

Fire up Xcode and create a new External Build System project. I called my project Lua. You can put the project wherever you want. It doesn't need to be in the same directory where you unarchived the Lua source code since we will be referencing the source files anyway.

Right-click on the project and add the entire directory where you unarchived the Lua source code. In my case it would be ~/Xcode/lua-5.1.4.

This is what it looks like after adding all the files.

Next, we need to edit two of the Makefiles. First, we need to edit the top level Makefile in ~/Xcode/lua-5.1.4. Change line 8 to PLAT= macosx since we are targeting the OS X platform. Then, we need to make changes to the Makefile in ~/Xcode/lua-5.1.4/src. Change line 17 to MYCFLAGS+= (we want the + symbol). Change line 108 to $(MAKE) all MYCFLAGS+=-DLUA_USE_LINUX MYLIBS="-lreadline" (again, we want the + symbol). In fact, by default, it should have the + symbol so that we can easily accumulate our own settings. I suspect that this is a careless omission in the Makefile for Lua.

We need to make some changes to the Target configuration for our Project. So navigate to the Lua target in your Groups & Files (it's the left navigation pane). And double-click the Lua target. Then edit it so that it resembles the image above. Notice the line that says "Settings show Debug" near the top of the window; we are changing the settings for Debug (and not Release).

You need to change the directory to the location where you unarchived the Lua source so that it can find the top-level Makefile.

Then you need to add a new build setting, MYCFLAGS so that we can pass the -g flag (for debug) to the compiler. Without this flag, we cannot debug our program effectively with the debugger (it doesn't have all the necessary debugging information).

Now we can build our project by going to Build > Build. And notice that we are building for the Debug configuration i.e. on the menu item at the top it says 10.5 | Debug | i386. The settings that we made for our Lua target are reflected in the output of the build e.g. gcc -O2 -Wall -g .... (the -g flag that we specified in the settings).

Now that the project builds, we can proceed to debug it (or rather we just want to step through its execution in the debugger to find out how it works). The image above shows how we would run that executable (notice that we are passing some arguments to it). We want mimic this and run the program in the debugger.

So we create a new Custom Executable. We call it Lua.

In the dialog that pops-up, remember to specify the location of the lua executable (you will only have it after you have built the project).

Before we can debug the lua executable, there is one more setting that we have to perform: change the way debugging symbols are loaded. So, open up the preferences for Xcode, and switch to the debugging tab. Ensure that the "Load symbols lazily" is unchecked.

Now we need to set a breakpoint. Notice in the image above that I have set one on line 378 in the lua.c (Xcode/lua-5.1.4/src/lua.c) file. After that we can invoke the debugger from the Build > Build and Debug menu.

And finally we have our debugger in action.

The steps above are applicable for any other external project that you need to work on (sans the modifications to the Makefiles since that is Lua-specific).

The end of LLVM/WebKit VW integration and layout improvements.:

"Over the last 18 months or so I've put a lot of work into enhancing VisualWorks with WebKit integration, GCCXML, and later LLVM integration, as well as improving the GUI layout system. I've stopped development on these projects, primarily because there seems to be no external interest in these projects."

I am really sad that Antony Blakey is going to stop work on the GUI layout improvements for VisualWorks. His work actually made the VisualWorks UI pleasant and usable. Here's a screenshot to illustrate what I mean.

I am glad that he has pushed his GUI layout work onto the Cincom public repository so we could actually look at it and modify them as necessary. A cursory glance reviews that all of the code is written in Smalltalk without the need for calling C code. So there is the possibility that I can actually decipher the code and make changes if necessary. I am not an expert on VisualWorks so this might still prove to be rather challenging.

On the other hand, while I am definitely impressed by his work on LLVM/WebKit integration, I am not sure if I have the right level of knowledge to hop on board and contribute. I definitely would like to and perhaps after a year of using VisualWorks I would be able to. But right now, I wouldn't be of much help. Moreover, if I read his blog entries on these subjects correctly, the LLVM/WebKit integration involves diving into the VM source code and actually changing the internals of the system. I think it even requires a custom version of the VM. Also, he hasn't pushed all of his work on LLVM/WebKit integration onto the store (he has an interesting article on why the Cincom public store is not really suitable for collaborative development)

Most people might argue that the VisualWorks UI is actually much better than the one for Squeak with all its colorful windows and non-standard layout. But here's a quote that exemplifies what UI design (taken literally as a quote like I would from Shakespeare with none of all the mumbo jumbo of religion):

"So, because you are lukewarm – neither hot nor cold – I am about to spit you out of my mouth. – Revelation 3:16"

So the Squeak UI isn't all that bad. It's different enough that your mind just accepts it as being different. On the other hand, the standard VisualWorks UI for OS X tries to blend in but does it in a way that is just lukewarm... This isn't to say that the Squeak UI or the VisualWorks UI can't be improved on....

In short, I am really impressed by Antony Blakey's efforts. He definitely has some radical ideas for improving (modernizing?) Smalltalk, hence, the title of his blog: "The creation of a new order of things". I will definitely continue to monitor his future work on Smalltalk.

Programming Quotes, Sayings about Programmers, Software Developers, Application Development:

"The only way for errors to occur in a program is by being put there by the author.  No other mechanisms are known.  Programs can't acquire bugs by sitting around with other buggy programs.  ~Harlan Mills"

The last time I updated to OS X 10.5.2, some developer inserted this extremely annoying bug into Mail-- dragging any file onto its dock icon would crash it! This is particularly annoying because I already had it wired onto my reflexes to perform a drag and drop every time I want to send an attachment to someone.

Eventually I was able to find the solution: change Mail's composing preference to RTF instead of plain text. Well that isn't really a solution since that means that I will have to compose all my e-mails as RTF which is something that I don't agree on. E-mail messages should be plain text whenever possible! RTF might be better than HTML but it is still egregious compared to plain text.

Anyway, I found an alternative solution. Instead of dragging the file to the dock icon, create a new empty message first and then drag the file onto the body of the message. This involves the extra step of creating a new empty message but at least it does not crash Mail nor force me to use RTF. Being able to drag the attachment into the mail message body without crashing it (even with the plain text setting) just illustrates that this is a bug that could have been avoided/fixed since there is nothing inherently wrong underneath with Mail. Instead it's probably just the drag and drop component that needs some reworking.

Yesterday I upgraded to OS X 10.5.3 because I wanted to install the latest iPhone Beta SDK. The README specifically said that OS X 10.5.3 is required.

And I was rather disappointed (but not really surprised) to discover that this Mail bug has not been fixed yet. Fortunately I could use the alternative solution which will suffice until this bug gets fixed (if ever). I'd rather have less features (for instance remove the useless Stationary/Template feature from Mail) than to have a program crashed on the most rudimentary of tasks.

I've been reading some mentions/reviews of Evernote on various sites so I decided to try it out for myself. Right now, the latest beta version is by-invitation only. I tried my luck at their invitation-only beta registration and was lucky enough to get an invite the next day. Since then I have sent out 5 (of the 10 invites) to my friends.

The coolest feature of Evernote is its ability to recognize text within images (see this demo video). The ability to recognize text in images is not something new but this is the first time I have seen it offered in a consumer application. Because of this, I finally found a good use for the built-in camera of my iPhone.

Text recognition is not built-in to the application itself. Instead anything that you store in Evernote is synchronized with the Evernote's servers (this allows you access your notes from the web). The text detection/processing is done at the servers and the metadata is sent back to your application. That means that unless you sync with the servers, you can't actually get text recognition. I think this is a good idea since it lets Evernote change its recognition algorithm without bothering the user with some software update.

So how good is the text recognition? I decided to do some experiments and come up with the following observations. These are merely observations so they are not rigorously tested. Also, expect the recognition capabilities to increase over time.

It recognizes some non-standard letters like Intel's old logo on this mouse pad.

It does not recognize vertical text well.

In fact, for vertical text, its recognition seems to be pretty off; recognizing things that are not there.

It probably only recognizes words in the English dictionary since it can't recognize "DTrace".

It recognizes most words but might have some trouble pinpointing their exact location.

I don't think it recognizes symbols well; it's probably optimized for numbers and letters.

It seems to have trouble with multi-colored words like the Google logo.

So for better results, the text should be horizontally written, unicolored and contain only alphabets and numbers. But it works pretty well for most cases. It certainly beats having to enter information by hand.

So, will I continue using Evernote after its beta period? I am expecting that it will require a paid subscription for the ability to sync and recognize text within images but if the price is reasonable, I might continue using it. Moreover, if they decide to create a native iPhone app (an offer it for free for paid subscribers), the likelihood of using it is even higher for me. After all, there isn't a convenient way to sync notes between my iPhone and my computer. I'll definitely keep Yojimbo around though since it handles PDF and has some nice predefined containers for storing image, serial numbers, etc.

As I am writing this, I am also partly listening to the Apple March 6 Event where the iPhone SDK was first introduced. And halfway through, I cannot help but notice that Scott Forstall was practically emulating Steve Jobs. He even used phrases like "... a screamer...", "... we made it even better...", "... the iPhone is the most advanced... ", "... years ahead of any other...". He is definitely a smart guy but I think he is emulating Steve too much. It would have been nice to see his own personality. On the other hand, this also means that I probably have watched too much of Steve Jobs to know how he talks....

So, I downloaded the free version of the iPhone SDK. It comes in at a whopping 2.1 GB so it took about 20 minutes to download.

After extracting it, the README has this to say:

1. It requires about 5.3 GB for installation.
2. It requires OS X 10.5.2 on intel machines (some claim that it can work on powerpc as well).

There is the option to keep Xcode 3.0 and Xcode 3.1 Beta that comes with the iPhone SDK on the same machine. I did not choose this option so it replaced my original developers tools (meaning that I did not need to sacrifice extra disk space at the expense of a possibly buggy beta version Xcode 3.1).

I tried some of the sample apps from the iPhone developer site (it uses a generic URL of http://developer.apple.com/iphone/samples/index.action which checks to see if you are authenticated).

Here are the ones that I tried:

• Kalimba - Supposed to be a replica of an African thumb piano. We should be able to strike each bar and have a musical note sound. It failed miserably on the iPhone simulator -- sound will not play and the piano refused to rotate to landscape mode. See this thread. Here's a picture to show what I mean:


This is one of the examples for the iPhone SDK. Unfortunately, it does not seem to work properly on the simulator – sound doesn't work and it refuses to rotate into landscape mode.

• Jigsaw - Just a simple jigsaw puzzle. Works fine.


• TheElements - Shows the periodic table with the possibility to view each element's page on wikipedia. When I clicked on the link to wikipedia, the simulator crashed gloriously -- no warnings, no output to console. It just crashed. After some playing around, I discovered that it crashes when you run it immediately after it opens up in the emulator. Instead, if you go to the home screen and then activate TheElements application, then opening a link would work!


• GLGravity - Draws the canonical OpenGL teapot and allows you to rotate it by rotating and tilting your iPhone. This refused to run on the simulator -- claiming that it needs to run on an iPhone.

I have to agree that the iPhone SDK has a lot to offer. If you don't believe me, just watch the video. The demo comes on at about 30 minutes through. It's akin to writing for a mini version of OS X with the addition of an impressive user interface, multi-touch control and internal accelerometers. Games will definitely benefit from this. So it should be easy for most developers to get started once they familiarize themselves with the new human interface guidelines.

Spore on the iPhone. It uses the accelerometer on the iPhone for controls.

However, as impressive as the SDK is, it also has some shortcomings which can't be ignored. Here's why (some of these might change when iPhone 2.0 debuts but I doubt it):

1. No garbage collection.
   Creating an iPhone Application:

   Note: iPhone OS does not support memory management using the garbage collection feature that is in Mac OS X v10.5 and later.

   Maybe most Objective-C developers love doing manual reference counting but this seems like something that should be addressed. After all, Google's Android platform supports this. Moreover, Objective-C 2.0 already supports it so garbage collection could have been enabled from the beginning.
   
   Some might argue that garbage collection adds extra performance overhead. But consider what happens when your app starts leaking memory all over the place. And with all the rich history that garbage collection has, it's really amazing that companies don't really start to take it seriously.
   
   In fact, during the video, they showcased several different developers creating fantastic prototypes for the iPhone in two weeks. I suspect that development and debugging time could have been reduced more if only garbage collection was enabled. =)


2. Crippled simulator
   Not sure if this will change in the future but the current simulator is rather dumb and featureless. You cannot even trigger the hard buttons (like the volume UP/DOWN, silencer, top button). The only button you can activate is the home button -- the one at the bottom of the screen. And no, you can't simulate the features of the accelerometer.
   
   It does however support the two-finger gesture if you hold on the OPTION key on your keyboard.
   
   I suspect that this is a ploy by Apple to get people to i) buy iPhones to test on b) subscribe to the $99/year developer deal to get your app on to the iPhone. After all, how are you going to test your next greatest app that relies on the accelerometer if the simulator cannot even handle it. However, of my three criticisms, this might be the easiest one to fix.
   
   Google's Android emulator is currently better but that could be because there isn't an actual phone to run it on yet!


3. $99/year (yes, it's PER YEAR!)
   Apple Announces iPhone 2.0 Software Beta

   During the beta iPhone SDK program, a limited number of developers will be accepted into Apple’s new iPhone Developer Program and offered the ability to get code onto iPhones for testing. The Standard Program costs $99 (US) per year and gives members an iPhone SDK and development tools; access to pre-release iPhone software; technical support; the ability to get code onto iPhones for testing; and distribution of applications via the new App Store. The Enterprise Program costs $299 (US) per year.

   
   To even get your app for testing onto the iPhone you need the special version of the SDK or a special license. This is weird since that means that I cannot even write an app for MYSELF and install it on my phone just for my own PERSONAL use.
   
   Plus, right now no one can install your app unless you list it on iTunes (which minimally also requires the $99/year contract).
   
   You can argue that this annual fee is not really a problem with the SDK but I think it is. After all, without paying the fee, your SDK basically allows you only to experiment and not actually get anything onto your iPhone.
   
   I think the $99/year (or $299 for Enterprise) fee is somehow used to do code signing which I think is a weird way to guarantee that your program is non-malicious. I could be wrong.
   
   Also, after having to pay $99 would anyone release your app for free??!! I look forward to seeing how many free apps there will be. My prediction is that apps that are somehow tied to a desktop app that costs money (for instance, Transmit, NetNewswire, etc) might be free since the cost is absorbed by the desktop app.
   
   It would be interesting to see how it would compete with Android in terms of interested developers. I am not sure if it is a good idea to actually get developers to pay to actually use the development tools.
   
   I do like the idea of paying the yearly fee to have Apple list your product for you on iTunes but it would be good to offer developers the choice of distributing their own applications if they want. In fact, just being able to install your own app on your own phone would be fantastic!

So while the SDK definitely has a lot to offer, it also has some serious shortcomings that might discourage some developers. But with all things Apple, they certainly won't mind ostracizing some developers in favor of others....

There are certain events that are just so exciting that I feel compelled to blog about them immediately after I experience it. This is one such event.

Alan Kay recently gave at talk at TED. You can view his video from here. Like all TED talks, it's about 20 minutes long so it's short and straight to the point. The rest of my post will make references to the video, so reading it without watching the video might not make much sense.

Unsurprisingly, in the video, Kay demonstrated the canonical moving car example for Etoys. The moving car demo is something that most people familiar with Squeak would have seen. It's really simple but it lets kids experience programming in a fun interactive way. Unfortunately, this is something that most modern languages have failed to enable. After all, which is more fun: printing text to the screen or watching your creation actually move on screen?

However, the second part of Kay's demo was even more interesting. He shows what you can do to help illustrate some simple math and physics properties in an insightful manner. It uses all the features of Etoys (or maybe the full Squeak implementation) to let students experiment by themselves.

Experimenting with this would have been so much cleaner than using a tape meter. It's actually even cooler when you watch the animation or code it up yourself in Etoys.

For instance (and this was something that impressed me), you could design a simple car that drop dots along as it moved. So, a car that is accelerating will be dropping dots further and further apart from one another. This is basically the same idea as using a tape meter. However, the animation of the car moving and dropping dots seem so much cleaner to me. You can easily illustrate the concept of velocity and acceleration without having to talk about friction, etc. Something that is unavoidable with a real experiment. This helps especially when you are teaching a younger audience about the basic principles of motion.

Toward the end of the talk Kay showed an example running on the OLPC. So I was curious whether all courseware on the OLPC will be interactive or whether they will be like normal textbooks only in digital format. Either way, it's already hard enough to actually get good content onto the OLPC. As far as I know, there is no group dedicated to creating content for the OLPC yet.

However, I was able to find a couple of interactive learning environments at OLPC Courseware Review but, from the list, it seems that Dr. Geo II is the only one that has been ported to run on the OLPC. It would be interesting to see if there is a Google Summer of Code project for creating/porting an existing interactive learning environment to the OLPC.

Incidentally I was reading "A Mathematician's Lament" by Paul Lockhart which also talks about how to revamp the current K-12 mathematics education. The paper is available from here. Basically, Lockhart says that there is not enough experimentation with math going on in the class rooms. And that most of math is rote memorization with little appreciation for the beauty of math.

The math education back in Malaysia is not much better either. In school, the teachers are more interested in finishing the syllabus. So students either get-it in school or have to rely on paid tutors to teach it to them. There's very little appreciation on the derivation of the proofs of math. Either the derivation is skipped entirely while teaching or it follows the route of the boring derivation on the board that doesn't engage students.

I was reading the book Spring In Action in my attempt to learn about Spring. More importantly, I needed to know enough to be able to incorporate refactoring support for it as part of my project.

Unfortunately, the book had some typos which were actually technical errors. And this was just in Chapter 1! If you are trying to learn something for the first time and there are typos, you might not be able to detect it. And this can lead to hours of frustration....

Fortunately, IntelliJ has support Spring. And it detects the errors for you! So even if the technical reviewers did not detect the error, at least your IDE (a good one) can do it for you and save you time.

IntelliJ 7 has support for Spring. In this case, it detected that something was wrong with the xml configuration file.

It even offers the ability to correct the error!

I wonder if the error in the book could have been detected had the reviewers use a better tool. Or at least attempt to run it using some automated tool.

A few months ago, I posted an entry about being able to search your menu items and how it can be useful. Well, it seems that OS X Leopard actually has this feature now.

Searching Safari menu items in Leopard.

So, by going to the Help menu you can actually search for a phrase and if that phrase appears in the menu items, it highlights it for you. And the blue arrow actually animates by moving slightly.

Of course, this would be more useful with a keyboard shortcut. And the keyboard shortcut that you are looking for is ⇧ ⌘ /. In case those symbols did not show up properly, they're Shift + Command + /.

A few months ago, I posted an entry about being able to search your menu items and how it can be useful. Well, it seems that OS X Leopard actually has this feature now.

Searching Safari menu items in Leopard.

So, by going to the Help menu you can actually search for a phrase and if that phrase appears in the menu items, it highlights it for you. And the blue arrow actually animates by moving slightly.

Of course, this would be more useful with a keyboard shortcut. And the keyboard shortcut that you are looking for is ⇧ ⌘ /. In case those symbols did not show up properly, they're Shift + Command + /.