nick.recoil.org

In the last few months, I’ve made time to migrate some old RubyCocoa code to the latest and greatest version of MacRuby. Not only did I see a huge performance increase across the board, I found I could also create a stand-alone binary which could easily be distributed to end users. The entire framework is fast becoming a first class citizen on Mac OS X.

It was during the porting process that I ran into a small issue when attempting to read ID3 tags from mp3 files. I’d previously used the native Ruby gem ruby-mp3info, but this had some compatibility issues with MacRuby 0.6, and refused to install. After hacking around with the gem source, I worked around the issues, but the resulting performance was awful, so I reviewed my choices:

1. Investigate the cause of the performance problems in ruby-mp3info
2. Switch to using id3lib-ruby
3. Investigate bundles and use a C/C++ library directly

I didn’t sink a lot of time into fixing ruby-mp3info’s specific problems on what is still a relatively niche platform, and I felt that using id3lib-ruby would complicate my ability to create standalone binaries. id3lib-ruby is so named because it depends on the libid3 C++ library, which would introduce another layer of complexity into the build process. Lastly, the id3lib gem didn’t support the latest version of ID3 tags, and wasn’t under active development.

That left the last option, which I had always wanted a good excuse to investigate. I had originally looked into this when I originally started looking at RubyCocoa in Summer ’09, but linking with native Objective-C seemed excessively difficult and poorly-documented.

One of the many improvements that the MacRuby project brought over RubyCocoa was to make this functionality as easy as loading bundles in native Objective-C applications. This is achieved with use of the NSBundle class, so I thought all I needed to do was to take a C or C++ ID3 library, and wrap it in a very small Objective-C wrapper. Through the magic of runtime introspection, all of the wrapper’s methods would become available when you loaded the bundle into the MacRuby environment.

After reading up on existing tutorials, I managed to get this to work, and because it’s using the native compiled code, it’s extremely fast. This process of using interpreted Ruby code with compiled C/C++/Objective-C code is tremendously powerful, and allows for a mix and match approach to development that enables both rapid prototyping, and an ability to optimise for performance, from within a single codebase.

So powerful is this technique that I wanted to write up my experiences for others, who like myself, had maybe had just enough experience with Ruby (through Rails) and iOS development to feel that merging them together might be fun. With Mac OS X as my primary desktop environment, I’ve now achieved a triumvirate of control:

1. I can write web-based code that lives in the cloud and is available from anywhere in the world.
2. I can write mobile applications that I can carry with me at all times.
3. I can write larger, more flexible and powerful applications when a desktop environment is appropriate.

I can remember buying my first Powerbook back in 2002 and getting the distinct feeling that Mac OS X had successfully channeled all of the potential energy that the original NeXTSTEP had so successfully created. That this was a futuristic platform that eagerly awaited the craftsman’s touch. Something that could be deftly moulded it into whatever shape you could conceive, if only you invested a little time in the tools.

Eight years on, the choice has grown richer. MacRuby occupies a unique place within the spectrum of development tools on the Mac, offering a high level ease in harnessing low level power. If you haven’t looked at it yet, I can recommend a good tutorial.

I’ve just put a little article up on the Tactotum blog about the possibilities of processing your automatic iPhone backups to create a giant database of all your phone calls and SMS messages.

I’ve finally enabled SSH on my long dormant AppleTV, and am integrating it into my DVB / Rails / Beanstalk / MySQL system for processing data. I’ve used the Patchstick image available from atv4windows. I ended up unpacking and dd’ing the image from the Mac, but the process remains exactly the same. I now have Perian, ssh and a slew of other things enabled, and all I need now is to attempt the hack to get composite output working. I’ve yet to take the plunge and replace my old CRT with an LCD TV.

Incidentally, for anyone looking to figure out the ssh username and password for your freshly enabled ssh daemon, they are both frontrow, and that user has passwordless sudo privileges.

I also had a minor breakthrough with my x86_64 Ubuntu 8.04 machine. I have a Zyxel G-202 Wireless USB stick, to keep the number of trailing wires to a minimum, but I kept getting an error saying:

1

zd1211rw error ioread32(CF_REG1): -110

Which was exceedingly unhelpful. I eventually tried disabling hi-speed USB from the BIOS, and rebooted to find it sprang into life immediately. Great! What was even more strange that when I rebooted and reset the BIOS back to enable USB 2.0, the G-202 kept working. I’m unsure whether this is due to the device not being cold booted, and I’ve yet to see if it stops working after I power the system off, but so far so good, and I don’t need to resort to NDIS.

I’ve been accepted as a committer to MacPorts, initially to look after beanstalkd, but I’ll hopefully extend what I contribute to. I’ve been a consumer of Macports (née Darwinports) for a long while, and use it regularly to create my local development environment on the Mac. As of today, I have 98 ports installed, from ImageMagick to zlib, and I’m happy to be giving back some effort to something I get so much value from.

I was sitting in my local wifi-enabled cafe in London for the first time yesterday, and was struck with a peculiar problem. I could attach to their Wi-fi network properly, and browsing webpages worked fine, but trying to scp a small file to one of the recoil.org servers was stalling at exactly 2064kB.

I had a quick glance around for the problem on Google, and a thread turned up on the Apple message board. These people were discussing the same symptoms as I was having; An scp would start out fine, but stall after a particular amount of data had transfered. Following lots of discussion about tuning net.inet.tcp.delayed_ack, I tried fiddling with all sort of sysctl and ifconfig settings for the best part of an hour, and eventually had success.

I had to drop the MTU of en1 down from 1500 all the way down to 1400 for the problems to go away. The more common settings you might find via Google such as 1492 didn’t resolve the issue. For those of you who might have arrived here looking at similar issues, type the following into a Terminal window:

 sudo ifconfig en1 mtu 1400

I’m not entirely sure what was going on, but Path MTU discovery is turned on by default on the Mac. By blocking ICMP packets on the Wifi network, it may cause issues with the discovery system. If people are more familiar with the networking circumstances here, drop me a comment/email.