Category Archives: Uncategorized

DimensionalMap: Accelerating the heat-death of the Universe

I thought I was being clever with my DimensionalMap subproject:  bootstrapping on top of the Map object to build a multi-dimensional hashtable.  Then I started using it heavily in my Verbosio Templates subproject to implement a very customized Document Object Model in JavaScript.  With over 900 Jasmine tests passing, execution time was averaging about 4 seconds.

However, I suspected my use of DimensionalMap was unnecessary – particularly since I was working with only one dimension at the time.  So in a quick experiment, I replaced the code that used it with code using WeakMap.  Total execution time with the same tests:  about 1.5 seconds.

Ouch.  I still think the API is a good one, but clearly the implementation has issues.

Hey, kids!  Wanna build your JavaScript profiling skills?  Help me find the spots that are causing unnecessary slowness!  I’ll be happy to write a letter of appreciation for anyone who wants to take it on.  As always, the code is available under Mozilla Public License 2.0, GPL 3 and LGPL 3.  (Childhood not required for participation.)

Ars Technica: Free compiling on Windows? Forget it.

This cannot possibly be good for our developer community.  Think about it:  Visual Studio has a much more developer-friendly C++ debugger than GDB on Linux – that’s why when I’m writing C++ code, I prefer to do it in Windows.  Certainly it means many of us will be stuck on VS 2010, and Mozilla will have to support code written for before the C++11 standard for quite a while.

It wasn’t that long ago that I implemented timeouts for XMLHttpRequest.  If I’d had to make do with the VS2011 Express compiler… I’d be on Linux.

Pay-to-play sucks when it’s pay-to-make-the-Internet-better.

InterfaceChecker: Enforcing JS prototypes override correctly

I decided I had to write my own Document Object Model implementation because the models available to me just won’t meet my requirements.  That involves writing a lot of code, though, and ensuring that Element nodes, Text nodes, etc. all implement Node properties like firstChild, childNodes, etc., and methods like appendChild() correctly.

To lend a hand, I wrote a little InterfaceChecker library for ensuring that tests on a base class are run on derived classes.  (I know, JavaScript uses prototypes instead of proper classes; I’m using the concept’s meaning here.)  In principle, I need to only do three things:

  • Write tests for the Node interface’s methods and properties
  • Designate Element as inheriting from Node, and
  • Provide some functions to build “typical” instances of Element,

My InterfaceChecker will run the Node tests against the “typical” instances of Element, for example.  It’s not DOM-specific, either:  I can do the same to arbitrary JavaScript constructors, like a theoretical Shape and Circle pairing.

This code is for debugging purposes only; in my opinion, it’s a little extreme to include these tests in a production environment.

Please, let me know what you think!

A little more fastness, please? Maybe?

Over the last few years, there’s been a big movement on making Mozilla code really, really fast.  Which is wonderful.  A fair bit of this has been in “quick stubs” – specifically, optimizing how JavaScript (aka JS) code calls into C++ code.  For instance, the HTML input element has a quick stub for the value property, bypassing much of the XPConnect gobbledygook.

This post is about the reverse:  frequent calls from C++ code to JS code.  Calls like that don’t have the direct path.  They go through XPConnect.  This is understandable – JS code can do pretty much anything under the sun.  Plus, there aren’t many areas where C++ calls on JS.  The most notable spot is DOM event listeners, but again, they can do anything.

On the other hand, there are specific interfaces where the JS author is supposed to do only very simple things – or where the first few actions taken are validation (“does this event have a keyCode I care about?”).  The NodeFilter interface from DOM Traversal comes to mind.  It’s supposed to check a node’s properties and return a simple value.  A NodeFilter you pass into a TreeWalker or NodeIterator will be called for any node of the specified node types.

This is the kind of thing I look at and think, “Why don’t we get XPConnect out of the way, by having native code do the repetitive work?”  JavaScript is a glue language, where you can connect components together.  So we could use JavaScript to assemble a C++-based NodeFilter, which then gets passed into the native TreeWalker.  The purpose of this “intermediate filter” is simply to call on the JS code less frequently.

Now, I admit, node filters aren’t the most compelling case for pre-assembly.  (I have my reasons for wanting that, but they’re not common cases on the Web, I suspect.)  An event listener, though, would be more compelling.  I’d wager a native ProgressEvent listener, filtering on the readyState property before possibly executing a script-based callback, would be nice.  So would a native keypress event listener, based on keystrokes to a form control.

