Raving about a moon

Several months ago I tripped over a little language called Lua. It seemed like a novel idea, but its absence of curly braces and lack of ++, += and similar operators felt uncomfortable after years of C, and I didn't look very close. Then I started to notice it hiding in the most unlikely places, culminating in Adobe Photoshop Lightroom where the development team claims that over 40% of LR is implemented in the Lua programming language. It seemed like it was worth a second look (along with SQLite, the database engine behind LR, but that is another subject altogether) so I started to play with it.

In a word, "wow".

Lua is a scripting and extension language designed to be easily embedded in a host application. It has a simple C language API that permits the application to easily call functions and manipulate lua values. It also makes it easy to call C functions from lua code, and to add those functions by dynamic linkage to a running program from shared libraries (DLLs on Windows).

Lua was invented by a resourceful group at a Brazilian college to serve needs they saw for configuring and extending applications. Since it was a successor to an earlier language called Sol (Portuguese for Sun), it got named Lua (Portuguese for Moon).

As I see it, several properties of the language have contributed to its success. First, the Lua team has chosen to use the MIT license which is an open source license that also permits effectively unrestricted use in commercial products. This has made it legally possible for commercial developers to consider using the language in their products; and probably as a result of this leniency a significant number of commercial product teams are regular contributors to the lua programming community.

Second, Lua is implemented in standard C, sticking to the subset of the C language that has identical semantics if compiled as C++. The Lua language itself is compiled for a virtual machine and can be saved as (non-portable) bytecode before execution in the VM. Since it is possible (and encouraged) to write lua programs that don't need to compile new code at runtime, it is easy to separate the compiler from the interpreter and distribute only pre-compiled byte code files. Because of this, it is amazingly portable. It is found inside a shocking number of game consoles, PC games, more general products like LR, and even a wide array of embedded systems. In an embedded system, it is most likely to have the compiler stripped off to reduce the amount of code and data space required in a limited environment.

Third, and certainly not last, lua is a very expressive language. The designers have emphasized mechanisms over policies, and as a result although lua is not an object oriented language, you can use its core metatable features to implement object oriented features such as single and multiple inheritance, private data, and object and class methods. Functions are a first-class value, and hence can be stored in variables, passed as arguments to functions, and even be generated (as closures) as the return values from functions.

The core language provides numeric and string data types, along with nil, tables, functions and threads, and two kinds of data wrappers for opaque data belonging to the C side of the fence. The language provides an incremental garbage collector that can be tuned to avoid long stalls for collection.

The C API makes it easy to provide wrappers for third party libraries and system calls that can be loaded on demand. By putting the most demanding inner loops and algorithms into C libraries and leaving the overall program structure to lua, powerful utilities can be built quickly.

My first project in Lua was a serial protocol debugger for a new feature for one of Cheshire's projects. In about 1500 lines of lua and another 1500 lines of C (and only a couple of days work) I was able to build an interactive serial port debugging tool that could log traffic, load and save the logs, send arbitrary data to the device, send random data to the device, and play saved files at the device at an adjustable rate. Building something like that from scratch with C++ and MFC would have taken a lot longer and may never have been as feature rich.

Since then I have built a protocol analyzer for an unrelated Cheshire project with a much more complex packet based protocol, and even built a live status monitor with meters and displays. I have created my own generalized C language host application so that I can deliver an installable windows application as an executable, a few DLLs, and a nest of lua scripts. When my host engine is ready for public view, I will be releasing a version of it back to the Lua programming community as my thanks.

Learn more about Lua at www.lua.org where you will find links to the language itself, its reference manual, books published by its authors, and of course links to the most prominent bits of the lua community: the lua wiki and luaforge.

The tools I've built for Windows would not have been possible without some of the other work contributed by people associated with Lua's creation: IUP for portable user interface design, CD for 2-D graphics, and IM for image processing.

A Box of (slightly) Puzzling Mystery

So I get home from work the other day, and a small, white, cubical mailing carton is waiting on the doorstep. Since that isn't all that unusual, it got nudged inside without much thought. A little later, Michelle noticed it and wondered what I had ordered since it wasn't hers after all.

Looking at the label didn't answer any questions. It was, indeed, addressed to me. My name was spelled right. The return address was a complete unknown and I am pretty sure I haven't been shopping on eBay (actually I know I haven't since I don't have an account there at all... that's Michelle's bailiwick).

So we open the carton, and this is what we found inside neatly wrapped in plastic, bubble wrap, and air bladders. It is a very nicely made puzzle box, about 11.8 cm by 8.2 cm by 5.3 cm, covered with intricate inlay patterns.

