Picture a Mozilla geek standing on the shoulders of another to reach an electric outlet in the ceiling, then expecting to be returned to firm floor and instead being shuttled elsewhere to the reason of "one more outlet to gooooo!". (Note: this post is also available in Italian on xulit.org)

Picture a Mozilla geek standing on the shoulders of another to reach an electric outlet in the ceiling, then expecting to be returned to firm floor and instead being shuttled elsewhere to the reason of “one more outlet to gooooo!”.

(Photo credits: William. Complete photoset here.)

Picture the chatty signora who serves drinks and panini at the bar, getting asked tens of chairs first, then an old knife to be used as a screwdriver to assemble fans (no, not the human variety), then rags to clean above said chairs retrieved from the basement from above said geeks. Picture her respond with more lively chatter instead of increasing threats to kick us out.

Picture two guys who never gave a presentation together bantering/negotiating on stage, much to the audience’s amusement, which slides to skip to make time for an unplanned but ubercool presentation. (Of course I was right most of the time but Luca was tougher. )

You might think by now that the Mozilla Add-On Workshop had more than a bit of adventure in it, but our men in Florence Giacomo and Iacopo (from Mozilla Italia) as well as the headquarter agents Paul and William (from Mozilla Europe) plowed through every obstacle and got us safely to the heart of the workshop: an introductory talk on Firefox extension development, a hands-on tutorial, and a short finale on the tricks of the trade.

Despite many rough edges and a wealth of non-obvious material to cover (we went from zero to a Twitter-search extension to interactive development in less than three hours), almost fifty people gave us full attention and support, which is a testament to the rising interest on the subject in this country (or to the seldom sung quality of Italian patience (or both)).

Courseware is available: slides, incremental examples on building an extension, samples of “unusual” (if you’ve only done web development so far) JavaScript.

If you were there and your questions went unasked or unanswered because of time or because you couldn’t hang out afterwards; or you want us to keep you in the loop about this Fall’s initiatives; or you just want to say hi, feel free to get in touch with us or leave a comment here or on the Italian version of this post.

Happy extension hacking!

Four lines of Lisp, a little hack and a function theft from w3m.el later, something pops up in an Emacs buffer... After providing a Lisp-like facility for interactive development to Firefox, it was only fair for the cute panda to return the favor and lend some rendering power to Emacs.

Four lines of Lisp, a little hack and a function theft from w3m.el later, something pops up in an Emacs buffer…

It is, of course, just a proof of concept. No, I don’t have the time to develop it further. Yes, I’ll treat you to several rounds of Belgian beer if you do.

Here's a practical application that turns Firefox into a screenshot server. It lets you request e.g. http://localhost:4242/screenshot/http://en.wikipedia.org and receive a PNG screenshot of Wikipedia homepage. (Instructions to run it are at the bottom.)

Features and things to note: In October I introduced custom interactors and someone asked what can be done with them other than application inspection.

Here‘s a practical application that turns Firefox into a screenshot server. It lets you request e.g. http://localhost:4242/screenshot/http://en.wikipedia.org and receive a PNG screenshot of Wikipedia homepage. (Instructions to run it are at the bottom.)

Features and things to note:

• Every page is loaded in a new tab, meaning that multiple screenshots can be requested concurrently.
• You can have MozRepl listen to outside requests and thus have the server run on a machine (or machines) other than the one requesting screenshots.
• Adding .../pdf/http://en.wikipedia.org, .../postscript/http://en.wikipedia.org, .../getmail/http://mail.google.com?user=foo&password=bar, and so on, shouldn’t be too hard.

This is no finished product but it should give a hint of the possibilities. Known issues: since it takes the screenshot upon DOM load event, pages that use the same event to build sizeable portions of the document (such as iGoogle) might turn out incomplete or just white. Also, Firefox 3.1 seems to hang when the same browser instance is both the requester and the receiver of the screenshot (ok, not the most useful scenario, but still).

To try it:

1. Get MozRepl, whether devel or stable branch doesn’t matter.
2. Copy the source of the screenshot server to a file (e.g. /home/foo/mozrepl-init.js)
3. In about:config, set extensions.mozrepl.initUrl to the URL of that file, e.g. file:///home/foo/mozrepl-init.js. (This file gets read whenever a new MozRepl session is started.)
4. In about:config, also set extensions.mozrepl.defaultInteractor to “screenshot”.
5. Select Tools → MozRepl → Start from the menu to start MozRepl.
6. Point wget (or curl, or another browser) to Firefox with:

    $ wget http://localhost:4242/screenshot/http://en.wikipedia.org 

