Trusting Functionality

Published
by
Atul
on July 23, 2008
in Coding, Mozilla, Python and Usability
. 4 Comments

One of the major challenges we face with the design of our new linguistic command-line project is that of trust. As Zittrain mentions in The Future of the Internet, this is really the fundamental problem of generative systems, and also their most valuable asset: the ability for a user to run arbitrary code is simultaneously what gives the personal computer its revolutionary power, but it’s also its greatest vulnerability.

At present, because our project is still in the prototyping stage, we’re opting for freedom of expressiveness and experimentation over security. That means that all the various verbs we write, while written in JavaScript, are always executed with Chrome privieges, meaning that they’re capable of doing whatever they want to the end-user’s computer.

So the particular dilemma that needs to be solved here is: how can an end-user trust that a verb won’t do anything harmful to their data or privacy—be it intentional or accidental—while still providing a low barrier of entry for aspiring authors to write and distribute their own verbs?

We’ve considered some technical options so far. One is the idea of “security manifests” that come with verbs, specifying what a verb is capable of doing. For example, the “email” verb mentioned in my last post could specify in a manifest that it needed access to the user’s email service and their current selection. This information could then be presented to a user when they choose to install a verb. At an implementation level, the code could run in a specially-constructed sandbox to ensure that the verb code never steps outside the bounds prescribed by its manifest. Alternatively, or in addition to this, an object-capabilities subset of JavaScript like Caja can be used. Such mechanisms ensure that untrusted code can only go as far as the end-user lets it—which, unfortunately, also puts a burden on said end-user. While I don’t personally mind having such a burden myself, I know I wouldn’t want to put it on my friends and family.

Digital certificates are another component of potential solutions, but they too have their own problems. While they’re easy for centralized corporations to deal with, they’re problematic for more distributed operations, and the monetary cost involved in obtaining one significantly increases the barrier to entry for individual software authors. And even signed code doesn’t prevent the more privacy-invasive—but not outright malicious—classes of software like spyware.

As I’ve indicated earlier, this general issue of trust isn’t a new problem, or even just an important issue for an experimental Firefox addon. It’s what Zittrain believes is at the core of the future of the internet and the PC, and the solutions we create—or don’t create—will determine whether their future is one that is sterile or generative. Windows Vista, being the most frequently exploited operating system as a natural result of its widespread use, is the harbinger of a future that relies entirely on technology and corporate trust heirarchies without taking any kind of social mechanisms into account; the result is a notoriously hard-to-use user interface that places an enormous burden on the end-user to constantly make informed security decisions about their computing experience. I don’t think that the answer is merely a “less extreme” version of Vista—which is the model that most other operating systems and extensible applications seem to be following—but rather that a more effective solution is primarily a social one that is supported by technological tools.

I have a particular solution in mind that I’ll be writing about soon. That said, I’d still love to hear any thoughts that anyone has on this topic.

My First Ambulate-For-a-Cause

Published
by
Atul
on July 21, 2008
in Mozilla and San Francisco
. 0 Comments

Yesterday I participated in the San Francisco AIDS Walk with two Mozilla interns.

I’ve always been a bit puzzled by the concept of walks/runs-for-a-cause because at a surface level, the energy an individual spends running or walking doesn’t directly contribute to the actual cause they’re ambulating for. Ultimately, it seems like it’s a transaction for one’s time and energy in exchange for a cause’s publicity: rather than simply donating a few dollars to a cause, ambulating for the cause is indicative of the sacrifice of one’s time in the name of a cause (which can be more valuable than money, depending on the individual). On the micro level, this can result in additional revenue for the cause as friends and family of the individual pledge money in recognition of that sacrifice. On the macro level, the collective behavior of so many people doing this at once creates significant publicity for the cause, which raises awareness for it and consequently leads to more revenue.

It’s no surprise that corporations have an incentive to ride this wave by “donating” money and human resources in exchange for publicity and associating their brand with the cause in the minds of consumers. For the vast majority of companies that I don’t care about, I tend to perceive this as the coldly calculated move I just described it as: The Gap, Blockbuster, McDonald’s, Williams-Sonoma, Wachovia, and a number of other corporations helped sponsor the event, their employees wearing t-shirts saying things like “[Company Name] Cares!”. Such things elicited a gag response from me. I don’t think that this actually damaged my perception of the companies in question—their behavior is entirely rational and has good consequences—but it doesn’t particularly improve my perception of the companies, either. I’d like to say that this is because I only want to associate qualities like compassion and benevolence with actual human beings that I know personally and trust.

