Allan Saddi's projects blog

As per Ian Bicking's suggestion in the Web-SIG mailing list, ajp and scgi will now use the environment variable WSGI_SCRIPT_NAME (as passed from the web server) as the scriptName. Note that at this time, cgi2scgi and mod_scgi do not pass extra environment variables. (mod_jk can pass extra variables via the JkEnvVar directive.)

Currently, WSGI_SCRIPT_NAME overrides scriptName. If anyone sees a problem with this, say so now.

Also, scgi will accept a scriptName of None. In this case, scgi will not touch the environment at all. (It is assumed to be correct as is the case when using cgi2scgi.)

I've just released version 1.2.6 of newsfish, which is also its final release from me. There was one bugfix and a few minor (mainly configure/build-related) changes made since 1.2.5.

I had originally committed the bugfix to my CVS repository, with the intention of stamping out a release after rolling in a few more updates/fixes. Unfortunately, that never happened and I actually lost my CVS repository when the hard drive of one of my development machines died. (I lost a lot of data that day... Luckily, I was in the middle of migrating to Subversion, so many of my projects survived... on a different server. ) I just recently stumbled across what is probably the most recent backup of my CVS repository, sitting on a machine from my old university.

I haven't had a USENET account in years, and I don't really foresee myself dabbling in USENET anymore. So I think it's best to just close up the project...

By default, wsgi.multiprocess is now False on all threaded WSGI servers. This may be changed by passing the keyword argument multiprocess=True to the servers' constructors.

My original interpretation of wsgi.multiprocess was "is running multiple instances of an application possible with this server implementation?" I think that's a question better answered by the person deploying the application, since even SCGI can be run with load-balancing/redundancy using an HTTP load-balancer.

MemorySessionStore and ShelveSessionStore were incorrectly allowing the same Session to be checked out multiple times simultaneously. Also, eliminate a possible deadlock in DiskSessionStore.

Well, whether you have or haven't been keeping up with my personal blog, I have been quite busy the past 2-3 weeks moving about 200 miles south. I'm still not settled in and my main development machine, though running, isn't exactly in an ergonomically usable state (i.e. it's sitting on the floor ).

Anyhow, Ian Bicking's blog entry about single signon tuned me onto mod_auth_tkt. I haven't actually tried mod_auth_tkt yet, but by all descriptions and accounts, it seems like something I'd like to use. (In fact, before my moving got serious, I was working on a single signon service for flup.org - but still hadn't quite worked out the mechanics.)

The only big problem with mod_auth_tkt is this note from the web page/readme:

NOTE: mod_auth_tkt does NOT work with Apache version 2, only with Apache 1.3.x.

Which is unfortunate, since I use Apache 2 for deployment. But really, I'm not going to let that stop me. (It didn't stop me in the case where the Apple-supplied mod_WebObjects only supported Apache 1.3 either. ) I began porting mod_auth_tkt to Apache 2 last night.

Porting to Apache 2 is actually quite easy and mechanical, almost requiring no thought. I didn't bother using the ap*_compat.h headers though and opted to rename the types/functions to use the Apache 2 equivalent. (Maybe not a smart move, in hindsight, with regards to maintenence... doh!)

Anyway, it's compiling without warnings... but I've yet to actually try it. For some reason, I think I need to set aside a whole day to debug it... and I will probably do that sometime soon. These past few days, I've been too concerned with getting my DSL working...

Well, not really, as I'm finding out.

With the release of Mac OS X Tiger last Friday, I finally got a chance to play around with gcc 4.0 and its auto-vectorization feature. A few, simple contrived cases convinced me that the feature actually worked, but I was quite disappointed when I began compiling my own C projects with the appropriate flags turned on. I have yet to find a single loop that successfully auto-vectorized. (FYI, I'm using the -fdump-tree-vect-stats option which dumps the output of vectorization phase to a separate file.)

I guess moving forward, I should start coding with auto-vectorization in mind... which will be challenging considering the strict requirements (just look at the examples on that page!)

Anyway, I thought I was being clever last night when I built Emacs.app with -ftree-vectorize. Now I doubt whether even a single loop was vectorized.

Oh well, it's a start. I wonder if auto-vectorization will ever get to the point where hand-coding vector instructions is no longer necessary for 90% of code...? (Kind of like what C did to writing in assembly language, I guess.)