Jarnography

Google lähetti postia:

Ehkä yömyöhä-sivulla ei ole konkreettista tai hyödyllistä tietoa, sen hyväksyn. Tuota "mainoksessasi"-kohtaa en ymmärrä, ei minulla mitään omia mainoksia ole.

Pitäkää tunkkinne, sanon minä :) Täytyy nyt vaan koittaa pärjätä ilman mainostuloja - ai niin, eihän niistä ole vielä senttiäkään tilille tullut.

I wanted to update the Haskell development environment on my work computer, especially after I found out I didn't have one after upgrading to Snow Leopard. I proceeded to install Haskell Platform, which I had already installed on my home computer with great difficulties. This time it installed fine, they have a binary installation package for OS X on Intel, but the problems started only after that.

I tried to build happstack-tutorial with Cabal, but it failed with gcc complaining about missing cc1. Quickly looking at the directory there indeed was no cc1. After a slight misstep of accidentally installing older XCode on top of the new one, losing for example /dev/null in the process, having to reboot and reinstall XCode, I figured out something more about the cause.

With a bit of googling I found out about gcc --print-search-dirs. Gcc thought its installation directory was /usr/lib/gcc/i686-apple-darwin9/4.2.1/, which unfortunately did not exist, it should have had darwin10 there. A bit more googling showed me the light: I had some /Developer directories in the path. Getting rid of those got me forward, trying cabal again. And failing.

Now I got errors like "CPU you selected does not support x86-64 instruction set." Great. Still more googling, found out it was a bug in GHC. Of course the fix was not yet in the GHC that came with Haskell Platform. Fine, I installed the latest and greatest GHC. Trying cabal again. And failing.

This time: "cabal: failed to parse output of 'ghc-pkg dump'". It was mentioned on the ghc page that it only works with Cabal-install version 0.8 or later, I had 0.6.2 from Haskell Platform. I should have updated it first, but I couldn't because ghc didn't work. Chicken and egg.

So I had to get new cabal-install from somewhere. Cabal home page had the same 0.6.2 version I already had. Use the source, then. Cabal-install source package came with bootstrap.sh, which failed because my cabal library was too old.

I got the latest cabal source, ran ghc --make Setup, got "ld: can't write output file: Setup". Ran it again, this time it worked and produced Setup executable. I did what man's got to do, and surprisingly enough there were no errors.

Back to compiling cabal-install. With the new cabal library it compiled just fine. Backtracking further to where I started, happstack-tutorial. That didn't compile as fine:

Building containers-0.2.0.1...

Data/IntMap.hs:182:7:
    Could not find module `Data.Data':
      It is a member of the hidden package `base'.
      Perhaps you need to add `base' to the build-depends in your .cabal file.
      Use -v to see a list of the files searched for.

I gave up with that for now and tried to cabal install happstack. Naturally that failed too: "ghc: could not execute: trhsx". More googling, added ~/.cabal/bin in the path. Now happstack install succeeded.

Maybe I'll continue with happstack-tutorial some other day...

Today's Linux administration puzzler: Why do the files in home directories mounted from another server belong to nobody?

First I looked at /var/log/messages to find out if there were any messages that might be related. There were indeed:

Jan 12 10:43:02 xxx rpc.idmapd[4383]: nss_getpwnam: name 'xxx@localdomain' does not map into domain 'local.domain.edu'

After a bit of grepping I found out that there was a wrong domain ('local.domain.edu') defined in /etc/idmapd.conf. Fixed. Restarted rpc.idmapd. Helped one user, didn't help me. My home directory was still all nobody. I logged out and logged back in, didn't help. I su'd to root, checked out /var/log/messages again, but there was nothing relevant any more.

I looked at my home directory once more and now the files were suddenly in my ownership. I don't know why it took a while, but the issue seems to be fixed now.

After a long time away, I've returned in the area of manual memory management. The reference counting model in Apple's frameworks is pretty nice and easy, but of course not as easy as automatic garbage collection would be.

I got a reminder yesterday, when I used a tool to check if it finds any memory leaks in my program. Indeed it found one place where I had forgot to release an object. That was easy to fix, but fixing that one revealed another bug. In a related code I released an object twice, which happened to be one time too much, causing a crash elsewhere. One bug hid another.

There has been a couple of occasions before where I tried to use a deallocated object, but those have surfaced immediately. I still consider myself lucky (or maybe just good?) in that I haven't run into any more problems with memory management in this project.

I like the way how 37signals does business: providing simple products with little staff and lots of paying customers, making revenue and profit. I especially admire their ability to get so much positive publicity.

http://37signals.com/podcast