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
}

Golden Cheetah has gotten a really nice write-up on the “bike racing, news and events” site nyvelocity.com. The article was featured on the front page for a time, sporting the brand new icon from Dan Schmalz.

A couple of weeks ago I sat down with Andy Shen over lunch and discussed the project, it’s developer community and my thoughts on open source software. He did a really nice job parsing my semi-coherent babel and combining it with Sean and Justin’s perspectives into a thorough history of Golden Cheetah, brief outline of how the program grows through user contributions and a great outline of the major features (and he even built some hype for the forthcoming mapping and long-term metrics features).

Great to see! Read the article at:
http://nyvelocity.com/content/coachingfitness/2010/golden-cheetah-open-source-goodness

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

We finally got a new version of Golden Cheetah out the door….it’s been only like, almost a year. Whew! Pressure is off.

I had been making personal builds since the summer to give out to folks who wanted to take advantage off several new features introduced since the march build. Sean gave Justin and I write access to the svn code this past December and we’ve been playing catch up on a backlog of patches, and i’ve been remembering c++ and Qt.

Several new features have been added in this release: Critical Power calculator, find best intervals utility, Pedal Force / Pedal Velocity chart, iBike and Ergomo CSV import, GUI power zones creator, separate vertical axes for Power / HR / Cadence and Speed in the Ride plot, sorting rides with the most recent at the top of the list, and many bug fixes courtesy of JT Conklin. This version is also using FTDI D2xx drivers rather than VCP.

We’ve also switched to a numbered versioning system which will serve to better indicate which svn revision the releases were built from and perhaps will mask our slow release cycle. :)

The new release is available on the Golden Cheetah download page.

super annoying…Qt advertises that you can make an xcode project file using qmake to enable native development on mac…i had never been able to get the golden cheetah project working in this way, even after following what little documentation i could find. each time i’d run “qmake -spec macx-xcode” would result in a non-parseable xcodeproj file. to date i’ve just been coding and compiling with a simple text editor.

justin had done some initial troubleshooting, eventually filing a bug report with trolltech. he determined that the QMAKE_CXXFLAGS = -DGC_BUILD_DATE=”`date +’\”%a_%b_%d,_%Y\”‘`” was causing the issue. commenting out the offending line to get a valid xcode project and having to create another define in a source file.

a dev from trolltech got back to justin confirming the bug and offering a workaround by manually adding the directive in the xcode target’s build settings. they also mentioned that a fix would be coming in a future version of qmake, but gave nothing specific. i spent most of the afternoon trying to follow this workaround to no avail. it was very frustrating. i looked at the project file that qmake created and something looked odd with how special characters in the qmake_cxxflags key were escaped with slashes. too many it seemed.

finally, i came across a forum post where someone was trying to set a define macro to have a string value – jsut what we are trying to do. the solution is somewhat a hack, a bandaid for a shortcoming of qmake… triple-escape the outside quotation marks. looks like: -DGC_BUILD_DATE=\\\”`date +’\”%a_%b_%d,_%Y\”‘`\\\”

it compiles fine on the linux (ubuntu) test box, manually on mac os x (using qmake/make) and also creates a valid (parseable) xcode project file, but it won’t compile in xcode. i still have to disable these lines in src.pro and add them in by manually later. for the time being, i’m planning to develop in xcode, and build test versions without the build date/version number and then compile beta/release versions by hand, which works fine.

for reference, here are the lines i’m referring to in src.pro:

QMAKE_CXXFLAGS += -DGC_BUILD_DATE=\\\"`date +'\"%a_%b_%d,_%Y\"'`\\\"
QMAKE_CXXFLAGS += -DGC_SVN_VERSION=\\\"`svnversion . | cut -f '2' -d ':'`\\\"
QMAKE_CXXFLAGS += -DGC_MAJOR_VER=1
QMAKE_CXXFLAGS += -DGC_MINOR_VER=0

the top two lines are string values; the bottom two values are integers. also note, this has been reported to not work in win32, but i haven’t tested it myself. after we get the mac/linux builds going i’ll get back to the win build.

oops. school’s out and i’ve completely ignored documentation. looking to correct that, please accept the following communiqué:

the winter show went very well – it seemed that cloud reader was well received. most of the favorable comments were split among two categories…those which really liked the performative aspect of the project and could envision it large on a wall….and those who reacted strongly to the intimate aspect of seeing it running on the iPhone screen.

since the project was originally designed for the small screen in ITP’s 2×2 class, the comments were enough to encourage me to finally get around to iPhone application development. i’ve looked over various objective-c, cocoa and iphone docs over the past year, but never really made a commitment to actually learn or apply it. now i’m driven, and have come to love square braces :)

