Really, it is a little encouraging that after so many years of staring at browsers, I can still thoroughly entertain myself on a Sunday afternoon by reading the homepages of total strangers.

However, if it's still winter, a north-eastern transplant to Southern California does have to be careful when reading accounts of wool coats, comforting snowfall and hot soup at just the right time. It's been a long time since I've actually wanted hot soup. Say what you will about the weather in San Diego - I was debating shorts when I walked out for my coffee today, and sandals were a given, but this kind of weather has never really supported a good bleak mood like a nice cold snowy day would, back home. Sunny blue skies have a way of making you feel ungrateful if your smile doesn't fit right today.

Now I realize why it seems like so many people here are healthier than the rest of America. If I can't maintain a satisfactory sulk under bright sun and pleasant breezes, I have to resort to working out. It'll do the job, but sometimes I really do miss the old way - a blanket and a book, with hollow curses aimed at the weather.

0.2

Review: My weblog editor of choice.





Mar 16, 2006

Michael McCracken

San Diego, CA 92109

product MarsEdit 1.1.2

MarsEdit was recently updated to version 1.1.2, with a few bug fixes. I really like MarsEdit - It does what I need and stays out of my way. I'm not the most demanding user - I have one WordPress weblog and don't keep up with the latest in blogging tools. I did have my own customized weblog editor, Blapp, that I used for years, so I was expecting to find plenty of things that annoyed me about a program that wasn't written just for me. To my surprise, it felt comfortable right away - I got started posting with MarsEdit quickly, and haven't had to learn about all kinds of features that I don't use. Thumbs up.

*[ Mar 16, 2006 ]: 20060316T1155-0800

Coverity, the company formed by the people behind the Stanford MC Checker, has started posting regular reports from their analysis tools on prominent open-source projects at scan.coverity.com.

I found out about this through an email from the Coverity CTO on the GCC mailing list, and it seems to have been received with some moderate enthusiasm. I think it's a good idea, but as usual the specter of false positives makes the developers itchy, especially when they're publishing bug counts...

Dawson Engler, the professor at Stanford who was behind all this bug-finding work (and co-founded Coverity) gave a talk recently here at CSE, about newer approaches to finding bugs that uses execution on symbolic inputs - meaning that you mark some inputs to a program as symbolic, and somewhere there's a theorem prover that goes to work finding out if any value of those inputs can cause an error or a crash - then you can run the original code on the input to verify the problem. A nice consequence here is that the generated 'bad' input is then guaranteed to actually be bad, since you can test it and force the error.

There's a paper about that from Engler's group here, and apparently this PLDI 2005 paper from Bell Labs is very similar.

Here's Prof. Engler's slides from talks about the new work on bug finding and an entertaining talk about commercializing the MC Checker.

The Tomorrow's Professor Mailing List, a great resource for tips and info about what professors actually do (as opposed to what you learn in grad school), is now out in a weblog form, in case you'd rather read in an aggregator than a mail client: Tomorrow's Professor Blog

I'd recommend poking through the back issues - there's a lot of wisdom in there.

I don't remember, but I must have just shot off the couch. You see, when I caught the power cord of my Powerbook in between my toes, there was enough velocity to pull the laptop halfway across the table. It punted my full coffee mug into the hallway, contents flying everywhere.

The laptop caught some coffee, but avoided the full soaking that the rest of the table got, with the neat trick of being off the table by the time most of the coffee hit.

I'm just really glad that my carpet is brown right now.

Anyone else vote for a MagSafe retrofit accessory? I'd drop $29.95 for sure.

Herb Sutter, software architect at Microsoft, chair of the ISO C/C++ committee, and blogger, gave a talk this Monday about the impending concurrency revolution and his project, Concur, an extension to C style languages to support usable concurrent programming. I enjoyed his talk in spite of the job-fair atmosphere (it was also a Microsoft recruiting event) and having to stand the whole time, so I'd say it was a good talk.

Check out his article "The Free Lunch is Over" for a programmer's viewpoint on what to do with the processors we're currently faced with. This is a very exciting time for computing - parallelism has always been the future, and the future is finally now. I am increasingly convinced that as a programmer, if you resist learning how to program concurrent systems, then you will be obsolete very, very soon.

The reason is that processor architects have density to waste, but they have nearly run out of ways to use extra transistors to make single processors faster - so they're happily just shipping chips with bunches of smaller processors. According to intel's (nicely readable) Platform 2015 site, Dual and Quad-core isn't nearly the end - today's college freshman will likely start out their career programming not "multi-", but "many-core" systems (think 'at least hundreds'), requiring hundreds or thousands of independent threads of execution to avoid leaving performance on the table. Are we preparing students for this? I doubt it.