Update 2009-06-16: Adam has an HTML-to-PNG server with an improved version of the interactor.

• Link to your original tagger(s) and list these rules in your post.
• Share seven facts about yourself in the post.
• Tag seven people at the end of your post by leaving their names and the links to their blogs.
• Let them know they've been tagged.

That said... I tried to pretend I didn’t notice but when tag count reached four it became difficult. So here’s my “seven facts”. But first, the Rules:

• Link to your original tagger(s) and list these rules in your post.
• Share seven facts about yourself in the post.
• Tag seven people at the end of your post by leaving their names and the links to their blogs.
• Let them know they’ve been tagged.

That said…

1. I’m not fanatic about optimizing code but I’ll shave every gram I can out of my baggage. Current target is a single 6kg (down from 8kg) carry-on bag for trips of indefinite time.
2. I hate being woken up by the alarm at 10:00 and love being woken up by sunlight at 5:00.
3. I’ve been a computer geek for two thirds of my life but a programmer for “just” one. What got me started on programming was building harps. (Yeah, the musical thingies.) You can go with paper calculations when making a violin (four strings) or a guitar (six), but mis-designing half a hundred strings in a harp means either a floppy sound or a very loud one… when the instrument implodes. Sometimes you really want a computer to help out.
4. I sleep on a tatami mat and walk barefoot whenever I can. For some reason small disconnections from the ground bother me much more than serious ones.
5. I’m one of the six Italians who rarely drink coffee and don’t care about soccer.
6. I know a better answer than 42.
7. I don’t like the N-things meme because I’m always at a loss when I get to the nth-thing.

And here are my victims:

1. Don, because he invited John Gilmore for a talk on the day I was leaving for a vacation, and this is my way of punishing him.
2. Peter, because he’s proof that being a superstar and an incredibly nice guy is possible.
3. Irakli, because it’s like looking back in time.
4. Simone, who knows the art of making people feel welcome.
5. Paolo, because I haven’t spoken to him in ages.
6. Oleg, because people like him is the best that can happen to an open source community.
7. Luke, because he has no clue how much of an influence he is (if I end up trying unicycling, you know whose fault it is).

If you, dear Reader, who have stoically endured my writing so far, are coming to the event, please leave a comment or send a mail, I'd certainly like to meet you for some important algorithm implementation. Only three days left before FOSDEM!

If you, dear Reader, who have stoically endured my writing so far, are coming to the event, please leave a comment or send a mail, I’d certainly like to meet you for some important algorithm implementation.

(Flashback: MozRepl is an interactive shell for Firefox and other Mozilla apps. You connect to Firefox with telnet or similar, type some JavaScript code, and it gets executed on the fly.) First guy: “So how would an object inspector look like in MozRepl?”

(Flashback: MozRepl is an interactive shell for Firefox and other Mozilla apps. You connect to Firefox with telnet or similar, type some JavaScript code, and it gets executed on the fly.)

I patiently explained how a command line inspector would look like. More or less like:

First guy: “Well, and how do you get this in MozRepl?”

I (im)pantietly explained that there was no inspector yet.

First guy: “Why not?”

I (im)patiently…

Second guy, out of nowhere: “Yeah, why not?”

You know that you’re in trouble when even the nicest guy in the place teams up to nag you.

Then I spent some time not to write an inspector, but to make it possible (and easy) for third parties to write new interaction modes for MozRepl, so that the onus of writing the damn inspector would be on the above guys. (The best thing you can do with challenges isn’t winning them, it’s turning them upside down.)

However things quickly got fancier while I explored, because the same request/response pattern interactive interpreters are built around is common to a lot of applications. Object inspectors, sure. Even text adventures (“You’re in a dimly-lit browser, surrounded by menacing angled brackets and curly braces”).

But also HTTP.

One custom interactor later, there it was: Firefox understanding HTTP and browsing itself.

Where to go from here? Once there’s a halfway decent implementation of HTTP (hint: mine isn’t), you may be able to drive Firefox with XML-RPC, JSON-RPC, REST-style manipulation of resources, and who knows what else. (Oh, yeah, I guess server-side long-timers in the audience will know what-else very well.)

Support is available in the new stand-alone MozRepl package. To try out the http-inspect mode, just go to about:config and set the “extensions.mozrepl.defaultInteractor” pref to “http-inspect”, then point the browser to http://localhost:4242. Documentation on how to write custom interactors is on the wiki.

