Ray Gun Robot

On Cyber Monday, I was looking through Mail’s spam folder and noticed some bacn from VMware, creators of virtualizator (?) VMware Fusion, letting me know that, with a special coupon code, I’d be able to get Fusion for half its typical $80 price. I took the bait and bought it.

Since I don’t have any copies of Windows, so far I’ve been using it to experiment with FreeBSD 7. However, I’ve got to say that, compared to the older version of competing product Parallels Desktop I have at work, I’m quite disappointed with VMware’s support of FreeBSD (and glad I didn’t pay full price for it). Now I didn’t totally expect FreeBSD to be a first-class citizen on a tool primarily advertised as something which lets you RUN WINDOWS ON YOUR MAC!!!!!!one, but I did expect a level of support at least comparable with its competitor.

Nonetheless, I’ve managed to get it working to a certain extent, thanks to various IRC channels, forums, and handbook pages. I’ve been taking rough notes on the process and may post them soon. (Update: Those notes are now posted at Running FreeBSD 7 in VMware Fusion 2.) But let’s start off with a list of annoying things about VMware Fusion which are making life unnecessarily difficult.

• The Command key is, for whatever ungodly reason, sent to the virtual machine as a press of the Escape key. If the virtual machine has focus and you want to return focus back to your machine, VMware wants you to press Command-Control. Command-tabbing to another application works as well. However, both of these will send an Escape key press to the system, causing me to accidentally close dialog boxes and menus and such I wanted open while I looked stuff up on the interbutts back on the Mac side. This also makes it difficult to take screen shots. For Frank’s sake, how did that one get past beta testing?!

• As an extension of that: When I want to shut down the virtual machine, I run halt. FreeBSD cleans up after itself and then says something to the extent of “System halted. Press any key to reboot.” So I press Command-Control to get control to my Mac pointer back so I can tell VMware to shut down the system - and doing so sends an Escape key, causing the system to reboot itself. FFFFFFUUUUU-

• And yet another focus annoyance: When VMware is the front app, mousing over the VM window causes focus to shift to the VM, whether you want it to or not. Not clicking; just mousing over. Even on FreeBSD before I have X running and the mouse does absolutely nothing anyway. So I go up to the menu bar and open a menu; it drops down over the VM window. I select a menu item. The menu disappears, and now my pointer is over the VM window and the machine takes focus. But I want to select another menu item, so I press Command-Control - and escape out of a dialog box in the VM I was trying to keep open. Headdesk.

• Parallels has a menu which lets you send various keys and key combinations uncommon on modern Mac keyboards, such as Scroll Lock - which is essential when you need to scroll through output in FreeBSD’s text mode to see where something went wrong. VMware only lets you send Control-Alt-(Forward-)Delete. If I want to send Scroll Lock, I need to press F15 - which isn’t present on my MacBook Pro’s keyboard. Similarly, using Alt-Fx to switch between virtual terminals only seems to work with my external keyboard.

• No matter what OS you’re running, apparently, FreeBSD puts an annoying message in the VM window’s status bar telling you to install VMware Tools (the relevance of which thus far escapes me). You’re supposed to be able to do this just by selecting a “Install VMware Tools” menu item and then mnt /cdroming. During this process, you’ll be told that you’re logging in remotely even iwhenf you’re not and asked if you want to continue. Also, the installation will actually fail until you first install a FreeBSD 6 compatibility package and then ln -s a file from that package to a place where VMware Tools expects it to be.

Dammit! Fusion 2 got some great reviews when it came out, but I can see now that it’s likely that the reviewers just tested it with Windows, and maybe that youbuntuh thing for ten minutes or so.

Note to fellow BSD fans: Don’t make my mistake. Buy Parallels instead.

EDIT: A perfectly reasonable reply to my vitriol would be to point out that VMware Fusion has a demo available and that I should have used that to verify that FreeBSD would work well on it before I paid. Indeed, I had downloaded the Fusion demo; that’s how I got on the bacn list. But clearly I didn’t play with it enough before I paid up. So my frustration is partially my own fault, I know. That being said, there’s still a lot that could be done by VMware to make FreeBSD in Fusion a less painful experience, and hopefully this post, warts and all, makes some of those things apparent.

