More on Gtk2Hs on Mac Os X

It turns out that the problem with Gtk2Hs was not related at all to GMP or OS X frameworks. The issue is related to ticket #957 and libraries not in the default search path. The problem is fixed by passing the flags '-L/opt/local/lib -I/opt/local/include' to ghc when compiling a Haskell module that uses Gtk2Hs. The right thing to do, copied from the MacPorts book, is to edit your ghc driver (mine lives at /usr/local/bin/ghc) and add these flags there:

Contents of my /usr/local/bin/ghc file:

GHCBIN="/usr/local/lib/ghc-6.7.20070328/ghc-6.7.20070328";
TOPDIROPT="-B/usr/local/lib/ghc-6.7.20070328";
# Mini-driver for GHC
exec $GHCBIN $TOPDIROPT ${1+"$@"} -L/opt/local/lib -I/opt/local/include

Gtk2Hs on Mac Os

It all started with the Omega Gameboy Emulator written in Haskell. I got interested by the optimization challenge, it's a cool project after all, even though Haskell is not the most appropriate choice of a language. As a matter of fact I've never been a low-level guy, a systems programmer, but this project had its allure. After having played with the Universal Machine VM this summer during the ICFP contest, I found that I could understand the code very quickly.

After a few days hacking on Omega (it turns out that of the two alternative implementations of the CPU, the fast one was half-coded only, so I wasted a lot of time trying to debug it until I found this out), I got the unstoppable desire of seeing the emulator in action. I had been trying to avoid this, because I knew that setting up Gtk2hs on my Mac Os X86 would be a nightmare, but I just couldn't let go.

So here go my findings. These apply to the current release of Gtk2Hs, that is 0.9.11. I installed gtk2 via MacPorts, and hand compiled Gtk2Hs.

First, home compiled versions of GHC won't work. Gtk2Hs itself will make and install fine, but the helloworld demo will die with a "bus error". GDB is pretty useless to debug the problem. But someone in #haskell told me that MacPorts GHC would work, though he didn't know why. I tested this and he was right. So I digged into the MacPort install script for GHC, and it seemingly has to do with treating GMP as a lib instead of as a framework.
So this is what I found. GHC has a section in the configure.ac file to look for a GMP framework and use that. MacPorts installs GMP as a lib, and since all MacPorts ports try and succeed in eating their own food, the GHC port includes a patch to teach the configure script to use their GMP lib, and ignore any framework.

I don't really understand how frameworks are supposed to work in Mac Os, so I don't know if this makes any sense at all, but now my home compiled GHC is able to compile Gtk2Hs and Haskell code using Gtk, and everything works. I guess it should be possible to manually apply the patch at the ghc port, but I haven't tested it; I did my changes by hand to my package.conf file.

UPDATE: The real fix is given in a later post

The ICFP contest has a winner!

And no, this year Haskell is not the language of choice :(

Don't miss the video of the presentation at ICFP, seriously cool stuff, at least if you can follow the geeky -rather academia- jokes. Only by watching it you'll find out which is the super-cool multinational company that has conquered both 1st and 3rd prize this year.

#haskell managed to have 5 teams among the first 50: Lazy Bottoms, DunComLooLump, Deus Ex Machina, Team Roflcopter, and the Int-E lone ranger team. Not too shabby, though nothing compared to previous successes. None of the winners this year used a high-level language.

By the way, a few weeks ago I made a video to showcase the ghci debugger which used the ICFP contest task as an example. Watch it!

Debugging in Haskell

Some few days ago, an innocent query sparkled a fiery discussion in the Haskell mailing list, this time about the virtues and vices of debugging.

At the time I did put up a quick survey page in the wiki about the various debugging options available in Haskell (including the ghci debugger, of course!), but I didn't think about mentioning it here. A partial rip-off of that page follows.

Printf and friends
The simplest approach is to use Debug.Trace.trace:

trace :: String -> a -> a

When called, trace outputs the string in its first argument, before returning the second argument as its result.

A common idiom to trace a function is:

myfun a b | trace ("myfun " ++ show a ++ " " ++ show b) False = undefined
myfun a b = ...

The advantage is that disabling and enabling the trace takes only one line comment.
You must keep in mind that due to lazy evaluation your traces will only print if the value they wrap is ever demanded.

A more powerful alternative for this approach is Hood. Even if it hasn't been updated in some time, Hood works perfectly with the current ghc distribution. Even more, Hugs has it already integrated, see the manual page. Add an import Observe and start inserting observations in your code.
For instance:

import Hugs.Observe

f'  = observe "Informative name for f" f
f x = if odd x then x*2 else 0

And then in hugs:

Main> map f' [1..5]
[2,0,6,0,10]

>>>>>>> Observations <<<<<<> 10
, \ 4  -> 0
, \ 3  -> 6
, \ 2  -> 0
, \ 1  -> 2
}

