Planet Mozilla Education

Mark Surman (surman): Need feedback: generic Drumbeat slides

msurman — Tue, 09 Feb 2010 16:02:59 +0000

With Drumbeat gathering steam, a number people have asked for generic slides that they can use to spread the word. Which is amazing. I’ve taken a first shot at generic Drumbeat slides plus a voice over here:

You can also download the slides (PDF) or view the open video (ogg theora). The open video is actually nicer to watch than the embed above.

My goal with this version is to get feedback from people so that I can then do something more polished. I have two questions:

If you were in the audience, does this presentation provide you with a good intro to Drumbeat? If not, what additional topics would you want to see covered?
As a presenter, do the slides plus my voice over give you what you need to give a talk? If not, what else could I provide?

There are a couple of people who have offered to give Drumbeat talks in late February. So, I’ll take comments for a week or so and then post a revised slides in remixable form.

Filed under: mozilla

Mark Surman (surman): Why is there flash video on my blog?

msurman — Tue, 09 Feb 2010 11:45:02 +0000

A number of people have asked me: why do you still have Flash based videos on your blog?

The answer: my blog is hosted on wordpress.com, which strips out the video tag and also does not (yet) have it’s HTML5 video player. There is a trick to get around the video tag being stripped for self hosted WordPress, but not for wordpress.com.

The good news is that WordPress is working on their own HTML5 video player. Also, there is a bug filed to fix the issue of stripping out the video tag. Also good: wordpress.com automatically encodes everything you upload to Videopress into Ogg Theora. So, when HTML5 video does arrive, it will be Ogg ready.

As a happy wordpress.com customer (love the service) with a fair bit of traffic at commonspace.wordpress.com it’s worth it to me to wait around until the HTML5 video issue is fixed. In the meantime, I am posting all of my videos directly to wordpress.com using Videopress (and their Flash player) and also providing a link to the Ogg Theora version for people who would rather watch my videos natively in the browser.

PS. If anyone has a workaround that doesn’t involve leaving wordpress.com, would love to hear about it.

Filed under: mozilla

Gordon P. Hemsley (GPHemsley): PHP, MySQL, and the BIT field type

GPHemsley — Mon, 08 Feb 2010 05:47:43 +0000

As Dave Humphrey once taught me:

When you do a search, and it comes back with no results, it’s a sign that you need to write something.

This is an issue that I came across while testing SASHA (which is available for you to try out, by the way), and I didn’t know if it was a bug or a feature. I could find no mention of it anywhere, and the people in the #mysql IRC channel on FreeNode weren’t especially helpful in helping me get to the bottom of it.

What is the issue, you ask? Well, even that in and of itself is a question, because I don’t know whether it’s a bug (or feature) in PHP or MySQL. However, I’m inclined to think it’s the latter, and I’ll get to why in a moment.

But first, some background. The table that SASHA uses to store schedules uses the BIT field type for keeping track of which days of the week a schedule occurs on. I figured it’d be easiest to use a 7-bit field and just flip a bit for each day of the week. And that worked fine for me on my local test server. But then I had a colleague test SASHA out on his test server, and things went a little wacky.

It took a little while to figure out what was causing our problem, and we finally got to the bottom of it: I was using MySQL 5.0 and he was using MySQL 5.1! Apparently, between 5.0 and 5.1, the return format of a BIT field changed from the literal binary data (output in the browser as a character, because the browser didn’t know it wasn’t) to a decimal representation of that data.

The first problem with that was that I had no idea there was a possibility of getting anything but the raw binary data I was getting on my server. The second problem was coming up with a straight-forward solution to detecting whether the database was feeding us raw binary data or converted decimal data. There was no direct way to do this, but I figured out the next best thing. A simple way to check what kind of data we’re getting is to find out whether it converts cleanly to an actual character. Here’s an excerpt from SASHA that demonstrates:

// MySQL 5.0 returns bit as binary, while MySQL 5.1 returns decimal
if( $days == chr( ord( $days ) ) )
{
	$input = 'binary';
}
else
{
	$input = 'decimal';
}

That seems to do the trick when it comes to handling unpredictable BIT field data.

(Again, I can’t guarantee that this isn’t actually a PHP issue, but I seem to recall us both being around the same version of PHP.)

If you have any insight into the matter, please do leave a comment.

David Humphrey (humph): Writing Automated Tests for Processing.js

david.humphrey — Sat, 06 Feb 2010 01:27:56 +0000

I finished up some work today on the Processing.js automated test tools. Previously I wrote a test harness to allow JavaScript based unit tests, as well as parser tests. However, after watching some of my students struggle through bugs during the lead up to their 0.5 release, I decided we needed a way to also be able to write them in Processing. Right now I see a lot of tests being drawn into sketches, and then manually comparing results. It’s sub-optimal to say the least.

Having written the unit test functions already, I decided to simply load them into Processing via a library. Processing.js, like Processing, has the capability to load “native” libraries. In Processing.js, such libraries are JavaScript functions written like so:

(function() {
  Processing.lib.Foo = function() {
    this.something = function() {...};
    ...
  }
})();

Then, in your Processing.js sketch code, you initialize the library by calling its constructor (e.g., Foo();), and then any function (e.g., something();) will be available to your code.

Using this technique I added the same set of _check* functions already available to JavaScript unit tests, such that I’m now able to write small unit tests in Processing like this:

// Tests for Processing str() function - http://processingjs.org/reference/str%28%29
boolean b = false;
byte y = -28;
char c = 'R';
float f = -32.6;
int i = 1024;

_checkEqual('false', str(b));
_checkEqual('-28', str(y));
_checkEqual('R', str(c));
_checkEqual('-32.6', str(f));
_checkEqual('1024', str(i));

I’ve fully documented the setup and use of the new automated testing features. All Processing.js developers (especially my students), should read through this. Beginning with the 0.6 code, we’ll start using this by default for all regression and API testing.

Joshua Cranmer (jcranmer): Developing new account types, part 1: The folder pane

noreply@blogger.com (Joshua Cranmer) — Fri, 05 Feb 2010 23:25:18 +0000

This series of blog posts discusses the creation of a new account type implemented in JavaScript. Over the course of these blogs, I use the development of my Web Forums extension to explain the necessary actions in creating new account types. I hope to add a new post once every two weeks (I cannot guarantee it, though).

In the previous blog post, I gave a broad overview on the overall structure of the backend interfaces and the components of account implementation. Now, we will prepare the necessary components of getting your extension's folder displayed in the folder pane.

Account implementation decisions

Before you start implementing, you have to decide how to structure the account. The first decision is what the internal account type will be. This will be the value of nsIMsgAccount::type and will dictate the contract IDs for several interfaces. The next decision is what the account URI scheme is. This will be the scheme for the URI and dictates the contract IDs for a few more interfaces; for mailbox accounts, this scheme will be mailbox. For my extension, I have decided to choose webforum for both of these.

Another important decision to make will be the server for which you will be doing most of your initial tests. It should be something that is manageable for debugging purposes. In my case, I've decided to bestow this honor on the Kompozer web forum, because it seems lower traffic than any other forum I'm reasonably interested in. As you may notice, I am starting my extension with the intention of focusing on phpBB access—it's sufficiently widely used that I expect that only supporting phpBB at first would still make a worthwhile extension.

Once you have decided that, you should take the time to study how things will be structured: what determines a folder? What determines a message? A thread? Replies? How are you going to be carrying out new actions, such as checking for new messages? What internal information are you going to need to save for accessing? Heck, what determines the "server" to begin with? In my case, the DOM inspector is an invaluable tool for answering this questions. Don't worry about how to figure out the list of possible subscribable folders yet. Subscription will come into play much later; we are going to start by just hardcoding this list somewhere.

In my case, I am choosing to structure the folders as a Category → Forum hierarchy. I'll pick a few of the smaller forums to use so I don't overwhelm debug logs.

Implementing protocol information

Since nsIMsgProtocolInfo is the shortest and simplest of the interfaces, let me start by implementing this one. There are a total of 12 attributes and 1 function on this interface, so the code will not be hard to write. Following is an implementation of the code [1]:

wfService.prototype = {
  contractID: ["@mozilla.org/messenger/protocol/info;1?type=webforum"],
  QueryInterface: XPCOMUtils.generateQI([Ci.nsIMsgProtocolInfo]),

  // Used by the account wizard and account manager
  get defaultLocalPath() {
    let dirSvc = Cc["@mozilla.org/file/directory_service;1"]
                   .getService(Ci.nsIProperties);
    let file = dirSvc.get("ProfD", Ci.nsIFile);
  file.append("WebForums");
    if (!file.exists())
      file.create(Ci.nsIFile.DIRECTORY_TYPE, 0775);
    return file;
  },
  get serverIID() { return Ci.nsIMsgIncomingServer; },
  get defaultDoBiff() { return true; },
  get requiresUsername() { return false; },
  getDefaultServerPort: function (secure) { return -1; },
  get canDelete() { return true; },

  // Used by UI code
  get canLoginAtStartup() { return true; },
  get canGetMessages() { return true; },
  get canGetIncomingMessages() { return false; },
  get showComposeMsgLink() { return false; },
  get specialFoldersDeletionAllowed() { return false; }
};

The meaning of each of the attributes can be found in more detail on the MDC page. The properties used by the account wizard mostly control initial preference values; those used by the UI code mostly control which UI elements are enabled. I have excluded from the implementation also those attributes which are unused.

Perhaps the most leeway you have is in implementing defaultLocalPath. In this case, I have adapted the RSS implementation, which does not allow users to change this location. The other implementation (used by IMAP, POP, NNTP, Movemail, and Local Folders) uses a preference to return the default path. An example implementation of this method is like thus:

get defaultLocalPath() {
  // This will probably be found in the constructor
  this._prefs = Cc["@mozilla.org/preferences-service;1"]
                  .getService(Ci.nsIPrefService)
                  .getBranch("extensions.webfora.");
  // Preference looks like [ProfD]WebForums
  let pref = this._prefs.getComplexValue("rootDir", Ci.nsIRelativeFilePref);
  return pref.file;
},

Once you have completed that, you should test that the service implementations work as expected via test snippets in the Error Console. The account manager can be mean when it comes to unusable account types [2], so this will help fix the most obvious bugs before the account manager attempts to do it for you.

Server and root folder discovery

Before I start going any further with code, let me take a minute to explain how servers and folders interact. The server objects themselves do surprisingly little in the UI; the most common property calls are probably rootFolder and type. This even includes what you might think of as server attributes: the bold display name, has new messages treeview properties, etc. Instead, those features can be found on the root folder, which is a "fake" folder object. Most of what we care about in this part happens on the root folder instead of the server; however, if you browse the implementation in nsMsgDBFolder, you can see that some of the property calls get forwarded back to the server for root folders.

The backend code will create server objects early on and hold onto them for the duration of the program (or until they are deleted). The server objects then create the root folders which then create subfolders as necessary. Links that go backwards (parent links and server links) are weak references to avoid refcount cycles. Most of this work is hidden in nsMsgDBFolder for you. After creation, various properties are accessed at will; some properties will be loaded in from the database info (a topic for later).

In more concrete code terms, the following is the steps in loading the folder pane:

The account manager loads the mail.accountmanager.accounts preference; the values here are a comma-separated list of account keys.
For each account key, an account is instantiated. Per-account data is read off of the mail.account.<key> preference branch; in specific, the server preference contains the server key to load and the identities preference is a comma-separated list of identity keys.
The identities and servers are then bootstrapped. In the case of servers, the server is created as an object with the @mozilla.org/messenger/server;1?type=<type> contract ID. The server pref branch is mail.server.<key>; key preferences here are type, the type for the contract ID; userName, the (optional) username of the server; and hostname, the (required) host of the server.
The account manager sets the key, type, username, and hostName properties, in that order on the server object instance and then retrieves the port property. The (type, username, hostName, port) tuple is the unique identifier for a server: no two servers can have the same combination of these values. Now your server is constructed and returned to the folder pane.
The folder pane retrieves the rootFolder of your server. If you happened to be saved in the expanded state, subFolders is recursively retrieved from folders as corresponding to the saved open state. The folder pane also calls performExpand() on the server if the root folder is expanded.

So that explains how your server gets created; how do your folders get created? nsMsgIncomingServer::GetRootFolder [3] calls nsMsgIncomingServer::CreateRootFolder, which calls serverURI and uses it to construct an RDF resource. serverURI creates a URI of the form localstoretype://[<username>@]<hostname> by default. This URI is actually the URI of your root folder; other code will assume that this invariant holds true (especially subscribe!). Other folders are created when you get the subFolders property. When the folder URI is parsed (which is pretty much the first time a useful property is called), getIncomingServerType is called to get the type of the server.

In summary, you may need to implement localStoreType and possible serverURI on your server, and subFolders, and getIncomingServerType, and CreateBaseMessageURI on your folder [4]. First we'll start by getting the root folder display working:

function wfServer() {
  JSExtendedUtils.makeCPPInherits(this,
    "@mozilla.org/messenger/jsincomingserver;1");
}
wfServer.prototype = {
  contractID: ["@mozilla.org/messenger/server;1?type=webforum"],
  QueryInterface: JSExtendedUtils.generateQI([]),
  get localStoreType() { return "webforum"; }
};


function wfFolder() {
  JSExtendedUtils.makeCPPInherits(this,
    "@mozilla.org/messenger/jsmsgfolder;1");
}
wfFolder.prototype = {
  contractID: "@mozilla.org/rdf/resource-factory;1?name=webforum",
  QueryInterface: JSExtendedUtils.generateQI([]),
  getIncomingServerType: function () { return "webforum"; }
};

At this point, I recommend you again check to make sure resources are properly registering via the Error Console. With that in hand, it's time to modify your preferences manually. I personally recommend changing settings via editing prefs.js while Thunderbird is off so you don't accidentally confuse the account manager. I'm using the keys account99 and server99 to make it plain which account is being edited. First, I copy the mail.identity.id3 pref branch (any identity would do) and change the id3 to id99. Then I copy the mail.account.account3 pref branch and change the 3's to 99's.

The next changes are the server preferences, which are going to be the most unique. directorydirectory-rel are set to a folder where I want to store stuff ([ProfD]WebForums/kompozer, in my case). download_on_biff and login_at_startup are set to false (to avoid dealing with biff for a bit longer). name is set to be the display name of the server. hostname and userName were set to the appropriate values for this account [5]. To the preference mail.accountmanager.accounts, I appended account99. With those changes done, I then start up Thunderbird to see the outcome:

Perhaps I should have chosen a shorter name for display.

Folder discovery

Now that the root folder is displayed, we need to get the folders added to the display pane. Somehow, we need to figure out what the folder hierarchy looks like—it has to be stored in some file, in other words. The NNTP code uses the newsrc file to store its folder tree, and local folders looks at the directory hierarchy for its map, to name two examples.

In my code, I'm going to choose the use of a JSON file to store this data. I've considered SQLite, but I don't really need synchronization (per-server files work nicely here), and I'm mostly doing simple lookups. Plus, I can probably handle automatic schema migration more easily in SQLite.

For this next part, we concentrate on a single property: subFolders. This function typically has two parts: it first checks for initialization (if so, it returns the enumerator to the stored values); if it's not initialized, the rest of the function, or perhaps a second function altogether, is used to create the subfolders.

Some code to initialize these subfolders is as follows (the logic to retrieve the database is not included and can instead be found in the source code for my extension):

 get subFolders() {
    if (this._folders)
      return array2enum(this._folders);// If we're here, we need to initialize.
    this._inner.QueryInterface(Ci.nsIMsgFolder);
    let serverDB = this._inner.server.wrappedJSObject._db;
    // Uninitialized -> no subfolders
    if (!serverDB.categories)
      return array2enum(this._folders = []);

    // First find our level
    let level = /* some logic */;

    let URI = this._inner.URI + '/';let folders = [];
    // Yes, we still use RDF
    let RDF = Cc["@mozilla.org/rdf/rdf-service;1"].getService(Ci.nsIRDFService);
    let netUtils = Cc["@mozilla.org/network/io-service;1"]
                     .getService(Ci.nsINetUtil);
    for each (let sub in level) {
      // Some URIs may contain spaces, etc. -> escape
      let folder = RDF.GetResource(URI + netUtils.escapeString(sub.name,
        Ci.nsINetUtil.ESCAPE_URL_PATH));
      folder.QueryInterface(Ci.nsIMsgFolder);.parent = this;
      folders.push(folder);
    }
    this._folders = folders;
    return array2enum(this._folders);}

There are a few major things to note. First, the new folders are created via the RDF resource. Both Thunderbird and SeaMonkey use RDF for folder access, so it is still a good idea to create via the RDF service so you don't confuse the caller code. Also, with that in mind, the subfolder name still needs to be escaped as well in the URI, hence the calls to nsINetUtil. The auxiliary function array2enum takes in a JS array and returns a proper nsISimpleEnumerator for the array. I've excluded it's definition here do to its simplicity and the length of this document; if you want to see it, you can view it from the extension source code. The last thing to note is that this code is using this._inner: this variable is a link to the nsMsgDBFolder implementation which was created for us by the JSExtendedUtils inheritance call. I will defer a more thorough treatment of this C++-JS glue until later.

Folder pane extras

At this point, you should have a simple, plain folder hierarchy, which is navigable if not fully usable. In terms of UI, though, it's not quite fully perfect: if you have an inbox, it will be rather indistinguishable from other folders; similarly, "fake" folders (think the [Gmail] folder if you have Gmail IMAP) show up as regular folders. These things are handled to a large degree by CSS.

A full list of the available of the styling points for the Thunderbird folder pane can be found on MDC. Extensions can also modify the folder pane views or add other, non-folder items. More information can be found at MDC's folder pane information page.

I would provide some example styling code here, but when I was doing testing, I discovered some related assertion failures that I have not yet had time to grok. In the interest of keeping to a posting every two weeks, I am going to defer this until either a mini "part 1.5" or the beginning of part 2, depending on how much time I will have available next week.

Notes

I will not, in general, post the full code for any of the classes, only enough to demonstrate what needs to be done. For example, the classID property is omitted in this example. Something to note is that I have a modification to XPCOMUtils locally that will accept arrays of contract IDs as opposed to a single one (wfService will be implementing more than one contract ID).
What it specifically does is attempt to get the server; if it fails, then it removes the account from the accounts pref. If you are compiling your own builds for your extension development profile, I recommend you remove the lines in nsMsgAccountManager::LoadAccount that remove the account on failure.
In general, I will mix the IDL and C++ names for methods and properties in the course of the guide. As a basic rule of thumb, if you see a :: in the name, it's a C++ name; otherwise, it's the IDL name.
getBaseMessageURI is a local function called by nsMsgDBFolder during initialization that is used to set up the URIs for getting individual messages. This function will be covered in more depth as we get messages working, but it is technically necessary for startup (a stub that does nothing is provided).
A strong temptation for accounts whose sources are some web address (for example, RSS or my web forums account) is to put the base address as the hostname property. However, as you would quickly realize, that plays havoc on URI parsing, and nsMsgDBFolder::parseURI is not virtual. A better option would probably be to leave the hostname as some identifier that you use only for guaranteeing uniqueness and to store the base URI somewhere else. Since all of my folders have independent URIs associated with them, I can safely ignore the issue until account creation and subscription are covered.

Simon Teo (Simon): Mozilla Project Proposal

Simon — Fri, 05 Feb 2010 15:03:30 +0000

Software testing is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible. It is commonly believed that the earlier a defect is found the cheaper it is to fix it. Hence, it ignite my passion into automated testing which bring me to Mozmill!

I hope to use Mozmill to automate testing on some of the complicated and test cases that require lots of time
from Litmus.Mozilla.org

If time permit, I hope I can implement Mozmill automated testing on some of the new extensions and my classmates extension. *Wink @ Chris

Daniel Le Duc Khoi Nguyen (Libras2909): Mozilla project – Proposal

libras2909 — Fri, 05 Feb 2010 09:01:10 +0000

I’ve just submitted my proposal this afternoon. So I guess I’ll upload it here, to remind me of what needs to be done (also as a link from our module’s wiki).

SCHOOL OF COMPUTING

CS3108A/B: INDEPENDENT WORK (IW)

Description of Activity

This project is a one-semester project under the Mozilla-independent-work module (CS3108B). The project will enable me to familiarizing myself with the Mozilla community, and get a hand on various tools, technologies and programming languages involved in Mozilla-product development process. During the project, I will be contributing code to two Mozilla products (Firefox and Thunderbird), and documenting my work and experience on my blog. I will also be online on different IRC channel at irc://irc.mozilla.org to provide supports to other developers or users.

Blog URL: http://grbmozilla.wordpress.com/category/cs3108-mozilla-project/

My main objective in this project is fixing ‘non-trivial’ and/or ‘enhancement’ bugs.

‘Non-trivial’ bugs usually are issues that are important to an on-coming release version of the product(s). They require reasonable depth of knowledge in both the application platform and the application itself. This knowledge can be gained through reading code in Mozilla’s repository and some of its documentation, and most important, through interacting with developers in the community. This task is challenging because much of Mozilla code lacks documentation due to the huge repository size.

‘Enhancement’ bugs usually provide/correct desiring features that Mozilla’s users want in the next version. Therefore, a large number of users can benefit from the fixing of a bug belongs to this category.

To be specific, I plan to work on these bugs:

Bug 527472 (Firefox) Enhancement to Tab previews to support different language search, a new Firefox 3.6 feature.
Bug 350006 (Firefox) Enhancement to ensure favicons is displayed under Page Info section. Favicons are small, customized icons to allow users to easily distinguish pages under their bookmark folder.
Bug 538015 (Thunderbird) Minor bug to enable window position saving. Users want their windows to appear exactly the same place during last session of Thunderbird.
Bug 542705 (Thunderbird) Critical bug where account configuration in new version of Thunderbird doesn’t follow the security policy desired.

Working on an open-source project has always been one of my dream. This Mozilla-independent-work project will give me a good start on this field. I will try my best to fulfill my proposal during this semester. If these bugs above can be fixed on time, I can continue working on other bugs to contribute more to Mozilla community.

