Not surprisingly, Ubuntu is on top; this distribution is often considered to be the most popular among desktop users. What is perhaps surprising is the magnitude of its popularity: in May 2010 it was more than 10 times as popular as its nearest competitor (SUSE).

Of course, a few caveats are in order:

• Drawing broad conclusions based on the visitors to a particular web site can be problematic; the visitors to the web site may not be representative of all users. (Still, Wikipedia is one of the most popular sites on the entire web, with literally billions of visits every month, from all over the world; it seems unlikely that Wikipedia’s visitor data would be heavily biased towards any particular desktop Linux distribution.)
• Obviously, the data only measure desktop Linux users; they do not reflect the popularity of server Linux distributions.
• In the data, not all Linux users are placed in a specific distribution; some are placed in a generic “Linux” category. (Presumably the user’s browser did not report a specific distribution.)

(At least, that was the error message generated on one monitor. The message was generated by the on-screen display of the monitor itself, so results may vary. You may observe a different error message, smoke coming out the back of the monitor, etc.)

You can read about it in this forum thread; to summarize, the workaround is as follows:

1. When running the installer, just before the error occurs, you will see this cryptic screen:

   

   That cryptic little keyboard next to that cryptic little man apparently means “press any key.” If you do that, a menu will pop up. First, select a language, then press F6 (“Other Options”). A new menu will pop up; use the arrow keys to move to “nomodeset”, and press Enter to select it. Press Esc to dismiss the menu. Then you can proceed with the installation as normal.

2. Of course, this only works for the installer. When you first try to boot your newly installed system, you will get the same error as before. To boot, you will need to add nomodeset to the kernel command line. When you boot the machine, wait for the GRUB menu to appear. (If the menu does not appear, you may need to hold down the Shift key when booting.)

   

   Press e to edit the kernel command line:

   

   Add nomodeset right after quiet splash:

   

   Press Ctrl+x to boot.

3. Of course, editing the kernel command line only affects the current boot process; the next time you boot the machine, you will have to manually add nomodeset again. To fix the problem permanently:
   1. If you have an NVIDIA video card, installing the proprietary NVIDIA driver may make the problem go away.
   2. Alternatively, you can edit the file /etc/default/grub and change the line

      GRUB_CMDLINE_LINUX=""
      

      to

      GRUB_CMDLINE_LINUX="nomodeset"
      

      Then run

      sudo update-grub
      

      See the release notes for details.

1. Using JSCoverage with the script.aculo.us test suite
2. Using JSCoverage with the MochiKit test suite
3. Using JSCoverage with the jQuery test suite
4. Using JSCoverage with the MooTools test suite
5. Using JSCoverage with the YUI test suite
6. Using JSCoverage with the Dojo test suite
7. Using JSCoverage with the JsUnit test suite (this article)

Unlike the previous articles in this series, today we will not examine the test suite for an all-purpose JavaScript library, but instead we will look at JsUnit, dedicated JavaScript test framework. JsUnit comes with its own test suite, used to test the JsUnit code itself. To run this test suite, we will download the latest release (version 2.2 as of this writing). JsUnit is easiest to use running on a web server, so we will install it in the document root of a local Apache web server, running on port 8080. Then we can load the following URL in a web browser to run the test suite:

http://127.0.0.1:8080/jsunit/testRunner.html?testPage=http://127.0.0.1:8080/jsunit/tests/jsUnitTestSuite.html&autoRun=true

To collect code coverage data for this test suite, we will need to run it in JSCoverage’s “inverted mode,” since it does not run well inside a frame. This means we will have to add a button to the JsUnit user interface to launch the jscoverage.html file in a separate window. Looking at the jsunit/app/main-data.html file, we see that the existing buttons are generated dynamically via script; we will generate our button the same way:

document.writeln('<input type="button" name="runButton" value="Run" onclick="top.startTests()" class="' + buttonClass + '">');
document.writeln('<input type="button" name="stopButton" value="Stop" onclick="top.stopTests()" class="' + buttonClass + '">');
document.writeln('<input type="button" name="jscoverageButton" value="Coverage Report" onclick="window.open(\'../jscoverage.html\');" class="' + buttonClass + '">');