The evaluation outputs a report of all the invocations of f and their result.

I have a handy bogus Hugs.Observe module with no-ops for the observations so that I don't need to remove them manually, expecting that the compiler will optimize them away.

Dynamic breakpoints in GHCi
Finally, the GHCi Debugger project aims to bring dynamic breakpoints and intermediate values observation to GHCi in a near future. Right now the tool is only available from the site as a modified version of GHC, so unfortunately you will have to compile it yourself if you want to have it.

This tool allows to set breakpoints in your code, directly from the GHCi command prompt. An example session:

*main:Main> :break add Main 2
Breakpoint set at (2,15)
*main:Main> qsort [10,9..1]
Local bindings in scope:
x :: a, xs :: [a], left :: [a], right :: [a]

qsort2.hs:2:15-46> :sprint x
x = _
qsort2.hs:2:15-46> x
This is an untyped, unevaluated computation. You can use seq to
force its evaluation and then :print to recover its type
qsort2.hs:2:15-46> seq x ()
()
qsort2.hs:2:15-46> :p x
x - 10

Once a breakpoint is hit, you can explore the bindings in scope, as well as to evaluate any haskell expression, as you would do in a normal GHCi prompt. The ':print' command can be very useful to explore the lazyness of your code.

SoC demographic stats

The Google people have published some numbers about this year Summer of Code.

I am still jaws open. Haskell.org is ranking above organizations such as The Mozilla Foundation, Eclipse or Ruby Central !!

How would you interpret this?
Could it perhaps be an indication that Haskell and FP in general is starting to become more popular among the masses, at least young masses?
Or could it just mean that Haskell.org project proposals were terrific -they were, imho- and attracted a lot of minds?

In one way or another it is awesome, and I am really thankful to all the people in Google and in Haskell.org who have made this possible.

Short Update

In the style of a fellow Summer Haskeller I enumerate below my current headache sources.

• C-- I got two prim ops implemented in GHC, one is for retrieving the info table pointer of a closure and another to retrieve the payload. All in all, C-- coding withouth knowing C--
• Dealing with Pointers I've been reading the code from FPS to get a better idea of how to work with this kind of stuff. The payload of a closure is retrieved as a tuple consisting of an array of pointers (to other closures) and a bytearray. Skimming through the FPS code (now called Data.ByteString) helped me a lot and now I got the bytearray side of the tuple sorted.
• Debugging the beast Maybe in an exercise of naivety, I hoped to be able to complete the project withouth resorting to gdb. After all, it debugging the beast is well known to be scary. The current situation is that if well the bytearray thing is working, I cannot say the same about the array of closure pointers. All I got for now are segfaults and no clue.

If you want to know a bit more about what exactly I am working on, follow this discussion in the Glasgow Haskell Mailing List.

On a side note, Simon Marlow has set up a Darcs repository at darcs.haskell.org for the nine of us. I haven't still given it a thought, but probably I will have to branch the entire GHC repo in there. I'm not sure if that's the right thing to do.