So, should we all run off and learn all about pthreads and mutexes? No - concurrent programming is really hard, even to get it almost right on a toy problem. In some areas (like servers and mathematics used for scientific computing), concurrency is a "well-understood" problem, but even there it's widely understood to be hard. No wonder everybody's been avoiding it.

This is really a problem for language designers, framework designers, and compiler writers - how do we build an environment where a reasonably competent developer can write and debug programs with a very high level of concurrency? For everyone else, just keep your eyes peeled - they're working on it.

To quote Maurice Herlihy, from an invited speech (ppt slides) at 2005's PLDI conference (for compiler writers and language jockeys), This situation amounts to a "PLDI Full-employment act". Interesting times, indeed!

A quick thought: why not wrap NSUndoManager to support adding scriptable hooks to almost any user action? Surely someone can think of a good scheme to let an application programmer support really thorough scriptability without tons of extra work...

I thought of this because I'd like a way to mark a To-do item for an email reply as completed once I'd sent the email, and a good way would be with an email-send hook in Apple Mail.

Okay that's it, thanks!

After reading Merlin Mann's suggestion to live in iCal, I thought that even though I don't use kGTD, it might be a good idea to try to limit the number of places where things I have to do exist. Following on the idea of moving lines of text from VoodooPad to iCal todos, I just wrote a script to take the frontmost email message and add a todo that reminds me to reply to it. I'm getting a little closer to just having one place I need to check tasks.

tell application "Mail"
    set l to the selection as list
    set selMesg to item 1 of l
    set cont to content of selMesg as string
    set subj to subject of selMesg as string
    set person to sender of selMesg as string
    tell application "iCal"
        set theCal to (first calendar whose title is "Email")
        set theString to "reply to " & person & " about " & subj
        make todo at end of todos of theCal with properties {priority:0, summary:theString}
    end tell
end tell

This ends up with a todo that says something like "reply to michael_mccracken@mac.com about Locations for the party of the century"

Of course, it's best invoked with a twitch and Quicksilver, so just drop it in ~/Library/Scripts so it gets indexed. I called it "NewTodoFromEmail" and Quicksilver calls it "nte". Clever.

I based it on my NewEventFromEmail script, which I still use regularly. So nice!

Hey, the O'Reilly Emerging Technology conference is in San Diego next week. I live in San Diego - but I can't even afford the deeply discounted student admissions. I'd go to see the microformats session, since I'm interested in seeing a good citation microformat develop.

If anyone I know or should know is in town for the conference and wants to hang out, I know a few good places to go - email me or something.

I take notes at meetings in VoodooPad, and as such I write a lot of to-do items in MeetingNotes pages. They tend to get buried in those pages unless I do something about it fast. Sometimes I put them somewhere more useful, like on my "TodoToday" page, but that page is getting more like a "TodoSomeday" page, and isn't fit for serious action items. Today I realized that I wanted a script to take line-items from VoodooPad pages and make them into Todo items in iCal, so I can track them easier.

I already have a Quicksilver plugin for creating new todos, so I repurposed it as a python plugin for VoodooPad to add a big list all at once. Check out Gus' post on python plugins for the enabler, and then check this sucker out:

VPScriptSuperMenuTitle = "Notes"
VPScriptMenuTitle = 'Create Todos in iCal'

import os

def main(windowController, *args, **kwargs):
    tv = windowController.textView()
    s = tv.string()
    ranges = tv.selectedRanges()

    scriptString = ""
    for r in ranges:
        rs = s.substringWithRange_(r.rangeValue())

        lines = rs.split("\n")
        for line in lines:
            if len(line) < 1: continue
            scriptString += "tell application \"iCal\"\n\
            set theCal to (first calendar whose title is \"Work\")\n\
            make todo at end of todos of theCal with properties\
            {priority:0, summary:\"%s\"}\n\
            end tell\n" % line

    f = os.popen("/usr/bin/osascript", 'w')
    f.write(scriptString)
    f.close()

Want to add to it? These and many things are easily imaginable:

• Change priority based on the first character of each line
• handle continuation lines better
• change calendar to select based on some simple syntax, like " foo" is a line with text "foo" but "foo bar" is a line with text "bar" destined for calendar "foo"...
• Another idea: a line starting with the words "email" or "mail" be made into a todo with the glyph ✉, and/or an actual email in Mail.app.
• Any other ideas?