Dysfunctional Programming

Nine days ago, I made an off-hand remark in #content that I might be able to get the geolocation service working in Fennectrolysis by the end of the day if my plans worked out. I also remember referring to the process as “not a big deal.” Since that moment, I have put in a significant amount of work (at least several hours every day), and learned:

• My estimating skills are severely underdeveloped
• How to make use of the cycle collector
• How weak references work
• Best practices for XPCOM reference counting
• There’s a confusing thing called nsIClassInfo which I should learn more about, but I know enough to force it to do my bidding for now
• How non-modal prompts work
• The meaning of obscure GCC linker errors like “undefined reference to vtable”
• How to implement an XPCOM object in Javascript
• Implementing XPCOM objects in Javascript frequently results in much more pleasant code than C++

Having said all that, yesterday I got the Fennec geolocation permission prompt to appear when triggered by a content page, and the proper callback was called when I allowed or canceled the request, so I’m confident that I can have a patch up for review by the end of the holiday weekend. Of course, given my track record, that means it might be up by the end of the week.

You’re looking at a mind-bogglingly alpha Jetpack prototype running out of process. Yesterday was a black triangle moment for me, as I finally saw the culmination of 2.5 months of work to make the words “Gmail it” appear in the status bar.

In this implementation, when a Jetpack tries to do something that doesn’t really make sense in its own process (say, adding an element to the status bar), it proxies this operation to the chrome process and continues on its way. Theoretically this allows the main chrome to focus on important things like being responsive or not freezing, so the main work of running Jetpack scripts can be delegated to another process.

There’s lots and lots more work from here (for example, clicking “Gmail it” does nothing for various reasons I need to explore), but this inauspicious screenshot demonstrates that the out of process future is alive and kicking!

I realize that while I’ve been contributing to Mozilla since last July, I’m still quite new to a lot of the process and knowledge that more experienced developers take for granted. Therefore, I’m going to document the steps I’ve taken to increase my understanding and involvement in hopes that it generates some discussion on the best way to help new people get their bearings.

One of the most inviting aspects of the project right off the bat was that I had a point of contact. Benjamin Smedberg announced in a blog post that the Electrolysis project could always use more help, inviting interested people to get in touch with him. This was an immense help, as he pointed me towards a really good introductory bug that forced me to explore and learn about IPDL, IDL, XPCOM, Javascript, the build system, and more. This was perfect for me; I’m always looking to expand the horizons of what I know, and my work hooking up e10s with the typeaheadfind component allowed me to do just that.

I find that one of the largest hurdles for getting involved in any project for me is lack of knowledge. You’ve got a source checkout, and you’ve got a problem to solve, but no idea where to start. If you’re courageous, you can start dipping into random files and window shopping until you find something that looks promising. However, this approach is inefficient. As I said, I really like to expand the breadth of my understanding as quickly as possible, so here are my patented steps to getting a better handle on the source tree:

1. Subscribe to an RSS feed of commits
2. Hang out in IRC channels
3. Watch interesting Bugzilla users

The trick here is to have lots of information available for consumption, and to sample a wide variety of it. I read commit logs every morning, pick out entries that catch my attention and skim the commit. If I’m still interested, I’ll visit the original bug and read through its history. Through these actions, I am now in possession of:

• names of people involved in something I’m intrigued by
• locations in the tree of code that I’m interested in
• other information from the bug – components worth paying attention to, dependencies, blockers, etc

IRC channels are a great way to act sponge-like. Many diverse conversations on all sorts of interesting code-related topics occur in #developers, while more focused channels like #content and #static allow me to pick up new concepts and insights into the work that I’m currently doing. Furthermore, they’re points of contact for people who are usually happy to help out when I’ve got a question.

Finally, Bugzilla is a goldmine of fascinating activity and information. When I started working on electrolysis, I realized that all of work I was interested in was clusted in the Core:IPC, so I set up an email watch on the QA contact for that component. Eventually, however, I wanted to diversify, so I began to follow specific users. Watching the activity of the polyglots of the project, those who dip in and out of every component is a great way to quickly become exposed to the wealth of work being done. There’s a downside to this: the more users you watch, the more intimidating your bugmail becomes. Today, I ended up receiving 270 emails over the course of one hour because roc decided to unassign himself from a crapload of bugs at the same time as a bunch of dependencies were added to some Jaegermonkey tracking bugs. However, I’ve become adept at quickly deciding whether a conversation thread is interesting to me or not, and these deluges are infrequent.

