A lot has happened this week, in particular:
For those in the Cambridge/Boston area, we now give you a word from our sponsor:
It's been ages since the last release of Alleyoop, but an update has finally arrived. I've just fixed up Alleyoop to build on openSUSE 11.1 (some libbfd stuff has changed, apparently) and so I've dropped the need for libbfd and libiberty completely. The code that used those libraries didn't really gain us any extra information that Valgrind wasn't already giving us anyway, so it as rather pointless.
It looks like a year and a half or so ago I fixed some parser bugs too and just never made a new release with those fixes.
So now Freedom Lovers who prefer a GUI can once again Valgrind their applications 'til their heart is content.
You can download the new Alleyoop 0.9.4 package here.
Oh, also, if there are any bored web developers out there, I'd appreciate it if someone could make a less-ugly website than what is currently at http://alleyoop.sourceforge.net. In case you couldn't tell, I'm horrible at website design.
As another fabulous example of my webdesign prowess, take a gander at GMime's website. So yea, that site could also use a make-over.
Update: Thanks to Akos Kemives for his improved website design for Alleyoop!
A lot of cool stuff happened this past week:
Found out about Larry's, Aaron's, Rusty's, and Geoff's work at making a Moonlight 1.0 release that could view the Obama Inauguration this morning, so I absolutely had to use Moonlight today to watch it and it was great. Flawless.
Way to go guys!
Once again proving that the Mono team is unstoppable!
GO MONO! GO!
This past week I've been furiously hacking away on my reimplementation of the Silverlight TextBox control for Moonlight. I never realized just how much work goes into writing such a simple text-entry widget before this past week, even after having written Moonlight's text layout and rendering engine for the 1.0 release.
Keyboard input, keyboard navigation, keyboard selection, mouse selection & cursor positioning, key repeat, cursor blink, etc. The list goes on.
Most of it isn't hard, it's just time consuming.
At the same time, it's also fun in the sense that it's a new challenge for me to overcome (I love a good challenge). It makes you think a lot about designing for performance because you just don't know how much text you'll be rendering. It could be a short sentence or it could be an entire document, and the way you design your layout/rendering engine could mean the difference between taking 5 minutes to render or a fraction of a second.
For months now, my GNU/Emacs has decided to sometimes not syntax highlight my source or ChangeLog files and I didn't know why.
The other day, emacs' failure to syntax highlight xaml.cpp was the final straw. I decided enough was enough with having to M-x font-lock-fontify-buffer everytime I opened a handful of source files, especially ones that I often find need to edit and/or to refer to.
A little digging later and I discovered that GNU/Emacs must have added a feature that disabled font-lock (even if you've specified (setq font-lock-support-mode t) in your ~/.emacs) if the buffer was over some arbitrary size. Either that, or they lowered the arbitrary size to something ridiculously small.
The solution seems to be to add the following line to your ~/.emacs file: (setq font-lock-maximum-size 1000000)
Feel free to append a few more 0's to that number if you find that Emacs still fails to syntax highlight any of your source files.
Update: Another Emacs annoyance can be turned off by adding (setq inhibit-startup-message t) to your ~/.emacs file. I'm not sure why this isn't inhibited by default.
Just got around to installing Seadragon on my iPhone and took it for a quick spin. First impressions are that it rocks. If I load the map views, for example, zooming seems far far smoother than Google Maps. Zooming in on the articles in the Library of Congress Set was amazingly smooth as well.
