Machina ex Deus

Behold!

"Do not be too proud of this technological terror you've constructed."

- Lord Vader

Cixar Tale Mailing List

If you're interested in Tale development, please join the email discussion in our new Google group.

Tale Music

It's also worth noting that I've commissioned Chris Pasillas, a friend from Cal Poly who studied Computer Engineering before getting his degree in Music with piano performance and composition. Chris drafted at least one sketch for each of the faces of the Tale World this week. The sketches are in the Tale Subversion repository. Each sketch is denoted by a number and a name for each face and tension level. Tension levels include "town", "adventure", and "battle". He's also working on a motif for each face. Please send us your comments and suggestions.

Chiron Automated Tests

It's worth nothing that I've posted the current results for automated unit testing for Javascript library.

The automated test system uses a web browser, an HTTP daemon, a client web page, and a batch of javascript unit test files. A script launches the daemon with an argument list containing a manifest of all of the javascript unit test files. The daemon serves all of the Chiron files, a logger, a reporter, and a test file-name iterator. The script then opens a web browser and navigates to the client page. The client page supplants the usual test.js module with its own autoTest.js module (in an aspect oriented fashion) so that the unit test assertions and timers get logged to the server via an HTTP request. Then, the client page iteratively requests a test URL from the server and opens the test in a new window. After all of the unit tests have run, the client opens the test results page.

In the future, I would like to use up a database and leave the test daemon running before and after each Subversion commission so that test results can be gathered from a suite of platforms. Then, there would be a catalog of performance and coverage trends.

Cixar Javascript Library and Names

The name "Cixar Javascript Library", or CJL, has numerous virtues. It has a three letter acronym, a full name long enough to asphyxiate a cheetah, conjures absolutely no mental image, nor alludes to any works of art or literature.

I'd like to announce that, having rigorously contemplated the issue from a vantage about two feet above my naval (that is, half of a meter for our dear friends huddled safely distant from the sanity interference field), I've decided to name the Cixar Javascript Library. My requirements are succinct:

• one word,
• allegorical, preferably ambiguous,
• eminently brandable,
• subtly humorous,
• an alternate spelling in Unicode,
• If possible, the name must enamour an attractive girl no more than five years older or younger than me before Monday.

I browsed Wikipedia and discovered Ajax's centaur tutor, Chiron. So, there you have it, the library's name is Chiron. I leave it as an exercise for the reader and my fate/doom to discover whether it will suffice. However, I will explicitly state that brandability is fulfilled. Chiron, it turns out (back me up on this, Wikipedia), was really half-cow, the only Centauren to grace the Hellenic Pantheon.

---

For prospective users of Chiron, I have a question of nomenclature preference. Use of the Chiron library requires the HTML author to include exactly one script tag in their header, modules.js (13KB shrunk but not compressed). From there the author can opt to use whatever modules they will.

Central to the Chiron library is a module currently called javascript.js that contains exceptions (KeyError), the type system (type), common types (Dict, List, Iter), and a wealth of common functions (forEach, stripEnd) (currently 36KB shrunk but not compressed). Since I would like to give the user the option of not loading this module, most modules explicitly include it, even though in a language like Python, these primitives would be implicitly available.

I called the module javascript.js since it would include primitives that in Python would be part of the language. In Python, this module would probably be called __builtins__.py. In any other Javascript library, precedent suggests that that module would be called base.js.

Which of the following should I call this module of language primitives?

• javascript.js,
• builtins.js,
• base.js,
• your idea here.

Please send me an email and weigh in.

Javascript and Load Time

I conducted a quick experiment to assess whether it is worth worrying about the size and distribution of Javascript modules. I gathered the following numbers on my Linux box at home (fast) connected to Cixar (fast) over my home Internet connection (average today).

ping cixar.com	30ms
ping google.com	80ms
HTTP overhead	30ms
bandwidth	0.1KB/ms
patience	1500ms
maximum size	150KB
Chiron core	100KB
Chiron core shrunk	50KB
Chiron core shrunk compressed	13KB

I've decided not to worry about the size or distribution of Chiron until its core is five times bigger.

Higher Order Functions in Javascript

Recently I discovered that a friend of mine isn't using "Higher Order Functions" in their Javascript. I cried. However, I fear, this is common-place, perhaps some artifact of a latent and ubiquitous fear of closures instilled by Internet Explorer and the folklore that arises in the absence of reliable, or believable, information. In any case, I'm resolved to expound the virtues of this lesser known programming paradigm among object oriented language aficionados.

Higher Order Functions are functions that accept or return functions. This variety of insanity is possible in functional languages, or languages that provide closures. It is of course possible to accept and return function pointers in C or its ilk, but these are not sufficient for Higher Order Functions because you cannot create functions that can refer to the local variables of the function that instantiated them. This is the crux.