There’s some kerfluffle in the community for the Python programming language. I would not be among that community; I experimented with Python for a bit, and didn’t hate it, but I also played with Ruby and found it to be more my style - but ultimately went crying back to PHP due to its ease of setup and omnipresence among web hosts. But for others, that’s not an obstacle. To each their own.

Anyway, the contention is about the recent release of the Python 3.0 interpreter. This version of the language breaks backward compatibility bi-directionally; code written for previous versions of the Python interpreter will generally not work with the Python 3.0, and code written for Python 3.0 will not run on previous versions of the interpreter.

The changes in the new version of the language are quite extensive. Many antiquated or redundant libraries were tossed out, and standard 8-bit Python string types were obliterated - all strings are in Unicode now.

The changes are going to mean bajillions of man-hours of labor to convert older codebases to the new system. Many Python-powered web sites use a framework such as Django or Pylons; the substantial codebases of these frameworks are going to have to be rewritten themselves before the sites using them can take advantage of Python 3’s improvements. It’s quite likely that many of these larger projects are going to be maintaining two codebases for a while (just as the Python organization themselves are) - one for Python 2.6 users, and another for Python 3.0 users.

For some, this is ludicrous. Python user Jens Alfke asks, on his blog, “Python 3.0: What’s The Point?” He argues that the improvements to the language are not worth the jarring and rewriting the 3.0 transition is going to cause.

On the other side one James Bennett, who titles his post, “Let’s talk about Python 3.0.” With a humorous story about monkeys, bananas and a fire hose, Bennett makes the argument that Python and its users are going to end up for the best in the end by implementing Python 3.0’s improvements now rather than later.

I see parallels with Drupal. With every major Drupal release, changes to the API mean that modules and templates for the previous version are not likely to work with the current one - and this is happening every eighteen months or so when a new major version of Drupal is released. Many developers have difficulty working with this concept. The result is that, even though Drupal 6 is the current version (its first standard release was in February) and Drupal 7 development is occurring full steam ahead, Drupal’s own main site still frequently showcases on its front page sites built with Drupal 5 - and the Drupal.org site itself is still using Drupal 5. Gradual process in the porting of many frequently-used modules such as Views to Drupal 6 forced many site admins to wait until the modules they depended on were upgraded before taking the plunge. In the [Drupal modules] and themes directory, you will to this day find many projects which do not have Drupal 6 versions available, even in pre-release form - and every once in a while you’ll come across a project which doesn’t even have a Drupal 5 version available, the coder instead going no further than one of the Drupal 4.x releases. It’s aggravating sometimes, and it’s going to all happen again when Drupal 7 is released.

And yes, some people whine and complain that all this updating and breakage is doing more harm than good. But I side with Bennett and those who think of the progress as a feature, not a bug. From a programmer’s perspective, the improvements in Drupal 6 over Drupal 5 are substantial - the menu system is much improved, and the improvements to the templating system are powerful and certainly make life easier. And when Drupal 7 hits, its new database interface is going to be a dream - but all Drupal 6 modules will have to be rewritten to take advantage of it.

But that’s progress. Look at the Mac. The transition from Mac OS 9 to Mac OS X required applications to be rewritten, sometimes substantially. The transition from PowerPC to Intel processors also caused some pain for Mac developers. Next around the bend is the transition to 64-bit codebases, which already has Adobe smarting. But the Mac is incalculably better than it was in the OS 9, PowerPC-only days - and it can keep its svelteness without Classic mode and Rosetta (backwards compatibility tech in OS X to run OS 9 and PowerPC apps, respectively) gunking it up.

Upgrades - and break-ups - can be painful. But life will be better if you do it sooner rather than later. Time to make a clean break, Python users.

I’ve written about Mac text editors before on the previous incarceration of Ray Gun Robot. My preferred editor, the one I use every day at work and home, is Smultron. It’s nice, for reasons I’ll get into, but I wouldn’t mind having a few features that more mature text editors have, such as syntax hinting (is it strpos($needle, $haystack) or strpos($haystack, $needle)?) and scriptability.

