shimweasel

btw, all this hacking was brought to you from an extremely elegant hotel room in NY. Wish I'd brought a real camera rather than having to angle my laptop awkwardly and run PhotoBooth.

For those of you who've been following along, in our last episode, we'd _almost_ managed to build GHC HEAD on Mac. Since that time, the rts_builtin bug has been fixed, and GHC will now install cleanly. There are still a few nasty shims to add in before Hubris will do what you want, however. (I'm going to assume you're up to date with the awful hacks from the last post: let me know if they need expansion)

UPDATE: this looks to not be entirely necessary - I can leave the rpath parameter out and the code still links now. I'm leaving this in as a reminder if I hit the problem again. First, the -rpath argument to ld on Mac needs some special Leopard loving: anything less than 10.5 is insufficient. ticket is here

second, ghc HEAD installs its libraries in /usr/local/lib/ghc-$VERSION/, then expects to see them in /usr/local/lib. There might be a cleaner way of fixing it, but for the moment,

ln -sf /usr/local/lib/ghc-6.11.20090915/*.dylib /usr/local/lib

will do the trick. (Yes, I _do_ love that green on black text, thanks for asking.)

And, just to show I'm not completely full of it, in classic "Works On My Machine(tm)" style:

11:53 ~/projects/HubrisBuild % uname -srv
Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386
11:53 ~/projects/HubrisBuild % irb 
irb(main):001:0> require 'lib/hubris'
mkdir: /Users/mwotton/.hubris_cache: File exists
creating Makefile
=> true
irb(main):002:0> class Foo
irb(main):003:1> include Hubris
irb(main):004:1> end
=> Foo
irb(main):005:0> f=Foo.new
=> #
irb(main):006:0> f.inline("foo (T_FIXNUM n) = T_FIXNUM (sum [1..n])", { :no_strict => true })
=> true
irb(main):007:0> f.foo(10)
=> 55
irb(main):008:0> 

Patches to the github repo will be up as soon as i've cleaned them up.

Mac OS X needed a bit of love to get GHC HEAD to build on it, but it does seem possible. The secret sauce: first, apply this patch It's not very polished and almost certainly breaks the Linux build, but it'll work ok for Mac. Then, create a file "build.mk" in the root ghc directory, with the content

SplitObjs=NO
GhcLibWays=v dyn

finally, GMP seems to resent being ignored: it needs a special flag passed to GCC, namely -read_only_relocs suppress. I assume there's a good way to tell GHC to use the flag: I cheated, and used make -v to get the gcc line that was failing, copy-pasted it and added the flags. Inelegant, but it seemed to work. Anyway, this is as far as i've got so far - the make step works, but then 'make install' complains about the package 'rts' not having an 'inplace' suffix. Bizarre, but I'll keep digging.

So, Hubris has got to be a bit more of a serious tool since the last time I posted about it. In preparation for a talk at RORO Sydney, I've been hacking madly, and now have full support for all of the basic types but hashes and works with GHC HEAD (JHC crashes for arrays at the moment, as I'm monstrously abusing unsafePerformIO).

To steal from one of my RSpec tests, it can be used from Ruby like this:

  it "returns a haskell list as  an array" do
    t=Target.new
    t.inline("elts (T_FIXNUM i) = T_ARRAY $ map T_FIXNUM $ take i [1..]
elts _ = T_NIL" )
    t.elts(5).should eql([1,2,3,4,5])
    t.elts("A Banana").should eql(nil)
  end

The interface could be cleaned up a bit: currently, everything has to be marshalled into a Ruby value(whether that's an array, hash or primitive type.) It'd be nice not to have to use the T_FIXNUM wrapper to indicate the type of the Haskell function - using ghc-src-exts, I could discover the type of the underlying function and wrap it automatically. Next release, perhaps. Anyway, this all only works on Linux for the moment, as GHC's support for dynamic libraries on Mac has bitrotted a bit. While Duncan Coutt's got the Linux side running sweetly, Daniel Peebles is currently having a look at the dynlib support on Mac, and I'm going to try to help out in whatever limited way I can - with any luck it'll all be ready for 6.12, which is coming out Real Soon Now and is full of tasty treats like ThreadScope.

Under the hood, it's actually pretty simple. Once you have dynamic library support, it's reasonably easy to take a chunk of Haskell, collect the top-level identifiers, wrap them for access from C-land, and compile a library. Likewise, accessing dynamic libraries from Ruby is very old news indeed. There's a lot of plumbing involved, working out exactly what flags various tools need to build the libraries correctly, but you never see that it in operation: it's software that just disappears into the background.

Anyway, check it out, see what you think. Collaborators are always welcome, and there's still a heap of things to do.