There was no packing slip, so the plot thickens.

I've seen this sort of thing before, so I know that opening it is just a matter of patiently searching out which bits of which panel will slide, and then solving the maze to get the box all the way open. This turns out to be a well made a fourteen step box, counting the final removal of the cover. Aha! There's a rolled up sheet of note paper inside. Perhaps that will answer the obvious question... but alas, it only answers questions for those who can read Japanese, and I cannot.

The one remaining clue is the return address: someone at U of Waterloo, in Canada. Perhaps Google will shed some light. Expecting to find someone known to the puzzle community, perhaps an importer of well crafted puzzle boxes, I give that a try. My unknown benefactor is clearly the first search result... but he has no obvious connection to puzzles, woodwork, Japan, or me.

 Except for one minor thing. He's one of a very small community of people who deeply understand quantum computers, another of whom almost certainly knows both of us, lives in Japan, and furthermore knows I collect things like this box and would be amused by a good puzzle.

Thanks, Rod, for the mysterious box...

Saving What?

<rant>

I keep meaning to research and write a meaningful and coherent piece about the madness that is called Daylight Saving Time in the US, and Summer Time in other places, but I keep finding clocks I've forgotten about.

My wristwatch that keeps accurate time by listening to radio broadcasts on WWVB (tune the right kind of receiver to 60000 Hz out of Boulder, CO for a bit stream pulse width modulated on the carrier carrying "official" accurate time data provided by NIST from their atomic clocks) and disciplining its local oscillator naturally failed to have a signal and didn't actually reset itself. Anecdotal reports have it that I am not alone in that experience. Beating it firmly with its user manual got it to go reacquire the time signal and reset.

And don't even get me started on the consequences of the law passed in 2005 that changed the DST start and end date rules on the theory that this will save energy. I don't happen to know what our 20+ year old PDP-11 (still happily running RT-11 and TSX+ and patched to correctly handle Y2K) chose to do. Since the PC on my desk is the only one at the office running a "supported" version of Windows, it was the only one that got an "official" patch applied.

The only change that should be made to the DST rule is to eliminate it entirely. Sure, there would be some amount of confusion as devices nationally are patched to forget about DST, but that is a small price to pay for never having to worry about it again.

I have a real problem understanding how giving the entire country Jet Lag twice a year saves anything worthwhile. If some activities are better performed in daylight, then just don't do them in the dark.

</rant>

And I though LA Traffic was bad...

I was following up on a recent article on an open source project that builds Windows Installer packages (.msi and .msn files) called WiX and wandered off to its lead developer Rob Mensching's blog where he had this post about driving in India: Its like Frogger!

That post links to this video at YouTube.  All I can say is that I'm surprised the 2 minute clip doesn't include at least one fatal injury ;-)

Aside from that digression, WiX looks like an interesting way to build reliable installation kits for both large and small tools without being obligated to buy yet another developer tool or distort the build process. Being command line based, it should integrate nicely with traditional Makefile builds, and comes with task definitions to fit with the new class of build tools (in particular Ant and MSBuild) that describe projects in XML.

I am currently using Inno Setup as my installation creation tool of choice, but it doesn't always play well with others since it creates executable installers rather than MSI packages. It too is open source, free, and it does integrate with Makefiles, so I don't have that much incentive to change tools.

More ad hominem attacks on skeptics

Today, the Boston Globe published an article by Ellen Goodman: No change in political climate. In it, she repeats an ad hominem attack that I am seeing used increasingly. She writes:

I would like to say we're at a point where global warming is impossible to deny. Let's just say that global warming deniers are now on a par with Holocaust deniers, though one denies the past and the other denies the present and future.

My problem is with the phrase "global warming deniers" which has been gaining currency lately and was clearly coined to evoke images of Holocaust deniers such as the deranged person who attacked Elie Weisel today. Worse, she makes the comparison explicit and even states that they "are now on a par with Holocaust deniers".

That is the worst kind of ad hominem statement. Hurling personal insults at those who disagree with your position does not make your argument correct. In the eyes of some people, it actually weakens your argument by damaging your credibility.

In addition, it is hugely offensive to many people to misuse the memory of the Holocaust in this way.

Science is properly about debate, skepticism, questioning, and explanation. Science is not about consensus. Labeling those who are skeptical about the extraordinary claims about anthropogenic climate change as "deniers" serves only to silence debate through intimidation, not to advance the cause of science.