Fellow Somerville resident and former MIT employee Jeff Deck is a modern-day Quixotic hero. As founding member of the Typo Eradication Advancement League (TEAL), Deck and his friend Benjamin Herson traveled across the USA this Spring fixing typos that they found on all types of signage. They unfortunately ran afoul of the US Government recently, when they "fixed" a historic sign at Grand Canyon National Park.
According to CNN: The sign was made by Mary Elizabeth Jane Colter, the architect who designed the rustic 1930s watchtower and other Grand Canyon-area landmarks. [read the full article]
Deck was interviewed on NPR in March, and as the story of TEAL's sentencing hit the news today (they got a year's probation, during which they cannot enter any national park or modify any public signs and a fine of $3,035 to repair the sign at the Grand Canyon), the TEAL website has become stripped of all interesting information. I want photos!
The other side of the story, of course, is that Deck and Herson actually are vandalizing signs, which is illegal defacement of property that does not belong to them. Moreover, if a sign from the 1930's has language that was different than what we use today, it might be the case that the language was correct given the conventions of the time. In that case, these vigilante word-fixers may be erasing our access to interesting cultural heritage!
I think that the TEAL project - though charming, and satisfying in a compulsive kind of way - is actually doomed to failure. Language constantly evolves, and these guys are fighting a very strong tide. If enough people make the same language mistake, it's no longer a mistake - it becomes part of the language (read Steven Pinker for more about how language changes over time, and this article in Wired magazine about Chinglish).
All of that said, the proofreader in me is all for TEAL - here's hoping that Jeff comes out on the other side of this challenge unscathed and ready to keep eradicating typos!
Saturday, August 23, 2008
Tuesday, August 12, 2008
personal freedoms vs public safety
There is a delicate balance between protecting people's freedom to invent and protecting public safety. The populace and the authorities are all so jumpy these days due to a perceived increase in the daily level of threat. It's true that if someone's side-project out in the garage is being built to harm their fellow citizens, somebody ought to nip that in the bud. However, the difficulty comes from sorting out real threat versus perceived threat.
Case in point: the basement of a a retired chemist living in Worcester was raided by MA State Department of Environmental Protection and although in the end the authorities conceded that they hadn't found anything particularly dangerous or incriminating, they are still planning to dispose of the guy's chemicals. Of course this is completely unfair to the chemist: he knows what he's doing, and was working on his own projects, and out of nowhere the state swoops in and declares his work dangerous to the public good.
Make Magazine posted a fiery response.
As an inventor of technology I find this story pretty disturbing. Constraints on what law-abiding citizens can invent, or experiment with, will stifle innovation when as a nation we need it most. As a related thread, I'm concerned by the corset getting tightened on the internet in a couple of ways:
First, I own an iPhone, but am really torn by the fact that all iPhone applications must be approved by Apple before they are available to the public. If the iPhone had a relatively small user base, I would not be disturbed - but the fact that such a popular mobile internet device has taken this walled garden approach makes me worried that lots of people will end up accepting these kinds of limitations as the price of admission, and we'll miss out on a lot of good things that the unencumbered mobile internet might otherwise bring to our lives.
Second, the question of traffic-shaping is a difficult one. With respect to the iPhone, the gadget doesn't even allow for HTTP downloads, which is pretty crippling. Furthermore, an application that would let a computer share the iPhone's internet connection was yanked from the Application store. Finally, I've read stories about ISPs blocking peer-to-peer traffic such as BitTorrent. The argument from the ISP is usually that P2P traffic degrades the internet experience of everyone else on your block, so they limit it. But is that fair? What are the rules of the internet?
In any case, it's now it's possible that both my home, and phone-based connections to the internet have serious constrictions on how they may be used. What if I wanted to invent an amazing and helpful new internet service that was just not feasible due to these policies? Maybe I'd just be stuck. Fortunately I have a connection at MIT that I trust to be un-constricted in these ways, but the vast majority of folks do not have such a connection. And if I didn't have it, might the constraints of my iPhone / cablemodem connections limit the type of invention that I'd even consider possible?
I think the answer is to keep inventing for an unfettered world, even if the actual one is somewhat-fettered. And when freedoms are infringed on, make some noise about it. Borrowing some ethos from the Media Lab, don't ask permission to implement your idea, just do it. To paraphrase a thought that Hugh Kenner penned in his book Bucky: A Guided Tour of Buckminster Fuller, if the Wright Brothers had tried to get a permit for their work, they would probably still be waiting around for it!
Case in point: the basement of a a retired chemist living in Worcester was raided by MA State Department of Environmental Protection and although in the end the authorities conceded that they hadn't found anything particularly dangerous or incriminating, they are still planning to dispose of the guy's chemicals. Of course this is completely unfair to the chemist: he knows what he's doing, and was working on his own projects, and out of nowhere the state swoops in and declares his work dangerous to the public good.
Make Magazine posted a fiery response.
As an inventor of technology I find this story pretty disturbing. Constraints on what law-abiding citizens can invent, or experiment with, will stifle innovation when as a nation we need it most. As a related thread, I'm concerned by the corset getting tightened on the internet in a couple of ways:
First, I own an iPhone, but am really torn by the fact that all iPhone applications must be approved by Apple before they are available to the public. If the iPhone had a relatively small user base, I would not be disturbed - but the fact that such a popular mobile internet device has taken this walled garden approach makes me worried that lots of people will end up accepting these kinds of limitations as the price of admission, and we'll miss out on a lot of good things that the unencumbered mobile internet might otherwise bring to our lives.
Second, the question of traffic-shaping is a difficult one. With respect to the iPhone, the gadget doesn't even allow for HTTP downloads, which is pretty crippling. Furthermore, an application that would let a computer share the iPhone's internet connection was yanked from the Application store. Finally, I've read stories about ISPs blocking peer-to-peer traffic such as BitTorrent. The argument from the ISP is usually that P2P traffic degrades the internet experience of everyone else on your block, so they limit it. But is that fair? What are the rules of the internet?
In any case, it's now it's possible that both my home, and phone-based connections to the internet have serious constrictions on how they may be used. What if I wanted to invent an amazing and helpful new internet service that was just not feasible due to these policies? Maybe I'd just be stuck. Fortunately I have a connection at MIT that I trust to be un-constricted in these ways, but the vast majority of folks do not have such a connection. And if I didn't have it, might the constraints of my iPhone / cablemodem connections limit the type of invention that I'd even consider possible?
I think the answer is to keep inventing for an unfettered world, even if the actual one is somewhat-fettered. And when freedoms are infringed on, make some noise about it. Borrowing some ethos from the Media Lab, don't ask permission to implement your idea, just do it. To paraphrase a thought that Hugh Kenner penned in his book Bucky: A Guided Tour of Buckminster Fuller, if the Wright Brothers had tried to get a permit for their work, they would probably still be waiting around for it!
Sunday, August 10, 2008
XSPF Music Player playlist generator utility
I recently came across the XSPF Web Music Player. It's a nice Flash-based player that can be embedded into a webpage to provide in-browser music playing capabilities. I've already used it in a couple of places, and along the way I found it helpful for myself to create a python script that automatically generates the XML from a folder of music files. The script has some options that you can read about in the help listing, and it is available for download, here. You will also need id3reader.py.
Friday, August 08, 2008
GAMBIT MIT/Singapore Game Lab summer session open house
This morning I stopped by the Singapore-MIT Gambit Game Lab, a joint laboratory run by MIT and universities in Singapore, to check out the games that students in the 8-week summer session have created.
Overall I was impressed with the creativity and artistry evident in these games. There also seemed to be a focus on incorporating new platforms, including Nintendo DS (1 game) and Facebook (2 games). I also thought it was cool that a couple of the games were designed to teach reasoning skills, and one was accessible to a blind audience, incorporating easy keyboard navigation and extensive narration and sound feedback.
The listing of games is here. Here are a few thoughts on each of the games that I saw:
Moki Combat: Great 2D graphics that reminded me of all my time spent on Sierra and Lucasarts games as a kid. The actual gameplay was a bit frustrating though. I found it difficult to catch up to enemies, and once I caught them hard to orient my player so that the striking actions with my staff. I spent a lot of time rotating in circles looking for the enemy guys. Also, the menu navigation needs some minor play-testing - there were too many steps between selecting options and getting the game on.
Oozerts: Very cool that this is a puzzle game that invents an entirely new challenge, and the graphics were delightfully reminiscent of 8-bit games I've known and loved. I had a hard time figuring out the connection between the pie-shaped wedges and the subdivisions of the creature though - probably if I spent more time with the game this would have been more clear..
Phorm: Neat user-customization in this game! You can draw an outline of your character in 2D, then it renders a custom 3D character from your outline. The way you draw the character (bigger arms, long legs) affects the capabilities that it has during play, and different levels require different capabilities. I'd like to see this concept developed further - so far it seems that needing to jump higher (make longer legs) or punch something harder (make bigger arms) were the only two parameters that were meaningful to tweak. Extending this basic idea could make for really compelling gameplay with a number of other variations.
Akrasia: The 2D artwork of this game was beautiful and psychedelic, and the speed with which the character can run around the level was deliciously fast - very sonic-the-hedgehog-like. A control inversion that I experienced reminds me of drinking the inversion potion in Prince of Persia that turned the screen upside-down and backwards (i.e. pressing left made the character go right, etc..). Not the most innovative stumbling block to throw in front of the gamer, but definitely challenging!
Mūzaïc: Cute characters, and neat that this game is a facebook game, so they're exploring a new platform with a lot of potential. The point of the game (I think) is to populate your island with 4 characters that all have something in common, and something different about them (i.e. same body, different heads, or vice versa). There are little violin-playing dudes, robo-techno-guys, etc.. Although all of the characters seem to be male, you can somehow cross-breed your characters with characters that other players have on their island and you get a resulting baby with characteristics drawn from each partner. I liked the artwork and the fact that the sound design made this a blind-accessible game, however the gameplay itself didn't grab me much. Will have to see how it does out in the wild!
Picopoke: This seemed less like a game, and more like an online social activity. The point of this one seemed to be to upload your photos that fit a particular challenge/theme to a facebook application where a community of people can look at them and tag+judge them. As with Mūzaïc, will have to see how well this one does in the wild - I didn't play for long, but it seemed to need something more to draw people in. This reaction might just be a result of this being a casual game while others that I played were more immersive.
Gumbeat: This was hilariously appropriate - the team of students from Singapore made a game about being a girl who just wants to chew gum and blow big bubbles. She gets really happy if she can recruit a cadre of buddies that will all follow her, duckling-style, blowing bubbles as they walk around town. However, watch out for the policemen! If you blow a bubble next to one, your character is likely to get beaten down (or at least will be chased), which will severely decrease happiness. Nice 2.5D-scroller gameplay like Zelda but with a continuous landscape.
These students did nice work! I think they have bright futures in gaming ahead of them if they want it, and I'm looking forward to seeing what next year's teams create.
Overall I was impressed with the creativity and artistry evident in these games. There also seemed to be a focus on incorporating new platforms, including Nintendo DS (1 game) and Facebook (2 games). I also thought it was cool that a couple of the games were designed to teach reasoning skills, and one was accessible to a blind audience, incorporating easy keyboard navigation and extensive narration and sound feedback.
The listing of games is here. Here are a few thoughts on each of the games that I saw:
Moki Combat: Great 2D graphics that reminded me of all my time spent on Sierra and Lucasarts games as a kid. The actual gameplay was a bit frustrating though. I found it difficult to catch up to enemies, and once I caught them hard to orient my player so that the striking actions with my staff. I spent a lot of time rotating in circles looking for the enemy guys. Also, the menu navigation needs some minor play-testing - there were too many steps between selecting options and getting the game on.
Oozerts: Very cool that this is a puzzle game that invents an entirely new challenge, and the graphics were delightfully reminiscent of 8-bit games I've known and loved. I had a hard time figuring out the connection between the pie-shaped wedges and the subdivisions of the creature though - probably if I spent more time with the game this would have been more clear..
Phorm: Neat user-customization in this game! You can draw an outline of your character in 2D, then it renders a custom 3D character from your outline. The way you draw the character (bigger arms, long legs) affects the capabilities that it has during play, and different levels require different capabilities. I'd like to see this concept developed further - so far it seems that needing to jump higher (make longer legs) or punch something harder (make bigger arms) were the only two parameters that were meaningful to tweak. Extending this basic idea could make for really compelling gameplay with a number of other variations.
Akrasia: The 2D artwork of this game was beautiful and psychedelic, and the speed with which the character can run around the level was deliciously fast - very sonic-the-hedgehog-like. A control inversion that I experienced reminds me of drinking the inversion potion in Prince of Persia that turned the screen upside-down and backwards (i.e. pressing left made the character go right, etc..). Not the most innovative stumbling block to throw in front of the gamer, but definitely challenging!
Mūzaïc: Cute characters, and neat that this game is a facebook game, so they're exploring a new platform with a lot of potential. The point of the game (I think) is to populate your island with 4 characters that all have something in common, and something different about them (i.e. same body, different heads, or vice versa). There are little violin-playing dudes, robo-techno-guys, etc.. Although all of the characters seem to be male, you can somehow cross-breed your characters with characters that other players have on their island and you get a resulting baby with characteristics drawn from each partner. I liked the artwork and the fact that the sound design made this a blind-accessible game, however the gameplay itself didn't grab me much. Will have to see how it does out in the wild!
Picopoke: This seemed less like a game, and more like an online social activity. The point of this one seemed to be to upload your photos that fit a particular challenge/theme to a facebook application where a community of people can look at them and tag+judge them. As with Mūzaïc, will have to see how well this one does in the wild - I didn't play for long, but it seemed to need something more to draw people in. This reaction might just be a result of this being a casual game while others that I played were more immersive.
Gumbeat: This was hilariously appropriate - the team of students from Singapore made a game about being a girl who just wants to chew gum and blow big bubbles. She gets really happy if she can recruit a cadre of buddies that will all follow her, duckling-style, blowing bubbles as they walk around town. However, watch out for the policemen! If you blow a bubble next to one, your character is likely to get beaten down (or at least will be chased), which will severely decrease happiness. Nice 2.5D-scroller gameplay like Zelda but with a continuous landscape.
These students did nice work! I think they have bright futures in gaming ahead of them if they want it, and I'm looking forward to seeing what next year's teams create.
Saturday, August 02, 2008
Embedding Python into a C program
When I was looking into ways to connect siftables to GIMP, I decided to try to embed a dedicated, separate, Python interpreter in the GIMP runtime so that I could easily send commands to siftables from GIMP. GIMP already uses python for image-processing scripts, but I needed an interpreter that I could route message into and out of from the rest of the GUI. I started with the following simple test C application, to make sure that I could embed Python in an extremely simple C application. Here's what I did, may it be useful to you. note that you'll have to have Python headers installed on your system. I already did.
-- begin paste -- pytest.c --
#include "Python.h"
void exec_pycode(const char* code)
{
Py_Initialize();
PyRun_SimpleString(code);
Py_Finalize();
}
int main(void)
{
exec_pycode("print \'helloworld\'");
return 0;
}
-- end paste -- pytest.c --
Then, to compile it I typed:
cc pytest.c -o pytest -lpython2.5 -lm -L/opt/local/lib/python2.5/config -I/opt/local/include/python2.5
a notes about lpython2.5: I have used macports to install python 2.5 on my machine, so I know that this library exists on my system. I have a directory called: /opt/local/lib/python2.5. In fact, all of the arguments reflect the fact that I have a macports installation that includes Python. if you are on OSX, I suggest you use macports too - on Linux, try apt-get.
I remember learning about this idea of embedding an interpreter into a compiled program a long time ago - when I was a novice Tcl/Tk programmer. At the time it seemed like a confusing concept, with a lot of new strange syntax to understand - particularly with respect to getting data to and from the interpreter from the C program. This time around it was a piece of cake. I guess I've come a long way since 1998.
-- begin paste -- pytest.c --
#include "Python.h"
void exec_pycode(const char* code)
{
Py_Initialize();
PyRun_SimpleString(code);
Py_Finalize();
}
int main(void)
{
exec_pycode("print \'helloworld\'");
return 0;
}
-- end paste -- pytest.c --
Then, to compile it I typed:
cc pytest.c -o pytest -lpython2.5 -lm -L/opt/local/lib/python2.5/config -I/opt/local/include/python2.5
a notes about lpython2.5: I have used macports to install python 2.5 on my machine, so I know that this library exists on my system. I have a directory called: /opt/local/lib/python2.5. In fact, all of the arguments reflect the fact that I have a macports installation that includes Python. if you are on OSX, I suggest you use macports too - on Linux, try apt-get.
I remember learning about this idea of embedding an interpreter into a compiled program a long time ago - when I was a novice Tcl/Tk programmer. At the time it seemed like a confusing concept, with a lot of new strange syntax to understand - particularly with respect to getting data to and from the interpreter from the C program. This time around it was a piece of cake. I guess I've come a long way since 1998.
Compiling GIMP for OSX
For my thesis, at one point I thought I needed to compile the GIMP from scratch. The idea was to connect siftables (wirelessly of course) to image manipulation controls, so that a person could tweak levels, colors and other effects just by picking up different siftables, tilting them, ordering them, and seeing the results immediately.
At the time of writing it's not clear if I'll actually end up using GIMP (probably not, since it's overkill for the test I want to do) - but in any case I thought it might be useful to someone else out there who wants to compile GIMP on their OSX system. It took me a while to get my environment set up to compile GIMP successfully, not because there was all that much to actually do - but because (like most of my experiences compiling open-source programs from source), the following Three Steps did *not* result in immediate success:
./configure
make
make install
As a side-note, I think it's laughable how many README files out there report that this is all you have to do. It almost never works that way for me. If it were only that simple..... These days I compile my own programs less and less on OSX most things have a proper installer, and for those that are open-source tools I can used port. On Linux apt-get or the graphical front-end, Synaptic, provides similar functionality.
So, here's what I actually had to do on my system to get GIMP to compile:
1) Download the most recent source, and most recent patch from here:
ftp://ftp.gimp.org/pub/gimp/v2.4/
2) Un-zip it all
3) I had to make sure that I had the required image libraries.. most were there already, and for the rest, some calls of "port install" did the trick.
4) At the command-line, set the following environment variables:
export LIBTIFF=/opt/local/lib/libtiff.dylib
export LIBJPEG=/opt/local/lib/libjpeg.dylib
export LIBPNG=/opt/local/lib/libpng.dylib
(if you don't have these libs, you can use macports to install them)
5) now I could execute Three Steps:
./configure
make
6) Then, before installing, I decided to test the binary. There were a few problems:
First, it couldn't find any of its menu definitions, since it was expecting them to be in /usr/local/share/gimp/2.0/menus/. I found them in the /menus folder in the source, and copied them to the directory that GIMP was expecting.
Then, it couldn't find it tips file. I found them in the data/tips folder in the source, and copied them to the directory that GIMP was expecting.
7) I didn't actually install it in the end - just ran the compiled binary from the app/ directory after each successful compile.
Update August 6: As I mentioned in the beginning of the post, I don't think I'll end up using GIMP for the thesis, but I did learn a lot about how to configure signals and popup menu widgets in GTK+.
At the time of writing it's not clear if I'll actually end up using GIMP (probably not, since it's overkill for the test I want to do) - but in any case I thought it might be useful to someone else out there who wants to compile GIMP on their OSX system. It took me a while to get my environment set up to compile GIMP successfully, not because there was all that much to actually do - but because (like most of my experiences compiling open-source programs from source), the following Three Steps did *not* result in immediate success:
./configure
make
make install
As a side-note, I think it's laughable how many README files out there report that this is all you have to do. It almost never works that way for me. If it were only that simple..... These days I compile my own programs less and less on OSX most things have a proper installer, and for those that are open-source tools I can used port. On Linux apt-get or the graphical front-end, Synaptic, provides similar functionality.
So, here's what I actually had to do on my system to get GIMP to compile:
1) Download the most recent source, and most recent patch from here:
ftp://ftp.gimp.org/pub/gimp/v2.4/
2) Un-zip it all
3) I had to make sure that I had the required image libraries.. most were there already, and for the rest, some calls of "port install" did the trick.
4) At the command-line, set the following environment variables:
export LIBTIFF=/opt/local/lib/libtiff.dylib
export LIBJPEG=/opt/local/lib/libjpeg.dylib
export LIBPNG=/opt/local/lib/libpng.dylib
(if you don't have these libs, you can use macports to install them)
5) now I could execute Three Steps:
./configure
make
6) Then, before installing, I decided to test the binary. There were a few problems:
First, it couldn't find any of its menu definitions, since it was expecting them to be in /usr/local/share/gimp/2.0/menus/. I found them in the /menus folder in the source, and copied them to the directory that GIMP was expecting.
Then, it couldn't find it tips file. I found them in the data/tips folder in the source, and copied them to the directory that GIMP was expecting.
7) I didn't actually install it in the end - just ran the compiled binary from the app/ directory after each successful compile.
Update August 6: As I mentioned in the beginning of the post, I don't think I'll end up using GIMP for the thesis, but I did learn a lot about how to configure signals and popup menu widgets in GTK+.
