Now, this isn’t personal, so sorry adurdin, but your panel can break things. It runs the view twice, no matter what view, which means if you are adding new objects in the view, you’re gonna get two new objects and have no clue why it’s happening. I thought I had somehow pushed a bug into the admin site as I kept making two of everything, no matter what.

This may be a drawback of profiling outside of middleware, I can’t find any django-debug-toolbar based profiling systems that don’t call the view twice, but it likely is possible inside of a middleware that pushes its data over to a panel on the far end of a request.

There was a promise made for a singe-call panel but after trying it, there’s no fix for the double-call nor does it even work with the latest debug-toolbar. If anybody knows of a profiling debug-toolbar panel (or writes one), comment below and I’ll write a post and publicize it.

Environment 2.5.1

So to build the version 2.5.1 environment, I followed these (Windows) instructions and these (Linux) instructions

Linux

For compiling in Linux, since I only want a plugin, I ran configure with parameters to disable all the pieces I didn’t care about and didn’t have the libraries for:

./configure –disable-gtkui –disable-gstreamer –disable-vv –disable-idn –disable-meanwhile –disable-avahi –disable-nm –disable-nss –disable-gnutls –disable-tcl

Windows

For Windows, I followed the instructions and stopped after the local.mak instruction and ran “make -f Makefile.mingw” on $BUILDDIR/pidgin-2.5.1 but at some point it wants “dlfcn.h” so I just let it error out.

Compiling

I cd into pidgin-2.5.1/libpurple/plugins/ and checkout my git repository. I then run “make gtalkinvisible.so; make -f Makefile.mingw gtalkinvisible.dll” and a few other commands to zip/tar the files and upload them to my website and update the version/Changelog.

Environment 2.7.1

It may be possible to combine these, despite the relative change in packages that breaks the gaim-extprefs project, but I didn’t bother. Thanks to the pidgin-privacy-please plugin for Windows instructions for the latest pidgin releases too, as they made the previous instructions as well. They’re instructions were perfect, better than Pidgin’s own Wiki.

Linux

These instructions were as simple as before, except I downloaded 2.7.1. Same simple setup if you don’t care about the libraries necessary for compiling the rest of Pidgin.

Windows

Following the instructions from above was super easy, I just had a small hiccup along the way that is super easy to fix. Just replace the first export to this:

export PIDGIN_DEV_ROOT=/tmp/build

Once you’ve done that, you can literally copy-paste almost the whole page as a script and copy-paste the local.mak file and you’re done. Of course, I didn’t use /tmp/build as my directory because I wanted to keep my environment around as well as have it fit into my ~/projects/ schema. I basically put it into my existing ~/projects/pidgin/ folder as /before270/ and /after270/ for the two environments.

So now I can update the plugin easier and upload both Linux and Windows binaries. If anyone knows how to compile automatic Windows installers, please comment so that I can create some sort of a shell repository for plugins. Thanks!

Basically, Django’s built-in ORM is awesome, but lacking. There are many reasons to move to SQLAlchemy, but not if you’re more interested in speed of development. One feature that Django’s ORM is missing is stored procedure support, including the ability to make them quickly.

A stored procedure is basically a function definition on the database side that runs a few to hundreds of lines of SQL and returns the result, decreasing the amount of SQL sent over the network. This is very useful for complicated statements that are called often, say once for every single page, but require only a few variables if any. A use-case in my PHP project was where 99% of the pages ran the same lookup query which consisted of about 10 lines of SQL; instead of sending that SQL over (around half a KB) each time, I replaced the SQL with “CALL generic_lookup($pageid)” or in Python “CALL generic_lookup(%s)” % pageid.

Now, to port this to Django we need a two-phrase process. The first one creates the procedures in the database, the second replaces normal ORM calls with stored procedures.

I have not made this, but here are the specifications for the code that would take only a few hours to create and a few more to debug (if only I had the time):

A decorator for models.Manager functions. Called @stored, it will function in both phases differently. For the creation phase, it will simply tag the function it is wrapping with func.is_stored = True, allowing introspecting code to identify it as a stored procedure. It will also make the wrapped function available like so:

