High Level Assembly Code?

A while back I needed to reverse the order of the 4 8-bit bytes in a 32-bit word, in some Delphi code. I worked out a way to do it with bit shifting, read the docs for a few minutes, and got something to work with AND, SHL, SHR, and some $FF constants. Later I encountered (on a usenet post which I can’t find at the moment), this implementation, which consists of some Delphi cruft around a single assembly statement:

function Swap32(aLong: Longint): Longint; assembler;
asm
BSWAP eax
end;

This is an unusual occurence: the assembly code is shorter, simpler, and more obviously correct (see this explanation of BSWAP), than the high level language implementation. Hmmm.

Math Drill – for your 1st..4th grader

Here is a simple piece of software I wrote to help my children practice basic arithmetic facts. Of course there are no doubt already a thousand or more similar programs out there; but in a few minutes of searching I didn’t find one that did quite what I wanted. I ended up tinkering with this for several hours, and even wrote documentation and made an installer. Free download and screenshot below.

MathDrillSetup.exe (free)

Math Drill screen shot

I’ve also published the source code over on Github: http://github.com/kylecordes/mathdrill/tree/master

This software is written in Delphi, and though there is some chance that I am the only developer anywhere using both Delphi and git, hopefully this will be wrong, and someone will fork and offer their improvements.

Joel, you have got to be kidding

Joel seems to “play it safe” … then goes off the deep end of irony in his final paragraph:

“FogBugz is written in Wasabi, a very advanced, functional-programming dialect of Basic with closures and lambdas and Rails-like active records that can be compiled down to VBScript, JavaScript, PHP4 or PHP5. Wasabi is a private, in-house language written by one of our best developers that is optimized specifically for developing FogBugz; the Wasabi compiler itself is written in C#.”

Fortunately DHH saved me some minutes of typing about it, with a scathing commentary.

Over at Oasis Digital we use both common tools (.NET, Java, PHP, C, Delphi, etc.) and more unusual ones (Lua, Prolog, Ruby, sorry no Lisp yet), so I believe that puts us in the DHH and Paul Graham camp: If you want to win, you must be willing to do something different from the pack… such as, in an extreme case, creating your own language optimized for the task at hand, whether in the form of Lisp macros or a C# compiler for Wasabi.

How To Do Deployment (Dave Thomas RailsConf Keynote)

I just attended Dave Thomas’s keynote at RailsConf. He had many interesting things to say, most notably that 60%+ of his Java-centric conference-circuit friends, mostly people who have written books on Java, speak regularly on Java, and have lots of experience as Java “architects”, are now making a living with Ruby / Rails.

Dave talked about 3 key areas where Rails should improve. The one I want to focus on is deployment. Rails has Capistrano, a slick tools for deployment automation. Capistrano is great, but it misses the boat in one key way: it is push-based. It assumes a world where the developer sets up, controls, and performs deployment to production servers. That is of course the case at the start of a small operation, but it doesn’t scale; in large organization, or even in small growing ones, sooner or later there is staff dedicated to production deployment and monitoring, separate from development.

One way, to me right way, to handle deployment is push / pull:

For the “push”, a developer uploads a new version to a storage site somewhere. It travels in the form of an archive file (ZIP, tgz, whatever) which contains all of the needed artifacts, as well as metadata about the required libraries, pre- and post-install steps, etc. for the new version. It has a unique name; it lands at a URL. Normal, off the shelf technology (FTP, web servers, etc.) can be used to serve and secure this storage, implement policies about who can upload new versions, etc. This upload happens with some simple one-line command (or as part of an auto-build); it does not actually put a new version in production, but only makes it available for pulling.