There’s even a bit of precedent in the Mozilla Firefox code:  the “browser status filter”.  I admit this poorly-documented web progress listener has caused me pain in the past, as it filters quite a lot… but that’s the point:  it hides a lot of unnecessary cruft from JavaScript code that frankly doesn’t care!  I also think JavaScript typed arrays are a point of comparison.

I think a few intermediate filter classes like this could have a measurable impact (ok, maybe small) on frequent calls from C++ to JS.  I don’t know if they would… but I think in the right places they could.  The major downside I can see is to readability of the code.

Opinions welcome!

“Before you load this page, do that…”

I’m still working on my prototype XML editor, Verbosio, through yet another infrastructure project.  This time, it’s through a “multi-dimensional hashtable” concept, bootstrapped from ECMAScript Harmony WeakMap objects.  You can read about my “DimensionalMap” concept and plan here.  That’s not why I’m writing, though.

When I’m working on a typical project, I’m usually alternating between three windows:

  • the browser
  • the editor
  • a shell or command prompt

That’s a little painful.  For DimensionalMap, I’m deliberately keeping the various components in different files, and assembling them together via a Makefile.  This gave me an idea:  what if a special URL could re-run make and force these files to rebuild?

First, the Makefile, which launches Firefox (given a path to the browser) with a custom profile.  Second, a custom protocol handler which I call “jasmine:”, after the very nice Jasmine test harness, which DimensionalMap uses.  This protocol handler’s sole purpose is to call make build before loading the Jasmine test page.

Effectively, that reduces me to two windows to work with:

  • the browser
  • the editor
  • a shell or command prompt

It makes a difference.  Now, if I knew how to incorporate Komodo Edit or Bespin/Ace/Cloud9 as a local file editor extension into the custom profile, it’d be down to one window.  That would be very, very nice indeed.

DimensionalMap is under MPL/LGPL/GPL tri-license.  Comments, reviews and patches are quite welcome.

Whither Amaya?

It’s been over a year since the W3C released a new version of its Amaya prototype XHTML editor.  This is not good.  I’d go so far as to call it ++ungood.  With apologies to Daniel Glazman and the many people who’ve worked on Composer-based tools, I’ve long preferred and used Amaya when it comes to writing HTML these days.  It’s had support for MathML and SVG forever, and its UI provides a lot of power without being in the way.  Oh, and it works on Windows, Linux and Macintosh… kind of like another code base I also love…

I realize Mozilla’s probably in no position to fund Amaya development, and I don’t believe they should.  I’m posting this to call attention to this project I find extremely useful, and inspirational (for Verbosio, my XML editor project).  Maybe someone out there among the W3C members or the global software community can help out a bit.

Three operating systems, three purposes

I’ve stated before that I work with Mozilla code on three different operating systems.  My desktop supports Fedora Core 15 and Windows 7.  My MacBook runs MacOS 10.6.  These three give me coverage on all three platforms.

That said, I realized a few minutes ago each system serves a different purpose for me:

  • With Fedora, I get fast compile times, especially incremental builds, and fast test execution.
  • With Windows, I get a really good free debugger with Visual Studio Express.
  • With Mac, I get portability:  I can write my code on the go.

It’s actually a pretty good situation, I think.  Is anyone else in a similar situation?

Why I’m attending college: trying to explain my thinking

A couple months ago, I started taking classes at Chabot College.  One reason is to get the degree that shows what I’m talking about.  But there’s another reason, even more fundamental:  filling in the gaps in my own knowledge.

Case in point, I’ve been thinking long and hard about building a JavaScript-based DOM.  The problem I’m facing is that to do everything I want – shadow content, undo/redo transactions, etc. – I need a specialized data structure.  Specifically, I need a data structure much like a multi-dimensional array or hashtable.

(The first dimension would be a set of object keys – the DOM nodes.  Another dimension represents undo history, like a timeline.  A third dimension could be the shadow content.  I could define other dimensions might exist for building an individual transaction until it is completed, or otherwise creating a “workspace” for experimenting.)

About 24 hours ago, I had an idea, related to my multi-part keys for hashtables implementation.  Typically, in designing a data structure class, I think about how to give each piece of data an address first, then I implement ways to store data by that address.  The idea is to flip that approach around:  to define an API that lets the user place an object with an address, and then add new dimensions to the address space as the user needs them.

