Free Food (for Cowboys)

Robert finally annouced his new position. Are you ready?

This is the best news I’ve heard in a while. It’s very nice to have F-Spot and the other mono apps gain new users and see the gnome desktop move a little closer to a shared vision. On a personal level it also feels good when you can convince yourself that your vote counts.

I’d like to share a snippet from a Christmas present I got this year.

Before long the chain broke; then the motorcycle ran out of gas. Ewing abandoned the bike, hopped a freight train, and fell in with two hoboes. The trio was discovered by a brakeman, who intended to rob Ewing of his money and watch. Ewing with persuasive-but true-story about being a poor college student, talked the man into returning the cash and timepiece.

The ordeal was no over, however. Eventually the hoboes attacked Ewing. Desipite being hit by a blackjack, he feigned insanity long enough to get away-but not without a chase. The attackers lost track of him as he hid in a churchyard.

The story is about my grandfather’s brother (my great uncle) and the book the book was given to me by my brother John. In an unrelated but not entirely unforeseeable turn of events I also gave John a book about hobos this Christmas. I guess we know each other pretty well.

F-Spot 0.1.5 was released on Monday. Get
it before it goes out of style.

sorry about the slightly delayed announcement.

Federico, it’s funny how unrelated threads of converge sometimes. The last couple of day’s I’ve working on trying to improve some behavior in F-Spot that is both processor and I/O intensive.

The Problem
There is a file loader in F-Spot that is used to load most images for display. It knows how to load some things progressively and others in a single pass. Sometimes for some files it would block for a long time while loading the image and this wasn’t acceptable. It is important that F-Spot is as responsive as possible to user input.

A Solution?
I started to work on the problem by converting a couple of problem loaders used blocked waiting for complete input into into incremental loaders that could operate asynchronously. This helped quite a bit, the loader would read some then process some and occationally return to the mainloop to process requests things were looking good.

Good except when it didn’t work. It turns out that in some cases the source stream was actually a pipe, and that pipe would often not have any data available for several seconds. So even though the loader was switching back and forth between reading, processing the image and yielding to the mainloop, if it ran into a one of those streams it would try to read from it and stop everything until something was written.

Async I/O to the rescue. After all it seems a like a good fit, we’ll start a read, get notification when it is done use that in the loader and be in good shape. Fortunately the .Net stream class has a nice built in interface for async I/O so the platform is even going to help me out. Now instead of calling stream.Read I call stream.BeginRead with a callback function that lets me know when the read has completed, then I add some support code to handle passing the read data back to the mainloop (the only place we can safely use it) and everything should work.

It should work, but it doesn’t. It turns out that for whatever reason (I honestly don’t know the details) System.IO.FileStream.BeginRead isn’t actually async in mono 1.x. It also blocks waiting for something to be written to the pipe. After some discussion with Gonzalo he schools/reminds that all c# delegates have asynchronous BeginInvoke/EndInvoke methods. So a quick wrapper later I have a stream that actually does async I/O, and everything mostly works.

Deadlock

So at this point the goal has been largely met, but at what cost? The complexity of doing everything incrementaly runs pretty deep and it turns out I haven’t actually avoided using threads (BeginInvoke uses a thread). I don’t think you can generalize this example to larger statement about when to use threads versus incremental apis and async I/O because it’s hard to draw general conclusions from a specific case. It is doubly hard when that case includes platform specific problems. If I’d been doing this all in C the problems and potential solutions would have been slightly different.

It does however, make two things clear to me: complicated things are complicated no matter how you slice them, and I’m not nearly as smart as I’d like to be.

As part of the work I’m doing to add raw file support to F-Spot I’m making a public request for sample raw files. Anyone who is interested in seeing their camera supported should send sample raw images to fspotraw@gmail.com. In this case the more obscure the camera the better as I already have sample images from many recent Canon and Nikon cameras. Since the long term goal is to have some of these included in a test suite please explicitly state any licensing and copyright restrictions that apply to your images.

In related news I’ve been in Boston all week working on F-Spot and doing some basic usability testing in Anna’s lab. The testing has been extremely interesting and I’m excited to do more when F-Spot is more mature. As part of getting ready for things I’ve added some features and ui tweaks to CVS that are still only partially complete. So if you are runing the latest and greatest use a little care and don’t expect everything to work.

I planned on sharing some thoughts about the intersection between Joe’s desire to upload photos Nat’s plans for social lubrication through software and F-Spot. Then I realized I could just think them and save on the typing.

So instead I bring you F-Spot 0.0.9. This is a very friendly release, please be gentle.

This is just a short announcement F-Spot 0.0.8. This is the first F-Spot release to include support for importing photos directly from the camera via libgphoto2 and I’d love to get as much testing as possible. Please try give it a try.

Sunday was my brother Brad’s birthday and Tuesday was Kristy’s birthday. My family usually has one big meal with everyone to celebrate both, so Monday night we all went out downtown. We had a very nice time at dinner and stayed out later for drinks until Brad mentioned he wasn’t feeling very well and we all parted ways. By Wednesday night it was clear that I was sick with something and a few calls revealed that almost everyone who had been at the birthday dinner had also come down with the flu. Thanks Brad.

Brad looking happy at a different party

Fortunately I managed to make an appointment with my doctor and got some Tamiflu hoping it might help. Happily by the next day I was feeling noticeably better. Still very sick but uncomfortable sleepy sick instead of completely miserable sick. I’m willing to credit the Tamiflu for the relatively mild symptoms. I hope by tomorrow I’ll be back to full strength.

F-Spot work is still progressing nicely considering the circumstances. Last week I made a 0.0.7 release that pointed out that I need to be more careful about which version of gtk# I test releases with. The current freeze policy for the stable gtk# branch is slightly less than frozen. and in fact because of back ported fixes things are now even more fluid. Since I really don’t want to force anyone to use the stable branch directly from SVN (even though it is much better) from now on I’ll double check that I’m not using some as yet unreleased entry point. Mike has promised a new release soon.

On the positive side of API additions Ben has taken the time to add most of the methods in System.Drawing.Rectangle to Gdk.Rectangle and promised to add overloads to a bunch of the drawing functions. While the changes are small they’ll make a lot of f-spot widget drawing code prettier to look at, and that isn’t a bad thing.

$100 portable computers make me dream of a Young Lady’s Illustrated Primer.