Saturday, June 10, 2006

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.

Saturday, June 03, 2006

Bitten by rsync

My tool of work is a Thinkpad X31, an impressive machine which still does its job after three years of extreme use. I've tried to install Linux on it several times, but I always end up dual booting on Windows: I'm not buying the Linux laptop experience.

Building GHC is an fairly complex process by itself, and setting the build process in Windows would probably be a nightmare. That's why I'm using a Linux box to build it. I make the modifications in my laptop and use Darcs to transfer them to the compilation box. Sounds ok.

Now, the annoying part is that I often have to correct a few things in the code to fix the ubiquitous compilation errors, and I do that directly on the server (emacs through SSH is awesome). Then I amend the patch and get it back in my laptop (amend-unpull-pull) which is a royal pain. It is even worse now that compilation times are huge (usually they aren't, but I'm working in some prim ops now and that requires almost full recompilation). I find that I'm coding in my laptop while the box is compiling, and once the amended patch compiles and is tested, I get a lot of conflicts with the current changes when pulling it back to my laptop.

So I seemingly have two options. Either 1) I do all the work in the server through SSH and Emacs, or 2) I do it all in my laptop. I'm not convinced by 1), and I have discarded Linux in my laptop and building GHC in Windows for 2).

This morning I came up with the idea of using rsync to enable 2). I can do all the work in my laptop, including correcting compile errors, and rsync helps me to get almost instant feedback (modulo GHC compilation times). The good thing of this is that I can avoid producing incorrect patches which I have to amend every time, and avoid the conflicts I get when pulling them back.

Well, so far the experiment has been a disaster. I wanted to go safe, so I took my time to read a few tutorials on rsync, the man page, set up a rsync server in my build box, carefully set the appropiate filters to synchronize only the appropiate extensions (hs,lhs,c,h,cmm..), exclude the _darcs directory and so on.... A few dry runs after and everything seems to be all right, so I jump and launch the actual thing.
ZAP! In a second I've lost two hours of work in my laptop because turns out I used rsync in the inverse direction, i.e. overwriting the files in my laptop with the files in the building box. And yes, dumb as I am I hadn't recorded those changes in a Darcs patch beforehand, and there is no way to restore them back.

I can redo that work in a few minutes, it's not a big deal, but right now I feel dumb and pissed!

UPDATE: I got it right at last, and now it is working beautifully. I've setup a two lines script allowing me to do the whole cycle edit -> compile -> edit ... from my side. Another handy trick for doing that was the ssh feature for sending a command remotely.