Category: Code

Sorry I haven’t posted this earlier – I got another request for it in an e-mail today, so I feel prompted to do so now. Hopefully this will get added to the standard RubyCocoa install. I’ve been using the wrapper without issue for about five months, during the development of SyncBridge.

Usage: install RubyCocoa and drop this somewhere in Ruby’s library path. If you have any issues with it, please let me know.

You can download the wrapper from our downloads page (or directly by following this link).

Technorati Tags: rubycocoa, ruby, syncservices

The comments feed wasn’t working in our Typo install (as of build 1055 which is the latest at time of writing). This was also reported on the Typo Trac, so I’ve posted the solution there.

Technorati Tags: typo

As we rapidly approach our semi-public Beta stage, I’ve switched from using WEBrick to Lighttpd (or ‘lightie’ as they like to call it *shudder*) as the web server. This also means switching to FastCGI. A brief overview on Oxyliquit gives the configuration that you’ll need which usually lives in /etc/lighttpd.conf on Linux or /usr/local/etc/lighttpd.conf on FreeBSD.

Here are some issues I’ve run into, in the hope that they’ll be useful to someone else.

When starting lighttpd, if I have more than one fcgi process (min-procs and/or max-procs > 1), Nitro starts the Og.setup once for each process. This means that you have to turn off schema evolution (:evolve_schema => false) and obviously make Og not drop the database at start-up (:destroy => false).

Nitro doesn’t know what your template directory is by default under fcgi. In your run.rb (or whatever script you use to start your Nitro app) insert Template.root = '/path/to/your/template/dir' before you start your app.

Nitro (and Og) doesn’t log everything properly into your log/app.log. This is some weirdness in the code base, which hopefully will get tracked down (possibly by me), but as a work around (thanks Brian!) put the following two lines at the top of your run.rb:

require 'glue/logger'
Logger.set Logger.new('/path/to/your/app.log')

Finally, if like me you’re using Nitro/Og in a REST-style manner, you may want to get access to the body of any post request. In WEBrick I did this with request.raw_body, but this doesn’t work with FastCGI. Unfortunately, there is no workaround for this that I can find, so I’ll be writing a fix tonight, and posting to the Nitro mailing list (and here in the comments).

Technorati Tags: lighttpd, nitro, fastcgi, ruby

In case it hasn’t become obvious by now, SyncBridge 1.0 is partially implemented using the RubyCocoa library (for all the usual reasons that one would choose Ruby over Objective-C). I’ve had to wrap the SyncServices API such that Ruby understands it (and I’ll be releasing that very soon as open source – Fuji-san is aware that I’m going to be doing that).

The single biggest issue that I had to debug was in type mismatches. SyncSchemas and Client Descriptions are what SyncServices use for determining what properties need syncing between clients, devices, servers, etc. These properties are specified using fairly generic names (“number”, “array”, “calendar date”) but they map directly to very specific Cocoa foundation types. RubyCocoa handles most of these just fine, but some aren’t quite right.

The two main culprits I’ve found so far are Fixnum and Date. A Fixnum gets translated to an Obj-C NSDecimalNumber, but SyncServices expects an NSNumber. Likewise, a Date becomes an NSDate, but SyncServices expects an NSCalendarDate.

Now for the really annoying part. SyncServices exception handling seems a bit spotty – when I passed a (RubyCocoa-converted) NSDate, it threw me an error that made it easy to see I needed to change the type of the variable (and SyncroSpector allowed me to determine which type). But when I pass an NSDecimalNumber instead of an NSNumber, the SyncServer didn’t throw any warning at all, it just didn’t update correctly (or at least this is the symptom I’m still seeing).

I’ll post more as I get to the bottom of this, possibly with a conversion table/script to make the SyncServices/RubyCocoa wrapper a bit more intuitive to use. It might be that RubyCocoa makes assumptions about types that I can override in the wrapper.

This relates to MJ’s “Almost done” post earlier.

The actual problem was one of poor coincidental timing. I upgraded to 10.4.6, I started using Syncrospector, and I changed some code, all within a few hours of each other.

Syncrospector is a developer tool from Apple which allows great insight into the whole Sync process. I turned on some debugging info when I first started it. I then started running and debugging the code and started getting weird untraceable errors:


ISyncConcreteSession#pushChangesFromRecord:withIdentifier: - NSInvalidArgumentException - *** -[NSProxy forwardInvocation:] called!

failed to save the call history: NSInvalidArgumentException *** -[NSProxy forwardInvocation:] called!


I tried to track down this error, and eventually decided to switch on “Save call history very frequently” in Syncrospector’s preferences. This option comes with a warning about a performance hit of “catastrophic proportions”, which is why I hadn’t turned it on at this point. Sure enough, I got the above error a lot more times. The astute reader will think this obvious, but I hadn’t read the names of the preferences for Syncrospector, just the descriptions of what they did.

Turning off the call history saving made the error go away.

I’ll detail the other show-stopper bug in the next blog post, mostly because the information contained in each of these posts is good search engine fodder.