Archive for January 2009
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:
dh_haskell*so that the two snippets for
-docare automatically generated instead (just like the script snippets for
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
deb http://deb.seereason.com/debian sid-seereason main
Why don’t I see the
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:
- Download hlibrary.mk into
hlibrary.mkis loaded from
haskell-devscripts-cdbsfrom the build dependencies in
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.
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:
- Extract the tar-ball in the working directory.
- Rename the directory to match the form
- Re-tar the directory into an archive named
- Change into the package directory.
- Run Cabal’s
configurecommand followed by
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
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).lower(), deps): print d EOF
Clean up by
rm pkg.confand running Cabal’s
- Create the
echo 5 > debian/compat
debian/changelog, it should be something like:
haskell-X (0.1-1) unstable; urgency=low * Automatic build. -- Magnus Therning <firstname.lastname@example.org> Mon, 19 Jan 2009 22:35:00 +0000
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.
debian/. At some point it will be included in some Debian package (bug #462482) but for now it can be found here.
#!/usr/bin/make -f include $(CURDIR)/debian/hlibrary.mk
and make it executable,
chmod +x debian/rules.
- Done. Run
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.
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
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.