Posts in "Software"
XML Namespace Selectors for jQuery
I hit my first real roadbump with jQuery yesterday, a missing feature that really made me stop and stare in puzzlement: jQuery doesn't support xml-namespace selectors. Since I'm trying to parse WebDAV response bodies, and such documents make extensive use of namespaces, it's quite the issue for me. Or rather, it was quite the issue – read on if you're interested in the details, or just download my solution if you're impatient.
Oh sure, jQuery supports prefix selectors just fine. If your document contains an element <D:response>, you can quite safely query for that element by name as long as you remember to backslash-escape the colon:
$(doc).find("D\\:response")
This works as long as you can guarantee that a single prefix is used for the target namespace, and that it's used uniformly throughout the document. But the XML Namespaces standard, as well as the WebDAV standard, make it very clear that you can't rely on this in general. The node name prefix is a purely syntactic construct, while its actual namespace is a semantic property that can be specified in several different ways.
Fortunately, the CSS Level 3 standard provides a very clear syntax and semantics for namespace-aware queries. After declaring 'D' to be the proper WebDAV namespace URI, the CSS-3 equivalent to the above prefix query would be:
Just a quite note to mark an updated release of filelike. Version 0.3.2 offers a lot of small robustness fixes and many new unit tests, much improved support for files opened in append mode, and a new filelike wrapper "FlushableBuffer" for buffering streaming reads/writes so they can be treated like a random-access file.
This library forms part of the backbone of a new project I'm working on, so expect to see more frequent releases over the next few months.
My long-standing obsession with Mozart/Oz is no secret, but I often find it difficult to articulate precisely why I'm so fascinated by the language. I never seem to make much headway by describing the power and elegance of its novel control structures such as first-class computation spaces – which, by the way, I would rank right up there with continuations on the list of "language features that sound useless but are actually incredibly powerful"...but instead of going down that esoteric road, let me demonstrate a short and eminently useful little hack that I put together last week, one which really highlights the power of the Mozart platform.
First, a brief primer on one of Mozart's great strengths: distributed programming. If you have remote access to a computer with Mozart installed, it's very easy to move some of your computational workload onto that machine. Here's a short Mozart script that uses the remote computer "guava" (the computer hosting this website) to calculate 1000 factorial:
% Wrap the target code in a functor F = functor export result:Result define fun {Fact X} if X < 2 then 1 else X * {Fact X-1} end end Result = {Fact 1000} end % Spawn a new Mozart instance on the remote machine R = {New Remote.manager init(host:guava fork:ssh)} % Have it execute the functor, and print the result Res = {R apply(F $)} {System.showInfo Res.result}
Following my previous post on testing Django with Windmill, I quickly ran into a common snag with in-browser web app testing: it's not possible to programmatically set the value of file input fields. This makes it very difficult to test file upload functionality using frameworks such as Windmill or Selenium.
In Firefox it's possible to request elevated permissions for your unit tests, but this is far from ideal. It means the tests are no longer automatic (you have to click "yes, grant this page extra permissions" whenever the tests are run) and it takes other browsers out of the testing loop. Like many things in life, the easiest solution seems to be simply to fake it.
But like any convincing fakery, the details are never that simple in practice. Uploading a big file from a web browser will take a long time, but could be nearly instantaneous if you fake it using a server-side file. And what if you have custom upload handlers to enable things like upload progress reporting? How can we make fake file uploads as transparent and convincing as possible?
Troubleshooting Remote Connections in Mozart
The Mozart/Oz programming language provides a comprehensive distributed programming subsystem, and when it works, it's a thing of great power and elegance. But when it doesn't work, it tends to fail out with error messages that are exceedingly unhelpful. This is particularly troubling if you're working with a high-level abstraction such as Parallel Search – the error messages are far removed from the code that you're actually writing.
Inspired by a recent request for help on the mozart-users mailing list, I've decided to compile a quick troubleshooting guide for Mozart remote connections. And when I say "quick" I really mean it - there's only two steps but they can solve a lot of common problems with getting the distributed programming subsystem up and running.
Step 1: Ensure remote processes are forked correctly
This step is actually quite well documented in the Mozart documentation on the Remote module. However, that's a pretty obscure corner of the documentation for someone wanting to work with higher-level abstractions, and the necessary steps are buried in a long discussion of the underlying mechanics of the remote forking mechanism. Below is the quick-and-dirty version of what you need to know.