Out of Hanwell

May 25, 2006

JavaScript Lint

Filed under: Uncategorized — Matthias Miller @ 10:26 pm

I think this is good news:

JavaScript Lint now has its own SourceForge project with discussion forums, bug/feature trackers, and a publicly-available Subversion repository.

Advertisements

May 18, 2006

Programming Is Hard

Filed under: Uncategorized — Matthias Miller @ 9:11 pm

Jakob Nielsen’s recent essay on Variability in User Performance examines various tasks and compares the most productive users with the least productive. Of the tasks he examines, programming has the most variance in performance.

This table shows why the number one guideline for managing software development is to hire the best developers: Good developers are three times faster than slow ones and offer companies tremendous gain — even when they require higher salaries.

He also states:

The difference between the very best and very worst developers is typically about a factor twenty.

That’s a big difference!

Interestingly, the runner-up is using web sites, which means bad news for web developers. Managers can go out and pick more productive developers, but web developers can’t go out and pick more productive users. Their users may be quite skilled or only somewhat skilled, so they need to find a way to cater to both without frustrating either.

May 13, 2006

SUSE 10.1 (with wifi that works)

Filed under: Uncategorized — Matthias Miller @ 8:22 pm

Today I upgraded to SUSE 10.1 on my notebook, mostly for its improved wireless network support. Aside from the hassle of reinstalling my wireless network driver after upgrade, I was not dissapointed. KNetworkManager is everything that KInternet and KWifiManager were not. Before I resorted to committing the network keys to my memory. Now I can now save them in a KDE Wallet. Switching between networks is very easy, and it’s something that I do lot. Wireless networking was the single most bothersome feature in SUSE.

Just for fun, I also downloaded Intel graphics drivers for my notebook so I could get 3D acceleration for Xgl and Compiz. Unfortunately, it’s way too slow to use, but the UI metaphors are very effective.

  • The cube effect is a nice, intuitive way of switching between desktops. It gives you visual feedback on what’s happening.
  • The Apple-like window switching is cool (see exposé), although I think a hover effect would make it more effective.
  • The scrollwheel-controlled transparency on Windows could be a very convenient way to quickly check information in other windows without the total loss of context from alt-tab. This is especially useful on notebooks since they have limited screen space.

I’ve reverted back to the two-dimensional world to write this post because, oddly, I prefer being able to get things done over seeing cool effects. But I can’t wait until I can do both.

SVG Icons

Filed under: Development — Matthias Miller @ 11:47 am

I recently used Inkscape to design an SVG logo for that development tool I’ve been talking about. Perhaps my inexperience explains why I’m so easily impressed by vector graphics, but here’s what I liked:

  • Attribution. I can attribute certain parts of the image that are derived from another source.
  • Accessibility. The image can be rendered at any required size and could (theoretically) degrade nicely for media with low color depth, should the software support it.
  • Consistent file size. The size at which the image is rendered doesn’t matter; it maintains a fixed file size. You might still end up with a huge SVG if you’re doing complex graphics, though.
  • Human-readable format. XML probably isn’t perfectly human readable, but compare it with JPEGs, GIFs, and PNGs and you’ll see what I mean.

As I started creating icons from the logo, however, I found that vector graphics are not integrated into the development process very well at all. Mac was pretty easy–create four PNGs and drop them onto the image tool–but Windows was a pain. Windows icons have five or six standard sizes and five different color depths, which means a lot of image conversion. Worse still, Microsoft Visual C++ does not support 256 color icons, so I had to hunt for an editor that did. Even then, I compromised. Any users with monochrome or 16 color displays will just have to suffer with whatever Windows gives them. (I apologize in advance!)

This made me wish for a one-click web service that creates icon files from vector graphics. It shouldn’t be so hard to do, but it would be very convenient. Eventually, of course, the service could support low color depths by removing gradients and by picking appropriate replacement colors.

May 8, 2006

Universal Binaries with Qt for Max OS 10.3 and 10.4

Filed under: Uncategorized — Matthias Miller @ 9:36 pm

This evening I was experimenting with universal binaries in Qt, as documented in the Qt tutorial. At the risk of duplicating some information, I’ll explain the slightly different route that I took for building the universal binaries.

Before you get started, if you’ve got a PowerPC processor, you’ll need to make sure the 10.4 SDK is installed. It’s available with the Developer installers. You’ll also need to install a version of Qt that supports universal binaries.*