Then, on a production machine, someone with software installation rights on that machine (administrated by the normal tools – not by any special feature of the deployment mechanism) runs a command (something like “deploy staging http://ourserver/project1/project1-build-3453.tgz”) which downloads the new build, runs various sanity checks, deploys it to a staging area, and makes it available to try out. Once the staging is verified, a similar command brings it in to live production. These builds refer as needed to configuration data on the deployment machines (such as production DB access credentials); the build archives are generic, not specific to any particular production machine.

The main idea behind this is that each person has the rights they need for the work they need to do, and these rights don’t need any special help or support from the deployment mechanism. Developers don’t need any special rights on deployment machines, nor to deployers need any special rights on development machine

I wrote this in the context of a Rails / Ruby talk, but it’s at least as relevant in Java and Delphi world; in fact at Oasis Digital we need something like this on a Java project and a Delphi project right now.

Take control of Delphi forms in your multimonitor application

The authors of the the VCL helpfully added multi monitor “support” a few versions back. Somewhat less helpfully, this support is very limited – it has no way to say “create form X on monitor 3”, which is a very useful thing to do in some kinds of applications – those intended to run on a multimon system in a specific configuration.

You can readily move forms around (with .Left, .Top, etc.) on to specific monitors after a Form is open, but not while it is opening (in OnShow or OnCreate), because a fine method TCustomForm.SetWindowToMonitor will jump in and undo your work.

Not surprisingly, most of the obvious methods to override to fix this, are not virtual. (An aside – I think the bias toward final methods in Delphi, C#, and some other languages, is a poor idea, and I think the guideline of “design for overriding, or prevent it” is even worse.) With some looking, I found a workaround, shown here somewhat mangled by WordPress:

private

FSetBoundsEnabled: boolean;

public

procedure SetBounds(ALeft, ATop, AWidth, AHeight: Integer); override;

…..

procedure TSomeForm.SetBounds(ALeft, ATop, AWidth, AHeight: Integer);

begin if FSetBoundsEnabled then inherited;

end;

FSetBoundsEnabled will be False by default. Sometime after your form is loaded (use a Timer or a windows message to signal this), set FSetBoundsEnabled := True then set your .Left and .Top to put your form whereever it needs to be.

St. Louis Code Camp – Lua Talk Notes and Source Code

At the St. Louis Code Camp on May 6, I gave a talk that was somewhat poorly titled “Painless Scripting with Lua”.  The topic more mostly about the overall use of scripting as a configuration and extension mechanism, with Lua as an example language.
The talk had no slides, only code and a 1-page handful with some notes. You can download the source code: 2006_code_camp_lua.zip and the notes follow:

Alternate Hard and Soft Layers

This is a Pattern from the C2 Wiki: http://c2.com/cgi/wiki?AlternateHardAndSoftLayers

In a system built with “hard” code (not in the sense of difficulty, rather in the sense of statically typed, statically compiled languages), organize that code in to layers, and between those hard layers, put “soft” layers in the form of scripts written in a dynamic, runtime modifying languages. AHSL is closely related to the idea of scriptable applications, with the additional notion of layering, rather than ad hoc extension.

“hard layer” languages:

  • C
  • C#
  • C++
  • Delphi (*)
  • Java

“soft layer” languages:

  • bash
  • BeanShell
  • Emacs Lisp
  • Groovy
  • JavaScript
  • Lua (*)
  • Python
  • Ruby
  • Tcl

This talks’ examples are in Delphi (hard) and Lua (soft). Delphi is a mostly static language, essentially similar in certain ways to C, C++, and Java, but with a Pascalish syntax.

Key Points about Lua:

  • An easily learned, dynamic programming language
  • Small, highly embeddable (~ 100 KB)
  • Multi-platform (highly portable C code)
  • Well suited to “Alternate Hard and Soft Layers”
  • Free and open source
  • Stable and mature
  • Safe and Sandboxed
  • Actively developed and maintained

Recommendation on Scripting:

  • If you’re building a Java system, the most appealing scripting language is JavaScript, because it will be “in the box” in Java 6.
  • If you’re building a .NET system, use a .NET-centric scripting mechanism
  • If you’re building a Win32 system with a lot of COM in it, use the Windows Scripting Host and expose your system’s feature to the scripts via COM.
  • If you’re building a system with a “hard” (very static) language, and want to keep your options open for cross-platform development / deployment, than Lua is an excellent choice, it is small, fast, proven, COM-free, and cross-platform.