Justin added a Twitter posting feature to Golden Cheetah a couple weeks ago. However, it used basic authentication, which Twitter has announced is going away in favor of OAuth only. So, after several more days of coding he did a bang up job of rolling in support using liboauth.

Now, getting liboauth and it’s prerequisites configured to play nicely with my Golden Cheetah dev environment has been another struggle. I have been making the OS X releases of Golden Cheetah for a while – and we package them as a universal binary (i386/ppc) with 10.4 support. I’ve had to custom compile Qt, QWT, srmio and all that stuff to enable this.

In brief, liboauth needed to be compiled against the same arch that GC and co. have been, and it really wanted to go native, eg x86_64 on my MacBook Pro. After a night and day of tinkering…here’s what worked. Thanks to Justin for getting this going.

Export config flags (just makes life easier on the command line):

export CFLAGS=-mmacosx-version-min=10.4
export CPPFLAGS=-mmacosx-version-min=10.4

openssl 1.0.0a:

./config -m32

liboauth 0.8.8 / curl 7.21.1:

./configure CC="gcc -arch i386" CXX="g++ -arch i386" -host i386

Golden Cheetah:

After getting linker errors for a while, I realized that I had to directly link to the static version of libcrypto that was installed alongside libssl in /usr/local/ssl.

Undefined symbols:
  "_EVP_MD_size", referenced from:
      _oauth_body_hash_file in liboauth.a(liboauth_la-hash.o)
      _oauth_body_hash_data in liboauth.a(liboauth_la-hash.o)
ld: symbol(s) not found

Here’s the relevant bit of src.pro:

!isEmpty( LIBOAUTH_INSTALL ) {
INCLUDEPATH += $${LIBOAUTH_INSTALL}/include
LIBS += /usr/local/ssl/lib/libcrypto.a
LIBS +=  $${LIBOAUTH_INSTALL}/lib/liboauth.a
LIBS += -lz
LIBS += -lcurl
DEFINES += GC_HAVE_LIBOAUTH
SOURCES += TwitterDialog.cpp
HEADERS += TwitterDialog.h
}

Rolling the extra logged sensor data into the GPX export took more effort that it should have…but I uncovered and fixed a latent bug in the export feature, so that’s a win right? Regardless, it’s was nice to use the new issue tracker at bugs.robertcarlsen.net for real(z) for the first time. I’m looking to get several other features implemented before the next released update…planning on a few weeks. Otherwise, code is available, as always, on github.

GPX export seems to be working, and imports fine into Google Earth. This is just a basic implementation of the essentials for a route; I’d really like to include other recorded sensors somehow into the track – maybe it could be a layer in Google Earth?

Looking at the ride data here reveals just how bad raw GPS data can be between tall buildings in NYC. Several data points often share the same GPS location. It seems that moving quickly with a clear path to the sky gives the best performance.

The app also quit midway though the ride – I have to look into that.

GPX export is available in the github repository.

Basic GPX export has been added to the github repo. That is all.

http://github.com/rcarlsen/Mobile-Logger/commit/9e1dc73304de562c30e64fa9a9b61840e69963c3

Golden Cheetah is about to release a new version. There have been extensive updates…some great, unique new features for analyzing cycling power training data. The full feature list will be announced with the official release. In brief:

• direct SRM download
• colorized power zones in plots
• altitude (from supported files)
• WKO file support (including bulk import)
• Critical Power (CP60) computation from aggregate CP data.
• weekly plot of time/distance and BikeScore/Intensity
• calendar view of workouts

There has also been significant work done under the hood in preparation for a pretty big announcement coming in the next few weeks. Exciting times.

Mac release candidate is available here. Linux and windows versions will be announced on the Golden Cheetah mailing list.

—

For posterity, I’ve upgraded my dev system to OS 10.6, Snow Leopard, and had to rebuild Qt and QWT. Since we want Golden Cheetah to continue to support PPC/Intel and 10.4+, here is the configure command I needed to use for building Qt 4.5.2.

./configure -static -prefix /usr/local/Qt4.5.2 -make libs -opensource -qt-sql-sqlite -LD="gcc -mmacosx-version-min=10.4" -confirm-license -universal -sdk /Developer/SDKs/MacOSX10.5.sdk