Things aren’t that simple, of course. Pixar was there, and I couldn’t help but cheer them on, as they’re one of the few corporations that I have a particularly positive impression of, and consequently mentally anthropomorphize into an awesome person rather than the usual faceless machination. My two companions were wearing Firefox swag and got a few cheers as well, which was nice.

Still, there was something odd about the whole event. Some American Idol people sang a song at the opening ceremony and some famous people emcee’d it as though they were hosting the Oscars, which added to the uneasy feeling that this was a publicity stunt rather than an authentic experience. In the end, I suppose it was a bit of both, but what made it really worthwhile was exploring Golden Gate Park and hanging out with my fellow Mozillians.

Ubiquitous Interfaces, Ubiquitous Functionality

Published
by
Atul
on July 14, 2008
in Mozilla and Usability
. 11 Comments

Lately some of us at Mozilla Labs have been experimenting with graphical keyboard user interfaces in Firefox. Our current work-in-progress is something that we’re calling Ubiquity for the time being, though the name is by no means set in stone.

This project is heavily informed by Enso, a software product developed by me and my colleagues at Humanized from 2005-07. Aside from the benefits outlined in Alex Faaborg’s blog post entitled The Graphical Keyboard User Interface, this experiment is intended to solve few other problems, one of which I’ll address in this post.

Web applications, much the same as desktop applications, are a bit like isolated cities: it’s difficult for an end-user to arbitrarily share data and functionality between them. This is alleviated to some extent by creations like Firefox Add-ons that add toolbars or sidebars to Firefox’s UI, Bookmarklets, and Greasemonkey, but while all of these solutions are powerful, each comes with its own set of problems. The buttons and bars of many Firefox add-ons don’t scale well because of the valuable screen real-estate they consume; Bookmarklets are restricted in scope because they only have the access privileges of the website they’re running on; and Greasemonkey doesn’t prescribe any kind of interaction model, which makes it difficult to reuse the functionality of a script in a context other than the ones it was expressly designed for.

Our new project attempts to alleviate all of these problems by allowing end-users to apply textual commands, or verbs, to whatever they’re looking at. For instance, let’s assume that I’ve found a typo on a friend’s blog, and I want to let him know about it. I can first select the typo on the page by dragging my mouse over it:

Then, I can activate what we’re calling the “command entry mode”. At the moment, this is done via a hotkey that displays a popup window, though this particular interface is only temporary (more on that later):

Now I type “highlight”, because that’s what I want to do to the typo, to emphasize the location of the typo to my friend:

I then press enter, which highlights the text, like so:

Now I’d like to email part of the sentence containing the highlighted typo to my friend, so that he has some context for where the typo is located. I do this by highlighting part of the sentence, and issuing the “email” command. This causes Firefox to switch to my Gmail tab and compose an email for me with some pre-filled content:

I can now modify the email as necessary to tell my friend about his typo, and then send it.

Our current code is capable of performing this workflow, though Gmail is the only supported mail application at the moment. The hotkey interface is also something of a placeholder, because it was the most expedient to implement while making the project dogfoodable. Ultimately, it would be ideal for verbs to be exposed to end-users through interfaces that already exist in Firefox, such as the AwesomeBar or contextual menus.

Exactly what the user needs to type in order to invoke a command is also under contention, and Jono has been doing some really interesting work on this front. There’s a number of additional aspects of the experiment that I’d like to write about, so keep reading Toolness for more updates.

We’re currently sprinting to have something more presentable by the Firefox Summit—hopefully a 0.1 release, if all goes well. In the meantime, if you’re interested, feel free to join the Google Group, and even check out the source code.

The Future of the Internet, How to Stop It, and Me

Published
by
Atul
on July 11, 2008
in Coding and Mozilla
. 3 Comments

A few weeks ago, Oxford University professor Jonathan Zittrain recommended Firefox 3 on The Colbert Report. While getting the bump for the browser from this great show was certainly a win for Mozilla, more provocative was the new book Zittrain was discussing with Colbert, entitled The Future of the Internet and How to Stop It.

Contrary to the Luddism I’d assumed the book’s title implied—e.g., that the Internet is a terrible thing and needs to be dismantled—Zittrain instead celebrates how open and positive the Internet and personal computing have been for us, but warns that this liberating period is in danger of coming to a close.