If I’m not making any sense, that’s fine.  In fact, that’s why I’m writing this blog entry.  I’m having lots of trouble articulating last night’s idea formally.  I can see it crystal-clear, and I can write JavaScript to implement it, but I don’t have the language to describe it yet in English.  I spoke briefly with my Calculus instructor tonight, to figure out what area of mathematics my idea might fall into, and he suggested linear algebra (that my idea relates to vectors in some way).  Which I can’t take a class in until I complete Math 1 and Math 2 (both are Calculus classes; I’m enrolled in Math 1).  The name of the linear algebra class, at Chabot, is Math 6.

This underlines why I’m going to college after at least six years as a professional software developer.  It’s a gap in my knowledge.

Some people, like me, enter this field with a talent built upon years and years of tinkering, of experimenting and of thinking.  The software industry can really take a person like that quite a ways.  Others enter the industry having taken computer programming courses – and that’s really hit or miss for an inexperienced person.  (No offense intended to the software engineers who started through college!)

I wonder if taking up college classes after you’ve been in the industry a while is actually the best approach of all:  continuing the education, helping clarify what you’re working on and expanding the imagination with new possibilities.

I wonder how many current software engineers have decided to go back to college after being in the field a while, to push themselves and their capabilities even further.

Jarring web content?

Many years ago, the Mozilla Application Suite implemented support for a jar: protocol.  This protocol states you can refer to ZIP-compressed files inside an archive served as application/jar-archive or application/x-jar.  A typical URL would look like jar:!/test.html.  The idea is that you download one file, target.jar in this case, and your browser extracts the rest of your files from that URL.

Today, Mozilla Firefox uses it as part of how they store their user interface (omni.jar these days) on the local file system.

It’s a pretty interesting concept.  There’s been a large push in recent years towards JavaScript minification, to reduce download sizes.  This is especially true as scripts have recently ballooned to hundreds of kilobytes.  If you have a lot of JS, HTML, CSS, XML, and other plain-text files that rarely change, it might be worth putting them into a single JAR for users to fetch – you get additional compression on top of your minification, and there’s one HTTP request instead of several.

With one major catch, though.

As far as I can tell, Mozilla Firefox is the only major browser to support the jar: protocol.  This is not news.  Even Google Chrome has not implemented support for the jar: protocol.

Naturally, Firefox’s history hasn’t been perfect with the jar: protocol.  They did fix the one issue I found publicly available about it, and wrote about it on MDN. I’m not aware of any other issues, so theoretically they should be safe to use.

I’m thinking about using this capability on my website.  For my “Visualizing the DOM” series I’m developing, I have a lot of JS files that I’m using, including some library files.  Ogg Vorbis doesn’t compress so well (on a 9 minute audio I received a 1% benefit), so I won’t include that.  Alas, if I lock out all the major browsers except Firefox, I’m not going to be too happy.  The good news is that the HTML file which loads my “theater” application is PHP-generated – so based on the user agent, I can probably send the user a JAR archive (to Firefox users) or the uncompressed files directly.

Comments welcome!  Particularly if you think this is a good or a bad idea.

Welcome to my new digital home. Watch out for falling bytes.

Well, it was time.  I finally decided to launch my own web site, again.  Truth be told, I didn't even have a website all these years that I had a blog.  I didn't feel I really needed one.  Many thanks to the MozillaZine crew for hosting me all these years.

So why'd I move?  There's a few reasons:

  • I needed a home for JavaScript demos, and free blogs just don't cut it for that.  (Which is why I didn't end up at
  • I've been playing with WebGL a bit, and HTML 5 Audio.  Fifteen seconds of Ogg Vorbis audio is around 200 KB, even for just speech! When I want to do five minute shows, that's a non-starter on a free blog.
  • To be honest, I've been a bit of a cheapskate, too. The free ride had to end sometime.

I've also gone ahead and purchased HTTPS hosting. Why? Admittedly, it's overkill. But at the same time, I want you to know that the files on this site are coming from me. In particular, I want people who don't trust the Web (NoScript, anyone?) to trust me. This really is just a personal site for me, to showcase my public works of Web technology.

Yes, Verbosio, my prototype XML editor, is the main focus of those works. I'm considering moving it over here, as it never really was a good fit with MozDevGroup's aim of supporting extensions. (Mine's a full-fledged vaporware application.)

Speaking of WebGL, I've got a cheap prototype demonstration of circles in 3-D space going. Don't ask me why the circles are a little flattened. I'm hoping someone out there can tell me why. It's all leading towards a series of presentations I'm calling “Visualizing the DOM”, and the first installment's coming soon (probably in a month or less).