software

Since no such beast seemed to exist yet, I have hacked up a wrapper to turn an existing python CGI script into a WSGI application. The result is available from the sysfs download area as cgi2wsgi.py.

The wrapper requires you to rename the original CGI script to somecgi.py (pick a name), make it available in the python path, and set the name you gave the script in the wrapper wrapcgi method. This is due to the way it works: it mangles the environment and standard output, and then tries to import the CGI as a python module. Any output is gathered, split into headers and data and then returned to the WSGI server. An alternative approach could have been to create a full-fledged CGI environment and run the script by forking or another equivalent method, with the added bonus that this should work even to turn non-python CGI scripts into WSGI applications; but this looks like a lot more work than the import approach I used (which was tricky enough in certain details already).

The wrapper is not complete as it stands: there are a bunch of variables which are usually available to CGI scripts but aren't when the CGI is loaded by the wrapper. Also if your script uses globals and does not reset them to a sane state before use data may linger in between subsequent invocations. However, I have successfully run a few applications through it so it should provide a reasonably good base to start from. And it did show a few bugs which were not triggered in a standard CGI environment.
The best way to figure out weak spots in your CGI script is probably by running the wrapper in a WSGI server which is not run itself through CGI, to avoid the WSGI server environment leaking through to the application. If run standalone, the wrapper tries to use the OwlFish.com WSGIUtils to this purpose.

Bugfixes, enhancements and feedback welcome at mechanix on rack66.net.

This blog uses Blosxom.PHP currently, and while there is a configuration option to tell it that it should generate valid XHTML, the output still has some small bugs.

I've corrected the few outstanding issues; I've put a small patch for Blosxom.PHP 1.0 in the sysfs download area that makes it get past the W3C validator. There is only a small change in output and it is how the calendar looks. And if I hadn't mentioned it, it even might have gone unnoticed.

I have just done a new release for innovation3d. Although "new" isn't exactly accurate: it is actually a release which has been sitting on some harddrive for a year and a half. Better late than never I suppose...

I am also going to ask for removal of the Debian packages. This release is rather a "make it slightly more buildable" than a real new release, and does not even come close to getting all Debian issues fixed. Upstream development has halted for a few years now, and I am not up to the task of taking over. If the project ever takes up again, surely packages will arrive into Debian once more. Until then, there is my latest .diff.gz for it which I have included in the sourceforge release.

I'm getting married in september, and we've been busy with our invitations during the last few days.
For certain reasons, we created them at my girlfriend's home where the PC is running Windows XP and Office XP. But Word is a pain to layout with, especially when it comes to vertical desings. We needed a picture above a block of text, but could not get it right.

In the end, I ended up printing things to PDFCreator, on separate pages: the picture with Photo Editor (at least I think that's what it's called), which allowed for exact on page positioning, and the text block in Word with page margins set to do the positioning. I used PDF output because I could thus print the invitations at home on a laser printer instead of the ink printer with my family in law.
Only thing is, I had to feed each page to the printer multiple times, unless I could overlay them with each other. The solution came with the help of LaTeX. When you set the position of the included graphics inside the AddToShipoutPicture blocks to (0,0), fullsize pages can be overlaid to achieve the effect I needed. A bit of a hassle, but in the end it's the result which matters.

I was looking for a GUI application to handle certificates, when I stumbled upon this. It looks interesting, but I wonder if it would be portable to That Other OS. That would make it even more interesting :)

When this made me look around again for more SIP information, I found a VOIP on Linux quick guide where I learned that the SIP protocol is in fact peer to peer just like a much hyped proprietary IP softphone. NAT issues aside, and looking only at home users at this point, this means not only that SIP offers an advantage over Skype because it is possible to switch networks, but in fact using dynamic DNS one should be able to eliminate registering with a SIP server altogether.