Release 6, Release 7, and Reflections

Hello everyone. This will be my last post for my Open Source electives, and I can honestly say I’ve enjoyed my time working with the assortment of projects I was able to get involved with. Without further ado, my updates:

I had a few outstanding issues to resolve with earlier PRs. For my issue 122 fix I had to resolve a nit modeswitch had with my sh.mv documentation. I had explicitly included ‘./’ in most of my examples, and he said that since that would be implicit I could just omit every reference. I also had to fix an asynchronicity issue in my Unix timestamp fix (done() was called twice in one test, and I resolved by making timestamp conversion synchronous and catching parse errors instead).

My first new issue, issue 158, involved adding a new test to fs.watch()’s spec to ensure that when a file is changed, watches on hardlinks are updated as well. I added the test, and was able to verify that it worked, but found out that fs.watch() is not working correctly. When original files are modified, watchers tracking hardlinks will not be notified, so my test currently times out. When I receive more feedback on my PR, I’ll probably be filing a new bug to report this issue.

My next issue, issue 87, required an implementation of fs.fsync(), a command which typically writes open file buffers to disk when called. Because of the way filer’s architecture is laid out at the moment, fsync() doesn’t apply (we don’t have unwritten buffers that would wait for such a command). For the time being, fsync() has been implemented as a no-op. I did include some basic tests and documentation changes, as well.

Issue 7 required project documentation to be altered so that it explicitly mentioned the accepted type for our ‘buffer’ parameters. The only valid argument is a subclass of ArrayBufferView; ArrayBuffers were invalid, but there was no mention of that in the docs, and for some it would be counter-intuitive. This was a quick and straight-forward change.

Issue 97 was a similarly simple documentation change. In an earlier issue, Dave and modeswitch had determined that we will not be implementing fs.realpath() at this point in the software stack, because there is no awareness of a current working directory. For that reason, it has been relocated to filer.io, which should provide that context. I changed the documentation entry to explain this choice in case users wanted it for node.js parity.

My last issue, issue 42 required modifications to fs.read() to accommodate node.js’ legacy argument format. I managed to get this implemented (despite some headaches with remapping arguments), and included a test.

Finally, I wanted to summarize how these courses have shaped my opinions of open source development. Above all, I have realized the value of open cooperation and collaboration. These tenets result in an unequaled environment for learning best practices and production level programming. Having a networked community (via Github and IRC) presents opportunities that wouldn’t appear in typical bedroom coding scenarios. Through these courses, I learned that JS is actually a viable language for web application development (and that the open frameworks supporting that paradigm are much more refined than I would have thought). I was introduced to a variety of technologies and patterns that I would not have been exposed to in my regular courses; marketable skills that have helped me in my co-operative education pursuits. It also gave me the ability to orient myself in new code bases, experience I had been sorely lacking until now. I’ve learned that if I want to be successful moving forward, I need to make more of an effort to assert myself, communicate with my peers, and schedule ample time for professional development.

Thanks everyone. I just wanted to say that I’ve had fun, and I certainly intend to continue with my contributions.

GLHF

Kevin Kofler

PRs:
Issue 86
Issue 122
Issue 158
Issue 87
Issue 7
Issue 97
Issue 42

A Belated Release 5

Better late than never, I suppose. For this release I have a few more Filer bugs, all of which add new functionality to the project.

First up, issue #122. David Humphrey recently got a Filer shell implemented, and a couple of shell commands were requested. Issue #122 involves the implementation of sh.mv with tests and documentation, which I’ve recently completed. The relevant pull request can be found here. sh.mv takes two arguments (source and destination) and a callback, and will attempt to “move” the node at source to the path specified in destination. The majority of my problems with implementing mv involved misunderstanding the use of callbacks; a couple of times some dependent code was accidentally left out of the callback (statting a directory before I was sure that the async creation had finished, for instance -_-). Dealing with the many callback nests in mv has given me a much better understanding of the pattern, however.

Next, we have issue #136. This one was very simple. A couple of our storage providers (IndexedDB and WebSQL) will fail when the user is trying to run an instance of Filer in a Private Browsing window. This issue involved adding a more verbose error for this particular issue to minimize the headaches involved in debugging it.
The relevant pull request is here.

Finally, we have issue #86, in which I added support for Unix-style timestamps. The relevant pull request is here.

