Sunday, January 25, 2009

JSHydra

Over the past week or so, in between my myriads of projects, I managed to find time to revive a partially-completed tool called jshydra (properly capitalized as "JSHydra"). JSHydra, in both name and code, is derived from Dehydra and Treehydra: it is a static analyzer for JavaScript. I first decided that such a tool was needed when I was in the middle of a large refactoring of address book code.

The source code for jshydra can be found at my Mozilla user hg repo. Presently, it requires some hackery and file modifications to merely build the system. I use SpiderMonkey internal APIs (the parsing APIs, to be exact), so that's where most of the hackery comes into play.

For the time being, I'm probably going to put aside doing more work on jshydra, as I have more pressing work on my plate at this time. If you have any questions, feel free to contact me via IRC (handle: jcranmer (I should be in #mmgc)) or via my email address as listed in bugzilla.

Tuesday, January 20, 2009

My other life

I have just opened up a new blog covering those topics that are not oriented towards my work with Mozilla or other similar technically-oriented projects.

Tuesday, January 13, 2009

Eight things you didn't know about me

Apparently it's my turn for these meme, according to taras. Oh yes, and KaiRo too. The rules:

  1. Link back to your original tagger and list the rules in your post.
  2. Share seven facts about yourself.
  3. Tag some (seven?) people by leaving names and links to their blogs.
  4. Let them know they’ve been tagged.

