Why I Hate Unix, Part VI

OK, so my new favorite programming language is Ruby. And there's this thing call "Ruby on Rails" that is a remarkably clever, sophisticated framework for building web sites that's written in Ruby. There's also a RubyCocoa package, which translates Ruby stuff into Cocoa and back. Cocoa is the name of one of the underlying systems in the Mac operating system. To open windows, do mouse things, fiddle with icons, chat with printers, and generally use any of the cool sexy features of the Macintosh and its operating system, one needs to talk to some part of Cocoa. Rails and RubyCocoa are both very cool and clever. Of course, first you have to install them. Once again, I get to suffer through the pain and misery of installing something from Unix's command line. We join this tale of woe in progress. . . .

September 2005

Well, the Rails installation has finally failed completely. I reached the point where Rails would get invoked when the right page was called, and I could even get results back, usually, *if* I did not attempt to communicate with my database. I couldn't get it to generate a useful error message, so I shelved that for a couple days.

Then my entire 'server data partition' (where websites, mail, and database files live) was obliterated when my RAID array botched a rebuild of a faulty drive on the one day in the past three months when I didn't have a backup of the whole thing.

So it's something of a moot point. I am now shopping for a used XServe.

I moved back to my other project, the RubyCocoa task list manager. That's been blowing up with bus errors for no obvious reason. Since it's clearly a fault in RubyCocoa, Ruby, or OSX, instead of programmer error, I've been a bit stymied. Since I now know that my 1.8.2 is the November version, I decided to install the December one.

Well, from the command line, I get the new 1.8.2 (darwin7.9.0). But XCode can't let go of the older, powerpc-darwin7.5.0 version, and continues to fail with a bus error semi-randomly. I have no idea how to get it to get a clue; repeated fiddling on my part just upsets it when it can't find the older libraries or whatever it's looking for.

I decided to scrap everything and reinstall Ruby from scratch.

In order to be able to tell the difference between the older 1.8.2 and the newer 1.8.2, I named the newer version "ruby-1.8.2(12/25/04)". How delightful to discover that "make install" can't handle parentheses. "Configure" didn't bat an eye. "Make" didn't have a problem. But "Make Install" instantly fails. And if I change the directory name, it still fails, since it turns out that "configure" hard-coded its own directory into the files it built. So I have to start over from the very beginning.

Then I can try installing gems. Then RubyCocoa. Then Rails.

[pause]

Or not. Make has failed.

compiling iconv gcc -fno-common -g -O2 -pipe -fno-common -I. -I../.. -I../../. -I../.././ext/iconv -DICONV_INPTR_CAST="(char **)" -c iconv.c iconv.c:1: bad macro argument list iconv.c:231: illegal function call, found `inptr' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode :1:1: no macro name given in #define directive make[1]: *** [iconv.o] Error 1 make: *** [all] Error 1

Let's try again....nope, my installation directory is now mysteriously corrupted. I must now erase it and download a whole new copy of Ruby. I guess I'll try the package that 'discordantus' put together. After I finish banging my head against the wall.

I do both, but neither one helps. One helpful soul on the RubyCocoa mailing list suggests "Another possibility is that the crash is a result of normal ruby exception being thrown, which the Objective C runtime doesn't know how to deal with it. The CVS version of RubyCocoa has support for handling these correctly."

Uh, oh. The "CVS version"? Is that shorthand for "a newer but not officially released version?" And would I have to have CVS installed (no, no, not that horrible word!) in order to access it? Yes, and no. The CVS system is already installed on my Mac. However, I'm told "Be prepared for this not to work first time, as there are probably a bunch of things that it needs in order to compile which you will need to track down (I haven't done it in a while so I'm not sure what they are)."

Uncle. Uncle, I say! I'm just going to go do other things for a while, and come back to this when I have more stamina.

December, 2005

With the announcement of RubyCocoa 0.4.2 I thought I might be able to move forward on some Ruby projects.

Go to web site. Go to download page. Download Panther installer. Install. Load a Ruby work-in-progress into XCode. Watch project fail to compile.

The download page says "Before downloading, you may want to read the Release Notes and ChangeLog." There do not appear to be any "Release Notes" on that page, nor any obvious links to same. However, if I instead do

Go to web site. Follow link to "main page." Follow link to "Getting RubyCocoa"

...then I see a notice that the binary distributions are for ruby 1.6.8. I'm using ruby 1.8.2. Could that be the problem? Mostly likely, yes. Anyway, I guess I'll try compiling from source.

First try for that failed too. The configure script can't handle spaces in the path. (This has since been fixed.) OK, I'll move everything to some place that doesn't have spaces in the path.

OK! Got the new version of RubyCocoa installed! However, trying to compile my Ruby program in XCode still fails. can't open library: /usr/lib/libruby.1.dylib (No such file or directory, errno = 2) Well, no kidding. That's because it's in /usr/local/lib.

I open .plist files. I use grep. I use otool. I use find. I use lsof. And eventually, at long last, I find out that, while the new install of RubyCocoa quite properly installed RubyCocoa.framework into my /Library/Frameworks/ folder, what XCode was using was the totally unexpected [my home folder]/Library/Frameworks/RubyCocoa.framework.

Lovely.