Glyphy

These guys totally saved me today. I dropped my phone today (had it on my lap when I got up) and its screen got all messed up. Turns out flashing the firmware helps restore things to normal state. Float’s helped to restore contacts and msgs. Success.

Part of the reason why pjs pjabberd only works on a single processing unit (core) right now is because of the GIL in Python. The architecture uses the asyncore module (asynchronous, like twisted). Looks like it was a good choice, though. In Concurrency with Python, Twisted, and Flex Bruce Eckel demonstrates how he got extreme parallelism from Python+Twisted by spawning n python interpreters, where n is the number of processing units on a machine, and communicating between them via sockets. The Flex part can be mostly ignored. This will come in handy for pjabberd when we add support for multiprocess operation and clustering.

This is my lame-o jabber video.

Video editing on Linux sucks. I used Cinerella to make this. Issues encountered:

• The slides had to be individually exported to PNG from OpenOffice.
• Each slide then had to be individually resized in gimp to match the size in the video. Cinerella just couldn’t do that for me.
• Cinerella crashes once in a while, so I learned to save my work every 5 seconds.
• Cinerella’s UI is awful, but you get used to it.
• The biggest problem is its importing and rendering. I had to try out 10-15 different combinations of audio/video formats to make it render the video properly. It couldn’t import any avis or movs that I generated from recordmydesktop’s ogvs (via mencoder). The only format it liked was mp4.
• Then it couldn’t get the sound right. It was recorded with Audacity in mono with 16kbps bitrate. Cinerella kept producing either no sound or sound in only one channel. I had to manually drop the bitrate in the rendered result to 16kbps and tinker with output settings (neither mp3 nor mpeg audio worked). I had to manually duplicate the contents of the audio track into another, which resulted in 2-channel output (even though the project was already set to 2-chan).

To give it credit though, the docs are pretty decent.

I spent way too much time making it all work. Next time, I’ll just find a Mac that I can use to do this.

Trim function for C++ std::string:

using namespace std;
#include <string>
 
inline string trim(const string& o) {
  string ret = o;
  const char* chars = "\n\t\v\f\r ";
  ret.erase(ret.find_last_not_of(chars)+1);
  ret.erase(0, ret.find_first_not_of(chars));
  return ret;
}

It returns a new string, sort of like it’s done in Qt or Java.

I don’t really know how it’s being held in place. Magic!

Update: This issue went away when I upgraded to pysqlite 2.4.1 (from 2.3.2), so I doubt the info below is really correct.

I just stumbled upon this issue (“database is locked”), so I’m posting in case someone googles for this.

With Pysqlite, the default isolation level is DEFERRED, which means that for all write statements (INSERT/UPDATE/etc.) pysqlite implicitly opens a transaction and you have to commit it to allow other writers to proceed. Apparently, when committing the writer thread holds a global lock, not just a write lock, which prevents readers from making progress too. This lock is held even if your transaction only has SELECT (read) statements. So you have to explicitly commit those transactions.

So, I thought, hey, why not just make all my SELECT statements execute within “autocommit” connections (isolation_level=None)? Turns out that you have to close the connection explicitly after executing a SQL query even in autocommit mode to unlock the db for other threads:

con = getDBConnFromSomewhere(isolation_level=None)
c = con.cursor()
res = c.execute("SELECT ...")
# do something with result
c.close()
con.close() # this is important

I couldn’t find a simple explanation of SQLite’s isolation levels on Google or the official site. I just tried them out with pysqlite.

SQLite has three isolation levels: DEFERRED, IMMEDIATE and EXCLUSIVE. The default is DEFERRED. Since SQLite requires a global db lock to commit writes, you can only have one writer per database with many potential readers. The levels seem to work like this:

• DEFERRED. You can start a deferred transaction with “BEGIN DEFERRED” and it won’t block other writes. If you begin a write (UPDATE/INSERT/…) query it will attempt to acquire the global write lock. So it will either block other writers or block while waiting for other writers to complete their transactions. It will also wait for all the currently-running readers to finish before committing, but the readers aren’t blocked until you actually commit the transaction. I didn’t test this, but I assume that while the write is taking place, the readers are blocked.
• IMMEDIATE. “BEGIN IMMEDIATE” will attempt to acquire a write lock as soon as possible. If it’s successful, no other writers will be able to make progress until your transaction is complete, even if there are no modifications in it. Readers aren’t affected.
• EXCLUSIVE. As soon as “BEGIN EXCLUSIVE” is executed, if a write lock is acquired, no other queries can be executed outside the current transaction. They all block until you commit/rollback, including readers.

Does this sound right?

I’ve been having strange problems with Qt4 applications and GDB. I can’t debug any Qt4 app in either Eclipse or KDevelop. See this thread on the qt-interest list. The error I get:

Cannot insert breakpoint 0.
Error accessing memory address 0x0: Input/output error.

Running GDB from the command line on the binary works fine. I just found that NetBeans 6.0 with the C++ plugin works fine as well. I wonder what’s wrong with Eclipse and KDevelop. Could be the way they try to interface with GDB.

These slides by Peter Saint-Andre cover a lot of interesting potential applications of XMPP (and similar technologies). The vastness of applications is astounding.

20:26:50 up 48 days, 23:46,  6 users,  load average: 111.92, 104.49, 104.97

They say that the load on the server is “still within acceptable levels”.

Update: they fixed the problem. Apparently it was a file-server issue causing slow I/O