Lindauson Hazell (Lindauson): Confusion...confusion...then Hope

Fri, 05 Feb 2010 01:28:13 +0000

When I first took this bug back at the UCOSP Code Sprint, I did so under the impression that it was a relatively simple one. I still believe that it is...

My initial problem was that my edits to the mailWindowOverlay.xul did not have the desired effect in the Shredder app. My first impression was that the UI changes were not being realized in Shredder because they were being handled by another .xul document -- the mailOverlay.xul. Howerver, after looking at the mailOverlay.xul, that doesn’t seem to be the case.

My current hypothesis is that, an error is being made (probably by me) when executing the build instructions, causing the changes to be unregistered. I spoke to my team-lead, Blake, yesterday. I asked him if I was running the make command from within the correct directory. I was; however, he did suggest that I try the other make commands instead (i.e. “make -s tier_app” or “make”). I’m going to try that (and some other things:) Hopefully something takes...

[Bug 495815]

Boris Zbarsky (bz): Understanding the numbers your profiler gives you

bzbarsky — Thu, 04 Feb 2010 20:21:35 +0000

A common situation I run into is that I have some testcase, I profile it, then I optimize one of the things that looks slow a bit and reprofile. If I'm lucky, then the fraction of time it takes drops from B to A (A < B of course, with B standing for "before" and A for "after"). What does that mean for the overall time of the testcase?

Obviously, what it means depends on both A and B. If we assume that the time taken for the part that wasn't optimized hasn't changed, then the overall speedup is (1-A)/(1-B).

So B - A = 5% would mean a 2x speedup if B is 95% and A is 90%, and only a 1.05x speedup or so if B is 5% and A is 0%. If B is something like 53% and A something like 48%, then you get a 1.11x speedup.

All of which is to say that focusing on the hotspots is _really_ the way to go, if at all possible.

Processing.js Blog: Processing.js v0.4.0 Released

admin — Wed, 03 Feb 2010 21:04:44 +0000

Download Processing.js 0.4

We are very pleased to announce the release of Processing.js 0.4!

The students at Seneca and the community at large, have been working hard to get some awesome code into the repository. Many smaller fixes and features have been added as well as larger functions like blend modes. Another landmark in 0.4, are the small fragments of OpenGL code that have begun to land. If you were not aware that Processing.js is getting 3D hardware support in the browser, you are now!

The whole development process has taken a few releases to get right, but the community has gathered great momentum in the last few months and the “right people” have joined the group, helping Processing.js to run like the well oiled machine it should be. We are seeing some amazing innovation and creativity from community members, such the experimental HTML5 audio stream reading and writing in Firefox from David Humprey and co.

Development Process

The GitHub flow has also shifted to a more organized state with Anna Sobiepanek heading up .NEXT branch control prior to super-review and release candidacy. This allows us to keep the repository clean, so the main branch jeresig/processing-js will only get updated when a new release ships. The code will bubble up through controlled channels that have had rigorous tests and checks applied by the community, keeping the library parallel with it’s big sister Processing, while maintaining a degree of difference that makes Processing.js suitable for the web context in which it is deployed.

Linting

From 0.4 onwards, release code is being linted, beautified and packed before release using some excellent script-fu from David Humprey and tested by fellow release controller (and GitHub master) Corban Brook. This way we will be confident that new releases do not break old functionality, code will be lightweight, ready for deployment and be easier-on-the-eye for future developers.

Get involved!

If you would like to get involved with Processing.js development, or have general usage questions about Processing.js, we would love meet you on IRC: irc://irc.mozilla.org/processing.js

Download Processing.js 0.4

ChangeLog:

added map()
added fill()
added reverse()
added matchAll()
added blendColor()
added split()
added subset()
added splice()
added concat()
added unbinary()
added online()
added mag()
added hue()
added saturation()
added brightness()
added splitTokens()
added append()
added match()
added unhex()
added PVector()
added nfs
added shorten()
added nfp()
added focused
added strokeCap()
added nfc()
added cursor ( mode ) definitions
added strokeJoin()
added bezierPoint()
added popStyle()
added boolean()
added screen()
added noCursor()
added curveTangent()
added pushStyle()
added curvePoint()
added frameRate()
added size() for 3D
added background() for 3D
added release automation
added automated parser and unit tests
fixed JSLint validation
fixed Pvector
fixed parser bugs
fixed nf() (Infinite loop)
fixed functions that return arrays

Download Processing.js 0.4

David Humphrey (humph): The case of the open file handle

david.humphrey — Wed, 03 Feb 2010 01:50:06 +0000

I did a rewrite of the Processing.js test suite code to get around a bug Al hit on Linux. In doing so, I hit another nasty bug that Ted eventually solved. I needed to get an escaped version of JavaScript or Processing code loaded into the js shell via the -f flag. Previously I had been passing this as a string via -e, but we were erroring out as the size of the files increased beyond the max arg length allowed. My solution was to create a temporary file in Python, stick the encoded script in, pass that into the shell for processing, then delete it.

It worked great on OS X, but on Linux we were getting an exception about half-way through the test run “Too many open files.” We have 855 test files at present, so it seemed unlikely that we had hit a real OS maximum. I tried adjusting the number of file descriptors per process (ulimit -n 8192) and it worked. Looking at my code I first thought that I must be accumulating pipes (I use stdout and stderr to communicate with the js shell). Nothing I could think of was fixing it, and it seemed crazy to me that subprocess.Popen() wouldn’t close them properly.

Eventually Ted figured out that my issue was that I wasn’t closing my temp files properly. Here’s the relevant bit of what I was doing:

tmp = tempfile.mkstemp()

t = open(tmp[1], 'w')
t.write(es)
t.close()

“But I am closing it,” I protested. “No, sir. You’re not!” said Ted, and he was right. Looking again at the docs for mkstemp(), and reading more carefully, I noticed this:

mkstemp() returns a tuple containing an OS-level handle to an open file (as would be returned by os.open()) and the absolute pathname of that file, in that order.

Did you catch that? “…an open file…” I missed it totally. I have said it before, but it is worth repeating: Python has really amazing docs. I should read them more often. Here’s the fix:

tmp = tempfile.mkstemp()
os.close(tmp[0])

David Humphrey (humph): Bad Gr@mm3r?

david.humphrey — Mon, 01 Feb 2010 20:58:58 +0000

The Globe picked up a Canadian Press article today, whose title echos the favourite refrain of big media and other institutional onlookers of so called social media: “Students failing because of Twitter, texting.” In it the author cites some “solid evidence” for the demise of writing skills at the post secondary level:

Ontario’s Waterloo University is one of the few post-secondary institutions in Canada to require the students they accept to pass an exam testing their English language skills.

Almost a third of those students are failing.

…

“What has happened in high school that they cannot pass our simple test of written English, at a minimum?” she asks.

Even those with good marks out of Grade 12, so-called elite students, “still can’t pass our simple test,” she says.

Poor grammar is the major reason students fail, says Barrett.

“If a student has problems with articles, prepositions, verb tenses, that’s a problem.”

We’ve heard all this before. Poor writing? Increased use of social media? Let’s connect the dots. A little further into the article, we find some other interesting bits; let’s start with grammar:

Some students in public schools are no longer being taught grammar, she believes.

…

“When I went to high school in the ’70s I was never taught grammar in English. I learned grammar from Latin classes.”

…

“We haven’t taught grammar for 30-40 years…(and it) hasn’t worked.”

“It’s not that hard to teach basic grammar,” he says.

I learned grammar studying classical Greek through four years of university. I was never properly taught grammar in high school, because that final statement above is false: it is hard to teach grammar, or perhaps it is hard to teach it well. Grammar, as an abstract system, is very difficult to grasp when you only know one language. Without being able to step outside English and examine it from the vantage point of Greek, I don’t think I would have ever understood it. But in the context of learning a second language, especially its literature, one is forced to map grammatical structures back and forth. You can be a very good speaker or writer of English and not know the names for the constructions you use. You can’t learn to read another language without them. In other words, the need for grammar has to be real if one is to learn and then retain it. I think many of the high school students who failed these tests did in fact learn grammar; they just didn’t retain it beyond the final exam.

Another issue discussed at length is spelling, contractions, and other short forms:

Emoticons, happy faces, sad faces, cuz, are just some of the writing horrors being handed in, say professors and administrators at Simon Fraser.

…

“Instead of ‘because’, it’s ‘cuz’.

…

“The words ‘a lot’ have become one word, for everyone, as far as I can tell. ‘Definitely’ is always spelled with an ‘a’ -’definitely’. I don’t know why,” says Paul Budra, an English professor and associate dean of arts and science at Simon Fraser.

I find the last example particularly funny. The use of alot vs. a lot frustrates me, I’ll be honest. I have a friend who uses ‘alot’ exclusively, and one day I decided to send him a private note telling him of his mistake. He replied politely that he knew, and had made a conscious decision to change the spelling as a way of normalizing ‘alot.’ I was blown away at first, but later, upon reflection, had some respect for his decision. Spelling reforms have happened throughout history, whether through decree or by means of popular usage shifts. If ‘definitely’ is always spelled ‘definately,’ it soon will be. Is it E-Mail, E-mail, e-mail, or email? Spelling is very much influenced by usage, just as meaning.

Students haven’t learned grammar. Students haven’t learned to spell. Ergo:

Cellphone texting and social networking on Internet sites are degrading writing skills, say even experts in the field.

“even experts” notwithstanding, how do we make the leap from an obvious lack of focused study on particular areas of language learning, and the increased use of cellphones, social networking, and the web? Furthermore, how is it that these are degrading writing skills?

I have spent the past decade teaching software engineering to third and fourth year undergraduate students. I teach in what is often thought to be an illiterate discipline (in addition to English and Greek philology, I also studied Computer Science, so I can speak from experience). What does programming have to do with writing? A lot (or should I say, Alot).

In my courses I expect students to do a great deal of writing and reflecting. Students are asked to keep a blog, use Twitter, collaborate on wikis, and communicate in real time using irc. My experience in doing this over the years is that students have a lot to say, are thinking in ways that help move the class forward when shared, and most of all, that they have much to teach the other students and myself.

Do I see them make mistakes in terms of punctuation, grammar, and style? I do. Do they see me do the same thing? Most certainly they do. But we’re all writing. Can students write? Yes, if you let them. Yes, if you model writing, and reading for them. One of my students asked me a few weeks ago if I’d ever done a word count on my blog. I hadn’t but decided to try. It turns out I’ve written the equivalent of 3 good sized novels since 2006. I haven’t written a novel, though, and don’t expect I ever will. Instead, blogging, Twitter, social networking, and the web have insured that I exist in a literate age, where writing every day is the new normal. I would argue that if students were allowed to use the web more, they’d be in even better shape. As David Eaves notes of his blog, “if writing is a muscle, this is my gym.”

I’m less skeptical of students’ ability to write than I am of the intentions of educators decrying the demise of writing. When all we have of writing is a “simple test,” education is reduced to a set of questions you can use in order to substitute real reading and ideas for a bell curve. We’ve seen “simple tests” before, and they often have very little to do with real writing. Writing, like many worthy pursuits, is easily stifled by pedants, who confuse the rules of writing for writing itself.

Lindauson Hazell (Lindauson): Confusion...then more confusion

Mon, 01 Feb 2010 17:21:38 +0000

So, I’ve been looking at the utilityOverlay.xul’s (yes, there are two of them) and they are very different, apparently one has been redesigned to temporarily resolve a mac os x bug. Anyway, it doesn’t seem as if changing anything here will help. I’m gonna see if someone on #educatiion can advise me on this, because i am thoroughly confused...

[Bug 495815]

Chris Cai (anttyc): Sunday Afternoon

anttyc — Sun, 31 Jan 2010 17:01:37 +0000

While looking for ideas as to how to visualize the search results I thought of the “tag” clouds used in blogs to show the frequency of topics/word uses.

If I am to pursue this project of search visualization, I will probably aim to create a “cloud” like prototype that represents the search terms. Following which I’ll create a more visual representation of the data.

Fatma Meawad (fmeawad): Respect the “H”

Fatma — Sat, 30 Jan 2010 15:22:50 +0000

I am not usually long sighted but I have seen it coming. I knew that when the time comes for the students to pick a final project in the open source course, they will resist taking assigned bugs. The learning outcomes of the course rely on their deep involvement in a big open source commuinty where they experience different practices to make use of the embedded knowledge in the community. The hope is that they will stick to such practices.

From the start I had a few questions in my head: should I allow them to work in different communities or not? should I allow them to propose ideas or stick to existing reported bugs? Based on experience, David Humphrey suggested that I get them all in one community so that they will help each other. This way, there are more opportunities for collaboration and contributions among them as well.

Even though, I am very convinced with David’s opinion, I faced the problem of raising the students’ interest in available bugs. Working in open source is usually motivated by a developer’s itch – egyptian accent pronouctian of “H”
I want the students to experience this interest in order to see commitment and enthusiasm for the their work. There are many challenges ahead but working day and night to overcome them is enjoyable when the developer is interested personally in this specific bug work. From here, I opened the choices from one community bugs to bugs from any communities that they are interested in provided that they are active and big enough.

Another thing that I saw coming but I couldn’t stop was students proposing a totaly new idea for a project. Obviously this is out of the scope of the course. But again, what is the right decision when the idea is really good and when the developers are extremely interested in it? Is it fair to say no? May be the right approach to this is to strictly emulate the whole commuity process for the students with their new idea.

This is the first time we run this course and with all the confusions, I decided to respect the developer’s itch and give it priority. If I am keen to get the students in the open source community mode, then they need to experience the feeling of an interested developer who is voluntarly taking part and making the best out of a community. I believe that any whether it is working on an existing bug or starting a new community, the course can be useful and the learning outcomes can be achieved. Well, I don’t know for sure but I will see at the end of the course.

……

I wrote the above paragraphs 2 months ago and as you might notice, I was waiting for the end of the course to report results. Well, the course has ended, so you get the results now. That is nice right? How many times you wanted to see an ending and you couldn’t wait for it.

I actually don’t have a significant outcome to report. I am simply happy and proud with the students who got into the mood and they actually changed their attitude towards software development in general. I get so excited when I get contacted about one of my students’ work. So, getting them into a community to work on specific bugs proved to be the correct path for learning.

Does this mean that allowing them to work on their project ideas failed? certainly not. But not the kind of success that relates to this course I am actually very proud of one of the output projects done which is g-apl. I am expecting great contributions to the GUC community and by making it open source, g-apl can be useful to everyone later

Does the itch win or not? Well, I certainly feel that sometimes developers don’t recognize that the task assigned to them could be of interest to them or not. I would say, give things a chance and don’t judge before you try first.

Boris Zbarsky (bz): Cross-compiling success

bzbarsky — Fri, 29 Jan 2010 22:25:09 +0000

I took another stab at directly cross-compiling (not via distcc) using toolwhip. My previous attempt failed, but not due to libffi at all. The problem there was that I had the Mac ld in my path before the host ld. After fixing that and a few mozilla build system issues and making sure the build system can find the right SDK and the right ar and such I now have a cross-compile setup working. No make package yet, since that requires the dmg-creation utility which I don't have on the Linux machine. No --enable-breakpad support yet due to bug 543111. --enable-shark needs headers I don't have on that machine yet, so I'd need to sort that out. But for basic bisecting, this works.

Just so I can find it later, the working mozconfig file I'm using is something along these lines:

mk_add_options MOZ_MAKE_FLAGS="-s -j10"
export MOZ_MAKE_FLAGS="-s -j10"

mk_add_options CC="ccache /Developer/usr/bin/gcc-4.2"
export CC="ccache /Developer/usr/bin/gcc-4.2"

mk_add_options CXX="ccache /Developer/usr/bin/g++-4.2"
export CXX="ccache /Developer/usr/bin/g++-4.2"

mk_add_options CROSS_LIB_PATH="/Developer/usr/lib:/Developer/SDKs/MacOSX10.5.sdk/usr/lib"
export CROSS_LIB_PATH="/Developer/usr/lib:/Developer/SDKs/MacOSX10.5.sdk/usr/lib"

mk_add_options CROSS_COMPILE="1"
export CROSS_COMPILE="1"

export LD=/Developer/usr/bin/ld
export AR=/Developer/usr/bin/ar

mk_add_options PATH="/home/bzbarsky/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/Developer/usr/bin:/Developer/SDKs/MacOSX10.5.sdk/usr/bin"
export PATH="/home/bzbarsky/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/Developer/usr/bin:/Developer/SDKs/MacOSX10.5.sdk/usr/bin"

ac_add_options --target=i686-apple-darwin9
ac_add_options --enable-application=browser
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk
ac_add_options --disable-crashreporter
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --disable-tests

Various other --enable-whatever are hanging out in there too, but the above are sort of the minimal set one needs at the moment.

David Humphrey (humph): Giving the parser a B-

david.humphrey — Fri, 29 Jan 2010 21:48:43 +0000

Today I finished-up my work writing automated tests for the Processing.js parser and a full unit test infrastructure. It has been an interesting bit of work, and resulted in a lot of good info. Today I imported Ben and Casey’s sample code from their Processing books, and it was interesting to watch things pass and fail.

Of the 855 Processing files I tested today, 623 were parsed correctly (72%). This leaves 232 that fail for one or more reasons. It’s actually not as bad as it sounds, since there are six main errors I see over and over, for which I’ve filed bugs, and a bunch of other failures that are likely related to my python/js scripts.

I’m pumped to have some new students about to start writing tests and doing more investigations into these bugs. At the same time, we’ve got a new project coming online to do an antlr-based rewrite of the parser.

If you’ve got Processing code that you want to make sure works on the web, let us know so we can add it to our automated test suite.

Lindauson Hazell (Lindauson): Where are the changes?

Fri, 29 Jan 2010 16:54:49 +0000

I’m a bit puzzled... I’ve gone through the mailWindowOverlay.xul and added in the missing command elements associated with the incorrectly enabled menu-items.

Sadly the changes in the script don’t seem to have any effect on the incorrectly enabled menu-items.

There is a comment in the code that mentions a utilityOverlay.xul. I’m gathering that it is being used as a temporary bug fix. I think the utilityOverlay.xul file is overriding the mailWindowOverlay.xul. I’m going to check it out...

[Bug 495815]

Simon Teo (Simon): Runway clear and safe?

Simon — Thu, 28 Jan 2010 14:45:19 +0000

Writing or Reading one’s blog could be very boring, so let me try something interesting….

Fog!!!! – Earlier of the day

Charlie Sierra 3108: ‘Centre, we’re unable to take off. Runway visibility here to less than 50 metres’

My visibility is very poor, I can hardly see where am I heading. I try to clear the fog in front of my view. Did some searches on Mozmill, went through the Tutorial, went through some examples and even throw questions at Gary. On top of that, I went through some of the task my seniors did and I must admit some of their work is really well done. I would like to share the work done by Hendrik, who have built an extension for Mozilla Firefox browser to clear the Password field of a particular specific field and on top of that did a mozmill automated testing on his extension. I’m really impressed by his work. I hope I can be as good as him. I would like to get myself familiar with this framework.

Help is no where? It’s now here! – Lessons

Tower: ‘Charlie Sierra 3108, the fog have been cleared with the aid of Fog Fences‘

The two hours of tutorial with Gary indeed cleared most of my doubt, cleared my fog, gave me a clear visibility of my runway! Now I know what I want to do after the lesson!

Gary has been a really gr8 (“Great” I know, no short form!) help to me. He guides me to where I want to… I ready to go now….

Proposal

Now that I’m at the starting grid, I would like to plan what I want to do in the near future, and where I want fly to eventually!
So here’s my very initial draft….

Plans for Near future

Get familiar with the Mozmill Framework
- Go through some more examples
- try out ‘Hello World’ tutorial
- try out one or more of the existing test cases done by someone and compare with them
Visit Litmus.Mozilla.org
- Identify those manual testing that Mozmill don’t have
Try to program my first unique Mozmill test on a Litmus test
To be updated…

Plans for the future

Contribute to the Open Source society.
More to come!

In order for a plane to be able to clear the runway during take-off, a plane will need to have 70 percent of its take-off speed by the time it reaches the half-way point on the runway…

I hope I can reached my 70% take off speed as soon as possible! Wish me the best! Thanks for reading! Hope you don’t get bored by reading my Blog!

Sincerely,
Simon

Benjamin Smedberg (bsmedberg): Multi-Process Plugins on By Default

benjamin@smedbergs.us (Benjamin Smedberg) — Thu, 28 Jan 2010 14:17:09 +0000

Out-of-process plugins (OOPP) are now on by default in mozilla-central! Starting tomorrow morning, the mozilla-central nightly builds will load Flash and all other plugins in a separate process by default (on Windows and Linux). The Electrolysis team would love for people to test any plugins on their system, especially less-popular plugins.

Since we are moving relatively quickly with multi-process plugins, there are a few known issues to be aware of:

The plugin-crash UI is not finished. The current UI is just a non-localized dialog so that we can get crash reports from nightly testers. This will be changed soon!
On Windows, tearing/repainting issues when scrolling, bug 535295
On Linux, compiz effects and Flash don’t work together on some systems, bug 535612
On Windows, selecting “Print” option in Flash may lock up Firefox, bug 538918
On Windows, hulu won’t switch to full-screen mode, bug 539658
On Linux with GTK+-2.18 or later, GDK assertions and a fatal XError, bug 540197
Firefox-process crashes at NPObjWrapper_NewResolve with silverlight and sometimes Flash, bug 542263

If you discover crashes while running nightlies, please make sure you submit them, and check about:crashes for the crash ID and signature. We could use help making sure plugin-related crashes and instability are filed and tracked by searching for signatures here and filing bugs in the Core:Plug-Ins component.

If your browser hangs, you can probably recover by killing the mozilla-runtime process in the Windows task manager or via `kill` on Linux. If you are a developer with a debugger, please use the Mozilla symbol server and get stacks for both the Firefox process and the mozilla-runtime process and file a bug.

