WeSay Development Progress

Since it’s been awhile since we’ve blogged, I figured I’d give a little status report. We just finished getting the dashboard task to be functional. The dashboard displays the current task as well as a list of available tasks that the user can select. It also provides a short description of each task and some status if applicable.  There are some tasks (dashboard and dictionary by default) which are “pinned” and will always be visible as tabs along the top. The last tab represents the current work task. The current work task is now selected from the dashboard. If the user wants to change the task they are working on, they can do so from the dashboard. John has created the admin application which allows the administrator to do stuff like choose which tasks will be available to the user, configure writing systems, and import and export from LIFT (xml) format. We’ve also put a bunch of work into speeding up the time that it takes to move between tasks. John has adding and deleting records working in the master dictionary task. This week, we’re planning to add a word collecting task which uses a wordlist from another language to help the user think of corresponding words in their language. John is working on getting the application to keep an ongoing, incremental backup of the user’s work in LIFT.

Thanks to Cathy, we now have a revamped skin on our wiki. We also have acquired wesay.org so update your bookmarks.

I have been working on two areas of WeSay. The first is our data access layer. Db4o provides a read only IList when queried. In the prototype, I had wrapped that result and provided our own read-write IList that automatically kept the database up to date. With John’s databinding work, we decided to provide a IBindingList interface over db4o. I spent quite a bit of work creating tests for the various interfaces: IBindingList tests, IList tests, ICollection tests, IEnumerable tests. I had an implementation working with tests when we hit performance issues with filters and John found Marek Istvanek’s work on providing a binding list over db4o. I chose to only use his db4oList class and implemented my own Db4oBindingList since we won’t be needing the paging and didn’t want to take on the associated risk. I had to modify the Db4oList class so that it would pass my previous tests.

Another big change to the Db4oList class had to do with unregistering the PropertyChanged event on classes which implement INotifyPropertyChanged. A number of people have blogged about the “lapsed listener” problem which causes objects to remain in memory due to the event source retaining a reference to the listener after the listeners go out of scope.

The solution to this tricky issue is to either use weak delegates or require a call to dispose before the listener goes out of scope. Wesner Moise claims that implementing weak delegates is a difficult proposition with a number of casualties (Joe Duffy and Ian Griffiths) to date. I found three implementations that still purport to be correct: Greg Schechter (he also provides the best overview of the problem space), Xavier Musy, and John Stewien. We finally decided the best way to handle this was to remove the listener from the event source when dispose is called.

The other area is in moving our proof of concept lazy GTK nodestore to production standards. In the process I came across this blog entitled DataBinding an IList as DataSource for the Gtk.TreeView. This obviously peeked my interest. At first, I adapted his code to use an IList but when I tried to load the assembly, I discovered that templated classes cannot contain references to external methods, which makes sense so I’m back to using an IList. This is still a work in progress for me too, but you can check out what I’ve done in our subversion repository.

After two discouraging days of trying to get Mono to work on the OLPC image, I have finally figured out why I was up against such a brick wall. The first problem I had was that the Mono installer for linux only provides bindings for GTK+2.4 and we have been using GTK+2.8. After unsuccessfully trying to use a machine.config file to tell mono that it can use GTK+2.4 in place of 2.8 (which I don’t know that it would have worked but I couldn’t get it to recognize that even), I finally decided to just copy over the 2.8 bindings from my ubuntu install.

Now I thought it would be easy from that but after awhile of getting all that hooked up, I determined that the gtk version on the OLPC must not be old enough and I copied over the ubuntu libs, only to find when I was going to copy them that the OLPC distribution is using GTK+2.10.

Apparently Fedora has a version of Mono that will work with GTK+2.10, so I have now decided I’m either going to have to build my own image Mono as a part of it or wait until Mono supports GTK+2.10.
On a whim, I took up Daniel Olivera’s offer to access his OLPC motherboard and ran some performance benchmarks to see how this compares to our test machine. The benchmarks seem to indicate that our test machine is about 75% as fast as the OLPC. You can read more details about it here. This puts my previous blog about the performance of WeSay on our test machine into better perspective.

Further testing on the memory usage seems to indicate the WeSay+Mono footprint on Linux is not 49MB as we previously thought but 19MB which is more like what we had found on Windows as well.