It is helpful to think of a name space as an Object. Calling a function creates a local name space, rooted in the name space in which the function is declared. Unlike in assembly languages, these name spaces can persist, as Objects do, long past the lifetime of the function call that created them. Like Objects, a name space exists as long as a reference exists referring to it. However, among name spaces, the only way to refer to a name space is to create a name space rooted therein. This means that the local variables of a function call exist as long as another function's name space refers to it.

Permit me to offer a practical example, one that any one can use every day of the week. Sort functions in most languages accept an optional comparator function as an argument. C++'s Boost library for example accepts predicates. This is, of course, an insane hack since C++ isn't designed for functional fu. Python provides sorted and accepts a comparator. You don't have to believe me; the important point is that Javascript follows suit.

This is the default sort behavior.

var items = [3, 1, 2];
items.sort();
assert(items == [1, 2, 3]);

A comparator is a function that accepts two arguments and returns an integer indicating whether the arguments are equivalent, sorted in ascending order or in descending order. The result of a comparison call can be compared to 0 (on the right hand side of an expression) with ==, > and < and the result will be exactly the same as if the operands were replaced with the comparison arguments respectively. So, if compare(a, b) == 0, then a == b, if compare(a, b) < 0 then a < b. The simplest compare function provides these results for numbers.

var compare = function (a, b) {
	return b - a;
}

This example, provides a reverse comparator; a comparator that will sort numbers in descending order.

var compare = function (a, b) {
	return -(b - a);
};
var items = [3, 1, 2];
items.sort(compare);
assert(items == [3, 2, 1]);

Of course, there are all manner of objects that you might want to sort, and not all of them are strings and numbers. Supposing you had an array of people, you might want to sort them by their last name. You can do this with a comparator.

var compare = function (a, b) {
	if (a.lastName b.lastName) {
		return -1;
	} else if (a.lastName == b.lastName) {
		return 0;
	} else {
		return 1;
	}
};
people.sort(compare);

Of course, it would be cumbersome to give highly descriptive names to every block of code you wrote and used once, so it's no more reasonable to have to name all of your comparators. You can just use an anonymous function.

people.sort(function (a, b) {
	if (a.lastName b.lastName) {
		return -1;
	} else if (a.lastName == b.lastName) {
		return 0;
	} else {
		return 1;
	}
});

However, you will find that all of your comparators will have the same shape. They will probably all test equality and lessity. It would be beneficial if you had a function that would create comparators for you just based on the attribute of the object you want to compare. Enter higher order functions. Let's construct one such function.

We want to create a function that accepts two elements and returns a number reflecting their transitive relationship, a comparator, based on some attribute. So, its clear that our function will accept an attribute name, and return a function.

/* the higher order function: */
var by = function (attribute) {
	/* the comparator: */
	return function (a, b) {
	};
};

Lets see the function in full.

/* the higher order function: */
var by = function (attribute) {
	/* the comparator: */
	return function (a, b) {
		if (a[attribute] b[attribute]) {
			return -1;
		} else if (a[attribute] == b[attribute]) {
			return 0;
		} else {
			return 1;
		}
	};
};

The important leap here is that the comparator can refer to the attribute from its enclosing name space, even though that function will have completed and been popped off the "stack" long before we ever call our comparator.

We can use our mighty by function to sort people by last name much more readably and succinctly.

people.sort(by('lastName'));

For good or ill, this will work for rigid arrays of arrays (tables) as well, if you provide an integer instead of an attribute name. I say this with half of a heart because it's a Pyrrhic victory. The price of being able to perform member selection and array indexing with the same, generic syntax is the inability to distinguish member selection for associative array (or hash) indexing, but that is a tale of woe for another day.

var table = [
	['Kris', 'Kowal', 3],
	['Ryan', 'Paul', 2],
	['Ryan', 'Witt', 1]
];
table.sort(by(1));

In any case, this demonstrates the power of higher order functions in your every day life. If you don't like the for (var i = 0; i length; i++) pattern (as you ought be weary of by now), modern Javascript implementations provide a higher order function, Array.forEach. From the pantheon of functions you will also find map, fold or reduce, filter, compose, partial, and others. Happy coding.

Javascript Events

This evening, I finally got around to implementing event base classes for the Cixar Javascript Library for Tale. These events resemble W3C DOM events but add some much needed complexity under the hood.

I've implemented Event, Dispatch, and Observable. Event is a base-class for events that implements the usual stopPropagation and cancelDefault. Dispatch creates a function object for dispatching an Event with optionally overridden event type or event factory and default function. Observable can be mixed into any type to permit users to listen to method invocations. This is the beginning of the fun. Dispatch implements call and listen as expected. Additionally, Dispatch implements listenBefore and listenAfter so you can attach event listeners that will fire before any other listener as yet attached, or after the default function and any other listeners have dispatched. Additionally, all of these listener functions return a new Dispatch object so you can assure that your listeners will fire in order relative to each other. This behavior is recursive, so you can attach a listener before or after any other listener.

Here's the unit test.

Don't Repeat Yourself: or Javascript DOM Initializers

I think I did something clever. Once again, it's time to fight the losing battle of explanation. I find that I've been repeating myself a lot in Javascript. Worse, I've had to compromise my ideals pretty frequently. Consider the following Javascript.

<html>
	<head>
		<script src="http://cixar.com/javascript/modules.js">
	</head>
	<body>
		<div id="clock_0"></div>
		<script>
			require('clock.js', function (clock) {
				clock.Clock(
					document.getElementById('clock.js')
				);
			});
		</script>
	</body>
</html>

In this example, I've installed the Cixar Javascript module loader. This gives me a global function called require that fetches javascripts and loads them as singleton modules and returns the module object or calls a given function closure with the module object. I then populate my document with HTML and bless the HTML with Javascripts. In this case, I set up a clock. The details of how this clock works are hidden in a Clock type that is in turn hidden within a clock module. This particular setup requires that any blessed DOM element have an identifier so that it can be in turn fetched by name in the Javascript.

It turns out that this pattern of laying out out a DOM element like a div followed by a script to imbue it with DHTML powers is pretty common in my Ish project. This makes for a lot of script blocks but also makes the server side code rather orthogonal and elegant. It's not that bad, and I am proud it's this clean so far.

However, it could be much cleaner. Consider this example that I implemented today.

<html>
	<head>
		<script src="http://cixar.com/javascript/modules.js"></script>
		<script>require('init.js')</script>
	</head>
	<body>
		<div require="clock.js#Clock"></div>
	</body>
</html>

Observe that with this approach, the div element does not have an identifier nor a corresponding script block. Instead, I've loaded an init.js module (the name will change when you email me a better one). The init.js module sets up a page load listener. When the page loads, the initializer scans the entire DOM for elements with require or requireRelative attributes. It then loads the given module, extracts the given function from the module, and blesses the corresponding element with that function.

I suspect this has a hidden advantage in addition to elegance. With the previous strategy, every DOM element had a corresponding getElementById call. I suspect that getElementById traverses the DOM until it finds an element with the given ID (plausibly, the browser tracks an (id, element) mapping dynamically, but this would be tricky to implement correctly). The old approach requires one of these traversals for every blessed DOM element. This new approach only requires one traversal of the document per page load.

So, two questions for the audience. What should this module be called instead of init.js? Alternately, should this behavior be automatically installed by modules.js?

Winged Monkeys

Just kidding. There aren't really any winged monkeys. However, there are going to be some other flying animalic contraptions in Tale: Gyro-pig and Lamb-chopper.

Also, I've posted some graphics for the faces of the Tale world.

Programming in Javascript

I'm going to attempt to explain computer programming. This will be interesting for my sister since she's nominally curious about the topic, and as I stumble through increasingly absurd (but commonly accepted) metaphors, I'll accidentally illustrate how odd the mind of a programmer must really be.

Programming is like writing a recipe book.

/* this is a recipe */
var ingredients;
mix(ingredients);
cook();

Running a program is like having a toddler make a gourmet meal by following the instructions in your recipe book (or toddlers in any number of kitchens capable of communicating with each other over the phone in ostensibly incomprehensible sequences of "gah" and "goo-goo" that mysteriously can also convey food). The recipe book is also a "make your own ending" novel. As the toddler reads instructions it will find "branches" like, "Making bread, step 567: to apologize to the butler, go to chapter 10. To bludgeon the butler with a monkey-wrench, go to chapter 829." However, "branches" or "gotos" are fairly uncommon.

/* this is not Javascript, but it looks a bit like it */
if (choice == 'apologies') {
	goto apologies;
} else {
	goto bludgeon;
}

Recipe writers use "functions" instead. A function is a chapter in the recipe book, a mini-recipe, wherein the author provides detailed instructions for doing things like "beat an egg". You can tell an infant to go to any of these chapters to do some particular task and then go back to the part of the recipe where they started, like "Making bread, step 568: knead dough. Go to chapter 12 with this dough and bring it back to step 569 when you're done."

var bread = function () {
	var eggs;
	var flour;
	var dough;
	dough = mix(eggs, flour);
	knead(dough);
	bake(dough);
	return dough;
}

To keep track of where they are in the recipe, the toddler keeps a stack of dishes, upon which, the toddler arranges peas and carrots with chapter, page, and step numbers from the recipe book.

I'm making bread
	I'm mixing eggs with flour
		I'm breaking an egg
			I'm picking bits of shell out of the yolk

This stack of dishes is often very tall.

With Javascript, this stack is usually about 10 plates. Apple's web browser, Safari, lets you stack 100 plates. Firefox's implementation of Javascript lets you juggle a stack of 1000 plates. Microsoft's Internet Explorer 6 handles 1125 plates. Opera gives you room for a whopping 3345 plates.

You might wonder why the toddler (in this case Hansel and Gretel) can't arrange the peas and carrots on the recipe book itself whenever it gets to a new chapter, letting it know where it needs to go back. There are some tricky chapters that actually, and often by way of long paths, refer back to themselves. These are called "recursive" functions and they have the special attribute that they must be "re-entrant", meaning that any number of toddlers can have any number of plates referring back to it without getting lost in their recipes or mixing up each other's ingredients. Recursion is handy because you can write chapters like "Find the spoons" that go like this: "If there's more than one place to look, divide those places in half. Find the spoons in north half. If you don't find them there, find the spoons in the south half. If you don't find them there, cry." Seriously, it's handy, and if you write the chapter well enough, it'll go a lot faster than, "Look in a new place. If you don't find the spoons, try again."

var find = function (places, spoons) {
	if (count(places) > 1) {
		try {
			find(beginHalf(places), spoons);
		} catch (tantrum) {
			find(endHalf(places), spoons);
		}
	} else if (has(places[0], spoons)) {
		return places[0];
	} else {
		throw new Tantrum("Wah!");
	}
};

The next nice thing about functions is that the recipes don't have to be particularly specific. This means you could write a chapter in your recipe book entitled, "Find Something". That way, the recipe writer can call for the toddler to "Find Spoons", "Find Monkey-wrench", or "Bludgeon Butler with Monkey-wrench". Writing recipes is about being vague. You never know when you're going to need to do something again and you don't want to write out every detail.

var bludgeon = function (something) {
};

So, you're keeping track of a lot of ingredients, so knowing what to call them can be a bit of a bear. You want to be sure that when you call for "the apple", you don't just get any apple; it has to be the relevant apple that the toddler just skinned. Most of the time, you keep track of names with the outline of your recipe. If you refer to an "apple", you read backwards first in the chapter, then the book the chapter is in, then the volume. You don't look in other chapters, books, or volumes because they might have their own apples.

var volume = function () {
	var apple = new Apple();
	var chapter = function () {
		var orange = new Orange();
		var step = function () {
			compare(apple, orange);
		};
	};
};

Many languages leave it at that. However some languages have "closures". It's a weird word for a simple idea. A closure is where you keep track of the plate you were on when you read the function. Sometimes reading a function is part of the recipe. When you do that, you're making it so that when you call that function, you can use any of the ingredients on your plate.

var makeACounterFunction = function () {
	var whereImAt = 0;
	return function () {
		var whereIWas = whereImAt;
		whereImAt = whereImAt + 1;
		return whereIWas;
	};
};
var counterFunction = makeACounterFunction();
assert(counterFunction() == 0);
assert(counterFunction() == 1);
assert(counterFunction() == 2);

Some languages are object oriented. There are a lot of interesting things about object oriented programming, but the short of it is that your ingredients can each have their own recipes and sub ingredients. You don't have to tell the function which ingredient to work on. You can just talk about it as "this".

var Egg = function () {
	this.break = function () {
		break(this);
	};
};
var egg = new Egg();
egg.break();

So, I'm going to gloss over a few details and descend into madness now.

Javascript Module Loader

I had an epiphany when writing a module loader. The trouble is that I didn't want modules to have access or ability to mess with the module loader's local variables. Since I was just calling eval with the text of the module, it had all of this access for reading and writing. Since I don't trust even myself, this was not acceptable. The problem was finding a way to sweep all the names under the carpet.

Here's the trivial solution:

(function () {
	/* module loader */
	this.require = function (url) {
		var require = function (url) {
			/* this require is for the module */
		};
		var text = http.requestText(url);
		eval(text);
	}
})();

Here's a less naive solution:

var evalModule = function (text, require) {
	eval(text);
};
(function () {
	this.require = function (url) {
		var text = http.requestText(url);
		var require = function (url) {};
		evalModule(text, require);
	};
})()

That solution still leaves evalModule as a variable that the module could potentially supplant. I needed to isolate evalModule. My solution uses a member variable of a jail object which eventually gets populated with the evalModule function without giving the closure access to either jail or itself..

(function () {
	var jail = {};
	this.require = function (url) {
		var text = http.requestText(url);
		var require = function (url) {};
		evalModule(text, require);
	};
	return jail;
})().evalModule = function (text, require) {
	eval(text);
}

Of course, it's not enough to isolate the module in a closure. I also give it a Module object as its context object.

(function () {
	var jail = {};
	this.require = function (url) {
		var text = http.requestText(url);
		var require = function (url) {};
		var module = new Module(url);
		evalModule.call(module, text, require);
	};
	return jail;
})().evalModule = function (text, require) {
	eval(text);
}

So, modules look like this:

var module = this;
assert(this != window);
with (require('module.js')) {
	/* go do stuff without fear of name collisions */
}

Javascript Functions, Accelerated Introduction

In Javascript, functions don't really have intrinsic names. The name is just a variable you've assigned an anonymous function object to.

function a () {}
/* is the same as */
var a = function () {};

You can tell a function that it should use some other object as "this".

var egg = new Egg();
var weasel = new Sweater();
egg.break.call(weasel);

You can also send any number of arguments to the function, even if it doesn't ask for them. Then, inside the function, you can get at all the extra arguments with the arguments variable.

(function (a, b) {
	assert(a == 10);
	assert(b == 20);
	assert(arguments[1] == 20);
	assert(arguments[2] == 30);
}).call(this, 10, 20, 30);

You can send arguments to a function from an Array.

(function (a, b, c) {
	assert(a == 1);
	assert(b == 2);
	assert(c == 3);
}).apply(this, [1, 2, 3]);

You can even make up an array of arguments with a program.

var array = [1];
array.push(2);
assert(array == [1, 2]);
var sum = function (a, b) {
	return a + b;
}
assert(sum.apply(this, array) == 3);

You don't have to give a function all of the arguments it asks for.

(function (a, b, c) {
	assert(a == 10);
	assert(b == 20);
	assert(c == undefined);
})(10, 20);

You can run programs/recipes that you get as quoted data.

eval("var a = 10; a = a + 1");

When you eval, you can see all the data in the caller's closure.

var a = 10;
eval('a = 20');
assert(a == 20);

An interesting thing about putting Javascript in HTML is that all of the scripts have the same closure.

<script>
	var global = true;
<script>
<script>
	assert(global);
<script>

You can wrap a bit of code in a closure so that its names are all its own, can't conflict with other scripts.

var global = true;
(function () {
	var local = true;
})();
/* local is not visible here */

In a web browser, the context object for the entire program is the Window object containing the script.

assert(this == window);
(function () {
	assert(this != window);
	assert(this == 10);
}).call(10);

The window is also the base closure for your program, so you can access everything in it as if it were a local variable.

window.document == document

You can play this trick with any object's member data or functions using the with block.

with ({'a': 10}) {
	assert(a == 10);
}

Photo Rally 3 - Continued

The photos for Photo Rally 3, from all teams, are now available online.

Javascript Modules Revisited

For those of us who retch at the mention of both "Java" and "Javascript", today's post brings us deeper into my realm of insanity, "deep in the shit", to quote Colbert. Yes, it's no picnic, but the development world has its human moments. Moments where hubris, playful cynicism, and violent indignation must give way to humility. People, harken to my words, hidden among the copious piles of refuse, there's some good code in Dojo.

Don't run off and commit resources to it; I'm just saying it's a good read for someone looking for snippets to steal. If you need something that works today, it might be a good option, but hold your horses; I haven't finished reading the alternatives.

I've mentioned that Dojo has a module system. It plainly doesn't meet our needs. Let's be explicit about our requirements

Module system must:

• be the first and only Javascript file explicitly loaded with a script tag in the header of a document
• have a light footprint on the global context object (window in browsers), ideally one function
• isolate each module in its own closure
• isolate each module with its own context object, preferably the module object
• leave no conditional module management code to users
• provide singleton module objects that are loaded once per page
• provide modules as shallow objects, encouraging the library user to obey the "Law of Demeter"
• handle synchronous and asynchronous pattern interface
• permit the library user to require a module under any pseudonym it desires, or vaguely, provide the flexibility of Python's import syntax, with suitable analogs for import module, import module as m, from module import *, from module import part as p.
• permit the library user to move an entire directory of scripts without breaking any of its references to other modules within the same directory tree nor break references to global modules

Dojo does not appear to follow all of these edicts. For example, all modules use the global object, window, as their context object. Every top level module, dojo for example, leaves a footprint on the global object. Dojo encourages Demeter violations like, dojo.component.subcomponent.WhatYouReallyWant. The list of annoyances goes on.

However, Dojo does load modules synchronously, ironically with the so called "Asynchronous XML HTTP Request". My solution in Cixar Javascript, modules load asynchronously using DOM or write tricks. Modules register themselves when they're text loads. Register isolates the context object and closure.

Neither my solution nor Dojo's solution address the problem of mobile libraries. This is a critical feature for a real module system, since it would permit authors across the web to isolate a tool in a directory and permit users to place and name that directory anywhere and any way they want without having to modify the contained code.

