Default to curses interface for mtr

I really like mtr (the traceroute tool), however, it always bugged me that it launches a GUI app instead of using the curses interface. You can easily pass the “-t” or “–curses” flag to default to the curses interface, but I always forget.

So today I set about writing a patch for mtr to read a environment varable to force the curses interface. While I was reading the source I noticed there was already a simple undocumented way!

export MTR_OPTIONS=-t

Voila the curses interface is now used by default. This is certainly going into my ~/.bashrc

Google Chrome Javascript console.log bug?

I recently stumbled across this issue while debugging some Javascript. Take the following example code:

	var array = [1,2,3,4,5,6,7,8,9,10];
	var i = 0;
	while(array.length > 0) {
		console.log(i++, array);
		//alert("pause");
		array.pop();
	}

If you run it in your browser you would expect to see the following printed (in your Javascript console):

	0 [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
	1 [1, 2, 3, 4, 5, 6, 7, 8, 9]
	2 [1, 2, 3, 4, 5, 6, 7, 8]
	3 [1, 2, 3, 4, 5, 6, 7]
	4 [1, 2, 3, 4, 5, 6]
	5 [1, 2, 3, 4, 5]
	6 [1, 2, 3, 4]
	7 [1, 2, 3]
	8 [1, 2]
	9 [1]

However, I instead saw:

	1 []
	2 []
	3 []
	4 []
	5 []
	6 []
	7 []
	8 []
	9 []

The issue seems to be that console.log() does not log straight away. In fact it most likely logs in a background thread for performance reasons. Thus by the time it actually logs the array it has changed. I tested this in Firefox (with Firebug) and it logged everything correctly. I also tried slowing down the loop by adding a alert() call. That fixed the issue at the cost of a popup every iterations.

What really should happen is either

  • console.log() should block until the logging is complete
  • console.log() should copy all objects to avoid them being changed after log() returns but before they are printed.
  • add a console.flush() and make me aware this race condition could occur.

I filed this as a bug report on the Chromium site, but I suspect I should have filed it over at the Webkit site.

For the moment I came up with a “fix”. I copy the array before I log it, so in this case I do the following:

	console.log(i++, array.slice(0));

Update: I previously searched for this bug, but didn’t find it before writing this article. However, I have just found someone else had reported it a few days ago:

HTML5 Canvas: Lunch Wheel

In the on going battle to make my lunch time more optimised I decided to learn some Javascript, and how to use the HTML5 Canvas element. Turns out it’s not that hard, and I have now created



The Lunch Wheel
. It helps me find lunch close to my office in the Courthouse area of Arlington, VA.

While making this I found that information on the Canvas element seemed to be lacking. For example, not many sites talked about ways to optimise or profile the javascript. Also I was disappointed to see that not all browsers supported the Canvas completely. Here is a quick list of the problems:

1) Firefox 3.5 (linux) doubled the size of the fonts when I was setting the font in “pt”. When I switched to “em” things seemed to work consistently across browsers. 30fps

2) Android 2.2 (Droid 2) works well but slowly. It also didn’t support the Audio tag. 6fps

3) Android 3.0 (Xoom Tablet) seemed to have some issues rendering half of the wheel. It looked like a bug with the hardware acceleration. I made some minor tweaks to the rendering and things started to work. 15fps

4) iPhone 3 didn’t render any of the text, but played the sound and spun the wheel. 3fps

5) iPhone 4 rendered fine but as slowly as the Android 2.2 device. 5fps

6) Chrome (linux) worked great, and was the platform I was developing on. 30fps (max)

I was also using the clip() method to ensure the text didn’t go outside of the wheel, but this heavily impacted performance. So instead I just chopped the text manually and performance doubled.

I realise HTML5 is new, but I’m really hoping all browsers will start to support it consistently and across the board. I’d hate to start writing large blocks of code to cope with all the browser quirks.

Also, thanks to jQuery, TinySort and ExplorerCanvas (which I still haven’t made work).

Update: Soon to come, the ability to find your own lunch places, as well as integration with foursquare so you can see how popular the venues are with your friends.

Beware the \r\n with grep -f, also perhaps PHP is a better choice?

I had two files, one large CSV file (10million rows), and another file (600K rows). I wanted to find all the lines in the large CSV file that contained a word in the smaller file. The smaller file was a simple text with one word per line.

I found that grep could do:

grep -f smallfile largefile > results.csv

Which would build a list of patterns from the contents of the smallfile. This seemed simple enough, however it didn’t work. Some investiagtion showed that the smallfile had windows
new lines, and grep assumed the \r was part of the pattern. Using dos2unix fixed my problem.

However, new problem, grep used 100% of my CPU and 2GB of my RAM and took over 5 hours. I actually gave up before I let it finish. I assume it was building a large regexp parse tree.
So I figured to allow it to make a simpler tree I would alter my smallfile to contain “^keyword”, instead of just “keyword”. I could do this because I knew the keyword would always
be at the beginning of the line. So awk ‘{print “^”$1} smallfile allowed me to do that. I tried grep again but it seemed to again be taking a long time.

While waiting for grep to finish, I started to write a PHP script:

<?php
// Prints out each line from a CSV where the first entry is in another list
// By Andrew Brampton March 2011
// php inlist.php bigfile smallfile
// TODO we need better names and more error checking

$bigfile = $argv[1];
$littlefile = $argv[2];

$little = array();
$fp = fopen($littlefile, 'r') or die('Failed to open little file');
while ($line = fgets($fp)) {
        $line = trim($line);
        $little[ $line ] = true;
}
fclose($fp);

$fp = fopen($bigfile, 'r') or die ('Failed to open big file');
while ($line = fgets($fp)) {
        $num = strpos($line, ',');
        $num = substr($line, 0, $num);

        if (isset($little[$num])) {
                unset($little[$num]); // We unset so we can get a count/list of all those not in the list
                echo $line;
        }
}
fclose($fp);
?>

It took me 10 minutes to write this. I quickly ran it, and it completed within 20seconds. Looks like this is a far more efficient way to do it :)

Linux 64bit Flash glibc memcpy bug

Does your Linux 64bit version of Flash now make anonying beeping/distortion noises while playing videos? Well it turns out a recent “improvement” to glibc has caused some programs to now crash or do weird things. This is to do with an improvement of memcpy, which makes its use more strict, causing those applications that incorrectly used it to now crash.

On Debian, there is a simple a fix that allows you to use the original memcpy. You can load the application using an additional .so file:

LD_PRELOAD=/usr/lib/libc/memcpy-preload.so /path/to/your/program

As I use Google Chrome when using Flash I had to do the following:

LD_PRELOAD=/usr/lib/libc/memcpy-preload.so /usr/bin/google-chrome

but if you want to fix chrome on a system level, you can edit the Chrome Wrapper used to launch it.

sudo nano /opt/google/chrome/google-chrome

add the following line

export LD_PRELOAD="/usr/lib/libc/memcpy-preload.so"

for example

export LD_LIBRARY_PATH
export LD_PRELOAD="/usr/lib/libc/memcpy-preload.so"

export CHROME_VERSION_EXTRA="beta"