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

If I had time

Projects I would work on if I had a bit more time.

• An improved way to handle exceptions for Haskell I have half-thought. More on this soon
• review hs-plugins and get it to work on the Mac
• A Dashboard widget for the awesome Lambdabot
  
• Read all those papers I want to read (sic)
• Finally get the mutable engine in the Omega Gameboy emulator to work, after all the time I have invested already (should put a Darcs repo up). Then the fun begins: profile and optimize extensively
• Blog more
• Get a website for myself
• Definitely... read GTD and start getting things off this list

Projects I will work on as soon as I get the time.

• The ghc 6.7 branch of Shim: Integrating the debugger. I have already some code but I'm waiting for soon-to-come changes in the debugging primitives in the ghc-api
• Send patches for the GHCi debugger... bugfixes, new bugs, new commands, experiments, etc.
  

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

www.songmeanings.net

What is better than procrastinating and listening to music at the same time? You got it: procrastinating about music.

This is a short entry to comment on said site. I just stomped on it, surprisingly via google. Yes, I didn't use any of the flashy diggit-readit-web-2.0-cool-sites-that-talk-about-sites-or-blogs... So, I have spent the whole evening procrastinating around its contents. And how we love these things... There is another thing we people love (apart from Of Montreal's Hissing Fauna album of course), and that is silly statistics, the sillier the merrier. Or look at Last.fm success (disclaimer: I love this sort of things too)

Before finding it I didn't know how addicted I was to song commenting!
After all it makes a lot of sense; people comment on albums, movies, shows, and personal posts such as this one! (sadly this blog is mostly comment-less, so it is not a good example).

So thanks to my newfound addiction, I've spent all this time digging each and every comment on every song of my latest fetish album: Hissing Fauna by Of Montreal. It is an impressive album. It is always impressive when a band produces its masterpiece, but it is jawdropping when this masterpiece comes as what makes their 10th studio album. How not to love songmeanings.net when you find comments as reassuring as:

"Hissing Fauna, Are You the Destroyer?" is final, clinching proof that Kevin Barnes is totally crazy. And totally awesome.
(on Faberge Falls For Shuggie)

Other funny comments that you can find on the songs in Hissing Fauna:

Favorite song. It's ridonkulous.
(on Heimdalsgate Like a Promethean Curse)

By the way, it is definetely about drugs.
(on Heimdalsgate Like a Promethean Curse)

My mom flat out asked me what the hell this song was about, and I simply told her
"Someone who is having a chemical imbalance and wants to be in a good mood, this their chemical imbalance shifting."
It's kind of funny I should be able to sum it up in a few lines. It's such a deep song.
(on Heimdalsgate Like a Promethean Curse)

"the mousey girl screams violence, violence
the mousey girl screams violence
she gets hysterical
'cause they're both so mean
and it's my favorite scene
oh, the cruelty so predictable
makes you sad on the stage"

Reference to Edward Albee's play Who's Afriad of Virginia Woolf. Honey, the mousey character, does scream "Violence! Violence!" at a point in the play when George and Martha are at each others throats.
(on The Past Is A Grotesque Animal)

The last one is too clever for me, but I mean, I looove this kind of stuff. When I'm not punishing my brain with Haskell, I'm either procrastinating or listening to music. And lately often procrastinating about music.

Just received my Summer of Code T-shirt

Now I can brag around my Uni with it!

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.

Darcs is broken

Darcs is broken. I found it out the hard way yesterday, while I was trying to commit my patches to the main trunk of GHC.
Essentially, my patches were living in a separate branch. Of course the Darcs model does not need the concept of branches, as traditional SCMs do, but the analogy works fine here.
The debugger is complete just in time for the 6.6 GHC release, and we were planning to include it in the candidate release yesterday Monday.

But Darcs planned otherwise. While my patches were on a branch, I had been careful to keep this branch sync'ed to the main trunk. This means pulling patches from the main trunk once a week or so and fixing any conflicts with my code. Since my patches are spread around several subsystems in the compiler, conflicts have arisen three or four times during these three months.
It turns out that since the last sync with the main trunk I did around the 22nd of August, a new patch has been commited which conflicts with my work. But this time Darcs has decided against simply doing the merge and calling conflict. Instead, it will diverge exponentially and hang.

I have tried everything! I switched to Linux, to Windows, to older versions, I tried all sort of Darcs tricks... to no avail.

What is more embarrassing, it turns out that this is a well-known issue of Darcs, and looks like there is no hope for a solution in the near future.

So now what? The maintainers of the Ghc repo are aware of this Darcs issue, and they have sensibly requested me to avoid pushing patches with conflicts into the main repo. Which means I have to manually re-record all my patches, by hand (with help of diff/patch), into the main trunk. This could take me several evenings, and is boring as hell!
Of course I could record a One Big Patch, but that's a less desirable solution.

I wish I had known about this issue of Darcs before.
I wish Darcs patch theory wasn't so broken in the first place.

[posted with ecto]