Release 4 – Fixing patches and adding features

Hello all. Release 4 is going to be a little light (we’re in crunch mode for our capstone project at the moment) but I’m getting comfortable working with Filer. I’ve finally landed a patch for issue #112, which implemented node.js’ Stats object methods. The version from my last release misused the constants syntax, and had a test suite written for Jasmine. The revised patch rewrote these in Mocha, and was more comprehensive.

Currently, I’m working on issue #122, a request to implement a Unix-style mv command for our new shell implementation. I’m writing the relevant function (found here) and a Mocha test suite (in progress), and will be submitting a pull request shortly.

As I’ve continued working with this project, I’ve realized that extending Filer with version control system features may be an interesting proposition. My next release should include some work that I’ve started for implementing filesystem branches, though I’ll have to discuss this with my professor and the Filer project leader.

Release 3 – A New Domain

This will be short again -_- I’ve recently started working on Filer, a browser-based file system for JS applications, and I’ve only had time for one simple bug for this release: issue #112. I added a few diagnostic functions to the Stats object prototype, a structure returned by calling stat() on a node in the file system. While the necessary changes were minute, this was my first opportunity to write tests for a JS testing framework, and it was quite interesting. My next releases should have much more content!

Release 2 – Change in plans

Hello all! As I’m sure you can gather from the title, I’ve had to shift my focus in DPS911. Firefox OS, while quite interesting, has been difficult for me to work on in the release schedule we are bound to. The development community moves so quickly that I’ve had bugs invalidated or fixed while I was studying/working on them, and as a result I’ll be moving into the much less tumultuous Filer project.

As a result, my second release is short and sweet. I was still working on creating a Mercurial patch for bug 927320. This work remains incomplete as I transition to Filer, though I’ll be coming back to finish it.

(This post is for posterity, it would have been applicable a few weeks back. Release 3 post forthcoming)

Patching Gecko (Generating Mercurial Patches)

Hello everyone. My last release contained what I THOUGHT would be a successful patch for Mozilla’s Gecko build (barring one unfortunate typo -_-), but it turns out that GitHub is not used for submitting patches. I needed to install Mercurial, configure it properly, and generate a patch file. Since I’m getting tired of struggling with Windows, I got everything up and running in Linux Mint 64bit. For those interested, this guide will help you get everything installed and configured, this guide will teach you the basics of Mercurial’s queuing system (the use of which is necessary for creating patches), and finally this guide will teach you how to clone the Mozilla development repository, and how to create a patch to be submitted on Bugzilla. I’ve finally got the hang of all of this, and I’ve submitted the revised HG (Mercurial) patch for bug 927320. See you all this Friday for release 2!

DPS911 Release 1

Only two simple bugs for this release; Firefox OS has been decidedly difficult to get started with.

The first bug, bug 937443, involved changing a few strings within Gaia’s settings application. This gave me a chance to familiarize myself with the B2G project structure (so many repos!) and try out the various ways of running FFOS on an x86-64 computer.

The second bug, bug 927320, involved renaming some file/interface/class names related to the Radio Interface Layer, which gave me an excuse to fork and look into the base Gecko repository (gecko-dev). Just as a warning to anyone interested in cloning it, it’s freaking massive (around 1.3GB). I’m hoping to try a few hardware specific bugs for my next release.

Stay tuned for an update on my project page! If all goes well, I’ll be working on a resource monitoring application for FFOS that I hope will be incorporated into Gaia. I can dream at least 😛 My project page is currently empty, but you can find it here.

Bug 937443

Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=937443

Pull Request: https://github.com/mozilla-b2g/gaia/pull/15737

Bug 927320

Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=927320

Pull Request: https://bugzilla.mozilla.org/show_bug.cgi?id=927320

Firefox OS – A primer

I’ve decided that for those of you who are interested, and perhaps those of you considering a new project for your subsequent releases, I’ll be writing a brief summary of the Firefox OS project, the various components thereof, and how to set up the test environment for each relevant platform (I’ll be using an x86 Boot2Gecko emulator on Windows, a Firefox browser extension, and the “Keon” developer preview phone). I’ve also got some bad news to relate about the status of one of my bugs! It’ll serve as a warning to those of you that like leaving assignments to the last minute 😛