The BeachBall app has been submitted to the iPhone App Store. I’m pretty sure that I’ve crossed all the t’s and dotted the i’s throughout the application and am holding out hope for a smooth process. If all goes well it will be a great surprise just before the next semester kicks off.

Thanks to everyone who has been beta testing the (codename) Pinwheel app. I’ll be sure to give you all a copy of the final app when (if?) it’s approved.

In the meantime there are several other projects which need my attention. I’m committed to getting the in-progress work finished before moving on to new stuff…which is a strong motivator since I have a few things I’m really excited about working on. Onward…!

In preparation of submitting Pinwheel to the App Store I’ve gone and released a beta version via ad hoc distribution. Seems like it should be a straightforward prospect, however the various device provisioning, code signing profiles and entitlements made it a bit of a process for a first-timer.

iTunes also seems to be entirely unhelpful when something goes wrong with the “unknown error” message. What could it be? Code sign error? Unprovisioned device? Incorrect OS target? Mismatch in the app and mobileprovision file? It’s all a mystery in the iTunes universe.

Despite the inconvenience involved with having to generate a new ad hoc mobileprovision profile each time I add a new beta tester device, requiring a recompile of the beta app, it’s nice to finally get an app out to other non-development devices.

The ad hoc distribution process is documented well (enough) on Apple’s dev portal and on several other blogs, but my real stumbling block was navigating the Xcode interface to ensure that the proper code signing profile was being included in the binary (hint, look at the verbose build output for “embedded.mobileprovision” and ensure that the mobileprovision ID matches the correct version.)

I’ve also been getting trouble with Xcode not building using the correct provisioning, despite updating the target info and cleaning out the build folder. A restart of the program usually gets it sorted.

The next step will be to set up a Distribution build for the App Store submission. We’ll see how that goes in the end…

Update: Proof-of-concept demo. Also, updated the script for building with the 10.6 SDK.

Update #2: Source code for demo project released.

I recently had need to use an open-source library in an iPhone project. Recalling the earlier work necessary in compiling the libraries needed for openFrameworks I started looking for a more generic way to build for iPhone development. Thankfully, LateNiteSoft wrote a great article about using a shell script to cross-compile linux projects, building a Universal Binary with versions for the Simulator and Device.

I configured their provided code snippets to build tesseract-ocr for iPhone, referring to the set-up for freetype and freeimage to fill in some c++ gaps. Anyway, the library seems to have built correctly. I’ll know for sure when I incorporate it into a project, soon.

To use it, copy the script into the project directory, next to the configure script. For a simple project which generates one monolithic library, edit the LIBFILE variable to reflect the location and name of the library. I’ve only used this for static libraries…other work may be necessary to correctly generate dynamic libraries (however, the iPhone SDK prohibits linking to dynamic libraries, so in this case it seems moot). Run ./build_fat.sh to kick off the process. Look for the compiled libraries in the “lnsout” directory. There’s no error checking, so caveat emptor.

Cross-compile shell script follows: (more…)

i’ve been dealing with a performance bug in a particle + accelerometer oF app. the same project which has run very smoothly on a first generation iPhone with OS 2.2.1 has a noticeable stutter on an iPhone 3GS with OS 3.0.

there was no improvement despite several rounds of optimizing the openGL drawing code and plugging several memory leaks.

finally, in frustration i bumped the explicit frame rate declaration from the default 60 fps to 120 fps. i realize that ofSetFrameRate(60) is merely the upper limit of the frame rate, and that the hardware won’t actually go faster than it can handle, however this immediately improved performance on the 3GS and the first gen is about the same as it was. further improvement was had with a declared frame rate of 240 fps.

i haven’t had a chance to look into the underlying issue, but i believe that oF is using NSTimer under the hood to trigger a scheduled update() and draw(). has there been some change in the SDK there?

i’m having a time of it tracking down a resource allocation bloat culprit in an iPhone app i’m working on. i’ve narrowed it down to when i’m rapidly updating the center property of a UIImageView. a snippet from the Instruments application is below:

there are hundreds (if not thousands) of these messages, and the object allocation graph trends steadily upwards. when i disable the portion of the method which updates the center property the allocations stop and the memory usage goes flat. this also only occurs on the device…the simulator does not exhibit this behavior.

i’m using UIImageView directly, without subclassing, and it contains data from a small PNG file. i’ve patched up several other leaks successfully today, and really wanted to nail this one too.