separately and coincidentally, sean from golden cheetah decided to extend justin and i write access to the svn codebase and the website. he’s been quite busy and gc development has stalled for it. although i’ve been busy with school, between the three of us we should be able keep abreast of patches and implement new features.

i’m trying to be cautious with the project…i don’t want to do something that will expose me as a (programming) fraud! justin and i were able to get it working happily in xcode…although the QMAKE_CXXFLAGS += -DGC_BUILD_DATE=”`date +’\”%a_%b_%d,_%Y\”‘`” compiler directive in src.pro was causing qmake to create non-parseable xcodeproj files…i think it may have to do with escaping special characters. justin sent a bug report to Qt…hopefully we’ll hear something at some point…for the time-being i’ve commented out the line in the .pro file and added a conditional define in MainWindow.cpp.

so, tinkering with the golden cheetah code has be getting me comfortable with code that isn’t java and i think i’ll be well on my way to get to with with cloud reader for iphone…come on apple and approve my developer application!

finally got the iBike CSV file support added to Golden Cheetah. the issue revolved around line endings on the iBike file that a user supplied. the file had CR (old-style Macintosh) line endings, and QTextStream::readLine() doesn’t honor them…reading the entire file at once.

the solution was pretty simple: use readLine() THEN split(‘\r’) and loop through each piece. files with LF endings will be read in correctly, and the split will only result in one element. files with CR will be read incorrectly (as one big chunk) and then split into lines. the rest of the code is agnostic to the differences. snippet for reference:

        QString linesIn = is.readLine();
        QStringList lines = linesIn.split('\r');
        // workaround for empty lines
        if(lines.size() == 0) {
            lineno++;
            continue;
        }
        for (int li = 0; li < lines.size(); ++li) { 
            QString line = lines[li];

ok, back to packing for the move.

another headache with GoldenCheetah. trying to implement a new feature – support for iBike CSV files. these files have a bunch of configuration data at the top, which is easy enough to skip, but for some reason the QTextStream::readLine() function is loading the entire file rather than line 1 (at least according to what i gather from gdb).

i’d figured that it was a line endings thing (\r rather than \n or \r\n) however changing up the line endings in both a GUI editor nor via the command line (cat oldfile.csv | tr “\r” “\n” > newfile.csv) corrected the problem.

opening the file in TextWrangler, replacing the line endings AND trimming the trailing zeros from the data DOES work though…so what else is going on here? is the regex replacing other hidden characters? is the file write process doing something?

at the very least, i’m getting more comfortable with gdb.

…is alive!

Justin and I have sorted out the connection issues with the USB cradle. We needed to explicitly set up the communication parameters before trying to speak to the PowerTap.

We changed D2XX.cpp:open() (For my bigger brain):

ftStatus = FT_SetBaudRate(ftHandle,9600);
ftStatus = FT_SetDataCharacteristics(ftHandle,\
    FT_BITS_8,\
    FT_STOP_BITS_1,\
    FT_PARITY_NONE);
if (ftStatus != FT_OK) {
    err = QString("FT_SetDataCharacteristics: %1").arg(ftStatus);
    close();
}

ftStatus = FT_SetFlowControl (ftHandle,\
    FT_FLOW_NONE,\
    '0','0'); //the 0's are ignored
if (ftStatus != FT_OK) {
    err = QString("FT_SetFlowControl: %1").arg(ftStatus);
    close();
}

This opens the serial connection at 9600 baud, no parity check, one stop bit and no flow control using the D2XX driver from FTDI.

I’m going to have to write up a description of all of the build steps necessary to get it to compile in win32. The code base is the same, but the compile flags and environment have to be set up in a certain way. Also, we need libregex.a, libftd2xx.a and a linker script which aren’t provided in the GoldenCheetah source tree.

The windows binary is ready for testing, we just need to make it easily available somehow. Hooray. I need a break.

Very exciting development….GoldenCheetah has been ported to Windows. Justin Knotzke did most of the leg work and got the first build going. He helped hold my hand through getting my Windows development environment set up.

Through much debugging I was able to pinpoint where the device communication was failing…and realized that there was an issue with the installed drivers. After a bunch of tinkering with the drivers, and ensuring that I was using the correct ftd2xx.h file it finally started to read from the PowerTap via the USB cradle.

Finally, we had to switch to Qt’s methods for creating a temporary file and writing out the data. In the process a bit of the data formatting got mixed up and created corrupted .raw files which caused GC to crash when the invalid file was read back in. The important bit (for my own future reference) was to setFieldWidth(2) for the data byte, then setFieldWidth(1) when adding the space delimiter or linefeed chars. It made the code a bit less elegant, but more importantly, it works.

So, more tinkering here on the newly minted Windows build of GoldenCheetah…then out to the mailing list for beta testing.