In some cases, it may be useful to the Electrolysis developers if you obtain a plugin log, which is a log of calls made between the plugin and the browser. Instructions for obtaining the log are available here.

I am very excited that we’ve made it this far, and I look forward to our next milestone release, which will backport these changes to the 1.9.2 release in preparation for Firefox Lorentz.

If for some reason you need to disable multi-process plugins, set the pref dom.ipc.plugins.enabled to false.

Daniel Le Duc Khoi Nguyen (Libras2909): Mozilla Project – the fun has just started

libras2909 — Thu, 28 Jan 2010 09:27:11 +0000

Hi CS3108 buddies,

I have always wanted to participate in a open-source project for a long time. I think open-source softwares are what the world need in order to promote freedom in computing age.

Therefore I enrolled in CS3108 – Mozilla Project offered by SoC. To most people, this is a tough module (just look at the size of our class now, only 3 left). But to me, the fun has just started

The first thing I want to mention about this module is that we have Gary as our instructor. He is actually very nice, and he always offer help to others if he can. I remembered last week he spent an hour after class answering my curious questions. Somehow, we’re gonna be on our own soon *scary*

I’ve spent quite some time researching I/O interface of Firefox. Besides Bug 538015 which is still not confirmed as a bug, I plan on working on Bug 489091. At first I think will be an easy bug. But I have to research I/O interface, how to get the zoom value of a tab, how sessionstore.js are stored … The last one I still not figure out, couldn’t find any documentation on that. Anyway I do believe this will be the first bug I fix.

Next class starts in 30min … See CS3108 folks over there

Mark Finkle (mfinkle): XULRunner 1.9.0.x Releases – The End is Near

Mark Finkle — Thu, 28 Jan 2010 05:46:37 +0000

Mozilla is currently, building and releasing XULRunner simultaneously with Firefox releases. Releases can be found here.

XULRunner releases for 1.9.0, 1.9.1 and 1.9.2 branches (matching Firefox 3.0, 3.5 and 3.6 respectively) are available. The question now becomes “How long does Mozilla keep releasing older branches of XULRunner?” We’d like to re-purpose some of the resources used to build older branches.

Therefore, we intend to stop posting XULRunner builds and releases from the 1.9.0.x branch soon. This would only affect Mozilla building and releasing XULRunner 1.9.0.x. The source code to XULRunner 1.9.0.x would remain available and developers could always build and release their own XULRunner packages from the source code.

Security updates and fixes may still happen on the 1.9.0 branch. If you depend on the 1.9.0 branch and want to get these fixes into your project, you’ll need to build XULRunner yourself.

Mozilla will continue to build and release XULRunner from the 1.9.1 and 1.9.2 branches.

Please feel free to provide feedback on the pros and cons. We’d be interested in knowing how this action affects users of prebuilt XULRunner releases. Follow up on the newsgroup posting.

Chris Cai (anttyc): For my eyes only

anttyc — Thu, 28 Jan 2010 03:42:35 +0000

Ok, just a quick post on bugs that I’ll probably be tinkering with and solving to learn a little more of how Thunderbird works.

Bug 236512 - “Get Mail” button stops working after successfully getting mail several times – imap
Bug 236588 - please add an auto-update function for the addressbook
Bug 238398 – checkbox for copy to Sent folder
Bug 305902 – Wrong ‘total’ and ‘unread’ number in saved search folders in some cases

These should help me figure out the main functionalities of the client.

As for what I plan to accomplish this semester..

My initial plan was to create an addon that helped stream online radiostations(In particular, my own University’s), but I realised it’s probably going to be much too ambitious.

Another idea is to add a threaded view for messages, ala Gmail, where the messages are concat-ed into a long conversation like view(with forwarded parts compressed). Currently, you can see the thread in the “subjects” pane and in a conversation window. Not sure how useful this is but some might prefer it.

The search function of Thunderbird looks interesting too.(strangely it is also less laggy in response than the main window but oh well). Can’t think of any improvements off the top of my head but I’ll bring it up in class and see if anyone has any suggestions.

Or maybe work with Simon on Mozmil(Which Gary initially started), we work well as a team and he did mention that it’s a pretty heavy.

Food for thought: I have only been using Thunderbird for a week and it has taken some time to get used to the interface and explore the features. It helps to be familiar with how a user would view/use the application. Right now I’m finding trouble making improvements because I have not used it for very long.

Srirang G Doddihal (Brahmana): Script to get nsIWebProgressListener state names from state codes

noreply@blogger.com (Brahmana (Srirang)) — Wed, 27 Jan 2010 19:20:38 +0000

This is totally Mozilla specific and probably will not make any sense to anyone not involved with Mozilla code.

So in Mozilla there is an interface named nsIWebProgressListener which can be used to get notifications about any web progress -- a page load in simple terms. So these notifications are sent to us by calling our onStateChange methods. One of the parameters passed is the state of the request. This is a hex code. Memorizing all the hex codes is insane. So to log the states I wrote a small, dumb, script.

I wanted to put it somewhere on the internet, instead of a file on my disk, and hence this blog post. Here is the script to convert nsIWebProgressListener state hex codes to state names. A simple lookup function, but handy for logging


var flagNames = [
"STATE_START",
"STATE_REDIRECTING",
"STATE_TRANSFERRING",
"STATE_NEGOTIATING",
"STATE_STOP",
"STATE_IS_REQUEST",
"STATE_IS_DOCUMENT",
"STATE_IS_NETWORK",
"STATE_IS_WINDOW",
"STATE_RESTORING"
]

var flagValues = [
0x00000001,
0x00000002,
0x00000004,
0x00000008,
0x00000010,
0x00010000,
0x00020000,
0x00040000,
0x00080000,
0x01000000
]

function splitFlags(aFlag) {
var states = ""
for(var i in flagValues)
{
if(aFlag & flagValues[i])
{
    states+= flagNames[i] + "\n";
}
}
return states;
}

That's it.

Mark Surman (surman): A truly global drumbeat

msurman — Tue, 26 Jan 2010 16:32:31 +0000

At it’s simplest, Mozilla Drumbeat is about everyday internet users using technology to make and do things that will keep the web open for the long haul. Diversity will be a critical to this. Drumbeat needs to engage the huge diversity of people who use the web in their work and play. Teachers. Artists. Lawyers. Filmmakers. Children. Everyone. It also needs to reflect — and be shaped by — the diversity of cultures that make up the web. Drumbeat needs to be truly global right from the start.

Building this kind of global diversity into Drumbeat is something I’ve been thinking about a great deal. Personally, I believe seeking out and supporting community leaders from as many parts of the world as possible is one of the most important things we can do during Drumbeat’s first year. While I’ve got a few thoughts on how to do this, ideas and participation from across the Mozilla community will be essential if we’re going to succeed. The aim of this post is to outline some ideas on making sure Drumbeat is truly global — and to ask for your help.

First, a few principles

A good place to start is with guiding principles. There are at least three very obvious things that we should be thinking about during these early days of Drumbeat.

Build diverse leadership at the edges early on. Drumbeat will be defined by the community leaders who step forward to start projects and organize events. We need to actively seek out these people on the edges of our networks, and not just where we already know people.
Make sure Drumbeat is relevant where the internet is growing most. The number of Internet users is growing rapidly in places like Asia, South America and the Middle East. These are good places for Drumbeat because new citizens of the web are coming online every day — and that is the perfect time to engage people around ideas like participation and openness. When the web is still a fresh experience.
Work in many languages. This will be critical. Right now, Drumbeat is happening mainly in English. Getting discussions — and then web infrastructure — happening in more languages is a big priority. We need your help with this (see below).

Of course, this is just a jumping off point. I suspect others who have done this before can suggest additional guiding principles to consider (please post comments). Still, if we can live up to these three principles, we’ll be headed in the right direction.

Some ideas on getting started

In order to get started, we need to make it as easy as we can for anyone anywhere to get involved. We also need to take most of Drumbeat’s important first steps outside of North America. We’re actively working on both of these things. A few early examples:

Make it easy for people to organize local events. My belief is that many of the first Drumbeat community leaders will come from small local events. We’re currently developing an event template to make it easy for people to run these events. We’re also going to offer training sessions for would be event organizers in various regional hub cities. The first of these events and trainings will likely happen in Brasil in March, with Europe following quickly in April. We also did some pilot events in Singapore and India late last year.
Hire diverse staff, and spreading them around. We’ve already committed to putting new Mozilla Foundation staff in Paris. And, we’re considering contractors and project leaders in Singapore, Brasil and India. Eventually, we can put people wherever there is real leadership and talent — just as Mozilla does w/ Firefox and Thunderbird development. Also, we’re giving a strong preference to people who are multilingual in all of our hiring.
Work with the existing Mozilla community. Mozilla already knows how to build diverse, global communities — that’s what Mozilla is. Many long time Mozillians have already pitched in with advice, project ideas, web site help and (probably most important) introductions to people outside the community who have something to contribute to Drumbeat. We’re hoping more community members can help us get rolling, even if simply by promoting Drumbeat and encouraging their friends to get involved.

The location of the first annual Drumbeat Festival will also be an important decision in all of this. We’ve already decided that it *will not* be in North America. Europe or the Middle East are likely. Amsterdam and Istanbul have been suggested as good options, althought we’re open to others and haven’t decided yet.

Drumbeat needs your help

As I said above, making sure Drumbeat is truly global isn’t something any one person — or even all the existing Drumbeat community members — can do alone. We need your help. Here are a few simple things that you can do right now to pitch in if you’re interested:

Blog about and discuss Drumbeat in your own language. A simple blog posting explaining Drumbeat in your language would be a huge help. Starting a newsgroup or some other kind of online discussion would help even more. Obviously, one benefit of this is that we get the word out in many languages. The even more important benefit is that your writing can help us test how we’re thinking about Drumbeat in many cultures. This is critical to evolving the ideas behind Drumbeat. If you write something, please post a link below or in the Drumbeat newsgroup.
Organize an event. Organizing a small, informal Drumbeat event in your city sometime during 2010 is probably the best way you can stir up community energy — especially if you can invite non-techie people like teachers, artists, lawyers and so on. We’ll be posting an event template for feedback within the next week. If you think you want to organize an event, send me mail or comment below. I’ll make sure to get in touch when the template is up online.
Propose a project. Right now, the majority of the project ideas proposed for Drumbeat come from people in North America. This is something we urgently need to change. If you have a good Drumbeat idea — something that revolves around everyday web users *making* or *doing* something to make the web more open — then you should propose it. Soon, you’ll be able to post project ideas on the alpha Drumbeat web site. For now, you can use this wiki page. Post your project idea in whatever language you want to run the project in.

Eventually, we’ll also need help with localization — both developing a plan and doing the translation. We need to get the Drumbeat alpha site up, tested and improved first. But localization is clearly an area where community participation will be needed.

A final thought

One of the things that has always impressed about the Mozilla community is its ability to simultaneously focus on a strong, global idea and embrace the fact that every part of the world is different. You see this in Firefox, and in how people talk about Mozilla’s values. It’s exactly this type of balance that we need to strike with Drumbeat. The core idea of people using technology to make and do things that create a better, more open web can hopefully resonate everywhere — but only because projects and communities emerge around the world that are grounded in local ideas about what the open web is and why it matters.

Posted in mozilla

Nikhil Kapur (Nik): libvorbis and Milepost

noreply@blogger.com (Nik) — Tue, 26 Jan 2010 16:31:38 +0000

After integrating Milepost into nspr, I found that it was not possible to measure the performance boost there. So Dan suggested that I try the same thing for libvorbis, the ogg library which is used for html5 video. So I started working on that, and as now I'm used to the mozilla build system it didn't take too long to perform the same steps, with minor variations for libvorbis.
Unfortunately, while using Milepost for libvorbis, I am now facing a compilation error on the file vorbis_res0.c. It works perfectly fine as long as I am not using Milepost, but the moment I enable Milepost, it gives a compilation error.
I have informed the cTuning people about this, and a thread is running here. It might just be that its something I am doing wrong, but frankly I can't think of anything. I hope they can give me a solution to the problem soon.
Lastly, I still cannot try checking the perf boost, because the Web Service is still not running properly. I have informed the cTuning people about this too and they are working on it right now. I hope it gets resolved soon, because until it does, I am stuck with nowhere to go.

Nikhil Kapur (Nik): nspr and Milepost

noreply@blogger.com (Nik) — Tue, 26 Jan 2010 16:31:11 +0000

I haven't posted for some time now, mainly because I did not have anything concrete, but now I am regretting that. There are so many tweaks here and there that I have done in the past 10 days or so to be able to integrate Milepost GCC into the Mozilla build-system that I am finding it difficult to remember all of them. Still, I'll give here a brief sum up of my progress since the last time.

Well it started with a chat with Dan (dwitte). And he suggested that we start work with SpiderMonkey and try and get Milepost integrated there, because the build system of SpiderMonkey is the same as Mozilla. He also suggested that we try and tweak the code written for PGO which also uses two passes on the system. So off I dived into PGO, got tangled up in makefiles and configures and whatnots and then finally had to approach Ted (ted) to make some sense out of all of it :). And then I got to know about config.mk which sets the CFLAGS and then all the fog cleared :). So I basically figured how PGO was working, but Ted told me that it had been disabled on Linux. Anyways, it helped me a lot in how to call multiple makes etc.

So I started trying to integrate Milepost into SpiderMonkey when I came across this discussion on the cTuning group which said that C++ is not currently supported and I saw that most of the files I was compiling were cpp, so I had run into a dead-end. So then off I went to Dave(humph) and Ted and they gave me names of some C-only modules and humph suggested nspr, a C-only module which provides a platform independent API for system level functions. So then I had to start again with nspr, although it was quite similar to SpiderMonkey and much simpler to understand :).

After much banging heads against the build-system I managed to understand the flow and I now knew what I had to do. So I created a "milepostbuild" target, similar to a "profiledbuild" target of PGO, which would call submakes, changing the environment variables as required by the ICI plugins of Milepost everytime. It was a huge task in itself to find out how to export the variables to the current shell in the first place but I finally managed. I am currently exporting them initially in configure, and to call configure I am using "source ../configure" in bash instead of a normal "./configure". This sets up my variables in the current shell and now I can make whatever changes I want to these variables while calling make again from the makefile by adding VAR=Val alongside.

This done, I now had to get the ICI plugins to work with the build, properly. For this I needed to add the filename of the source file being compiled by gcc to the files that the plugins create, which basically contain the executed passes (.txt) and the static features (.ft). I couldn't find a way to do this at first and I found myself wandering here and there in the gcc code with no idea at all, but after some searching I found the "function_filename" feature which would be able to return the filename. I used it and it worked fine on my small programs, but it did not work when I used the same thing in the build. Finally, I realised that it was because of the relative path of the filename being returned instead of the filename itself, and then I mended that and voila, everything works now!

So, I am now able to extract the gcc executed passes for each nspr file and its respective static features. I have to integrate the web service in now, to predict the flags using the extracted features, but right now there is some problem with the cTuning web services. Also, there is a slight problem regarding the passes for which I need help from the Milepost people. Lastly, although I am currently trying to make this work on a file-to-file basis, what we really need is something that can work on the whole module in one go, as working on each file, especially using a web service, takes a lot of time and as Dwitte mentioned, it won't scale. Already I see that my build time for nspr has changed from seconds to minutes, when I haven't even used the web service yet. I have posted the same concern to the Milepost authors and hope to receive a positive reply...

Chris Cai (anttyc): A sign post

anttyc — Tue, 26 Jan 2010 16:08:01 +0000

Heyo! This is Chris keeping a record of my experience in CS3108, a course that gives us a taste of open-source development. Since this is my first post, I’ll give a short introduction of myself and my reflection of the work I’ve done so far.

I’m a second year student in the NUS(School of Computing). I’ve mainly had experience creating and maintaining web sites, dabbling in PHP, Ruby on Rails among other things. I believe that technology has developed to be much more than a tool for everyday purposes and now Open Sourced development is a powerful force in driving innovation with limited resources and a whole lot of passion.

I first heard of this course through prof Damith and thought it sounded interesting. but also a little out of my league. considering I’ve only been doing pretty amature coding so far. but I’ve always dreamed of creating my own addon/ contributing to the open source community.

When my friend Simon(link) emailed me and asked if I wanted to join in, I thought it would be a great opportunity to learn!

Anywho, I’ll probably insert bits of my random ramblings among my reflections on the course.

Reflections of the 1st couple of weeks

The first couple of lessons were casual, with us absorbing the experiences of the previous batches, thanks Jason and (link) for sharing their insights with us. getting into the ubuntu environment was a litlle jarring. But at the same time, I found myself spending hours lost in experimenting and tweaking the system, fun times.

after the second lesson I started exploring Bugzilla and the different bugs marked “Student-Project” for Firefox. I quickly realised that it probably wasn’t a good idea just yet. Though the projects seemed doable, it would probably take me much more time than I could possibly find in the semester. So I followed Gary’s suggestion to start to take a look at Thunderbird, Mozilla’s email client.

I started off my actually using the Client everyday, I’m more of a webbased client kind of guy simply because I’m more familiar with the format. But I think there can be some ideas that are implemented in Gmail’s web client that could be ported into Thunderbird. I’ll probably run them by Gary some time this week. Mean while, I found a few interesting bugs that I’ll poke into to get a feel of it.

Boris Zbarsky (bz): H.264 patents outside the US

bzbarsky — Tue, 26 Jan 2010 03:47:26 +0000

I've seen a number of comments recently along the lines of "I'm in Europe, so the H.264 patents don't apply to me; why are you not letting me have a browser that plays my Youtube videos?" So I took a look at the list of patents on H.264. Or rather, the first 6 pages of the 43 page list. Excluding the US, there are relevant patents granted in at least the following countries:

Europe: Germany, France, UK, Finland, Italy, Sweden, Belgium, Bulgaria, Liechtenstein, Austria, Czech Republic, Denmark, Spain, Hungary, Ireland, The Netherlands, Poland, Romania, Portugal, Slovenia
Asia: Japan, China, South Korea, Hong Kong, Singapore, Taiwan, India
Americas: Canada, Mexico
Australia

I wasn't reading very carefully; I'd be suprised if I didn't miss a few, or if a few more don't come later in the list somewhere.

David Humphrey (humph): On the joys of the test harness

david.humphrey — Tue, 26 Jan 2010 02:35:12 +0000

This is the story of my favourite kind of programming. The kind of programming where you have a handful of existing tools, a bunch of data, and you need to make it all fit together somehow. There’s no neat-shrink-wrapped-sofware-download-it-from-the-web way to do it (none of this stuff was meant to go together), so you start hacking your tools, abusing data formats, work in multiple languages, and otherwise get round pegs to slide smoothly into square holes.

Today’s fun comes as a result of the need for a test harness to drive automated tests for the Processing.js parser. I tell it in large part to help my students see how one leverages open technologies and formats on the way to solving otherwise unsolvable problems. There’s no button in Visual Studio for what we’re about to do here.

The story is set within the Processing for the Web project, which is making a JavaScript version of Processing. The past few days we’ve been trying to track down some bugs related to the parser. Right now, there is a clever hack in place to take Processing code, and using a series of regular expressions, turn it into pure JavaScript. It’s a nice bit of code, and works pretty well turning the Java-style syntax into something the browser can understand. It’s also very brittle.

What we really need here, and what Processing itself uses, is an antlr based grammar to build our parser on top of JS. Processing basically subclasses the Java antlr grammar, and we could do the same thing, only use the JavaScript target. Probably doing this in parallel to a parser-lite version in the browser, so that you could choose to create your pure JS Processing code once, and then include that in your web pages. I’ve filed a bug, and some unsuspecting student is going to get the chance to work on it soon…

But! before you can go reimplementing a parser, and before you can properly fix regressions in the current one, you need a proper test suite. We really need a simple way to take valid Processing code, and make sure our parser produces valid JavaScript. And we need it now, so we don’t break more code while we fix these bugs. I debated making it a student project for this term, but Al convinced me that we needed it for the next release. So today I wrote a test harness.

The problem is actually pretty simple, but automating it required some thinking. I have a parser written in JS that is meant to be run in a web page, and I need to take lots of Processing code and run it through, some of which I want to pass, some of which I want to fail, etc. In order to automate this, I really want to decouple this from the browser, and do it from the command-line.

A lot of these problems are already solved in the Mozilla context. With Firefox we have a whole slew of testing frameworks and tools to drive our various automated tests. To run a lot of these, we don’t need a full browser, just a JS shell that can execute our JS code and report to stdout. I spoke with Ted today about our issues, and he recommended modeling it on how xpcshell tests work (i.e., js + python + makefile).

The first step was to take a directory of Processing files and turn them into something I could feed into a test harness running in the jsshell. The jsshell can run the Processing.js parser, since it’s just JS, and as long as I can feed the Processing code in, I’m good. There’s even a handy load() function I can use to get files into the jsshell. However, what it loads has to be valid JS and Processing code is anything but. I needed a way to trick the jsshell into loading the Processing code in so I could get it into the parser and tested.

I chose to use python, and decided to write it such that it would scan the test dir for all the files, and turn them into JSON strings, which I could pass on the command-line to the jsshell executable (i.e, ./js -e ‘{code: “x =7;\ny=5;\n…}’), along with my test harness scripts. I then wrote my test harness in JS, which also loads the Processing.js code (i.e., the parser), and then I basically do this:

try {
  eval(Processing(canvas, processing-code));
  _pass()
} catch (e) {
  _fail()
}

The Processing function takes a canvas element (where the graphics will get drawn), and the Processing code, and tries to parse it. What it gives back is pure JS, so we can use eval() to try and execute it. If that works, the generated JS is good, so our test passes; if not, we fail. But there’s another problem: the Processing code assumes there’s a canvas element and a DOM–basically, it assumes it’s running in a web browser as part of a page. But we’re nowhere near a web browser when this runs, so we have to fake it.

The nice thing about JS is that you can create and modify objects, data, functions, whatever on the fly. In my case, I needed to fool the Processing.js parser into thinking that it had access to various DOM functions and objects (e.g., document, setInterval, etc.). My solution was to create dummy functions and object literals that could stand-in for the real thing. The parser doesn’t actually need to call this code; it just needs to be there and non-null. Here’s my setInterval implementation:

