TruerWords Logo

Search TruerWords

This is one of my journal's many "channels."
This chanel only shows items related to "Customers."

Sign Up  Log On
Monday, May 4, 2009

Apple's Changes Can't Rattle These Bones

Last week I got an email from John Mello, a reporter working for Mac News World. He asked if, as a BBEdit user, I'd be willing to be interviewed for a story he was writing about Bare Bones. I said yes, and later we talked on the phone for about a half hour.

The article is now published, entitled Apple's Changes Can't Rattle These Bones. Kinda clever.

Among BBEdit's merits cited by the code warrior are its support of multiple languages, syntax coloring, code folding and HTML editing and preview, as well as speedy performance and powerful search features. Not only can it perform a search and replace on multiple files, but it will display the results of a search in a separate window for easy review and manipulation.

Hey he called me a code warrior. That's so much nicer than code monkey! (I'm mentioned by name a couple paragraphs earlier.)

The article is, um… a bit fluffy. It never claims to be otherwise! You can't do a one-page "company profile" as hard news.

He never mentioned my rant about email clients, even though we talked about them extensively. (No surprise he didn't mention it, I really do rant.) I was slightly surprised to find that he never mentioned my relationship with the company (which is currently on hold, but hopefully not for long...). Sean was surprised, too.

A significant point I made in our conversation ("interview") that I honestly thought he'd cover: all the editors give you a decent space to type your code. You don't differentiate editors based on which one gives you the best typing experience. Know what I mean? All of the good editors provide a decent space for entering your text. What matters to me is all the other stuff that I expect of my editor: language support, syntax coloring, code folding, performance and — perhaps most important of all — really powerful search and replace.

Anyway, I don't seem to get into the news these days for anything except the PMC, so it was cool for that alone, if nothing else. :-)

Monday, March 31, 2008

Other BBEdit Language Modules

Rich read the Why I Wrote a JavaScript Module for BBEdit story, but like everyone else at Bare Bones decided to respond to me directly instead of posting something on the site. (Jim Correia has been guilty of this so many times it's now an old joke.) Anyway, he suggests that list the other languages/modules I've added to BBEdit since the JavaScript module

They are, in no particular order:

  • Strings (for MacOS X developers)
  • Python
  • Markdown
  • SQL (five flavors)
  • Ruby
  • Java
  • TeX
  • Lua
  • YAML

My favorite is still the JavaScript module. My least favorite is definitely the Markdown module (see's source code and look for the author's comment, "This is an aspect of Markdown's syntax that's hard to parse perfectly without resorting to mind-reading" and maybe you'll understand my issues with it.)

My second favorite is the Python module, because Guido van Rossum wrote the gold standard of language specifications. He doesn't just describe the language syntax with near perfect clarity, he also has implementor hints! It's like he was in the room with me when I wrote that module, telling me what I should do here or there. His work made my work better, and there have been very few bugs reported in the Python module since its release.

My second least favorite module is YAML, for the same (or opposite) reason. The specification is obtuse, repetitive, unclear and unrealistic. It's full of internal language which you can only comprehend by looking for definitions elsewhere in the document, and inevitably those definitions have more internal language. (I'm working on an update to the YAML module, and the authors of YAML actually admitted to these problems in several IRC chats we had in the last few weeks).

I have various other unfinished language modules sitting around on my computer, waiting for me to make time for them, but all of the above have been released with BBEdit 8.5, 8.6, or 8.7.

Wednesday, December 19, 2007

BBEdit 8.7.2 Released Today

Bare Bones just released version 8.7.2 of BBEdit. This is a free maintenance update for anyone who owns a license to 8.5 or newer. Here are the release notes.

I had a small hand in this update. In the release notes is a list of fixed bugs, two of which are mine:

  • Fixed bug in which TeX syntax coloring would get out of whack if "Color Math Strings" was turned off and the scanner encountered certain constructs in the document.

  • Fixed bug in which the JavaScript function scanner could crash on certain malformed (usually because of in-progress edits) constructs.

There's lots more good stuff in store (way more than just bug fixes!), but some of the fixes in this release needed to get into people's hands sooner than later.

(Remember the BBEdit Disclaimer.)

Monday, November 12, 2007

Faster Code (Converting HTML to Text)

Over the years I've written this code in a few different languages: take some HTML input, process it according to some of the basic rules a browser would use, and spit out plain text (no tags or HTML entities). By "basic rules a browser would use," I mean that e.g. a series of <p> tags should not result in a long blank gap, but a series of <br /> tags should. Line breaks (r or n) don't matter except within a pre-formatted section. Etc., etc.

My first attempt, I think, was in straight UserTalk. Then i rewrote it a couple of times with regular expressions (still UserTalk) to make it faster. Then a client needed it in a language that could be used on any Mac OS X box, so I rewrote it in Perl, which was faster still (and was much better about converting the HTML entities to UniCode).

The Perl script uses lots of regular expressions, and so makes many passes over the input, changing the text in place. It worked well enough for most HTML, but long documents with a very high ratio of tags-to-text (that is, very tag heavy) would process very slowly. Unfortunately the script was run automatically in the background by a "regular" GUI application, and so the app would seem to freeze up for a little while as it processed one of these pathological cases.

Over the last week I rewrote it again, this time in pure C++. It's a command line tool with the same basic interface that the Perl script had: you can pass it an argument to specify the input file and output files. Omitting either one causes it to use standard input and/or output.

The new tool makes a single pass through the text, doesn't use any regular expressions, and generates slightly better output. Actually, it's more honest to say that it makes three passes through the text: first it converts UTF-8 to UTF-16 (but that's an OS API service), then it processes the UTF-16, then it converts back to UTF-8 (again, just done by the OS) for output.

The timing results speak for themselves. These tests use the worst, most pathological example we had. It's a 200 KB file that's about 90% tags (specifically, it's a long email exchange where everybody top-posted and quoted everything else, and everyone used HTML messages.)

$ time - < ./striphtmltags.input.html > ./striphtmltags.output.txt # old one
real    0m20.201s
user    0m19.774s
sys     0m0.352s
$ time newstriphtml < ./striphtmltags.input.html > ./striphtmltags.output.txt # new one
real    0m0.048s
user    0m0.039s
sys     0m0.010s

They wanted it faster. For this worst-case scenario, it's 420 times faster. Zoom.

Wednesday, April 25, 2007

Firefox? Isn't That a Movie?

One of my clients has recently signed up for an online shopping cart system to work with his catalog (which is based on Conversant).

When a customer buys something through this shopping cart system, they're shown a confirmation page with a link back to a specific page on the vendor's site. That's totally standard.

The link appears to use JavaScript to submit a form which POSTs the sale's data (minus the truly private info like credit card number) back to a page on the vendor's site. Still pretty common (except their implementation doesn't actually work).

They claim that it only works in IE. Not in Firefox, not in Safari, not in Opera. Why worry about those, they're just a small percentage of the marketplace, right?

I'm sorry, but those people are morons.

Without even testing it, I can tell you that they're wrong: it doesn't work in ANY browser, not even IE. How do I know? The link just runs the script, and the script just causes the browser to navigate to the vendor's thankyou page: it never does anything with the form at all.

The form is all hidden fields, looking something like this:

<form action="url/of/thank-you/page" name="postData">
<input type="hidden" name="firstName" value="Seth" />
etc., etc., etc.

The form's action is pointing to the correct URL... but the form is never used. The script looks like this:

function submitForm()
return true;

If you understood the above, then you know how easy it would be to fix:

function submitForm()
return true;

Sigh. (Even easier: do away with the javascript entirely, and replace the link with an actual submit button.)

December, 2017
Sun Mon Tue Wed Thu Fri Sat
  1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
May  Jan


Channel RSS: RSS Feed for channel

is Seth Dillingham's
personal web site.
More than the sum of my parts.