Inspired by a post entitled “Komodo vs Coda” (found via Planet Drupal) and subsequent comments, I recently spent some time looking over a selection of Mac text editors and IDEs, seeing what the alternatives were, as I periodically do. Unfortunately, what I found has convinced me to stick with Smultron still.

After a bit of consideration, I came up with four criteria that a text editor must have to be usable in my opinion. There are others, of course - syntax coloring, regular expression searching - but those features are common enough among all editors that dare call themselves such that I won’t bother mentioning them. Those criteria are:

1. Smart indenting. If I start a function by typing something like function foo($bar) {, the editor should be smart enough to realize what I’m doing and indent the next line by a tab stop to help keep my code tidy. Furthermore, if I end a function by typing a single } on a line, it should unindent that and the next line. (It would be really awesome if the editor could do that with array( declarations too, but I’ve gotten used to indenting those manually, unfortunately.)

2. Mac-like. It should support standard Mac keyboard commands; it should use standard Mac user interface widgets; it should support the standard OS X spell-checking dictionary; it should feel svelte and unbloated; etc. It should also work like a Mac app when it comes to keyboarding around the document: the Home/End key should take you to the top/bottom of the document, not the beginning/end of the line; the Page Up/Down keys should scroll the viewport without moving the cursor; etc. (See my post on Mac OO.o 3 for more rants about supposed Mac applications adopting Windows’ lousy (in my opinion) text editing interface.)

3. Vertical window splitting. Window splitting allows you to have two (or more) documents open in a window. This is handy when you want to work on HTML in one file and CSS in another file at the same time; or to refer to a database schema in one file while writing code in another file; or to work on a template file while referring to a code file… this feature offers a huge boost in convenience and productivity. Some editors only allow you to split horizontally, but I much prefer vertical splitting, especially nowadays that most displays are much wider than they are tall. Also, simply opening up two windows and displaying them side-by-side is not an acceptable alternative; you end up with redundant user interface widgets, and you can’t quickly and easily resize or minimize the windows at the same time when you need to get them out of the way. These problems are gone with true window splitting.

4. Reasonably priced. When I can go out and buy the latest 3D whizbang video game for $60 or less, ponying up over $100 for a text editor seems a little bit ridiculous. Granted, I may spend ten hours or less playing the video game, whereas the text editor will be used eight hours a day, five days a week, for the indeterminable future; still, I can’t imagine that the latter took all that many more man-hours to develop than the former. However, for the perfect text editor, I’ll pony up two days’ pay… it better be pretty waeome, though.

Okay. So here’s a snazzy chart showing how several OS X editors compare with regards to these features. Note that some of these might be a little off, as I haven’t actually used all of them; so on some of them I’m just guessing by the feature lists. Lemme know if I made any obvious mistakes. (The chart uses Japanese-style maru ◯ for “yes” and batsu × for “no” because I’m a nerd.)

This table is very basic, but it’s enough to see that some would-be-great editors have some glaring oversights which are stopping me from switching. TextMate has a lot of buzz and cred among Mac nerds, but the fact that it doesn’t support window splitting, vertically or otherwise, seems to me to be a staggeringly unacceptable omission to what is otherwise a slick and mature editor. Likewise with SubEthaEdit, which actually predates TextMate (if I recall correctly) and features support for the ability for two or more people to work on a file concurrently over a network - this strikes me as a rather esoteric feature, which makes the omission of a basic feature such as window splitting all the more annoying. (SubEthaEdit also has the lowest price among the non-free editors on the list.) Coda is possibly the youngest editor on the list, but one which has picked up a lot of steam with its support for IDE-like features like syntax hinting and revision control systems; but the fact that it’s the only editor on the list which can’t smart-indent for me makes it useless. jEdit lets you go absolutely crazy with window splitting, letting you split windows horizontally and vertically in the same window; too bad its non-Mac-native interface looks like butt. BBEdit has been around since at least the early ’90s, and was probably the first real serious industrial-strength editor on the Mac, but it doesn’t seem to have really changed much since then, and again, the lack of splitting is an annoying oversight. MacVim was an interesting inclusion on the list, being a version of the venerable vim command-line text editor with some Mac interfacey spit and polish on it. I can’t find myself calling it a true Mac editor, though.

So I’m sticking with good old Smultron for now. It’s served me well for a couple of years now, and looks like it’s going to continue to serve me well for a little while more, at least until other editors can come out with the features I’m expecting.

I’m working on a rather large web site for a rather large organization. Given the large number of people that will eventually be using the site - easily more than any other site I’ve built - I decided to write a manual of sorts for the site as I build it. That sounds like a job for a word processor!

Now typically, when I write documents which need formatting, I use OS X’s standard TextEdit. It’s small and svelte, and it gets the job done. But I wanted a few more features for this document; specifically, I wanted the ability to create a stylesheet, footnotes, and automatic page numbering and table-of-contents-building. I needed a beefier text editor.

But which one? At work, I have Microsoft Word, but I wanted the ability to work on this from home if need be. At home, I have Pages from Apple’s iWork suite, but I didn’t have that at work. Conundrum. But hey, I’ve heard that the OpenOffice.org open source office suite recently released a new version that works on OS X without having to start up X11. So maybe it’ll have a Mac-like interface. And I’m not quite sure, but maybe it’ll have all the features I need… With this mindset, I decided to give it a try.

So, having used it for about a week now, and with my page count now in the low teens, here’s my thoughts. Though, to be fair, this really is only a review of the word processing part of the app (and the drawing part, to a lesser extent); the other parts of this multi-faceted app will be outside my range of scrutiny.

Okay, first the negative stuff. OO.o really feels like an app ported from something that’s not Mac OS X. Of course, it was, but every time one of these big-name open source tools gets a/another major Mac release, I just can’t help but hope that someone will get it right some day; that it’ll be ported by someone who realizes that Windows 95 was not a high point in graphic user interface design and application integration. OO.o isn’t it. The spell checker does not recognize Mac OS X’s system-wide dictionary; some of the smaller subwindows which don’t use the standard GUI widgets have the close widget on the wrong side of the window; some of the key commands are wrong (Command-Y is redo instead of Command-Shift-Z); the Enter key on the keypad does not “click” the default button in dialogue boxes; and cursor movement is severely wrong for Mac users: Home doesn’t go to the beginning of the document, Page Up/Down move the cursor as they scroll, tricks like click-and-a-halfing inside a word to select the word and then dragging over the next word to select it as well do not work. And the default fonts are Times New Roman and Arial. Barf!

Check out that lovely notification thingie that appeared in the right side of my menu bar. With a yellow ballon, yeah. And when I clicked on the icon, instead of getting a menu, a window appeared - I’m not sure how that’s even possible. And it didn’t go away when I declined to update the Canadian French grammar checker or whatever it was.

Non-Macness aside, the interface just isn’t very friendly. Many operations require going through dialogue boxes with lots of tabs and buttons (sometimes two rows of tabs), and to make matters worse, trying to bring up the in-program help system hard-crashes the app. Then, when you start OO.o up again, it, without your permission, brings up this ridiculously large window to try to “recover” the documents you were working on when it crashed. The problem is that this window seems to get hidden underneath other applications’ windows while the standard OO.o interface elements (dock icon and menu bar) become unresponsive and beachball as if the application has hung. You can fix this if you go to that recover window and either start or cancel the recovery process - but, again, as it gets hidden underneath other app windows and doesn’t appear when you click on the OO.o dock icon, it’s easy to miss if you have other app windows open. Argh!

Then there was the fun when I tried to import a diagram I had drawn in Illustrator. The first thing I did was try to just paste it in; all that did was paste in the text parts of the diagram and none of the art at all. Oops, that’s a result worse than failure. So I switched back to Illustrator and exported the drawing as an EPS. After all, EPS is a fairly universal vector art format, right? Well, OO.o opened it, but then it would only show the low-res bitmap preview version of the drawing, including on export (and presumably on printing). Unacceptable. I found a plug-in which purported to let me open SVG images in OO.o, but that just caused the program to crash when I tried to use it. I wanted this document to eventually be both printed and viewed as a PDF, so doing it as a bitmap was an unattractive option. I briefly considered just redrawing it in OO.o’s drawing tools, but after starting up a drawing document with OO.o and trying to use it for a few moments, I collapsed into something between hysterical laughter and desperate sobbing and gave up on that idea. THERE’S NO KEY COMMAND OR BUTTON TO ZOOM IN EVEN, FER CRISSAKE. (Or if there is, it wasn’t as obvious to find as it should have been.)

After doing some searching around, I found a solution; in Illustrator, I had to export the drawing as a Windows Metafile format, with an extension of WMF. To my surprise, this imported into OO.o perfectly. What the hell?! Who would have even guessed that “Windows Metafile” was even a vector art format?! It certainly doesn’t sound like one.

Okay, now for the good stuff - and, believe it or not, there is some. The styles? They work great. The footnotes? They bring up an unnecessary dialogue box every time you try to insert one, but they work great. Automatic index-building? Kinda tough to figure out at first, but now that I have, it works great (it would be better if it automatically updated itself, though). The PDF export? Works great and produces smaller PDFs than Mac OS X’s standard PDFing trick. So all its bugs and headaches and unfriendliness aside, it delivers on its promises, at least as far as the word processing component is concerned. In fact, it kind of has the same problem as Word, erring on the side of having too many features, too many ways to do things.

Maybe future releases will be more Mac-like, but seeing as how Firefox has been on the Mac since the beginning and it still feels very un-Mac-like in some ways, I’m not holding my breath. So the final conclusion: If you can tolerate running ugly, unfriendly semi-Mac apps on your Mac, and can learn to save your documents early and often in exchange for a free, cross-platform program with an open document format, OO.o - or at least the word processor it contains - is worth it.

My boss had acquired a box full of Apple Newton MessagePad stuff at some point, and, after not being able to sell it at a yard sale over the weekend, asked if anyone at work would take it off his hands. I volunteered.

For a nerd for old tech, it’s quite a haul. There’s a MessagePad 120, the much-desired MessagePad 2100 (the last and mightiest of the MessagePads), a keyboard, an AC/DC fax modem capable of blazing 14.4kpbs speeds, various batteries and chargers, and various documentation - most of it for the 120.

The MessagePad 2100 was released in November 1997, and axed soon after as Steve Jobs came back to the company and pretty much halted all projects not directly related to the Macintosh. I’ve played with it a bit over the last few days. The first thing you notice when you pick it up is that it is almost comically large and heavy. Remember those old cell phones from the ’80s? It’s got the same vibe. In fact, if you compare the 2100 and the 120 which came out almost three years prior, you’ll see the 2100 is actually a bit larger - Apple was going in the wrong direction. No wonder they got railroaded by Palm, whose products truly were pocket-sized.

When I powered up the 2100, I was pleasantly surprised to see that it still worked, though it had forgotten what time it was. The Newton OS is in many ways different than what you expect to find on the desktop, but after finding a PDF of the manual buried on Apple’s site somewhere I was able to pick it up fairly quickly.

Unfortunately, there’s not a whole lot I can do with it that I can’t do with a piece of paper and a wristwatch. I can take notes (even with my chicken scratch, the handwriting recognition isn’t too bad if I write a little bit slower than normal) and make to-do lists and fill up an address book and find out what time it is in Nagoya, but that’s about it. There’s not even solitaire or some other simple game to blow time on.

There are Newton software archives out there with shareware and freeware which can add more functionality to this thing, but I haven’t owned a Mac with an old Apple-style serial port in six years or so, and I don’t have a network card for it either. Nor do I have a dial-up internet connection or even POTS of any form at all, so the modem is uselsess. So right now, it’s just kind of an oddity - an electroluminescent memo pad.

(Please pretend that my digital camera wasn’t borked and I’ve attached lots of cool and interesting photos to this post. Or, failing that, check out the Newton pool on Flickr.)