I can certainly agree with the first part: as far as technology goes, it seems to me like we’re living in something of a golden age of computing. Participatory, user-generated content is ubiquitous. An organic, community-authored browser has been declared the best way to experience the web, and a vast number of people rely on a surprisingly balanced community-maintained encyclopedia as a major source of information about their world. Individuals who want to learn about programming and create solutions to help or entertain others can do so on an open web, using free tools that they can take apart, modify, and remix as they please, without needing much more than an Internet connection and a computer. Extremely low-cost computers and network infrastructures are being created for those with lower incomes, thereby helping create a more level playing field for children.

This is an improved version of the world that I grew up in, where my first computer, an Atari 400, was like a blank slate waiting to be experimented with. But what drew me most to this particular kind of tinkering—as opposed to, say, electronics, a field which I still know next to nothing about—is that both experimentation and the sharing of one’s creations had negligible costs associated with them. After one had a computer and perhaps some instructional materials, inventing things with it involved spending no money on supplies, since the computer came with its own version of BASIC. There was no “gatekeeper” preventing you from distributing your software to as many people as you wanted, either by printing out your source code, or putting your program on a disk, or uploading it to a BBS.

Growing up in a freedom-infused computing environment like this, it was no surprise that I was a bit puzzled when I ran into things that had computers inside but didn’t let me tinker with them and share my solutions with others. Cell phones are the most obvious example of this; when I bought my first in 2001, while I understood some of the motivations behind my phone carrier and manufacturer “locking me out” from being able to tinker with my phone, I was nonetheless disappointed.

It’s the distinction between these two philosophies of information devices that Zittrain is concerned with. The personal computer and the Internet are generative tools that invite their users to discover new uses for them, providing the freedom to create and share at the cost of security and reliability: costs like tremendous quantities of unsolicited spam, phishing websites, botnets, viruses, and a diverse software ecosystem that inevitably results in bugs and crashes. The cell phone that we know today, on the other hand, is sterile: if it even allows any kind of invention and sharing, it does so in a very restrictive way, but with understandable motives. For instance, not only are we socially conditioned to expect a phone to not crash while making a call, but it’s actually life-critical that this be true, e.g. when calling 911 during an emergency.

In short, Zittrain is concerned about these kinds of choices we make, between freedom and safety, in the world of information. He believes that while the history of the Internet has been one of enormous generativity, it’s eminently possible for its future to be one of sterility as we’re continually faced with new challenges that personal computers and the Internet were never built for.

I’ve only read Part I of his book so far, and I’ve found his analysis to be quite thought-provoking, as well as a little frightening. What impresses me most, however, is one of the more mundane aspects of his work: it’s published under a Creative Commons license, which means that, among other things, you can read it online and collaboratively annotate it with others, download a PDF and print it out (or send it to your sterile Kindle like I did), or pretty much do almost anything else you want with it. That Zittrain has actively chosen to allow his own work to be freely used for generative ends suggests to me that he practices what he preaches.

Running C and Python Code on The Web

Published
by
Atul
on July 3, 2008
in Coding, Mozilla and Python
. 39 Comments

Last week, Scott Petersen from Adobe gave a talk at Mozilla on a toolchain he’s been creating—soon to be open-sourced—that allows C code to be targeted to the Tamarin virtual machine. Aside from being a really interesting piece of technology, I thought its implications for the web were pretty impressive.

Before reading this post, readers who aren’t familiar with Tamarin may want to read Frank Hecker’s excellent Adobe, Mozilla, and Tamarin post from 2006 for some background on its goals and why it’s relevant to Mozilla and the open-source community in general.

If I followed his presentation right, Petersen’s toolchain works something like this:

  1. A special version of the GNU C Compiler—possibly llvm-gcc—compiles C code into instructions for the Low Level Virtual Machine.
  2. The LLVM instructions are converted into opcodes for a custom Virtual Machine that runs in ActionScript, a variant of ECMAScript and sibling of JavaScript.
  3. The ActionScript is automatically compiled into Tamarin bytecode by Adobe Flash, which may be further compiled into native machine language by Tamarin’s Just-in-Time (JIT) compiler.

The toolchain includes lots of other details, such as a custom POSIX system call API and a C multimedia library that provides access to Flash. And there’s some things that Petersen had to add to Tamarin, such as a native byte array that maps directly to RAM, thereby allowing the VM’s “emulation” of memory to have only a minor overhead over the real thing.