var setInterval = function() {};

Using this trick I was able to slowly write all the bits of the fake DOM I needed to get the parser running. As I’ve tried running a few other larger tests, I’ve noticed other bits of the DOM I need to implement, but it’s pretty trivial to add them as I go.

I’ve filed a bug and am waiting for some feedback before a I fix a few more things and get it checked-in. Once I do, I plan to find some other students to write a ton of tests to try and break the parser even more, and then file bugs so we can fix them. Writing tests may not be the most fun you can have, but honestly, writing a test harness is pretty close.

Benjamin Smedberg (bsmedberg): Error calling method on NPObject!

benjamin@smedbergs.us (Benjamin Smedberg) — Mon, 25 Jan 2010 17:30:10 +0000

When a plugin crashes, content script may still have a reference to JS objects provided by that plugin. The JS objects will throw an exception “Error calling method on NPObject” when any properties or methods are called. Unfortunately, this generic error message is also thrown whenever a plugin method fails for any reason. You can’t tell, just by looking at the exception, whether the process crashed or some other type of failure occurred.

This is important when a test fails: there could be any number of different errors lurking under the surface with similar outward appearance. Today there was a Mochitest error with the following symptoms:

197 ERROR TEST-UNEXPECTED-FAIL | /tests/modules/plugin/test/test_painting.html | [SimpleTest/SimpleTest.js, window.onerror] An error occurred - Error calling method on NPObject! at http://localhost:8888/tests/modules/plugin/test/test_painting.html:105
PROCESS-CRASH | automation.py | application crashed (minidump found)
Thread 1 (crashed)
PROCESS-CRASH | automation.py | application crashed (minidump found)
Thread 1 (crashed)
PROCESS-CRASH | automation.py | application crashed (minidump found)
Thread 1 (crashed)
PROCESS-CRASH | automation.py | application crashed (minidump found)
Thread 1 (crashed)

Reading through the log, however, the important output is:

###!!! [RPCChannel][Child][/builds/moz2_slave/mozilla-central-linux/build/ipc/glue/RPCChannel.cpp:276] Assertion (mDeferred.empty() || 1 == mDeferred.size()) failed.  expected mDeferred to have 0 or 1 items, but it has %lu (triggered by rpc)
  local RPC stack size: 2863316886
  remote RPC stack guess: 8
  deferred stack size: 2863316886
  out-of-turn RPC replies stack size: 2863316886
  Pending queue size: 2863317142, front to back:

This assertion is immediately followed by an abort, which is visible in the crash dump output also:

Crash reason:  SIGSEGV
Crash address: 0xbdce4804

Thread 1 (crashed)
 0  libxul.so!mozilla::ipc::RPCChannel::DebugAbort(char const*, int, char const*, char const*, char const*, bool) [ipc_message.h:0235fc257969 : 97 + 0x0]

David B. mistakenly thought that this was a manifestation of Bug 541102 when in fact it is an entirely unrelated bug with similar symptoms. When in doubt about a crash, please check with one of the Electrolysis team to help diagnose and read the log.

Simon Teo (Simon): I’m ready to go!

Simon — Sun, 24 Jan 2010 09:15:49 +0000

CS3108

This is the 2^nd week since the start of my semester 2 in NUS and I got myself enrolled into CS3108, Mozilla, together with my NUS buddy Chris. I got interested in this course when I received an email on this course and the idea of working together with developers globally on Mozilla products.

On the 1^st week of the course, I’m surprised that only a handful of us applied for this course. Together with my buddy, there’s only 1 more of us into this course. Probably Gary has scared most of them away.

I’ve spent most of the time trying to lookout for things which I need to do as well as things which I want to do. I’m lost. I don’t know what am I suppose to do and what’s should be my expectation. Fortunately, after the last tutorial session we have with Gary, I seem to know which direction I’m interested in.

What really interest me is Mozmill, it is an user-interface test automation tool. You can use it to write tests for your Add-On or for your Mozilla Platform (Gecko) Application. I will be trying out the tutorials at the Mozilla Developer Center and get the feel of it. It would be great with I can use Mozmill on Thunderbird. Meanwhile, I’ve been looking up Bugzilla and found a few cases which I deem it’s appropriate to me, the case numbers are Bug 487041 and Bug 540330. Other than those on Mozmill, the other one is Bug 502515.

That’s all for now! =)

Simon

David Humphrey (humph): San Francisco goes Open Source

david.humphrey — Fri, 22 Jan 2010 19:15:57 +0000

There’s a great post over at Mashable by San Francisco mayor, Gavin Newsom, on the city’s new open source policy. In it he discusses the democratic, fiscal, and technical advantages of open source. He writes:

One of the greatest technology changes of our times is the rise of open source software…Open source software is created by the people for the people and as such is ideal for government. To that goal, I am extremely proud to announce today the nation’s first open source software policy for city government.

San Francisco’s new policy requires city departments to consider open source software equally with commercial products when purchasing new software. The opportunities with open source are tremendous: lower costs, greater agility, better reliability, improved security, and increased innovation.

Under the leadership of our City CIO, Chris Vein, and the Department of Technology, we have witnessed the benefits of open source with shorter implementation times and lower costs. We have seen this with my web site, DataSF.org, RecoverySF.org and our 311 integration with Twitter.

This week I’ve been introducing our students to open source, and a lot of our discussions have focused on how open source isn’t a fringe movement anymore–individuals use it, big companies use it, and governments use it. As government budgets continue to shrink, and fiscal responsibility becomes front page news again, open source is being discussed by an ever increasing number of people. Developers in San Francisco have long understood the value of open source on a technical level, but it’s another thing when the mayor’s office gets in the game, too.

If you’re interested to watch this same phenomenon happening in Canada, keep one eye on David Eaves. Hey Mayor Miller, where’s our open source policy?

Joshua Cranmer (jcranmer): Developing new account types, part 0: An introduction

noreply@blogger.com (Joshua Cranmer) — Fri, 22 Jan 2010 17:06:23 +0000

Before I begin the actual discussion, let me give some background. The ability to develop new account types has been my biggest extension goal for about two years now. Probably because of its difficulty, I know of only two extensions that have tried to do it: what is now the RSS code, and Webmail. In the first case, the implementer resorted to creating a binary component for the incoming server; in the latter, the implementer wrote a fake IMAP (and POP, SMTP) server to proxy the information to the web interface.

Some preliminary points: making a new account type is not a Good First Extension. You will need a fair amount of XPCOM experience, and probably decent experience at delving into implementations of undocumented interfaces. How much XUL and DOM (for stuff like webscraping) you use is up to you. MDC has a guide on building a Thunderbird extension from scratch. It is also probably not a bad idea to get comfortable with manual preference editing.

I am also trying a different form of development in this guide. This is not being done via my more common method of manually editing HTML by hand, but by writing in Kompozer. I'm also attempting to get more code included in my posts, and hopefully some images as well (the last part will be hardest). Like my first guide, I do expect that this will be adapted into a series of documents on MDC at some point. Some more reference-oriented documentation will be posted on MDC as I write this.

