Tags: novell

IronRuby on OS X

Originally published at The Pædantic Programmer. Please leave any comments there.

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.

Install Mono

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 ;)

http://github.com/mletterle/ironruby/tarball/20090805+git.e6b28d27

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/

Build IronRuby

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.

Build IronPython

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 (2.6.0.20) on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
>>> 1+2
3
>>> ^D

building unmodified_drivers

Originally published at The Pædantic Programmer. Please leave any comments there.

This is the gist of it:

$ cd /usr/src/
# $ sudo chmod a+rwx .
$ wget ftp://ftp.suse.com/pub/projects/kernel/kotd/SLE11_BRANCH/src/kernel-source-2.6.27.39-0.0.0.25.15a4c6f.src.rpm
$ alien -tg kernel-source-2.6.27.39-0.0.0.25.15a4c6f.src.rpm
$ cd kernel-source-2.6.27.39
$ tar xfj linux-2.6.27.tar.bz2
$ for f in patches.*.tar.bz2; do
tar xfj $f || break;
done
$ for p in $(./guards x86_64 < series.conf); do
patch -d linux-2.6.27 -p1 < $p || break
done
$ 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-2.6.27.39/linux-2.6.27 ./mkbuildtree x86_64
$ make -C /usr/src/kernel-source-2.6.27.39/linux-2.6.27 M=$PWD modules
$ sudo make -C /usr/src/kernel-source-2.6.27.39/linux-2.6.27 M=$PWD modules_install

mono-2.4.2.3 debs will include array comparison patch

Originally published at The Pædantic Programmer. Please leave any comments there.

Thanks to Marek being a superhero, we have isolated the changes necessary to fix the compiler from the 2.4.2.3 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.

In addition to this, Ivan has committed Ankit’s character case fix patch to Michael’s git repo.

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…

LOLs

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 martin@mfconsulting.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

SuSE / Novell, KDE / GNOME, gtk+ / qt, ximian / trolltech

For those of you who care, there's currently chaos in the community. SuSE users are grumbling about Novell's decision to make Ximian's users interface the "default" desktop.

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:

http://freedesktop.org/wiki/

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:

http://developer.gnome.org/doc/API/

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.

http://www.linuxtoday.com/it_management/2005111002326OPSSNV

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.

http://www.linuxtoday.com/news_story.php3?ltsn=2005-09-15-009-26-OP-GN-KE
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?