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
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-opendoesn’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:
(this comes from Gentoo’s
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:
I found some helpful information on
this forum, though my idea is different as I want Chromium to use KDE software when opening files (
detectDEis now somewhat smarter and a lot more complex (~70 LOC).
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
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:
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
PPLIBis 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
objdumpoutput, 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
retstatement, so no need to follow any jumps. Note to discard stack pointer registers,
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
xorg.confneed 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
debugkeyword argument to
True. This will show you how it actually calculates the result:
And finally, if you’re wondering where would you need madular exponentiation, well, it comes in handy for example when generating Pratt certificates.
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).