Somehow I got onto WebKit nightlies instead of stable Safari 3, and even after uninstalling SIMBL and losing magic Greasemonkey powers, it’s crashy. Just so you know.
Somehow I got onto WebKit nightlies instead of stable Safari 3, and even after uninstalling SIMBL and losing magic Greasemonkey powers, it’s crashy. Just so you know.
I want a TAP parser in Python, so I tried yeanpypa:
from yeanpypa import *
non_zero_number = AnyOf('123456789') + ZeroOrMore(digit)
rest_of_line = OneOrMore(NoneOf('\n'))
plan = Literal('1..') + non_zero_number
todo_directive = Optional(' ') + rest_of_line
skip_reason = ZeroOrMore(NoneOf(' ')) + Literal(' ')
+ rest_of_line
skip_directive = Optional(' ') + Literal('# ')
+ Literal('skip') + Optional(skip_reason)
directive = Optional(' ') + Literal('# ')
+ (skip_directive | todo_directive)
description = Optional(' ') + Optional('- ')
+ ZeroOrMore(NoneOf('#\n'))
ok_not_ok = Literal('ok') | Literal('not ok')
test_num = Optional(' ') + non_zero_number
test = ok_not_ok + Optional(test_num)
+ Optional(description) + Optional(directive)
plan_skipped = Literal('1..0') + skip_directive
plan_first_tap = plan + ZeroOrMore(Literal('\n') + test)
plan_last_tap = test + ZeroOrMore(Literal('\n') + test)
+ Optional(Literal('\n') + plan)
tap = plan_skipped | plan_first_tap | plan_last_tap
I guess it works, but it feels like writing a regular expression longhand. I would probably also make it more lax if I wrote it as an re, as it would be easier to write \s*-\s* in the description rule, say.
Install Python 2.5 on the new server from source, because dev Django prefers it and the distribution’s package is 2.3. Install dev Django from their subversion. Install PIL and flup, from source, because the docs for the app you’re setting up says it’ll need them. Grab and build pysvn because the app you’re setting up will, in fact, need it. Grab development subversion source, so pysvn will compile against it. Install subversion from source, because the source you built pysvn against is newer than the distribution’s package. Grab and try to build MySQLdb (the Python library), because although this is a private deployment, it is a deployment, so you might as well not use sqlite, plus you found the Django ORM isn’t 100% with sqlite anyway (apparently you can’t re-use a ForeignKey field as a primary key, with sqlite). Find the MySQLdb configurer can’t find mysql_config, so it can’t configure the build. Poke around on your other server, where the app already runs on Django’s runserver (not for deployment), and rediscover you get mysql_config from the distribution’s “testing” MySQL 5 package, not the package provided by your company. So reinstall MySQL from the testing repo package. Install mod_python, because although it’s a private deployment, it’s a deployment, and you guess you shouldn’t use Django’s runserver. Configure the app to run under mod_python. Find mod_python can’t find the django package. Find, oh, yeah, the packaged mod_python will use the packaged Python 2.3, not the manually built 2.5, so it’s looking for packages under /usr/lib/python2.3, not /usr/local/lib/python2.5 where django is actually installed. Try to have mod_python include 2.5’s package paths. Find there are, in fact, weird errors that are doubtless more work to fix than just rebuilding mod_python against Python 2.5.
Have some sleep, and most of a Saturday.
Grab and try to build mod_python from source. Google around to figure out what relocation R_X86_64_32 against 'a local symbol' can not be used when making a shared object; recompile with -fPIC means. Find there’s a mod_wsgi, and decide to use it, since Django apps don’t necessarily use any special mod_python facilities anyway. Find building mod_wsgi has precisely the same error. Find the error means that, indeed, you didn’t build Python 2.5 with shared library support, which both modules need to embed Python in Apache. Rebuild Python 2.5 with the right configure option (--enable-shared). Install mod_wsgi from source. Configure Apache for the Django app with mod_wsgi. Configure the app’s media uploads directory so it’ll quit its whining and run.
See that it runs!
But remember you want to use LDAP auth for this private deployment.
Look for how to set up the Django app’s LDAP backend. Find it’s only documented in the mailing list post by the author of the original patch. Install the python-ldap package, as it was noted as required (of course) in the mailing list post. Set up LDAP in the app semi-right but find you can’t tell, because the app eats all exceptions, the only error it actually shows being “Invalid username or password.” Fiddle with the configuration settings, restarting Apache and trying to sign in again. Fix the app to expose the real error, which is that you thinkoed in the app’s settings_local.py configuration file: you tried to define AUTHENTICATION_BACKENDS as a single-item tuple, but you left out the comma that’s required to turn a string in parentheses into a tuple. Realize also that, huh, the ldap package is missing. Realize that’s because (of course) you installed python-ldap from a package, meaning it’s installed for the packaged Python 2.3, not your manually built Python 2.5. Grab and try to build python-ldap from source. Find it doesn’t build against the openldap-devel package that came already installed on the server; the package is for OpenLDAP 2.2, but the python-ldap builder is hardcoded to look for for OpenLDAP 2.3. Try to update OpenLDAP from your distribution’s testing repo (it has 2.3), but find it “conflicts” with the existing openldap 2.2 packages, and you’d have to reinstall every damn thing if you removed and reinstalled openldap. Look for a download for an older version of python-ldap (the package was 2.0.1 but you were trying to build the new one, 2.3.4). Don’t find one on the official download site. But it is a package, so yum search then Google for a source package. Install the python-ldap 2.0.1 source package you do find. Untar and build and install python-ldap 2.0.1 from source. Confirm in the python shell that the ldap module loads. Try using LDAP to sign into the app again. Find now it outright crashes with glibc malloc protection faults (double free or corruption (out) or free(): invalid pointer). Wonder if all this is really worth it.
Find that, OTOH, these Friday and Saturday nights are somehow still more satisfying than the preceding week.
An idea didn’t crystallize for me until I read this article on Habbo Hotel that states a lot of Habbo Hotel users spend their time simulating real life activities; that the pre-mature citizens of Habbo Hotel are spending real money creating simulacra of the grown up experiences they expect to have. I saw (and participated in) this same behavior in social MUDs, so it seems natural to me, though I’m surprised the lengths to which Habbos have apparently taken it.
There must be the same impulse in SL, which ends up a source of tension: there are the people who see SL as an interesting software environment, and the people who are playticipating, each enabling the other by providing tools and a market respectively. To the extent these groups are separate and don’t have the other’s interests in mind, their relations are tense.
I’m sure this is not news, but I hadn’t thought of it in quite those terms.
Not to assume you all care about MacHeist, but two more things.
The answer to how many people need to buy the MacHeist bundle to “unlock” Snapz Pro X: twice as many. Another 5,000 or so people will have to shell out $50—about $12 of which goes to charity—for a discounted slew of Mac software in the next 12 days for it to be worthwhile for me (and presumably a lot of other people).
Roughly. I’m not sure exactly, because these numbers don’t add up. I expect it’s the discount you get when you buy multiple bundles.
25% of 5,320 bundles at $49 per bundle is $65,170, not the quoted $57,395. The quoted “Raised for Charity” amount is more like 22% of that naïve gross total. The $7,775 disparity would be a combination of the 20% and 33% discounts, and I expect one could come up with convincing proportions of discounts to get that number. I, however, should be working.
I was talking with
authenticgeek about it yesterday, but in case you don’t follow such things: there’s another of those dubious sounding Mac software bundles on sale at MacHeist. For $50 you’ll currently get:
and some alarm clock and stop motion animation (!) program.
The weird way it works is if 1,500 more people buy the pack, then all 5,000 purchasers will also get CSSEdit. I don’t care much about Pixelmator, as Acorn is more my speed, but the set would be totally worth it once it includes Snapz Pro X. (Jing is good and the screencast.com integration is nice, but it’s requiring me to upgrade to the version with ugly-ass advertising after screencasts in order to use the integration.) Unfortunately we won’t find out how many more people will have to buy the pack to “unlock” Snapz Pro X until after CSSEdit is “unlocked.”
It definitely sounds shady, but while I wouldn’t (and haven’t) bought these programs a la carte, I would probably pick up the set for $50.
Hmm: The new about:config interstitial: