The Sourcerer

~/bin

I've started a project on github for my collection of general-purpose shell scripts: the ones I keep in ~/bin on each of my shell accounts. If you have any general purpose utilities, don't hesitate to fork the project; I'm sure we could collectively build a fantastic set of power tools.

---

I wrote a new one this week, called xip, that is a shell analog for the zip function in many languages (the name zip is naturally reserved for the pkzip utility). I created this script to join the ranks of diff and comm, all functions that benefit from multiple input streams. This comes on the heels of discovering at commandlinefu.com that there's a syntax for subshell fifo replacement. That is, you can supply a subshell as an argument to a command, and it will be replaced with the file name of a named pipe. Let's take the the canonical example:

$ cat a
a
b
c
$ cat b
b
a
$ diff <(sort a) <(sort b)
3d2
< c

To peer under the hood, I used echo.

$ echo <(echo)
/dev/fd/63

Ahah! The stream gets passed as an argument!

So, this opens up a world of possibilities. Normally you can only work with linear pipelines because the functions or programs only have one input and one output stream, and this limitation has created a dearth of standard utilities for working with multiple input streams. Before discovering this feature, the command line was like a programming language where functions only accepted one argument (and no implicit partial application, smarty-pants). Now I feel like I've discovered bash's secret cow level.

So, to remedy the lack of multi-parameter functions in shell, I started by making xip. It takes any number of file names as arguments and interlaces the lines of their output until one of the streams closes.

$ xip <(echo 1; echo 2) <(echo a; echo b)
1
a
2
b

You can then pipe that to a while read loop, or xargs -n 2 loop, to create a table. This example enumerates the lines of a file (jot for BSD, seq for Linux).

$ xip <(seq `cat a | wc -l`) a | xargs -n 2
1 a
2 b
3 c

I suppose the next fun trick is producing multiple output streams, with something like tee and mkfifo. I leave this as an exercise for the reader.

---

I've also included some of my older scripts from back in the days when I was working exclusively on Linux and used mpg123 to play my music. mpg123 is a command line music player, and it doesn't really have a playlist system built in (for that there are alternatives, but I digress). So, I used a pipeline to generate my playlist stream. cycle, shuffle, and enquote are in the github ~/bin project.

$ find . -name '*.mp3' \
	| cycle \
	| shuffle `find . -name '*.mp3' | wc -l` \
	| enquote \
	| xargs -n 1 mpg123

this entry was posted on Sat, 28 Mar 2009 at 14:36 in program/cli

Interoperable JavaScript Modules

This year has begun with a combination of wondrous events in the JavaScript theatre. I've been struggling to promote the idea of module system in JavaScript for several years now. There has been a sudden explosion of progress.

It started with a series of prototypes for module loaders for Tale in college, which eventually developed into modules.js, that over the last few years was refined by the development of the Chiron module library. I presented Chiron at BarCampLA last year, only succeeding to put Dan Kaminsky to sleep. Before I left Apple and the bay area, I introduced myself to Mark Miller from the Google Caja team including Ihab Awad and Mike Samuel and discussed modules over lunch in Mountain View. In May last year, Peter and I started discussing converging on a common module standard so that our Chiron and XJS libraries could be interoperable, but that effort floundered. However, Peter introduced me to the Helma NG project and Hannes Wallnoefer which has a compatible notion about modules. We converged partially toward a standard in August. Peter was also kind enough to notify me when Ihab Awad started a discussion about modules on the ECMAScript standard discussion list. I met up with the Caja team again in October for a full day to specifically design a module system that was both usable and securable. We discovered a way to make a module system that looked just like any other, but also reused inert module factories for multiple sandboxes, addressing the need for dependency injection.

January this year, Mark Miller sent word to Ihab and me that we were on the agenda for the next ECMAScript committee meeting later that month to present a proposal for adding modules to a future version of JavaScript. After extensive discussion, we nailed down a proposal and Ihab flew down to LA to work on a presentation with me before the meeting. We presented to the committee on the second day and it was received well. The conversation focused on what additional requirements we would need to nail down to actually make the modules secure.

At about the same time, Kevin Dangoor from the Bespin team at Mozilla prompted a massive discussion that attracted a flash crowd of developers around the world who were interested in sharing code among JavaScript implementations outside the browser. One week later, with 224 members, and 653 messages posted, we knew Kevin had struck a nerve.

The group founded the ServerJS project, and among the first common efforts was to converge on a module system. Ihab and I camped out on the list promoting, receiving feedback, and refining a securable module proposal. There are now several efforts to create compliant module loaders for various platforms including Jack (which works on Rhino with Jetty and Simple, and eventually v8cgi among others), a project called JSEng or GPSE to be released eventually by Wes Garland at PageMail, Kris Zyp's Persevere, and of course Chiron. We're working on getting the various platforms passing unit tests and sharing code. I've got about 11KLOCs of Chiron ported to the standard.

Meanwhile, Kevin has hinted that Bespin may eventually have a JavaScript backend running on Jack, which would be an impressive foothold for the eventual JavaScript standard module library.

So, if last year was the year of JavaScript module struggles, this year looks like it will be the year of JavaScript module success.

---

The technical details are on the Securable Modules wiki page. The general idea is that modules receive a "require" function for getting other modules with both absolute and relative identifiers, an "exports" object which the module shares with other modules, and an "environment" object for modules that use dependency injection, those things that ultimately provide IO in secured sandboxes.

A module would look like:

var file = require('file');
exports.foo = function (bar) {
	return file.File(bar, 'r');
};

Secure module loaders would prevent tampering with the primordials and the global scope by creating module factory functions that receive those three variables under a hermetic bell. A sandbox would be a group of secured singleton modules produced by calling the module factory functions, and sandboxes can create smaller sandboxes and share loaders to improve performance without "leaking" capabilities. If you're used to dependency injection modules, the difference is that the only security boundary is at the sandbox interface, and instead of instantiating modules with an explicit list of its required modules, you inject capabilities in the environment and all modules in that environment are loaded on demand and have access to those capabilities. The hermetic bell is a special evaluator to be provided by the JavaScript engine that runs programs in an alternate transitively frozen global scope.

Enjoy!

this entry was posted on Sat, 21 Mar 2009 at 15:09 in program/javascript

Dict versus dict

Chiron's base module provides bot a dict operator and a Dict factory method, as well as List and list, and analogously Set and unique. Dict and dict both accept the same basic types.

dict({a: 10}) =
Dict({a: 10}) =
Dict([["a", 10]])

dict("abc") =
Dict("abc") =
Dict([[0, "a"], [1, "b"], [2, "c"]]) =
dict(["a", "b", "c"]) =
Dict(["a", "b", "c"]) =
Dict(iter("abc"))

In code, the difference is that Dict is a type and dict is an operator. The difference in practice is that dict first checks whether the first argument is a subtype of Base (which includes all objects using the type system), and whether it implements a dict method. If so, it defers to that polymorphic dict method. Otherwise, it defers to Dict.

var base = require('./base');
var test = require('./test');
exports.Foo = base.type(function (self, supr) {
	self.dict = function () {
		return base.Dict({'a': 10});
	};
});
var foo = exports.Foo();
test.assertEq(
	base.dict(foo),
	base.Dict({'a': 10}),
	'dict behaves as a polymorphic operator'
);

The same difference applies to the polymorphic operators unique (that defers to Set if unique is not a member of the type), or list (that defers to List if list is not a member of the type). object and array are also polymorphic operators that work as copy constructors for Object and Array, but also defer to polymorphic object and array members. The default behaviors of object and array are to copy or coerce the argument to an Object or Array, since Object and Array cannot be used as copy constructors themselves. A complete variety of coercions are possible, extending well into the bizarre and insane.

array("abc") =
["a", "b", "c"]

object([1, 2, 3]) =
{'0': 1, '1': 2, '2': 3}

this entry was posted on Sun, 08 Mar 2009 at 16:56 in program/javascript/chiron

Holiday Bash

I'll be holding a little party at my terminal for the holidays. Please join me by running the following command in your shell.

((while true; do echo -en "\e[31m." >&2; echo; done) | (while read line; do echo -en "\e[32m."; done))

this entry was posted on Fri, 12 Dec 2008 at 21:41 in program

On Faith

I grew up in two religions—I promise to tell you which ones later. Contemplating the agreements and arguments between these two faiths helped me realize something very important.

I am wrong.

I'm wrong for a variety of reasons. But, by a twist of logic that's hard to accept until you've been alive for a few weeks, the best reasons for me to believe that I'm wrong are the ones I don't know yet.

• If I change my mind about a proposition, I either am wrong, or was wrong.
• I have changed my mind many times.
• I have either been wrong, or become wrong many times.
• I will probably change my mind many more times.
• I'm probably wrong.

On several occasions, I've realized that I was so wrong that I had to become a completely different person to become right. While I was in school, this occurred so frequently and dramatically, that by the time I was in junior high school, I had become the kind of person that I would have despised when I was in early elementary school. And now, I pity the boy I was in junior high for his bitterness. I'm furthermore haunted by the persisting memories and following cognizance of the people I have failed or hurt along the way.

The reason I was bitter in elementary school was that no-one wanted to be my friend. In hindsight, I've realized that I had alienated my peers and thus brought this ill fate upon myself. I was, however, kind. I was not condescending, like similar kids in my situation. I did not pick fights, nor did I take what I did not fairly deserve. If anything, I retained few pleasures for myself for fear of taking them from others. For ample, to this day, I have never ridden a shiny-silver tricycle like the ones that were so popular in my kindergarten playground, and I always waited for everyone to lose interest before I tried the swings.

My fault was more subtle than any of the unkind things that children can cause upon each other. I refused to play their game, a game that you and I play together every day. I refused to play a role. It was my opinion that every person should always wear their true feelings on their faces, and say only what they believed. I believed that it was dishonest to do anything else and could only lead to deferred hurt. I couldn't bear to stand around with a bunch of people and have trite conversations about immaterial matters or play fake dramas among friends. It would have violated my sense of honesty.

This is why I was a wholly uninteresting, boring, stick-in-the-mud person for the rest of that decade. I did eventually learn how to play a role, to play power-games, and to act out dramas about how I certainly "must" feel for the amusement of the situation. I got over myself, a little bit, and now I enjoy the more important truth. As I came to accept wholly the moment Dr. Janice Daurio uttered it over coffee in my final year of junior college, life is about building relationships with other people.

So, yes. I was wrong. I'm likely still wrong about many things. But, more importantly, even if I do find the ultimate truth, the general theory of everything, I will have no reason to ever be completely certain about it. No matter how small the universe is, it's larger than me, and it's larger than I can perceive. It is finer than the least perceptible granularity. There is no vantage in the universe from which I can see its entirety. Furthermore, since I am part of this universe, the last impediment to my full understanding of the universe, is the ability for me to fully understand myself. I take it to be a paradox for a box to contain itself completely, and no more do I believe it possible for my mind to contain a complete and detailed model of itself.

I used to think that the word "abstraction" meant to find a better, more general, and reusable theory. When I was in Clark Turner's class on professional responsibilities for software engineers, he called out the real definition of abstraction: to omit detail. The price of a bigger idea is less detail. That's the limit of our mind, and it's the limit of to our understanding of the universe. We can only claw at the shapes around us with our minds, bending our minds to better fit the model, but never fully contain it.

For these reasons, I believe that if there is a sin, it is certainty.

---

However, apart from never being sure about anything, there are many things worth believing. There are three good reasons to believe a proposition: correspondence, coherence, and pragmatism.

• Correspondence is a theory that there is a universe. A thing is true because it corresponds to that universe.
• Coherence is the theory that all truths must be logically consistent. There are bodies and combinations of premises that are consistent among themselves. If a premise contradicts an accepted truth, it may not be a member of that body of accepted truths. It, however, may be the basis for a new body of truths.
• Pragmatism is the harsh realization that neither of the other two theories gives you a place to start believing things. You need a basis, a first truth, and you need to assume that it's inherent to the universe. The problem with coherence is that there are many bodies of coherent truths, not all of which necessarily correspond to the universe. To be pragmatic, or practical, we have to make a guess. With regard to correspondence, the question is, "Which universe?", and the pragmatic answer is, "This one!".

Based on these three mechanisms, consider this minimal guide to finding the truth:

• Guess.
• Always remember that the guess might not correspond to the universe. Test it through observation.
• Always remember that the coherent body of truths based on the guess might be wrong too. Test it with logic.
• With gathered knowledge and experience, always try to make better guesses such that over time you can asymptotically approach certainty.

Correspondence, coherence, and pragmatism come out of the discipline of philosophy. The ideas are innate, but it's in philosophy classes and text books that I heard them thus succinctly articulated. The guide to finding the truth is the empirical method: science. Oddly enough, both ultimately boil down to faith and uncertainty, traditionally the purview of religion and agnosticism respectively. The discord between religion and science, under this light, looks more like a popular myth.

Becoming more right requires a lot of observation and thought, but there are some pretty good tools for contemplating truth. For one, coherence is probably the most solid theory of the three. If you focus on culling incoherent premises, or at least organizing them into piles of propositions to be evaluated as a whole, you might not find the truth, but you can mitigate a lot of probable falsehoods. Coherence is math, a concept that's free of the messy details of the physical world, a metaphysical archetype. As such, its employment is the most satisfying of the three reasons to believe.

The next best behavior is observation. Keep sense open. Gather and mull premises in hope that between perception and abstraction, some mote of truth about the universe to which those observations correspond leaks into your mental model of the universe.

That brings us to pragmatism. Of the three reasons to believe a thing, pragmatism is the most tenuous. Pragmatism is about faith, specifically making leaps of faith. In math and logic, these leaps are called postulates, certain suppositions that you make so that you have some basis for evaluating the coherence of other ideas. The trouble with a populate is that, by necessity, it must be the foundation for any certainty that follows. An article of faith is further beyond question or doubt than any conclusion arrived at through the trial of observation and coherence. For that reason, it's best to use pragmatism as seldom as possible.

In mathematics, we presume that there's something called incrementation. There's no proof that incrementation exists, and if we found one such proof, behind it would be terms that would have to be assumed instead. We accept incrementation, that there is a void called zero and a unit away from it in some direction called one. From there, we have all the material we need to converse about all the various kinds of arithmetic and algebra that are possible in the metaphysical verse in which there's incrementation.

Likewise, to engage in meaningful discourse about our universe, we have to make certain leaps of faith.

• The universe exists (otherwise, correspondence theory would be out).
• The universe is consistent (otherwise, coherence theory would be a wash too).
• You exist (cogito ergo sum, except that there's a paradox inherent to the assumption that if you think you must be. Let's just stick to the assumption, "I am.").
• You are actually you (this one really gives me the shivers once in a while).
• The universe is significant.

That's a sample of good things to believe in the absence of proof or even it's lesser cousin, evidence. In particular, if you're going to talk about the universe with anyone, it's pretty safe to assume that these are your common ground. If they're not, one of you is either yanking the other person's chain, or the conversation is pointless. Either way, it's time to move on.

---

The trouble with leaps of faith is that, the more of them that you make, the more likely they are to be inconsistent. Coherence and correspondence are much more reliable allies. For that reason, it's best to minimize leaps of faith. It takes especial care to frame explanations for observations without making careless leaps of faith to which you haven't already committed. They tend to sneak in for less wholesome reasons than the search for truth, and tend to get in the way when you try to reconcile your theory with the next observation.

Occam's Razor does not mean that the truth is simple. The quest for a General Theory of the Universe, wherein all fields (electric, magnetic, gravitational) are explained in the terms of a simple formula like Einstein's relation between energy and matter, is predicated on the faith that the universe does have a simple mathematical root. However, this is not an application of Occam's Razor. Occam's Razor states that if you have a simple explanation for a phenomenon and an elaborate explanation for the same phenomenon, it's best to assume that the former is true. That is, chose the explanation that requires the least faith.

My father is fond of recanting a story from my childhood wherein, to my chagrin, I am not the protagonist. I learned how to write my name with crayons roughly when I was four years old. About a day later, my parents discovered my name written on every surface that could retain a crayon's impression, including my sister's back. Producing Kathy's marked verso as evidence, my parents accused me of the crime. In my defense I claimed that she had done it herself. Bear in mind, Kathy was half my age.

---

Apart from unlikely stories for easily explicable phenomena, a person who believes nothing that they do not perceive, induce, or deduce would be a sad and empty shell.

One problem for atheists, agnostics, and skeptics is that there is no natural source of Hope. In fact, you don't have to learn much physics to get to the part where the universe appears to be spiraling down toward a low-energy drain, the "Heat Death of the Universe". At some point, you really do have to make a leap of faith. So, it's important to add another precept to the catalog of postulates.

• There is hope.

In Yoda's words, "Fear leads to anger, anger leads to hate, hate leads to suffering.". While fear often comes from rational distrust and can drive us to excel, it can also mire us in depression. Hope is the cure for fear. Hope is our reason to try to make the future better than the past, and without it we are lost. Since there is no definitive evidence that the future will be better than the past, and the case is piled high that it will ultimately be worse or end in a zero sum, we must postulate that hope exists, that we can craft a better future.

Sometimes, when I am almost completely broken, I lay awake and let that truth fill me to the brim. I let the warmth flow from my core to my pores and to the bottoms of my feet. Hope, the critical endogenous morphine, eventually fills my dreams with blurry but bright visions of solace. I banish my doubts with a crucial lie and my strength returns.

Consider that power though. Can't blind belief drive us to do wicked things? Perhaps it's better to let hope stand alone, without attaching it to a litany of prerequisites or consequences. Everything you attach to a blind supposition, increasing its complexity, risks motivating you to do cruel things without good reasons. It's better to let hope stand alone, a single pure island of beauty on the horizon, or otherwise risk contaminating that vision with zeal for something less perfect.

There are, after all, many reasons to believe a proposition apart from need, logic, and observation. These include wont, fear, and pressure to conform with peers. Despite my disdain for the vapid writings of Terry Goodkind in the Sword of Truth novels, I find myself quoting The Wizards' First Rule, "People…will believe a lie because they want to believe it's true, or because they are afraid it might be true.". Terry wrote this in the spirit of condescent and bitterness, but it serves a greater purpose as an admonition. There are certain conditions where it's important to elevate skepticism:

• you want to believe
• someone else wants you to believe
• you're afraid not to believe

One of the greatest quotes said in service of hope and truth was that all we had to fear was fear, and one of the worst offenses against those same ideals was the creation of a rainbow of codes for how afraid we must be. It takes a powerful will to see coercion through fear, particularly communal fear, and these are the precise conditions when a healthy skepticism and faith in hope against what another would have you believe, what you are afraid might be true, and what you most desperately want to believe, might serve you best.

There are many good reasons to build communities, but getting together to publicly profess your agreement with one another, or to be fed the truth without argument, smothers that mote of latent uncertainty that helps people listen each other's ruminations, doubts, and observations. It repels people who disagree, the people who need your fellowship most. For those who grow up in such communities, they either grow with a hindered analytical sense, or buried revulsion and fear of rejection or guilt. If you gather to bolster your faith through the comfort of your peers agreement, your community submerges the relevance and welcomeness of pragmatism, coherence, and correspondence. A community should feel free to express their actual beliefs, argue, and converge through trial and support.

An article on Slate called, Does Religion Make you Nice?, explores the possibility that religion and atheism are orthogonal to how friendly a person grows to be. American atheists tend to be less nice than European atheists. The dependent factor in how well adjusted a person is in a society is acceptance in a community. We need to have communities that welcome people without regard to the details of their faith. Using tenets of faith to build walls around your church ultimately alienates people with the potential to be good.

If communities gather to ponder difficult choices on the fringes of desire and righteousness, they might discover that they actually hold very different beliefs. It's unhealthy to delude yourself into believing that every member of a community subscribes to the same faith. Our differences in experience, values, and chemistry, from birth, bring us to very different conclusions. We need to value each-other's experience more than our collective synthesis.

---

Regarding the philosophy of behavior, ethics, there is an ancient test for whether to do or not do a thing. You first generalize the act to a rule. For example, if I'm pondering whether to wear a silly hat in public, I would generalize that thought into a rule, like, "People should be welcome to wear silly hats in public.". Then you ask yourself whether society would function if everyone were to follow that rule. What would happen if everyone were welcome to wear silly hats in public?

Emanuel Kant called it the Categorical Imperative, but with subtle variations and derivations, it's a timeless strategy embodied by the Golden Rule. "Do unto others as you would have them do unto you.". Or, via my father the Cowboy Western fanatic, "Before judging a person, walk a mile in their moccasins.". Or, the corollary, "Do for others as you would have them do for you.".

"Categorical imperative" literally means, "the most important rule.". It's the recipe for peace and stability. However, like all mortal truths, it is far from perfect. Often to find a balance between reason and love, you must consider why every situation is special and carefully weigh how specific your situation is and how far away from your path you would, should, or can go for another soul. It's often best to err on the side of altruism. That is, defy your mortal laziness and do everything in your power to help others, and expect nothing from them.

That leads us to a flaw in the imperative. The categorical imperative also tends to imply that you can expect others to treat you with the same degree of cordiality with which you would treat them.

To address that flaw, consider a special rule. In order for the categorical imperative to bring about stability in a community, we have to create a bias, a pair of poles within which the imperfect universe can safely vacillate and gradually approach peace. The categorical imperative implies that your behavior must exactly match the expectations of all people in society. That cannot be the case. So we consider two rules.

• In so far as you can carry your mortal husk, be strict about your own behavior.
• In so far as you can defy your mortal indignation, be tolerant of the behavior of others. For those acts you cannot bring yourself to tolerate, try to bring yourself to forgive.

The beauty of these rules is that they fit within the mechanics of the categorical imperative. If every person in the world were to follow these two rules perfectly, we could eventually have peace. It also establishes the reason and necessity of forgiveness, and a solid basis for discussing the lossy abstraction of "human rights".

The last remaining flaw of these rules is that they can promote self-neglect. As I learned from the Star Trek episode, Evolution, self-neglect serves no-one, so there's a third important rule from Guinan: always take for yourself what you can fairly assume for your own health and happiness.

---

I've used the term, "universe", extensively. I've expounded upon the roles of uncertainty, empiricism, and hope in the quest for truth and peace. Throughout, it's important to have a solid definition of "The Universe". Many unfortunate arguments can be rendered moot by consensus on the meaning of "universe" and a thorough reevaluation of dependent ideas in terms of that meaning.

Let's consider an inductive definition of the universe.

• basis: I am in the universe.
• recursive step: anything that has impact on a part of the universe is also in the universe.

Apart from discussions about causal-domain-sheer, this definition is concise, simple, and readily applicable. We could consider much more detailed and complicated definitions with intricacies to suit our particular belief systems or definitions of other words we know only descriptively. For the sake of argument, let us take this definition as a postulate and let the definitions of other word and ideas move freely around it.

---

Imagine for a moment that you have achieved a vantage from which you can see the entire universe. This vantage, by necessity, is outside the universe and your perception pierces its occlusive barriers. You truly see the universe in its entirety.

Zoom out.

The universe is surrounded by void: a conceptual region in which the universe does not exist. No matter how many transendences you make to get to the vantage of the universe, there will still be an eternal nothing beyond it, at least one transcendently infinite scope larger than the universe itself.

Zoom out. Zoom out until you have taken in enough of the void into your perspective that the entire universe's size divided into the size of the infinite void is merely a point. There is only void.

From this vantage, there is an infinity of nothing filled with infinitesimal points, one of which is our entire universe. This does not diminish the significance of our universe, but it frees you to consider all of those other points. Each one is a universe, apart from our own, some perhaps sharing attributes but each distinct.

Mathematical concepts are special. There are uncountably infinite mathematical concepts. Each one is its own metaphysical realm whose complexity emerges from simple rules. This flushes well with the assertions that we all make whether consciously or not:

• A point is true because it corresponds to the universe.
• The universe is perfectly coherent.

One nice thing about this model of the universe is that it clears up that existential question about creation. Almost all explanations about how our universe came to be rely on intervention outside our universe. Consider this sequence of propositions:

• A exists. B does not exist.
• A creates B.
• B does exist.

The trouble is that A clearly has an impact on B and thus is part of the universe, B. That would necessitate A and B to both exist initially, which is a contradiction. What if A and B simply exist? Mathematical concepts do not require creation events to be internally consistent. This liberates us of the contradiction of creation, but also leaves room for the possibility that A and B existed initially, and for A to exist before B within the confines of the real universe, C. This opens the possibilities of towers of tortoises, big explosions, or sub-universal progenitors.

From a programmer's perspective, among fractals, programming languages, and Conway's Game of Life, there's compelling evidence that suggests that extraordinarily complex patterns can emerge from simple rules.

• Define a collection of simple rules.
• Apply those rules with mathematical vigor.
• Observe that complexity emerges.

Thus, it's possible to become comfortable with the idea that from a simple set of rules, a universe of great complexity can emerge. It does not exist any more than it does not exist. Since we're in it, it's significance to us, more so than any other metaphysical construct that my small mind can begin to fathom, is relevant. Furthermore, a universe arrived at by math, is unassailable perfect.

---

Let's define "nature" as the set of rules inherent to the "universe". Consider the notion of "super-natural" things or events. If we refer back to our definition of the universe, the only things that can be apart from the universe are those that have no impact on the universe. From there, let's consider the notion of "miracles", events in the universe that defy our conventional understanding of how the universe works, or "nature". One confusion that I think we can avoid is the bundling of the ideas "super-natural", "para-normal", and "miracle". By the definition of the universe, for a miracle to actually be a part of the universe, it must abide by "nature". Thus, for a miracle to exist, it must be "para-normal", not "super-natural".

---

Various tomes at various times talk about "God". Particularly, I've heard the following attributed to God:

• perfection
• anthropomorphism
• creation of the universe
• omniscience
• omnipotence
• super-natural
• performance of miracles

Let's take a step back. God can only be one of the following:

• beyond and outside the universe,
• within the universe, or
• be the universe itself.

If we take the universe to be perfect in whole or part, God could be any one of these things, but the term perfect suffers the diminution of its meaning. Let's say that perfection cannot be broken, thus a whole may be perfect and any part of it falls from perfection in so much as it is not complete. If we adhere to the notion that the universe is perfect, by this reasoning, the god would have to be either the universe or beyond it.

Omniscience denotes the ability to see the entire universe. That would imply that God is beyond the universe, or is the universe as well.

Omnipotence denotes the ability to do anything. If the universe is defined by natural rules, to break those rules could only occur in a universe with different rules. I would contend for God to be omnipotent, omnipotent would have to mean "capable of performing miracles", rather than "capable of anything, and thus capable of super-natural acts". There's quite a bit of room for the unexpected within the realm of possibility. I would prefer to pick a different word than omnipotence rather than conjure a new meaning from a word that clearly means "all-capable". How about, "super-powerful", or "ultra-potent".

Referring to the universe as a mathematical construct based on rules, the universe needs no creator any more than a story needs a story-teller in order to exist. Creation means to make something from nothing. I would contend that this definition is unsuitable for any real act. For example, creating a building is really construction from baser materials. If we substitute the term "creation" for "construction", the term could easily apply to the so-called "creations" of people, and also to the construction of a region of the universe by some super-powerful being. In order for this to be the case, God would have to be a part of the universe, and while not the creator of the universe, the constructor of a world.

---

The meaning of the word "death" is "end of life". To rationalize the notion of life after death, it is necessary to distinguish corporeal life from ethereal life. In order for either to be meaningful, they both most be real, that is to say, part of the universe. Ethereal life, therefore is either real, or part of another universe. Either possibility is plausible. For example, ethereal life could be in a distinct universe, where it can have no impact on our universe. However, there are infinite verses apart from our universe abiding infinitely diverse rules, none of which are relevant to ours. This notion of ethereal life does not have any meaning in the context of our corporeal lives. For example, such a life would not be bounded by consequences of our mortal lives, but rather bounded by the infinite possibilities of patterns of thought. The other possibility is that ethereal life exists within our universe, is bounded by the same rules, and thus the actions of our mortal lives could have an impact on them. If this is the case, ethereal life is a matter of a mysterious science, not math. In either case, ethereal life is probably not even similar to anything we would want to believe of it.

There are a lot of reasons to want to believe in life after death. For some people, it counters their fear of death. For others, it fills the gap in justice that the universe does not appear to serve during life. Another reason to believe in life after death is to lend an additional purpose to the immortal soul: if one's soul is separate from their body, living an ethereal life instead of a corporeal life, it's easy to reconcile determinism and free choice.

If we take the universe to be a mathematical construct, bounded by rules, the universe is deterministic. That is, if one had complete knowledge of one state of the universe, perfect knowledge of the rules of the universe, and infinite computational power, one could extrapolate the entire universe. Naturally, this is beyond our means as mortal components of the universe, but the notion permits us to use inductive reasoning, the notion that, for a statistically representative sample of the universe, if a rule appears be in action, it can be expected to occur in other samples. Inductive reasoning is imperfect in that our sample, and our perceptions of the rules are imperfect, but the idea is predicated on a predictable universe, the kind we can reason about. It's only rational to make this assumption.

So, the argument occasionally comes up that the universe can only be either deterministic or individuals have the ability to make choices. The notion is that, for a choice to be freely made, it must not be constrained by the rules of the universe. If the universe "made our choices for us", we would not be accountable for our actions. It's furthermore complicated because some people believe that God broke the world so that we could make choices, thus giving our choices meaning.

One way to reconcile determinism and free choice is to assert that a part of the mind, the ethereal soul, is not bound by the rules of the universe. This would contradict the definition of the universe, wherein all things that impact another thing in the universe are part of the universe.

There's another potential resolution. There are wheels within wheels in the universe, and our mind is one of them. In our minds, we are capable of formulating abstractions of the universe, metaphysical verses wherein we make many different choices. These metaphysical verses are in the realm of mathematical possibility because they are imperfect and incomplete renditions of the universe. These are not choices. They are options, and they are no more real than their perceived consequences. Also, the simple fact that we only ever choose one option reinforces the notion that the universe is deterministic. Making a choice is bounded by physical laws, sure, but that does not mean that we are any less responsible for them. It's a necessary assumption that all people are responsible for their actions and that gives our choices meaning.

Neither does this diminish the truth underlying the story of how God broke the world to give us choice. Consider a perfect universe, where we define perfection in this case to be one where good things happen by the rules of the verse. In this realm, choices do not render actions good or bad, but the law of the universe. For choices to be meaningful, good and evil must be independent of the laws of the verse. This explains why bad things can happen in a perfect universe. The story does not, however, address the premise that the rules of the universe are independent of an act of creation.

There's also consolation in relegating one's soul to oblivion after mortal death. If anything, mortality heightens the importance of life, this one chance to make good choices. We are custodians of the universe and for each other. We will have a legacy forever, and from a vantage outside our universe, our impact appears to be timeless.

---

I mentioned that I was raised in two religions. I'm an unconfirmed, non-practicing Roman Catholic. I also watched Star Trek. Laugh, but episode after episode, it's a series of complex metaphysical and moral thought experiments: a recipe for premature awakening for a child.

When I was in elementary school, I attended a Catholic program called CCD, or Confraternity of Christian Doctrine. At that age in public school, teachers and administrators appealed to our sense of justice and fairness. It was presumed that people my age only understood quid pro quo, a philosophy of balance and revenge, not forgiveness and stability. In CCD, teachers and administrators appealed to our desire to be loved. But, having watched more than one morality play on Star Trek, I was already an idealist, both of justice and reason. I wanted altruism in school, and I wanted philosophy and logic in church.

I never managed to escape school. As soon as I learned modesty, I deduced that my mother could not take me to school if I refused to get dressed in the morning.

I was wrong.

My attendance was impeccable for the rest of my academic career.