The primary limitation of using qmake to build universal binaries is that it will only run on Mac OS 10.3.9 or later, since GCC 4.0 is required to build. Binaries built with GCC 3.3 will run on previous versions of Mac OS X, but you cannot use GCC 3.3 to build universal binaries.

Rather than release separate bundles for 10.3 and 10.4, you can build a PowerPC binary for 10.3 and an Intel binary for 10.4, then use the lipo tool to stitch them together. The Qt documentation recommends using the gcc_select command to switch compiler versions, but this is very cumbersome for release scripts, since it requires that you enter a root password. Instead, you can force qmake to use a specific version of GCC.

To build a PowerPC binary that’s compatible with Mac OS 10.3, use this configuration, then save a copy of the binary.

QMAKE_CC=/usr/bin/gcc-3.3
QMAKE_CXX=/usr/bin/g++-3.3
QMAKE_LINK=/usr/bin/g++-3.3
CONFIG+=ppc

To build the Intel binary, use this configuration, then and save a copy of the binary.

QMAKE_CC=/usr/bin/gcc-4.0
QMAKE_CXX=/usr/bin/g++-4.0
QMAKE_LINK=/usr/bin/g++-4.0
CONFIG+=x86

From there, creating the universal binary is a simple matter.

lipo path/to/ppc/binary path/to/x86/binary -create -output path/to/universal/binary

If you like, you can use file to verify that the universal binary was created correctly.

Then, drop your universal binary into your bundle, and you’re good to go. Of course, you’ll want to automate this process so that you don’t have to build the universal binary hand every time, but I’ll leave that as an exercise for you, the reader.

Additional Resources:

May 1, 2006

Linking MSVC Libraries with MinGW Projects

Filed under: Development — Matthias Miller @ 11:47 am

Over the past several weeks, I’ve been reading Karl Fogel’s book Producing Open Source Software, having first heard about it from Ben Goodger. It’s full of practical advice for anybody’s who’s involved with open source software. But I’d like to focus on the advice about starting a project:

That sounds obvious, but many projects don’t bother to standardize their installation procedures until very late in the game, telling themselves they can do it any time: “We’ll sort all that stuff out when the code is closer to being ready.” What they don’t realize is that by putting off the boring work of finishing the build and installation procedures, they are actually making the code take longer to get ready—because they discourage developers who might otherwise have contributed to the code. Most insidiously, they don’t know they’re losing all those developers, because the process is an accumulation of non-events: someone visits a web site, downloads the software, tries to build it, fails, gives up and goes away. Who will ever know it happened, except the person themselves? No one working on the project will realize that someone’s interest and good will have been silently squandered.

I’ve been working with another developer on the software development tool that I recently mentioned: Compilation on the Mac was a breeze, and we had little concern about Linux. But things came to a grinding halt when we started on the Windows build.

The software is built with MinGW because it uses the Qt framework, and it also has dependencies on the Apache Portable Runtime. These libraries, like many other precompiled Windows development packages such as the MySQL client library, were compiled with Microsoft Visual C++ (MSVC). MSVC and MinGW, we discovered, use different naming conventions for stdcall functions. MSVC exports them as _name@ordinal, but MinGW exports them as name. As a result, the MinGW build failed with “undefined references” link errors when calling stdcall functions exported from the MSVC library.

The MinGW FAQ discusses this problem and offers a solution:

  1. Create a definition file using reimp (for lib files) or pexports (for dll files).
  2. Remove the underscore prefixes from the stdcall functions.
  3. Use dlltool to convert the MSVC library into a MinGW library with the new definition.

That didn’t work. We finally removed the ordinals from the function names, which caused it to compile. But the program wouldn’t run because it couldn’t find the linked functions in the DLL. Finally, after consulting the MSDN documentation for definition files, we changed the build instructions:

  1. Create a definition file using reimp.
  2. For each stdcall function (formatted as _name@ordinal) add a line name = _name@ordinal, allowing MinGW to map its stdcall naming convention to that of MSVC.
  3. Use dlltool to convert the MSVC library into a MinGW library with the new definition.

It worked! To compile the project you must simply:

  1. Download and install the Qt/Windows package, which includes MinGW.
  2. Download reimp and drop it into the MinGW/bin folder.
  3. Download the development packages for the third-party libraries and point an environment variable to that location.
  4. Build the project with the usual qmake/make commands.

We spent a lot of time on the Windows build system, and we’re much wiser now about libraries, export definition files, and the stdcall calling convention. More importantly, this project’s barrier to entry should be low enough to allow any interested developer to contribute.

Additional Reading:

Edit: Updated some URLs.

Blog at WordPress.com.