Lost's pilot episode pulled me in. It was one of the best television shows I'd ever seen. The writing was brilliant, the actors were not only excellent, but all clearly gave everything they had (with one or two exceptions, but I'm able to ignore than in an ensemble cast). By the second season, the show had ground to a halt, and I became bored. I'd also been burned by Alias, Abrams' previous creation, and was not eager to be strung along for season after season again. I stopped watching late in the second season, and didn't come back until the fifth. The fourth and fifth seasons definitely picked up the pace of the show, but I was left wondering how much of what was going on would be revealed. The show was clearly set on a very cosmic trajectory, and to play that out would risk alienating a large percentage of the viewship (no matter how you play out a cosmic ending, it always alienates someone who feels that your story conflicts with their beliefs).
So, it was with trepidation that I approached the sixth season, and in fact in the final two and a half hour movie, they never did play out the larger back-story. This post is aimed at exploring what was actually going on and whether, speculation aside, we had enough information to understand what it was that was going on. This will involve spoilers for the entire series. If you haven't watched the final seasons, I suggest you do, but go in expecting a non-reveal. I liked the last episode, but I felt the way I felt at the end of Donnie Darko: clearly someone knew where they wanted to go with this, but decided they didn't have the time, creative freedom or desire to follow through. In the case of DD, the story played out in supplemental materials on the Web. In the case of Lost, I think the creators simply don't want to explain what they feel they've sufficiently hinted at, for fear of losing the sense of mystery.
OK, so let's see if we can extract reason from this show. There is really only one unanswered question of merit: what is the island? The other questions ("what are the numbers," "why do pregnant women die, etc." are secondary to this central theme and may not have answers outside of fan speculation).
Tuesday, May 25, 2010
Sunday, May 23, 2010
Writing a Perl 6 URI module
I wanted to write a parser of some sort using Perl 6's spiffy parser language otherwise known as "rules". This is the super-extended regular expression syntax that Perl 6's own parser is written in, and it's not just powerful, it's easy to use. In fact, it's so easy to use that almost all of my time writing a URI parser module was spent on other aspects of the code than the parser itself.
First off, some background. Perl 6 has a URI module already. However, it relies on a number of Perl built-in character classes to match things like digits and alphanumerics. In reality, the RFCs that define URIs are very precise, and there are different specifications depending on what you need. So, I decided to re-write the module with a pluggable parser so that you could give a regular, modern URI and have it parse correctly, but you could also ask for special "IRI" parsing on an internationalized URI and the right thing would happen there. I even went so far as to bring in an older version of the specification as a legacy mode.
The current state of the Perl 6 parser and runtime called Rakudo is actually fairly solid for a pre-release implementation of such a complex language spec. There are some gaping holes, but they were all relatively easy to work around. Some of these included overly aggressive list-flattening, some operators that were broken at the time I wrote this code and the big one: named rules only work as a stand-alone grammer with a specific entry-point called TOP.
I worked around all of these issues and have, so far, been able to parse basic URIs according to RFC 3986. Here's a sample of what a Perl grammar for URIs looks like:
Here you can see most of the basics: "token" introduces a single expression within the grammar. It calls out to other tokens by enclosing their names in angle-brackets. Literal sequences are enclosed in single-quotes and sub-expressions can be enclosed in square-brackets with regular expression-like repetition counts such as ? for 0 or 1 matches.
In order to have a pluggable interface, I needed a class capable of providing me with two things for each grammar: the grammar itself and a set of routines which would tell me how to find the resulting URI elements in the match data. For this I defined an interface using Perl 6's roles:
Those ellipses are literal. They cause the methods to be required for any class composed with this role, but do not define any functionality themselves.
Each parser is then defined as:
That's it. The only really funky bit here is the gather/take code in the scheme_path. That's the way Perl 6 defines a coroutine-like interface. The paths define how we traverse the match object to find match results. So, for example, the "scheme" (the "http" in "http:/www.example.com/") can only be matched in the URI rule's scheme sub-rule. Some URI elements, however, such as authority (the host name and port - possibly username as well) can be matched multiple ways, so these routines might return multiple lists of subrule names to traverse. I would have simply returned a list of lists, but Perl 6's parameter passing is very complex and currently some of the specification is not yet implemented. Right now, this manifests as overly aggressive list flattening when returning them from a subroutine or method.
This is why I used coroutines to return each of the sub-lists, one call at a time.
I'll continue to post new updates as my URI module nears readiness. For now, it's just awaiting some love on the other parsers, and I think it'll be ready to go.
First off, some background. Perl 6 has a URI module already. However, it relies on a number of Perl built-in character classes to match things like digits and alphanumerics. In reality, the RFCs that define URIs are very precise, and there are different specifications depending on what you need. So, I decided to re-write the module with a pluggable parser so that you could give a regular, modern URI and have it parse correctly, but you could also ask for special "IRI" parsing on an internationalized URI and the right thing would happen there. I even went so far as to bring in an older version of the specification as a legacy mode.
The current state of the Perl 6 parser and runtime called Rakudo is actually fairly solid for a pre-release implementation of such a complex language spec. There are some gaping holes, but they were all relatively easy to work around. Some of these included overly aggressive list-flattening, some operators that were broken at the time I wrote this code and the big one: named rules only work as a stand-alone grammer with a specific entry-point called TOP.
I worked around all of these issues and have, so far, been able to parse basic URIs according to RFC 3986. Here's a sample of what a Perl grammar for URIs looks like:
token URI {
':' [ '?' ]? [ '#' ]?
}
}
Here you can see most of the basics: "token" introduces a single expression within the grammar. It calls out to other tokens by enclosing their names in angle-brackets. Literal sequences are enclosed in single-quotes and sub-expressions can be enclosed in square-brackets with regular expression-like repetition counts such as ? for 0 or 1 matches.
In order to have a pluggable interface, I needed a class capable of providing me with two things for each grammar: the grammar itself and a set of routines which would tell me how to find the resulting URI elements in the match data. For this I defined an interface using Perl 6's roles:
role URI::Specification {
method parser() { ... }
method scheme_path() { ... }
# ... other _path methods here... }
Those ellipses are literal. They cause the methods to be required for any class composed with this role, but do not define any functionality themselves.
Each parser is then defined as:
class URI::rfc3896 does URI::Specification {
grammar URI::rfc3896::spec {
token TOP { }
# RFC definition of URI goes here.
}
method parser() { return ::URI::rfc3896::spec }
method scheme_path() {
gather do { take }
}
# And so on ...
}
That's it. The only really funky bit here is the gather/take code in the scheme_path. That's the way Perl 6 defines a coroutine-like interface. The paths define how we traverse the match object to find match results. So, for example, the "scheme" (the "http" in "http:/www.example.com/") can only be matched in the URI rule's scheme sub-rule. Some URI elements, however, such as authority (the host name and port - possibly username as well) can be matched multiple ways, so these routines might return multiple lists of subrule names to traverse. I would have simply returned a list of lists, but Perl 6's parameter passing is very complex and currently some of the specification is not yet implemented. Right now, this manifests as overly aggressive list flattening when returning them from a subroutine or method.
This is why I used coroutines to return each of the sub-lists, one call at a time.
I'll continue to post new updates as my URI module nears readiness. For now, it's just awaiting some love on the other parsers, and I think it'll be ready to go.
Labels:
Perl,
programming,
programming languages,
software
Thursday, May 20, 2010
Icons from Wikimedia Commons
I'm often lacking for exactly the right Icon for Web work, and then I remember Wikimedia Commons. For a number of open-licensed UIs I've used the Wikimedia images to help create a look that implies I spent an awful lot of time and energy. These icons vary in quality because they were uploaded from different sources, but you can get some of the best icons available from this site (along with, of course, the best freely licensed photographs and other media). Commons is a gem, and if you don't use it, you're probably missing out.
The Crystal Icons from KDE were uploaded as PNG, but the original SVG icons can be acquired from their original site. These are very clean and plastic-feeling icons for everything from the power button you see on the left to various arrows to hands to gears. Because they were uploaded in fairly high resolution, using the PNG versions isn't all bad, but you'll still get a better final result if you work from the SVG.
There are also many icons for specific applications. You can use these when writing reviews or otherwise mentioning the applications in quesiton. Many of the application icons come from the Crystal set as above, but some are directly lifted from open source projects, such as the Gaim (now pidgin) icon you see to the left.
Other icons include arrows, globes, hands and many other cateogries. You can browse all of the categories from Wikimedia's "icons by subject" page.
To use these icons, I recommend always selecting SVG format images and then using Inkscape . Load an SVG icon up in Inkscape and select File, Export Bitmap... to save it as a PNG file, setting the height and width to exactly what you want. For now, PNG is the way Web browsers deal with icons the best, though in the future, SVG will be taking over that role as older browsers fade away.
The Crystal Icons from KDE were uploaded as PNG, but the original SVG icons can be acquired from their original site. These are very clean and plastic-feeling icons for everything from the power button you see on the left to various arrows to hands to gears. Because they were uploaded in fairly high resolution, using the PNG versions isn't all bad, but you'll still get a better final result if you work from the SVG.
There are also many icons for specific applications. You can use these when writing reviews or otherwise mentioning the applications in quesiton. Many of the application icons come from the Crystal set as above, but some are directly lifted from open source projects, such as the Gaim (now pidgin) icon you see to the left.
Other icons include arrows, globes, hands and many other cateogries. You can browse all of the categories from Wikimedia's "icons by subject" page.
To use these icons, I recommend always selecting SVG format images and then using Inkscape . Load an SVG icon up in Inkscape and select File, Export Bitmap... to save it as a PNG file, setting the height and width to exactly what you want. For now, PNG is the way Web browsers deal with icons the best, though in the future, SVG will be taking over that role as older browsers fade away.
Labels:
World Wide Web
Wednesday, May 12, 2010
Fire alarms: Among the worst UIs in history
So a fire alarm just went off in my office building. Here's what you hear:
"*beep* Your attention please. There has been a report of an emergency in this building. If your floor evacuation tone sounds after this message, please leave the building. *beep* Your Attention please. ..."
OK, am I the only person who sees the problem with that announcement? Is the second *beep* just a repeat of the message or am I supposed to read that as "my floor's evacuation tone?" What does my floor's signal tone sound like? Is it different from other floors? Does our floor's signal tone rule relative to the suckage of other floors' signal tones?
So here's an idea: Instead of a useless recorded message, have the damned thing announce the floor that the problem exists on (or floors). I'd really love to hear, "Floors 8 through 10 should consider jumping out the windows because a fire is quickly sucking the oxygen out of the stair wells!" Now that would be a warning I could do something with.
"*beep* Your attention please. There has been a report of an emergency in this building. If your floor evacuation tone sounds after this message, please leave the building. *beep* Your Attention please. ..."
OK, am I the only person who sees the problem with that announcement? Is the second *beep* just a repeat of the message or am I supposed to read that as "my floor's evacuation tone?" What does my floor's signal tone sound like? Is it different from other floors? Does our floor's signal tone rule relative to the suckage of other floors' signal tones?
So here's an idea: Instead of a useless recorded message, have the damned thing announce the floor that the problem exists on (or floors). I'd really love to hear, "Floors 8 through 10 should consider jumping out the windows because a fire is quickly sucking the oxygen out of the stair wells!" Now that would be a warning I could do something with.
Labels:
technology
Monday, May 3, 2010
Test Wave Post
I'm testing out Google Wave integration. Please, let me know what you think in the Wave, below.
Labels:
Google,
social networking
Subscribe to:
Posts (Atom)