Public service announcement
Hey! Have you sold your BlogShares stakes yet? THIS IS THE LAST DAY TO DO IT. All share balances revert to zero tomorrow, but your cash balance carries forward.
So sell. Now. I really mean it.
Hey! Have you sold your BlogShares stakes yet? THIS IS THE LAST DAY TO DO IT. All share balances revert to zero tomorrow, but your cash balance carries forward.
So sell. Now. I really mean it.
Over at Aquarionics you can find Cave Linguistica read aloud.
How cool is that?
I thought that my work computer’s demise had taken about a day and a half of Visual Basic drudgery with it.
Turns out not. I must have backed it up to the network while in a sufficiently altered state (caffeine, cut that out!) not to have remembered.
Well, that is a good way to start another day of VB drudgery.
Update: Bah. Have to redo it all anyway owing to new discoveries about semantics of supervisor-key fields. Some days it doesn’t pay to get out of bed.
I should not have to write this post. It’s just that the documentation for dates in Movable Type is—okay, it’s just plain organized wrong. I hope this will be fixed in an upcoming release.
Date- and time-related placeholders (<MTEntryDate>, <MTCommentDate>, <MTCommentPreviewDate>, <MTArchiveDate>, <MTArchiveDateEnd>, <MTPingDate>, and <MTDate>) all have a format attribute whose value is a concatenation of incomprehensible codes starting with % that represent various parts of a date and time.
If you’re lucky, you can use the two fully-elaborated codes and save yourself a lot of pain. %x gives you the date, in the form “September 6, 2002”. %X gives you the time, in the form “4:31 PM”. If these work for you, for heaven’s sake use them!
Otherwise, read on…
Movable Type’s documentation organizes all these codes alphabetically by code, which is great for geeks, not so good for everybody else. Here’s the list organized by unit of time, small units first, the way $DEITY intended:
Putting it all together: To get a date header like Caveat Lector’s—well, first you have to hack Movable Type itself to produce Latin month and weekday names. Not recommended, but I’ll tell you how if you ask.
But let’s pretend that I am a normal English-language blogger using English-language dates. What I’m using is the full weekday name, a comma, the one- or two-digit day of the month, the full month name, and the four-digit year. That works out to <MTEntryDate format="%A, %e %B %Y">. Note that you have to include any punctuation (such as my comma) and spaces you want.
Whereas the weekly-archive links in my blogroll use the abbreviated month, the one- or two-digit day of the month, and the four-digit year. (And the month names are in English, but you don’t need to know how I did that.) That’s <MTArchiveDate format="%b %e %Y">.
See? Not so bad. Okay, okay, bad but manageable.
If you’re scared of your Movable Type templates, you aren’t alone. I hear that pretty regularly. So it only makes sense that experimenting with the templates that make up your live blog is Not To Be Thought Of until you’ve built up a little more confidence.
Fear not. It’s easy to make yourself a new template to use as a sandbox to play in. In fact, before we go any further I strongly recommend you do this, because we’re going to build a template from scratch, something you do not want to do on your main blog page.
Here’s how.
Click the Templates button on the left-hand button bar. (No left-hand button bar? You’re in the main menu. Click on your blog’s name.) You should see a list of templates, the main ones at top. Click on “Create new index template.”
You should get the same template editing menu you’re already used to from looking at your other templates, only blank. Name your template (how about “Sandbox”?) and give it a file to write to (try “sandbox.html”). Leave the “rebuild when rebuilding indexes” checkbox checked, and do not put anything in the “Link this template to a file” box.
Click “save,” and go ahead and rebuild (choose the “indexes only” rebuild option). That’s it. You’re done.
Where is the page that this (currently empty) template creates? In the same folder as your main blog page. If your main blog page is http://blog.example.com/index.html, your sandbox page is http://blog.example.com/sandbox.html.
What to put in the template… we’ll get into in upcoming posts.
I’m told that the re recursion bug is finally finally finally getting fixed in Python 2.3. Yay! Much rejoicing!
(Would this have anything to do with this bug being enshrined for posterity in the latest edition of Mastering Regular Expressions? One wonders, one does. Maybe print books are good for something after all. Kidding!)
The friend who tipped me off to this bemoaned Zope’s being stuck at 2.1.something. So I gotta question for the hard-core Pythonistas amongst my readership: Is it possible to swap the new version of sre into an older version of Python and have it work? If so, how far back can one go?
Or is the Unicode support added in 2.2 (I think) absolutely necessary?
I think maybe I need to up the font size on my blogpost attributions. Turn ’em red. Or something.
I know I write the vast majority of CavLec, but I do put an attribution on every post. Because every once in a while, I can convince David to post something, and since he doesn’t dilute his talent by running off at the keyboard the way I do, it’s usually pretty special when he does.
“Cave Linguistica” is his, not mine. (Though I will take discredit for the pagecount and publisher on Caveman Morphology. Which bloody well ought to be a 500-page book.)
So be careful when you cite, please. When something here is particularly good, odds are it’s not mine. When it doesn’t use typographic quotes and dashes, you know it’s not mine.
(Ugh. Baker & Oop forget address. Send grant money David. Much grant money. No grant money, Oop smash.)
Heh heh heh. Somebody’s been doing too much work on his tones paper.
(So who took that one seriously, hm? Were you happy when you figured out it was a joke?)
I told them. I told them.
When my computer died, I reported that the hard drive was making a hitherto-unheard grinding noise, and I thought there was something wrong with it.
“Oh, don’t worry; we’ll just ghost it from a working machine.” Um, okay. Suppose I could be wrong.
So the IT guy arrives with the ghosting software, and I calmly and politely remark again that I think the hard drive is toasted. Does he check? Nah. He tries to ghost the machine. Three or four separate times.
It’d just kill him to admit I knew what I was saying, wouldn’t it? Never mind that I was right.
I guess wasting his whole day is preferable. What-the-eff-ever.
I ran into somebody else’s rant (not sure where, sorry) ’lowing as how XML would never catch on because wiki markup was really all you needed, and could be converted to whatever you like anyway.
Nice idea, but it won’t work. Human expression is a mite more complex than that, even on the text-only, affect-flattened Internet.
I am going to tell a story on myself to demonstrate my point, borrowing Liz Lawley’s blog for a moment.
In college, I picked up the very bad habit of emoting inside asterisks. I *grin*ned and *groan*ed my way through many years of email and Usenet postings. I also, of course, used asterisks for emphasis—who didn’t?
As I understand matters, wiki markup uses asterisks for emphasis only. Translators of wiki markup to HTML turn asterisk-delimited words bold. (Microsoft Word can be tweaked into doing this also, incidentally.)
Imagine my surprise when I used asterisks in a comment on Liz’s blog (which I can’t bloody find, unfortunately—the comment, not the blog!) both for emphasis and to delimit a *grin*, only to find my grin a bit bolder than I had intended, and shorn of its asterisks.
Ambiguity in action. Hey, is that the Andrea Doria?
The “wiki markup is enough!” cry is simply one more variant on the One True DTD theory of markup, about which I have pontificated before. The reality is that no markup language suffices for all texts, all people, and all situations. Keep trying to invent it, by all means, as it’ll keep you off the streets; just be ready to fail.
Eventually, any closed set of markup will run into edge cases and ambiguities it just can’t handle. That’s why XML- and SGML-defined markup sets are open—not in the sense of “open standards,” though they’re that too, but in the sense of extensible, open to revision and augmentation. Open-ended.
And that’s why XML and SGML exist to begin with, and why no closed tagset created with XML and SGML will ever completely replace them.