A friend of mine is interested in trying out the
Automatic Rule Based Time-Tracker arbtt which I programmed. Unfortunately, he is using Windows and up to now, arbtt only worked on Linux. But as I wanted to check out Haskell s cross-platform abilities for a while, this was a good opportunity to do so. I don t have Windows installed myself (and did not plan to do so), so I did all this under
WINE, the Windows compatibility layer, which works very well: It takes only a few minutes to install the
Haskell Platform for Windows and then I was able to run
wine ghc --make and
cabal install.
I played around with some simple programs and was surprised by these timings:
$ rm *.o *.hi; ghc --make fourfours.hs ; time ./fourfours > /dev/null
[1 of 1] Compiling Main ( fourfours.hs, fourfours.o )
Linking fourfours ...
real 0m1.909s
user 0m1.692s
sys 0m0.208s
$ rm *.o *.hi; wine ghc --make fourfours.hs ; time wine ./fourfours.exe > /dev/null
[1 of 1] Compiling Main ( fourfours.hs, fourfours.o )
Linking fourfours.exe ...
real 0m1.631s
user 0m1.376s
sys 0m0.092s
So it is faster to run a compiled Haskell program on top of a compatibility layer than directly on Linux! The world is in order again, though, if optimization is enabled:
$ rm *.o *.hi; ghc -O --make fourfours.hs ; time ./fourfours > /dev/null
[1 of 1] Compiling Main ( fourfours.hs, fourfours.o )
Linking fourfours ...
real 0m0.981s
user 0m0.876s
sys 0m0.108s
$ rm *.o *.hi; wine ghc -O --make fourfours.hs ; time wine ./fourfours.exe > /dev/null
[1 of 1] Compiling Main ( fourfours.hs, fourfours.o )
Linking fourfours.exe ...
real 0m1.270s
user 0m1.036s
sys 0m0.072s
Funny. Anyways, I wanted to port arbtt. The only platform-dependent part is the capture module that gathers the list of open Windows. The
Win32 package that comes with the Haskell Platform did not cover all the functions needed to do so, but creating additional function bindings is really easy with Haskell, as can be seen in the
Graphics.Win32.Window.Extra module. I also replaced the locking code that prevents two instances of
arbtt-capture to run at the same time by equivalent code using Windows mutexes (module
System.Win32.Mutex). With these small changes and some CPP conditionals to make the code compile for either platform, the porting was done! Even accessing the files in
~/.arbtt works correctly on Windows, where it will look in the Application Data folder, without changing the code, thanks to
System.Directory.getAppUserDataDirectory.
But Windows users won t like compiling software on their own. They won t even like installing software by copying various files to certain directories. Therefore, I also had to create a Windows Installer. I picked
Inno Setup, because it s Free Software and seems to be simpler than NSIS. The installer puts the compiled
.exe files, the example
categorize.cfg and the HTML documentation in the right spot, adds icons to the Start Menu ( Edit categorize.cfg , which fires up wordpad, a link to the documentation and the uninstaller), puts
arbtt-capture in the Autorun folder, puts the path to
arbtt-stats in the
PATH variable and starts
arbtt-capture at the end (the last three points being optional). Of course it undoes all this when removing the program again. I integrated the call to the Inno Setup installer into the usual ./
Setup build process of Haskell packages. Some more details of how to create the Windows installer are mentioned in the
README file.
Now all this does not magically add a graphical user interface to arbtt, so users will still have to work with
arbtt-stats on the command line even on Windows. If this is not a problem for you then you can fetch the latest installer from
the arbtt homepage. And if you happen to become a serious user of arbtt on Windows and want to help maintaining the Windows port, I ll gladly share some responsibilities.
I m very satisfied with the process and the result and I m happy to
know that I can offer some of my programs also to Windows users in the
future.It is also a big plus for Haskell with Python, shipping a program for Windows users is likely more difficult. The next step will be providing gtk-based graphical Haskell applications for Windows, including a nice installer that ideally includes all dependencies (gtk etc.).
Over the past weeks, a couple of contributors sent me fixes and new features for forked-daapd. Thanks to you all!
The biggest change is the addition of TV shows metadata as found, for instance, in TV shows bought on the iTunes store. Together with the added support for FrontRow and QuickTime clients, this means forked-daapd is a lot more able at streaming video files than it ever was. Kudos to Ace Jones for his work!
Note, however, that you ll need a patched version of ffmpeg to pick up the TV shows metadata from your MP4 files. At the time of writing, the patches have not landed into ffmpeg upstream yet, and it s a bit unclear when this will happen. Contact Ace for the patch and instructions, see the commits in the git tree for his email address.
Git tree on Alioth: http://git.debian.org/?p=users/jblache/forked-daapd.git (git URIs on the page)
Somehow, I'm still lacking the optimal media player application. Many popular
ones are totally overloaded (e.g. amarok). Others like totem seems to be just
a minimalistic frontend for a particular backend.My current choice:
Being stuck at home because of my stepfather's health condition
becoming worse and therefore family meeting plans being changed, I just made the Debian project a small Christmas gift
by 
When being told about the differences between Puppet and Chef
by Puppet fans, a few common talking points emerged. They
included the terms DSL , declarative , and shell script .
Shell script was probably the most entertaining meme, and
referred to how, without dependencies, Chef was just like
writing shell scripts in Ruby.
In actuality, a Chef cookbook appears to be roughly 17 files
in 7 different directories. Most of them end in .rb, but
there is also a metadata.json to keep the metadata.rb company,
and perhaps an .rdoc if you like that sort of thing.
I have no idea who writes shell scripts this way. I am also
stupefied that people say this is easier than Puppet, because
I doubt I would want to perform system administration by
writing one of these things.
So when I started writing my own thing, I contemplated the
dependency issue, and for a few minutes decided to be lazy
and leave them out entirely. Once it dawned on me, however,
that I was then writing shell scripts in Lua, I became ashamed.
If I were going to go that route, why not just set up a git
repository with a bunch of shell scripts, and set up cronjobs
on each of the clients to do a git pull and run these shell
scripts as root? After all, nothing beats shell scripting
for shell scripting, not Perl, not Python, not Ruby, and least
of all Lua.
So I wrote a dependency resolver. It was easier than I had
anticipated and I have vague plans to make it smarter than
Puppet's. Then I'm justified in sticking to my Lua DSL .
Now 
It was interesting to see Clint Adams 
Contained in the recent billionth-spam report from 
There was a minor hiccup yesterday. Our mortgage broker called me up towards
the end of the day in a flap because something had gone wrong on the
seller's side of things, and their bank hadn't accepted the
transaction or something. I still don't know the full story. Something about
them missing a mortgage payment possibly.
Anyway, she was able to arrange for funding and closing today, instead of
funding yesterday and closing today, so the outcome was still the same.
Now the real fun starts.
The first thing I did tonight was program the garage door opener into the
Prius' 
Another small update to
I've recently been fixing up my 
