I came across this video while reading a question on StackExchange programmers about the Principle of Least Astonishment.

Recently I’ve come across a ruby irc server called camper_van. What it does is pretty simple: it communicates with Campfire while acting as an IRC server. That, combined with irssi makes it much more fun to use Campfire for work.

The following is a simple script that starts the server (if not already running) and then opens up irssi in a new gnome-terminal session.

The second file is an example irssi config file (merge it with ~/.irssi/config).

I’ve recently learned that App Engine chokes on HTTP DELETE requests that contain a request body. While developing locally, everything works just fine, but when deployed, the production server drops these “malformed” requests with a “400 Bad Request” status line, so they don’t even reach the application in the WSGI pipeline.

After reading the specs I couldn’t find where it would state that a body is not allowed for DELETE, it does state however that the request URI should be enough to identify the resource and that no extra parameters should be required (so I guess many servers just ignore the body there).

Anyway, since App Engine is so strict about requests (which is a good thing anyway), it would be cool if Sencha Touch 2 could be somehow forced not to send an XHR payload when deleting a moel instance using the REST proxy. There seem to be no config option to prevent a request body, and when I asked in the forum, I got no decent reply.

After reading the source, I came up with an override that fixes this behaviour. However, since overrides are now deprecated in favor of Ext.define, the following gist now includes a correction to the override.

Chromium opens downloaded files using xdg-open. Problem is, xdg-open doesn’t work correctly with awesome (and also doesn’t support a number of other, non-mainstream wms.)

The piece of code responsible for detecting the desktop environment:

detectDE()
{
    if [ x"$KDE_FULL_SESSION" = x"true" ]; then DE=kde;
    elif [ x"$GNOME_DESKTOP_SESSION_ID" != x"" ]; then DE=gnome;
    elif `dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetNameOwner string:org.gnome.SessionManager > /dev/null 2>&1` ; then DE=gnome;
    elif xprop -root _DT_SAVE_MODE 2> /dev/null | grep ' = \"xfce4\"$' >/dev/null 2>&1; then DE=xfce;
    elif [ x"$DESKTOP_SESSION" == x"LXDE" ]; then DE=lxde;
    else DE=""
    fi
}

(this comes from Gentoo’s xdg-open, ebuild x11-misc/xdg-utils-1.1.0_rc1_p20110519.)

A solution

While we could easily monkey-patch this, or we could just set some environment variables, but there’s a cleaner solution. Create the script /usr/local/bin/xdg-open, so it will take precedence over the real xdg-open, and have it set the environment variable only for the process you’re about to start:

#!/bin/sh
KDE_FULL_SESSION="true" /usr/bin/xdg-open "[email protected]"

I found some helpful information on this forum dead link removed, though my idea is different as I want Chromium to use KDE software when opening files (okular, gwenview, etc.)

Update

As of xdg-utils version 1.1.0_rc1_p20120916, detectDE is now somewhat smarter and a lot more complex (~70 LOC).

A broken Sapphire Radeon HD 4850 somehow ended up in my possession. I didn’t know what was the problem, so I tried to plug it in in a mobo I just had lying around, running the nightly oneiric.

The card showed up fine in lspci. I didn’t try using it with the open-source drivers, as I’m not interested in putting a display on it. Instead I wanted to play around a little with OpenCL, so I went for the closed-source Catalyst driver. (This was a few days ago, when 11.6 was the newest version around - I haven’t tried it with the latest 11.7 or with the 11.8 preview versions.)

The driver didn’t start, X choked on this error:

(EE) PPLIB: PP_Initialize() failed.

Since the driver is not open-sourced, googling around didn’t reveal any usable source code on PP_Initialize. So I turned to objdump.

$ objdump -CRd fglrx_drv.so

This revealed a few things about PP_Initialize. (I don’t think I should post any dumps here, as I believe that would violate copyright laws.) I assumed it returns a status code, so I tried overloading it and returning a different status code instead:

$ gcc -shared -fPIC -o preload.so preload.c -ldl
$ LD_PRELOAD="`pwd`/preload.so" startx

This will start the X server but with our library preloaded. With a status code of zero, the server now continued the loading of the driver, but of course other errors have emerged. So I ended up overriding a couple more functions.

I was wondering if maybe PPLIB is part of the code that manages PowerPlay functions, and if maybe just disabling it all and setting the fan speed manually to 100% would give me a result.

Well, I was wrong. The only thing I gained was some experience with objdump, reverse-engineering, some C and assembly. After disassembling the card itself, I noticed that one of the conductors on the GPU seemed to be burned out - probably causing card initialization to fail.

I also learned that when pre-loading with LD_PRELOAD, the overriding function should accept the same number of arguments as the overriding function, otherwise crap will be left on the stack, messing up the rest of the code. To figure out how many parameters a function takes, it is usually enough to fund it in the objdump output, look at the assembly, and count how many things are popped off the stack before returning.

The pops usually occur around the top of the function body, just before the ret statement, so no need to follow any jumps. Note to discard stack pointer registers, %ebp and/or %esp.

Another thing I’ve learned playing around with GPUs is the fact that X has to be running in order for OpenCL to work on a card. No displays are necessary, but the Device sections in xorg.conf need to reference the proprietary drivers (as the open-source ones don’t provide OpenCL support at the moment).

Exponentiation of large numbers can easily be implemented using exponentiation by squaring, which greatly reduces the number of steps it is needed for a given imput. Computing large exponents modulo a number is even faster and requires less memory, as it reduces the size of the resulting integer.

The following implementation works for both Python 3 and python 2 (although in Python 3 it will run faster):

Due to the modulo, the resulting function will be very fast: for example, it calculates mesq(3**5**7, 11**17**3, 69) in a matter of milliseconds.

To get the idea behind, set the debug keyword argument to True. This will show you how it actually calculates the result:

>>> mesq(7, 30, 5, True)
(7**30)%5 =
((7%5)**30)%5 =
((((7%5)**16)%5)*(((7%5)**8)%5)*(((7%5)**4)%5)*(((7%5)**2)%5))%5 =
((((((((((7%5)**2)%5)**2)%5)**2)%5)**2)%5)* \
 (((((((7%5)**2)%5)**2)%5)**2)%5)* \
 (((((7%5)**2)%5)**2)%5)* \
 (((7%5)**2)%5) \
)%5 =
4

And finally, if you’re wondering where would you need madular exponentiation, well, it comes in handy for example when generating Pratt certificates.

Update

Do not actually use this code. This is just an example. A way faster implementation is the built-in pow(), which also accepts a third argument (the modulo).