When it comes to learning about specific pieces of code that confuse me, I have another system. If it’s some fundamental concept that I need to grok (nsCOMPtr, ns*String, etc.), I turn to the faithful Google search: “mozilla X”, X being the unknown item, and 99% of the time the first result will be the relevant MDC page. If I’m more interested in quickly locating pieces of code, I pull out DXR and make use of its wonderful search limiters such as member: or derived:. If what I’m looking for is a piece of C or JS code, or simply isn’t indexed in DXR (m-c only), I haul out mxr and search there. If I do a few searches and can’t find what I’m looking for, it’s usually off to the friendly folk in #developers.

There’s one specific moment I remember from when I was starting out – my very first review. I’d submitted my first attempt at the typeaheadfind work, and to my horror, and email arrived with the subject “review denied.” I felt crushed. Reading through the review, I saw that many good points were made, but it was hard at first to shake the feeling that my code was simply not good enough. I’ve gotten better at accepting review- since then, but I feel that a simple change to the email subject (“review complete“) would go a long way to improving that user experience.

So that’s it, really. Through the application of these methods, I’ve gained enough knowledge to submit a bunch of patches, log some bugs, and start answering other people’s questions. It’s really just been a process of perseverance, asking the right questions, and making use of the correct tools.

Got a story? Please share! I’d love to hear how other people’s experiences differ.

As a follow-up to my previous post about merging mq reject in emacs, I thought I’d share some improvements to the process that I’ve made since then.

It turns out that swapping back and forth between the reject and the original in a single window felt was quite inefficient. With these changes, the reject opens up in another window (think emacs terminology here) on C-c r, and I can kill it later with C-x r. This also works better with other modules like uniquify – the code from the previous post would fail when trying to access rejects associated with buffers name “Makefile.in|ipc”. No longer must you suffer the indignity of process! Merging can, and should, be fun! BEHOLD MY WORKS AND DESPAIR.

I think I’m starting to feel more at home in the Mozilla codebase. It’s an exciting feeling when you can actually start answering other people’s questions instead of always being on the asking end.

Since Mozilla has embraced mercurial, and especially patch queues, with open arms, I get to deal with rebasing patches frequently. There are two ways this can happen – either you set up an external merge tool like meld to handle each conflict, or the rejected changes are dumped in a filename.ext.rej in the same directory as the file being patched. Since I do all of my work in emacs, I’ve finally got around to writing an elisp function to allow me to switch to a reject file from the original quickly and painlessly:

A simple C-c r is all it takes to switch from nsFrameLoader.cpp to nsFrameLoader.cpp.rej in the current buffer, and another C-c r will take me back to the original. Now that’s convenience!

I’m interested in playing around with Dehydra to see whether I can create a pre-review checker, hopefully to lessen the amount of nits that inevitably crop up in any patch submitted on Bugzilla. However, as always, the immediate hurdle is acquiring and building the software involved. Making dehydra from scratch involves building gcc 4.3.x, SpiderMonkey 1.7+, and dehydra itself. The instructions in the dehydra README gave me good, error-less instructions for gcc, and installing SpiderMonkey was nothing more than ./configure ; make ; sudo make install. Building dehydra was a bit hairier; here’s my final sequence of steps:

export CXX=/home/t_mattjo/src/gcc-dehydra/installed/bin/g++
./configure --js-libs=/usr/local/lib --js-name=js_static --js-headers=/usr/local/include/js/
make

Of course, I also had to go into the Makefile and add -lstdc++ because I kept receiving this error while trying to use the generated gcc_dehydra.so (thanks bradh!): /home/t_mattjo/src/gcc-dehydra/installed/bin/../libexec/gcc/i686-pc-linux-gnu/4.3.4/cc1plus:
symbol lookup error: ./gcc_dehydra.so: undefined symbol: _Znwj

So after all that, make check almost passes everything. I’m running into the same six errors that Roger Dicke got a few days ago, so I might try digging into that. However! I can hopefully start playing with static analysis soon, and that’s a very exciting prospect.

Update: the treehydra problem is a known regression in Spidermonkey trunk.