One of the things that's been annoying me about JavaScript recently is the inability to only catch certain classes of exception, as in Java or Python, for instance. The try {..} catch(e) {..} block has always seemed too inclusive. But recently Ash found a crazy syntax in SpiderMonkey that lets us only catch certain exceptions.
try {
// something that can throw
} catch(e if e.bar == 'foo') {
// an error is only caught here if it has a 'bar' property of 'foo'
} catch(e if e.bar == 'baz') {
// there can be different catches for different conditions
} catch (e) {
// otherwise it's caught here. Without this block, the error would fall
// through the 'try' and be re-thrown.
}
I haven't bothered testing this in Internet Explorer (or any other web browser for that matter), because I'm only interested in server-side JavaScript execution at the moment. It works in at least recent SpiderMonkey CVS and Rhino 1.6r6, not sure about earlier versions.
Ash Berlin and I recently hacked together an Apache module that embeds the SpiderMonkey JavaScript engine and lets you run JavaScript code on the server as CGI scripts. We called it mod_js.
It was written as a proof-of-concept module at the last Fotango hack-day - Ash and I used my ancient mod_tt as a starting point and had a module capable of printing to the client in about 4 hours of work. Not bad. See the mod_js project page for the source code, examples and build instructions, if you want to have a look yourself.
Right now in mod_js you can print output to the client, and access CGI parameters in the incoming request. There's no filesystem access or database access. This leads me to a dilemma. I feel there's use in a stand-alone server-side JavaScript programming environment, but heavier ones than this exist already. Faced with having to re-implement the entirety of the Perl DBI layer, TCP/IP networking, disk access, etc, etc, with all the associated security problems that will happen, I'm forced to consider mod_js somewhat of a dead-end. It would probably be much more useful implemented as a mod_perl module using the Perl SpiderMonkey bindings to embed JavaScript, so I could use all the existing Perl infrastructure to support my scripts. It would be heavier, but there will be more hosting companies offering mod_perl than are willing to compile new Apache modules, or it could be run as a stand-alone daemon more easily than something written in C.
Given all of this, mod_js is still a nice proof-of-concept, though, and could be turned into a real server-side programming language. I also quite enjoy working in C every so often. It reminds me why I don't do itmore.
Last weekend, I was at hack day London, and I'm only just getting around to mentioning it here. ChrisGarethMirona and I made Twitup - it lets you comment on in-progress TV using twitter, extracting the channel name from your message and assigning it to whatever's on at that time. In theory.
It's written in Perl and built on Catalyst, which I haven't touched in quite some time, but is still tremendously easy and fun to use. (We were going to built it on rails, but then it turned out that none of us had any idea how. So we used something we understood..)
I've moved the DjangoKit source and documentation (such as it is) into Google Code at the request of Rob Hudson, so other people can work on it. Other people? Work on my code? Crazy.
More Google Earth / Dopplr stuff - this time it's an overlay of planned trips. Your planned trips, in fact, which isn't terribly useful, but it's a new API, and I'm hopeful that I'll be able to do overlays for everyone you have data for. Then I need some way of establishing time data, or something. Plans, plans, plans.
I’ve been wanting to use zimki to make a Google Earth KML file for some time now - not for any particularly good reason, mind, it’s just that Zimki is good at XML and Google Earth is fun technology. I just haven’t had an idea worth building till now. Then dopplr turned up, with its lovely geographical data and data on fellow travelers exposed in a simple XML format, and I had my project.
The next thing I’d like to do is expose information about the home cities of the travelers, to indicate people away from home, or perhaps an arrow to where people are going next. Any useful ideas?
DjangoKit suffered a hiatus recently due to a non-anticipated
hot beverage/keyboard intersection incident, but recently I've been able
to poke at it again, and I have it in a much more flexible state now. Although
the code itself is still scary and horrible, and I'm abusing distutils in
a way that'll get me into trouble soon, it's now installable. Once installed,
it can be used to turn any stand-alone Django application into a MacOS .app.
The best way of demonstrating this is with one of the two examples I
have in the source tree. The TODO application is utterly trivial, and
consists of only a model definition, an url dispatcher, and a template - I
use generic views to look at the todo items, and the admin interface to edit
them. I can now put a setup.py in the app folder with minimal application
information, and run
python setup.py py2app
And produce an application. The other example was built after I had this
working - it's based on the wiki written by Paul Bissex that he was
kind enough to point me at in the comments on the last DjangoKit blog post.
The app itself needed tweaking slightly, but not for any DjangoKit-specific
reasons, and now I have a setup.py that turns the wiki into an application.
The response to the first release of the thing was interestingly mixed.
Some people were very enthusiastic, others either don't see the point
of, or actively dislike, GUI applications written using HTML frameworks. I
think that, if I had to make a call, I'd be in the latter camp - there's a
reason all my other GUI apps are written in PyObjC and not, say, wxPython.
I lose lots of portability, I gain much nicer-feeling apps. I just wanted
to know if I could do it. And it might come in useful for something..
Update (2007/04/13) - DjangoKit got better since, you know. But everyone keeps linking here for some reason...
DjangoKit is a framework that will (eventually) allow me to package just
about any Django application as a stand-alone MacOS .app. I've been noodling
with the concept for a while now, but I was finally motivated to do something
after I saw Slingshot and started reading about Apollo and
related technologies. I've tried using Ruby and Rails, and tried again as a result of seeing Slingshot, but I really don't enjoy it. I'm a Python
person, and most of my personal projects (including jerakeen.org itself)
are written in it, so it seemed like it would be easier to re-implement the interesting parts of Slingshot as a PyObjC app than re-write everything I care about in Rails. Also, I'm weird.
Like slingshot, the built .app gets a local (sqlite) database that works offline, but I'm not thinking at all about sync with a remote server. It's an orthogonal problem that can be solved later. I also don't care about non-mac users right now. Lots of the hard bits of the code are in the bundling system, and should be convertible into py2exe rules, so I won't rule out doing the same thing for Windows, but this is a personal project, and I'm a mac weenie this month, so if you want it, you can do it. Likewise linux.
It's early yet - I've only really spent a couple of days hacking on it - but I have a downloadable demo available - it's an utterly trivial application, but demonstrates Django with a model, a generic view and a template, as well as the admin site that Django provides magically. The demo app source code is avaliable if you want to see how trivial the app is, or you can get the entire thing as source - both from my subversion repository. I'm not promising the thing will build for you, though. You'll need PyObjC, Django and pysqlite2 installed, and they mustn't be installed as eggs. Running setup.py the first time will generate a local database.sqlite with the tables for the app model. I haven't solved the schema upgrade problem yet. :-)
The code is almost entirely nasty hacks, so beware, but it should be possible to clean it up and produce something more elegant. Eventually I want to be able to turn just about any Django application into a Mac application by writing a small config file describing it, but right now you should be able to ship your application by:
editing theproject/urls.py and adding a dispatcher for it
add the package name of your project to the packages line in setup.py
make sure your app is in your python library path
delete the local database.sqlite (so the models are regenerated)
Run python setup.py py2app
If you need media files shipped, try putting them in ./media, and they'll be bundled with everything else, but this isn't so well tested. The first time you run the app it'll copy the database into ~/Application Support/DjangoKit/appname so you'll also need to clean that folder out if you change the model.