However, after a couple years of coloring in pastoral scenes with Jesus and being told that I should believe a boatload of facts mostly relating to how I should behave, because he loved me so completely, I told my mother that I no longer wanted to go to CCD. My mother is a well-intentioned person with a heart that fills every part of her. She does not fathom why a person would question the doctrine of the church. She also had no idea how to convince me that I needed to go to CCD. So, she telephoned the director of religious education, an intimidating pear-shaped woman with a smoker's voice, and put me on the line. She asked, "Why do you not want to come to CCD." I was mortified. I really had no idea how to articulate my thoughts. I feared offending her. I feared the loss of love. I had nothing to say. I also never went to CCD again. It wasn't until junior college that I met Catholics who believed that there were children for whom CCD was not appropriate.

---

Reading through this article, you have probably noted points that you agreed with or disagreed with. In the past, I've accidentally alienated people with a small number of my thoughts, perhaps not because they disliked me, but because they did not want to be exposed to my point of view and mar their conviction to their beliefs. It's a hard thing to have your faith questioned. It's my hope and care while writing this article to keep you all, my friends and other readers, in my fellowship, my community. It is inevitable that any two of us will disagree on any number of points, but if we hold in our hearts a mote of uncertainty and a well of hope, we can asymptotically approach the truth through discourse together.

this entry was posted on Thu, 27 Nov 2008 at 18:00 in philosophy

Google Eyes 2

Ryan Paul finally found a use for my Google Eyes graphic in his article, Security Expert: Google not anonymous enough, which was posted a couple months ago.

this entry was posted on Mon, 24 Nov 2008 at 18:27 in program

Blogosphere

When I moved my blog over to askawizard.blogspot.com, the quickest and easiest way to give my page a unique look was to make my own banner graphic. I decided to make a depiction of the "blogosphere" as I envisioned it based on the mimetically virulent xkcd 239. Randal Munroe stakes claim to a literal interpretation of the popular term "blogosphere": a layer of the atmosphere where free speech enthusiasts convene aboard various flying platforms and hawk their ideas in a sort of aerial or ethereal bazaar.

According to xkcd, Cory Doctorow from the EFF is the only blogger who actually wears a cape and goggles. I caught a certain implication that he's the only person crazy enough to dress up when they passionately jotcast. This is not true. I put on my robe and wizard hat. Don't take that the wrong way.

So, I drew a depiction of the blogosphere. Over the last few weeks, I've taken some time to characterize more of my web neighborhood.

• Ryan and I are in the foreground in the guises we took for our web comic, Punnished.
• Cory Doctorow occupies his ironclad balloon on the opposite side of the scene. (?:T)?ron Paul lurks behind in his blimp.
• Like the wizards and witches of Harry Potter, in this metaphysical representation of the web, microblogging is facilitated by sending flocks of Twitter bird messengers from balloon to balloon. I called out Josh Lewis, a prolific blogger in my network, by putting him and his family in a balloon the same initial color as his old blog, emanating a halo of tweety birds.
• Ars Technica is heralded as one of the largest "blogs" on the Internet. My long-time MUD project partner and friend, Ryan Paul edits the Ars Open Ended journal. While the blogosphere is not quite high enough to qualify as "orbital" in the sense of Ars's purported "Orbital HQ", I decided to put Ryan in a nearby balloon emblazoned with a likeness of the Ars logo. Ryan is wearing a cloak of Roman imperial purple.
• One of the earliest bloggers, Peter-Paul Koch flies in the dark-blue Quirksmode balloon, from which he provides a steady hail of browser compatibility tables.
• Zeppelin enthusiast, Simon Willson, flies a Django themed zeppelin. He is trailed by the mimetically unstoppable Django Pony.
• A man I believe saved JavaScript from horrible doom, Doug Crockford occupies a balloon in his blog's colors.
• As a nod to all the fabulous people who participated in #wotw2, a Martian Unpowered Inter-planetary Attack Cannister falls through the scene on the left.

I've posted an annotated version of the current banner as a larger image, including a version in the original Scalable Vector Graphics format, wherein the annotations are a hidden layer.

I plan to add to the scene every once in a while.

this entry was posted on Sat, 08 Nov 2008 at 21:56 in

My iTunes Playlist

I have almost 9,000 songs, comprising a month of continuous play and 60GB of storage. I've actually listened to maybe half and rated about 20% of the library. Random shuffle doesn't work for me anymore.

When I was in college, I noticed that trying to do homework with lyrical music hindered my productivity, presumably because it engaged my otherwise occupied language brain-matter. I'm also a musician, so I've definitely collected a trove of anecdotal evidence supporting the assertion that exposure and repetition to particular pieces (and broadly but with weaker correlation, certain genres) expands appreciation. Also, overexposure diminishes the effect, presumably because the amygdala begins tuning out the pattern. Randomly traversing my library usually leads to irritation. Also, I thirst for new, rare, serendipitous musical experiences at the expense of occasionally hearing a piece I'm not ready for.

So, on account of what I presume to be common psychological phenomena, my ideal musical experience would consist of:

• mostly music I know and like
• some music I don't know occasionally
• no music that I definitely don't like
• some constant minimum interval between playback of a given piece.
• intervals between hearing a given song inversely proportional to how well I like the piece
• over time, my playlist should improve as I provide feedback to the system

A few months ago, I found a way to accomplish this with iTunes smart playlists. I construct "pools" of songs. Each pool contains only songs that have a particular rating and haven't been played recently. If there are lot of songs with a particular rating, I generally require a longer interval between plays. So, I created a pool for each rating, and maximum number of songs in each pool to tune the probability of a a song being chosen from each category. Then, I created a master smart playlist that incorporates all of the rating pools.

5 stars

I have 76 tunes in this category. Almost all of them can make it to the master playlist. Since they play frequently, the dominant factor is when they were last played. The number of songs that haven't been played or skipped in the last 5 days hovers around 20. As a special factor for these, I broke the songs that are longer than 10 minutes into their own category so that only two of them contribute to the master mix at any time. I like Mahler's second symphony a WHOLE LOT, but a half an hour is a long commitment and I prefer to save it for maybe once every other week. I also have about ten different versions of Beethoven's Symphony 7 movement 2, so I might have to make a new category for it so only one of them comes up at a time.

4 stars

200 tunes total. 200 tune limit. 20 days between playing. Defer 10 days if skipped. Stable around 20 tunes contributed to the master playlist, so minimum interval is the dominant factor.

3 stars

800 tunes total. 100 tune limit, sampled from least recently played. Defer 1 week if skipped. Stable at 100 tunes contributed to the master playlist, so the maximum sample size is the dominant factor.

2 stars

800 tunes total. 20 tune limit, sampled randomly. Defer 4 months when played or skipped. stable at 20 contributed to the master playlist, so the maximum sample size is the dominant factor.

1 star

I reserve this rating for songs I don't want to hear in a random shuffle, but don't want to delete either. This includes Christmas tunes, apart from the soundtrack to The Nightmare Before Christmas. There are about 400 of these. I should probably use this rating for songs I would like to very rarely hear and use the checkbox to exorcise a song from my random shuffle.

0 stars

These are songs I've not rated. 6500 tunes. 30 tune limit, sampled randomly. Playing or skipping defers the next chance to play for six months. There are 30 tunes in this playlist, so the dominant factor is the max tune limit.

Mix

Then I create a my main mix playlist from these rating pool lists. The trick is to create an "any" predicate and include all of the smaller playlists with playlist predicate rules.

---

So, believe it or not, this minimizes my need to fiddle with iTunes and keeps me focused on work. If you've got a ridiculous music library too, I highly recommend this technique.

Also, if you work on iTunes, I highly recommend providing a smart playlist abstraction with equalizer knobs for each rating to automate similar processes; not everyone's a programmer and I bet this problem is just beginning to surface for most folks. It would be nice to see how probable a particular song is to be played based on the size of its pool, the effective sample size of its pool, and the total of all sample sizes. I also want to be able to sort and filter and bulk set "checked" and "unchecked".

this entry was posted on Sat, 08 Nov 2008 at 13:56 in program

War of the Worlds 2.0 - The Post Mortem

Stuff's just beginning to trickle in reflecting on our Halloween reenactment of The War of the Worlds on Twitter. Here are some links to what we've found so far.

• The invasion status feed, @wotw2
• Search for participants using the #wotw2 hashtag.
• The Buzz Out Loud CNET podcast that Josh Lewis called into to advertise the event
• The Call of Cthubuntu, wherein Ryan Paul plugged the event on Arstechnica.
• Coverage from Wired's Underwire Blog
• Coverage from Ashville, NC
• Josh Lewis's video
• @RhythmHippy's doctored photos
• Flickr photos
• @MackReed's blog entry
• @sea_dot's blog entry
• @MackReed's retrospective blog entry
• @sea_dot's retrospective blog entry
• Archive of everything we could scrape when the event concluded and we realized we were going to want an archive to build cool visualizations from. The archive includes source code you can use to perform your own automated tweets in conjunction with @segphault's Gwibber microblog Python library.
• The tweet plan spreadsheet

Each participant averaged 2.6 tweets total. The most active participants posted 60 to 100 tweets. There were around 600 people following the invasion progress. That's about 1500 tweets for all participants over the course of the event. I think it's safe to assume that about 10,000 people were touched by these apocalyptic tidings.

Hopefully, we'll have a participation histogram (total tweet count for each participant) soon. I'd like to see a timeline integrating all of the media we produced.

That was a lot of fun. We'll have to do something similar again some time.

this entry was posted on Sat, 01 Nov 2008 at 14:35 in

What is Tale Anyway?

So, I've been working on this project that's currently called Tale for nearly a decade now. The notion is to build an interesting, fun, humorous, immersive, narrative virtual reality. If you're into such things, it's more succinctly called a distributed, web-based MUD. I don't intend to go into detail about how Tale is like a MUD and unlike a MUD. This article is intended to explore some of the novel aspects of Tale.

Gameplay

Tale's landing page, tale.im, is the game. You click play and the game begins. There won't be a lengthy sign up and character creation process; everyone starts as a ghost in Limbo or gets straight back to playing from wherever they left off. To start playing, you just click or type "start" and you're consciousness is installed in a standard-issue resident of Dya, the Tale world. From there you can start doing whatever it is you like doing most: socializing, exploring, fighting, building, or getting into character.

Playing Tale is like many things you're probably already familiar with. It's like chatting with friends with an Instant Message client, or IRC, or opening a Terminal and issuing commands. MUDs in general combine the social aspects of chatting with friends, with a virtual world simulator and its own narrative and commands. Some MUDs lean in favor of socialization and others on gameplay. Tale favors neither, allowing you to gracefully shift between mostly chatting and mostly playing. Since the game is in a web-browser instead of a specialized chat application or old-fashioned command terminal, Tale can alternate among coherent interactive modes like entering quotes to say aloud like "hello, world!", entering action commands like "go north", typing quick commands with single keys for mini-games like "p" for "parry", "r" for riposte, "f" for feint if you're fencing, or browsing through menus to discover commands visually.

Already in Instant Message and IRC clients, you might be familiar with commands like "/me laughs" (that you can use in AIM) or "/nick cowbert" (that you can use to chose a name in IRC). If you use Vim, you might already be familiar with colon commands like ":w". If you use FireFox's incremental search feature, you know that you can use single-quote and slash to start searching for text as you type, alternating between single-key command mode into a full-line command mode.

Tale's input field will accept similar commands depending on whether you're mostly chatting, mostly playing, or performing quick, expert actions. If you're mostly chatting, you'll be able to issue commands with the slash "/" prefix like /go north, and when you're mostly playing you'll be able to chat with a quote prefix like "hi. If you're in an expert mode where you're, say, navigating a yacht on the high-sea with discrete arrow key and letter key commands, you can start entering a chat or command with the same keys.

Narration

Each player in the Tale world has a narrator. This is the charming fellow who listens to your commands and tells you how the story unfolds in response. The narrator is a program that keeps track of what you already know and what you're likely to be interested in and interprets the events occurring around your character like, "Joe says 'hi'.", into just that kind of textual prose, as well as taking your commands and plugging them into the simulator in the selfsame event objects. The ideas of "events" and "things" are central to how Tale works behind the scenes, but it suffices to say that if you are "Elbereth" and you're talking to "Glorfiniel", the narrator would translate events like:

Elbereth Say "Hello" to Gorlfiniel
Glorfiniel Say "Hi" to Glorfiniel

…to story-like narrative accounting for various linguistic and cognitive assumptions that you regularly make &mdash "You say, 'Hello', to Glorfiniel and says, 'Hi', back.". There is a lot of room for making the narrator more and more interesting as Tale development continues, but there's code in Tale already that creates reasonable paragraphs from a stream of events, accounting for pronouns and such, but still sounds fairly robotic.

Having a complex narrator serves many purposes in Tale. First, it makes the game immersive. It also relieves the burden of creating lots of static content, which is one of the limiting factors that ultimately ends with most games feeling rather shallow. A complex narrator can also abstract the tired MUD practice of BATTLE SPAM, where lines upon lines of discrete hits and jabs rapidly scroll down up the chat buffer.

The most subtle benefit of the narrator is that it can introduce a significant burden for programmers seeking to automate their characters, often called "botting". "botting" tends to diminish the quality of gameplay for non-programmer players. With the narrator in our arsenal, we can engage in an arms race with "botters", continuously evolving the narrator to deter botting without banning the practice outright. This incentive structure could be a lot of fun for everyone.

Beyond the Narrative

The narrative is the centerpiece of Tale gameplay. However, unlike a Telnet or Teletype MUD, Tale is not strictly text-based. Since the game takes place in a web browser, we intend to take advantage of the opportunity to add icons, maps, inventory visualizations, sounds, and atmosphere and lighting changes to punctuate the narrative.

Among other things, we're planning to use "parametric" graphics to underscore the narrative. For example, if you're in a sailing or flying vessel, or riding a rabbit around the Tale world, your ride will have a parametric icon. We're using SVG graphic manipulation on the server-side to render permutations of layers from "macro" graphics to produce customized versions of each ride and vessel. The parameters include things like the genetic domain of your steed (Is it descended from an elephant? Did the Narwhal bless it with a tusk?), and the installed rigging on your Zeppelin. The two Ride macro graphics have around 100 layers each.

Inspired by Josh Lewis's old blog site, we intend to mix up the style sheet colors on the page slowly and subtly to reflect the time of day and lighting of your surroundings as you explore the world. Each face of the world has its own color scheme and different parts of the world are lit by the 20-sided Sun and various celestial dice, at times filtered through dappled shade, or illuminated by magma and mana. Using alpha-translucent PNG renderings of SVG graphics, and subtly tuning the foreground and background colors of the entire page, we'll gradually modify the mood of the narration.