Credits to Sergi for coming up with the “metabrowsing” title!

In the (real) synchronous world, error conditions used to travel on the same road as return values: Last time we saw how to transfer results of computations from pseudo-blocking calls back into the main process. What happens if when something goes wrong, though?

In the (real) synchronous world, error conditions used to travel on the same road as return values:

    char *foo;
    foo = doSomething();
    if (foo == NULL) {
        error("can't get foo");
        exit(1);
    } else {
        doSomethingElseWith(foo);
    }

Then someone realized that error handling and the real task would better not be intertwined, or the general sense of the latter might become less and less clear. After all, errors were, er, the exception, not the rule, and might best be handled in a parallel world that veery now and then resurfaced, but not in the middle of nice-looking, expressive code.

    try {
        var foo = doSomething();
        doSomethingElseWith(foo);
    } catch(e if e == NoFooException) {
        error("can't get foo");
    }

Normally, asynchronous code in JavaScript puts us back in the first scenario, although we don’t get the result/error through a return value but as a function argument:

    var req = new XMLHttpRequest();
    req.open('GET', url, true);
    req.onreadystatechange = function(event) {
        if(req.readyState == 4) {
            if(req.status != 200)
                error('Something went wrong!');
            else
                doSomethingWith(req);
        }
    };
    req.send(null);

Turning it into pseudo-synchronous makes things only a bit better. The error comes through a return value and we deal with errors exactly as in the first scenario:

    function getUrl(url) {
        return function(driver) {
            var req = new XMLHttpRequest();
            req.open('GET', url, true);
            req.onreadystatechange = function(event) {
                if(req.readyState == 4)
                    driver(req);
            };
            req.send(null);
        }
    }

    var driver = proc(function() {
        dump("Retrieving URL...\n");
        var req = yield(getUrl('http://hyperstruct.net'));
        if(req.status != 200)
            dump('error!');
        else
            dump(req.responseText + '\n');
    });

    driver();

What we want, though, is to make use of the exception “channel”, for the reasons given above: separating description of the task from description of what to do when something goes wrong.

It takes some extra load in the process definition that hopefully isn’t too hard on the eyes:

    var driver = proc(function() {
        try {
            var result = check(yield(
                errorProneFunction()
            ));
            dump('Success! ' + result);
        } catch(e) {
            dump('Something went wrong   ' + e);
        }
    });

    driver();

Implementation of check() and changes to the process driver are trivial:

    function check(obj) {
        if(obj instanceof Error)
            throw obj;
        else
            return obj;
    }

    function proc(processDef) {
        var process = processDef();

        function driver(value) {
            try {
                var pseudoBlockingCall = process.send(value);

                try {
                    pseudoBlockingCall(driver);
                } catch(e) {
                    driver(e)
                }
            } catch(e if e == StopIteration) {

            }

        }

        return driver;
    }

• The inner try...catch inside the process driver catches exceptions thrown from pseudo-blocking functions, and passes them back to the process as if they were values, so they will be returned to the caller of the pseudo-blocking function.
• check() receives yield()‘s return value. If it’s an exception, it throw()s it (thereby sending it across the usual exception channel), otherwise just returns the untouched vaule.
• An extra try...catch in the process driver lets it ignore the StopIteration exception—we won’t go into that here.

The example below, relying on the revised implementation of proc(), shows that exceptions thrown synchronously in a pseudo-blocking call can be caught and exposed within the process:

    function errorProneFunction() {
        return function(driver) {
            throw new Error('Something went wrong!');
            driver('Some other value for correct computation');
        }
    }

    var driver = proc(function() {
        try {
            var result = check(yield(
                errorProneFunction()
            ));
            dump('Success! ' + result);
        } catch(e) {
            dump('Error.   ' + e);
        }
    });

    driver();

Exceptions can be thrown by the asynchronous part of pseudo-blocking call, too: just pass them as argument to driver() where you’d normally pass the result of the computation:

    function getUrl(url) {
        return function(driver) {
            var req = new XMLHttpRequest();
            req.open('GET', url, true);
            req.onreadystatechange = function(event) {
                if(req.readyState == 4) {
                    if(req.status != 200)
                        driver(new Error('Non-success HTTP status!'));
                    else
                        driver(req.responseText);
                }
            };
            req.send(null);
        }
    }

Articles in this series:

1. Part 1: Problem and basic solution
2. Part 2: Execution dissected
3. Part 3: Returning values
4. Part 4: Error handling