The end result is the ability to run a wide variety of existing C code in Flash at acceptable speeds. Petersen demonstrated a version of Quake running in a Flash app, as well as a C-based Nintendo emulator running Zelda; both were eminently playable, and included sound effects and music.

So, once Petersen’s modifications to Tamarin make their way into the next version of Adobe Flash, we can expect to see older commercial games running in the browser. Even more impressive, though, is the sheer volume of existing code that can be made to run inside the browser: Petersen showed us the C-compiled versions of Lua, Ruby, Perl, and Python all running on the web in secure Flash sandboxes.

What this means for Python

The potential implications this has for Python are particularly interesting to me. The ability to run Python on the web is exciting, to say the least; also interesting is the fact that by sandboxing CPython in a virtual machine, we solve a lot of the security issues that currently face the language when it comes to running untrusted code.

Petersen’s work also resonates with a few goals of another project called PyPy. I’m going to try to explain the idea behind PyPy in a later post; for the time being, the slides from my April 2007 ChiPy presentation on PyPy may serve as a passable introduction.

In a nutshell, the difference in mindset between PyPy and Petersen’s work is that the former is radically innovative in scope and mission, while the latter is pragmatic. PyPy’s goal is essentially to move the canonical implementation of Python from C to Python itself, and then use a pluggable toolchain to translate the Python interpreter to any platform with a configurable set of language and implementation features. In one fell swoop, this modularizes the composition of the Python interpreter in such a way that innovating and maintaining different ports and variants of Python like IronPython, Jython, and Stackless no longer requires either writing an entire copy of the same interpreter in a different language or branching the CPython source code and making pervasive changes to it.

Rather than focusing on innovation, Petersen’s work focuses on code reuse. Instead of moving a canonical interpreter implementation from C to a dynamic language, his strategy is to simply compile the existing C code to run in a virtual machine that’s implemented in a dynamic language. Both approaches aim to obviate the necessity of “ports” of interpreters to different platforms, and as such their purposes intersect at a common subset of functionality. But Petersen’s work can’t be used to facilitate the innovation of the Python language and its implementation, while PyPy offers few or no tools to reuse existing non-Python code. Perhaps it’s possible to combine the best of both worlds by taking PyPy’s generated C interpreter and using Petersen’s toolchain to allow it to be usable on the web and other places that Tamarin runs.

What this means for the Open Web

To be honest, I’m not quite sure where the dividing line is between what of Petersen’s work is Flash-specific and what can be reused to benefit the Open Web. Since ActionScript is a sibling language to JavaScript, it’s possible that the custom VM he created can be run in a browser with relatively few modifications—albeit much more slowly in Firefox at the time being, since SpiderMonkey-Tamarin integration is not yet complete. Once that’s further along, though, I imagine it should be possible to create C “libraries” that can be used in the toolchain to allow sandboxed C code to interact with web pages rather than Flash apps. Should this be feasible, I think it will possibly be the ultimate in a relatively recent string of next-generation Javascript virtual machines that allow existing code to run safely in browsers.

Also, in the context of the web, download size is a significant concern because applications are essentially streamed to clients. While Petersen’s toolchain means that it’s possible to instantly inherit most of CPython’s benefits on the web, it also means that we get all of its flaws along with it—such as the fact that the standard CPython distribution is a few megabytes large. But there’s ways to get around this.

In any case, I’m really excited to see how both Petersen’s work and PyPy proceed. I just hope I haven’t mis-represented either one of them here due to a lack of understanding; I’ll try to correct this blog post as I become aware of my mistakes.

Learning How to Write Interactive Fiction

Published
by
Atul
on June 29, 2008
in Coding and Interactive Fiction
. 3 Comments

Yesterday I tried learning Inform 7.

I’m not sure how I feel about the documentation for this language; on the one hand, like its predecessor, the DM4 for Inform 6, it’s extremely thorough and well-written. On the other hand, one aspect of the DM4 that made it among my favorite programming books—perhaps one of my favorite books, period—was its exercises, which made experiencing the book fairly interactive. The act of reading a relatively short amount of text and then putting one’s newly-found knowledge to use in the solving of a difficult problem not only helped reinforce the knowledge for me, but it was also fun. On top of this, many of the exercises involved implementing features found in classic works of interactive fiction, which gave the experience a fascinating historical dimension as well; as such, the book was almost like a work of “interactive nonfiction” in and of itself.

