therning.org/ magnus

If George ever decides to make even more money off Star Wars then he should release a remix of the existing films based on this story.

First of all I decided to make this a new post rather then answer in the comment section in my previous post. I think that this way the chance is greater that both David and Jeremy will read this

So, first let’s set the stage… It’s almost midnight and I’ve just spent somewhere between 30 and 45 minutes hunting down packages on Haskell and navigating the directory listings on src.seereason.com. I’ve been sent in the wrong direction once (downloading a Debian package that seems to be from Linspire instead of grabbing the identically named package from the seereason site. I’m tired and slightly frustrated. I run cabal-debian, it works, then I run debuild just to be told that I really should have build cabal-debian itself into a Debian package and installed it that way and I also need another package that isn’t in Debian at all.

Anyway, having slept and let almost 24 pass by I’ve come to my senses somewhat

Here’s what think is a slightly more tempered whishlist:

1. Remove haskell-devscripts-cdbs and include hlibrary.mk in haskell-devscripts.
2. Modify dh_haskell* so that the two snippets for -doc are automatically generated instead (just like the script snippets for -dev already are).

I think it would be easy to stick that in seereason’s repos for public consumption. Then interested people, like me, can start thinking about how to use that as a base to make Debian the best Haskell platform in the world, or at least making it better than Arch

Completely unrelated question for seereason people

I have the following line in my source.list:

deb     http://deb.seereason.com/debian sid-seereason main

Why don’t I see the seereason-keyring package?

So, after receiving several pointers to seereason’s cabal-debian tool I thought I’d take it for a spin.ⁱ

After about 30 minutes of browsing through HackageDB and seereason’s source repos, building and installing, I had finally satisfied all dependencies and the build of cabal-debian succeeded. (Oh, BTW, seereason people, it’s really confusing that you have a package called debian among your source repos, when there already is a different debian package on HackageDB. Please consider renaming it!) I decided to take the tool for a spin on my own package, dataenc.

The result was fairly good. It seems the generated files depend on some packages that either aren’t in Debian or that the people at seereason have modified. With the following changes to the generated files I was happy with the contents of ./debian and I successfully built an (almost) autogenerated Debian package:

1. Download hlibrary.mk into ./debian.
2. Modify ./debian/rules so that hlibrary.mk is loaded from $(CURDIR)/debian/hlibrary.mk.
3. Delete ./debian/libghc6-dataenc-doc.post*.
4. Remove cabal-debian and haskell-devscripts-cdbs from the build dependencies in ./debian/control.

I’ll try to find the time to put those changes into cabal-debian itself. Then I’d have a rather nice tool for building Debian packages automatically.

1. I did pull down autobuilder as well, but didn’t feel I had enough time to explore it tonight.[back]

I’ve just spent the last hour or so ironing out the details required to automate the building of cabalised Haskell packages for Debian. At the same time I also built Debian packages for 5 Haskell packages (test-framework and its dependencies).

These are the basic steps I’ve followed:

1. Extract the tar-ball in the working directory.
2. Rename the directory to match the form haskell-X-0.1.
3. Re-tar the directory into an archive named haskell-X_0.1.orig.tar.gz.
4. Change into the package directory.
5. Run Cabal’s configure command followed by register --gen-pkg-conf=pkg.conf.

6. Modify the generated file and turn it into a .ini-style file:

   echo '[conf]' > pkg.conf.tmp; cat pkg.conf >> pkg.conf.tmp; mv pkg.conf.tmp pkg.conf
   

7. Use Python to extract the dependencies:

   python << EOF
   from ConfigParser import ConfigParser
   cfg = ConfigParser()
   cfg.read('pkg.conf')
   deps = cfg.get('conf', 'depends').split()
   for d in map(lambda s: s.rsplit('-', 1)[0].lower(), deps):
       print d
   EOF
   

8. Clean up by rm pkg.conf and running Cabal’s clean command.

9. Create the debian directory.
10. Create debian/compat: echo 5 > debian/compat

11. Create debian/changelog, it should be something like:

    haskell-X (0.1-1) unstable; urgency=low
    
      * Automatic build.
    
     -- Magnus Therning <magnus@therning.org>  Mon, 19 Jan 2009 22:35:00 +0000
    

12. Create debian/control. This is by far the most time consuming part to do manually. It’s also a bit long so I’ll leave it out of this post. Take a look in my APT repo if you are interested in the details.

13. Copy hlibrary.mk into debian/. At some point it will be included in some Debian package (bug #462482) but for now it can be found here.

14. Create debian/rules with

    #!/usr/bin/make -f
    include $(CURDIR)/debian/hlibrary.mk
    

    and make it executable, chmod +x debian/rules.

15. Done. Run debuild.

My intention is to at some point encode these steps in a tool so that I can spew out Debian packages for all interesting packages on HackageDB at the press of a button. Of course that tool will be written in Haskell, and it sure won’t rely on Python for any part of the process

Readers who are familiar with the rules for Debian packages will notice that this won’t create well-formed packages. i’m not particularly interested in getting these packages into Debian proper, I see the package generated this way living in an unofficial repo. So there is no need to make sure they are acceptable for inclusion in the distribution itself. The resulting packages might offer a good starting point for someone who feels that a package deserves to become official. I also suspect that a tool that generates fully compliant packages, and is able to deal with keeping them up-to-date, is too big a task for me. I’m also not sure it really is worth it, better to keep things as simple as possible in order to deal with the amazing rate of new releases on Hackage.

It’s strange but Ubuntu cola seems to be more mainstream in Sweden than in the UK. My brother found it in downtown Gothenburg, in a branch of a major chain of grocery stores. On the other hand, I haven’t seen it anywhere in the UK until yesterday. I found it in a fairtrade store in a tiny village outside Cambridge. A little strange since Ubuntu Trading is a UK company.

I’ve been using both QuickCheck and HUnit to make sure that the functions in dataenc both have the expected properties and follow the specifications.

This morning I stumbled on a series of posts by Matthew Podwysocki on Functional Programming Unit Testing (part 1, part 2, part 3, part 4, part). I think I really could have used these posts about two years ago when I first ventured into the world of testing Haskell. The only new thing I learnt was the existance of the package test-framwork in parth three. Anyway, they are a good introduction to testing Haskell code (and F#).

I found test-framework today. In adopting it with my already existing unit tests I found this function to be rather useful:

import Test.HUnit
import qualified Test.Framework.Providers.API as TFAPI
 
unitTest2TFTest :: Test -> [TFAPI.Test]
unitTest2TFTest t = let
        unitTest2TFTest' desc (TestCase a) = [testCase desc a]
        unitTest2TFTest' desc (TestLabel s t) = unitTest2TFTest' (desc ++ ":" ++ s) t
        unitTest2TFTest' desc (TestList ts) = concat $ map (unitTest2TFTest' desc) ts
    in unitTest2TFTest' "" t

Yesterday I implemented yEncoding in dataenc and uploaded version 0.12 to HackageDB.

Today I started the day by watching some Swedish telly, Gomorron Sverige I think the show was called. Three guests got to comment on the news year that just passed. They were asked for their nominations in categories such as Most Over-Reported News Story, Most Important Public Figure and the like. One of them nominated climate change for the category Most Under-Reported News Story. Immediately one of the others blurted out that he thinks that climate change is exaggerated and has received too much attention in media. He was told that there now is proof that large portions of the polar ice has melted (25% was mentioned, though I didn’t catch whether it was an increase of 25% or if 25% was gone, anyway, it doesn’t really matter here) and that therefore this is a very real problem. In answer to this the climate-change doubter mentioned that he has been keeping an eye on the water level at the pier near his summer place and there has been no change over the years. So, if climate change is real and the polar ice is melting, where does the water go? My initial reaction against this line of ressoning seems to have been shared by the person who initially brought up the subject, “How could he argue against climate change? And with such a simplistic argument as well?” Then I was disappointed to hear that the only counter argument basically boiled down to “But, it doesn’t work that way” and “How can you argue against all the scientists?” First I was disappointed in her for not providing any answers, then I grew more disappointed in myself as I realised that had I been sitting next to this climate-change doubter myself at a dinner I wouldn’t hve been able to provide a stronger argument myself.

How should a counter-argument be constructed? What scientific ideas and proofs should be used to point out the fallacy of the “pier argument”?

I can think of these:

• There is evidence of climate change on a macro level, his argument doesn’t explain those away. All he’s really saying is that on a micro level, and in a very specific geographical location, measuring only the water level, he can’t find any evidence for climate change.
• It’s probably also simple to point out the lack of scientific rigor in his methods. Somehow though, I feel this is a bad way to try to convince anyone.