Or for the more cynical:
You catch more flies with honey than you do with vinegar.
Let’s all be nice to each other, folks. :)
Or for the more cynical:
You catch more flies with honey than you do with vinegar.
Let’s all be nice to each other, folks. :)
Inspired by river’s addition of PostgreSQL support, I was gonna make a few quick changes to mwdumper. I figured I’d get Eclipse and the Subclipse SVN plugin set up on my 64-bit Linux workstation so I’d have a decent Java IDE to work on it in.
Well… no.
Neither with the version of Eclipse that ships with Ubuntu Feisty, nor with a fresh copy of it from eclipse.org… when I try to check out from SVN, and get to the final stage, it just… stops. No error message, no explanation. Just the wizard’s done and I’ve got no project.
I… hate… computers.
Update: Mark Phippard explained the secret in a comment — you can check out a project from the SVN Repository browse view, and it works! Thanks, Mark!
I noticed the fallback implementation for mb_strlen() that we had in GlobalSettings.php sucked:
function mb_strlen( $str, $enc = "" ) { preg_match_all( '/./us', $str, $matches ); return count($matches); }
There are two things to note about this code:
I’m replacing this with a new version which uses PHP’s count_chars() function to count up the ASCII-compatible bytes and multibyte sequence head bytes. It’s still a smidge slower than mb_strlen but it’s… much better than the old one.
/** * Fallback implementation of mb_strlen, hardcoded to UTF-8. * @param string $str * @param string $enc optional encoding; ignored * @return int */ function new_mb_strlen( $str, $enc="" ) { $counts = count_chars( $str ); $total = 0; // Count ASCII bytes for( $i = 0; $i < 0x80; $i++ ) { $total += $counts[$i]; } // Count multibyte sequence heads for( $i = 0xc0; $i < 0xff; $i++ ) { $total += $counts[$i]; } return $total; }
Some quick benchmarks using the UTF-8 normalization benchmark pages (code):
Testing washington.txt: strlen 31526 chars 0.007ms mb_strlen 31526 chars 0.114ms old_mb_strlen 31526 chars 4813.686ms new_mb_strlen 31526 chars 0.132ms Testing berlin.txt: strlen 36320 chars 0.001ms mb_strlen 35899 chars 0.129ms old_mb_strlen 35899 chars 6328.748ms new_mb_strlen 35899 chars 0.127ms Testing bulgakov.txt: strlen 36849 chars 0.001ms mb_strlen 20418 chars 0.076ms old_mb_strlen 20418 chars 3003.042ms new_mb_strlen 20418 chars 0.133ms Testing tokyo.txt: strlen 36244 chars 0.001ms mb_strlen 19936 chars 0.071ms old_mb_strlen 19936 chars 2623.109ms new_mb_strlen 19936 chars 0.131ms Testing young.txt: strlen 36694 chars 0.001ms mb_strlen 16676 chars 0.063ms old_mb_strlen 16676 chars 2246.179ms new_mb_strlen 16676 chars 0.125ms
While whipping up a theme for the nascent Planet Wikimedia, I needed to use the standard font for Wikimedia logos, Gill Sans.
Gill Sans seems to come conveniently preinstalled on Macs, so I opened up my MacBook, symlinked the Mac fonts from /Library/Fonts to /usr/lib/x11/fonts/TTF, and whipped out Gimp… Unfortunately I ran into an old problem I’d forgotten about:
For some fonts, only the bold-italic version seems to come up in the font list. This time I decided to get to the bottom of it. Poking at the font files, I found that Gill Sans comes as a single .dfont
file instead of the more traditional bundle of .ttf
s. While Gimp/Freetype was happy to read the file, it appears to only pick up one of the style variants — in this case bold italic.
Some googling turned up this page which included a hint that you can extract .ttf files out of a .dfont using the utility fondu. Conveniently this is available as a fink package, so in a couple minutes I was able to replace the .dfont symlinks in /usr/lib/x11/fonts/TTF with separated .ttf files. Restart Gimp, and presto!
We’ve got some new machines in for the Wikimedia staff, and among them a shiny Core 2 Duo iMac has found its way to my desk as my in-office development workstation. Yum!
Doing web development, I need to have access to a number of operating systems for testing purposes: Linux servers, Windows clients, Windows servers, Linux clients, Mac clients, and the occasional other oddity.
In theory, at least, an Intel-based Mac should be the ideal environment to run this: test the Mac clients on the main OS, and everything else running in virtualization at full speed. The new Core 2 Duo boxes are further capable of running both i386 and x86_64 guest OSs, for full coverage.
With this in mind I’ve fiddled around for a while with the main desktop-level virtualization packages on the Mac to get a feel for what’s available… unfortunately the field isn’t very thick.
Basically there’s Parallels and the beta of VMware Fusion. There’s also some QEMU-based packages, but last I tried that was very unsatisfactory, both slow and unstable.
The good:
The bad:
Snapshotting is the ability to save the state of the virtual machine, run it further, then return to the saved state. You can use this to roll back installation of experimental software, for instance. *Very* useful when developing and testing software, for obvious reasons.
Since this has been part of VMware Workstation for some time, I had hoped to find it also in…
The good:
The bad:
That single snapshot limitation is *horrible* from my perspective; it’s totally arbitrary and wrecks much of the usefulness of it.
An example of one of my prime uses for snapshots on VMware Workstation was maintaining a single copy of Windows XP in both IE 6 and IE 7 states; I could switch back and forth between them at will, while still using the snapshotting for more local changes. That’s something I couldn’t do with only a single snapshot available — I’d have to install two separate copies, which would imply a second license. And then I’d still be stuck with only a single snapshot for all my debugging uses!
The quick fix
For now I’ve wiped the disk and installed Ubuntu Linux, so I can run VMware Workstation for Linux. I’ve got the full range of snapshotting features available, and can still use my laptop for Mac client testing and all the other happy shiny Mac OS X goodness.
Of course there were some installation issues… ;)
Hopefully Parallels will catch up or they’ll get proper snapshotting into Fusion and I can someday reinstall Tiger (or perhaps Leopard by then), but in the mean time it looks pretty rockin’ on my desk and VMware actually works!
1.6.9 for the stragglers, 1.8.3, and a 1.9.0rc2.
1.9.0 final in a day or so, after a few more chances for people to test last-minute regressions.