This is actually not unlike what I enjoyed about the better mathematics textbooks I used in college, which interspersed information with theorems that the reader had to prove in order to move forward, as the book used the theorems in later chapters. It almost made it feel as though the reader was on equal terms with the author, that they were in some way writing the book together. Proving these theorems had a historical dimension to them as well, since they clearly had to be completed by mathematicians years ago in order to arrive at the understanding of mathematics we have today.

The Inform 7 manual, in contrast to the DM4, features non-interactive examples instead of exercises, which makes the book a little less compelling to read. It also makes the book feel a bit more overwhelming, as my understanding of the language being taught isn’t constantly put to the test the way it was in the DM4.

I get the impression that this was intentional. When reading the DM4, I didn’t really have much of an idea of what kind of IF I wanted to write, and indeed, I never actually wrote any after finishing the book and doing all the exercises. Inform 7, on the other hand, seems focused on actually getting authors to write what they want with as little training as necessary.

This makes sense to me; good adult literacy programs don’t bog their students down with rules of grammar and spelling, foregoing the red pen in favor of placing primacy on first getting the student to actually enjoy expressing themselves through writing. In that vein, perhaps it’s wise to not distract the reader with interesting yet ultimately pedagogical examples that cause them to focus more on the mechanics of interactive fiction rather than the actual content.

The design of the language itself makes sense in this vein, as Inform 7 looks much more like natural language—which is the actual domain of interactive fiction—than its predecessor, Inform 6, which looks much more like a dialect of C. But I’m not yet sure what this means for me; I think I’m going to try just writing a story without reading any more of the Inform 7 manual, and only use the manual for reference, when I need to do something that I have no idea how to do.

Introducing Parchment

Published
by
Atul
on June 15, 2008
in Coding, Gaming, Interactive Fiction and Mozilla
. 24 Comments

A few weeks ago, I started a small project to create a user interface for something called a Z-Machine: a virtual machine created by Infocom in the late 1970’s to run their text adventure games—the most famous among them being Zork, which is apparently what the “Z” in Z-Machine stands for. These games, as their name suggests, are completely text-based; Infocom’s 1984 masterpiece The Hitchhiker’s Guide to the Galaxy, for instance, opens with this passage:

    You wake up. The room is spinning very gently round your head. Or at
least it would be if you could see it which you can't.

It is pitch black.

At this point, the player is presented with a prompt, where they can type what they want to do using natural english sentences; entering turn on light, for instance, would attempt to make the player turn on the room’s lights. For the most part, these games were like literary puzzles; at the beginning of Hitchhiker, for instance, the first “puzzle” is to figure out how to see things, and the next is to get over your morning migraine.

The interesting thing is that the virtual machine powering Infocom’s games lived past the company’s demise, which occurred in the late 1980’s: in the early 90’s, it was reverse-engineered by a clever mathematician-poet named Graham Nelson. A small but vibrant community rose up around this time, at first with the intent to create their own Infocom-style text adventures; but some of their works eventually surpassed anything Infocom had ever published. Because of the fact that some of these “games” were really more like interactive versions of novels or short stories rather than traditional puzzle-based adventures, the community decided to call them “interactive fiction”.

If modern video games like Halo and Grand Theft Auto are like movies, then interactive fiction is the literary equivalent. And in-line with this analogy, one of the many practical advantages of creating IF is that—unlike most video games that require programming and music and graphics—it’s eminently possible for a lone author to create something enduring.

Perhaps due to this low barrier, one of the things that I find particularly inspiring about the interactive fiction community is its diversity, especially in comparison to the modern industry of video game development. Unlike the video game industry, authors aren’t expected to have a technical background, and so the tools the community has created generally don’t assume any: one of the most popular programming languages for IF, called Inform 7, was actually designed by some of the most talented authors in the field, and the result is a fascinating rule-based language that reads much like literature.

Curiously, though, actually experiencing interactive fiction could be a bit cumbersome, as I found when trying to introduce friends to the genre: first, a user would have to download and install an interpreter application which was capable of decoding and providing a user interface for the work itself, which was contained in a story file that the user would have to download separately. Then, the user would have to open the story file with the interpreter. The amount of work involved in playing such a seemingly “low-tech” game seemed a bit out of proportion in comparison to the more multimedia-rich offerings available on the web through sites like Kongregate, which allow games to be shared and played with the click of a hyperlink.