The problem with my system was that it requires modules have to register their location:

this.register('module.js', function (module) {

This was necessary because of the non-blocking, asynchronous module loader. There was no way for a Javascript to recognize what module it was supposed to be since the module scripts would load in an indeterminate order.

Enter Dojo's module loader code. This bit of AJAX is pretty good, with lots and lots of embedded knowledge of multiple Javascript environments and their eccentricities. Using it as a reference, I wrote a new module loader system that provides both synchronous and asynchronous forms for require, and obviates the need for register calls completely.

A module:

/* import module */
var module = require('module.js');

/* import module, asynchronously */
require('module.js', function (module) {
});

/* import module as m */
var m = require('module.js');

/* from module import * */
with (require('module.js')) {
}

/* from module import component */
var component = require('module.js').component;

/* from module import component as c */
var c = require("module.js').component;

Most of all, the register function no longer exists. Modules have their own closure and singleton context object. Modules have their own require function so (eventually) they will be able to load modules relative to their own URL rather than the URL of the containing page. Here's what it looks like:

(function (url) {
var require = function (subUrl) {...};
eval(http.requestText(url));
}).call(modules[url], url);

Meanwhile, I also re-imagined Dojo's HTTP request mechanism, the heart of AJAX. Since the module system requires HTTP requests, it creates a pseudo-module that users can later require as http.js. The HTTP module supports the same abbreviated syntax for both synchronous and asynchronous requests as require, and provides forms for retrieving the HTTP response, text, XML, and the XML document element object. The module includes most of Dojo's code paths for multiple browsers, environments, and platforms and provides a wrapper for the HTTP response object that cleaves more strictly to an observable style and handles some odd cross browser cases.

var text = http.requestText('text.txt');

http.requestXML('xml.xml', function (xml) {
});

var response = http.request('location.html');
if (response.isOk()) {
var text = response.getText();
}

Photo Rally 3

Ministers of Mayhem Patrick Thomas and Zach Unlastnamed held the third quarterly Photo Rally this weekend and it was my pleasure to attend for the first time. I captained "Team Moof" with our totem/mascot/team-mojo, Sam, with friends Tom Tarn, Jim Strange, and Kyle and Jen Wiens. We garnered second place and had a positive blast.

So, a photo rally turns out to be a scavenger hunt for photographs of vaguely described objectives for eight hours. Here are some some of my favorites from our collection.

From the first category of objectives "Adjectives A to Z"

Brutal

Divine

Guilty

Kosher

Questionable

Victory

Wicked

53. Chicken

"Show everyone, once and for all, why the chicken crossed the road. (5/3/2 points)"

36. Drive Thru

"Order something from a drivethrough while riding in a contraption that makes the window lady call for backup. Document your escapade. (8/5/3 points, have it your way)"

55. Flying

"I feel like I'm flying! (5/3/2 points)"

30. Uniform

"The Photo Rally Committee would like to take this time to remind you that you are not a unique and beautiful snowflake. Show your solidarity with matching team uniforms and crushed souls. (7 points)"

51. Mother's Birthday

"Today is my mother's birthday - true story! She couldn't make it , so you should do something nice for a different United employee instead. Also, please don't get arrested by the TSA. (6/4/2 carry-on points)"

52. Urban Kayacking

"Urban kayacking. Best sport since spooling. (7/4/3 points)"

43. Claim a Table

"Have your team claim a table at a restaurant. This should be performed with the same level of enthusiasm as claiming Iwo Jima. (8/5/2 points)"

49. Ghost Ridin' the Whip

"Ghost ride the whip in something that is most definitely not a car. (6/4/2 points)"

Squirrel

Today brings us Squirrel and Sand Witch, President of Dys

Squirrel

Today brings us Squirrel and Sand Witch, President of Dys

Parametric Art

I've been meaning to make some "parametric art" for some time now, and having worked on Tale graphics automation, I now have the tools I need. Parametric art is the name I'm using for creation of artistic compositions where the position, orientation, and shading are programmed using what we learned in High School trigonometry by the pseudonym "parametric equations". Last night I decided to attack the problem by making another set of backdrop images for Jason Reinsvold's Bowmaster. I popped open Inkscape, created some layers for sky, sun, moon, and terrain. Instead of hand positioning the Sun and Moon, I just put them on the origin. Then I pulled up my Python SVG tools that I made for generating maps. Using some trig, I programmed the positions and rotations of the sun and moon. Here are some samples:

more

Tomorrow's project is adjusting the linear gradients that overlay the cells in the foreground terrain to catch the light of the sun, moon, sky, or form shadows and silhouettes.

New Character Sprites

I completely recreated the rider (or stand-alone character) for the Tale sprite graphic. The major goal was to represent both genders equally in the game. On the way, I created several hair styles and facial expressions, articulated the arms into three positions for each gender, and created a lot of layers. Here's the breakdown:

• male or female
• round, oval, or angular head
• arms out stretched, bent for holding shields and such, or hanging at your sides
• shirt with detachable sleeves
• pants or shorts
• shoes, boots, or sandals
• buckler, roman shield, hero shield
• long or short, lobed or round ears
• 11 hair styles
• 14 facial expressions

Here are a couple samples of riders:

Portraits

Hey folks. I've been down with the Flu, but I'm getting back in the saddle.

Saturday, a week ago, I stayed up late agonizing about a color module for Cixar Javascript. The new color module builds on the refinement of the Mootools color module and the Cixar Javascript type system. The new Color type provides accessors and mutators for HSL and RGB components and can parse hex strings in both modes. The color also tracks opacity. Under the hood, the Color instance is modal, converting its internal components array to arbitrary modes, radices, and cardinalities. For example, when you parse a six character RGB string, the color implicitly switches to base 256 with values in [0, 256) in RGB mode. When you set its lightness to .5, the color implicitly normalizes its components to HSL mode with values in [0, 1]. When you get the RGB string out, it actually doesn't do a conversion, but makes a copy of the color and converts that to RGB 256 mode so that you don't get floating point propagation error. The color modules is here. I still should port the "invert" function and find a way of consistently calculating "strobes" and "complements", but first I need to beat the definitions out of an art major (easy), but first I need to find a math major who knows some math (hard). All in all, this was a nice diversion, but I don't know whether I'll ever use it and I certainly stayed up too late working on it and fell ill.

I've continued my perusal of Javascript libraries. I started looking into uses for the new canvas tag that debuted in Safari and made its way into Opera and Firefox. Internet Explorer doesn't support the standard, but I found an open source library that Google has contributed to the community called excanvas that transparently causes canvas tags to mostly work in IE. The library performs some VML voodoo and provides an interface consistent with the canvas standard. The interface supports rotation, translation, and turtle drawing, but does not support gradients. I starting paring out pieces of the implementation into a matrix module for Cixar Javascript that provides a Matrix type with Google's matrix multiplication written elegantly and, alas, sub-optimally. Before I pare it out in favor of fast native loops, here's the pretty version:

return matrix.Matrix(
 each(range(value.getWidth()), function (x) {
  return each(range(other.getHeight()), function (y) {
   return sum(each(range(value.getWidth()), function (a) {
    return value[x][a] * otherValue[a][y];
   }));
  });
 })
);

Tale News

I'm redrawing the rider graphic for the sprite. This is the character sprite that will appear on maps, in battle mode, and close up in your inventory or equipment viewer. Additionally, the sprite will provide a small portrait for chats and status messages about your character. The portrait will have interchangeable faces to reflect your mood and also serves as an emoticon. Also, the primary goal in the redraw was to provide male and female variations of the character. So far, I've made the two figures, three arm positions each (outward, bent, and down for holding various armaments), three head shapes, several faces, many hair styles including "lemming", "block", and "dreads", and four kinds of ears. I've also outlined some clothes. Until the whole ensemble is ready, here are some samples for each of the facial expressions:

Javascript Libraries

I've been poring over Javascript libraries lately, trying to ascertain the extent of their features, how much implementation overlap there is among them, and which ones implement certain features best. The idea is that I'm going to integrate the best tidbits into Cixar Javascript. I'm reading:

• Yahoo's YUI,
• Dojo,
• Prototype,
• Mootools,
• Mochikit, and
• Scriptaculous, plus outliers and extensions like
• Flapjax,
• Mooshow,
• iBox, and
• Lightbox.

Please contact me if I need to add a library to my reading list.

I've got some general impressions so far. Dojo and Mochikit are by far the heaviest. They're loaded with lots and lots of well tested unreadable undocumented components. Dojo supports its own weight because it's the only Javascript library that has a module loader, albeit a module loader that loads modules into the global name-space. YUI, Mootools, and Scriptaculous are comparatively higher quality but smaller and limited to their size by the lack of a good module system. YUI is the best documented, having lots of Javadoc style comments. Mootools, I think proves to be the highest quality code for the few things it does and does rather well. Scriptaculous and its base library Prototype, spun off the Ruby on Rails project, both seem to work pretty well, but the code is criminally bad, showing lots of signs of having been designed by whim. I get a very strong "the least that would work" vibe from it.

Dojo's module system intrigued me because it loads modules synchronously with AJAX and Javascript's eval. I've considered applying the same ideas for Cixar Javascript's module system. However, the current Cixar Javascript module system puts the power of nomenclature into the hands of the module writer, not the hands of Kurremkarmerruk, the Wizard who knows and manages all (or most) of the names in the universe. I think that the "CJS" syntax is verbose because of this feature, not because it loads modules asynchronously. Since loading modules asynchronously may have higher performance in the long run, I don't see much reason to adopt Dojo's approach. However, Dojo does include a lot of good snippets that seem to embody a lot of working knowledge on how to make Javascript work in many, many environments, so I do intend to study it throughly.

Let me back these statements up with some code. This is the Dojo syntax for defining, loading, and using a module:

dojo.provide('dojo.provided_module');
dojo.require('dojo.required_module');
dojo.provided_module.provision = dojo.required_module.provision;

This is Cixar Javascript's:

this.register('cixar/provided_module.js', function () {
this.require('cixar/required_module.js', function (that) {
this.provision = that.provision;
});
});

I particularly like using Javascript's with block to effectively bring all of a module into my name-space so that I don't have to qualify any of its names.

this.register('my.js', function () {
this.require('javascript.js', function (js) { with (js) {
assertEq(js.List, List);
}});
});

I'm getting comfortable with the parentheses and braces because I feel that localizing names is really important for the long term maintainability and extensibility of the world of Javascript.

From this preliminary analysis, I think I will be integrating most of Mootools code since it's small and high quality. I will probably also integrate parts of Dojo and Mochikit since their feature coverage is quite extensive, but porting whole modules is probably out of the question. In any case, I will try to bring a comprehensive set of features into CJS so that people coming from any of these frameworks will find some degree of familiarity, if not because of their experience with their respective Javascript libraries, then because of their familiarity with the server side scripting language on which that library was based.

Blowfish

Enough said.

McLorry

The McLorry, powered by a SirFusion reactor, operating by the magical virtues of the LuxTransistor, grants the operator initiative, the ability to dodge circumstance, to correct mistakes made.

Dancing Hamster

At work, someone wondered aloud what had happened to the dancing hamster. I'll tell you what happened: months locked in a caged. Now he's back.

The dancing hamster, ronin, bereft of master, master only of the dancing hamster fu. None have seen the technique and lived.

Terrain

This weekend's project was to write a program to generate tiles for maps in Tale. To this end, I needed to extract clips of trees, mountains, and mushrooms from svg files like tree-poplar.svg, that include layers with "metadata" like crop boxes and "pathing" boxes. Pathing boxes are rectangles that represent the base of a 3d object, so the umbra of a tree, for example. The idea is that these trees, mountains, and mushrooms can be combined into terrain tiles by filling a space with their pathing boxes, then rendering the corresponding terrain features from back to front. So, this weekend, I wrote a tool that will at length fill a region with randomly selected terrain features pared out of a given "plate" of images. Here's the resulting mushroom forest.

The algorithm is quite slow; it has an order of complexity something like (shooting from the hip here) O(n²). First, I extract the clips from the SVG plate, including their pathing and crop boxes. I populate a list with the sizes of each of the pathing boxes. The bulk of the algorithm is taking a given region and filling it up with as many of those pathing boxes possible in a suitably random fashion. To this end, I keep a queue of "regions" these boxes can occupy. These regions can overlap. I seed the queue with a single, large region. Then, I iteratively pull a region from the queue at random, find a suitable pathing box at random, place the pathing box inside the region, and then test every region in the queue against that pathing box, breaking any region that overlaps the pathing box into smaller regions that do not overlap the pathing box. Crawling through numerous off by one errors and infinite loops that still vex me though they're fixed, I finally managed to reliably plant a region with pathing boxes. I then sorted the pathing boxes from back to front and composited the grand image from the corresponding clips.

The next task is to set this up so that tiles can be generated incrementally throughout the world, and speed up the performance by using a quadtree, presumably the same quadtree we'll be using to distribute nodes of the world across multiple servers and organize the rooms into a hierarchical geographic grid.

The other major task is reviewing the mushroom graphic for ways to make the end result prettier. Perhaps thinner, pastel borders, and maybe some parametric color variation, or shadows.

Behold!

"Hear ye, hear ye! Santa Claus be commin' ye slags! Make way!"

Jolly Boots of Doom [mp3] [m4a]

Hexforce

I'm beginning to regret having not blogged my daily progress for the last seven years. There are a lot of undocumented discussions and ideas for Tale. One of the more recent ones is the notion of shards of hexforce. I've enlisted the aid of Geoff Kriston (previously mentioned by his mmearth.net character name, Toronsire Elenath) and he's distilled this description of the shards:

The Hexforce is the mystical mover of magic, the essence "mana", in Tale. Shattered into six shards, these pieces and their shadows are both mana dipoles and tomes of instruction, inscribed with instruction in the fundamental mechanics of the Tale world.