I personally use a debug version of Thunderbird, on Linux, very near the tip as the source code as the basis for my extension development (my regular profile is some 370 MB of stuff I don't dare threaten with developmental work). This is the same build I do patch development on, so I will rely on patches in said tree from time to time. One patch in particular is required [1], but otherwise, it should work on 1.9.2 and probably 1.9.1 as well.

This guide is structured to first demonstrate the actual activity components (e.g., displaying messages) and only cover configuration (e.g., the wizard to create a new account) when the more basic stuff has been completed. Therefore, you will need to get comfortable with editing configuration files by hand if you follow these steps exactly.

Backend introduction

So, let's start with an overview of the backend interfaces in mailnews. A list of the interfaces a front-end widget might use to talk to an account is: nsIMsgAccount, nsIMsgDatabase, nsIMsgDBView [2], nsIMsgFolder, nsIMsgDBHdr, nsIMsgIdentity, nsIMsgIncomingServer, nsIMsgMailNewsUrl, nsIMsgMessageService, nsIMsgProtocolInfo, nsIChannel, nsIProtocolHandler, and nsIRDFResource. Many of these would need to be implemented, and a few of them are not in any way small; to implement nsIMsgFolder would require a total of 186 methods, setters, and getters (as of this writing), many of which are not well-documented.

In reality, implementations are not from scratch. Everything tends to boil down into two or five different implementing classes: the server, the service, the folder, the url, and the database (there is also typically a protocol implementation as well). Of these, only the service is implemented from scratch, and it gets the simplest interfaces to implement. When I said "two or five," I am referring to the fact that there are actually two types of accounts. The first type, which only has to implement a server and service, can be called mailbox accounts: all of the messages are downloaded into local folders [3]. The second type implements all of the above, as the messages are generally stored on the server and downloaded on demand (or cached).

Of these two types, the less interesting is the first one. I will therefore generally ignore this account type. If you want to make such an account type, look at the RSS implementation for guidelines. The primary distinction is that mailbox accounts lack their own folder types, and therefore databases and URLs. In such a case, all you need to worry about is delivering the messages.

Following is a description of the major implemented components:

Server: The server represents the source of messages for an account. It also serves as the per-account configuration information for implementers. For example, NNTP stores the maximum connection limit to a server off of this implementation.
Folder: The folder represents a container of messages. Ultimately, the UI interacts more with folders than with servers, at least on a regular basis. This is the most complex interface to deal with, primarily because it can be hard to tell precisely what you need to implement versus what (eventually) calls back on some other message.
Database: The database represents a store of a subset of message information. It generally stores by default what NNTP would call overview information (enough to create a threaded message list), plus some flags like read status, as well as some information that extensions which to preserve.
Service: The service is more of a "how-to" guide for accounts. This is the external endpoint for ultimately copying messages, viewing messages, etc. Note that this is the only service implementation, so the actual server communication code typically happens in a different implementation.
URL: URLs are what the name implies. It's how one refers to messages, folders, and servers, although only messages are typically instantiated with the object in question. They also tend to be used as the primary internal communication system.
Protocol: The protocol instance represents a connection to a server. Unlike the other implementations, this one is not mandatory and is typically not visible via the "main" interfaces (nsIChannel is perhaps the most useful one they export). I suspect this is primarily useful for binary protocols, but I have not yet delved far enough into creating a new account to say for certain.

Important interfaces and their interactions

The center of an account is represented by the nsIMsgAccount. To get an idea for the amount of interfaces involved, look at the collaboration diagrams for nsIMsgAccount and nsIMsgFolder.

nsIMsgAccount represents an account. The interface itself is not terribly useful—it's mostly just a step on the way to get to a server or an identity.

nsIMsgIdentity represents an identity. Identities are essentially a way of persisting compose settings; since their use is wholly related to compose code, I will not discuss them in detail until later parts of the guide.

nsIMsgIncomingServer, as mentioned earlier, represents a message source. This is one of the interfaces you will have to implement, although much of it is already done for you. Everything that is specific to a server hangs off of this interface; everything that is specific to a folder hangs off of nsIMsgFolder; folders are accessible via the root folder of a server.

nsIMsgFolder, as mentioned earlier, represents a container of messages. This is one of the interfaces that has to be implemented, unless you are using a mailbox account. All folders have a database.

nsIMsgDatabase represents the message store overview. This has to be implemented if you are implementing nsIMsgFolder (unless you want to be sneaky). Databases are used to get at thread and header information, via nsIMsgThread and nsIMsgDBHdr, respectively. Messages themselves have numerous representations: URIs, header objects, message keys, and (sometimes) message IDs. Conversion between these forms is common.

nsIDBFolderInfo represents folder properties normally stored in the database. All of these properties are also stored in the folder cache (nsIMsgFolderCache) to avoid opening up all of the databases just to figure out how many unread messages are in each folder.

nsIMsgAccountManager and nsIMsgBiffManager are two managers that handle account creation and the periodic mail download (generally called biff), respectively. Expect to see these calling your code a lot.

nsIMsgDBView represents the thread pane view. This is going to be the primary consumer of nsIMsgDatabase, and this is where you should go to look to find out what happens if, e.g., you select a new message.

nsIMsgFilterList, nsIMsgFilterPlugin, nsIMsgFilterService, and nsIMsgFilter are the interfaces that deal with filtering. None of these will have to be implemented to support filtering [4].

The nsIMsgSearch* interfaces are those that deal with search (there are around 9 of them). Most of these will not have to be implemented to support searching. More on this when searching is discussed.

nsIMsgWindow represents the bridge to the front-end. It is passed into many functions, although it may be null, typically when being invoked from the backend.

nsIMsgMailNewsUrl represents the URL object that loads a message. This will generally have to be implemented if nsIMsgFolder is.

nsIMsgProtocolInfo represents the basic information about an account type's capabilities. This interface is one that is required to be implemented. As the name implies, it is generally geared towards the capabilities of the connection to the server.

nsIMsgMessageService and nsIMsgMessageFetchPartService represent the ability to retrieve the message (and message parts, more often known as attachments [5]). This is another interface that one must implement if folders are being implemented.

The MIME, compose, and import interfaces are omitted from this list of backend interfaces, as these are topics that will not be discussed for a while, and I am not certain they are useful to know about making new account types at present.

Notes

The purpose behind this patch is to enable extensions to reuse files from base/utils like C++ components can. If you were to adapt this to use C++ instead of JS, this patch would not be necessary. As the comments in the linked bug indicate, there is no guarantee that this will be implemented for Thunderbird 3.1; however, in such a scenario, the specifically required binary components would be available for reuse on some webpage. More on this when a decision is made.
Strictly speaking, this interface uses other interfaces in the list to talk to you. That said, a lot of interaction with folders and databases happens through this interface.
I say local folders—not Local Folders—here because Global Inbox settings actually rely on POP-specific attributes. It is still possible, via a reimplementation, to change the delivery settings. Such a mechanism is outside the scope of this guide.
It's not strictly necessary to implement these, but if you want to add custom filter terms or actions or custom search terms, some interfaces will need to be implemented. Such actions are beyond the scope of this guide.
Classifying all message parts as attachments is a pretty big oversimplification. In general, the only time specific parts are requested in Thunderbird and SeaMonkey are when attachments are involved. For more information on message parts, please see RFC 2045, RFC 2046 (two of the five MIME specifications), as well as the IMAP FETCH subsection (for numbering).

Benjamin Smedberg (bsmedberg): Firefox 3.6

benjamin@smedbergs.us (Benjamin Smedberg) — Thu, 21 Jan 2010 19:23:43 +0000

We released Firefox 3.6 today. If you are currently running Firefox, choose “Check for Updates” from the Help menu. If you aren’t, go get Firefox 3.6 now! One of our most popular new features is Personas, which you can use to style Firefox the way you want. We’ve also made Firefox faster, more responsive, and more secure than ever.

Mark Finkle (mfinkle): Perils of the viewport meta tag

Mark Finkle — Thu, 21 Jan 2010 15:22:48 +0000

Apple introduced the viewport meta tag in mobile Safari to help web developers improve the presentation of there web pages on the iPhone. We added support for the viewport tag in mobile Firefox for the same reasons.

The viewport tag allows web developers to set the width, height and scale of the browser area used to display web content. However, some websites are not doing a good job configuring the viewport tag and it affects the presentation in Firefox.

When setting the width or height, developers can use a fixed number of pixels or use the constants: device-width and device-height. The iPhone is 320px wide in portrait and 480px wide in landscape. Other devices have different screen sizes. It seems the “width=320″ is a popular fallback though. See how Facebook and DeviantART display in Firefox on the N900 (480px in portrait and 800px in landscape):

touch.facebook.com

deviantart.com

Don’t get me wrong. I like “touch-friendly” web pages on my mobile device. However, the iPhone is not the only mobile device out there. If a web developer has gone through the effort to make a “touch-friendly” web page, please configure your viewport to work in other devices. It’s easy!

David Humphrey (humph): Experiments with audio, part VIII

david.humphrey — Thu, 21 Jan 2010 01:46:07 +0000

I’m working with an ever growing group of web and Mozilla developers, along with some talented audiophiles, on a project to expose audio spectrum data to JavaScript from Firefox’s audio and video elements. Today we bring out the demo reel.

Last time I wrote about our success getting the browser to make dynamically generated sound. Since then we’ve continued our work to expose and use raw audio data, and it has produced some delicious demos. Today I finally got setup to record some of them and show a bit of what’s possible. NOTE: I’ll provide links for all of these, but you need a patched Firefox to see things happen.

The first demo is a visualization of audio spectrum data using the C++ FFT code (the one Corban did before was done with JavaScript). This particular song is perfect for demonstrating beat synchronization, wave changes, etc. Al MacDonald wrote both the code and music (click here to watch video):

The second demo shows how the <video> element can be used in the same way as <audio>. In this video of whales singing to one another, Al once again visualizes the spectrum data, but this time in 3D, and overlays it on the <video> element using <canvas> (click here to watch the video):

The third demo shows both visualization and dynamic generation of audio using JavaScript. In this demo an oscillator module generates a signal which is sent through a Low Pass filter and ADSR Envelope and then written to an <audio> element. The demo was created by Corban Brook, who also wrote the PJSAudio library especially for the task (click here to see the video):

For my part I’ve been busy thinking about how to rewrite my browser implementation so it is done properly. In the third demo you’ll hear some static, since I’m not doing any buffering, which we need in order to deal with latency in generating the audio frames. I’ve got a number of email threads going with people who can help me figure out the API and implementation directions.

In addition to working on code, we’ve also been chatting about the other things we might do with audio in the browser. Here are some of the ideas that have come-up:

Audio Data and Experiencing 3D

As WebGL gets closer to being released, I’ve been thinking about accessibility within 3D scenes. Reading this inspiring article about a blind architect, it made me think about sound in a new way. I’ve got students right now working on light and cameras in 3D web environments, but what about sending sound in too? What if you dynamically sent sound into a 3D scene and had it echo back to you, such that you could judge depth, objects in front of you, different materials, etc. Doing this well requires dynamic transformations of the sound, which is exactly what this work is making possible (Corban’s demo shows the first steps).

Audio Data and Seeing Sound

Still on the subject of accessibility, I’ve been thinking about sound data, and especially the visualization of sound, for those who can’t hear it well, or at all. One of my colleagues first got me thinking in this direction. She can’t hear a lot of the sound her computer makes, and is often unaware that web pages are even making sound. In cases like this, it would be great to have even simple indications that there is sound, how loud it is, etc.. Taking this further, one can imagine exploring ways to make the browser more like the Emoti-Chair or other similar devices, which bring the experience of sound to those who can’t hear it.

Audio Data and Programmatic Approaches to Music

Then there’s the possibility of making music specifically for this medium. We (I’m thinking of people like me who can’t play instruments) tend to think of music as a consumable end-product vs. something you build or assemble. Music is something you buy, something you download, something you play. That’s what text used to be, too. But putting text on the web, and specifically, assembling text using code, changed that forever. Just as we mix text from different sources, dynamically overlay it, transform it, translate it, etc., what if you could listen to music being mixed and altered live in your browser? What if music was one part drum loops and one part repeating sample and both were written in JavaScript? What if those got layered over audio being played from an .ogg file, or got mixed into something happening in a video? What if the music was changed in response to what you were doing in the page? When music becomes algorithmic, scriptable, and composable, any number of new things will happen.

This portion of our experiments has really been about imagining what you might do with something new. The browser hasn’t traditionally been the place where sound gets made. But what if it was? How would music adapt to its new surroundings? What would we expect of it?

I’ll leave you with a quotation from a recent interview with Brian Eno, as he talks about the synthesizer, and innovation in music and sound. When he says ’synthesiser’, replace it with ‘browser’ in your mind, and think about it for a moment:

One of the important things about the synthesiser was that it came without any baggage. A piano comes with a whole history of music. There are all sorts of cultural conventions built into traditional instruments that tell you where and when that instrument comes from. When you play an instrument that does not have any such historical background you are designing sound basically. You’re designing a new instrument. That’s what a synthesiser is essentially. It’s a constantly unfinished instrument. You finish it when you tweak it, and play around with it, and decide how to use it. You can combine a number of cultural references into one new thing.

Boris Zbarsky (bz): From the mouths of babes

bzbarsky — Wed, 20 Jan 2010 05:19:35 +0000

Today Arlan happened to look at my screen when part of the desktop was actually visible. That led to approximately the following conversation:

Arlan:: Папа, там лиса!
Me:: Где? Да, там лиса.
Arlan:: Еще лиса! Две лисы.
Me:: Две?
Arlan:: Один, два, три.... Три лисы!

Little did he know that the fourth one (3.5 to be exact) was hiding under the iTunes window....

Mark Surman (surman): MozFdn in 2010: a status update

msurman — Tue, 19 Jan 2010 16:49:25 +0000

It’s hard to believe that I’m now entering my second full year at Mozilla. Year one was both enlivening and humbling: mind blowingly smart people; cool and useful projects experiments; and a ton of new ideas and learning. Much of this great energy flowed into Drumbeat, which will be the main focus of Mozilla Foundation during 2010. It also helped the Foundation team clarify our thinking on telling the Mozilla story and supporting the broader community. We’ve got a clear and crisp plan for the year ahead.

This coming year, I’m going to use video and slides to provide Mozilla Foundation status updates. Here is the first 2010 status update, which is focused on our plans for the coming year.

<embed allowfullscreen="true" allowscriptaccess="always" flashvars="guid=PYcnDO1s&width=380&height=284&locksize=no&qc_publisherId=p-18-mFEk4J448M" height="284" id="video0" overstretch="true" seamlesstabbing="true" src="http://v.wordpress.com/wp-content/plugins/video/flvplayer.swf?ver=1.15" title="MoFo status update - jan 01 - 02" type="application/x-shockwave-flash" width="380"></embed>

You can also view this in open video (ogg theora) and download the slide deck (PDF).

As with the text status updates I was provided last year, the video and slides offer slightly shorter version of the info presented at our most recent board meeting. I’ll continue to provide these updates every two months, following the board meeting schedule. Comments on both the content and this new format welcomed.

Posted in mozilla, statusupdate

Mark Finkle (mfinkle): Prism 1.0 Beta 3 – Getting Closer To Final Release

Mark Finkle — Tue, 19 Jan 2010 15:52:23 +0000

Prism’s long march to final release got a little closer recently with the release of Prism 1.0 Beta 3 (Linux too). Prism is now using the same Gecko 1.9.2 as used in the newest Firefox 3.6 release. A big thanks to Matt Gertner for keeping Prism development moving along. Firefox for Mobile has been keeping me very busy.

I noticed some other people are eager for a Prism release too: Webmonkey, Business2.0, Reddit

Mark Surman (surman): Learning from 10 yrs of Bugzilla data

msurman — Mon, 18 Jan 2010 17:00:26 +0000

Diederik van Liere is a postdoc at Toronto’s Rotman School of Business. His passion: finding out whether open source communities actually make software better, faster. With this in mind he’s taken an in depth look at 10 years of bugzilla.mozilla.org data to look for bug fixing patterns.

Here is a (very amateurish) video of a talk Diederik gave at the Mozilla Toronto office last Friday:

You can also view this in open video (ogg theora) and download the full slide deck (more slides than you see in the video) as a PDF.

Following the presentation on Friday, the Moz-TO crew gave Diederik all kinds of constructive feedback on how to make this research better — mostly around different ways to run the data. If you have similar suggestions, please post comments and I will pass them on.

Posted in mozilla

Mark Surman (surman): January Mozilla Drumbeat update

msurman — Fri, 15 Jan 2010 19:56:08 +0000

Drumbeat – and growing the number and diversity of people participating in Mozilla — will be the main focus for the Mozilla Foundation team in 2010. I’m super psyched about this, especially about the community projects that are taking shape. I’ll be blogging more about some of these projects soon.

In addition to posting about projects, I figured I should post a broad overview of what’s going on with Drumbeat on a monthly basis. This is the first of these updates.

Headlines

First steps in Drumbeat roll out started late November.
Early participation is promising. Join the newsgroup to get involved.
Proposed projects now over 20. Have an idea? Propose a project.
Plans emerging for ~5 regional Drumbeat events in Q1 and Q2 of 2010.
Drumbeat site making good progress. Release in beta early February.
We’re recruiting two ‘project producers’ for Drumbeat — Paris and Mtn View.

Early participation

Since November starup: 100+ people on new mail list, ~15 people heavily engaged.
These people helping on website and general Drumbeat concept.
20+ proposed projects = another ~60 early participants.
Real buzz. “I’ve heard about that. It’s exactly what Mozilla should do.”
Also: a bit of early press coverage, which got slashdotted.

Projects

Bootstrapping a few projects that show what Drumbeat looks like remains our biggest priority.
Three projects that fall into this ‘let’s bootstrap and run fast’ category include:
- P2PU Open Web Career Track -> Creating an alternative to expensive, proprietary tech education, and teaching open web development skills as we go.
- Visualizing the (open) internet -> Artists, programmers and everyday web users creating data visualizations that help us understand the living, breathing organism that is the ‘net.
- WebMadeMovie -> Four Directors. Four hackers. And the citizens of the web. Telling the story of the internet, and inventing the future of online cinema along the way.
See complete list of projects here. Propose a project idea here.

Events

~5 Mozilla run regional events in the works to kick off Drumbeat.
Idea: local open web festivals, people share and work on Drumbeat projects.
Start in ’seed cities’. Train people from nearby cities to organize own events at same time. Aim: create ripple effect.
Once we’re rolling, anyone can organize an event anywhere.
Rome, Sao Paulo, Boston, Bangalore as possible ’seed cities’.
Also: possible Drumbeat event partnership w/ OReilly’s global ignite week.
All of this will feed into Drumbeat Festival late 2010.

Web site

Web site’s primary role is to attract participation and support for projects.
Anyone can propose a project, very best ones get highlighted and (small) seed funding.
Will also serve as hub for local events people are organizing around the world.
Site being developed in Drupal and CiviCRM. Beta in February.
Still need to develop a localization plan — community help wanted on this.
Look for a more detailed web site update on Matt Thompson’s blog soon.

As above, the aim with this (and future) posts is a high level overview for people who aren’t deeply involved in Drumbeat. For more detail or to get involved, jump into the Drumbeat wiki and newsgroup.

Posted in drumbeat, mozilla

Mark Finkle (mfinkle): Add-ons and Restarts – Yuck!

Mark Finkle — Wed, 13 Jan 2010 14:30:00 +0000

There has been a lot of discussion about the future of the Mozilla add-on infrastructure. I think it’s clear now that Mozilla is not removing the classic add-on mechanism. In fact, Fabrice Desré found a nice bit of news on an upcoming feature (via comments on Atul’s post):

Fabrice: Does the fact that jetpacks are now XPIs mean that the “no restart after install” feature will be implemented for traditionnal add-ons ?

Atul: That’s correct! We don’t have a bug filed for it yet, still need to do that, but the idea is that if an extension includes certain metadata in its install.rdf that essentially tells Firefox “look, I know how to unload all my resources reliably”, then Firefox will trust it and call a certain function whenever the extension needs to unload itself.

Mossop: I’ll just elaborate a little. Plans are naturally in flux right now but the idea is to allow XPI packages to install without restarts if they wish, however there will be constraints. They will be responsible for doing everything themselves, which means (at least in my head right now) we won’t automatically load chrome or components from these extensions. Instead we will just do startup and shutdown calls into the extension and allow it to register/unregister what it needs by itself. This means that just marking an existing extension to work without restarts wouldn’t get you anywhere, you still need to do the extra work to handle the startup/shutdown parts.

This is great news for add-on developers! I’m sure MDC will have some code snippets for dynamically loading chrome overlays and components to make it easy to support no-restart add-ons.

Boris Zbarsky (bz): More on distcc

bzbarsky — Mon, 11 Jan 2010 20:48:36 +0000

A few days ago I mentioned that I've been experimenting with distcc. I finally took the time to do some timings. All times below, unless stated otherwise, are for a completely clean debug non-libxul build on my Mac. In particular, none of the files are in ccache, but ccache _is_ being used (so the compile time includes the cost of caching the new object files). distcc is being invoked via CCACHE_PREFIX. The distcc builds were done with -j10 (I also tried higher -j numbers and saw things between no effect and a slowdown as I got up close to -j20) and allowing 10 distcc connections to the server. The non-distcc builds were done with -j3, which is my normal build setup (since the mac in question only has 2 cores). distcc over ssh did not use ssh connection sharing, and was doing X forwarding on each ssh connection; I should retest with those two things changed at some point, if I decide I don't like doing things over tcp. The network is a wireless 802.11g on the Mac laptop end and gigabit ethernet to the wireless router on the Linux desktop. I found that ,lzo for the distcc builds didn't materially affect things (may have made the build 1-2% faster when used).

Build type	Time
local build on the Mac	38 minutes
distcc over ssh	50 minutes
distcc over tcp	32 minutes

This was obviously distressing. I didn't test distcc over ssh after this, but particularly distressing was the fact that the compilation seemed largely diskbound and therefore distcc didn't help much. This got me started looking into hard drive performance as a function of utilization, since I could swear that the Mac's hard drive has been getting slower as it fills up. Turns out, this is actually the case. So I moved my rarely-used Linux VM to an external hard drive, which took free space on my internal disk from 4GB to 65GB or so. With that change done:

Build type	Time
local build on the Mac</dr>	32 minutes
distcc over tcp	22.5 minutes

Progress! Next, I tried dropping ccache, which let me measure the impact of pump mode. Since I do generally see a benefit from ccache, and wanted to measure it, I also tried a build without distcc but with a primed ccache (so build a tree, delete the objdir, rebuild that tree). Results:

Build type	Time
no-ccache distcc in pump mode	16 minutes
no-ccache distcc without pump mode	17 minutes
Local build coming entirely from ccache	15 minutes

So if I were pretty sure I'd almost always be near this Linux box, just not using ccache and using pump mode might be the way to go. As it is, using distcc + ccache seems like a good approach for now.

Now all I need is a way to figure out a way to get this sort of data without it taking several hours, a way to pick good values for -j, and a faster internal hard drive in this laptop.

David Humphrey (humph): Experiments with audio, part VII

david.humphrey — Mon, 11 Jan 2010 20:30:05 +0000

I’m working with a group of web and Mozilla developers, along with some talented audiophiles, on a project to expose audio spectrum data to JavaScript from Firefox’s audio and video elements. Today we teach the browser how to sing.

Our experiments to expose audio data to JavaScript have really started to get exciting. Since I last posted, a number of new features and demos have been created, and our group of developers has continued to expand. This was greatly helped by the fact that the story was picked up by Ajaxian, Hacker News, and Reddit. If you’d like to help us experiment more, please get in touch.

Previously I linked to a video of a demo made by Corban Brook, in which he uses JavaScript to calculate an FFT, and then visualizes the resulting spectrum data. After this test we wanted to see how expensive these calculations were in script, so I ported his code to C++ and stuck it into the audio element’s decode loop. A number of people have expressed concern over the idea of doing this in JavaScript and the cost in terms of speed and time you could spend on other work (e.g., complex real-time graphics). Therefore, I wanted to have a good way to compare speeds. I’ve already received feedback in the bug that native FFT calculations probably aren’t warranted, and we should optimize the JavaScript case. I anticipated this, and having been involved with as much 3D in the browser as we have, I know that JavaScript is up to the challenge of doing very fast calculations. As soon as I convert over to the faster WebGL arrays I’ll do some tests comparing JS-FFT and Native-FFT so we have better numbers. In the mean time, the C++ FFT is working really well, and a number of new visualizations have been done with it, including this one by Thomas Saunders.

Another thing we’ve got working is generating and writing audio directly from JavaScript. So far in these experiments, I’ve been focused on creating a real-time event with raw audio data. I did this in response to the various Flash and other audio developers who have all told me they need some way to get data as it’s being played. Now that this is working well, I decided to turn my attention to what Vlad suggested in the bug, namely doing a get/set style method.

I’ve been stumped on the right way to do this for a while. Actually adding the method is pretty easy. What I’ve been trying to think through is how you deal with the linearity of audio, and the fact that unlike a canvas (which also lets you do a get/set) the audio data isn’t necessarily there to get (e.g., it is yet to be downloaded/decoded). I’m sure there are good solutions to these problems, but they’ve eluded me thus far.

I ended-up chatting about it with Rob Campbell and Ted Mielczarek, and together we hatched a plan: what if, for the sake of experimenting, you just added a “write” method, and let JavaScript dump raw audio? Imagine an <audio> element with no source, totally controlled by JavaScript. Since I already have an event that gives data as it’s decoded, it would then be possible to have one audio element decode, get the data and transform it somehow in script, then dump it into a second audio. Is this the right way? Probably not (the implementation is completely wrong no matter what). But it was simple enough to do a Friday-afternoon-evil-hack and write a patch. So I did.

I added two new methods to audio/video:

mozSetup(channels, rate, volume) // called to create the audio stream
mozWriteAudio(buffer[], bufferCount) // called to write buffer to the stream

Ted then wrote a simple Tone Generator, and Al MacDonald took that and wrote what I believe to be the first ever HTML document that can play scales using nothing but JavaScript (seriously, check out the source for yourself)! Here’s a video of it in action:

Next time I hope to show some other demos that my colleagues have created or are creating now. It is ridiculously fun to iterate on this stuff. That’s partly due to the fact that I’ve got such a talented group of people working with me. But it’s also due to how “hackable” this code is to begin with. The fact that we can go from a back-of-the-napkin idea and then turn that into a working (if somewhat evil) patch in a couple of hours speaks to how well this stuff was written in the first place. There’s a good discussion going right now about View Source, and how important it is. What we’re doing in these experiments is View Source all the way down: we work in terms of HTML5 and the Open Web, but underneath is this amazing browser and platform, and underneath that the audio lib, etc. The only thing that enables this kind of experimentation and collaboration is the existence of View Source, and the kinds of communities that can form around it.

Boris Zbarsky (bz): Toolwhip, distcc, and faster compiles

bzbarsky — Fri, 08 Jan 2010 21:19:27 +0000

Ted recently pointed me to the toolwhip project, which is a way to run Apple's gcc on Linux, cross-compiling to produce Mac binaries. Clearly desirable, since my Linux box is a lot faster than my Mac one. Here are the steps to get it working, as far as I can tell, at least if you Mac has OS X 10.5:

Grab yourself a toolwhip tree following their directions.
Follow the instructions in cctools.README to compile and install cctools. Note that the toolwhip tree comes with an existing usr_include so you can ignore the REQUIREMENTS section in this readme.
Follow the instructions in ld64.README to compile and install ld64. Once again, you can ignore the REQUIREMENTS section.
Download the Apple gcc source for the exact compiler version you want from the Apple site and untar it into a directory called gcc_42-5574 or gcc_42-5566 in your toolwhip source tree. If you plan to use this compiler with distcc, make sure it's the same exact version as that installed on your Mac. If you just plan to cross-compile, I'm not sure that it matters quite as much.
Apply the relevant patch (gcc_42-5574.patch or gcc_42-5566.patch) to the gcc source tree.
Follow the instructions in gcc_42-5574.README or gcc_42-5566.README to compile and install gcc. This time, follow the REQUIREMENTS section as needed; in particular you will need to copy whatever SDKs you want to your Linux box.
Create the following symlinks:
```
  ln -s Developer/usr/bin/gcc-4.2 /usr/bin/
  ln -s /Developer/usr/bin/g++-4.2 /usr/bin/
```
for all those makefiles that call the compiler with an absolute path.

At this point you should have a working cross-compiler. The remaining instructions are for setting up distcc with it.

Grab a toolwhip tree on your Mac a well and follow the directions in distcc.README to build distcc.
Follow the directions in distcc.README to build distcc on your Linux box.

What you do after this point probably depends on exactly how you plan to run distcc and distccd, whether you plan to use ccache, whether you want pump mode, etc. There are lots of directions in distcc.README. So far I have a setup that does distcc over ssh to my Linux box. I'm hoping to sort out the rest of the distcc stuff (not using ssh, and maybe using pump mode) sometime in the next week or so. To get what I have working so far going:

Set PermitUserEnvironment to "yes" in /etc/ssh/sshd_config on the Linux box.
Put DISTCCD_PATH=/Developer/usr/bin in your ~/.ssh/environment on the Linux box.

Now you run a test. In my case, I use ccache, so this worked:

  export DISTCC_HOSTS=bzbarsky@linux-box:/path/to/toolwhip/distccd/on/linux,lzo
  export CCACHE_PREFIX=/path/to/toolwhip/distcc/on/mac
  export DISTCC_VERBOSE=1

and then compiling Firefox normally, using make -f client.mk. If you don't use ccache, you would need to skip the CCACHE_PREFIXgcc-4.2 and g++-4.2 came in your PATH on the Mac before the real compilers and pointed to the toolwhip distcc. I think that should do the trick, but haven't tried it. The ",lzo" in the DISTCC_HOSTS above just says to gzip-compress the data; it can be left out if desired.

Question for those with some distcc experience: is pump mode worth forgoing ccache?

One last note: I have not yet verified that this gives me faster compiles! Linking has to happen on the distcc client, and that tends to be a pretty slow part... Perhaps I would be better off just compiling entirely on the Linux box then copying the resulting .dmg to the Mac.

UPDATE: While the above distcc setup works for compiling an already-configured Mozilla tree, it seems that trying to configure from scratch fails because it thinks it failed to find Core Text, or more precisely because it fails to find ANSI C headers. But only if you use DISTCC_VERBOSE=1, so don't do that. It also seems that actually cross-compiling from Linux doesn't work because libffi insists on passing gnu ld options to an ld it detected as not being gnu ld. That's very sad.

Joshua Cranmer (jcranmer): Building packages: harder than they look

noreply@blogger.com (Joshua Cranmer) — Mon, 04 Jan 2010 21:28:46 +0000

For a course I'm TAing, we (the other TAs and I) decided to revamp the tools so that students could more easily install them on their own computers. This was really my first look into actually producing packages for other people. Here is the long tale:

Step 1: Build `simpl`

Okay, the basic, core tools here compile and work easily. The more complicated tale is the GUI, built on qt. qt 3, to be precise. Except the autodiscovery thinks we want to try building qt 4. A single post-configure change gets this working. Only took a few hours here (trying to go the qt4 route didn't work so well, and we had interesting endeavors trying to figure out how to get KDE headers to work).

Step 2: Build binutils

This wasn't all that hard at first. Configure ran nicely and without problems, and building... oops, there's a warning and someone turned on -Werror. Another reconfigure gets this building quickly.

Step 3: Build (cross-compiling) gcc

Configure... build... fail... reconfigure... rebuild... fail... Repeat for several hours. Make that days. Do I want these options? Or those options? Still failing. Try editing files mid-build, so if that gets it to work. And, no. Okay, let's try binutils again. Solution: make install binutils first, then build gcc. That works without problems.

Step 3.5: Test the build

I have a Makefile that just requires me to change a few lines to swap gcc versions and directories of everything. Do that, try it, and... it doesn't work. Something about libc not working correctly.

Step 4: Build newlib

By this point, I know the drill: copy the configure from elsewhere, configure, and build. Apparently there's a typo in one of the ARM assembly files. I teach myself a tiny bit more of ARM (this is turning out to be very educational!) and fix the file. Reconfigure, rebuild, install, and test again. This time, it's complaining about missing a few functions. I found some more documentation online, and wrote my own sbrk function (where "wrote" means copied from some file online and tweaked to make it build). Testing fails again, so I make myself a few more functions and everybody's happy.

Step 5: Build vba

As you might imagine, this one didn't work either. So many build errors. I look at what Debian did, so I ponder some more, talk it over with the other TAs, and give up. Skritch, skritch.

Step 5: Build vbam

This fork builds... oh, wait, I need cmake. Okay, this fork builds without problem. They don't have version package downloads for my build script to pull, so I just have it yank a specific svn revision. Nice, simple package to work with after the mess that is cross-compiling.

Step 6: Build gdb

No problems here. Worked fine the first time, no patching, no need to rebuild. Even the testing had no problems. Stunned me.

Step 7: Package and test on school computer

Problems:

Can't find libmpfr.so
cc1: /lib/libc.so.6: version `GLIBC_2.7' not found
as: /lib/libc.so.6: version `GLIBC_2.7' not found
(vbam) Segmentation fault

Solutions:

Statically compile libmpfr.so. Not too hard...
Statically link gcc. Not very trivial. Eventually, LDFLAGS=-static in the configure arguments works.
Statically link as (and other binutils). This requires manually copying the final line and adding in the -static argument. Every time I rebuild binutils.
Debug, find backtrace. It's in pthreads, called from SDL. Try statically linking SDL (no luck). Try using different SDL versions. Rebuild vbam with debug. Notice that the primary reason for fault is... no sound device. Patch vbam. Test again, it works!

For the sake of clarity, every time I had to test in the final step, I had to reupload the tarball, which started out at 49 MB and grew to 55 MB (thanks to static compilation). Sometimes I had to reupload it again, if the connection died in the middle (my internet connection started getting flaky... possibly related to the 100s of MB I was uploading a day. Or maybe the 100s of MB I was downloading (every time I restarted the script, it downloaded 100 MB of source archives....).

So, in short, I had to override build scripts for 2 different packages, patch another 2, and build 3 out of 5 packages statically. One package doesn't have a point release; the other three are spread out among three separate servers to download. Running the build script from scratch requires nearly 2GB of disk space and takes several hours. At least now I repackaged it in Makefile form so you don't have to restart all over from square one if you forgot to install cmake first. Building the final tarball requires a good minute on my system.

But, I've finally finished the experience. Plus, I won't have to do it again... after I build the 64-bit version.

David Humphrey (humph): Experiments with audio, part VI

david.humphrey — Mon, 04 Jan 2010 15:26:19 +0000

For the past month I’ve been working with some audiophile friends on a project to try and expose audio spectrum data to JavaScript from Firefox’s audio element. Today I finally have something more than raw numbers to show off.

When I last wrote about our experiments with the <audio> element in part V, I had successfully written a patch to add a new DOM event (onAudioWritten), which is dispatched every time a frame of audio is decoded (this works for <audio> and <video>). I make this raw data available via a list type object called MozAudioData, which exposes .length and .item() for accessing the data in script (I’m hoping to move to the new WebGL arrays as soon as Vlad lands them). As I finished up for holidays, I made a very crude but promising demo that proved things were working:

Now it was clear that the data could be had, but we wondered whether it was possible to consume it fast enough in js. Corban Brook decided to try, and wrote a Cooley-Tukey FFT algorithm in JavaScript to work with the raw data in real time. He then wrote a very cool visualization in Processing.js, and the end product is nothing short of amazing (you have to see this video demo of it running on Vimeo to get the full effect):

I want to do some more work to see what moving the FFT into C++ would mean in terms of performance. Having the ability to do even more complex analysis or visualization (imagine real time speech-to-text coming out of <video>) in script is our goal. I’m also starting to wonder about how best to add write capabilities to go with this read-only version. Imagine being able to do equalizing, filtering, etc. on the audio from script. I have no idea how to tackle this yet.

It’s been fun working with these guys who know so much about audio. I know almost nothing about the data I’m extracting, and it’s humbling to learn from them. We’re approaching the point where input on API design would be useful, as I get this patch in better shape for review. If you’d like to get involved or try it out yourself, drop into irc.mozilla.org/processing.js, where we are working, and join the discussion in the bug. I’ll continue to blog this series about our work, and I know the others are working on posts and more demos, too.

Joshua Cranmer (jcranmer): Predicted work on Thunderbird

noreply@blogger.com (Joshua Cranmer) — Sat, 02 Jan 2010 19:46:16 +0000

It's a new year, so it's time for me to predict (and probably overestimate, who knows) what I would like to do and see in the realm of Thunderbird (and SeaMonkey) and other tidbits in the Mozilla realm.

News submodule

Thunderbird 3 improved the filter story dramatically here; the next two biggest itches are the complete inanity that is news URIs (too many bugs to count), and the venerable old crossposts bug. I still contend that the latter would best be served by per-account database functionality; in any case, it does require some database changes to work properly. I doubt I'll find time to look at that bug in particular this year.

The URI issues are more tractable, but I don't think I'll find time to hit them for 3.1; in any case, I now consider them to be the highest priority news bugs. So, to anyone with time on their hands: feel free to take one or two of these and start fixing. You'll get much kudos from Thunderbird Usenet users.

Other various "nice-to-haves" on my list: fixing subscribe, cleaning up some of the gunk in the code, adding support for RFC 3977 CAPABILITIES, possibly changing how news:a.group URIs work (open the folder view, not necessarily subscribing to them), among others. Combine-and-decode also falls under this list, but it's a lot less tractable than some of the other stuff.

Analysis tools

jshydra could use some more love: I hope to be able to be able to get a converter to a more natural AST working by the end of the year, as well as an automated test suite to verify correctness whenever I change m-c versions. I've also been working on-and-off on getting symbols for DXR via MSVC, which should hopefully also be finished this year.

Other Mozilla/Mailnews work

As I've mentioned before, my biggest goal for 3.1 is to be able to specify new account types in Javascript. I basically have the necessary framework completed locally, I just need to finish writing the tests and fix some bugs before getting it reviewed and committed; after that, I'll be writing a series of blog entries on developing an account type in JS, similar to (and hopefully better than) my pork guides. Speaking of which, I hope to finish that sometime this year as well. Possibly during summer again.

I've yet to see a roadmap for the address book in 3.1 and later, so I don't know what I'll be doing for the address book in this upcoming year. I expect, though, that I won't do anything near the scale of what I did for bug 413260. De-RDF and de-morkification are another two things I'd like to see worked on that I don't expect to get to this next year as well.

Time to see how much I'll actually get done this year!

Nikhil Kapur (Nik): Milepost GCC-Web Services

noreply@blogger.com (Nik) — Sat, 26 Dec 2009 16:15:07 +0000

So finally after banging my head for almost two days against the Web Service of cTuning and CCC Framework, I have finally managed to get the combinations correct and am able to receive the Compiler Optimization flags now from the cTuning web services. There are a few glitches here and there, I think it requires that the platform, compiler and environment that one is using should be already present in the database. So I opened up the database and retrieved some records and used the platform, env and compiler ids from there to retrieve the predicted compiler flags and I am quite pleased to say that it is working now. Although, I see that using the flags generated, I am getting a worse runtime than by using normal -o2, -o3 levels :)..

Also, I read on the cTuning website that currently only compiler optimization flags are being predicted by the ML based compiler and optimization passes are not being predicted but there are plans to incorporate this too. I will try to follow up the authors of Milepost and find whether that part has been done, or is in the process.

Nikhil Kapur (nik): Review: Mainland China

noreply@blogger.com (Nik) — Thu, 24 Dec 2009 15:16:00 +0000

Having not much to pass time with in the hols, I thought I would start what I have been wanting to do for a long time now.. Write about food! Whenever I tell people that I am an indulgent foodie, they look me up and down and then comment, doesn't seem so. Well being skinny sure has one advantage, you don't have to think about all the fat going in..

So first up in my mind is a restaurant that I have visited the most in Delhi: Mainland China. It has branches now in GK, Rajouri Garden, Gurgaon and even a brand new "New World Mainland China" in Saket, though I have only been to the one in GK. On my first visit to Mainland China, I was quite impressed. It was not easy to come by good authentic chinese food at non-exorbitant prices. The food suited the taste buds, and it was not very spicy: the way I like my chinese. Now that I have given it quite a few visits (more so because of the prices than the food) I feel the food is not out of the world but much much better than what we usually get in the name of chinese.

Coming to the dishes, the staters tend to be Chinjabiish. Frankly I don't expect to see Crispy Chilli Potatoes in an authentic chinese restaurant but there they are, popping straight into my face the moment I open the menu. Avoid them at all costs. I will give full marks to the Dimsums though, be they Siu Mai or Hargaos. One of the dishes that I really love is the Barbecued Chicken with Manthao Buns, it is truly and simply delicious. Crackling Spinach also makes its appearance for the veggies and it is supposedly one of the best in Delhi, though personally I am not very fond of all the oil. Coming to the main-course, I would suggest Broccoli, Corn and Water Chestnuts in Chilli Garlic Sauce and Mixed Vegetables in Chengdu Pickled Chilli Sauce. For the non vegetarians, there are much more options out of which I find Sliced Chicken in Oyster Sauce quite succulent. Oh, I forget that even their lamb is very good. I prefer taking Burnt Onion and Garlic Rice but I have heard their Chinese Olives XO Fried Rice is also very good, though it does not feature on the menu. All in all the meal is a nice experience, leaving you satisfied without burning a hole in your pocket.

But the best part of the restaurant lies in the lunch buffet. For around 425/- +taxes you can fill your stomach to the brim with quite a variety of dishes. The best part is that they even have sea food in their buffet menu: Crabs, Prawns, Shrimps etc. If you are planning to visit at lunch time, I would recommend that you take the buffet. But do book you table in advance 'cause the VFM buffet attracts a lot of crowd.

Ratings:
Food: 3.5/5
Service: 4/5
Decor: 3.5/5
Value for Money: 4/5
Meal for two: 1200/- + taxes

Mark Surman (surman): Drumbeat: ideas and proposals from Singapore

msurman — Tue, 22 Dec 2009 15:08:02 +0000

Another goal of our Singapore presentation challenge was to seek our potential Drumbeat projects. A big part of Drumbeat is inviting people to propose projects that make web better and more open — and then helping the most promising ideas succeed. The Singapore event was our first opportunity to see what kind of projects people might put on the Drumbeat table. Here are five of the eight ideas presented.

Idea #1. Free content hat tip system, presented by Preetam Rai. Click to watch as open video or use Flash version below.

Idea #2. Improving the open font library, presented by Jon Phillips. Click to watch as open video or use Flash version below.

Idea #3. Assisting bots in crawling the web better, presented by KahWee.

Idea #4. Better automated site maps, presented by U-Zyn Chua.

Idea #5. More intuitive web browsers, presented by Patipat Susumpow (Keng).

In all cases: great presentations and intriguing ideas. Some are very much about *using* technology to help people understand the web and make it more open. Others are much closer to building and improving the core technologies of the web itself. And interesting mix.

Given the Drumbeat focus on *using* (as opposed to building) technology to make web better, I’d be interested to know: which of the ideas about sound most Drumbeat-y to you? Are there projects that you’d be interested in backing or getting involved with when Drumbeat gets rolling in the new year?

Posted in drumbeat, mozilla

M. Mead Armsby (mead): XPCShell Testing for Firefox Addons (Extensions)

noreply@blogger.com (Mead) — Sun, 20 Dec 2009 16:15:22 +0000

A quick bit of info on what I've done to get xpcshell unit tests working for my add-on.
Here's my folder structure:To the .mozconfig (not in the above diagram, as mine is located in my home folder), I add the following to enable tests:

ac_add_options --enable-tests

To the Makefile.in in the bittorrent folder, I take the existing lines:

# list of subfolders to process
DIRS        = public src

And add the following (based on http://zenit.senecac.on.ca/wiki/index.php/Dive_into_Mozilla_Unit_Testing_Lab)

# Adding xpcshell unit tests
ifdef ENABLE_TESTS
DIRS  += test
endif

This means in addition to Make processing the public & src subfolders, it should also process the test folder, if tests are enabled.
The Makefile.in in the test folder is terribly boring. My Add-ons module name is bittorrentwikiscraps, I can perhaps specify the module for this Makefile as that also, however the pattern seems to be test_modulename. (My notes say I was basing this on this Makefile.in, take a look if you need platform specific tests)

DEPTH        = ../../..
topsrcdir    = @top_srcdir@
srcdir        = @srcdir@
VPATH        = @srcdir@

include $(DEPTH)/config/autoconf.mk

MODULE = test_bittorrentwikiscraps

XPCSHELL_TESTS = \
                 unit \
                 $(NULL)

include $(topsrcdir)/config/rules.mk

The XPCSHELL_TESTS defines the folders where the tests are stored, and MODULE defines where the tests will be copied, and run from. The tests will be copied to OBJDIR/_tests/xpcshell/test_bittorrentwikiscraps/unit/ when running 'make', and when running 'make xpcshell-tests' the tests in these folders will be executed.
The above is pretty normal for xpcshell tests. The next bit is what's been described to me by ted a couple of times, it's what crashreporter does to circumvent an issue with xpcshell (with a little hack of it's own^).
xpcshell doesn't know about add-ons, so the components I want to test won't be available when the tests run. So, I copy the components (JS files, in bittorrent/src/) to the testing area, by adding the following to bittorrent/src/Makefile.in (at the end of the file):

libs:: 
    $(NSINSTALL) -D $(DEPTH)/_tests/xpcshell/test_$(MODULE)/unit/components

libs::    $(EXTRA_COMPONENTS)
    $(INSTALL) $(foreach f,$^,"$f") $(DEPTH)/_tests/xpcshell/test_$(MODULE)/unit/components

With JavaScript components, the files are listed in EXTRA_COMPONENTS (you list them! It's not automatic!). What we're doing here is first creating the components subfolder in the testing area (the first use of libs::) and then copying every item in EXTRA_COMPONENTS to this new folder (second use of libs::). Yay! Now the component files are there. But how will xpcshell know about them when the tests are run?
This is acheived by using nsIComponentRegistrar to register the components during the test. Yes, every time a test is run the components are registered first. We do this by creating head_regComps.js in the unit folder. When tests are run, for example test_sample.js, all the head_*.js files are executed before the contents of test_sample.js to do any setup. So, head_regComps.js will be run first, which ensures the components are loaded before the testing code. The contents of head_regComps.js are from the crashreporter code:

// load components from test subfolder
//  Get current working directory
let cwd = Components.classes["@mozilla.org/file/directory_service;1"]
      .getService(Components.interfaces.nsIProperties)
      .get("CurWorkD", Components.interfaces.nsILocalFile);
// load subfolder
let cd = cwd.clone();
cd.append("components");
Components.manager instanceof Components.interfaces.nsIComponentRegistrar;
Components.manager.autoRegister(cd);

The code gets the current working directory (the unit folder in the testing area) and then registers all the components in the components subfolder.
For tests that just involve new components, this is enough. My tests can now see the components (in test_sample.js):

function run_test() {
  var btPresent = ("@wikiscraps.com/transport/wireInStream;1" in Components.classes);
  do_check_true(btPresent);
}

However, my Add-on also has new component interfaces (see the IDL files in the public folder). This issue isn't tackled in the current Mozilla build setup, and the above approach based on crashreporter can't handle interfaces. So, to recap: the issue of xpcshell not being aware of Add-ons prevents the interface being loaded; and unlike components, interfaces can't be loaded dynamically. My hack is just to copy the interfaces to OBJDIR/dist/bin/components/. I'm fine with this, my Firefox build has an interface that belongs in the extension folder. This will probably cause an issue when the Add-on interface in a profile and this components folder are out of sync, but oh well. This build is fine for testing and generating the Add-on's XPI file.
Anyway, the copying of the XPT file is achieved by adding the following in the bittorrent/public/Makefile.in (at the end)

libs:: 
    $(INSTALL) $(XPIDL_GEN_DIR)/$(XPIDL_MODULE).xpt $(DIST)/bin/components

Usually the xpt files are copied in a similar manner to the folder '${FINAL_TARGET}/components', however because Add-ons are built for an XPI that will mean FINAL_TARGET will point to the xpi-staging area, so instead '$(DIST)/bin/components' must be used. Now, when xpcshell is run the interface will be ready to be loaded.
Just a note, I had removed OBJDIR/dist/bin/components/components.list, OBJDIR/dist/bin/components/compreg.dat & OBJDIR/dist/bin/components/xpti.dat earlier during my development; I'm unsure if I hadn't done this if the interfaces would be loaded.
Anyway, we can now test and see the interface has been loaded, by adjusting test_sample.js:

function run_test() {
  var btPresent = ("@wikiscraps.com/transport/wireInStream;1" in  Components.classes);
  do_check_true(btPresent);
  var btiPresent = ("btIWireInputStream" in Components.interfaces);
  do_check_true(btiPresent);
}

Yay. I can test my Add-on components using xpcshell unit tests.

Nikhil Kapur (Nik): Mozilla Builds

noreply@blogger.com (Nik) — Sun, 20 Dec 2009 13:45:00 +0000

I have started working on a student project in Mozilla which requires using Milepost GCC to speed up Firefox. I started with doing a few builds of Firefox, both by using Mercurial and downloading the source code archive directly. I faced a few problems during the build process. After taking a lot of time for the build, it would crash on me giving errors like "vsnprintf not found", "fprintf not found" etc. After trying all possible options, I googled the errors and even found a related bug already filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=485019
But the bug is marked "Resolved Invalid" (I have no idea what that means). Anyways, once I found that it was the breakpad which was causing problems, I disabled the crashreporter in the mozconfig file and that worked. So I managed to do some optimization and debug builds.

After that I moved onto Profile Guided Optimization Builds, which I believe Mozilla is currently using for its releases. A PGO build consists of two passes: a first pass to build binaries, then a second pass to re-build optimized binaries using profile information extracted by running the first binaries. I managed to successfully build firefox 3.6 with PGO.

I have moved on currently to studying Milepost GCC for now, but I'll be back to the builds to examine the makefiles and the code changes between normal and PGO builds, because I'll need to know how the builds actually work.

Nikhil Kapur (Nik): Milepost GCC - Plugins

noreply@blogger.com (Nik) — Sun, 20 Dec 2009 13:43:16 +0000

Here are some of the plugins that I have installed and a summary of what they do:

save_executed_passes.legacy
This plugin saves the executed passes per function in external files
"ici_passes_function<function_name>.txt"</function_name>
save_executed_passes_with_time.legacy
This plugin times the execution of the passes split-compilation.
substitute-passes.legacy
This plugin substitutes original GCC pass order with the one read from either external files "ici_passes_function<function_name>.txt", 1 global file "ici_passes_all.txt" or environment variable ICI_PASSES_ALL (passes are separated by comma) thus allowing external manipulation with passes (adding, removing or reordering).</function_name>
extract_program_static_features
This plugin extracts program static features per function as vectors and saves them into "ici_features_function<function_name><pass_to_extract>.txt"
</pass_to_extract></function_name>

The installation of these plugins was not very intuitive but I managed by tweaking the code here and there. The plugins are working fine now with GCC. The only problem I now face with Milepost is how to predict the optimization flags using the static program features which are extracted by the last plugin mentioned above. I believe (I may be wrong here) that we need to access the cDatabase and push our features in there, which then returns a set of optimization flags which can be used to compile with GCC. There are two ways to do this: using Web Services or using the CCC Framework (http://ctuning.org/wiki/index.php/CDatabase:Documentation:API). I have currently tried both but there are issues.

I cannot find a php script using which I can send a request to the "predict_opt" Web Service. Without this, its not possible to use the Web Service. The script for adding the optimization cases is available though.
With the CCC framework, I am unable to access the Web Service using sockets. This is the part where I am currently working. I have posted a request on the Discussions of the Community for making available the php script. Meanwhile, I'll try to get the CCC framework to work and return the predicted flags.

Nikhil Kapur (Nik): Milepost GCC - Introduction

noreply@blogger.com (Nik) — Sun, 20 Dec 2009 13:20:03 +0000

Continuing with the work of the previous week, this week I started reading up about Milepost GCC. Some of the information can be found on this link: http://ctuning.org/wiki/index.php/CTools and the following paper: http://gcc-ici.sourceforge.net/papers/fmtp2008.pdf.

I am putting up here some of the extracts which I thought were important and which highlight the key concept of the Machine Learning based compiler:

Considerable speed-ups can be already obtained after iterative compilation on all platforms. However, this is a time-consuming process and different speed-ups across different platforms motivate the use of machine learning to automatically build specialized compilers and predict the best optimization flags or sequences of passes for different architectures.
Research has shown a great potential to improve program execution time or reduce code size by carefully selecting global compiler flags or transformation parameters using iterative compilation. The quality of generated code can also be improved by selecting different optimization orders. Milepost GCC's approach combines the selection of optimal optimization orders and tuning parameters of transformations at the same time.
Here is a description of some of the related tools and frameworks:
- Continuous Collective Compilation Framework (CCC): A tool that generates the training examples for the Machine Learning tools. It does this by evaluating different compilation optimizations, storing execution time, code size and other metrics in a database.
- Interactive Compilation Interface (ICI): The ICI provides opportunities for external control and examination of the compiler. The new version of ICI expands on the capabilities of its predecessor permitting the pass order to be modified. This version of ICI is used in the Milepost GCC to automatically learn good sequences of optimization passes.
- PLUGINS: The features of the program (program structure) are extracted from Milepost GCC via a plugin and are also stored in the database. They are driven through shared libraries.
Working of Milepost GCC:
- The plugins are invoked by the new -fici GCC flag or by setting ICI_USE environment variable to 1. When GCC detects these options, it loads a plugin (dynamic library) with a name specified by ICI_PLUGIN environment variable.
- The machine learnt model predicts the best GCC optimization to apply to an input program based on its program structure or program features.
- To extract these static program features an additional GCC pass 'ml-feat' is implemented. This pass can be called using a extract_program_static_features plugin after any arbitrary pass starting from FRE when all the GCC data necessary to produce features is ready.

There is still a lot of material to be read. I will give some details about the plugins I have installed in the next post. I believe Milepost GCC is an ingenious idea, however, as a user, I would have been happier if the documentation had been better. Currently I have to read the READMEs scattered around in the installation directories, and they are not very clear and specific.

M. Mead Armsby (mead): Progress? Firefox Debug Builds on Ubuntu 8.10

noreply@blogger.com (Mead) — Sun, 20 Dec 2009 03:35:07 +0000

I expected to have released a new version, but on finally using the Bittorrent extension on torrents with data greater than 300Mb, I can see that the memory usage is quite horrid, and memory isn't released when downloading is finished.
So now I'm stuck in trying to debug to find why memory isn't released, which brings me to getting a debug build on Ubuntu 8.10.

Building on Ubuntu 8.10

DO NOT follow this guide. You'll be building an OLD Firefox. Check out jboston's user page; you MUST use Mercurial (hg) to get the latest source. I wish this had been made more clear on MDC.

It appears there is a new hoop to jump through to build on Ubuntu 8.10. A better guide is on jboston's user page; consider this another way to skin a cat. I initially followed dbranski's guide to building Firefox on Ubuntu, though this doesn't appear to work on Ubuntu 8.10.
I grab some packages:

sudo apt-get install gcc g++ perl make cvs libxt-dev libidl0 libidl-dev libfreetype6 fontconfig libcurl4-openssl-dev libgtk2.0-dev libdbus-1-dev libdbus-glib-1-dev

I grab a make file that lets me grab the source I'll need:

cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/client.mk

I've also grabbed trace-malloc for this debug build, not sure if this is the right way, but it's what I've done. Skipped when not making a debug build.

cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/tools/trace-malloc

I get into the mozilla folder, and open up the .mozconfig file to configure this build.

cd mozilla
nano .mozconfig

I paste the mozconfig for a debug build into the file (found the text from Mozilla QA's Howto Debug Builds). I comment out the CPU line and the let line beneath it, and the line marked MOZ_MAKE_FLAGS (the let line caused a complaint, and I don't care about the 'make' tool running jobs in parrallel). I then add the lines:

export CFLAGS="-U_FORTIFY_SOURCE"
export CXXFLAGS="-U_FORTIFY_SOURCE"

Then save the file. The above addition is because Ubuntu has changed the default gcc flags, and the fix is due to Ori Peleg. Unoptimised builds are not effected. If you're using an existing mozconfig that doesn't explicitly turn off optimisation, add the above U_FORTIFY_SOURCE statements.
I then get the source I need:

make -f client.mk checkout MOZ_CO_PROJECT=browser

And then start the build:

time make -f client.mk build

To find out if I'm leaking, I set an environment variable to a file I want to log to then run firefox (learnt from Mozilla QA leak testing):

export XPCOM_MEM_LEAK_LOG=~/leaklog0001.log
cd firefox-debug/dist/bin/
./firefox -P

When I've done whatever I want to test, I then quit Firefox and change the environment variable so I don't overwrite the log file.

export XPCOM_MEM_LEAK_LOG=~/leaklog0002.log

If I have leaks, the file tells me what objects weren't freed and in what quantity. To understand the output, I use MDC's debugging memory leaks page. It doesn't tell me why though, and that's my next problem.

David Humphrey (humph): Experiments with audio, part V

david.humphrey — Fri, 18 Dec 2009 21:19:03 +0000

I’m working on a project to try and expose audio spectrum data from Firefox’s audio element. Today I ponder arrays and fix some things.

Today is my last day of work before the Christmas break begins, and I just submitted my final grades. This gave me a little bit of time to rewrite some of my code in order to fix a few things. Here’s my latest demo:

After talking with some more people who work with audio, I realized that I’d be better off giving floats vs. integers for the data. In this demo you can see both my code, which uses event.mozAudioData, and the output in Firebug. I’m pretty happy with our progress to date. Twelve days isn’t bad to go from clueless to slightly-less clueless and with a working patch. I want to draw attention to this, because a large part of why I’m doing this is to inspire my students and others to take risks and work on things that scare them. You hold yourself back if you don’t. I don’t know what I’m doing most of the time, I just keep at it until I do. There’s no reason you can’t, too.

Anyway, this is looking good, but I’m far from done. What I spent the most time on with this iteration was getting my arrays working properly. I’ve been doing a lot of reading in our code, looking for ways to expose pure arrays in content (e.g., in the DOM). In the comments of my last blog post, a few suggestions where given, and in the bug another was mentioned. Here are the ways I’ve come-up with (there might be others):

Create a DOM class that wraps your array and provides getter/length semantics (that’s what I’ve done for now). See nsIDOMClientRectList.
Use an nsIVariant type, and let XPConnect coerce the type for you. See nsAnnotationService::GetPageAnnotationNames.
Go around IDL altogether and grab raw JS values. See nsCanvasRenderingContext2D::GetImageData.
Use the (currently not landed) WebGL Array (Vlad recommends I move to this, so I’ll explore that in subsequent work).

Now that I have it running, I’m starting to think about performance vs. just getting it to work. A lot of questions I am getting relate to doing Fourier Transform in JS vs. navtive code. I’ve been around Mozilla long enough to know that the first answer to questions like this isn’t to drop into C/C++. Maybe it won’t be possible in JS; but I need to have that proven before I’ll make that conclusion. I’m also concerned that my time-based events for exposing the data are going to be problematic. I really wonder about keeping up with the timing of the audio as it’s played. A lot of people I talk to are excited about doing precise visualizations that are timed to music. I know my current code can improve a lot here, so it’s too early to assess whether this will be possible.

I’m not sure when I’ll post my next part of this series. I am going to celebrate this success with some much needed holiday time. Rest assured, though, that I’ll be back at it again soon.

Nikhil Kapur (nik): Where it all begins

noreply@blogger.com (Nik) — Fri, 18 Dec 2009 15:49:00 +0000

So finally the day has come when I start blogging.. Had it been left to me, my hands wouldn't be typing this write now.. But well, duty calls, and thanks to Mozilla, I am now writing these seemingly monotonous words which must be making no sense to you all.. But I hope to improve soon and bring you some interesting tidbits.. So do keep up!

Mark Surman (surman): Open web talks from Singapore

msurman — Fri, 18 Dec 2009 14:35:57 +0000

Describing the open web is tough. Yet, it’s essential if we want to help people understand, participate and take control of their online lives (Drumbeat’s mission). We’re running a small experiment with this in mind: asking people to give five minute talks on the open web and why it matters.

We kicked off by calling for talks at events in Singapore and India this past week. Here are two of the best talks from Singapore. India talks coming soon.

Presentation #1 is by Coleman Yee, a user experience designer and strategist.

Presentation #2 is by Lucian Teo, a web standards advocate working in the Government of Singapore.

PS. We also asked for talks on possible Drumbeat project ideas. I’ve got a bunch of these from Singapore. Will post over the weekend.

Posted in drumbeat, mozilla

Mark Surman (surman): Drumbeat idea: open web skills @ p2pu

msurman — Thu, 17 Dec 2009 15:51:29 +0000

Another Drumbeat bootstrap idea that’s getting traction is open web skills courses delivered via the Peer 2 Peer University. It’s a simple concept: people combine self organized, collaborative learning with open curriculum materials to improve their skills in areas like HTML, CSS and Javascript. Over time, a peer to peer certification system could emerge as well, with participants rating each others skill level.

At the moment, there are a number of us writing this up, looking for learning materials and trying to find people to help mentor and run courses. Here’s the intro from the write up in the Drumbeat wiki:

Open Web Career Track: a collection of P2PU courses for people who want to learn open web skills

The challenge: Most tech career development courses focus on certification around a single technology (e.g. MCSE or Cisco Academy). The result: students go into their careers knowing one or two tools rather than knowing how to learn and adapt tools on the fly. Also, there is a sense that permission and certification are the keys to tech career success — but the reality is that creative, entrepreneurial problem solving is much more important.

The Peer 2 Peer University (P2PU) is planning to offer an alternative to this kind of career development. P2PU helps small groups of motivated learners to compile packages of open learning materials and design and facilitate their own courses. Students and tutors get recognition for their work, and an open credits pilot is in the works in order to hack the formal closed accreditation system. Open web technology is the perfect pilot discipline.

The plan: Open Web Career Track is a series of P2PU courses where students collaboratively learn — and rate each other on — open web skills. The courses focus both on specific, standards-based technologies (HTML, CSS, JavaScript, etc.) and learn-as-you-go problem solving and hacking (the real skill you need to succeed). Individual courses are organized by learners using the P2PU model. The overall program is organized as a Drumbeat project involving both employers (TopCoder?) and online career web sites (LinkedIn?).

In addition to facilitating social learning processes, P2PU is coordinating a group of individuals and organisations interested in building an open credits infrastructure (think of it as an open knowledge currency that makes sense in the knowledge economy). It will make it easy for Open Web Career professionals to showcase their skills and expertise to potential employers on personal profile pages. The open credits incubator will be held in mid-2010 and we plan to use open web career for our pilot.

The Open Web Career Track program is particularly focused on regions with high growth technology sectors and a strong bent towards certification. Likely places include: India, East Asia and Brasil. We want peer learning and accreditation to emerge as serious open web career path alternatives in these regions.

The reaction to this idea was good when I focus grouped it at #nsc1 in Singapore. Lots of questions, for sure. But people saw value in providing a grassroots (and hopefully very scaleable) alternative to mainstream tech courses and certification. This is one of our main goals. A few of the people I talked to also suggested getting small companies who need more tech talent involved as mentors and co-organizers. Recruiting people directly out of these courses could be a win for everyone.

We’re hoping to try a couple of these courses early next year, with at least some of them based in Asia. If you want to help organize a course — or if you know of good open web curriculum — please get in touch. You can comment below or jump onto the Drumbeat community mailing list.

Posted in drumbeat, education, mozilla

Mark Surman (surman): What does the web mean to you?

msurman — Thu, 17 Dec 2009 11:32:45 +0000

As I blogged the other day, I’ve been asking people for ideas on the ‘movie about the web, by the web‘ concept. One of my thought experiments was to simply ask people: what does the web mean to you? I edited the answers together as quick video poem just to see what it felt like.

Also: watch or download as OGG open video.

In some ways, the result is a bit schmultzy. But there is a nice affirmation also: people are totally ready to talk eloquently about very big ideas about the web. This is a good thing as the goal is to make a massively collaborative movie that helps people understand the web and why the fact that it’s open matters so much. It think the citizens of the web are more than ready to pitch in to do this.

If anyone’s interested, I’d love to see other clips responding to the ‘what does the web mean to you?’ question. Just you talking. Or you and your friends. You can just paste links below as comments. It’ll keep the thought experiment going.

Posted in drumbeat, mozilla, webmademovie

David Humphrey (humph): Experiments with audio, part IV

david.humphrey — Wed, 16 Dec 2009 16:26:23 +0000

I’m working on a project to try and expose audio spectrum data from Firefox’s audio element. Today I get raw data into the browser.

This blog post was going to be very different than the one you see now. That’s because our DOM code kicked my ass all day yesterday and into the night. I stopped coding when my eyes stopped working. And the result was very much, “…so close, what is causing this error!!!!!????” But then this morning, through the power of irc debugging, the answer came! Let me show you a picture before I go on:

Previously I wrote about my idea to add a new method to the audio element, which you’d call whenever the onaudiowritten event occurred. I thought a lot about this and couldn’t figure out how I was going to deal with the synchronization issues: the decoding (and raw data) is produced on a separate thread, and I need to expose it without blocking on the main thread. I decided to get some advice and went to speak with Chris Jones, who is one of the people working on Electrolysis, Mozilla’s project to rewrite Firefox with a multi-process architecture. Chris knows a lot about threading and synchronization, and he confirmed what I suspected–I should make this data available as a parameter of the event vs. adding another function call and trying to deal with the locking semantics.

I was hoping to avoid this. The very first thing I ever did with Firefox, back in 2005, was to work with some students to add a new event with data to the DOM. And it was hard. Very hard. But dealing with thread issues is hard too, so I dug in and went to work. Luckily for me all these years later, there are a lot more examples in the code I can follow. The MozAfterPaint event is pretty close to what I need to do: an event that contains a list of data. So I spent much of the day studying the code that implements it, and it’s a wild ride.

Eventually I was able to add nsIDOMNotifyAudioWrittenEvent and nsIDOMAudioData, with implementations. The way this code works now is this:

<script>
function audioWritten(event) {
  for (var i = 0; i < event.mozAudioData.length; i++)
    console.log(event.mozAudioData.item(i));
}
</script>
<audio src="song.ogg" onaudiowritten="audioWritten(event);"></audio>

As the audio is decoded, this event fires for every “frame” and you get an object with the event named mozAudioData. This contains all the raw audio data, basically a list of numbers like I discussed here. You can iterate through them using .item(n) and .length. Simple, right? Well, I can tell you it wasn’t simple to implement!

Last night I had all the code in place, but when I quit I was staring at an assertion being caused by my code:

###!!! ASSERTION: hmm? CanCallNow failed in XPCWrappedNative::CallMethod. We are finding out about this late!: ‘rv
== NS_ERROR_XPC_SECURITY_MANAGER_VETO’, file /Users/dave/moz/mozilla-central/src/js/src/xpconnect/src/xpcwrappednative.cpp, line 2206

I knew I must be doing something wrong with my nsIDOMAudioData class, since the event was working, and is very similar in terms of the plumbing it needs to get dispatched to the DOM. This morning, feeling thoroughly stuck, I went in search of Olli Petty (smaug on irc), who knows this code really well:

09:28 < smaug> AudioData isn’t an event
09:28 * smaug is surprised that even compiles

Me too! In my sleep deprived state last night I’d copy-pasted my nsDOMClassInfo code for the event and reused it for nsIDOMAudioData without removing the line that makes it an event. After deleting that line it works!

My patch is getting a lot bigger, but it needs more yet–I don’t even want to think about what they’ll ask me to change as I move to getting it reviewed. But that’s trouble for another day. Today I’m thrilled to have gotten this data exposed to script and lived to tell the tale. In part V I’ll try to get this into a state others can use, and then set my audiophile partners loose on doing something cool with the data.

Benjamin Smedberg (bsmedberg): Mozilla Status Updates

benjamin@smedbergs.us (Benjamin Smedberg) — Wed, 16 Dec 2009 03:57:55 +0000

If you work on Mozilla, how do you coordinate with other people? How do you let people know what you’re working on and ask for help without burdening your coworkers with unwanted email? As part of coordinating the Electrolysis project, I created a webtool which allows people to post status reports in a low-touch way. The Mozilla Status Board allows members of the Mozilla community to post status updates which will be distributed to other people on their teams, and to the public.

A status report is simple: you list items that have been accomplished, what you plan to work on next. Finally, you can list items that other members of your team may need to see, such as review requests, links to posted designs, or even vacation days.

One of the important design considerations was not forcing users into one communication medium. Users group themselves into teams, and each user can decide whether to receive email updates from their team or subscribe to a web feed. For example, if you wanted to see my personal status updates, you can visit my status page or subscribe to my personal feed. And if I wanted to use a feed reader, I could subscribe to the posts of everyone on my team. Hint: to change your email settings, visit the preferences page linked from the header.

Everyone in the Mozilla community is invited to use the status board. In order to keep spammers away, registrations require a password: ask somebody who has already registered, or ask in irc.mozilla.org #developers, or ask any Mozilla employee.

The status board was written in python cherrypy+genshi. The code is hosted at hg.mozilla.org and I am happy to take patches or suggestions. At some point I will probably try to transfer the site from my own server to some Mozilla server, but I’ll make sure that links keep working and data is migrated.

If you’ve been using the status board already, note that I just fixed a bug in the email system: daily/weekly emails were being delivered incorrectly, so starting tonight it should work correctly.

Update: Fixed an issue where Firefox wouldn’t remember your username correctly; renamed “Tags” to “Coordination” to make its intended purpose more obvious, and enabled markdown.

Benjamin Smedberg (bsmedberg): Multi-Process Plugins

benjamin@smedbergs.us (Benjamin Smedberg) — Tue, 15 Dec 2009 21:33:39 +0000

Yesterday I landed multi-process plugin support in mozilla-central. By default, this capability is disabled, because there are still some serious bugs. But if you are willing to suffer some temporary instability, we could really use some help testing Minefield nightlies with out-of-process plugins (OOPP).

Currently only Windows and Linux support multi-process plugins: mac support requires additional work. To turn OOPP on, visit about:config, find the pref dom.ipc.plugins.enabled, set it to true, and restart your browser. Please report any crashes or instability in bugzilla: product “Core” component “Plug-Ins”. Where possible, please be as detailed as possible in bug reports:

Operating system: please be specific about Windows versions, since Windows XP and Windows Vista deliver some Windows events differently;
Page visited;
Plugin data from about:plugins;
Whether turning IPC off fixes the problem (Note: flipping the pref usually requires restarting the browser to take effect).

There is one major known bug right now: any plugin which is installed in a path with spaces fails to load. On Windows, this affects almost everything except Flash. I hope to have this fixed in tomorrow’s nightly. There is a tracking bug for all the known issues which prevent us from turning on OOPP by default.

Please direct any questions about this work to the mozilla.dev.tech.plugins discussion list.

Mark Surman (surman): Hackerspaces, internets and cities

msurman — Tue, 15 Dec 2009 11:09:56 +0000

Name dropping Jane Jacobs at a tech conference is a good way to get my attention. And that’s exactly what Meng Weng Wong did on the hackerspaces panel at #nsc1 in Singapore the other day. His point: those of us trying to build a vibrant, healthy digital world can learn from people like Jacobs who know how to build vibrant, healthy cities.

A native New Yorker who lived most of her life in Toronto, Jacobs was amongst the wisest people to ever write about cities. Some of the things she encouraged us to do included:

Embrace density as form of connection. It creates serendipity and dynamism.
Also encourage diversity. Different ideas banging together drive entrepreneurial discovery.
Build — or at least look for — ways for cities to evolve and reconfigure overtime.

Jacob’s argument was that cities built on these principles are engines of economic expansion, growing the pie by fostering innovation that creates new industries. Sound a bit like the open internet? Indeed.

Of course, this healthy city <–> healthy cyberspace link shouldn’t be surprising coming from someone who founded a hackerspace (Meng just opened one in Singapore). Hackerspaces tangibly embody the essence of both a good city and the open internet. Chaotic. Malleable. Evolving. Resilient. Filled with all of your closest friends. These are wonderful places born of internet culture. Which makes me smile, and gives me hope.

PS. Another cool internet <–> city link at #nsc1: Pio Stark’s talk on how 19th century growth of cities into teaming masses of unfamiliar faces led to the need for new systems to track identity. New identity systems to deal with so many unfamiliar faces? Very much something we need to be thinking about now on the internet.

Posted in mozilla

David Humphrey (humph): Experiments with audio, part III

david.humphrey — Mon, 14 Dec 2009 20:43:00 +0000

I’m working on a project to try and expose audio spectrum data from Firefox’s audio element. Today I add a new event to the audio element.

Last time I wrote that “I’m going to have to get this wrong before I get it right.” So here goes some “wrong that feels right.” Having located the proper audio data, I’m up against the problem of how to get it exposed to content (i.e., script running in a web page). We’ve been starting to talk more about how to structure the API, but I’m a ways off from needing those decisions made. Since my last experiment I’ve been realizing that we’re going to need a notification so as to let scripts know that audio data is available.

Today’s experiment was to add a new DOM event to the audio element, such that web developers could be notified whenever raw audio data was available. Since it comes in a “frame” at a time out of the decoder, we get the song or “sound” in chunks as it is played. Here’s how you use what I’ve done today:

At the moment, there isn’t much you can do in doSomething(), since I haven’t exposed the data with the event. Instead what I’m planning to do is add a method named mozGetAudioData(), which you’ll call whenever onaudiowritten occurs.

Adding a new DOM event is accomplished by carefully studying how other events are implemented The audio element has a bunch of events, for example onloadedmetadata. I had to make a dozen or so changes to the following files (look for the string loadedmetadata as an example in these files):

The only tricky part was marshaling the call from the decoder thread over to the main thread, so the DOM event could be safely dispatched. I’ve put the patch up here if you want to look at it. WARNING: I’m just experimenting, and I wouldn’t look at this code for anything other than curiosity. This hasn’t been reviewed, and shouldn’t be mistaken for the right way to do this. This is just me learning out loud, as it were.

In part IV I hope to get the decoded frame data exposed via a new method on the audio element.

Mark Surman (surman): Who would you cast in a movie about the web?

msurman — Mon, 14 Dec 2009 05:56:49 +0000

Over the past couple of weeks, I’ve been helping Brett Gaylor and Henrik Moltke write up a movie concept. The idea: a documentary about the web, by the web. People around the world would contribute ideas, clips and remixes. The best stuff would roll into a core storyline with regular releases or episodes.

A part of Drumbeat, the goals for this movie project are pretty clear. 1. Help people understand how the web works and why its open nature matters so much. 2. Push the envelope on cool uses of HTML5 <video> and on the open source filmmaking process. 3. Give filmmakers, musicians and artists an easy, fun way to contribute to making the web better.

What’s harder is the storyline. Of course, much of this will come from the people of the web. That’s the point. But you need to start with something. A thesis. A point of view. The small bits of stuff we’ve written on this feel a bit stodgy and unsurprising. Good stories about the internet for sure, but stories we already know.

As a way to insert some creative juice into the process, I did a little experiment at #nsc1: I asked people to put themselves in the casting director’s chair. Each person I talked was invited to propose one character for the movie. Here are some quotes of what people suggested:

Peter Pan. Because the internet is alot like Neverland.
The transformers. They’re pretty geeky, but also cool. More to the point, they have the same sort of open ended adaptability that the internet has.
Web spiders. DNS. And other invisible agents that make up the web under the hood. Bring them to life as characters.
Doug Englebart and Ted Nelson. Focus on the unsung pioneers and thinkers behind the internet, not just the names we’ve all heard of.
My grandmother. That’s who I am trying to help when I try to make the internet better and simpler. She should be in the movie.
Myself. I am a part of the internet. I help make it when I use it and contribute content. I should be a part of the movie. And so should everyone else on the internet.
Anonymous. Our anonymous identities are just as much a part of the web as our public identities.

This was a really fun — and useful — session to run. So fun that I want to keep it going here. I’m extending the invitation to you: if you could cast one character in the movie version of the web, who or what would it be? If you have an idea, please post a comment.

Posted in drumbeat, mozilla

David Humphrey (humph): Experiments with audio, part II.I

david.humphrey — Fri, 11 Dec 2009 15:32:57 +0000

I’m working on a project to try and expose audio spectrum data from Firefox’s audio element. Today I give an update on yesterday’s progress, since there are pretty pictures, and then ask some questions.

Yesterday I wrote about our first steps to find and extract audio spectrum data from the <audio> element. At the end of my post I wondered aloud whether or not the numbers I’d produced were meaningful.

After that post I spent some time working with Al MacDonald and Thomas Saunders–my partners in these experiments–and a number of interesting things happened. First, what were simply numbers to me proved to be meaningful to them, and after helping them build Firefox with my changes, they started playing with the data. Al made a simple audio test case, and Thomas worked the data into a JavaScript friendly form. Next Al took the audio and analyzed the wave form in Audacity, before creating a real-time canvas visualization of the data we’d extracted from the browser. The results speak for themselves.

Having an early success is encouraging, but like one of my students is fond of saying, success brings you to your next problem. Knowing that this data is meaningful means I now need to figure out the right way to expose it in the DOM. When I get this data I’m deep in C++, nowhere near JS running in the browser. What I need is a proper API for making this data available.

My choice of words is important: “right way,” “proper API.” I could (and probably will for my next test) just drop-kick the data across the the content boundary. But what’s the right way to do this? I did some investigations into our implementation of DOM events last night. I was thinking that maybe I should pass the data out within a custom DOM event. However, I don’t see any events that use this model. There doesn’t seem to be much data pushed with the event. Another option is to dispatch an event and then fill a buffer that can be read via a getAudioData() call. But even when I get this working (if this is the right thing to do), I’ll next have to worry about how to make that data meaningful in terms of sync with the actual audio that the user is hearing. A little bit out of sync is almost as bad as being totally random, especially if you’re trying to time visualizations or other UI updates to sound.

So I’m convinced we’re on track, and also feeling a bit lost. I know that “the perfect is the enemy of the good,” so I won’t halt my work until I can settle all these questions. It’s clear to me that I’m going to have to get this wrong before I get it right. But I’d value some input from those closer to our DOM implementation and the JS community on which paths to explore. Thankfully, Chris Blizzard has started that ball rolling by introducing us to some more people. The most enjoyable part of experiments like these for me is the chance to work in community.

David Humphrey (humph): Experiments with audio, part II

david.humphrey — Thu, 10 Dec 2009 15:36:58 +0000

I’m working on a project to try and expose audio spectrum data from Firefox’s audio element. Today I document some of my background research and initial first steps at locating this data.

The <audio> element is part of the html5 spec, and you can already use it in Firefox 3.5 and above. Here’s a page that uses it, for example. If we go spelunking through the Firefox code, we can see that <audio>, and the bits needed for these experiments, are spread across a number of files.

First, and perhaps least interesting, is the IDL definition of nsIDOMHTMLAudioElement, which inherits everything from nsIDOMHTMLMediaElement (note: if you are unfamiliar with IDL, and Mozilla’s use of it, I’ve written about how we use it here). This tells us the sorts of things one can do with an audio element, which attributes or functions it has. One important thing to note, for purposes of this experiment, is the presence of Mozilla-specific additions to this list, namely, mozAutoPlayEnabled and mozLoadFrom. Similar to Mozilla’s CSS additions, which are named -moz*, we’ll have to name our additional features for audio with a moz* prefix.

Next we see the actual implementation of the nsIDOMHTMLAudioElement interface in nsHTMLAudioElement.cpp. Here are the aspects of the audio element relating to “content” or the DOM. Just as with the IDL, most of the functionality we care about is really in the nsHTMLMediaElement.cpp instead (e.g., here is the code for mozAutoPlayEnabled).

Reading through this code, I’m interested to find some sort of connection to the underlying sound device, and the location where spectrum data is dealt with. I notice numerous references to objects of type nsMediaStream, which sounds interesting. This directs my attention to the content/media/ directory, and I notice nsAudioStream.cpp, which includes a Write method.

I decide to try adding some debugging info and see what the data being written down to the audio handle looks like. The code seems to imply that I’m in the right spot, as data is being written down to the audio stream in a series of shorts. Using the same audio test page I linked to above, I run my modified build, and here is what I see:

[43 43 -1063 -1063 -70 -70 1350 1350 658 658 -414 -414 -476 -476 -1631 -1631 -3145 -3145 -2758 -2758 -1988 -1988 -2282 -2282 -2488 -2488 -2204 -2204 -2371 -2371 -1514 -1514 -230 -230 243 243 1950 1950 2835 2835 2398 2398 3106 3106 3970 3970 3281 3281 1736 1736 992 992 1482 1482 2162 2162 1552 1552 681 681 -69 -69 -835 -835 -1182 -1182 -884 -884 267 267 703 703 140 140 -187 -187 238 238 86 86 -724 -724 -1004 -1004 -683 -683 226 226 412 412 -366 -366 -2132 -2132 -3578 -3578 -3118 -3118 -2473 -2473 -1405 -1405 -1053 -1053 -2695 -2695 -3086 -3086 -2081 -2081 -1906 -1906 -1992 -1992 -2153 -2153 -2688 -2688 -2127 -2127 -1160 -1160 -409 -409 718 718 676 676 248 248 553 553 275 275 -105 -105 327 327 586 586 1110 1110 2734 2734 3373 3373 1627 1627 673 673 1353 1353 944 944 1712 1712 3272 3272 2751 2751 1092 1092 -116 -116 223 223 275 275 -1367 -1367 -2829 -2829 -837 -837 1115 1115 -401 -401 -437 -437 ...]

Looks just like the song sounds, doesn’t it? I have no idea, but I’ve sent my patch and the data off to my audiophile colleagues for analysis. Maybe we’re on the right track, maybe I’m just pulling numbers out of the air. At any rate, I’m learning more about this code. Next time I hope to do a bit of work to get this data exposed in a more usable way (right not it’s just a console dump). That will likely be the subject of part III.

Joshua Cranmer (jcranmer): Google Wave in Thunderbird 3

noreply@blogger.com (Joshua Cranmer) — Wed, 09 Dec 2009 18:57:27 +0000

While it's not in the format I would ideally want, I recently got Google Wave inside Thunderbird 3. How, you might ask. Simple: the new content tabs feature.

So, to do it, go into the Error Console, and type this line in: Components.classes['@mozilla.org/appshell/window-mediator;1'].getService(Components.interfaces.nsIWindowMediator).getMostRecentWindow("mail:3pane").document.getElementById("tabmail").openTab("contentTab", {contentPage: "https://wave.google.com/wave/?nouacheck"});. Note that Google Wave for some idiotic reason decides that Thunderbird isn't a valid UA to be using, so you have to convince it to disable the UA with the ?nouacheck. I thought browser sniffing died out years ago...

For bonus points, if you restart Thunderbird, the tab will stay open, so all you need to do is login again!

David Humphrey (humph): Experiments with audio, part I

david.humphrey — Mon, 07 Dec 2009 18:10:33 +0000

This post marks the beginning of what I expect to be a somewhat regular series of posts in which I will document my thinking, learning, and progress related to some Firefox development. I say “Experiments” above, because I am going to try a number of things. First, I’m going to push into a part of the Firefox source code where I haven’t worked before, namely, the DOM implementation (note: it scares me, to be honest). Second, I’m going to do so in an open and pedagogic way, attempting to cast aside my own ego and hesitation at looking foolish–I don’t actually know how to do what I’m going to try, and will learn and fail as I go–on the way to producing an authentic model of open development for my students. Third, I’m going to work with a few others who are also interested in extending themselves and extending the web. The only thing I can assure you of at this early date is that these posts will be an honest account of the attempt.

First, I should say something about <audio> and what we’re planning to do with it. The <audio> element is part of HTML5, and allows web developers to embed audio, music, sound effects, etc. directly in a web page. This same ability has been achieved in the past through the use of Flash. The <audio> element, like the <video> element, is still in flux and presents an excellent target for experimentation and play while the spec continues to wend its way toward completion.

I don’t know anything about audio or have any need for <audio> personally. However, I have spent the fall working with creative designers, visualizers, and developers as part of the Processing for the Web project. It has opened my eyes to what the browser and web might become, if these people are given the right tools. And while I can’t do anything more with audio than press ‘play’ (I struggle to get this to work sometimes, too), I can bring my knowledge of Mozilla, its code, and the web to this effort. So my role in these experiments will be to help get things working in Firefox, and to help my partners (who do understand and need audio and <audio>) understand how to do this work.

Thomas has written a nice post about why the web needs more data exposed from <audio>. He has also created an interesting demo, which uses Processing.js, JavaScript, and Flash, and shows what we should be able to do with pure html5 and JavaScript. His demo is a visualization of the audio’s left and right channels, getting data about the underlying sound wave.

Our goal is to make the same sorts of interactions with audio possible, but not rely on Flash. This will mean making it possible for web pages to get at more data within the <audio> element from JavaScript, and therefore that we have to expose more data within the underlying implementation. The way you get something like this done is to file a bug. Thomas filed this bug, which we later discovered was a duplicate of an older bug. This practice is common, and helps to keep discussions focused in one place. After closing the first bug, we’ve moved to the second. If you want to follow along from home, you can make an account on Mozilla’s bugzilla, and then CC yourself to this bug.

In my next posts I’ll show some of the work I’m doing to understand the process of exposing more data to content. We have some existing DOM elements (e.g., canvas) that do similar things now, so that’s where much of my reading is currently taking place.

David Humphrey (humph): My First FUDCon

david.humphrey — Sun, 06 Dec 2009 17:09:55 +0000

Yesterday I spent the day attending day 1 of FUDCon Toronto 2009. It was my first time attending a FUDCon, and I found it an interesting experience all around. I was especially pleased to be able to attend one being held at Seneca, due to the hard work of my colleague, Chris Tyler.

I have attended and organized many open source events in the past, and I was most interested to observe Chris’ community, in order to see what they do differently. FUDCon is a conference for Fedora Users and Developers, and while I tend to think of myself primarily as a developer, in the Fedora context I’m mainly a user. As such, it was nice to be able to attend such a gathering and not feel like I was in the wrong place: so many developer related events are dismissive (or hostile) to non-developers. This point was re-iterated by my colleague, Peter Liu, as we chatted outside one of the sessions. He observed that this community was very friendly and welcoming. I expressed a similar feeling, while also noticing that the two of us where standing under a giant Fedora poster with the word ‘Friends’ taking up the lower third.

The conference was organized using the Bar Camp style. I have never been a fan of Bar Camps, as I think they tend to lead to unpreparedness or disappointment in having prepared and not having your talk chosen. I also find them unnecessarily chaotic–something that appeals to some people, but turns me off. FUDCon confirmed many of my feelings about Bar Camps. We lost nearly half a day getting all the talks pitched (half of the ~200 attendees wanted to give at least one talk) and many of the talks were rejected. Having been a conference organizer many times in the past, I do think it’s nice to spread the work of finding and scheduling talks across the community; but why not do it online in advance of the event and set the schedule so as to avoid wasting time on the day?

Once the chaos was over and the talk schedule taped to the wall, the day got rolling. I attended a number of talks that were quite good (all of which had been well prepared in advance, with lots of demos). The first was a group talk led by Andrew Overholt on the Eclipse Linux Tools and CDT projects. Prior to the talk, Fardad and I had been discussing the difficulty his students have in doing cross platform C++ development, since they have become so dependent on Visual Studio. “What I really need is an equivalent for Visual Studio on Linux and Mac.” I told him he needed to attend this talk, and I was right. The talk demonstrated doing C++ development using visual tools for things like gdb, oprofile, valgrind, etc. They made a very convincing argument for moving our students to Eclipse for both Java and C++ development.

Another talk I really enjoyed was Sami Wagiaalla’s on the new features they’ve added to gdb. Despite the bad rap it gets, I have really come to like gdb. I use it for all my Mozilla development on Linux and Mac, and appreciate the fact that I don’t need to learn a new tool moving between the two platforms. The ‘interface,’ while spartan (disclaimer: I love the command line), is not hard if you’re willing to invest a few hours learning some basics. Sami demonstrated a lot of new C++ features in gdb from the Archer project. The thread debugging and gdb python pretty-printers were perhaps my favourite. It made me wonder if there would be value using Dehydra to auto-generate pretty-printers for complex types in Mozilla.

I also gave a talk on Mozilla Tools, and presented Dehydra, Treehydra, JSHydra, Pork, and DXR. I wanted to make the case to the Fedora/Linux/Eclipse communities that these tools can and should become a part of the way we work. For example, during the Eclipse talk I was interested to learn how they currently collect auto-complete information for C++. Using Dehydra it would be possible to do this in a much more accurate way. During the talk I was also able to demonstrate some ways in which Mozilla has done automatic rewrites, including Ehren’s work to optimize away functions that always return zero. Chris also joined me in the presentation, and gave some ideas for Fedora-specific uses of these tools, for example a Fedora-wide DXR.

Half-way through the day, Fedora’s project leader, Paul Frields, stopped me in the hall to see how my experience had been so far: “Are you enjoying yourself?” I could honestly answer in the affirmative. I think that it’s interesting to see the attention of the project’s leader being focused on the experience of the attendees. It says a lot about him, and a lot about the culture of this community. A big thanks to Chris Tyler and others for making this event possible. I’m looking forward to attending some more of it on Monday.

Frank Hecker (hecker): Leaving Mozilla

hecker — Sat, 05 Dec 2009 06:23:03 +0000

Just a quick note to let all of you know that I’ll soon be leaving the Mozilla Foundation to take a new position as a sales engineer in the Federal sales group at IronKey. My last day at the Foundation will be Friday, December 11. Those of you with whom I worked pre-Mozilla know that this is a return to what I’ve done for most of my career (and I’ll be working with folks I’ve enjoyed working with previously). It’s been fun and interesting to work at Mozilla, but it’s time to move on.

I’m spending my last few days at the Foundation working on transitioning my various duties to others and helping out with planning for 2010. If there’s anything you need from me before I leave, please contact me in the next few days. After December 11 you can reach me at hecker@hecker.org; my work address will be fhecker@ironkey.com if you want to contact me on IronKey-related matters.

I appreciate all the help and support I’ve gotten from other folks at Mozilla. I’m sorry I won’t be able to thank all of you personally, and I won’t be at the Mozilla all-hands meeting next week so I won’t be able to say good-bye in person. I wish you all the best of luck in your endeavors, and look forward to seeing all the great things coming from Mozilla over the next year, from new releases of Firefox and Thunderbird to the start of Mozilla Drumbeat.

Posted in mozilla

Frank Hecker (hecker): Mozilla Education: Looking back and ahead

hecker — Fri, 04 Dec 2009 04:45:29 +0000

I’m currently working on putting together a draft plan for Mozilla Education activities in 2010. I’m a bit blocked on coming up with a coherent plan, so I thought I’d try to unblock myself by blogging my thoughts on the subject. These are informed by the recent feedback on Mozilla Education I solicited from several Mozilla folks, as well as the Mozilla Education 2009 report I wrote earlier. Note that I’m thinking out loud here, so this will be somewhat long and rambling.

Based on the feedback, the first point to address is: What is Mozilla Education, and what are its goals? The people I asked were familiar with what Dave Humphrey has been doing at Seneca College in terms of introducing students to Mozilla, but weren’t clear on what was going on beyond that. So, some explanation: “Mozilla Education” as a program started out as an effort by the Mozilla Foundation to take what was going on at Seneca and try to replicate it at other schools, on the assumption that the Seneca approach was worth replicating. (There seems to be general agreement on this, though as discussed below there are some limitations to this approach.)

The primary goal of Mozilla Education now and going forward is to help grow a new generation of Mozilla contributors by working with students and educators around the world. In the original Mozilla Education planning document we outlined another broader goal around promoting general innovation in education (“help to drive a new wave of participatory, student-led learning in fields like computer science, design and business”). As discussed in the progress report, we’ve since deemphasized that second goal and are now focusing Mozilla Education efforts primarily on the Mozilla project proper.

In the context of this discussion the term contributorcovers anyone who makes a significant positive impact on Mozilla worthy of recognition; this includes both technical and non-technical contributions, anything from doing heavy-duty Gecko hacking to helping out with marketing Firefox. Thus there are multiple types of students and educators who might participate in Mozilla Education, and multiple types of activities directed toward them. To provide a bit more focus, let’s follow the advice of one of the people who provided feedback and discuss 1) what has worked (and not worked) in the past and 2) how we might take what’s worked and establish scalable processes for the future.

The first thing to note is that the Seneca approach–integrating teaching of Mozilla technologies and practices directly into college and university courses–is proving to be somewhat replicable, with several schools and professors now teaching or planning to teach such courses. (See the progress report for a full list.) However the pure Seneca-style approach has some limitations, at least from the point of view of producing core Mozilla contributors: It has been successful in producing good contributors in such areas as build infrastructure and release engineering, but less so in terms of producing contributors who are hard-core Mozilla hackers.

In my opinion this is not so much a failing of the approach as it is a failing of academia: The schools that have been most open to integrating open source development work into the classroom (like Seneca) are the schools that focus more on practical instruction for job-seeking students. The high-end research universities that attract top-quality computer science students are the ones least interested in anything that smacks of vocational education.

Until and unless this situation changes, I suspect that the most realistic approach to growing full-time core Mozilla contributors (i.e., people who are good candidates for employment at the Mozilla Corporation or Mozilla Messaging) is as follows:

Continue to promote the Seneca approach to schools that are most likely to be receptive to it, and in particular try to target schools interested in teaching topics like quality assurance through automated testing, continuous integration, and other software engineering practices needed in large-scale projects like Mozilla.
For research-focused institutions, pursue a more lightweight approach of encouraging professors to have students do Mozilla-related senior projects and independent study, either based on self-generated ideas or based on tasks previously identified as being good student projects. Note this is lightweight only in the sense that it demands less of the school and its faculty; in practice this approach will be limited by the amount of effort existing Mozilla contributors can devote to helping students.
For recruitment of hard-core hackers continue to rely on recruiting students from top schools as Mozilla Corporation or Mozilla Messaging interns, outside the context of the Mozilla Education program proper. In this context it’s easier to justify the amount of time needed to bring such students up to speed.

Moving beyond the issue of growing new core contributors, a second topic is that of encouraging students to make technical contributions outside the context of the core Mozilla code. This could include working on Firefox or Thunderbird add-ons, developing web applications that make use of new Firefox features, working with the various technologies being prototyped by Mozilla Labs, and so on.

In the context of Mozilla Education the Processing for the Web project (based on processing.js) is the primary project of this type thus far, and is proving to be quite successful. Projects like this are somewhat peripheral to the core Mozilla activities around shipping new releases of Firefox, Thunderbird, etc. However they do get more people involved in working with Mozilla technologies and code, help to promote adoption of Mozilla products, and help support other Mozilla activities, whether technical or not. (For example, the Processing for the Web work could be used in the context of the “visualize the (open) web” project proposed as part of Mozilla Drumbeat.)

In my opinion doing projects like Processing for the Web is a useful and scalable approach for two reasons. First, it provides a common focus for lots of student work, so that the limited time of mentors can be leveraged across more people: A mentor can help many students at once, and students can help one another. Second, it leverages the time and expertise of people outside the project (in this case people like Al MacDonald who were already working on processing.js), further lessening the burden placed on core Mozilla contributors.

Are there other possible projects like Processing for the Web that could serve as a focus for student contributions? One possibility is a project around Dehydra, Pork, and similar code analysis and rewriting tools designed for large code bases like Mozilla’s. Like the Processing for the Web project, such a project could leverage an existing community of people outside of Mozilla, including developers working in the GCC project and others developing or working with advanced code analysis tools.

Another way to engage students is the design challenge approach pioneered by Mozilla Labs and then adopted in a Mozilla Education context for the Jetpack for Learning Design Challenge. Design challenges and similar contest-like events have proved successful at attracting student participants, including design students and others who are not programmers at heart. Keys to success include have a fairly tightly focused challenge, along with one or more expert mentors who can help the students realize their ideas.

Because they’re focused on leading-edge work not yet ready for incorporation into standard shipping products, the Mozilla Labs folks have some freedom and time available for running design challenges that other Mozilla core contributors don’t necessarily have. In the context of Mozilla Education running a design challenge would typically finding third party subject matter experts to help with the challenge, which in turns means that challenges would typically require additional funding over and beyond what the Mozilla Foundation spends on the basic Mozilla Education program.

With that in mind, here are my thoughts on how Mozilla Education should approach engaging students to contribute outside the context of the core Mozilla codebase:

Sponsor at least three projects in 2010 that can each serve as a focus for engaging larger groups of students:
- continuation of the Processing for the Web project
- a new project around tools for analyzing and/or rewriting code, leveraging existing work by Taras Glek and others and done in loose cooperation with the GCC project or others
- at least one other new project in an area yet to be determined.
Start at least one new Mozilla Education design challenge project in 2010, if (and only if) there is a suitable problem (e.g., one that doesn’t overlap with planned Mozilla Labs challenges) and funding can be found.
coordinate with Mozilla Labs to cross-promote Labs design challenges to the students involved in Mozilla Education activities, and vice versa.

Thus far I’ve primarily discussed engaging with CS students and others in related IT-centric programs. What about students in other areas, such as design or marketing? My feeling is that in 2010 at least Mozilla Education won’t play a major role in terms of growing core contributors in those areas, primarily because they’re outside the expertise of the main people working on Mozilla Education activities.

However that doesn’t mean that those areas have to be (or can be) ignored from a Mozilla Education point of view. One of the things we discussed in 2009 was the role of the proposed education.mozilla.org web site (currently instantiated as a set of pages on wiki.mozilla.org. We’ve pulled back on some of the more expansive ideas for what that site might become. However I do think it makes sense to use it as a central point from which students can find information on Mozilla activities of potential interest to them. That leads to my final Mozilla Education proposed activity for 2010:

Establish and actively maintain a single high-profile page (e.g., www.mozilla.org/education) that can serve as a portal to information about Mozilla activities of potential interest to students, including not only Mozilla Education material but also links to Mozilla Labs design challenges, student internship opportunities, etc.

Those are all my thoughts for now. If you have comments or questions about the above, please let me know. I’ll next boil this down into an actual plan.

Posted in education, mozilla

Planet Mozilla Education

Mark Surman (surman): Need feedback: generic Drumbeat slides

Mark Surman (surman): Why is there flash video on my blog?

Gordon P. Hemsley (GPHemsley): PHP, MySQL, and the BIT field type

David Humphrey (humph): Writing Automated Tests for Processing.js

Joshua Cranmer (jcranmer): Developing new account types, part 1: The folder pane

Account implementation decisions

Implementing protocol information

Server and root folder discovery

Folder discovery

Folder pane extras

Notes

Simon Teo (Simon): Mozilla Project Proposal

Daniel Le Duc Khoi Nguyen (Libras2909): Mozilla project – Proposal

Lindauson Hazell (Lindauson): Confusion...confusion...then Hope

Boris Zbarsky (bz): Understanding the numbers your profiler gives you

Processing.js Blog: Processing.js v0.4.0 Released

Development Process

Linting

Get involved!

ChangeLog:

David Humphrey (humph): The case of the open file handle

David Humphrey (humph): Bad Gr@mm3r?

Lindauson Hazell (Lindauson): Confusion...then more confusion

Chris Cai (anttyc): Sunday Afternoon

Fatma Meawad (fmeawad): Respect the “H”

Boris Zbarsky (bz): Cross-compiling success

David Humphrey (humph): Giving the parser a B-

Lindauson Hazell (Lindauson): Where are the changes?

Simon Teo (Simon): Runway clear and safe?

Fog!!!! – Earlier of the day

Help is no where? It’s now here! – Lessons

Proposal

Plans for Near future

Plans for the future

Benjamin Smedberg (bsmedberg): Multi-Process Plugins on By Default

Daniel Le Duc Khoi Nguyen (Libras2909): Mozilla Project – the fun has just started

Mark Finkle (mfinkle): XULRunner 1.9.0.x Releases – The End is Near

Chris Cai (anttyc): For my eyes only

Srirang G Doddihal (Brahmana): Script to get nsIWebProgressListener state names from state codes

Mark Surman (surman): A truly global drumbeat

First, a few principles

Some ideas on getting started

Drumbeat needs your help

A final thought

Nikhil Kapur (Nik): libvorbis and Milepost

Nikhil Kapur (Nik): nspr and Milepost

Chris Cai (anttyc): A sign post

Boris Zbarsky (bz): H.264 patents outside the US

David Humphrey (humph): On the joys of the test harness

Benjamin Smedberg (bsmedberg): Error calling method on NPObject!

Simon Teo (Simon): I’m ready to go!

David Humphrey (humph): San Francisco goes Open Source

Joshua Cranmer (jcranmer): Developing new account types, part 0: An introduction

Backend introduction

Important interfaces and their interactions

Notes

Benjamin Smedberg (bsmedberg): Firefox 3.6

Mark Finkle (mfinkle): Perils of the viewport meta tag

David Humphrey (humph): Experiments with audio, part VIII

Boris Zbarsky (bz): From the mouths of babes

Mark Surman (surman): MozFdn in 2010: a status update

Mark Finkle (mfinkle): Prism 1.0 Beta 3 – Getting Closer To Final Release

Mark Surman (surman): Learning from 10 yrs of Bugzilla data

Mark Surman (surman): January Mozilla Drumbeat update

Headlines

Early participation

Projects

Events

Web site

Mark Finkle (mfinkle): Add-ons and Restarts – Yuck!

Boris Zbarsky (bz): More on distcc

David Humphrey (humph): Experiments with audio, part VII

Boris Zbarsky (bz): Toolwhip, distcc, and faster compiles

Joshua Cranmer (jcranmer): Building packages: harder than they look

Step 1: Build simpl

Step 2: Build binutils

Step 3: Build (cross-compiling) gcc

Step 3.5: Test the build

Step 4: Build newlib

Step 1: Build `simpl`