Aside from that, though, there was another issue I had with most of the interpreters I’d used, which was that they didn’t seem to pay much attention to typography—for instance, they didn’t offer any mechanism for the author of a game to specify its typographic design, so as to let the typesetting honor the content in the best possible way.

The more I thought about it, the more the web actually seemed like an ideal place for interactive fiction to be experienced, rather than merely a more convenient one. HTML and CSS, for instance, provide far more flexibility for typography and layout than any desktop technology I know of, and the notion of a page with constantly-increasing length is much more suited to the medium than a computer terminal. Furthermore, recent advances in browser technology set forth by HTML 5 and implemented by standards-compliant browsers like Firefox, Safari, and Opera make it possible to save and restore games just like desktop interpreters, as well as play them while offline, all without the need of any special plugins like Flash or Java.

I actually found a Z-Machine interpreter already written in JavaScript, in the form of Thomas Thurman’s open-source Gnusto; the only problem with Gnusto was that it was a Firefox extension instead of a web application. So I took a look at its source code, removed the engine from the rest of the XUL-based user interface and decoupled it from its XPCOM dependencies, and used John Resig’s excellent jQuery library to make my own web-based user interface for it.

I called the result Parchment, because I wanted playing interactive fiction titles to feel as natural as reading from and writing to a sheet of paper.

Parchment, like Gnusto, is open-source; its Google Code project page is at http://code.google.com/p/parchment. It still has a number of bugs and missing features. One of the most rewarding parts of creating Parchment has been the feedback I’ve received from the interactive fiction community; the kind and enthusiastic people at rec.arts.int-fiction have been extremely helpful by providing me with encouragement, suggestions, advice, bug reports, and even code contributions.

While I’ve learned a great deal about web development from writing Parchment—it’s my first “real” web application, at least since the days when CSS was too cutting-edge to be useful across browser implementations—I’d like to focus on such things in later posts and conclude this one by linking to Parchment-powered versions of some of my favorite interactive fiction titles. These should work if you’re using at least Firefox 2, Safari 3, Opera 9, or Internet Explorer 6.

  • Wishbringer, written by Brian Moriarty and published by Infocom in 1985, was the first text adventure game I ever won, when I played it in 2004. Yes, 2004: unlike a lot of interactive fiction afficionados, I didn’t play many of the genre’s classics as a child, and certainly never completed any of them. This game was designed to provide a pleasant introduction to the genre, so the puzzles aren’t particularly hard, but they’re not trivial either. If you’d like more information, check out my Wishbringer review and see the Wishbringer Infocom Gallery page, which contains images of some of the great “feelies” that came included with the game’s packaging.
  • Plundered Hearts, written by Amy Briggs and published by Infocom in 1987, was Infocom’s first and only foray into the romance genre. It’s also the only game of this genre that I’ve ever played or heard of, period. Set in the Carribean during the 1600’s, it features one of the earliest examples of a strong female lead in a computer game. It’s also a little harder than Wishbringer; see my Plundered Hearts review and the Plundered Hearts Infocom Gallery page for more information.
  • The Hitchhiker’s Guide to the Galaxy, written by Douglas Adams and Steve Meretzky and published by Infocom in 1984, is one of the most infamous text adventure games ever made. It’s also one of the hardest, in part because of the clever use of puns and wordplay required to solve its puzzles.
  • Photopia is the first of my selections that wasn’t a published commercial game, but was a product of the modern era of interactive fiction. Written in by Adam Cadre in 1998 and winner of that year’s community-wide Interactive Fiction Competition, this title is a touching interactive story that doesn’t actually feature any puzzles. See Cadre’s website for more information about this and other works of his.
  • Galatea, written by Emily Short in 2000, received the Best of Show prize in the community’s Interactive Fiction Art Show of that year. Like Photopia, it’s not a traditional adventure game; rather, it’s like an interactive portrait, in which the player can converse with Galatea, the mythical statue-come-to-life created by Pygmalion. There is no “win condition” for the game and no real puzzles per se, but the plot is highly multilinear in that the player’s conversation with Galatea can end in a wide variety of ways, some of which are more satisfying than others. See Short’s website for more information about this and other works of hers.

If you liked any of these, you can actually play any game created by the interactive fiction community at http://parchment.toolness.com. Enjoy!

Python-SpiderMonkey Resurrected

