We had a visitor on #ironruby today asking for help getting IR running on his mac. I gave him the following directions, and they seemed to work aside from one glitch. I tested them on my wife’s mac, and it worked for me, too.
You can grab the Mono .dmg from go-mono.com. This will install the framework and put the required programs (mono, xbuild) in your PATH.
Fetch the IronRuby source
Since Jim Deville likes macs, I’m sure more recent versions will work, but this is the one we’ve recently packaged up for Debian and tested on Ubuntu. If you want to be certain that the IronRuby code you write on Debian works on OS X, then you should probably build from the same version of the source. You should probably also install version 2.4.3 of Mono, but that may be more effort than it’s worth ;)
Unpack the tarball
Open up a terminal and unpack the thing you just downloaded:
$ mkdir ~/src/ $ cd ~/src/ $ tar xfz ~/Desktop/mletterle-ironruby-e6b28d2.tar.gz $ cd mletterle-ironruby-e6b28d2/
At this point, you should be able to build the IronRuby assemblies using xbuild. I don’t recommend using rake, as it has some dependencies, and I’m not a fan of dependencies.
$ xbuild /p:TreatWarningsAsErrors=false Merlin/Main/Languages/Ruby/Ruby.sln <snip/> Build succeeded. 2817 Warning(s) 0 Error(s) Time Elapsed 00:00:28.8378230
Run the IronRuby interactive interpreter
Our guest mentioned that he was using a terminal with a white background. Do note that the font color of the interactive interpreter (aka Read-Eval-Print Loop or REPL) is white, so if you’re using a white background, you might want to change it. IIRC, there is a way to change the font color using a configuration setting. Figuring it out is left as an exercise for the reader.
$ mono Merlin/Main/Bin/Debug/ir.exe IronRuby 0.9.0.0 on 2.6.3 (tarball Wed Mar 10 18:18:12 MST 2010) Copyright (c) Microsoft Corporation. All rights reserved. >>> 1+2 => 3 >>> exit()
Extra credit: IronPython
The tarball you downloaded also included the source to IronPython. The procedure to build/run IronPython is pretty similar to IronRuby.
Unlike IronRuby’s .sln, this version of IronPython’s .sln does not have a default configuration parameter, so we need to specify it with the /p:Configuration=Debug argument.
$ xbuild /p:TreatWarningsAsErrors=false /p:Configuration=Debug Merlin/Main/Languages/IronPython/IronPython.sln <snip/> 69 Warning(s) 0 Error(s) Time Elapsed 00:00:38.8057450
Run the IronPython interactive interpreter
IronPython has a REPL interface like IronRuby’s. Or is it the other way around? Anyway, here’s an example.
$ mono .//Merlin/Main/Bin/Debug/ipy.exe IronPython 2.6 Beta 2 DEBUG (188.8.131.52) on .NET 2.0.50727.1433 Type "help", "copyright", "credits" or "license" for more information. >>> 1+2 3 >>> ^D
This is the gist of it:
$ cd /usr/src/
# $ sudo chmod a+rwx .
$ wget ftp://ftp.suse.com/pub/projects/kernel/k
$ alien -tg kernel-source-184.108.40.206-0.0.0.25.15a4c6f.s
$ cd kernel-source-220.127.116.11
$ tar xfj linux-2.6.27.tar.bz2
$ for f in patches.*.tar.bz2; do
tar xfj $f || break;
$ for p in $(./guards x86_64 < series.conf); do
patch -d linux-2.6.27 -p1 < $p || break
$ cd linux-2.6.27
$ fakeroot make-kpkg debian
$ fakeroot make-kpkg build
$ sudo make install modules_install
$ cd /usr/src
$ hg clone http://xenbits.xen.org/xen-unstable.hg
$ cd xen-unstable.hg/unmodified_drivers/linux-2.6
$ XEN=/usr/src/xen-unstable.hg/xen XL=/usr/src/kernel-source-18.104.22.168/linu
$ make -C /usr/src/kernel-source-22.214.171.124/linux-2.6.2
$ sudo make -C /usr/src/kernel-source-126.96.36.199/linux-2.6.2
Thanks to Marek being a superhero, we have isolated the changes necessary to fix the compiler from the 188.8.131.52 tag so that we can build IronRuby with xbuild. I’ve delivered the patch to meebey, and he has included it in his debian/patches list.
Without this patch, I was going to have to package up the pathname2 gem and add a dependency on rake and this gem. Ick. Too much work, and we planned to move to xbuild eventually anyhow, so it would have been thrown away as far as I’m concerned.
Now all I’m waiting for is the diff.gz from meebey, then I should be able to get the IronRuby packaging done and commit it to pkg-cli-libs.
But rather than sitting around and waiting for this, I should really clock some billable hours…
09:31 < directhex> the trick appears to be that a) the GTK# included with mono for windows lacks all stock_ icons, rendering it sucky, and b) Novell.Directory.Ldap on windows ignores the windows certificate stores 09:38 < directhex> and i still feel trying to load a missing stock icon should not cause an exception, since it's entirely dependant on a user's themes and such 09:47 < cj> morning folks 09:48 < cj> directhex: have you filed a bug? 09:48 < directhex> cj, no. i've been waiting for someone to disagree with my assessment 09:49 < cj> directhex: you'll also likely have to do a bunch of it yourself. Our resident win32 gtk# guy is training for the military 09:49 < cj> directhex: no. you're right. it needs to be fixed. 09:49 < cj> directhex: go file a bug 09:49 < directhex> two bugs. i've got another one. 09:49 < cj> got a blog? 09:49 < cj> making them public is a good way to get patches 09:50 < cj> fixing them yourself is a good way to get familiar with the internals 09:50 < cj> filing bugs is a good way to keep track of your progress 09:51 < directhex> i have a blog, but it's not the place to mention mono bugs 09:59 < directhex> cj, what's the correct place to file a Novell.Directory.Ldap bug against? it's not in the list under Mono: Class Libraries, but it's in the mono upstream tarball 10:19 < cj> directhex: did you find out where to file that/those bug/s? 10:20 < directhex> cj, no, i didn't. and i've got another couple of bugs to file too :) 10:21 < directhex> i have four bugs to file. one against gtk#, one against monodevelop, one against novell.directory.ldap, and (if possible) one against paco's gtk# for ms.net 10:21 < directhex> i know where to file the first two, i just need to do more investigating to find the problem 10:22 < cj> directhex: have you checked here? 10:22 < cj> http://bugzilla.ximian.com/ 10:23 < directhex> cj, it looks like i'm meant to file the latter two on novell forge, but i'm worried they'll get no attention 10:23 < cj> directhex: public humiliation usually works for that 10:24 < directhex> ah well. at least the gtk#-win32 bug is easy to explain and file, even if paco's busy shootin' foreigners 10:24 < cj> large corporate entities squirm under such situations 10:24 < paco> :) 10:24 < cj> paco: ltns ;) 10:24 < directhex> my word, a paco! 10:25 < paco> directhex, tell me mine 10:25 < paco> send me an email at email@example.com 10:25 < paco> Hey cj 10:25 < directhex> paco, you include Novell.Directory.Ldap, but not Mono.Security (without which the former doesn't work) in your latest runtime installer 10:25 < directhex> or email, that works too 10:26 < paco> that should not be too hard to fix 10:26 < paco> in between shots I should be able to repackage and upload a fixed version
Novell will continue to ship *both* GNOME and KDE, but instead of doing what it has done since "obtaining" SuSE and Ximian, it will now make GNOME the default desktop.
Good news for me. Not so good news for my friends who develop QT applications that run on the KDE desktop.
I think this stresses how important cooperation in the Free Desktop project is. You can read more about this project, started by a Red Hat developer, Havoc "hp" Pennington at the following URL:
I have been writing GTK+ applications since 2000 and have many times wished that KDE and GNOME tools functioned more similarly or at least inter-operated more smoothly.
Perhaps the QT documentation should be presented in a style that gtk+ developers are familiar with. We keep our API documentation here:
Where does the QT API documentation reside?
From this article:
Contrary to what was expected from recent Novell announcements, Novell executives are apparently slicing deeply into the Linux heart of the company. Jobs and resources are actually being slashed in several areas previously dubbed by Novell management as "key component parts of Novell's Linux developments": staffers working on Mono, Hula, Evolution and Desktop Strategy are getting the sack.
Eep! I think that's a couple of my friends losing their jobs.
One of my friends at Novell in the group in question tells me "that story is both wrong and old news." So I'm not concerned.
I run... ahem...
Ubuntu GNU/Linux with GNOME on an IBM T42 Thinkpad.
Based on the recent discussions fueled by Linus Torvalds, I look forward to the coming of GNU's multi-server operating system, HURD, which runs on the GNU project's Mach microkernel.
Anyone have any first-hand familiarity with HURD or Mach?