For some reason, inaccurate info ended up in your vdi file. VB is now more strict, and this inaccurate information just needs to be expunged to prevent VB from panicing. See this ticket for details:

http://www.virtualbox.org/ticket/7289

The short of it is: You download the tool for your host platform:

http://www.virtualbox.org/download/VBoxFixHdd/

“Identify the affected images. You can either use the VirtualBox GUI and check which base images are inaccessible, but shouldn’t be. The same can be done with “VBoxManage list hdds”, in this case make sure you only look at images which say “Parent UUID: base”.
Run the repair tool:
VBoxFixHdd –filename /path/to/image.vdi –zeroparentuuid
Repeat for all affected images.”

Worked like a charm.

Click your Windows “Start” button and select “Run”, or hold down the “Windows Key” and press “R”.
Enter “regedit” in the “Open:” dialogue box and press OK.
Press “Ctrl” and “F” to open the Find dialogue.
Enter “Blizzard Entertainment”. It should display a folder on the left entitled “Blizzard Entertainment”. Expand this folder by clicking the “+” to the left of it. You should see a “Downloader” folder. Expand this too. There should be a key with some random string of alphanumerics. Click on that.
In the right pane you should see a key that titled “Path”. Right click on that and click “Modify.”
Change the “Value data” to set the location for the download folder and press “OK”. Close RegEdit.
Enjoy!

Standard disclaimer: when mucking about in your registry, be careful, as you can bork Windows.

Does the directionality of a person’s primary writing system (left-to-right, top-to-bottom for English) affect the way in which they take in other compositions, such as a photo or painting, creating a “perceptual directionality”? If so, should visual composition be informed by knowledge of the target audience’s perception directionality? After a brief search I came up with this paper, which seems to indicate that I’m not too far off the mark.

Writing Direction Influences Spatial Cognition

Now that doesn’t exactly answer the original question, although it does inform the decision of how to compose the shot.

In that case, mb_strlen() becomes strlen(). mb_strlen() is strlen() with support for different charsets, which may use different byte lengths for a single character. By default, it will use your internal encoding. However, it supports an explicit character encoding as its second parameter. Knowing that latin1 uses a single byte, mb_strlen($string,’ISO-8859-1′) will do what we want and count the bytes in $string regardless of your current internal encoding or the string’s apparent encoding.
Let’s wrap this in a function for clarity, and in case we need to change our counting method because of a change in PHP or some such helpfullness:

function bytelength ($string) {
// Returns: (int) number of bytes in string
// Use latin1 as a alias for "1 byte"
return mb_strlen($string,'ISO-8859-1');
}

test-more-php version 0.1 is out now and ready to help prevent hours of debugging with so little effort it’s ridiculous not to use it. The API is a direct port of the popular Perl Test-More library with some minor PHP adaptations. Both object and procedural interfaces are available, so pick your flavor and get coding!

I started test-more-php after getting sucked into writing PHP full-time and casting about for a testing library with the elegance I knew from Test-More. Eventually I discovered a few, but each was incomplete or failed me by silently bailing on an error that could have been reported appropriately. Test-More.php is a drop-in replacement for those other libraries and provides me with the confidence that, if something goes wrong, I will know about it.

I’ve tested it under Windows XP, Ubuntu Linux, FreeBSD and Cygwin but not OS X, so if anyone with a Mac wants to take it for a spin please let me know how if it passes all it’s tests. (Of course it comes with its own test suite!)

I discovered this when I was repointing my jQuery libraries toward the googleapis hosted versions, to take advantage of their speed. I tested the switch in Opera, where it looked fine. Later, doing some debugging with firebug, I noticed those pages were no longer executing any javascript. Chrome had no problem loading them, and initially I thought the jQuery lib was the issue, but curling a new copy proved it was identical to my locally hosted version. Finally I noticed the difference in how I had self closed the script tags, which is perfectly legal… firefox 3 just doesn’t like it.

So I like the ajax.googleapi.com hosted libraries, although I don’t buy that using the google.load() method is better than pointing to the hosted library directly. Profiling the difference between two pages that do nothing more than load jquery shows that using google.load() adds about 0.2 seconds to the load time. Try it yourself:
Pointing directly vs Using google.load(). Which only makes sense, since loading the google api takes time… so where is the extra “power” they boast you receive by using this method? The only potential advantage I see is the ability to load the library conditionally, avoiding the load unless you need the library. I say potentially because I’ve yet to make use of that kind of just-in-time loading. If you have, or I’ve overlooked some strength to this method, I’d love to hear it.

One last googleapi related note: using a script tage to call your library, you can use https to load the file. The google.load() method appears to load files using http, which is quicker but poses a security risk by injecting insecure code into a supposedly secure environment. This is the same reason secure method pages should use the secure-only flag on cookies: you are only secure as your weakest link.