Published
by
Atul
on June 11, 2008
in Coding, Mozilla and Python
. 5 Comments

Yesterday I found John J. Lee’s old Python-SpiderMonkey code from 2003, which creates a bridge between the Python language and Mozilla’s SpiderMonkey JavaScript engine—the same engine that powers Firefox. Lee mentioned on his website that it’s not currently maintained, and after downloading it and trying to compile it, I found that SpiderMonkey had changed a bit since the code had been written, so I made some fixes and, after discussing things with him, set up a new Google Code project for it at http://code.google.com/p/python-spidermonkey.

I also revamped the documentation, wrote a basic tutorial, and removed some dependencies for building it.

Interoperating between Python and C

Python-SpiderMonkey still isn’t particularly easy to build, though: while you no longer need to get Pyrex or compile SpiderMonkey yourself, you do need to download the XULRunner SDK and have a C compiler on your system so the C Python extension can be created. Ideally, this shouldn’t have to be done: I’ve written some example code that uses ctypes to dynamically load the SpiderMonkey shared library file at runtime, which is proof that all that should be required by Python-SpiderMonkey are Python and either Firefox or the XULRunner SDK.

On the other hand, Python-SpiderMonkey currently uses Pyrex—a dialect of Python that understands C data types—to do all its communication with SpiderMonkey. This was my first time using Pyrex, and I’m quite impressed: without even reading a tutorial, it was easy for me to understand and change what Lee’s Pyrex code was doing. Having written “from scratch” C Python extensions, SWIG extensions, and ctypes code, I think that my (admittedly brief) encounter with Pyrex makes it my favorite of all the options from a coding standpoint: it was very easy for me to write (and read!) code that interoperated between Python and C. On top of that, tracebacks into Pyrex-generated code were eminently useful, which made debugging very easy—and almost as much fun as writing pure Python code, if it weren’t for the recompilation step (which makes me wonder if there’s an importer that transparently re-compiles Pyrex code on-the-fly).

The only downside of Pyrex, though, is that it compiles to a C Python extension, which makes it difficult for other Python users to use. It’d be really cool to see an optional backend for Pyrex that compiled its extension down to ctypes-wielding Python code instead, but I’m not sure how possible that is. I suspect that the issue of calling C macros from Python code would be an annoying one to get around.

Why did I do this?

To begin with, I should make it clear that I didn’t actually do much—this is still almost exclusively John J. Lee’s code. I just added some documentation, made the build process a bit easier, and got it to work on modern builds of SpiderMonkey.

One reason I did this was just for personal education: I wanted to see what Pyrex was like, and I also wanted to get my hands dirty with the rather well-documented SpiderMonkey C API. In doing that, I actually found a potential bug in SpiderMonkey that I submitted a test case for.

The other main reason I did this may be a bit controversial.

Since becoming more acquainted with web programming, I’ve started to really like JavaScript. Aside from the fact that it’s on almost everyone’s computer and its applications in web-content-space are incredibly easy to deploy, it’s just a fun and powerful language to use, once you get around some of its wrinkles. It’s in this web-content-space where the language is used by an enormous community of developers and new tools and better ways of doing things are invented every day.

The thing is, a lot of Firefox itself is implemented in JavaScript, and that’s not really web-content-space; Mozilla calls it chrome-space, because it has entry to a variety of software components—via a rather obtuse and verbose Microsoft-inspired system called XPCOM—that provide access to the local system. Think file I/O, sqlite storage, the sorts of things that the Python standard library does.

The only problem is that, perhaps because chrome-content JavaScript and the associated XPCOM componentry is only really used by Mozilla, Firefox extension developers, and a handful of smaller projects, the development environment isn’t nearly as mature and as much fun to program in as web-content JavaScript and Python. There’s no Firebug, for instance, and there’s nothing like nose; there are very few development and testing tools in general, and they’re not terribly robust. Perhaps most importantly for newcomers to chrome-content like myself—and in stark contrast to the Python standard library and nearly every major Python library in existence—many XPCOM components don’t even have any documentation. Just accessing the filesystem to open a file can involve a nontrivial amount of XPCOM sorcery, unless you happen to find the right page on MDC or talk to the right person on IRC. Development tools often fall into disrepair, quickly becoming nonfunctional because the trunk changed, the original developer stopped maintaining the code and no one was interested in picking it up.