And there's Music! The musical selection you experience as you roam the world will vary based on what face of Dya you're travelling on and the tension level of the narrative: safety, adventure, battle, and peril. Chris Pasillas has composed six brilliant themes and variations for Tale and is currently rendering them. The game uses a variation of Scott Shiller's SoundManager library that's been ported to operate as a Chiron JavaScript module. (The largest distinctions are that the Flash bridge code has been factored into its own module, and the API has been simplified. It's a complete rewrite using SM2 as an MTASC reference.)

Engine

The Tale engine is a real-time clock-based event-driven simulation. Every event can trace its cause to a tick of the world clock, which for the time being is imagined to be once per second. The difference between a player character and a non-player character (NPC or MOB in the MUD parlance) is that a non-player character generates a progression of commands on demand using a Python generator that yields Event or Verb object trees in response to observations about their environment and their current state, and a player character has a queue of the same kind of Event or Verb trees. This means that invoking a command in Tale does not render an immediate physical response from the world's engine. Rather, a command is translated by the narrator into an Event and it's enqueued to be invoked when the world clock ticks and visits everything that's not busy or waiting, in the whole world. This levels the playing field between people with nearly instantaneous Internet connections to the Tale server with those who have up to one clock tick worth of lag. It also, in a sense, regulates a certain "conservation of energy" law throughout the world, permitting game mechanics to be tuned more accurately and fairly.

World

Feature Number One in Tale is the data structure we've chosen to model the world. This data-structure underpins it's potential consistency, algorithmic subtlety, performance, scalability, and distributability. This data-structure conveniently models a world of arbitrary size, scope, and detail and provides the scaffolding for engine effort minimization for event propagation, abstraction, and synthesis.

So, what is it? Well, nothing new really: it's a tree. Depending on the scope and particular region of application, its children have 0, 4, 6, or 9 branches on each node. Most of the world is simply a quadtree. Each node has four children, one for each quadrant. The top of the quadtree has a bounding box that encompasses exactly all of contained, square region, and for purposes of Tale, conceptually encompasses all of the air-space above that region. A room is a leaf of the quadtree: a node through which players travel with a unit width and height. Each node is an abstraction of all of its contained rooms, containing the sum of its rooms contents. Roaming the quadtree, each player can divine it surroundings by analyzing the contents and events occurring in its own room, and then those events and contents of each of the more abstract rooms that contain it all the way up to the root of the world tree. Each room is directly connected to its parent and children, and traversing linearly across the plane of the world uses tree traversal algorithms where you zoom in and out of the quadtree to find your destination.

Among the algorithmic possibilities that the quadtree provides a scaffold for, we can provide multi-scale gameplay, the same inspiration behind the recently released, Spore. The most mundane way this might be applied would be to have larger scale creature roam the world in abstract bounding boxes, like a Fire Drake that would move from 16x16 room to 16x16 room. Room abstractions could also be used for flight or sea navigation, since one travels higher and faster with that medium, somewhat negating the mundane obstacles of the world floor. As an eagle, one might move about the world by zooming in and out instead of traversing in cardinal directions. Also, more abstract forms of gameplay might take place entirely on room abstractions. For example, melee would occur in 1x1 rooms, ranged attack (missiles and magic) in 8x8, tactics at 32x32 with 4x4 tiles, strategy at 256x256 with region-sized tiles, and politics at larger yet. Taking a moment to step out of a first-person player experience, garnering increasingly abstract political support from larger social organizations, gameplay could scale from thief to Queen).

Another algorithmic possibility is maintenance of the world's physical invariants, like global distribution and availability of various resources. Using abstractions to redistribute resources absolutely throughout the world would make it possible to keep the weight of gold throughout the world constant. This would prevent the most common physical inflation problems that most MUDs suffer.

The other major implication is that the quadtree permits entire branches of the world to run on independent servers with minimal cross-talk. During my last year at Cal Poly, Ryan Witt engaged his distributed computing team at Caltech to implement a Distributed Hash Table (Chord) for Tale and we extensively discussed the implications of the quadtree for purposes of distribution for scale and redundancy. Ryan and I are now roommates working at FastSoft. The topic of distributed computing comes up from time to time, even though we still need to get a vertical gameplay stack working on a single system before we begin implementing distribution.

Events

