Debian packages commonly use or dependencies of the form “a | b” to mean that a or b should be installed, while preferring option a over b. In general, for resolving an or dependency, we will try all options from the left to the right, preferring the left-most option. We also prefer real packages over virtual ones. If one of the alternatives is already installed we use that. def solve_or(or): best_real = None best_virtual = None for dep in or: for target in dep: if target.name == dep.name and best_real is None: best_real = target if target.name != dep.name and best_virtual is None: best_virtual = target if target.is_installed(): return target return best_real if best_real is not None else best_virtual Now, this way of solving dependencies is slightly problematic. Let us consider a package that depends on: a | b, b. APT will likely choose to install ‘a’ to satisfy the first dependency and ‘b’ to satisfy the second. I currently have draft code around for a future version of APT that will cause it to later on revert unneeded changes, which means that APT will then only install ‘b’. This result closely matches the CUDF solvers and cupt’s solver. ... Read more 》

In the past days, I looked at various memory allocators in a quest to improve performance in my multi-threaded test cases of a reference counting language runtime / object allocator (a fun project). It turns out the glibc’s memory allocator is relatively slow, especially if you do loops that create one element and destroy one element at the same time (for example, map() on a list you no longer use after you passed it to map). To fix this problem, I considered various options. ... Read more 》

One thing I thought about today is reference counting in combination with tail calls. Imagine a function like this: function f(x) { return g(x+1); } Now consider that x is a reference counted object and that x + 1 creates a new object. The call to g(x + 1) shall be in tail call position. In most reference counted languages, the reference to an argument is owned by the caller. That is, f() owns the reference to x + 1. In that case, the call to g() would no longer be in a tail call position, as we still have to decrease the reference count after g() exits. ... Read more 》

In the language introduced yesterday, mutable parameters play the important role of representing the side effects of actions in the type system and thus ensure referential transparency. One of the questions currently unaddressed is how to handle currying in the presence of mutable parameters. In order to visualise this problem, consider a function printLn(mutable IO, String line) If we bind the the first parameter, what should be the type of the function, and especially important how do we get back the mutable parameter? Consider the partially applied form printLn1: ... Read more 》

Just for you, and this time in the Pythonesque rendering. module main: import std (range) import std.io (printf, IO) # print the Fahrenheit-Celcius table for fahr = 0, 20, ..., 300 function main(mutable IO io): Int lower = 0 # lower bound Int upper = 300 # upper bound Int step = 20 # step for Int fahr in range(lower, upper, step): Double celcius = 5 * (fahr - 32) / 9 std.io.printf(io, "%3d\t%6.1f\n", fahr, celcius) It does not really look like it, but this language is purely functional. It represents side effects using unique types. If you declare a mutable parameter, you basically declare a unique input parameter and a unique output parameter. ... Read more 》

Just for you: module main { import std (range); import std.io (printf, IO); /* print the Fahrenheit-Celcius table for fahr = 0, 20, ..., 300 */ function main(mutable IO io) { Int lower = 0; // lower bound Int upper = 300; // upper bound Int step = 20; // step for (Int fahr in range(lower, upper, step)) { Double celcius = 5 * (fahr - 32) / 9; std.io.printf(io, "%3d\t%6.1f\n", fahr, celcius); } } } It does not really look like it, but this language is purely functional. It represents side effects using unique types. If you declare a mutable parameter, you basically declare a unique input parameter and a unique output parameter. ... Read more 》

I have just released version 0.2 RC1 of my hardlink program. Compared to the 0.1.X series, the program has been rewritten in C, as Python was to memory-hungry for people with millions of files. The new program uses almost the same algorithm and has almost completely the same bugs as the old version. The code should be portable to all UNIX-like platforms supporting nftw(). I have tested the code on Debian, FreeBSD 9, and Minix 3.2. For storing path names, it uses a flexible array member on C99 compilers, a zero-length-array on GNU compilers, and a array of length 1 on all other compilers (which should work everywhere as far as I heard). ... Read more 》

Over the last years, I have developed a variety of metapackages for managing the package selections of the systems I administrate. The meta packages are organized like this: jak-standard Standard packages for all systems jak-desktop Standard packages for all desktop systems (GNOME 3 if possible, otherwise GNOME 2) jak-printing Print support jak-devel Development packages jak-machine-<X> The meta package defining the computer X Each computer has a jak-machine-X package installed. This package is marked as manually installed, all other packages are marked as automatically installed. ... Read more 》

Just because Julien did it, I moved my website to almost the same design now. Still using ikiwiki, of course. I’m still missing a few things, such as marking the currently active page in the menu, but I hope to get that done as well soon. Go to http://jak-linux.org/ to see it.

If someone in Germany (or want to send it to Germany [at low costs]) still has (new) Touchpads to sell, I’d buy one or two of them at the reduced price (16GB: 99€, 32GB: 129€), or take them for free. I promise that I will not sell them to others. I’m interested in WebOS, in running Debian and/or Ubuntu on those devices (for the extra fun factor), and lend it to family members for surfing, etc. ... Read more 》