Then we can instrument the code using the jscoverage program:

jscoverage --no-instrument=tests jsunit instrumented-jsunit

We can run the instrumented test suite at the following URL:

http://127.0.0.1:8080/instrumented-jsunit/testRunner.html?testPage=http://127.0.0.1:8080/instrumented-jsunit/tests/jsUnitTestSuite.html&autoRun=true

We can click on the “Coverage Report” button to view code coverage statistics:

1. Using JSCoverage with the script.aculo.us test suite
2. Using JSCoverage with the MochiKit test suite
3. Using JSCoverage with the jQuery test suite
4. Using JSCoverage with the MooTools test suite
5. Using JSCoverage with the YUI test suite
6. Using JSCoverage with the Dojo test suite (this article)

First, we need to download the Dojo SDK, which includes the Dojo test suite. The latest release is currently version 1.4.2. This release unpacks to a directory named dojo-release-1.4.2-src. Some of the tests in the test suite need to be run under a web server, so we’ll install the distribution in the document root of an Apache web server, running on port 8080. Then, the test suite, which uses a test framework called DOH (the Dojo Objective Harness), can be executed by loading the URL http://127.0.0.1:8080/dojo-release-1.4.2-src/dojo/tests/runTests.html in a web browser:

To obtain code coverage data for this test suite using JSCoverage, we will need to make one modification to the source code. The DOH test framework does not work well running inside a frame, so we will use the JSCoverage “inverted mode” to run it: we will add a button to the file util/doh/runner.html which launches the JSCoverage user interface:

<h3 style="margin: 5px 5px 0px 5px; float: left;">D.O.H.: The Dojo Objective Harness</h3>
<button style="margin-top: 5px; float: left;" onclick="window.open('../../jscoverage.html');">Coverage Report</button>
<img src="small_logo.png" height="40" style="margin: 0px 5px 0px 5px; float: right;">

Then we can run the jscoverage program to instrument the code. We will use the --no-instrument option avoid instrumenting the test suite itself. Some of the files in the distribution contain non-ASCII characters encoded using the UTF-8 character encoding, so we will use the --encoding option to specify this. (Otherwise, we would get “Illegal character” errors.)

jscoverage --encoding=UTF-8 --no-instrument=dojo/tests dojo-release-1.4.2-src instrumented-dojo

Then we can run the instrumented test suite by accessing the URL http://127.0.0.1:8080/instrumented-dojo/dojo/tests/runTests.html:

Note that some tests failed (indicated by the red sections in the bar at the top). Looking at the DOH “Log” tab, we see a lot of errors like this:

Error: Bundle not found: currency in dojo.cldr , locale=en-us

Looking in the (uninstrumented) dojo/cldr directory, we see it contains a lot of .js files; dojo/cldr/nls/en-us/currency.js is typical:

// generated from ldml/main/*.xml, xpath: ldml/numbers/currencies
({
        USD_symbol:"$"
})

The .js files under the dojo/cldr/nls directory contain valid JavaScript code, but they do not contain arbitrary JavaScript code; Dojo expects every one of these files to contain a single JavaScript object literal. When jscoverage adds instrumentation to one of these files, it no longer contains a single JavaScript object literal, and this causes errors when the test suite is run. We need to use the --no-instrument option to ensure that these files are not instrumented:

jscoverage --encoding=UTF-8 --no-instrument=dojo/tests --no-instrument=dojo/cldr/nls dojo-release-1.4.2-src instrumented-dojo

Then we can run the instrumented tests without any errors:

We can click on the “Coverage Report” button to see the code coverage statistics:

Tomorrow we will look at using JSCoverage with the JsUnit test framework.

1. Using JSCoverage with the script.aculo.us test suite
2. Using JSCoverage with the MochiKit test suite
3. Using JSCoverage with the jQuery test suite
4. Using JSCoverage with the MooTools test suite
5. Using JSCoverage with the YUI test suite (this article)

First, we need to download YUI. We will use the latest release in the YUI 2 series, version 2.8.0r4. The YUI test suite requires a web server to run in some browsers, so we will install it in the document root of a local Apache server, running on port 8080. Also, the file yui/tests/common/tests/YUI.html has a typo that needs to be corrected; we need to change this:

           "../../calendar/tests/datemath.html",

