Quick -- how many different kinds of things can we taste?
If you said zillions, think again.
If you said four, then huzzah for remembering what we all learned in kindergarten.
What are they?
Sweet, sour, salty, bitter.
Well, it turns out that there is actually a fifth. It is sometimes described as "savory", "meaty", or "pungent", but the Japanese have a word for it: umami. And chemically it is the sensitivity to glutamic acid and its salts, the glutamates. Glutamic acid is one of the amino acids, found in abundance in protein.
This is an addendum to a previous journal entry.
This evening, on a news talk show about the impending invasion of Iraq, some ex-general type said something like
...the cost is going to increase, the cost in terms of humans lives are going to increase...
Don't get me wrong, wiki is a pretty cool idea. And in many ways, it's better than almost anything to which it might be reasonably compared.
But let's face it, wiki pretty much blows.
The problem? Scalability.
One of the other guys where I work, the chairman of a technical working group, decided to try using wiki as a collaboration tool as the group hammered out some revisions to a honking old document.
With only as few as three people working on the document -- some 100 different pages -- we had a problem with people overwriting each other's edits.
One part of the cause was a kind of social phenomenon: although there were around 100 pages in the wiki, at any given time only about 2 or 3 were actually of any interest to anyone. You know how it happens: one guy modifies a page; another guy checks to see what pages have been recently modified, notices that one, goes to check out what changed, and immediately wants to weigh in with his own changes. Get two guys doing that, and whammo! -- big headaches and discontent.
I'm now quite convinced that the wiki paradigm of editing whole web pages cannot reliably scale above exactly one author .
The real problem, of course, is locking. The lack thereof, that is.
So, just for the heck of it, I created a syntax highlighting module for english. (This is for vim, of course -- the only real editor.
It works well enough, but:
a) it takes almost 10 minutes to highlight a screen-full of english text on my 1 GHz linux box; and
b) the result appears -- at a casual peruse, anyway -- to be little more useful than if the words were highlighted with random colors!
Well, I've started dabbling in Tcl. It's something I've been meaning to do for Quite Some Time Now.
I have to say that the experience, over all, has been very satisfactory and non-frustrating. That is, it has not been what I expected it to be!
The Scary Thing About Tcl, as Perl hackers are typically led to believe, is its Obnoxious Shell-like Whitespace-based Parsage. Also its Ubiquitous Symbolic References. And "Variable Scoping is Hacked and Twisted, so Use Global Variables For Your Mental Health".
But in practice, I find that Tcl has an elegant -- if imperfect -- consistency that is easy to program in. Yes, it's been a mental adjustment, but not a huge one.
One of the things I like about Tcl is its Lispiness. Essentially, square braces are eval'ed like lists in Lisp, and curly braces are like quoted lists. A block of code is just a block of terms that might (might!) get sent to the eval function. In fact, Tcl's syntax is extremely reminiscent of Lisp's. (One thing that's different is Tcl's (less than desirable) sensitivity to newlines.)
I also like Tcl's built-in support for event loops.
Basically what it boils down to is that all the things I've heard people say to try to scare me away from Tcl have turned out to be bogus.
That's not to say there aren't a few good reasons to continue using Perl... but mostly they're cultural, or community things. The one thing about perl that can be said to be qualitatively better, as a language, is that it is possible to write things much more tersely. Well, I'm sure there are others. I'm sure the Tcl regex engine hasn't kept up with Perl's, for example.
Wanting to get caught up on various perl.org-based mailing lists, I thought I'd just download the archives in mbox format and view them in my local mail reader.
Not so fast.
Turns out the mailing lists are managed with ezmlm, which stores the messages in a format other than mbox.
So I asked Ask what it would take to bring that capability to reality. He told me, and I volunteered to do it. So I was up until about 2:30 last night banging out a script which converts from maildir format to mbox.
I thought about trying to use the tools that come with ezmlm, or maybe the Mail::Ezmlm wrapper module... But it turns out that this conversion is too simple to require that approach. Basically, every message is stored in its own file, and the files are shoved down in a directory structure that seems to have no more purpose than to keep any given directory from having too many files in it. Also, each directory contains an index file.
So, essentially, converting that to mbox format takes nothing more than concatenating all the files of interest into one file.
But there are (of course) a few glitches.
First and foremost, the messages as stored do not have the initial 'From ' line. So, I process each file through formail -a Date:, which fabricates a 'From ' line, containing the info from the Date: header.
Then I process each file through a little loop of perl which parses the date (using the handy Date::Manip module) and reformats it into the correct format required for 'From ' lines.
The second issue is filtering down the messages to just those of interest. In this case, I want to select only those whose date is in a given year/month timeframe (specified by the user).
Anyway, the script works pretty nicely. It's not particularly fast. In my test, it takes 13 seconds (user) to read in 1300 messages and process 200 messages through formail out to the mbox. The main overhead is probably spawning and reading from formail. Considering how little it actually does, I should probably replace it with some perl. Some more performance hit probably comes from using Date::Manip to parse and reformat dates. But man, the flexibility! It can understand just about anything you throw at it. For example, to convert the current month's messages, you can specify "today" rather than an explicit year and month.
O.k., replaced the formail bit with perl code to create the 'From ' line. Shaved about 10% off the time. But remember that this step is only done for the messages which match the interest criteria. In general, the number of matching messages will be much less than the total number of messages in the archive.
Broke out the ol' Was (Not Was) this morning... Damn cool. Was is a geek for sure.
(The following lyrics have "Robot Girl" scattered throughout; I've omitted them for clarity.)
TV screen faces are'nt pretty, it's true
She will do anything I tell her to
Her conversation's not what you'd call clever
But she can't contradict me, oh no never
Move your arms a few degrees more
Now gently back and forth
You know just where to scratch
We're such a perfect match
I'm in a whirl - You're my robot girl
Programmed for love, she can be quite tender
Treat her unkind, nothing offends her
She vacuums the carpet and doesn't complain
She'll walk the dog in the pouring rain
You are my world - You're my robot girl
Don't have to worry about diamonds and furs
There's no confusion about what's mine and what's hers
When she fixes her lens on my bedside I shudder
She goes through my blood like a hot knife through butter
This is one that is not very common in ordinary usage, but which seems to recur like a bad rash in bureaucratese and militarese.
Apparently some technical writers have an aversion to the more usual (and more correct) "including".
Granted, "to include" can be right in certain contexts -- specifically, when describing a future/potential situation, as in some kind of specification. E.g.:
The vessel shall be capable of containing, with zero leakage, a variety of solvents, to include water, ethanol, and benzene.
Problem is, some people conclude that it therefore makes sense in every context. Consider:
Medieval lords employed cruel tactics to keep serfs in subjugation, to include torture, whimsical justice, and extreme taxation.
And the list goes on...
O.k., people, it's not "extendable", it's "extensible".
I think people just think they take the infinitive form, and add "-able".
And I just read in another journal (which shall remain anonymous) the word "undefendable".
Cripes. "Defensible", "indefensible".
Make a note of it.
(CAUTION: SPOILER BELOW)
We watched Mulholland Drive last Sunday (yesterday), and it has me pretty freaked. I mean, WTF is going on in that movie? I really liked Lost Highway, and there are plenty of similarities between the two (almost too many, one might opine), but at least with Lost Highway I was able to fit the ends of the mobius strip together and make it make sense. Mulholland Drive just has too much bizarre, unconnected stuff, it's too much of a puzzle for me. I think I might have to watch it a time or two more. One web site I found (google search: "mulholland drive what the fuck is going on") does a pretty good job of putting some of the bigger pieces into place, such as that the second part of the movie is "real", i.e. Diane is the real person, and the events shown really happen, while the first part is Diane's dream or fantasy, and Betty is her persona in that dream.
Actually, given that the first part is a paranoid hallucination, there's not a lot of point in making it all make sense. But still... why would Diane include, as part of her fantasy, finding herself dead and decomposing in her bed?
And also, Diane's neighbor comes to the door and says that Diane has been missed for three weeks. Where did those three weeks go? Was she magically asleep, only to be awakened by the Cowboy? And what's all that about, anyway?
Actually, it doesn't make sense to say that the second part is more "real" than the first part. I mean, the homeless guy has the blue cube? And when he drops it, the tiny loony old folks come out, and get into Diane's apartment, and terrorize her?