Ontario, CA

My copy of Mac OS 10.4 is shipping from "ONTARIO, CA". What? Canada? Apple stuff usually comes from up by Oakland!

Turns out there's an ontario.ca.us down near Los Angeles. Presumably they mean that one rather than ontario.on.ca.

When I'm benevolent dictator, all these innumerable human settlements will get globally unique ids. I don't even see why ontario.ca.us needs a name; surely it's just part of Mega-City Two?


AirPort Extreme

This might have been obvious to everyone else, but it wasn't to me: although the AirPort Extreme base station can talk to 802.11b and 802.11g clients, it looks like the AirPort Extreme card can only talk to 802.11g base stations.

[Update: I was wrong. Two things fooled me. First, and silliest, is that networks that aren't broadcasting their ids don't show up in the list; that's what "Other..." is for. I knew that. Second, and most surprising, is that people in my building seem to turn their base stations off! I don't often look at the list, because I don't usually need to, but it turns out to have been pure coincidence that the 802.11b networks I was familiar with from my old PowerBook's menu weren't available. Thanks to Geoff and Nathan for convincing me to try harder!]


Me love you long time

Despite the relative paucity of Google matches for the phrase, I've heard it a lot. Reprobate friends, I guess. And pulp Vietnam war fiction.

Anyway, I always assumed "me love you long time" was the best translation of something along the lines of "I have admired you from afar for some time now" you could manage with little knowledge of English grammar but access to a dictionary. Except no-one's said anything even half that stupid since 1827. Not even me.

So I have wikipedia to thank, via a friend's comments on Thai-Burmese relations, for an article on Prositution in Thailand which has a far more plausible explanation:

sexual services ... generally divided into "short time" (at most a few hours) or "long time" (overnight).

So something like "my services are available for the duration of the night" is probably closer to the phrase's meaning, though that does seem very prosaic in comparison and unlikely to catch on.

Mac keyboards have two "delete" keys!

How could it have taken me so long to notice that backspace and delete are both labeled "delete" on Mac keyboards?

Or that alt-delete (either one, depending on the direction you want) removes a word in native text components? Control- or command-delete don't seem to do anything interesting, though.


Mac OS 10.4's "finally" features

I'm really looking forward to 10.4, but it's hard when reading about what's coming not to say "finally!"...

Enhanced Dock menu — "Quickly set an application or document to open automatically when you login to your Mac — straight from the Dock." Imagine that; they've unhidden the functionality, and put it with its close relative "Keep In Dock".

iCal — "Always know the birthdays of everyone in your Address Book with this automatic calendar in iCal ... Never miss another birthday because you didn’t transfer it from your contacts list to your daily planner. iCal 2.0 automatically displays birthdays listed in your Address Book right in your calendar. And adding or removing birthdays is easy: Make a change in your Address Book and iCal displays up-to-date birthday information."

But will it understand Outlook meeting requests? (Mail on 10.3 won't even show them, even though using telnet(1) to talk to the configured IMAP server shows they're there. Uncool.)

And will it finally check my spelling as I type? How hard is that? One call to setContinuousSpellCheckingEnabled: hard.

Mail — "Mail uses the Safari engine to format newly composed email using HTML." Scary, that one, with it's emphasis on "newly composed". Newly-composed email isn't my worry so much as forwarded or replied to mail, which Mail on 10.3 manages to mutilate most impressively, first stripping most of the formatting, then hard-wrapping at a fixed number of characters. And there's not even the work-around of "forward as attachment". Evil.

But at least we're getting parental controls and slideshows. In Mail. No, seriously.

ksh — "More easily run scripts written for Sun Solaris or similar systems now that AT&T’s ksh is now bundled with Mac OS X." Let the dead bury the dead, dudes. I just hope we also get something useful like GNU make 3.80. And speaking of the dead, a CVS from this century, rather than 1.10 (I wouldn't touch CVS myself, but I need it for other people's projects sometimes).

VPN — "Stay connected to a VPN server when switching user accounts or logging out, and direct all network traffic through the VPN connection." Finally! Like I wanted to have to mess with gateways and routing, just to surf the web or listen to streaming radio when working from home. If I was in to that kind of nonsense, I'd be running Linux.

Tamil support — I wonder if being a "world citizen" means 10.4 will be able to use ISO standard date format? 10.3 can't even get close, for the "long format". Time zones would be handy, too. In Mail, what does "On Jan 17, 2005, at 09:25" mean? Is that now, or was that 8 hours ago in a different country?

Network-based home directories — "Access a network-based home directory even when offline, then automatically sync your work when you reconnect to the server." This might be cool. Or it might require a .mac subscription, like most of the rest of Mac OS' synchronization features. ("Feature" seems too strong a word for something you have to pay extra to use.)

Dictionary — "Quickly find definitions by typing all or part of a word. View the same word in the thesaurus to find synonyms, antonyms and more. Since the dictionary and thesaurus are built into Mac OS X, you don’t even need an Internet connection." I was disappointed this wasn't in 10.1 (the first version of Mac OS I used), since it had been one of the things that impressed me about the NeXT. Better late than never.

The unit converter dashboard widget hopefully means the end of the awful abortion of a converter that's in 10.3's Calculator.

Java — oh, actually, we're still on 1.4.2, but hopefully we'll see 1.5.0 before long.

Don't get me wrong. I love Mac OS. It's the least worst OS by far. It's much better than anything else I've used. But it's not perfect, and in some areas it's still incredibly weak. And Apple being Apple, you've absolutely no idea whether or not they care until something changes.


Editors don't need a getCaretPosition method

There are lots of well known convenient simplifications/generalizations when writing text editors.

For example: the selection is just a special case of a range highlighter, which is a concept useful for displaying find matches or misspellings and so on.

Or: there's no need to keep track of an insertion point and a selected range; the former is the special case of the empty selection. (Though as far as I know, if you want traditional keyboard selection, you will have to keep track of which end is the anchor.)

And: the one true primitive is replaceRange; a removal is a replaceRange with an empty replacement, an insertion is a replaceRange with an empty range.

They're all pretty traditional, but there's one I hadn't come across until our latest editor-writing adventure: not only don't you need getCaretPosition, you're better off without it. If you can't ask where the caret is, you're forced to think about the selection. What does the operation I'm writing mean if there's a non-empty selection? Do I want the selection start, the selection end, or do I want to behave differently depending on whether the selection's empty or non-empty?

Maybe others have more natural discipline than I do, but I've found not having getCaretPosition a really useful way to force me to think about both cases, where I wouldn't have done previously.


Urbano - Love Me Tonight

You know how embarrassing it is to see yourself on video, or hear your voice, or even read something you wrote, if it was long enough ago. The way it's both recognizable and alien at the same time, and for some reason worse than you imagined?

One reason I prefer only offering nightly builds and web pages rather than "releases" and paper documents is that you can keep revising indefinitely. Hopefully in a pleasing direction. Publishing pushes you in the direction of foolish consistency. I was never impressed by Emerson, but "be prepared to admit you were wrong" sounds like good advice.

I find it interesting that wikipedia's Ralph Waldo Emerson article gives more context than you usually get, but they only quote from after the "foolish consistency" sentence. To me, the paragraphs before and after seem to say very different things. Those before are eminently reasonable warnings against sticking to ideas that are wrong. Those after are typical of what I disliked about him, and really go overboard against consistency, almost as if any consistency – rather than just foolish consistency – were a mistake.

I think "Self Reliance" could have done with a few bug reports and a new nightly. Or a better author.

But that wasn't what I wanted to talk about. I wanted to talk about a eurodance track, "Love Me Tonight", by Urbano. I rather like the track, but I always feel sorry for the female vocalist, and hope she never learns enough English to understand that (a) the words make next to no sense, and (b) how idiosyncratic her pronunciation is. I'm used to eurodance and vocal trance lyrics making no sense, so it was a while before I realized that slight changes to pronunciation help a lot:

aks [ask] me questions
a hand that sows [shows] a way
stars in the sky gonna sine [shine] any more
take me off the hates [heights]

Poor thing. You'd think she'd have known someone who could have helped her. But then, anywhere I've ever been there's always been at least one native English speaker.


Eclipse's new clothes

I found Why Eclipse Developers Are Moving To NetBeans interesting. I've tried Eclipse several times, and each time it's been too slow and clunky for me to want to learn to use it. And the only other people I know who've used it say the same.

And yet all the time we hear how great SWT is. I've even tried writing little programs with SWT, and found it nothing more than a world of pain. I put that down to me being a Mac user, and maybe things were okay if you were on Linux, but the article suggests not.

At the same time, I and some friends have been working on a more-or-less source compatible replacement for JTextArea more suited for the kind of editing programmers do, and I've been really impressed with the performance you can get out of AWT/Swing.

(Especially on MS Windows! My dual G5 with a 128 MiB ATI Radeon 9600 XT is significantly slower than a random Dell box with motherboard graphics at work; a machine that feels like a dog. Where "significantly" means about 6 ms to redraw a window full of text, versus 0 ms. I should switch to currentTimeNanos [oh, sorry, they called it nanoTime, the damned buffoons!] to see how long the PC is actually taking. Graphics performance was something Apple regressed on in 1.4, and hopefully it will be better in 1.5 when we get it. I wonder how much of MS Windows' perceived bad performance in general is actually just because they're terrible at giving good feedback. The whole experience is so jittery that you don't notice that lots of things are actually quite fast.)

Anyway, I'll shed no tear if SWT dies before I have to worry my pretty little head about it. What I saw of the API didn't look very pleasant (unless you miss the home computers of the 1980s), the implementation sucked on Mac OS, and who wanted to install more crap to run a Java application?

Good riddance to SWT; IBM's programmers did enough damage giving Java some of its cruftiest classes; horrors like java.util.Calendar and java.text.MessageFormat. They have their work cut out to regain my trust in them, and SWT wasn't a good way to try.


DIY versus rapid development

Not so long ago, Slashdot had a link to something by the CEO of Wind River: five things you can do to avoid becoming roadkill. The first of his five things to do (I didn't see any particular reason to assume that he considered it the most important) was to "get over Do It Yourself".

He claimed that using your own code instead of off-the-shelf code is too risky and too time consuming.

Like all generalizations (including this one), this is wrong.

One of the Big Things They Don't Teach In School is that everything in life is a trade-off. Ignoring the wider applicability of this, just look at a few of the computer science examples: using more space to save time, spending more time now to save time later, implementing a more complex algorithm to save time or space, implementing wanted new functionality at the cost of stability (hopefully only in the short term), implementing new functionality at the risk of unwanted interactions with existing functionality, adding ugly hacks for compatibility with something widespread but broken... We all do these things, pretty much all the time.

And writing your own code versus using someone else's is no different. I don't tend to think very concretely, so as practice I'll force myself here to explain what I mean with an example. Since 1997, I've used an editor, Edit that I wrote with friends of mine. Initially, it was a Java implementation of wily, itself a Free Unix/X11 implementation of Pike's acme. Since then it's diverged quite a bit.

The first version used a home-grown text component. Swing wasn't out yet, and the off-the-shelf solution of the time, AWT's TextArea didn't offer a suitable interface (both from a UI perspective and from an implementation perspective) for a lot of the stuff we wanted to do. So at that point, there was no choice.

After a few years, we decided that Swing's JTextArea was probably good enough, and that rather than fix a few bugs that had been annoying us, and rather than do anything about our unusual acme-like scroll bars, we'd just switch to JTextArea. Which we did. And that was okay, except now we didn't have our bugs; we had Sun's bugs. And sometimes there were work-arounds, and sometimes there weren't. When there were, they cost us both in the time and experimentation to find them, and in the time and resulting complexity of using the work-arounds. As I'm sure you know, work-arounds aren't generally the nicest chunks of code in any project.

A good example of a hard problem is that the up-arrow on the top line of a JTextArea doesn't work. Any other text component interprets this as moving the insertion point to the beginning of the document. JTextArea just does nothing. I think it did work in 1.3, but it's been broken ever since, with a bug on the bug parade that I can't be bothered to find right now, and it's still broken in 1.5. And if you look at trying to work around it, you'll see that the particular method that needs fixing could hardly be in a more awkward place. I think it's a static method in a package-private class. Working around that kind of problem generally involves a lot of copy and paste, which introduces its own problems. Especially if other stuff gets fixed in the meantime, or you want to work on multiple Java versions.

If you think that's easy, I'd like to see a work-around that always (rather than mostly) works for the problem of the selection highlight not extending to the right-hand margin when the selection includes a the whole line.

After a while, we decided that we'd like to experiment with colored text. As you may know, JTextArea doesn't support that, but JTextPane does. Only there's a huge leap there from a relatively-lightweight plain text component to a big, slow, buggy text component intended to be able to implement word processors and HTML viewers. But we tried it anyway and vastly reduced the maximum size of file we could open, and vastly increased the time various operations took. The best part, though, was that we couldn't really implement the coloring we wanted, because we couldn't manage to safely batch style mutations to avoid causing a lot of redrawing. I know there's a toy example in the SwingSet demo, but it's a joke. "Please wait" while it applies the coloring? And editing disabled? They may as well have a notice there saying "we know this is too slow to be useful, but we don't intend fixing it, so get lost".

If you can't re-color the whole of a 22,000 line C++ source file from Mozilla because someone's opened a comment near the start so quickly that it doesn't feel any different from typing the first character in an empty file, you're not useful. Because the world is full of poor bastards who have to edit those kinds of files. (Much of Edit's focus is on making it easier to get around large files and large codebases.)

So we went back to JTextArea. And now we're working on a text component of our own. A less buggy, slightly better-featured equivalent of JTextArea. We considered using whatever JEdit uses, but when we looked, it didn't support wrapping (that seems to be another preference that distinguishes Unix and MS Windows users), and it was really tied into that particular editor. We want something we can use in all our other projects, and that others can use in their projects too, without too much hassle.

I think, if we were starting Edit today, we'd start with JTextArea. There's no question that it's good enough for an initial implementation, and the advantage of being able to spend your time working on the editor's features rather than on a text component is a huge one. And don't get me wrong: I learned from the Swing text components that treating the selection as a special case of a more general notion of highlighters is very powerful, and I wouldn't want to use a text component that didn't support highlighters.

But sooner or later, we'd end up writing our own. There would be enough pressure for coloring, say, or we'd get sufficiently sick of all those little bugs that don't seem so important when the text component isn't the main focus of your application, but when you're using it all day every day can really get to you. (The JTextArea bug where sometimes a selected line will only render the selection highlight, and not the text, is the scariest.)

And yes, I do see the humor in using Yet Another Text Editor as an example in an explanation of why there will always be room for DIY. But James Gosling wrote (since he started blogging, most of his papers have been unavailable, so I'll have to paraphrase what I remember rather than quote and link) that it's naive to expect to not have to implement your application's fundamental class yourself. This may be because you're doing something sufficiently new that by definition you can't use someone else's code, or it may be because you need millions of something [I think Java's lack of user-defined value types was his specific context]; the traditional example of not building a spreadsheet from your system's grid container of your system's text field, because neither was likely to have been designed for use on the scale you're thinking of.

So, after explaining myself through an example, I'm left wondering if what the guy really meant was "you probably want to use an off-the-shelf OS", but didn't want to say that as an OS vendor, and abstracted his message to a point where it made no sense. That interpretation would certainly explain "when you contribute to differentiated value, you're also differentiating yourself. You become visible and invaluable instead of out of date, cranky, quaint." He's recommending knowledge of something like RTLinux instead of your own task scheduler, rather than suggesting that you won't learn anything from having written an editor or a compiler, or even your own task scheduler. (And pointing out that although the implementor of the home-grown scheduler learns useful lessons, those who have to use it just learn arcana that no-one cares about and that won't be much use anywhere else.)

It may have taken me several weeks and over 1,000 words, but I think I get what he was trying to say now. If only he'd had the confidence to say what he meant. I'm sure no-one would have held it against him if he'd mentioned (say) RTLinux every time he'd mentioned his own product.



Perfume's a funny thing. The sense of smell in general is pretty weird, but I think perfume is the best example of how weird. I can picture someone's face (though this does fade if you don't see them), I can hear their voice in my head (especially if I'm reading something they've written; it's almost as if they're reading it to me), but I can't even describe a smell as distinctive as a perfume.

And then, after as little as one date, you can be in a crowd – at a cinema, say – and you find your head turning and your face switching to it's "I'm pleased to see you" expression before you even realize that it's a perfume that's done it. And the back of the woman you're staring at is the back of someone totally unfamiliar, because you don't know her; you just know her perfume.

I remember when I was younger, the first time I had this experience, worrying that there would come a point where I wouldn't be able to walk through a crowd. Too many women who walked by would remind me in an olfactory manner of someone, and I'd find myself snapping my head round to greet the evaporator of the familiar smell, and not have time to replace my expression with one of bemusement or amusement before the next came along.

But it didn't happen. Either I only have the ability to remember one at a time, or the association fades fast enough that I've never had two around at once. (My suspicion is that it's one at a time, at least for me, because you'll notice I talk about perfume in the singular, as if there's a one-to-zero-or-one mapping from women to perfumes, which isn't true. And maybe that's why I have a favorite in one-to-many cases; that there's only one I can remember. I wonder how that's chosen?)

So although I'm often annoyed that I can't remember exactly what people or things look like, and I often wish I could remember exactly what was said, or the exact wording of something I've read (if Google can index 8 billion pages, why can't I index my paltry life?), I'm glad I can't remember perfumes. It would only be a liability.

I also think it's interesting that the perfume-person association's so strong. Like any smell you're exposed to for an extended period, you soon stop noticing a woman's perfume. And yet presumably the sensitivity continues, because the association grows. Or maybe it's just repetition. There's the bell in our noses, there's the saliva in our mouths...

This wasn't what I intended writing about.