This StackOverflow answer is a nice example of the problem:

$mondayStr = "last monday";
if (date('N') !== '1') {  // it's not Monday today
    $mondayStr .= " last week";
}

$monday = strtotime($mondayStr);
echo date('r', $monday);    // Mon, 22 Feb 2010 00:00:00 +1000

$sunday = $monday + 86400 * 7 - 1;
echo date('r', $sunday);    // Sun, 28 Feb 2010 23:59:59 +1000

The code seems logical. Get the timestamp of the last Monday, add 60 * 60 * 24 * 7 – 1 seconds and you have the end of Sunday. Works fine most of the time. Although, if the $monday happens to be Mon, 22 Mar 2010 00:00:00, the date that was supposed to be Sun, 28 Mar 2010 23:59:59 will actually be Mon, 29 Mar 2010 00:59:59. Why? Because 28 March 2010 has only 23 hours.

Never use timestamps to do calendar calculations. It’s hard to get it right. If you really have to, at least use GMT timestamps.

Changes since version 0.2:

• PDF export
• Support for printing
• Opening of files passed through the command line arguments (Bug #401595)
• The recently used files list now always uses absolute paths
• Implemented auto-scrolling in the diagram view (Bug #420324)
• The “Close” menu item will now only close the document, not the window (Bug #420322)
• Use the selected file format in the export dialog, instead of relying only on the extension (Bug #396056)

Cheap Branches

One of the main reason people use DVCS is cheap branching. The most surprising thing for me was that Mercurial doesn’t offer many choices. It doesn’t have the concept of branches, like Bazaar or Git. All you have is an immutable repository that can contain multiple head revisions. By default, you are expected to clone the whole repository. As I mentioned earlier, I tend to work with many feature branches, so I prefer to have just one working tree.

One way to partially solve this problem is the bookmarks extension. It basically allows you to have dynamic tags that move to new revisions as you commit. The initial configuration looks like this:

[extensions]
bookmarks =
[bookmarks]
track.current = True

The next step is to go to your clone and set the main/trunk/master/etc. bookmark:

hg bookmark main

This is necessary, so that you easily know which revisions represents the project’s “mainline”. With the configuration I mentioned, the extension will track your current bookmark and update only that one. To set the current bookmark, you can use update:

hg up -r main

It’s important to always have the current bookmark set to main whenever you are fetching changes from the mainline. Otherwise you will have to manually fix the bookmark’s revision.

Creating new “feature branches” is easy then:

hg bookmark -r main my-feature
hg up -r my-feature

One important thing to remember is that after you use this, the repository will contain multiple heads. This means you can’t use plain hg push to push changes to remote repositories. You always have to specify the revision, for example:

hg push -r main https://hg.example.com/projects/trunk

Merging

When it comes to merging, Mercurial doesn’t make your life easier at all. The default assumption is that visual merging is the preferred way to go. Maybe I’m just too stupid, but I don’t get visual merge tools. I just don’t know how to use them. I prefer merging changes manually in my text editor, after I see the changes for the whole project. Mercurial would start up the merge tool for each file linearly, which means you don’t have a global picture of impact on the project, when you are supposed to resolve a merge. I just can’t work that way.

Fortunately, Mercurial does have an internal three-way merge algorithm, that can leave conflict markers in the merged files and let me do my job. You can configure it this way:

[ui]
merge = internal:merge

This actually uses the merge code from Bazaar, so I expected I’ll be done quickly. There is one problem though. Instead of using patience diff, like Bazaar, it uses its own diff algorithm. The result is that in Bazaar the algorithm works just fine, in Mercurial it produces horrible results. That’s actually pretty funny, considering the fact that I used ideas from Mercurial’s diff code to implement the C version of patience diff in Bazaar.

Next step, the Mercurial wiki suggests diff3 as a possible non-interactive merge tool. There are no examples how to configure it, but something like this technically works:

[ui]
merge = diff3
[merge-tools]
diff3.args = -m $local $base $other > $output

In my experience, this produces even worse results than internal:merge, so there is no reason to use it.

The last idea was to use the merge program from RCS (yes, that’s right, using an ancient VCS to fix issues in a “modern” VCS). I must say that installing RCS in 2010 feels weird, but as long as I can get my job done… Once it was installed, I used this configuration:

[ui]
merge = merge

I was surprised that the results were acceptably good. Not perfect, but I knew I can’t expect more from a three-way merge. Ideally I’d like Bazaar’s merge algorithm with patience diff, but I probably won’t find time to port it, so merge will stay as my default merge tool for some time.

That’s only the first part of the problem though. Now you have files with conflict markers and you need to resolve them. Based on my experience with other version control systems, I assumed conflicts would be listed in hg status, but I was wrong. They are nicely hidden here:

hg resolve -l | grep '^U'

After manually resolving the conflicts, you can use the following command to mark the files as resolved:

hg resolve -m path/to/file

To be continued…

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L]

If the server then gets any HTTP request, it will redirect the client to the same URL, but with the https scheme. This means that actual requests will be only ever served via HTTPS.

Somebody asked a question about a Perl module a few days ago and based on reading the source code of the module, I gave them one possible way to solve the problem. Today, an author of multiple Perl books came in and very confidently claimed that my solution will never work. I explained him why he is wrong, but it didn’t help. The problem was that he failed to read the source code correctly and made incorrect assumptions based on that. I pointed him to specific parts of the code, still nothing. At that point I wanted to gave up, but later he came up with a broken example, which didn’t work for different reasons, that should show me why I’m wrong. Soon after that he realized what is wrong about the example, changed his answer and deleted all his old comments, as if they never happened.

The problem I see is not this specific case (I’ve seen far more of them, either on Stack Overflow or some IRC channels), but the fact that even average programmers write popular programming books. And people learn from these books. I guess the saying about teachers who failed to apply their knowledge in practice, which I can’t remember right now, applies even for book authors. What a wonderful world.

(I just needed to get this out of myself.)

I’m doing this on an Ubuntu laptop, so first I’ll need LaTeX:

sudo apt-get install texlive

Then download fithesis:

wget http://www.fi.muni.cz/~xpavlov/fithesis/install.sh
wget http://www.fi.muni.cz/~xpavlov/fithesis/fithesis-0.2.12.tar.gz
tar -zxvf fithesis-0.2.12.tar.gz
cd fithesis-0.2.12

Convert the sources to UTF-8 and change the package options in the file:

recode latin2..utf8 fithesis.dtx
sed -i 's/latin2/utf8/' fithesis.dtx

And now we can install it:

cd ..
chmod a+x install.sh
./install.sh 0.2.12 /usr/share

At this point you can use the package in your UTF-8 encoded LaTeX document.

swapoff /dev/vg_foo/lv_swap
lvextend -L+100M /dev/vg_foo/lv_swap
mkswap /dev/vg_foo/lv_swap
swapon /dev/vg_foo/lv_swap

That is: disable swapping on the volume, extend it, re-create the swap area and enable swapping again.

So I thought about switching to using my own URL as my OpenID, but I didn’t want to run my own provider server. OpenID supports delegation, so normally it would be a matter of adding two lines of HTML code to the header of this blog and I could use Google’s OpenID server with my own URL. The issue is with the way Google handles identities. The main URL https://www.google.com/accounts/o8/id is the same for everyone and Google will generate an unique OpenID for every combination of user and OpenID consumer. This is nice from privacy point of view, but it makes it impossible to use OpenID delegation, because in the delegation code I have to specify my OpenID. I can’t do that if my OpenID is different for every site I log in to.

I ended up with just adding this to the static HTML file I have on http://oxygene.sk/:

<meta http-equiv="X-XRDS-Location" content="https://www.google.com/accounts/o8/id" />

This means that every time I want to log in to an OpenID-enabled site, I can type in http://oxygene.sk/ and it will use the same Google’s OpenID as before. Not exactly what I wanted initially, but it’s better than having to remember the long URL.

QString represents an Unicode string. That is, an array of Unicode code-points. The issue is that on most UN*X platforms, filesystems are not aware of Unicode. File names are stored as an array of bytes. The filesystems don’t care how are the bytes interpreted, but if applications want to display non-ASCII characters properly, they need to decode the bytes into Unicode. Since the filesystem itself doesn’t know the encoding, it’s necessary to look for the information somewhere else.

The user’s locale is probably the first place to look. If the user uses some encoding for input/output, it’s expectable that they use the same encoding for file names. This doesn’t always have to be the case, so GNOME for example uses a special environment variable named G_FILENAME_ENCODING. The problem is that all these solutions work globally for all filesystems. What if the main filesystem uses UTF-8 for everything, but the media player on which I sometimes upload files from Windows uses a different encoding? There is no way to tell applications that it should use CP-1250 for /media/disk-1 and UTF-8 for everything else.

That’s not everything though. Seeing broken characters is not nice, but not a blocking problem either. What if the application can’t even read or write such files? That’s a much larger issue. If the application is using Unicode to store file names, but it can’t properly decode/decode the name, it won’t be able to access the file. The obvious solution is to ignore Unicode and just use byte arrays. This would work fine on UN*X, but new problems will show up if you are trying to write a cross-platform application. To be able to access all files on Windows, you have to do the exact opposite. You have to work with Unicode. On Mac you also have to work with Unicode, but it’s even more interesting, because the filesystem will do Unicode normalization for you. There is no solution that works in all cases on all platforms.

To summarize the situation:

• File names on UN*X are byte arrays. You don’t know their encoding, you can only guess. It’s safest to not treat them as Unicode. If you want to treat them as Unicode, use functions like QFile::decodeName() or g_filename_from_utf8() to do the guessing for you.
• File names on Windows are in Unicode. You can work with them using UTF-16.
• File names on Mac are in normalized Unicode. You can work with them using UTF-8, but you can’t just save any Unicode. The filesystem will normalize it to NFD for you.

It’s sad to say, but I think this is one area where Windows is the nicest platform to deal with.