One problem Shawn Tice (who needs his own home page, because he's too awesome not to have one at this juncture) and I struggled with when we were coding up the second Python rendition of the quadtree was event management. The general notion has always been that events would escalate up the quadtree to a scope that contains all objects that can notice the event, then each object would have an opportunity to respond to the event by visiting each node in their room's "scope chain". The borrowed notion of a scope chain, in this case, means the containing room and the transitive closure† on its parents. Events would each have an "impact" attribute and each object would have a "sense" attribute. So, each time the world ticks, a bottom up visitation of the world would calculate the minimum impact that an event would need to have to be noticed by the one thing in that branch of the world with the highest sensitivity. This would be performed for all of the senses in parallel: visual, aural, olfactory, thermal, thaumaturgical, social, and such. All objects that can have effect events would have senses. For example, a wall can hear a sound so that it can echo it. Most events would also be directed, so they can only propagate in one of the cardinal directions: north, south, east, or west.

However, as you may have already had an inkling of suspicion, this quadtree-based event propagation model isn't actually realistic, and adding realism would nullify the performance and scalability benefits of the system. For example, with the described event propagation system, if you were standing in a room off-center of a quadtree, as at (2, 2) of a 4x4 quadtree, an sound that is loud enough to carry to room (3, 3) might not be loud enough to carry to room (1, 1). The sound would have to be loud enough to carry to (0, 0) before (1, 1) would hear it at all. So, to guarantee that events radiate the same distance in every direction, you need to propagate events laterally, not merely along the quadtree abstraction scope. However, radiating events laterally defeats the performance benefits of restricting perceptible events to those along the scope chain.

So, there was a trade off between performance and realism. Then we remembered we were writing a game. Thinking back to the original Zelda, we observed that each tile of the screen was analogous to a room in Tale, and that every screen in Zelda was analogous to one of the nodes in its abstract node scope chain. That is, there was some parent room that contains about 30 of the rooms Link walked around in. When he got to the edge of the screen, he was no less privy to what was going on in the neighboring room than he was on the opposite side of the screen. So, we decided that the same abstraction would be sufficient for Tale, except that in Tale, the opportunity for zooming in and out around your character was much more profound; we could provide zoom perspectives for every binary order of magnitude.

Frameworks

The current underlying technologies include Python, Twisted, AJAX, Comet, and Lighttpd. In the past, I dabbled with C++ and Boost, including an iostream system that decoupled input and output, had reasonable variable names, and supported VT100 stream functors, but that code branch has been abandoned since 2002. In addition, the project has inspired the creation of frameworks that I'm calling Chiron (a JavaScript module system), and Python on Planes (a system for persistent HTTP route and responder trees).

Parting Words

So, Tale is a pretty massive undertaking. When I started this project, I had no idea that good ideas took so much more time to implement than paltry ones, but that lesson's learned. To meet at least one of my New Year resolutions (that is, one of the milestones for Tale), I'm cutting back scope in the short term in order to get the project up and running by January. A lot of this design, if not all of its powerful implication, I plan to realize by then. This weekend, I've been working on sewing the quadtree, the Dyan world design, and the Narrator into a single piece. As always, I'm looking for people who are willing to volunteer to set themselves up with commit access to Tale so that, in the absence of time to spend on the project (which I know none of us have), a sufficient body of people can randomly wake up in a cold sweat with a bad idea and have nothing between them and implementing it for Tale!

---

† The excessively precise term transitive closure, in this case, means the room's parent, grandparent, great-grand-parent, ad nauseam. Ad nauseam, in this case, means, "until you retch from nausea or meet Adam and Eve: whichever comes first."

this entry was posted on Sun, 19 Oct 2008 at 19:07 in tale

War of the Worlds 2.0 Update

It turns out I write a lot of words and say very little. Here's what you need to know about the upcoming alien invasion:

• Follow @wotw2
• On Halloween, tweet in earnest about the unfolding alien invasion. Make your own story. Keep in touch with your friends like you would in any other disaster situation. Try to imagine what you would tweet as the aliens land, emerge, and lay waste to every metropolis around the world.
• Email wotw2@cixar.com if you want to help plan the story or provide technical assistance.

this entry was posted on Sun, 05 Oct 2008 at 23:21 in

War of the Worlds 2.0

Last week, Josh Lewis; friend, former Apple coworker, and Lex Luthor hairstyle enthusiast; got me thinking about fiction on Twitter. Then, Ryan Paul pointed out that he had written an article about Twitter fiction already. Here's the idea. Let's (and by "us", I mean everyone) reenact The War of the Worlds, on the Internet, for Halloween!

CBS ran the Orsen Welles War of the Worlds radio program in the tense times leading up to the second World War. The aforementioned Wikipedia article claims that Adolf Hitler denounced the program as a sign of democratic decadence. Without commercial breaks and interpolated among real news, the program was broadcast in earnest and public panic ensued. War of the Worlds was the Ultimate Prank, never to be reproduced. As an homage, let's take Halloween to tweet, share bookmarks and status messages, and blog in earnest about the alien invasion in progress. Everyone, tell your story.

The War of the Worlds has several phases that I believe have strong analogs in the tense times leading to World Web II (point oh).

1. a noteworthy astronomer speculates on the possibility of an alien invasion. This would be a good time to talk about the Drake equation in your blog, especially if astronomy is your hobby. Send an email to wotw@cixar.com with your blog so we can proliferate it on the @wotw2 Twitter account.
2. The alien invasion occurs. Follow @wotw2 to keep in sync with the progress of the invasion. This Twitter feed will automatically update, in general terms, the unfolding of the alien invasion like clockwork throughout the world. Coordinate with Tweeters in your area to tell local stories.
1. cylinders fall from the sky. Tweet about where you are. Ask your friends where they are. Form posses. Skip town or take a closer look.
2. tripods emerge. Flee, get stuck in traffic, or take refuge and tell us what you see.
3. Martians begin obliterating every Terran metropolitan area with heat rays. Don't call them heat-rays; that would be a dead giveaway. Describe what they do and come up with your own name! Do you work in a public service like hospitals or fire? What's your job and what do you do? Do you organize your coworkers and flee? Do you head for the hills with your go-bag?
4. Military, local militia, and national guard units get organized and attack the alien invaders. Do you serve in the military? This is your last chance to tell us where you're headed. Do you have family in a militia? Try to keep in touch and let us know how and where they valiantly fought and lost.
5. The invasion spreads from cities to countryside.
6. Tripods begin to shut down an malfunction. Are you near one? Do you take a closer look?
3. After the threat dies down, people begin to blog and speculate about what happened, and every topic near and dear to them.
4. The curtain rises. Blog, link, and tweet about the experience.

The "War of the Worlds 2.0" event will be synchronized, on Halloween Friday, with the http://twitter.com/wotw2 account and we're writing automation with Ryan Paul's Gwibber tool to automatically post Tweets to various services on that day. If you would like to make additional accounts to synchronize local events, please send an email to wotw2@cixar.com with a Twitter account name and password and we'll hook you up with edit privileges for the tweet plan on Google Docs. Tweets (rows) will be deployed for each column (account).

Let's tell a story!

this entry was posted on Sun, 05 Oct 2008 at 21:51 in

JSON Basics

JSON is a strict subset of JavaScript, particularly a subset of its object-literal notation, discovered and specified by Doug Crockford. The subset is sufficient to make the creation of parsers and formatters in various languages nearly trivial, while completely trivializing the process of parsing the notation in a web browser.

Object-literals in JavaScript are very similar to their analogs in many other languages, like Perl, Python, and even AppleScript. The notation provisions text strings, numbers, booleans, and the literal null for all elemental (scalar) data. Then the notation provides Arrays for ordered values and Objects for unordered, unique, string-to-anything key-value-pair mappings. With these types, you can express most hierarchical data easily.

10
3.1415
"a"
true
false
null
[1, 2, 3]
{"a": 10, "b": 20}
[{"a": 10}, {"a": 20}]

JSON makes a couple simplifications even on JavaScript's object literal grammar. These make it even easier to write parsers and formatters.

1. a JSON expression contains no new-line characters.
2. all strings, including keys in objects, are enquoted between double quotes.

JSON joins the ranks of many other markup languages that we can use to easily transfer data among web servers, but its primary function is as a common data interchange language between web browser clients and web servers hosted in the numerous languages of the web. JSON is well adapted for this space because it can take advantage, through various channels, of every web browser's fast, built-in JavaScript interpreter.

There are two flavors of JSON services with subtle differences for both clients and servers. One is JSON proper, which I will call XHR JSON because it uses an XML HTTP Request. The other is called JSONP or "JSON with Padding". You would use one, the other, or neither based on security and performance concerns.

XHR JSON

XHR JSON uses a feature that exists in one form or another in all modern web-browsers, called an XML HTTP Request, and a function in JavaScript that lets you evaluate arbitrary text strings as JavaScript programs, called eval. With an XML HTTP Request, the client can make an HTTP Request to any URL on the same domain as the hosting page. This constraint is called the "Same Origin Policy". Unfortunately, the policy is in many cases not sufficient to isolate vulnerability to paths of a particular domain, nor to prevent cross site scripts from using the data (more on that later). Whether the security mechanism is effective or not is a longer and later discussion. The point being that this mechanism is the crux of your choice between XHR JSON and JSONP.

With an XHR, you request plain text from a URL on the same domain as your page, then you evaluate it as a JavaScript program. Performing a cross-browser compatible XML HTTP Request isn't trivial in itself, so let's assume that I'm using a library that provides an xhr function that synchronously (blocks) until an HTTP request is complete and returns the content of the HTTP response as a String. There are other variations on xhr for asynchronous requests and grabbing XML.

var text = xhr("/some.json");
var json = eval(text);

In this case, the "/some.json" contains unadulterated JSON. However, because your JSON is likely to be an Object like {"a": 10}, we need to make a special arrangement. A JavaScript program that is merely an Object literal would be mis-parsed initially as a code block. For this reason, we must force the JavaScript parser into expression context instead of statement context. For this reason, we wrap the JSON string in parentheses or assign it to a variable.

var text = xhr("/some.json");
var json = eval("(" + text + ")");

I prefer parentheses because I haven't, in my fallible memory, encountered a browser that supported XHR but wasn't standards compliant enough for the eval function to return the value of the last evaluated expression.

When you use an XHR to grab JSON, you are vulnerable to the host, depending on it to not give you an alternate JavaScript program that insidiously evaluates to the same data. For that reason, a lot of JSON libraries engage in the slower and dubious attempt to validate the JSON before evaluating it with a regular expression. The bottom line is that you're vulnerable to your server when you use XHR and eval.

That being said, it's better to get an exception early than an untraceable error later. For that reason, attempting to validate JSON is a good idea. There's another one: variable laundering. The eval function inherits the calling context's scope chain. This means that the server can read and alter any variables on your scope chain. I use an evalGlobal routine to launder my scope chain. This doesn't give security all by itself, but it could help lead to a secure system down the way and can turn a bunch of silent name resolution errors or data leaks into thrown NameErrors.

(function (evalGlobal) {
	var text = xhr("/some.json");
	validateJson(text);
	var json = evalGlobal("(" + text + ")");
	...
})(function () {
	return eval(arguments[0]);
})

I'll give a detailed explanation of evalGlobal in another article. For now, suffice it to say, this is much more elegant than using a variable to capture the JSON value, although it is possible:

var text = xhr("/some.json");
var json;
eval("json = " + text);

JSONP

JSONP is different than XHR JSON in both the way the server hosts the data and in the way that the client consumes it. On the client side, the user adds a <script> tag to their own page. The source of the script is the URL of a server side program with the name of a callback function that the client places in global scope sent as a query argument.

<script src="http://other.com/some.jsonp?callback=foo">

The client script arranges to receive parsed and evaluated JSON data asynchronously by adding a foo method to the global scope, the window object.

window.foo = function (json) {
	...
	delete window.foo;
};
var script = document.createElement('script');
script.src = "http://other.com/some.jsonp?callback=foo";
document.getElementsByTagName('head').appendChild(script);

When you add a script tag to your document, browsers are kind enough to notice and automatically send an HTTP request to fetch the request JavaScript program. In this case, your page trusts the script on other.com to return a JavaScript program that will call your "foo" function and pass it some JSON data.

foo({"a": 10});

With JSONP, the client is vulnerable to the remote server because it can opt to write an arbitrary JavaScript program before calling foo, if at all. So, you should only use JSONP to request data from domains that you trust.

Also JSONP is slower and less responsive to errors than XHR JSON can be. The only signal that you receive as to the progress or status of a JSONP request is whether your callback gets called in a timely fashion. XHR JSON is preferable in all situations where it is possible and it may even make sense to create a proxy to the other domain from your same domain server. Using a proxy also gives you an opportunity to validate the JSON on the server-side, where computation time is cheap.

Same Origin XHR JSON

There's another trick with XHR JSON, and I'm not sure what scenarios require it. Some people can use the JSONP technique to fetch JSON from a foreign domain. These folks can't send HTTP headers or cookies, and they never get an opportunity to alter the text of the HTTP request before it's evaluated as JavaScript in their browser. I would think that it would be sufficient to prevent an other domain client from intercepting sensitive data for the server to require an authenticated token in the HTTP request, as can be provided by an XML HTTP Request but not a JSONP request. However, some crackers can attempt to get data from your service by using JSON data in a cross site script, much like JSONP. However, instead of using a callback, these crackers arrange to override the Array or Object constructors and thus can monitor and transmit snippets of JSON constructed by simply evaluating JavaScript object literal notation. This technique can be prevented by padding your XHR JSON service with an infinite loop.

while (1);
{"a": 10}

In this case, your client conspires with the server, and since it does get a chance to intercept and modify the text of the JSON, it strips the known number of characters for the while loop before evaluating it.

var text = xhr("/some.json");
var json = evalGlobal("(" + text.substring("while (1);".length) + ")");

What baffles me is that, unless you've secured your JSON with an authentication token, any server capable of making HTTP requests and parsing JSON could do the same thing. Malicious clients are not required to use web browsers. The only situation where this might occur would be if the cracker had compromised your client already, had your authentication token, and needed your browser to make a cross domain JSONP request on its behalf. That could not be the case since the server would have no reason to give an XHR JSON authentication token to a client that could only fetch data with JSONP. That point is even moot since, going back, the cracker has already compromised your client and might as well use XHR JSON with all the same rights as you on even the same origin.

That being said, I noticed that GMail used this technique, so I assume there's substance to it. Perhaps someone will clarify in the comments.

this entry was posted on Sun, 05 Oct 2008 at 00:38 in program

Designing Django's Object-Relational-Model - The Python Saga - Part 6

Django is a web application framework in the Python language. One of the advantages that Django has over other libraries is that it was written and designed by Python experts. That is to say, they knew about variadic arguments, properties, and metaclasses. Furthermore, they knew how to cleverly use these ideas to sweep a lot of complexity under the hood (or bonnet if you will; some of them appear to be British) so that common developers, or uncommonly good developers who want to think about other things most of the time, can gracefully suspend disbelief that anything complicated is going on when they design their database in pure Python. This article will illustrate how Django uses metaclasses and properties to present an abstraction layer where you can specify a database schema with Python classes. For simplicity, the "database" backend will be plain Python primitive objects—tables will be dictionaries of dictionaries.

In the end, we want to be able to write code that looks a whole lot like it's using Django's Object-Relational-Model:

class Cow(Model):
	id = PrimaryKey()
	name = ModelProperty()

cow = Cow(id = 0, name = 'Moolius')
cow.save()

cow = Cow.objects.get(0)

The easiest part (for the purpose of this exercise) is Django's concept of an "object manager". In Django, every model has an object manager that provides a query API and, depending on the backend, might cache instances of Model objects. Conveniently, a very narrow subset of the object manager API is almost exactly the same as a dictionary. Conceptually, the object manager boils down to a dictionary proxy for the database where you can use the get function to retrieve records from the database. For simplicity, our ObjectManager is just going to be a dictionary.

class ObjectManager(dict):
	pass

Beyond the scope of this article, the ObjectManager should be handy for grabbing lots of objects from the database at once. Django provides a very thorough and relatively well-optimized lazy query system with its object managers. The ObjectManager has get, and filter methods which, instead of simply accepting the primary key, accept keyword arguments that translate to predicate logic rules. In particular, the filter function is lazy, so you can chain filter commands to construct complex queries and Django only goes to the database once.

While it would be super-cool to model all of this with native Python, it actually is a lot of code, so that's a topic for maybe later. We'll just use the built in dict.get.

We'll also need all of the code from Part 5 since models will be another application of the ordered property pattern. This is how Django creates SQL tables with fields in the same order as the Python properties.

from ordered_class import \
	OrderedMetaclass,\
	OrderedClass,\
	OrderedProperty

We use the OrderedMetaclass to make a ModelMetaclass. The model metaclass will have all the same responsibilities as our StructMetaclass, including "dubbing" the properties so that they know their own names. The model metaclass will also create an ObjectManager for the class. This isn't the complete ModelMetaclass; we'll come back to it.

class ModelMetaclass(OrderedMetaclass):
	def __init__(self, name, bases, attys):
		super(ModelMetaclass, self).__init__(name, bases, attys)
		if '_abstract' not in attys:
			self.objects = ObjectManager()
			for name, property in self._ordered_properties:
				property.dub(name, self)

The next step is to create a ModelProperty base class. This class will be an OrderedProperty so it's sortable. It will also need to implement the dub method so it can figure out its name. Other than that, it'll be just like the StructProperty from the previous section: it will get and set its corresponding item in the given object.

class ModelProperty(OrderedProperty):
	def __get__(self, objekt, klass):
		return objekt[self.item_name]
	def __set__(self, objekt, value):
		objekt[self.item_name] = value
	def dub(self, name):
		self.item_name = name
		return self

There is a distinction in the refinement of ModelProperty from StructProperty: ModelProperty objects will eventually need to distinguish the value stored in the dictionary from the value returned when you access an attribute. In the primitive case, they're the same, but for ForeignKey objects, down the road, you'll store the primary key for the foreign model instead of the actual object. This is the same as the behavior in an underlying database backend.

class ModelProperty(OrderedProperty):
	def __get__(self, objekt, klass):
		return objekt[self.item_name]
	def __set__(self, objekt, value):
		objekt[self.item_name] = value
	def dub(self, name):
		self.attr_name = name
		self.item_name = name
		return self

Let's consider a PrimaryKey ModelProperty. The purpose of a PrimaryKey is to designate a property of a model that will be used as the index in its object manager dictionary. In Django, this can be an implicit id field at the beginning of the table. For simplicity in this exercise, we'll require every model to explicitly declare a PrimaryKey. The ModelMetaclass will identify which of its ordered properties is the primary key by observing its type. Other than their type, a primary key's behavior is the same as a normal ModelProperty, so it's a really easy declaration:

class PrimaryKey(ModelProperty):
	pass

Now we can go back to our ModelMetaclass and add the code we need for every class to know the name of its primary key. I create a list of PrimaryKey objects from my _ordered_properties and pop off the last one, leaving error checking as an exercise for a more rigorous implementation. There should be only one primary key.

class ModelMetaclass(OrderedMetaclass):
	def __init__(self, name, bases, attys):
		super(ModelMetaclass, self).__init__(name, bases, attys)
		if '_abstract' not in attys:
			self.objects = ObjectManager()
			for name, property in self._ordered_properties:
				property.dub(name)
			self._pk_name = [
				name
				for name, property in self._ordered_properties
				if isinstance(property, PrimaryKey)
			].pop()

Now all we need is a Model base class. The model base class will just be a dictionary with the model metaclass and a note that it's abstract: that is, it does not have properties so the metaclass better not treat it as a normal model.

class Model(OrderedClass, dict):
	__metaclass__ = ModelMetaclass
	_abstract = True

The model will also have a special pk attribute for accessing the primary key and a save method for committing a model to the ObjectManager.

class Model(OrderedClass, dict):
	__metaclass__ = ModelMetaclass
	_abstract = True

	def save(self):
		self.objects[self.pk] = self

	@property
	def pk(self):
		return getattr(self, self._pk_name)

Now we have all the pieces we need to begin using the API. Let's look at that cow model.

class Cow(Model):
	id = PrimaryKey()
	name = ModelProperty()

cow = Cow(id = 0, name = 'Moolius')
cow.save()

cow = Cow.objects.get(0)

All of this works now. You make a cow model; that invokes the model metaclass that sets up Cow._pk_name to be "id" and tacks on a Cow.objects object manager. Then we make a cow and put it in Cow.objects with the save method. This is analogous to committing it to the database backend. From that point, we can use the object manager to retrieve it again.

We can refine the Model base class to take advantage of the fact that it's not just a dictionary anymore: it's an ordered dictionary. We create a better __init__ method that will let us assign the attributes of our Cow either positionally or with keywords. That makes our cow more like a hybrid of a list and a dictionary. Also, since our model instances aren't merely dictionaries, we create a new __repr__ method that will note that cows are cows and moose are moooose. The new __repr__ method also takes the liberty to write the items in the order in which their properties were declared.

class Model(OrderedClass, dict):

	…

	def __init__(self, *values, **kws):
		super(Model, self).__init__()
		found = set()
		for (name, property), value in zip(
			self._ordered_properties,
			values,
		):
			setattr(self, name, value)
			found.add(name)
		for name, value in kws.items():
			if name in found:
				raise TypeError("Multiple values for argument %s." % repr(name))
			setattr(self, name, value)

	…

	def __repr__(self):
		return '<%s %s>' % (
			self.__class__.__name__,
			" ".join(
				"%s:%s" % (
					property.item_name,
					repr(self[property.item_name])
				)
				for name, property in self._ordered_properties
			)
		)

Now we can make a cow model with positional and keyword arguments, and print it out nice and fancy-like:

>>> Cow(0, name = 'Moolius')
<Cow id:0 name:"Moolius">

The next step is to introduce ForeignKey model properties. These are properties that will refer, via a relation on a primary key, to an object in another model. So, the ForeignKey class will accept a Model for the foreign model. Its dub method will override the item_name (preserving the attr_name) provided by it's super-class's dub method. The new item_name with be the attr_name and the name of the primary key from the foreign table, delimited by an underbar. This will let the foreign key property hide the fact that it does not contain a direct reference to the foreign object; it just keeps the foreign object's primary key. However, if you access the foreign key property on a model instance, it will go off and diligently fetch the corresponding model instance. If you assign to the foreign key property, it'll tolerate either a primary key or an actual instance.

class ForeignKey(ModelProperty):
	def __init__(self, model, *args, **kws):
		super(ForeignKey, self).__init__(*args, **kws)
		self.foreign_model = model
	def __get__(self, objekt, klass):
		return self.foreign_model.objects.get(objekt[self.item_name])
	def __set__(self, objekt, value):
		if isinstance(value, self.foreign_model):
			objekt[self.item_name] = value.pk
		else:
			objekt[self.item_name] = value
	def dub(self, name):
		super(ForeignKey, self).dub(name)
		self.item_name = '%s_%s' % (
			name,
			self.foreign_model._pk_name,
		)

Now we can write code with more than one model using relationships. Let's give our cow a bell.

class Bell(Model):
	id = PrimaryKey()

class Cow(Model):
	id = PrimaryKey()
	name = ModelProperty()
	bell = ForeignKey(Bell)

bell = Bell(0)
bell.save()
cow = Cow(0, 'Moolius', bell)
cow.save()

Note that you must save the bell so that when you construct the cow, it can fetch the bell from Bell.objects.

There's more to Django's ORM, of course. This article doesn't cover parsing and validation, which are both assisted by the ORM. Nor does it cover queries, query sets, the related_name for ForeignKey properties on foreign models, Django's ability to use strings for forward references to models that have not yet been declared, or many of the other really neat features.

What this article does cover though, is that you can create a powerful abstraction of a proxied database with pure-Python in less than 200 lines of code. This means that you could create a light-weight proxy over HTTP to a Django database that exposes itself with a REST API. You could also create an abstraction layer that would allow you to pump Django ORM duck-types back into Django to use pure Python objects in addition to or in stead of a database backend.

But, if this article does nothing else, I hope it communicates that Django is cool. I have read a whole lot of code from every dark corner of the web and I have liked very little of it; people I've worked with will testify that I've regularly "hated on" every library or framework I've ever seen. I've never met Simon Willson and the growing developer community around Django. However, I've read their code and now I can tell you, over the course of several articles, that they're really smart and you should use their code.

this entry was posted on Fri, 03 Oct 2008 at 15:13 in program/python

Ordered Properties - The Python Saga - Part 5

In C and SQL, structs and records have properties that appear in a particular order. In Python, objects use hash-tables to store their attributes, so the order is not deterministic nor relevant. That's no consolation if you're trying to model C structs or SQL tables in Python though. Reading though the Django code, I discovered that those wily coders had synthesized a technique that combines the virtues of properties and metaclasses that we can generally model the order in which fields of a struct or SQL table appear.

The trick is to provide an API that allows your users to write code like:

from time import gmtime
from cstruct import Struct, IntegerProperty

class EpochTime(Struct):
	seconds = IntegerProperty()
	microseconds = IntegerProperty()

epoch_time = EpochTime()
timestruct = gmtime(epoch_time.seconds)

In this case, the Struct type cares about the size, order, and disposition of the C structure it models so that it can unpack a byte buffer presumably retrieved from a C-type library.

There are two components to the general solution. First, there's an OrderedProperty base type. Ordered properties track the order in which they were initialized. For this purpose, ordered properties use a global counter. The absolute value of a property's creation counter is irrelevant. The only requirement is that they monotonically increase as each property is declared, and that classes declared concurrently do not interfere.

from itertools import count
next_counter = count().next

I learned about itertools from Brett Cannon who was preparing his thesis defense when I was at Cal Poly. In another piece of code, which I would cite if I could recall, I learned the trick of using the itertools.count function to atomize a global counter. It takes advantage of Python's dubious global interpreter lock.

Then the OrderedProperty base type just stores a creation counter upon initialization. Keep in mind that all derived types must trickle their __init__ call—your base types are not always what they seem and there are use cases you can not foresee where you might be required to receive and pass your initialization arguments to an unknown super-type. That's a side-effect of working in a language with mix-ins, and it's a "good thing".

class OrderedProperty(object):
	def __init__(self, *args, **kws):
		self._creation_counter = next_counter()
		super(OrderedProperty, self).__init__(*args, **kws)

The next part of the puzzle is inspecting your property order. We use a metaclass to note when new types are created and we give them an _ordered_properties attribute with the ordered-property items in their attributes. Keep in mind that base types might have properties too. __mro__ is an attribute of all classes that is a linearized list of a classes inheritance hierarchy. It's effectively the result of a dynamic topological sort algorithm for the closure of your base types. We traverse it backwards so that if you create a dictionary via dict(_ordered_properties), name collisions are resolved chronologically.

class OrderedMetaclass(type):
	def __init__(self, name, bases, attys):
		super(OrderedMetaclass, self).__init__(name, bases, attys)
		self._ordered_properties = sorted(
			(
				(name, value)
				for base in reversed(self.__mro__)
				for name, value in base.__dict__.items()
				if isinstance(value, OrderedProperty)
			),
			key = lambda (name, property): property._creation_counter,
		)

Then, we create our OrderedClass that we can inherit to get free _ordered_properties attributes.

class OrderedClass(object):
	__metaclass__ = OrderedMetaclass

Let's see it in action:

class Foo(OrderedClass):
	bar = OrderedProperty()
	baz = OrderedProperty()
Foo._ordered_properties == [
	('bar', <Ordered Property instance somewhere>),
	('baz', <Ordered Property instance somewhere>),
]

With a small modification, we can track ordered inner classes too.

class OrderedMetaclass(type):
	def __init__(self, name, bases, attys):
		super(OrderedMetaclass, self).__init__(name, bases, attys)
		self._creation_counter = next_counter()
		self._ordered_properties = sorted(
			(
				(name, value)
				for base in reversed(self.__mro__)
				for name, value in base.__dict__.items()
				if isinstance(value, OrderedProperty)
				or isinstance(value, OrderedMetaclass)
			),
			key = lambda (name, property): property._creation_counter,
		)

So, we put all of those order classes in our generic ordered properties module. Now we can delve into our particular Struct example.

First, we need field types. We will need a base type and derivative types for all of the field types we want to model from C, like IntegerField. Bear in mind that OrderedProperty is just a mix-in; it doesn't actually define __get__ and its ilk because those are all specific to the derivative implementation. All struct fields are going to store their actual values in a special _value dictionary on their corresponding Struct instance.

class StructProperty(OrderedProperty):
	def __get__(self, objekt, klass):
		return objekt._values[self.name]
	def __set__(self, objekt, value):
		objekt._values[self.name] = value
	def dub(self, name):
		self.name = name
		return self

You'll notice that instances of StructProperty need to know their name, the key in their corresponding instance's _values dictionary. The struct property instances don't get this from their initializer. Instead, each property will get "dubbed", given a name, when the StructMetaclass visits its _ordered_properties.

Let's just look at an integer.

class IntegerProperty(StructProperty):
	_format = 'i'

The only thing special about an integer is that it's format specifier for the pack routine is "i".

We're going to want to use a metaclass again, this time inheriting from our OrderedMetaclass. The purpose of this metaclass will be to analyze the ordered properties, construct an aggregate format specifier for pack and unpack methods, and to dub each of its properties with their name.

class StructMetaclass(OrderedMetaclass):
	def __init__(self, name, bases, attys):
		super(StructMetaclass, self).__init__(name, bases, attys)
		for name, property in self._ordered_properties:
			property.dub(name)
		self._format = "".join(
			property._format
			for name, property in self._ordered_properties
		)

All that remains is to create our API base class, Struct. This class initializes its values and declares its metaclass.

from struct import unpack

class Struct(OrderedClass):
	__metaclass__ = StructMetaclass

	def __init__(self, *args, **kws):
		super(Struct, self).__init__(*args, **kws)
		self._values = {}

	def unpack(self, value, prefix = None):
		if prefix is None: prefix = ""
		for (name, property), value in zip(
			self._ordered_properties,
			unpack(prefix + self._format, value)
		):
			self._values[name] = value

So, now our epoch time example is possible using Struct and IntegerProperty, completely oblivious to the machinations behind the scenes.

from time import gmtime
from datetime import datetime

class EpochTime(Struct):
	seconds = IntegerProperty()
	microseconds = IntegerProperty()
epoch_time = EpochTime()

timestruct = gmtime(epoch_time.seconds)
datestruct = (timestruct[:6] + (epoch_time.microseconds,))
print datetime(*datestruct)

this entry was posted on Wed, 01 Oct 2008 at 20:38 in program/python

Metaclasses - The Python Saga - Part 4

The original type function, whose behavior is preserved in modern Python 2.5, accepts an object and returns the class, albeit the type, that would emit it. It's like the typeof operator in JavaScript that returns the String name of the primitive type of an object, or the C++ function that returns a pointer to an object's virtual function table. They're all sufficient for comparing apples to oranges, but all of them are also insufficient for the more interesting comparison of apples to the idea of a Fiji apple: the question, "Does your type inherit from this?", that can be accomplished with Python's isinstance, JavaScript's instanceof, or C++'s infernal dynamic_cast. So, type's single argument behavior is effectively retired.

At some transcendental moment, somebody deeply involved in the Python project must have been thinking, "Well, if functions and classes return objects, what returns a class? Could a class, like a property, be syntactic sugar for some deeply metaphysical latent behavior in pure Python?". I figure this is how the type function grew its new wings.

So consider a class declaration:

class Foo(object):
	bar = 10
	def __init__(self, bar = None):
		if bar is not None:
			self.bar = bar

This is what is actually happening behind the curtains:

name = 'Foo'
bases = (object,)
def __init__(self, bar = None):
	if bar is not None:
		self.bar = bar
attys = {'bar': bar, '__init__': __init__}
Foo = type(name, bases, attys)

That is to say, there is no magic in the syntax. Ultimately all of the magic happens when you call type. By "magic" I mean functionality that cannot be replicated in pure Python without the interpreter's intervention.

The type function returns a type: a function that returns new instances. It's also called a "metaclass". type just happens to also be the implied metaclass of object. That is to say, you can create your own metaclasses.

The big question about metaclasses is, "Why on earth would you want to define a metaclass?". David Mertz from IBM wrote that you would simply know when you needed them. Since I read that article, I've wracked my mind for a reason to use metaclasses to no avail. At some point, I was reading Django's ORM code and it occurred to me that the reason you would want to define a metaclass is to provide a class in your API that, when subclassed by unsuspecting users, would invoke certain preparations without their knowledge or consent. Here's how:

Define a metaclass. The best way to define a metaclass is to inherit type and override its __init__ method.

class FooType(type):
	def __init__(self, name, bases, attys):
		super(FooType, self).__init__(name, bases, attys)
		print '%s was declared!' % name

Define a base class for your API. The trick here is that you can override its metaclass. Let's look at this one in an interactive interpreter:

>>> class Foo(object):
...     __metaclass__ = FooType
...
Foo was declared!
>>>

Whoa! You didn't call anything. Not true. Here's what actually happened:

name = 'Foo'
bases = (object,)
attys = {}
attys['__metaclass__'] = FooType
Foo = attys.get('__metaclass__', type)(name, bases, attys)

Python checks your attributes for a metaclass before defaulting to type.

That means that your FooType.__init__ got called. Hot damn. I wonder what happens if you create a subclass.

>>> class Bar(Foo):
...     pass
...
Bar was declared!
>>>

Whoa! I totally inherited a metaclass.

So, the reason for writing a metaclass is that metaclasses give you an opportunity to get and manipulate your derived class objects before anyone instantiates them. You get to do this once, right after the class dictionary is fully populated. You can take this opportunity to monitor class declarations, to prepare additional attributes, or to interpolate additional base types.

---

Keep in mind that metaclasses are jealous. If you create a metaclass for a type that inherits from base classes in someone else's API, your metaclass must inherit from their metaclass. I suspect that it's best not to assume that your base types use a particular metaclass. Thankfully, you can use an expression for your base type.

class FooType(getattr(Bar, '__metaclass__', type)):
	pass
class Foo(Bar):
	__metaclass__ = FooType

This takes advantage of the Python idiom of accessor methods like dict.get and getattr that accept a default-if-none-exists argument. Unfortunately, Python's object doesn't explicitly state that type is its metaclass. Otherwise, you could safely say:

class FooType(Bar.__metaclass__):
	pass

Such things are to be looked for in Python 3. I find that the Python developers have either, after considerable review and debate, already accepted or rejected most of my ideas before I even consider them, so I'm not even going to check for a PEP on this one.

this entry was posted on Tue, 30 Sep 2008 at 22:45 in program/python

Properties - The Python Saga - Part 3

Properties come out of a tired programming language genesis. In the beginning, there were structs. The trouble with structs was that an opaque data structure could not programmatically monitor or intercept access and mutation of its member data.

So that's not a big deal; we could solve the problem with classes. The best practice to avoid programming yourself into a corner was to never expose a datum; you would write accessor and mutator functions, whether you needed them at the moment or not. Thus, as your design grew, you could eventually do nice things like validation, observation, or proxying. The trouble with this approach was that you had to write six times as much code on the off chance you'd need to extend it some day. But it was worth it.

The idea of managed properties came along eventually in various languages (Python, C#, some implementations of JavaScript, and recent versions of [C]). The notion is that you would initially write all of your classes like structs with member data camped in public view. You would encourage your API consumers to interact with those members directly. Then, as need arose, you would subvert the member variables with property objects. These objects would intercept accesses and mutations with functions that you could write at any time of your design process.

Lets observe this design shift in Python. Here's a class with unmanaged data:

class Foo(object):
	def __init__(self);
		self.bar = 10

Here's some other fellow's code that uses your class:

foo = Foo()
foo.bar = 20
print foo.bar
del foo.bar

So there you have it. Just to keep on the same page, the idea at this point is to add a feature to Python that permits both of those code samples to work and, in-fact, be perfectly cromulent. However, we also want to eventually add features to Foo such that its bar attribute can be managed, validated, proxied, secured, or outright lied about. Enter property. property is a function that accepts an accessor function and optional mutator and deleter functions. The property must be a class attribute to work. Here's how you would use a property:

class Foo(object):
	def __init__(self):
		self.bar = 10
	def get_bar(self, objekt, klass):
		return self.baz / 2
	def set_bar(self, objekt, value):
		self.baz = value * 2
	def del_bar(self, objekt):
		del self.baz
	bar = property(get_bar, set_bar, del_bar)

Now we have a Foo class that transparently maintains the invariant that "bar" will always be half of "baz".

Sometimes you don't need to have a setter for a property, and you almost never need a deleter. For the common case, you can use the property function as a decorator.

class Foo(object):
	def __init__(self):
		self.baz = 20
	@property
	def bar(self):
		return self.baz / 2

Creating the property function.

So, it's easy to assume that the property function does all the magic behind the scenes, setting up traps in your class's accessor and mutator paths. There's actually another layer of code that can be done entirely in Python. That is, we can implement the property function in pure Python. The trick is that the property function is actually a type or factory method (who cares which) that returns a Python duck-type: a property object. A property object is any object that implements __get__, __set__, or __del__. These are special magic Python functions that intercept access, mutation, and deletion on members. All you have to do is install an object on a class with one of methods defined, with the name of the member you want to manage. The property function just handles the common cases. Let's redefine the property function in Python, as the Property class.

class Property(object):
	def __init__(self, fget):
		self.fget = fget
	def __get__(self, objekt, klass):
		return self.fget(objekt)

This defines enough of the Property object to decorate an accessor function.

class Foo(object):
	def __init__(self):
		self.baz = 20
	@Property
	def bar(self):
		return self.baz / 2

Here's a full implementation of Property. You will note that, in order to exactly emulate the property object, the __init__ method has the same argument names as the internal property so that code that uses keyword arguments will function in perfect ambivalence.

class Property(object):
	def __init__(
		self,
		fget,
		fset = None,
		fdel = None,
		doc = None,
	):
		self.fget = fget
		self.fset = fset
		self.fdel = fdel
		self.__doc__ = doc
	def __get__(self, objekt, klass):
		return self.fget(objekt)
	def __set__(self, objekt, value):
		self.fset(objekt, value)
	def __del__(self, objekt):
		self.fdel(objekt)

this entry was posted on Mon, 29 Sep 2008 at 23:34 in program/python

Migrating to Blogger

Heij, folks. I'm migrating my blog from my homegrown PyBlosxom solution to Blogger. I will continue cross posting here, but if you would like to make comments, please visit my new location, http://askawizard.blogspot.com/.

this entry was posted on Mon, 29 Sep 2008 at 12:01 in

Decorators - The Python Saga - Part 2

Python introduced a short-hand for the adapter pattern on functions. You can "decorate" a function with another function. This is a neat tool you can use to factor out some common code from a bunch of functions. You can fiddle with the arguments, return values, or intercept exceptions thrown by any function you decorate.

The canonical example is a memoize decorator. The idea is to generalize the notion of memoization so you can simply subscribe to it in any function you want to memoize.

def factorial(n):
	if n == 1: return 1
	return n * factorial(n - 1)
factorial = memoize(factorial)

You accomplish this by writing the memoize decorator. A decorator is a function that accepts a function and returns another. Python virtuously provides a shorthand for taking the function, decorating it, and assigning it to a variable with the same name.

@memoize
def factorial(n):
	if n == 1: return 1
	return n * factorial(n - 1)

In the imagined normal case of decorators, the returned function accepts the same arguments and returns the same kinds of values as the accepted function. However, a decorator does have the liberty of extending or restricting that interface, like accepting additional arguments or raising an exception if the arguments are of the wrong type. It might also perform some common computation on the original arguments and pass the result to the original function as an additional argument. In any case, you can use some closures to create a decorator:

def memoize(function):
	cache = {}
	def decorated(*args):
		if args not in cache:
			cache[args] = function(*args)
		return cache[args]
	return decorated

Of course, that's too simple. A lot of things you put after the "@" symbol are just functions that return decorators so that they can be configured with arguments. For example, you probably want to make a memoize decorator that lets you specify your own cache object. So, you need another layer of deference.

def memoize(cache = None):
	if cache is None: cache = {}
	def decorator(function):
		def decorated(*args):
			if args not in cache:
				cache[args] = function(*args)
			return cache[args]
		return decorated
	return decorator

@memoize({})
def factorial(n):
	if n == 1: return 1
	return n * factorial(n - 1)

Since, in Python, functions, objects, and types are indistinguishable to the casual observer, you can do the exact same thing with a class, although I shudder to think that you might want to forgo the simplicity and elegance of closures. After the transform, the previous code might look like this:

class memoize(object):
	def __init__(self, cache = None):
		self.cache = cache
	def __call__(self, function):
		return Memoized(function, self.cache)

class Memoized(object):
	def __init__(self, function, cache = None):
		if cache is None: cache = {}
		self.function = function
		self.cache = cache
	def __call__(self, *args):
		if args not in self.cache:
			self.cache[args] = self.function(*args)
		return self.cache[args]

@memoize()
def factorial(n):
	if n == 1: return 1
	return n * factorial(n - 1)

So now you can use a Least Recently Used Cache, assuming it is a dictionary-like-object (a duck-dict, if you will):

from lru_cache import LruCache
@memoize(LruCache(max_size = 100, cull = .25))
def factorial(n):
	if n == 1: return 1
	return n * factorial(n - 1)

Download decorators.zip.

this entry was posted on Sun, 28 Sep 2008 at 21:42 in program/python

Variadic Positional and Keyword Arguments - The Python Saga - Part 1

Python supports "variadic" arguments. Variadic arguments are the man behind the curtain for C's printf function. The idea is that a function can accept a variable number of positional arguments, the values to put in your format string. In C this is accomplished with an ellipsis, ..., and some VA macro-linked-list-stuff that I always have to look up. Python goes a couple steps further with variadic arguments and the results are stunning, orthogonal, and actually useful almost every day. With Python, you get both "positional" arguments, like C, and keyword arguments: those arguments that conceptually map, in any order, to the names of the arguments in your function's declaration. The magic symbols are "*" and "**" for positional and keyword arguments respectively. With one "*", you can declare a function that accepts any number of arguments as the declared list object:

def foo(*args):
	return args
assert foo(1, 2, 3) == [1, 2, 3]

You can also pass an array of positional arguments to a function with very similar syntax:

def foo(a, b, c):
	return [a, b, c]
assert foo(*[1, 2, 3]) == [1, 2, 3]

And you can do the same thing with keyword arguments except you use dictionaries:

def foo(**kwargs):
	return kwargs
assert foo(a = 10, b = 20, c = 30) == {'a': 10, 'b': 20, 'c': 30}

Likewise, you can pass keyword arguments:

def foo(a, b, c):
	return [a, b, c]
assert foo(**{'a': 10, 'b': 20, 'c': 30}) == [10, 20, 30]

You can use them in combination, along with default arguments to provide beautiful, orthogonal, reusable abstractions:

def foo(a, b = None, c = None, d = None):
	return [a, b, c, d]
assert foo(*[1, 2], **{'c': 3}) == [1, 2, 3, None]
def bar(a, b, c, *args, **kws):
	return [a, b, c], args, kws
assert bar(1, 2, 3, 4, 5, f = 6) == ([1, 2, 3], [4], {'f': 5})

this entry was posted on Sun, 28 Sep 2008 at 00:09 in program/python

It Shtarts with a Bloody Esh.

The light saber application for the iPhone was recently "upgraded" to a naggy advertisement application for a game that I will not give the benefit of calling out by name. If, like me, you need to "downgrade" your iPhone application, fear not, there is a way.

If you upgraded the application directly on the phone, the old version may be backed up on your main iTunes library. If you have docked since you got the application originally, and have not docked since you upgraded, just delete the application from your phone then dock and sync. The old version will be restored.

If you have already docked and synced your iPhone with your iTunes library, it will appear that the new application is both on your phone and your computer with no sign of the old one. Check the trash—it might still be there. Copy the .ipa (iPone App) file for your application to your iTunes/Mobile Applications directory and open it in iTunes. It will prompt you for whether you would like to replace the newer version. Just say, "YES!".

this entry was posted on Sat, 27 Sep 2008 at 11:37 in

JavaScript Module Standard

The purpose of this document is to propose a contract between a collection of JavaScript module loaders and modules. The specification describes the environment that module loader implementations provide, and the environment that modules may depend upon. In particular, compliant module systems:

• map one file to one module (while leaving room for implementation-specific multi-module bundling for website performance),
• cache singleton module objects before executing the corresponding module file,
• execute modules with a feature-rich context,
• resolve module URLs relative to a module path, and
• conform to a domain-name-based site-package naming convention and leave a name-space for a centrally managed standard library.

The specification is intended to be suitable for client- and server-side JavaScript module loader implementations.

The specification is intended to provide insights and an easy migration path to future versions of JavaScript.

The specification is intended to narrow the domain in which JavaScript modules can universally depend to maximize portability.

The specification encourages modules to adhere to a strict subset of the JavaScript environment in which they may be loaded. In spirit, this is a theoretical version of the JavaScript language that provides the intersection of behaviors provided by Class-A browsers and server-side run-times including Rhino, plus this system for loading modules.

Module Execution Context

The singleton module object MUST be declared and cached BEFORE the corresponding module file is executed. The module file MUST only be executed ONCE for the duration of a page-view or JavaScript program.

In a module file's execution context, the context object, represented by this, MUST be the module object.

The scope chain, from global to local, of a module file's execution context MUST consist of:

• builtins
• moduleScope
• module
• <anonymous>

builtins

Rules for module systems:

• The builtins object MAY be frozen.
• All objects in the transitive closure of builtins on item selection MAY be frozen.
• The builtins object MAY contain more values than specified.
• The builtins object MUST include:
• String
• Number
• Boolean
• Object
• Array
• Date
• RegExp
• Error
• EvalError
• RangeError
• ReferenceError
• SyntaxError
• TypeError
• The module loader MAY enforce these invariants at any time. In some environments, verifying these invariants will not be possible or pragmatic.
• All objects in builtins MUST conform to the JavaScript subset described in the introduction: one that consists of the intersection of behaviors of the respective objects in all Grade-A browsers and server-side JavaScript environments.

Rules for modules:

• Modules MUST NOT write items to the builtins object.
• Modules MUST NOT modify any object in the transitive closure through references on the builtins object.
• Modules MUST NOT access any items in the builtins object not herein specified.
• Modules MUST NOT use non-standard features provided by builtins.

moduleScope

The moduleScope is a module's private name-space for module loader functions and imported values.

The moduleScope MUST provide:

• builtins
• module
• moduleUrl
• moduleRootUrl
• require
• include
• foreignModuleBind
• log

The moduleScope MAY provide:

• register
• publish

Modules MAY augment the moduleScope with additional items.

Modules MUST NOT overwrite the items specified here.

Module Loading

require(<moduleUrl>, [<structure>])

The require function returns an object with items from a foreign module. The required module is referenced with a URL. By default, all items from the foreign module are copied into the returned object. The returned object MAY be frozen. Modules MUST NOT modify the returned object. If a structure is provided, a subset of the items from the foreign module will be returned, the result of destructure(<module>, <structure>). If a function in the foreign module was declared with the foreignModuleBind decorator, the corresponding item in the returned object is the result of <foreignModule>.moduleScope.moduleBind(<name>, <value>).

If the URL begins with a dot, ("."), the fully qualified URL for the requested module is resolved relative to the fully qualified URL of the current module. This would be the result of urlJoin(moduleRootUrl, moduleUrl, foreignModuleUrl). Otherwise the fully qualified URL is urlJoin(moduleRootUrl, foreignModuleUrl).

Regarding module file names:

• Directory components and file names in modules MUST be in camelCase.
• Modules MUST have a ".js" extension if they are provided by files.
• Modules MUST not have an extension if they are provided by the module loader but are not backed by real files. This might include a "window" module in a particular browser implementation.
• The module root is reserved for a cross-browser JavaScript standard library.
• Modules provided by entities other than the standard library MUST exist in a subdirectory of the module root corresponding to a domain name controlled by the author, or a subdirectory thereof.

Module authors are encouraged to use module relative URLs to increase the mobility of entire directory trees of modules.

include(<moduleUrl>, [<structure>])

The include function defers to require, both its arguments and its return value. However, include also copies all of the items from the object returned by require to the moduleScope object.

foreignModuleBind(<function>)

A function decorator that denotes that the module loader guarantees that, when the decorated function is called, it will receive the module object for the module file in which it was called as its context object: this. foreignModuleBind MAY return the same Function it was passed. The returned function MUST be usable in the module in which it was declared as if it were the function passed to foreingModuleBind. foreignModuleBind MAY modify properties of the given Function.

For example:

this.foo = foreignModuleBind(function () {
	log("foo called from: " + this.moduleScope.moduleUrl);
});

destructure(<object>, <structure>)

For the purpose of this specification, the "destructure" function has the following semantics. If the structure is an Array, the returned Object contains the items from the given <object> corresponding to the keys provided in the given Array structure. If the structure is an Object, the returned object contains items where each key corresponds to a value in the structure, and the value is a value from the object corresponding to the key in the structure. For example:

• destructure({"a": 10, "b": 20}, ["a"]) == {"a": 10}
• destructure({"a": 10, "b": 20}, {"a": "A"}) == {"A": 10}

module

The module object is a module's public interface. Adding items to the module object makes them available for export to other module scopes. To that end, the module object is mutable. The module object MUST provide a moduleScope. Modules MAY augment the module object.

moduleRootUrl

moduleRootUrl is the fully qualified URL of the JavaScript site-packages directory: the module root.

moduleUrl

moduleUrl is the relative URL of the current module file relative to moduleRootUrl.

log(<message>, [<label>])

log is a simple console logging function.

The module loader MAY ignore calls to log. The module loader MAY ignore the label argument.

The optional label MAY be any string, and MUST be suitable for use as a CSS class-name (preferably lower-case delimited by hyphens) of which the following MAY be significant:

• info
• warn
• error
• module
• help
• pass
• fail

Afterword: Browser Implementations

This specification outlines the process of requiring modules from within other modules. However, in a browser's global context, JavaScript execution blocks are not modules. To that end, this specification does not require that the module loader be invoked in any particular fashion. A particular implementation might hook an initial module to be loaded from within a script tag. Another implementation might scan the DOM for script tags with an alternate language attribute and execute them as modules with the current page's URL as their module URL.

Afterword: Future ECMAScript import semantics.

A future version of the ECMAScript standard might specify new syntax and semantics for importing modules. Current discussions about this feature trend toward having new syntax that "desugars" to native JavaScript. To that end, I propose the following syntax and desugaring transformations in the context of this specification:

• import "<moduleUrl>" as <moduleName>;
• module.<moduleName> = require("<moduleUrl>");

• from "<moduleUrl>" import *;
• include("<moduleUrl>");

• from "<moduleUrl>" import <a>;
• include("<moduleUrl>", ["<a>"]);

• from "<moduleUrl>" import <a> as <a'>;
• include("<moduleUrl>", {"<a>": "<a'>"});

this entry was posted on Thu, 04 Sep 2008 at 03:28 in program/javascript

Tale Update

I'm not exactly on schedule for Tale (I intended to have a playable alpha this month), but here's your consolation prize: art updates.

I recently added Fire Drakes and ducks to the Tale managerie. You'll encounter varous breeds of Fire Drake Elementals and Alloyals throughout the eastern face of the world, Oria. The brave and, more importantly, resilient will eventually encounter FrancisDrake, the drake leader.

Additionally, those daring to travel south to Austra will eventually encounter first patrols, squadrons, platoons, companies, battalions, regiments, brigades, divisions, corps, and eventually hordes of penguins. The penguin collective recently added an air-force to their numbers with propellor-beanie sporting aerial grenadier penguins, Aero-pengins, and ballistic-missile ground forces, Rocket-penguins.

The penguins appear to be gearing up for war with Borea, however, the red mage of the North will not be caught with his snow-pants down. The elves have recruited the not-so-friendly poler-bears to introduce penguin to their rich baby-seal diet. The narwhal claims neutrality and you're not likely to find him unless you dive in the frigid Boreal Sea.

Plans are under-way to populate all of the evil faces of the world with popular open-source mascots. You can expect to see the BSD Daemon in the hell-world of Dysia, and maybe even Fire-foxen in Oria. Drop me a line if you think of an appropriate mascot for the /East, perhaps involving fire or ducks, especially if it continues the theme of rougue operating systems.

On a completely different topic, there is new art for Tale accessories including a morning-star, the brick-of-power, and the iTome for manic fighters. These items will be available on the ever-popular face 5, Occia.

That gives me a good an idea. Perhaps there should be an operating system for every face! Faces 6, 5, and 4 (good) would be commercial operating systems while faces 1, 2, 3 (evil) would be open-source. Face 6 will obviously be blighted with drafts; does anybody have an idea for Borea, the north pole?

Also, there's a new item for your initial inventory when you start the game in Euia, a spork.

this entry was posted on Sat, 02 Aug 2008 at 21:06 in art/tale

Got Style?

There's a new JavaScript library from Google on the block. So, I'm of course out to absorb the good bits for Chiron. I've got to wonder some times whether people have started to use ideas from my code.

Compare this bit from Google's JavaScript library with this one in Chiron.

I don't hear much about people using Chiron. Could this be a sign that people have been reading it and absorbing the good bits? There are other parallels. For example, some of the function names and file names match up with Chiron too, like base.js and inherits (instead of Doug Crockford's recommended term, begets).

this entry was posted on Wed, 14 May 2008 at 16:48 in program/javascript/chiron

Re: Recommendations for the Fourth Edition of the ECMAScript Programming Language Specification

Doug Crockford has posted some recommendations to improve JavaScript.

I have some comments in the context of my experience with live-patching JavaScript issues with libraries.

New Features

Function Reflection

Doug recommends that function objects contain a "name" property. Some versions of JavaScript actually have this already. This could be handy but I haven't needed this and would not be likely to use it. I was surprised that FireFox had this when I used a Function in a with block. I've learned my lesson.

However, Doug also recommends the addition of an arguments member to Function objects. This is a critical feature. The arguments array would contain the names of all of the functions declared argument variables. Function objects already have a length member that corresponds to the length of this hypothetical arguments array. There was some buzz about using this value for method overloading and it permitted me to create an elegant partial application decorator. If we had access to the names of a function's argument declarations, I could implement a decorator for supporting Python-style positional and named arguments. Decorated functions would accept an array/list of positional arguments and an object/dict/map of keyword arguments and the decorator would translate them to an array for a wrapped Function.apply. That decorator or further decorators could support default values and automatic argument length assertions.

typeOf

Doug notes that JavaScript's typeof "function" is broken because it returns the wrong strings for null and arrays. All that and he hints that using camelCase instead of lowercase would have been more in keeping with the language's aesthetic. He recommends that we deprecate typeof and replace it with a fixed version called typeOf. I would go a step further. typeof returns a string. I propose that it ought to return the type object. This would jive well with instanceof, instanceOf, or isInstance. This means there should be a Null type that would construct null and an Undefined type to construct undefined.

Object Methods

Don't Enum

I don' particularly care whether Object has a dontEnum method since I don't augment base types and wrap them when I need reliable collection types, but this would help ameliorate integration woes with prototype so it's a good idea.

Array of Keys

Doug wants a Object.arrayOfKeys method. I want a keys method that returns a Set. I would also like keysIter and, less emphatically, keysArray. I don't want the name arrayOfKeys because it introduces an unnecessary Of and doesn't sort as well as keys*.

Array of Values.

Doug also wants Object.arrayOfValues. I want values and valuesIter. These should return Array and Iter object respectively.

toJsonString

Object.toJSONString(memberName). The first thing that comes to mind to improve this idea is to rename it toJsonString; I prefer to consider acronyms words and I would have also called XMLHttpRequest XmlHttpRequest. This name jives well with toString, but I would have called that string. But, I actually would call this repr and made it a global function. repr would work on arbitrary objects, a subset of which would be serializable JSON. The behavior of repr would be overridable by providing a repr method on an object.

Beget Object

Doug recommends that Prototype inheritance be a little more lucid by providing a beget function that returns a new, empty Object that inherits from the previous. I like this idea. I called it inherit in Chiron.

isEmpty

isEmpty would return whether an object has any properties, other than those inherited. Sounds fine to me, although I probably would have just used number and boolean casting. This is a good idea too though, because in JavaScript, it's hard to distinguish an Object that is being used as the base of the inheritance tree and an Object that is being used as a hash-map. To that end, I recommend the addition of a Map type. Map would have isEmpty, number, and boolean functions and would implicitly cast to Number and Boolean based on their length that would be reflected publically by the getLength function.

Array Methods

Doug recommends the addition of some of Mozilla's JavaScript 1.6 Array methods. I support all of them. However, some nomenclature refinements and specifications:

indexOf should be augmented by a find function that throws a KeyError instead of returning a negative index.

lastIndexOf should be augmented by a findLast function similar to find.

every should be called all. This function should accept an iterator or iterable and short circuit on the first failure.

filter should be called where. Filtering implies the opposite of finding. To filter something is to remove it from a stream if it passes a particular condition. where implies that the outgoing stream should contain only those elements from the original stream that affirm the guard.

forEach is good as is. I would like to specify that it should return this so that forEach calls can be chained. This has implications on iterations that are partially consumed by a forEach call that throws a StopIteration exception in its continuation.

map is good as is. As a member of an array, each should be a synonym. These functions should also be declared in global scope with opposite argument order: map(function, collection, [context]) vs each(collection, function, [context]).

some should be called any. This function should accept an iterator or iterable and short circuit on the first success.

String Methods

trim is good as is. There should also be trimBegin and trimEnd or trimFirst and trimLast.

string.eval is a good idea, but I've got my own ways to launder the scope chain for eval.

Date Methods

Date.toJSONString and Date.toISOString are both great ideas; not having them has been a problem for me in the past. I recommend calling them toJsonString and toIsoString.

Corrections

Reserved Words

Doug argues that identifiers in object literal notation and member dot notation should allow reserved words. I concur. It's a small syntax shortcut that identifiers used in member selection and object literal notation are not required to be enquoted; the language should be equally permissive for both syntax forms.

Doug also argues that the list of reserved words is too long. I have mixed feelings. On one hand, having a long list of reserved identifiers leaves open the door for future advances in the language (some of which include type annotations, which I find dubious). On the other hand, they muddy the name space for current code. On the latter note, it's important that all browsers are equally strict. Safari, at the moment, is much more strict than other browsers, so I've been surprised.

Object Literal Notation

I agree that commas should be more regular throughout the language. They should be permitted after any value, including the last in an Object or Array literal without affecting the length of either.

arguments

arguments should definitely be an instance of an Arguments type that inherits from Array.

Inner Functions and the Context Object (this)

I agree that this should not be the global object (window) in inner or anonymous functions. this should be acquired from the scope chain in such closures. Doug claims that this is not the standard. I recall being corrected on this point, but I also recall having been under the same impression. I leave this as an exercise to the reader to determine the current state of affairs in various browsers.

Tail Recursion

Tail recursion would be nice.

Deprecation

Primitive wrappers should be eliminated. Boxing is almost never necessary. In fact, the use of the new keyword could be completely obviated and code would become much more reusable since there would be no distinction between a factory method and an object constructor.

I actually use the with statement in a couple cases that are really important. I don't recommend using it for its designed purpose, but I really do need it to stay in the language for my module system and my JavaScript shell to keep working. FireBug, in particular, depends on this feature.

Semicolon insertion was silly. Off with its head.

I don't particularly care about arguments.callee.

typeof has to go.

Again, eval is a necessary part of my perverse world. I can do my own laundry. There are, however, irresponsible uses of eval that I do not condone.

this entry was posted on Thu, 24 Apr 2008 at 18:40 in program/javascript

De Schpugeti

You've heard of syntactic sugar. After a syntax and vocabulary provides all of the normal forms necessary to express all of the programs possible in a language, yummy shortcuts bridge the gap between expressiveness and usability. For example, c++ is a delicious variation of (temp = c, c = c + 1, temp).

You've also heard of CRUD, an acronym for the normal forms for a data programming interface (databases, data structures). If you design an interface library for data and fail to cover all of these bases, you deserve what's coming to you — and I can't promise that it won't involve a big hole in the ground and Hello Kitty.

CRUD stands for create, read, update, and delete. Those functions encompass all of the necessary data interactions; however, they are not sufficient. While CRUD may provide all the nutrients, vitamins, and minerals your data API might need, it certainly won't taste good without sugar.

Enter: Chiron.

del, set, cut, has, put, get. De Schpugeti. All of these names are three letters long, should be familiar by their names, and are sufficient in addition to necessary. These methods are the interface of Chiron's Dict, for manipulating item data: data that have keys and corresponding values. They are also implemented in a consistent manner by List presuming that indices are like keys.

del

Deletes an item for a key.
Returns the mutated collection.
For ordered collections, accepts a beginning key and an ending key, deleting all items in that range of keys excluding the ending key.
Implemented in terms of remove.

set

Adds or overwrites an item for a key.
Returns the mutated collection.
Implemented in terms of insert.

cut

Deletes an item for a key.
Throws a key error of no item has that key.
Returns the corresponding value.
Implemented in terms of get and del.

has

Returns whether key is among items.
Implemented in terms of has.

put

Adds an item for a key.
Throws a key error if there is already an item with that key. returns the mutated collection.
In an ordered collection, reserves the right to change the keys of some other items to make room for the new item.
Implemented in terms of set and has.

get

Returns a value for the given key.
Throws a key error if there is no value for the given key.
Implemented in terms of retrieve and has.

Also, Lists, Sets, and, by extension, Dicts have functions for managing collections of values that do not have keys. Dict is a Set of items instead of mere values that are compared and hashed on their key.

has

Returns whether a collection contains a particular value.

insert

Adds or overwrites a value.
Returns the mutated collection.
Defaults to an implementation in terms of find and set.

retrieve

Returns the contained value that is naturally equivalent to a given value.
Throws a value error if none exists.
Defaults to an implementation in terms of find and get.

remove

Removes a value.
Throws a value error if the value isn't in the collection.
Returns the mutated collection.
Defaults to an implementation in terms of find and del.

discard

Removes a value if it exists.
Returns the mutated collection.
Implemented in terms of has and remove.

find

Returns the key for a given value.
Accepts an optional equivalence relation to override the default of eq.

Now accepting ideas for a good mnemonic.

The fun trick is that List, Dict, and Set implement all of these functions. While it may be more appropriate to use one collection type for one kind of data or one algorithm, you can use any of these types interchangeably.

this entry was posted on Mon, 24 Mar 2008 at 17:51 in program/javascript/chiron

Caption Contest

I found this gem around to corner from my current workplace:

Please send me your submissions.

(I say current because we're (FastSoft) moving to Padadena at the end of this month.)

this entry was posted on Thu, 20 Mar 2008 at 16:00 in photo

Unicode

What I've learned today—

In order for a program or library to operate in a Unicode compatible fashion, all strings must be in Unicode. All input strings must be brought into Unicode, and all output strings must be sent out of Unicode at the very last possible moment. This is because, outside of Unicode strings, encoding is not a function of type and type information does not generally cross API boundaries accurately, plus regular expressions don't play well against mixed-length characters.

Django works entirely in Unicode and drops a string to UTF-8 at the last moment. I had need for Python's Textile library to transform text, but it only dealt with byte strings. Anyhow, It turned out to be quick work to change all of its strings to unicode and not bother with encoding and decoding.

this entry was posted on Thu, 21 Feb 2008 at 20:10 in program

Integrating Simile

Not to name names, but I've been working on integrating code from Simile from MIT into Chiron. Refactoring an existing JavaScript project highlights all the things you get for free in Chiron.

Simile has it's own XHR engine, DOM event wrappers, DOM layout and style functions, PNG transparency solution, and a SortedArray type that provides binary search functions. Here are some of my observations.

• Simile's layout getSize was better than mine. I will rectify this.
• Not having a module system makes us reinvent the wheel: frequently.
• It's hard to write a good XHR engine. There are a lot of XHR modules out there, most of them have some issue or another: missing browser, doesn't report OK status on local files, doesn't unify browser caching inconsistencies, doesn't support timeouts, doesn't expose XML (the X in AJAX) in IE, or so on. If you're going to make a new one, you should use these as references and do some serious research, development, and testing. Otherwise, you should copy or use the best of them (jQuery, in my opinion). Also, it needs to support asynchronous (the A in AJAX) requests, and you need to use them as often as possible.
• Not having a solid, modular library makes us lazy. The inconvenience of name-spacing makes us lazy. This causes us to write sloppy code. For example, we should always use an enquote function when we're string interpolating HTML attributes and an inoculate function when we're interpolating HTML, or we should use DOM functions or a DOM wrapper API to generate our HTML.
• As I integrate code from other libraries, a pattern emerges. In my first pass, I collapse the name-spaces. Every module is a name-space, so all the manual creating of hierarchies like Simile.DOM (Simile = {} presumed, then Simile.DOM = {}, then endless repetition of Simile.DOM to augment or use its contents) is unnecessary and undesirable.

Referencing URL's of resources, like other scripts and images, relative to the URL of the script you're currently in, is hard. Starting from scratch, this usually means you're going to have a global URL constant. This means domain-coupling. Maybe you make the URL relative to the root. This means domain-coupling. Maybe you provide it as a configuration variable. This means site-coupling. Maybe you scrape the script tags on the page for the URL of your script then resolve the URL relative to your own URL. This means you're going to write a lot of slow code for what you perceive to be little value. In Chiron, you can get a function called resolve from http.js that resolves a URL relative to a base URL. Chiron also provides your modules with a moduleUrl variable that is the URL of the script you're in. resolve also implicitly uses this variable as your base URL if you don't provide a second argument(include('http.js'); resolve('images/blah.gif')).

Chiron grabs the script tag href of modules.js and removes the script object from the DOM (so other scripts can't sniff it) exactly once, since it needs that URL to resolve other module URL's. From there, Chiron keeps track of where all of your modules are relative to it and provides that information to each module.

• About SortedArray:
• A collection type should create an empty instance if you pass no arguments in.
• A collection type should populate itself from the values of another collection if you pass one in as its first argument. This should always be the first argument, even if you frequently create empty collections with overrides on later arguments. Force your user to pass in a null or undefined.
• Try to accept null and undefined as equivalent unless the distinction is meaningful.
• Try to distinguish null and undefined from 0 in all meaningful cases.
• Invariants like "sorted" are a promise. Guarantee your invariants across all function calls, including construction. If this means an unacceptable performance degradation, permit the user to suppress whatever code you need to verify the invariant if they are willing to provide treated data.
• If there is a reasonable default, it should always be implicit. I should not have to explicitly send the global compare function into a SortedArray if I want a SortedArray of types supported by compare.
• Not having a system of base types makes for noisy API's where names from different organizations have different meanings. For example, find functions should always accept the same kinds of arguments and return the same kinds of values. Simile's name choices are very close to mine, to the effect that they could almost be used as partially implemented duck types for mine, but some of the names would have to be realigned. find in Simile accepts a comparator and returns an acceptable index to insert or remove a particular element. find in Chiron returns an index or key at which an item can be inserted or removed, and guarantees that it will be the first occurrence of a given value (not a comparator). It was very easy to refactor SortedArray to subscribe to the strict model. Also, removeAll needed to be clear, length and getCount both needed to be getLength, getIterator needed to be iter, next needed to throw StopIteration once in a while, among others.

I'm looking forward to having a semblance of Simile Timeplot and Timechart in the Chiron family.

this entry was posted on Tue, 19 Feb 2008 at 01:39 in program/javascript/chiron

Polymorphic repr

I'm not about to debate whether debugging is a valuable exercise in JavaScript, nor whether introspection or reflection tools are useful, nor whether they would be especially helpful in a dynamic language. Ruby has inspect. Python has repr. The Chiron JavaScript library has repr too.

Notionally, repr is the inverse of eval for a reasonable subset of JavaScript. There are a lot of object hierarchies that cannot be reconstructed from a repr serialization, but as a debugging tool, repr is indispensable.

repr is a polymorphic function you can import from base.js. If you pass repr an object that implements a repr member function, repr will defer to your overridable repr. Otherwise, repr returns reasonable defaults for other types. For example, repr provides defaults for Array, Object, String, Number, Boolean, and Date. repr also recursively represents members of arrays and objects, but provides circular reference protection by tracking visited objects in a memo Set.

Chiron's debugger uses repr to convert the value of an expression on the command line to a human-readable string.

j$ 1
1
j$ repr(1)
"1"
j$ "hi"
"hi"
j$ repr("hi")
"\"hi\""
j$ true
true
j$ {a: 10}
{"a": 10}
j$ [1, 2, 3]
[1, 2, 3]
j$ [{a: 10}]
[{"a": 10}]
j$ var a = {}; a.a = a; a
{"a": <cycle>}
j$ type()()
<instance run.html#0 0>
j$ type({'repr': function () {return "x"}})()
x

this entry was posted on Mon, 18 Feb 2008 at 12:19 in program/javascript/chiron

Tale Mailing List

Please subscribe to Tale's mailing list if you are interested in joining the invitation alpha in July or the beta in November.

this entry was posted on Mon, 28 Jan 2008 at 00:26 in tale

Some Handy Commands

I've learned a few handy commands this year, so here's the wealth.

Sets have always been a big hole in my command line toolkit. I've gone to such lengths as to implement commands for basic set intersection and union in Perl or Python. Go no farther! While looking over Lasermacaroni's shoulder about a year ago, I noticed that he used the comm command. comm operates on sorted unique streams of lines and produces a three column output of which elements were in column A only, column B only, or both. Of course, three columns are nearly useless, so you can tell comm to suppress the output of certain columns. Yes, this is stupid, but here's your mnemonic: ask not what columns comm can display for you, rather ask what columns you can suppress from comm. Go!

A & B: comm -12 A B
A & !B: comm -23 A B
!A & B: comm -13 A B
A | B: cat A B | sort | uniq

Of course, I like to use comm like grep or grep -v to find the elements from an input stream that either are or are not in a given file. Mind that your file needs to be sorted and uniqued.

also in A:  ... | sort | uniq | comm -12 - A
not in A:   ... | sort | uniq | comm -23 - A

I've known about the seq command in Linux-land for a while. It creates lists of numbers in a given range.

seq last
seq first last
seq first stride last

For examples:

$ seq 3
1
2
3
$ seq 3 5
3
4
5
$ seq 0 2 4
0
2
4

I was quite disappointed not to find seq on Mac OS X. Turns out the BSD folks have a pretty bad case of NIH. Instead of the seq function, you may, having the good fortune of working around brilliant people every day, notice a friend, coworker, or other friendly mammal use the jot command to produce their streams of numbers.

jot [reps [begin [end [stride]]]]

Here are some occlusive examples:

$ jot 3
1
2
3
$ jot 3 5
5
6
7
% jot 3 0 6
0
3
6
% jot 3 1 1
1
1
1
jot -b+ -s- 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

fin

this entry was posted on Thu, 10 Jan 2008 at 22:57 in program/cli

modules.js

We've posted modulesjs.com this evening to proliferate what could be the most important piece of code I've ever written, modules.js. This JavaScript is the core of my Chiron JavaScript library project for the Tale game user interface, but could stand alone as the core of any number of JavaScript library projects. Every popular JavaScript library could benefit from a module system that handles dependencies and isolates name spaces like Python or Ruby. Read the tutorial and look over the code. Find me on an instant messenger or my face in the big blue box or send me an email and tell me what you think.

Thanks go out to Ryan Witt for managing the server and domain, my sister Kathleen Kowal for the graphic design, Ryan Paul, Ryan Ernst, and Mike Stone for proofreading and particularly to Ryan Paul for letting me expound at him nigh daily for the last decade.

this entry was posted on Thu, 03 Jan 2008 at 15:04 in program/javascript/chiron

New Year's Resolutions

I don't generally make New Years resolutions. But, since I'm a software engineer, and I've got some milestones to plot, I've decided to post a release schedule for my personal software projects. This year, I'm going to release Tale.

This involves continued development on Chiron JavaScript for the front-end, Python on Planes for the back-end, and lots of new musical, graphical, and programmatic content.

I'm of course still looking for volunteers (occasionally paid help, if I must and it's worth it) to develop various parts. Chris Pasillas has been working on composing music for the game; we've got a lot of content and had a meeting [mp3] last week to develop creative direction. However, if someone's equipped to render orchestrated versions of the music from the MIDI's (I've got Jonathan DeKlotz in mind for this, but he's a busy fellow too), that would be a super-awesome contribution. We could also use some help from smart, creative, driven (perhaps by angst, anger, or escapism; whatever works for you) programmers who know or are eager to learn Python to develop the actual game engine logic and "mob procs"; this is a lot of work and the bulk of player experience, but I must admit that I'm only marginally interested in developing this aspect of the game, plus I've got a lot of work ahead of me to re-integrate PoP and Chiron. I've had some help from Scott, and Josh "Jynx" Jenkins to develop the game math, plus some ideas of my own in the works, but someone who can dedicate programming time to make ideas real could have a big impact. There are also a lot of Python and JavaScript mini-projects that I may or may not have time to develop myself with the remaining year of schedule, many of which would be very interesting, like intelligent narrative generation from event description trees, SVG sprite composition and rendering (partially implemented), much more 2d vector art for content, game state logic (making lots of use of Python generators if you want to learn about that), and much more. Most of all, Tale needs volunteers who are willing to give a part of their soul, as I have, to the project. Here's the development schedule.

January 2008
Sun	Mon	Tue	Wed	Thu	Fri	Sat
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31
1	Post Chiron 0.1 (done)
February 2008
Sun	Mon	Tue	Wed	Thu	Fri	Sat
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28
2	Deploy Chiron Website
May 2008
Sun	Mon	Tue	Wed	Thu	Fri	Sat
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31
3	Post Python on Planes 0.1
June 2008
Sun	Mon	Tue	Wed	Thu	Fri	Sat
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30
1	Release Chiron 1.0
1	Begin Tale Invitation Beta
December 2008
Sun	Mon	Tue	Wed	Thu	Fri	Sat
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31
5	Begin Tale Public Beta
January 2009
Sun	Mon	Tue	Wed	Thu	Fri	Sat
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31
1	Deploy Tale 1.0

This year will also mark another major step in the collision of my hobby-life and work-life. I've never mentioned this in my personal blog, but I've been working at Apple for the last year and a half, but I'll be moving on to work for a start-up spun off of a networking lab at Caltech called FastSoft where I will be developing the web user-interface for their Aria, a wide-area network performance optimizer. This means I'll be much busier, and I'll be able to work on open-source projects like Chiron as part of my job.

Looking back at all of my personal projects for the last eight years, a pattern emerges. I want my code to help as many people as possible. As for my motivations, as I realized over lunch with Ryan Witt and Christine Ortega over lunch last week, I'm an artist — I'm performing for an audience and am gratified for appreciation of my creations. I'm a fan of Reusability and Repurposability with big R's. This has implications for the nature of the projects I find interesting. I prefer to write libraries and languages: crystalline, orthogonal, refined, applicable, general, powerful, hosting usefulness through emergent patterns: uses unforeseen. Reusability is also best served by proliferation, and what better way to proliferate a thing by making it valuable and free. This isn't economics where value, cost, supply, and demand have interesting but vague relationships; I mean value as usefulness minus cost. Also, what better way to make a thing valuable than to permit your users to exercise and refine it themselves and give them every reason in the world to share their contributions. On a selfish note, I prefer to write software I can use anywhere, even if I'm working on something proprietary. What I'm getting at here is Open Source, with a free, non-viral license. I've chosen other licenses in the past for various purposes, withholding a piece of value for myself for money or the cause of freedom, but for the raw purposes of Reusability, Repurposability, proliferation, and the advancement of the state of the art, I've chosen to use a permissive, free, non-viral license. So, my contributions to Chiron and PoP, at work and at home, will be available with the MIT license.

Happy New Year; let's make.

this entry was posted on Tue, 01 Jan 2008 at 17:35 in program

Machina ex Deus

Behold!

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

- Lord Vader

this entry was posted on Mon, 18 Jun 2007 at 00:00 in program/tale

Cixar Tale Mailing List

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

this entry was posted on Tue, 12 Jun 2007 at 00:00 in program/tale

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.

this entry was posted on Sun, 13 May 2007 at 00:00 in program/tale

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.

this entry was posted on Sun, 13 May 2007 at 00:00 in program/javascript

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.

this entry was posted on Sat, 12 May 2007 at 00:00 in program/javascript

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.

this entry was posted on Sat, 12 May 2007 at 00:00 in program/javascript