@stored
def all(self):
    return self.get_query_set()

all.is_stored == True
str(all.func.__class__) == <type 'function'>

The first phase also involves a management command that goes through every model’s managers and looks for stored procedures using the .is_stored property created above. The .is_stored and .func properties could be combined.

This management command, having found all the stored procedures, will then proceed to get the SQL for each QuerySets and wrap it with the DB-specific code for stored-procedures (MySQL’s is provided earlier). Once the SQL has been wrapped, it is sent to the DB for creation and the procedure is now available. The SQL will need some filter to allow for arguments to the stored procedures, but that’s a whole other can of worms for a possible continuation of this post.

Once the procedures have been created on the DB, the @stored decorator now just ignores the function it’s wrapping save for its name and arguments and returns the dataset returned by the database after a call to the stored procedure. Since most databases don’t allow further filtering on procedure output, returning the dataset is the only way to easily keep loose-coupling with the DB.

I hope this post was useful to someone else who can code in Python/Django. If you create a decorator using these specifications, please post a link in the comments so that others can benefit from it too. If I write it, I’ll definitely provide the app somehow, though I don’t see it in my near future.

Skipping all the Windows 7 stuff, I’ll just skip to what I did.

The Jump List is what shows up when a user right-clicks on a taskbar item in Windows 7, so I modified PuTTY’s source to enable JumpList functionality. On my main site, I have a binary and the necessary patch.

Added Functionality:

* Each session can add itself to the JumpList for PuTTY

* Upon startup, JumpList is created

* If user pins PuTTY to the Start Menu, JumpList remains

My main site has some further information, as well as the actual files.

There are many improvements of openconnect over the official Cisco AnyConnect client, one of them being that it actually works. Because of these, I’m an advocate of this script versus the official client.

I’ve made my script available here. Please comment here regarding any issues or dependencies regarding this script. I’m happy to incorporate any patches you have for making more things work, and I’ll try to fix any problems you may have. If you have to modify the script to make it work for your system, let me know so I can make the script more generic (assuming you’re using a generic distribution, I have no intention in supporting custom Linux OSes).

Happy VPN’ing!

Well, there’s good news. I created a plugin to enable Invisible for Google Talk accounts.

Now, before you go rushing off to download and install that plugin, here’s the big caveat: I only made it work for one account. If you have more than one Jabber/XMPP/GTalk account, then it won’t work for all of them. Proceed with caution, because having multiple accounts may break it. I have tested it with one account, so no worries there Fixed, now supports multiple accounts (but no guarantees, this is open source software).

Instructions are available on my main site for both Windows and Linux.

Update 3/19/2010: There have been a lot of requests for fixes/updates/rewrites to this code. I’m sorry to say, but I’ve moved on to newer projects. This was originally only a weekend project for me, little did I realize that there was this much demand for it. I’ve provided all the code I have for this, if anyone wishes I can provide the whole working directory as well as instructions to compile on both Linux and Windows, but beyond that I will not be making any more changes.

Now, I have a patch waiting in my email, and I will attempt to incorporate that sometime in the future, but as above, no guarantees.

Sorry to everyone who has posted with problems with this code, but it’s over a year old, meant for a much older version of Pidgin, and works with at least historically badly documented APIs (sorry Pidgin, but that documentation wasn’t easy to understand at all, I worked mostly off examples). Good luck with getting a real invisible implementation into Pidgin trunk!

Update 6/27/2010: Again, there have been many further comments as to whether it works or not. Seeing this much demand for only a few lines of code is very interesting. Until now, many of your problems have been either unfixable due to the way the plugin works (a hack) or too much work to reproduce. However, I’ve been notified of a better way to go about going invisible and I will try to update the plugin soon (no guarantees however) with that new system: http://chinmaykamat.wordpress.com/2010/01/22/google-talk-invisible-mode-in-pidgin/

Sorry to everyone who’s Pidgin crashes when using this plugin, there’s little I can do when I have the plugin enabled all the time and get no crashes. In fact, I’ve had Pidgin crash repeatedly on me before, but never since I enabled this plugin.