Julian Rex

The Short Answer

Add --no-check-certificate to the wget call in logBugDataP4.pl

The Waffle

On the recommendation of Kirby, I’ve been trying out FogBugz for task and bug tracking. I’d dismissed FogBugz assuming the cost would be too much (and for the daft name), but, amazingly, it has a free startup edition – good for 2 users. (One of the most interesting features is the Evidence Based Scheduling i.e using historical metrics for better estimates. I’ll be very interested to see how it works out.)

FogBugz integrates with a number of SCM packages. In my case I’m also running the free 2-user Perforce install, and of course wanted to link the two. (I’ll get around to SVN and Git too but for now it looks like I’ll have to sort myself out for integration with AccuRev).

For Mac OS X, FogBugz has a Perl script (logBugDataP4.pl) which scans your changelist description for lines like:

BugzIDs: 1234


This allows FogBugz to link back to the Perforce changelist (if you’re running P4Web). By default though, the script appears to fail when issuing the wget.

The answer is to add –no-check-certificate to the wget calls, so that:

system("wget '$url' -q -O /dev/null");

becomes

system("wget '$url' -q -O /dev/null --no-check-certificate");

In my version I’ve removed the -q and the /dev/null preferring to dump the output and logging to files, so I can see what’s going on.

(There are two calls around lines 134 and 165.)

A recent post over on Acorn Heroes, “Unit Testing and linking Static Libraries with XCode”, has got me thinking: I went through a similar process a few months ago, when I was integrating UnitTest++ into my build environment. I use external makefiles to build static C++ libraries and the associated tests, and although the standard approach works well for the simulator, I still haven’t found a decent solution for the running on the iPhone itself (read more below).

Unit testing on the iPhone Simulator

Although this is a solved issue (using the “google-toolbox-for-mac” approach), it still runs UI-less, which most of the time is fine. Approaches such as using OCMock look great, but at the time I wanted to see if I could get unit testing running on the simulator with the UI.

Using a combination of tools like fseventer (which observes filesystem changes) and Peek-a-Boo (which observes processes), I set about documenting the application startup process (on the simulator). From this, I cobbled together a script which I’d hope would do the trick… but unfortunately not . But I think it must be close!

I’ve put the salient points of the script at the end of the post, in case someone else has a solution.

Unit testing on the iPhone

Running tests from the command line (built via makefile) on the device is what I’d really like to find an answer to, but I haven’t really got very far with this

The strongest candidate at the moment may well be a combination of CMake to generate an XCode project file, and then using Applescript to launch the app, as others are discussing here. Unfortunately the command-line tool xcodebuild doesn’t appear to have an option to launch applications.

Do you know of any alternatives?

For running test sub-projects (not built from the command line) the article Unit Testing Applications on the Apple developer site is definitely worth reading, especially the section “Setting up Application Testing”, but again doesn’t help in my situation.

“Script” for running unit tests on the iPhone Simulator

Finally, here are the snippets of the script I talked about earlier. I haven’t had time to revisit this since the release of OS 3.0, but if anyone else has tried anything similar I’d be very interested in hearing about it.  As I mentioned above, this script doesn’t work, so is only here for reference!

# Start the simulator, but wait...
"/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone Simulator.app/Contents/MacOS/iPhone Simulator" -SessionOnLaunch NO &

# Get the pid of the simulator, we'll need that in a moment
pid=`ps wwax | egrep -i '[i]Phone Simulator' | awk '{ print $1 }'`

Now I found I had to set the usual environment variables, as per the standard approach, namely, DYLD_ROOT_PATH, DYLD_FRAMEWORK_PATH, IPHONE_SIMULATOR_ROOT and CFFIXED_USER_HOME.

# Start the simulator bridge
"/Developer/Platforms/iPhoneSimulator./Developer/Applications/iPhone Simulator.app/Contents/MacOS/SimulatorBridge" $pid &

# Had to unset some environment variables for the following commands to work.
unset DYLD_FRAMEWORK_PATH

The following is where it gets a bit odd. I noticed a sequence of launchd, installd and securityd (which may need to be run as another user, possibly _securityd).

#launchd - not sure what this is doing perhaps handling the following sequence.

# Run installd with a timeout of 30 seconds
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/usr/libexec/installd -t 30 &

# Run securityd - think this is something to do with entitlements
#/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/usr/libexec/securityd

# Now start SpringBoard
"/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/System/Library/CoreServices/SpringBoard.app/SpringBoard" \
    -SBDisableAutoDim YES \
    -SBAutoLockTime -1 \
    -SBAutoDimTime -1 \
    -SBDontLockAfterCrash YES \
    -SBDidShowReorderText YES \
    -SBFakeBars YES \
    -SBDontAnimateAppleDown YES \
    -SBEnableDoubleHeightToggling YES &

# Now start the app, which you'll find in some auto-generated folder in
"/Users/.../Library/Application Support/iPhone Simulator/User/Applications/.../test.app/test"

There’s not a huge point in chasing a solution to this broken script, as the UI-less testing works so well. But, have you tried anything like this at all? It strikes me that the jail-breaking crowd may know more.

Just a quick note about the new iPhone 3GS. Recently Noel Llopis tweeted about an AnandTech article, which contains more detailed info about the iPhone 3GS and its hardware (see page 2 for the juicy details).

It’s not clear if the information comes from a tear-down, but it matches a lot of other information out there in the wild. So while this hasn’t been confirmed, I’m happy to assume that the info is good.

The Cortex A8 is an ARMv7 chip, where the chip in the existing iPhones is an ARMv6. The PowerVR MBX, gets replaced by a PowerVR SGX with programmable shaders.

These specs represent a big leap in performance compared with the previous generations; NEON represents improvements for SIMD operations, in terms of speed and usage, and OpenGLES 2.0 will give improved graphical performance and fidelity: Sony needs to come up with a PSP2 soon, as this new iPhone has some serious oomph.

So, Phaze, the iPhone and iPod Touch game I’ve been working on with Andy Wilton of Pazzazz Games, has recently been launched!

It’s a futuristic racer with a number of unlockable tracks and ships, weapons and progression through a number of different worlds and levels.

You can grab it from the App Store right now Or read more about it at the Astraware website.