This isn’t to say that it’s impossible to do things in chrome-content. Almost nothing is impossible for a programmer; it’s rather that things just aren’t fun, especially when compared to well-documented platforms with diverse, vibrant communities like web-content JavaScript and Python.

So, I’ve been spending some of my time trying to connect Python to JavaScript, so that, at least when it comes to writing unit and system tests, chrome-content JS can leverage some of Python’s mature, well-documented, easy-to-use tools. I don’t have any really concrete ideas just yet, but I think that building a bridge between Python and JavaScript is the first step. There’s also another somewhat neglected package called PyXPCOM that I’d like to make a little easier to use and possibly integrate with Python-SpiderMonkey—but that’s a topic for another post.

Aside from the world of chrome-content JavaScript, there are a few other places where I think this kind of bridge could be useful:

  • As I mentioned in my overview of Weave, because the client’s data is decrypted client-side, almost all synchronization logic needs to be done there. This logic needs to be rock-solid in all client implementations, or else the user’s data can become corrupted. So one way of creating a Python client may be to simply reuse the sync logic from the Weave extension, which is written in JavaScript 1.7.
  • It seems as though web applications need to duplicate logic on both the client and server side: for example, client-side code in a web application may want to check to see if a user’s credit card number is valid, and warn them before they submit the form. The same logic may need to be duplicated on the server-side; one way to do this is by allowing Python-based servers to access some of the JavaScript code that’s being sent to the client, to prevent the duplication of code in multiple languages.

I’ve talked to Ian Bicking and Kumar McMillan about this too, and they had some pretty interesting ideas of things that could be done with Python-SpiderMonkey. I’m interested in hearing any other thoughts people have on this.

The Morality of Bottled Water

Published
by
Atul
on June 8, 2008
in General
. 3 Comments

Salon.com recently published an interesting interview with Elizabeth Royte, the author of a new book called Bottlemania: How Water Went on Sale and Why We Bought It.

It’s definitely worth a read, I think. One of the biggest takeaways from it is the fact that the whole “8 cups of water a day” maxim isn’t so much a myth as a misinterpretation that’s been promulgated by the water industry: yes, we need 8 cups of water a day, but we already get most of it from the water contained in the food we eat. And as with most environmentally and ethically-conscious texts, it looks like this one ultimately prescribes a local solution: get your water locally, whether it’s from a tap or—if you’re in a place that has extremely poor public water—a bottle.

I don’t really consider myself to be an environmentalist, but I really like the idea of “staying local”. For me, it’s largely just an issue of understanding small, simple systems versus enormous, complex ones. It’s also an issue of observability. Things immediately around you are easier to perceive and understand the nature of; it’s relatively straightforward to know whether the people in your community are happy with something, because they’re your friends and neighbors and you can talk to them. One of the most startling realizations I had in college while researching the issue of sweatshops was that there was actually no way for me to truly know whether people who worked in sweatshops were unhappy that they had their job without either going to the affected area and seeing things for myself or doing an enormous amount of research; otherwise, any single account portraying a positive picture could be dismissed as corporate propaganda, while authors of negative portrayals could have their own agendas. And either way, reading reams of journalistic accounts in an effort to obtain a balanced perspective or traveling the world myself would be a huge time investment. Much easier, and far more satisfying, would be to simply obtain my clothing from someone I knew and trusted, who obtained their raw materials from someone they knew and trusted, and so on.

This isn’t to say that one should be blind to the things that are affecting the globe, of course, because ultimately the things that happen around the world do affect us whether we like it or not. It’s rather that whenever I read things like this interview, I become acutely aware that it is by no means a trivial matter to be certain of what’s true and what’s not in today’s world, especially as the players become more aware of what people find truthful and use it to manipulate people to their own ends. A recent book by Farhad Manjoo called True Enough: Learning to Live in a Post-Fact Society seems to address this issue, and I think I may pick it up soon.

Python for JavaScript Programmers

Published
by
Atul
on June 6, 2008
in Coding, Mozilla and Python
. 20 Comments

I couldn’t find anything on the web that attempted to teach Python to readers who already knew JavaScript, so I thought I’d give it a shot, since a number of my friends at Mozilla don’t know much about Python but know JavaScript incredibly well. The languages actually aren’t that dissimilar—in fact, some of JavaScript’s latest features have been borrowed directly from Python.

Aside from focusing on differences and similarities between the two languages, I also try to explain Python’s design philosophy a bit, to give readers a context for why things work the way they do.

You can read the tutorial here.