Well, that's it. Finally going on the road trip. I'll probably be inaccessible for the next week or so. At least, I'd better be! It'd be lame if I sat around and/or didn't use this opportunity to unplug.
Matrix: Part VOIP, and Return of VOIP. This goes right along with what I've been saying. 
Thanks Matt.
Glenn Reynolds does a good job of pointing out the hypocrisy of those like Chuck Schumer, who are strong advocates for taking guns out of the hands of citizens, but who can afford to travel with armed bodyguards.
... but you see, Schumer's life is important. He needs the protection. It's not like he's just some single mother working late at a convenience store or something.
Examples like this can be multiplied many times over. Hypocrites like Schumer value their own lives over those who, for some reason, continue to elect them, and who they take an oath to serve.
Check out Ronaldo's post on the evolution of programming languages. There's a lot there. Worth a read.
Woo, SharpReader 0.9.0.2 has been released
Favorite new feature by far: "Auto-display linked webpage in mini-browser if no description present in feed". Feeds like Slashdot, Mozillazine, etc. now aren't as much of a pain to read.
Also includes gzip compression support, he fixed the annoying "browser refresh when feed-refresh comes in", and it now uses the system default browser instead of just IE whenever it can.
I don't understand yet what the changes he made to the threading feature mean.
Ah, get it now.
I figured I'd throw this out there. This explains what the last remaining difficulty in my StructuredText parser is.
The problem is this... if you have tokens which are made up of the same characters, the parser needs to do a better job of figuring out which one opens and which one closes. It has to DWIM better than it's doing. So, if you have bold be '*', and italic be '*', and have a line like ***bold italic* italic* or ***bold italic* bold** it's got to be able to parse both correctly
My regular expressions in my current parser do that correctly, so when I get a chance to dive into it I should be able to make what worked for my regular expressions work for my new parser without regular expressions. How hard it's going to be to code depends on whether the regular expressions worked because of backtracking.
I think part of the solution is going to be to, for a given open or close tag (such as '*'), look at what other tags share that character, and simply make sure that it can only be one tag. That is, to make sure it's not ambiguous. This involves precedence rules to disambiguate, such as "short tags match first", so that '*' will match before '*', and it shouldn't involve searching around more than a few characters. Hopefully, it will only involve code when matching an opening tag, and hopefully it'll only involve looking *forward, and not back. We'll see.
By the way, I've added a StructuredText page on my wiki to keep track of different StructuredText implementations. Also keep in mind that when I refer to StructuredText, that's not one set thing. I use "StructuredText" to refer to any plain text format that uses conventions to give structure to the markup without having to use a formal markup language like XML or LaTeX, etc.
new⇒Free image hosting sites
Well, TinyPic has this in itsFAQ:
> Images and videos is inyour accoun...
Keith: Dec 1, 1:13am