Firefox OS is an open source mobile operating based on the Linux kernel and Mozilla’s Gecko web rendering engine. Essentially, the entire OS is contained in a stripped down web browser, which means that FFOS applications are coded using web standards like HTML5 and JavaScript in patterns that should be familiar to web developers. What are the benefits to this approach? Rapid iteration and prototyping spring to mind immediately; using a JavaScript interpreter of course means that there is no compilation process that needs to take place before an application is run. Like web development, changes to views can be evaluated almost instantly. Another benefit to this approach is, similar to Java, very portable code. JavaScript virtual machines need to be tailored to individual processor implementations, but the application code is identical across platforms (more or less, since styling may need to be device specific).

Firefox OS has two main repositories: the Boot2Gecko rendering engine implementation, and the “Gaia” OS UI, which is of course written in HTML5 and JS. There are also a number of device specific B2G repos and dev tool repos available through Mozilla’s mozilla-b2g GitHub profile.

Because of this system architecture, we’re able to test FFOS applications within the Firefox browser! There is an extension named Firefox OS Simulator (the latest version can be found here) which allows developers to test their apps in browser on any operating system capable of running Firefox 26. This simulator is compatible with Firefox’s web development tools, and actually includes a few features (such as the screen orientation and geolocation buttons) which are not available on the usual desktop build of B2G. Simply install the .xsi file at the link above to install the add-on; navigate to about:app-manager and the “Start simulator” button should be visible at the bottom of the page.

The app manager page

The app manager page

After starting the simulator, start the appropriate build (only 1.2 is stable at the moment)…

Button to start simulator

…circled above…

…and the simulator should be up and running.

Firefox OS Simulator screen-cap

It’s beauuuuuuutiful.

The simulator’s actually pretty interesting. The App list can be populated by hosted applications (using a URL) or by packaged applications (using a local directory identifier). Sadly, the simulator can only be used to test applications; testing Gaia requires either Firefox Nightly with the appropriate profile or…. drum roll please….. an x86 B2G emulator!

Nightly builds of B2G desktop can be found here. I’m going to be using the Linux 64bit version, as getting anything related to FFOS working under Windows was a supreme headache, and frankly was not worth the effort. To make a long story short, the make commands in Cygwin and MinGW are nowhere near as flexible as the make command under Linux, in that they were unable to work with the heavy use of JS within Gaia’s makefile. Anyway, once you’ve downloaded the appropriate version (depends on which release you want to debug – I have a bug that I’m working on which is 1.1 specific), simply extract the folder and run the b2g binary. By default, the version of Gaia included in the archive will be used, but the binary takes a command line argument which will target another local copy of the Gaia directory (more on that later). Otherwise, the emulator is ready to go!

Finally, Firefox Nightly can be configured to run a local Gaia profile for quick testing and debugging. This works in a similar manner to the above B2G emulator retarget. In both cases, navigate to the root of the Gaia directory that you’re working on, and run the command “DEBUG=1 make” for Firefox Nightly or “DEBUG=1 DESKTOP=0 make” for B2G desktop. This creates a profile folder that can be used by both Firefox Nightly and B2G Desktop (the path is the same for both makes, and is displayed right at the end of the command’s output); the next step in both cases is to start the respective binaries with the argument “-profile /path/to/profile”, and your changes should be visible as you navigate the UI.

Finally, a warning: Firefox OS moves quickly. In a matter of days, my first assigned bug was incidentally resolved by someone else’s work on another, lower-level problem (my original bug, and the one that invalidated it). Work fast if you want your contributions to be valid/noticed! On a lighter note, I’ll be following this up shortly with my first release post!

New year, new class, new bugs!

Hello everyone. Over a month since my last blog post… The place is looking a little empty. Just writing a quick update on what I’ve been up to.

I’m now enrolled in DPS911 – Open Source Project, a continuation of my professional option from last term. We have to choose a project from a pool curated by our professor, the eminent David Humphrey, and contribute either a significant number of bug fixes, a (completed) new feature, or a combination of the two. For our first release, Dave has recommended that we choose a “good first bug” related to our project of choice, so that we can ease ourselves into the community. I’ve decided that I want to contribute to Firefox OS, Mozilla’s mobile operating system. It’s built entirely on web standards, which should make it a fairly easy transition from working on Webmaker Suite. I’m looking forward to getting involved!