So let's get this show on the road! Eight things you didn't know about me (why eight? Because I like to go one step further):

  1. When I was tested around first grade, my auditory processing skills were rated as "retarded." Possibly related to this fact, I was apparently deaf or near-deaf at the same time, and I'm still rather poor with auditory processing to this day.
  2. I nearly flunked 7th grade biology but got the second-highest grade in my 9th grade biology class, I believe averaging over 100%. Indeed, I probably still recall large hunks of biology although biology is my least favorite core science and I wish I could forget it.
  3. Despite having a high school GPA of 3.99 (where the best grade is a 4.0, and AP credit adds 0.5 to the final grade), the first time in my entire life that I achieved a perfect 4.0 was my first semester of college. My grades have often been littered with scores that just make the next grade level, such as a 93.52 in one year of French, or a 89.50 in Psychology.
  4. Nearly all of my programming knowledge I taught myself. The only languages I learned as part of a class were (in order) Python, FORTRAN, and Smalltalk. All other languages (roughly speaking, Java, C/C++, x86 assembly, PHP, bash scripting, awk, sed, etc.). I taught myself before any courses that used them taught it to us. One day, for Senior Switch Day (a high school tradition), I taught a Computer Architecture lecture covering, in order, how vtables are implemented in gcc, how to use setjmp and longjmp for exception handling, and how to write a stack walker in C. And yes, I do know that I'm going to hell for using setjmp and longjmp.
  5. In 7th grade, I tied for 10th place in the state for the Mathematics League. I personally know 11 of the other people who did at least as well. One of those people I actually referred to earlier in this post. And it's not Haitao.
  6. I was once in a fight in 7th grade. The fight happened like this. Step 1: I was knocked into a bench in a locker room. Step 2: I was knocked over this bench into the lockers in same locker room. Fight over. I don't think I actually bled, but it hurt, IIRC.
  7. For my senior prom, I went with four girls, for a definition of "went" more exclusive than "went in the same dinner/limo group" (there were actually around 12 or so girls in our group). Incidentally, all four girls were Asian, which is fairly representative of the ethnic makeup of my high school (or at least among those I knew).
  8. Because of my speech impediment (or so I've heard), I've been fairly often asked if I'm British. Technically speaking, it's not a lisp—my problems are with r's, not s's. I wonder if people here think I sound British (I certainly don't)?

Time for poking people:

Gary Kwong
Fellow intern and bug triager, I wonder what he's done.
Siddharth Agarwal
His blog has been pretty empty.
David Bienvenu
He needs the excuse to blog.
Jesse Ruderman
For finding so many typos in my blog postings.
Shawn Wilsher
mozStorage writer, and one with whom I've spent some time trying to debug a TB news problem…
timeless
Because…he's awesome?
Saul (whose blog is inaccessible)
Because it doesn't take a computer scientist to know the problem with pyramid schemes.

Hey look, I got through the entire post without mentioning demorkification! Oh cra—

A problem with feature requests

Among many of my secret lives, I personally follow several mailing lists, newsgroups, and technology updates for reasons beyond the scope of this posting. I follow the WHATWG mailings list somewhat closely. One issue that has been raging quite ferociously recently was whether or not to include RDFa, eRDF, RDF, or whatever into HTML 5.

Many of my readers, especially those for whom RDF is immediately associated with cumbersome, inflexible APIs that should be rid from programs, are probably wondering why one would want to include such a specification into HTML 5. Don't worry, you're not alone. Even Ian Hickson, the editor of the HTML 5 spec, is having problems trying to figure out why. To whit:

One of the outstanding issues for HTML5 is the question of whether HTML5 should solve the problem that RDFa solves, e.g. by embedding RDFa straight into HTML5, or by some other method. Before I can determine whether we should solve this problem, and before I can evaluate proposals for solving this problem, I need to learn what the problem is.

A bit of context: earlier in 2008, there was a previous thread about RDF measuring well in excess of 100 messages. Being a good editor, Hixie asked in this message about what problems it was trying to solve. The response? Seventy-three email messages, most of which promptly ignored the issue. Many sub-discussions centered around things such as quality of search engines, how it should be implemented, etc. The idea of trying to figure out why people should use it got lost in the wind.

And to me, this signifies a problem. One of the most important questions when deciding whether or not to include a feature is why. And it seems to me that this question is the one that is least pondered by proponents of new features. The answer is often some variant of "it's obvious" or a description of what the feature does. The last bit is like trying to answer a question of "Why do you want to put a door in the wall here?" with an answer "Because we can have quicker access to the other side of the wall." At first glance, it's acceptable, but in reality, it doesn't justify the feature (why then, do you want quicker access?).

There are more instances where I've seen this. One of them that aggravates me the most is the proposal to include closures in Java. There are several conflating issues in the entire controversy, so here's some background. There are three proposals for closures: CICE (usually with ARM included), which really isn't a closures proposal, more of a "let's decrease anonymous inner class verbosity;" FCM, a "lite" version of closures which basically just makes methods first-class objects, and BGGA, which is full-blown closures support. By now, when people refer to a closure proposals, it's the full BGGA closure; FCM has all but disappeared, and CICE+ARM is generally only mentioned as a compromise opportunity.

The BGGA proposal can be viewed as roughly comprising three parts. The first is the idea of function pointers, the second is the ability to convert a function pointer to an interface so long as the interface has a single method and the function signatures match, and the third is (in a nutshell) the ability to create control structures. I have seen a lot of valid arguments on both sides for the first two portions, but the third portion still mystifies. Yet it is this third part which truly differentiated BGGA from FCM, and it is there where almost all of BGGA's complexity comes into play.

Just one catch: Why do you want or need the ability to create control structures? One control structure almost invariably pops out: the with construct, or (in other words) syntactic sugar for a try { ... } finally { ... } block. This is where the ARM portion of the CICE proposal comes in—it would add the only construct desired by any sizable amount of people. Okay then, that's one, how about another? And therein lies the problem. It's hard to come up with other examples. Proponents always mention the with and assume that everything else is evident. For something that is definitely going to increase complexity and difficulty in programming greatly (e.g., return 5 would behave differently, in some cases, than return 5;), you better have more than one, easily manually-addable use case.

Another problem is underestimation of what it takes to include a feature. A 16 MB extension for a 6 MB program is completely untenable, so let's include it into the 6MB program! How about introducing multiple tokens as a CSS unit token (think about it for a moment...)?

The final thing that irks me with feature requests is the importance with which people attach. The news that Java 7 will definitely not be containing closures (adding a complex, controversial feature to a specification already behind schedule isn't exactly tenable) seems to have been treated with proclamations that Java is dead or that it will die as a result. I somehow can't imagine that millions of Java programmers will suddenly switch because Java won't have closures—indeed, no programming languages ever in the Top 5 have ever had closures.

Similarly, the announcement that JavaScript had been disabled in trunk Thunderbird builds for email was met with a few vocal opponents complaining (I don't know of any non-Mozilla product that ever had support for JavaScript in email to begin with). And most of my readers are no doubt aware of the furor that removing MNG support caused.

Sunday, January 4, 2009

News submodule roadmap

It's the new year! As the owner of the NNTP submodule of Mozilla Mailnews, let me lay out a rough roadmap on what I seek to get done on the submodule for some time to come.

For Thunderbird 3 (and SeaMonkey 2.0, of course), the ability to filter on any header is probably in and of itself sufficient to make people happy. The only other change I think reasonable to make it into 3.0 is making get messages actually get messages. More substantive changes will have to wait for later.

For 3.next, I think the most important thing to tackle is news URIs, as they are incredibly broken for most practical purposes. High importance is ensuring that news://<server>/message-id and news://<server>/group are usable via external protocol handlers and command line. Making server-less URIs work would also be delightful.

Also important to me is more protocol support: AUTHINFO SASL, STARTTLS, and CAPABILITIES in roughly that order. While I'm at it, I'll also clean up some of the cruft surrounding nsNNTPProtocol. I would also like to have a lot more comprehensive tests for 3.next.

What's not on my plate is more binaries support. Specifically, I'll not be working on combine-and-decode (as useful as it is in general). Offline love I think will have to wait for 3.next.next before I can find some time to work on it.

Finally, I'd like to get all of the news bugs neatly triaged into categories. As of me writing this message, I count some 150 bugs in the Networking: News component, and I'm sure there are a few more bugs floating around in other components that I haven't found. I'd like to remove dupes and categorize all of these into specific categories (at least locally). And, more importantly, remove the cruft of these bugs. Many of the NEW bugs should be UNCO because no one ever really confirmed them.