When I checked it, Eclipse recognized my subrepo as a subrepo: it shows a revision id (or whatever Mercurial calls something like “12:aa5aaf57f6c0″). That much is good.

But there’s no way to pull or update the subrepo, which does rather call into question the deverlopers’ use of the word “support”….

The CREATE PROCEDURE statement ends with a semicolon. So does the SELECT statement inside the CREATE PROCEDURE statement. The MySQL parser is not smart enough to tell them apart – odd, given that Pascal compilers solved exactly the same problem forty years ago – so it it necessary to use the DELIMITER statement to change the (outer) delimiter to something else.

The MySQL manual does mention this in the chapter on stored procedures, but neglects to mention two important details:

• This applies to any communication with the MySQL server, not just via the mysql command-line client.
• The new delimiter will not be recognized unless it is the only thing on the line. Replacing (e.g.) END; with END// will produce incomprehensible MySQL errors (that offer no guidance at all toward fixing the problem).

So now I can write stored procedures that return query result sets. Yay me.

So I had to drive to work after all.

Hm…donuts….

LoadModule wsgi_module modules/mod_wsgi.so

to the appropriate file in /etc/http/conf.d, restarted Apache, and – presto! – mod_wsgi is available.

Next: figure out how to use the silly thing….

LoadModule python_module modules/mod_python.so
AddHandler mod_python .py
PythonHandler mod_python.publisher

removed from various files in /etc/http/conf.d; Apache restarted; mod_python is no longer present.

But the mod_wsgi install function only makes mod_wsgi available to Apache: it doesn’t cause it to be loaded when Apache starts up.

The build stage went well (albeit with some warnings suggestive of sloppy coding practices on the part of the mod_wsgi developers).

The install went well.

Now attempting to disable mod_python.

checking for apxs2… no
checking for apxs… no
checking Apache version… ./configure: line 1704: apxs: command not found

This is because the httpd-devel.x86_64 package isn’t installed.

In theory,

yum install httpd-devel.x86_64

would fix that.

$ ldd /usr/bin/python
linux-vdso.so.1 =>  (0x00007fff613ec000)
libpython2.4.so.1.0 => /usr/lib64/libpython2.4.so.1.0 (0x000000380e200000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000380da00000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000380d200000)
libutil.so.1 => /lib64/libutil.so.1 (0x000000381cc00000)
libm.so.6 => /lib64/libm.so.6 (0x000000380d600000)
libc.so.6 => /lib64/libc.so.6 (0x000000380ce00000)
/lib64/ld-linux-x86-64.so.2 (0x000000380ca00000)

The second line of output is the important one: the shared-library incarnation of Python is /usr/lib64/libpython2.4.so.1.0.

I’ve read them all. “Vile” doesn’t even scratch the surface of what they have become…. Give water to Frank Herbert!