to this:

           "../../datemath/tests/datemath.html",

Once that is done, we just open the URL http://127.0.0.1:8080/yui/tests/common/tests/YUI.html in a web browser to run the tests:

To obtain code coverage data, we will have to make one more modification to the file yui/tests/common/tests/YUI.html. The YUI test framework does not work inside a frame, so we will use JSCoverage “inverted mode” to run the tests. This entails adding a button to the page to launch the jscoverage.html file:

<div id="out"></div>
<button onclick="window.open('../../../jscoverage.html');">Coverage report</button>

Once that addition is made, we can instrument the code:

jscoverage --no-instrument=tests yui instrumented-yui

Note that the YUI distribution is fairly large, so this command may take a while to run. We can speed things up a bit by using the --exclude option to skip some directories that are not needed:

jscoverage --no-instrument=tests --exclude=as-docs --exclude=docs --exclude=examples yui instrumented-yui

Then we open up the URL http://127.0.0.1:8080/instrumented-yui/tests/common/tests/YUI.html in our web browser:

We can then click the “Coverage report” button to launch the jscoverage.html file:

Tomorrow we will look at using JSCoverage with the Dojo test suite.

1. Using JSCoverage with the script.aculo.us test suite
2. Using JSCoverage with the MochiKit test suite
3. Using JSCoverage with the jQuery test suite
4. Using JSCoverage with the MooTools test suite (this article)

First, we need to check out MooTools from its Git repository. We will check this out into the F:\ directory. The repository contains a .gitmodules file referencing Git submodules; we will need those too:

git clone http://github.com/mootools/mootools-core.git
cd mootools-core
git submodule init
git submodule update

MooTools actually has two test suites: one in the Specs directory and one in the Tests directory. The one in Tests is newer and does not have very many tests in it yet, so we will skip that one and just run the one in the Specs directory. To run the test suite, we open the URL file:///F:/mootools-core/Specs/index.html in a web browser:

It lists a number of test suites; we will choose to run “MooTools-Core 1.3: 1.2public + 1.3public”. Clicking on the link loads the URL file:///F:/mootools-core/Specs/runner1.3.html?specs=1.2public&specs=1.3public:

We will instrument this code using the jscoverage tool. We will use the --exclude option to skip the Tests directory and the --no-instrument option to avoid instrumenting the test suite in the Specs directory:

jscoverage --exclude=Tests --no-instrument=Specs mootools-core instrumented-mootools

To run the instrumented tests, usually we open in our web browser a URL of the form file:///.../jscoverage.html?URL, where URL is the URL of the test suite. But note that the test suite URL contains some special characters, so we need to encode these when putting them in a URL:

file:///F:/instrumented-mootools/jscoverage.html?Specs%2Frunner1.3.html%3Fspecs%3D1.2public%26specs%3D1.3public

We can open this in our web browser:

The “Summary” tab displays coverage statistics:

Tomorrow we will look at using JSCoverage with the YUI test suite.

1. Using JSCoverage with the script.aculo.us test suite
2. Using JSCoverage with the MochiKit test suite
3. Using JSCoverage with the jQuery test suite (this article)

To run the jQuery test suite, we need to check out the jQuery Git repository. We will use Cygwin Git and check out the code into the F:\ directory:

cd /cygdrive/f
git clone git://github.com/jquery/jquery.git
make

The make command retrieves some external dependencies (one of which is QUnit, the framework used in the test suite) and builds the jquery.js file. To run the test suite, we just open the file test/index.html in a web browser:

We will instrument the code using the jscoverage program, using the --no-instrument option to avoid instrumenting the test suite directory itself (as we did for the MochiKit test suite):

jscoverage --no-instrument=test F:\jquery F:\instrumented-jquery

Unfortunately, things do not go smoothly; we get the following output:

jscoverage:src/intro.js:18: SyntaxError: missing } after function body
jscoverage: parse error in file src/intro.js

The contents of the file F:\jquery\src\intro.js are as follows:

/*!
 * jQuery JavaScript Library v@VERSION
 * http://jquery.com/
 *
 * Copyright 2010, John Resig
 * Dual licensed under the MIT or GPL Version 2 licenses.
 * http://jquery.org/license
 *
 * Includes Sizzle.js
 * http://sizzlejs.com/
 * Copyright 2010, The Dojo Foundation
 * Released under the MIT, BSD, and GPL Licenses.
 *
 * Date:
 */
(function( window, undefined ) {

That is the entire file. The file is not actually a valid JavaScript file by itself (which is why jscoverage was confused by it) but is used as input to the build process used to construct the final jquery.js file. Since this is needed only for building the code, not for running it, we can skip it entirely when instrumenting the code. We tell jscoverage to do this using the --exclude option:

jscoverage --no-instrument=test --exclude=src/intro.js F:\jquery F:\instrumented-jquery

Running this command, the previous error is gone, but we get a new error:

jscoverage:src/outro.js:1: SyntaxError: syntax error
jscoverage: parse error in file src/outro.js

Looking at F:\jquery\src\outro.js, we see again this is just a fragment of a JavaScript file, not a valid JavaScript file by itself:

})(window);

We will add another --exclude option for this file. (Note that the --exclude option can be used multiple times.)

jscoverage --no-instrument=test --exclude=src/intro.js --exclude=src/outro.js F:\jquery F:\instrumented-jquery

Finally, the command runs without any errors. We can run the instrumented test suite by opening the URL file:///F:/instrumented-jquery/jscoverage.html?test/index.html in our web browser:

Tomorrow, we will look at using JSCoverage with the MooTools test suite.

To run the test suite, first we have to download the latest version of MochiKit (currently version 1.4.2). We will assume this distribution is unpacked in the F:\ root directory, creating the directory F:\MochiKit-1.4.2. Then we can open the URL file:///F:/MochiKit-1.4.2/tests/index.html in a web browser:

To get code coverage for this test suite, we first instrument the code using the jscoverage program:

jscoverage F:\MochiKit-1.4.2 F:\instrumented-mochikit

Then we open the URL file:///F:/instrumented-mochikit/jscoverage.html?tests/index.html in our web browser:

The code coverage statistics are displayed in the “Summary” tab:

That works, but there is one improvement we can make. Notice that the list of files in the “Summary” tab contains both the files in the SUT (in the lib directory) and the files in the test suite itself (in the tests directory). We are not really interested in coverage statistics for the latter; we can tell the jscoverage program to avoid instrumenting these files by running it with the --no-instrument option:

jscoverage --no-instrument=tests F:\MochiKit-1.4.2 F:\instrumented-mochikit

With that command, jscoverage will not instrument any JavaScript files in the tests directory. We can run the test suite again in our web browser and see that the files in the tests directory are no longer displayed:

Tomorrow, we will look at using JSCoverage with the jQuery test suite.

We will start by downloading the latest version of script.aculo.us (currently version 1.8.3) and unpacking the distribution in the F:\ directory (so that the code unpacks to the directory F:\scriptaculous-js-1.8.3). Running the test suite is simple: all we have to do is open the file test/run_unit_tests.html in a web browser. Because we unpacked the script.aculo.us distribution in the F:\ directory, the URL would be

file:///F:/scriptaculous-js-1.8.3/test/run_unit_tests.html

The user interface displays two frames; clicking one of the links in the left frame runs a test in the right frame.

To get code coverage for this test suite, we need to instrument the code using jscoverage.

jscoverage F:\scriptaculous-js-1.8.3 F:\instrumented-scriptaculous

This creates a new directory, instrumented-scriptaculous, which is a copy of the original directory with two differences:

1. All of the .js files in the directory have been instrumented to collect code coverage data when executed.
2. The directory contains a file jscoverage.html (and a few other support files) for displaying code coverage data.

We need to open the jscoverage.html file in our web browser, and pass the path to the test suite in the query string:

file:///F:/instrumented-scriptaculous/jscoverage.html?test/run_unit_tests.html

The run_unit_tests.html is displayed in an iframe; in that frame we can execute the tests as we did before.

After running some tests, we can click on the “Summary” tab to display code coverage statistics:

We can click one of the links to get a detailed view of a source file:

Tomorrow, we will look at using JSCoverage with the MochiKit test suite.