Older blog entries for badger (starting at number 20)

All this Gnome 3 talk reminded me of Heinlein's The Door into Summer. One of the sub-themes of the novel is that engineering is all about prior art. You can't build railroads until you have steam engines. You can't build robots without computers.

Taking this from a programmer's perspective, the free software movement is all about creating a body of prior art that enables us to create our own versions of railroads. We don't have libgnome so we can say, "look at libgnome, isn't it great?" We have libgnome so we can build evince, metacity, evolution, and abiword. And we know that if any of those apps ever falters and stops being maintained by their present authors/companies someone else can pick up the code and use it as a basis for improving and creating new work.

So breaking Gnome-2 API/ABI in order to clean things up and make them more intuitive for a programmer has to look at this cost/benefit: We have a certain level of prior art in Gnome-2. It may be clunky in places but it works. According to gnotime, I've spent about 260 hours plunking away on QA Assistant. That's about 32 work days in which I've gone from basic python and Gnome-1.0 knowledge to a small but workable Gnome-2 application. Will a more intuitively designed Gnome shave a day off that ? Cut it in half?

Because here's where we find the collision of ideas of the relative importance of platform vs applications: there's a lot of stuff built on the prior art represented by the Gnome-2 platform. To make transitioning to Gnome-3 worthwhile there has to be some widespread, "there ain't no way to solve this in Gnome-2" problems that, when solved in Gnome-3 will make both innovation and implementation of new ideas faster and easier. If that happens, then we end up with more, higher quality applications. If it's just tinkering with things here and there to make the ride smoother for the new programmer but don't significantly reduce the time spend implementing his ideas, we've taken a step back from our overall goal even if the underlying architecture is better.

Funeral

Back from my grandmother's funeral in Pennsylvannia. Feeling kinda strange. Coudersport was a place my family would go every summer and hear tales of what it was like for my father to grow up as the only Japanese (heck, only Asian) family in town. It became a mythic ancestral seat. Only one generation of heritage yet very important to my identity. Even though I was born and raised in California, Coudersport was still the place that I was from.

At the funeral I saw most of my father's family. And I realized that of the five sets of uncles and aunts and the nine cousins and their new families only two are still living in Coudersport.

Metaphor: In the desert there was a city built by an ancient people. They came, they built, their city stood tall and strong. But the people longed to see more than just the city they had built. One by one they left. The wind blew. Sand filled their homes, blasted their names from their monuments, left a long rolling dune....

There's no reason to go back.

So where is home?

The more I use Python, the more impressed I am by it's clear, concise power. Properties were pretty simple to implement in QA Assistant thanks to Python's inheritance features. I was able to base my class on the standard Python dictionary type so much of the needed functionality was already provided for me. It was also easy to override the dictionary class's __setitem__ method (which give you the indexing syntax ex: myproperty['ticketNum'] = 1234) to provide the class with just the barest bit of non-dictionary behavior I was looking for.

I have lots of friends who tell me Java is the best language around because of its extreme object orientedness. None of them have touched Python, Ruby, or another really high level language, though. When one of them does and explains what makes Java special in comparison I'll consider taking a look at it.

Interesting... Using gnome-blog for a livejournal blog as well as my advogato blog. Looks like the previous entry to LiveJournal ended up here on advogato. Let's check this out and see if it's a bug or user error :-)

Yep. Definitely a gnome-blog bug. Well, I was going to try a different client for LiveJournal anyhow... guess I'll set that up tonight as I hunt through the gnome bugzilla.

Spent the day thinking of how Properties and Functions should work in QA Assistant. I've got a workable plan now. There's going to be a Properties class that gets read in from the checklist. This class will inherit from dict and add a few specific methods. One to aid in extracting the data as a set when needed (For example, so dependencies are apparent when output to the Properties Widget) A second to check for automatic Functions to invoke when updating the value of a Property.

A Properties gtk.Widget will exist for setting these entries. I'm hoping to only have display information in there. The Properties class will figure out how to order the entries (according to dependencies, optional/required/etc) and actually manipulate the values. When a property is changed that allows another property to be automatically set, the Properties object will invoke a special Function method on the function name. The PropertiesWidget will only give a user interface to change the values of the data.

Functions will be referenced from the checklist. But the code will be loaded from a python file. Not exactly sure how I'm going to interface the xml and the python file but I'm leaning towards keeping a hash of the python file within the xml and referencing where each function is used (so menus, tests, and propset functions would each have enough information to perform the function call later but the code itself would reside in the external file.)

The external python file will have a class that subclasses a generic Function class that QA Assistant will provide. This generic class will know how to organize the various types of functions (propset, menu, and tests so far) provided by the checklist specific python file and have a function to enable invoking functions via stringified function name.It may also make sense to keep a reference to the Preferences here since we're going to be using it as input to our python functions and for some of the functions, using them as our output as well.

I'm leaning towards having specific display widget classes to diplay the FunctionMenu and provide toolbar buttons, as opposed to including the display code in the Function class but time will tell if breaking the code up at that level is beneficial.

You look out the windows of the bus. The slowly moving traffic. The snow covered streets. Slushy, salty snow on the roads, Cold frozen snow on the sidewalks.

The light changes. You lurch as the bus moves away from the curb. You hear a squeal as the blower starts to circulate warmed air. You feel the winter sun shining through the window.

The cold winter sun. Shrunken in the powdery sky. The sun shines weakly here. So cold. It shines so weakly. So cold. How did you feel it through the window?

The light changed. You lurched when the bus moved. You felt the heat of the blower. You felt heat through the window. What did you feel? You felt the bus lurch.

You can taste the snow. Salty. So cold it's warm. It stings your face. You remember the bus lurching away from the curb. The sound of the blower suddenly loud in your ear. Wet snow suddenly plastered to your cheek. Sharp and stinging. Gritty. Salty.

How did you get outside the bus?

The snow is warm on your cheek. Cold on your cheek. You remember the lurch of the bus coming away from the curb. The cry of the blower. A squeal.

I'm leaving Vermont! Sometime this summer. For where? I'm not sure. But it's going to happen. We've been in two auto accidents in one week and I'm not going to spend another winter having to drive on glare ice and know the odds are good that you'll either hit something or be hit by someone. Not only does it cause undue financial harm, it also eats into my hacking time. What programmer doesn't have enough problems allocating time to all theirr free software projects withour having to add filling out insurance forms to the pile?

If anyone knows of a free software job outside of Vermont, I'm in the market!

Despite the influx of paperwork, I have managed to do some useful work this week. Got a stable version of my sylpheed patch for gpgme-1.0 out. I've still got to implement some enhancements that take advantage of the new gpgme-1.0 features but things are looking pretty good. The gpg signing works better for me than with vanilla sylpheed.

The development branch of QA Assistant has progressed enough that I released a new devel release today. GConf Preferences, a Druid, and other goodies are now working. Properties and automated testing remains to be implemented. Figuring out just how I'm going to mixin the extra menu entries I've been defining in the checklist xml files is also on the list. The data for these are all in the XML file but the code to handle it is in its formative stages. I have to apply the Feynman "Think real hard; write down the answer" Algorithm to this one first.

Managed to update my desktop from FC2 with devfs and lvm1 to FC3 with udev and lvm2 with no mishaps. That was a bit of a miracle. Especially because it doesn't have a working floppy or bootable CDROM. The one other time I'd tried that I ended up spending an extra couple days booting old kernels in single user in order to resuscitate my box. This time, I took some extra steps to make sure I had a /dev directory that could boot without devfs or udev and all was well. The computer is chugging along quite happily now (well, aside from the fact that it can't take more than 64MB of memory.)

Someone at work pointed me to Apple's website today to see the new Apple Mini. If I had more money, I'd look into buying one to dual boot Tiger when it's out and FC3-ppc. The thing is cute! (Not necessarily the most important thing to look for in a new computer to be sure, but this isn't just a computer... it's an accessory!)

Python docutils
===============

The docutils_ project has really impressed me. It implements a minimal markup language called reStructuredText_ along with commandline tools and a python library to transform reStructuredText_ files into html, latex, and other formats. The eventual goal is to allow marked up inline Python Documentation like javadoc and doxygen. This is not finished yet but standalone use of reStructuredText_ for documentation is already quite potent.

The beauty of reStructuredText_ is twofold: It's quick to write and non-intrusive when viewed as plain text. This puts it head and shoulders above XML/HTML for simple documentation. I'm migrating all the docs for `QA Assistant`_ as the minimal syntax allows me to quickly jot down my notes in vim while knowing it'll transform into html for the website if I so choose. This Advogato entry is also written in reStructuredText_ so you can see what a typical plain-text representation looks like.

For those interested in running docutils on a Fedora_ system, I have some packages in the `Fedora.us QA queue`_.

.. _docutils: http://docutils.sf.net
.. _reStructuredText: http://docutils.sf.net/rst.html
.. _QA Assistant: http://qa-assistant.sf.net
.. _Fedora: http://fedora.redhat.com
.. _Fedora.us QA queue: https://bugzilla.fedora.us/show_bug.cgi?id=2081

Couple of weeks of slow but steady progress on various programming projects. Also tried out synaptic for the first time. There's a few fancy features that I miss from the rug/red-carpet combo but not as many as I expected. Great job being done on both apt and synaptic.

QA Assistant

The minor news is qa-assistant is now in fedora.us's testing repository. Hopefully it's more accessible to newcomers there. Although I don't have a good feel of whether we're contnuing to pull new users into QA'ing for fedora.us or not. Gotta stop programming for a while and do some more QA work.

Big news is I've started work on 0.5. Mainly a code cleanup but I'm hoping to start implementing tests as discussed with Erik LaBianca and do an overhaul of the Review Widget's display as well. The cleanup is centered on how the checklist data and the two views (The checklist style and the review style) of the data interact so it seems the appropriate time to make the Review widget display better.

Gnotime

My patches have made it into gnotime. Lots of bugfixes I won't have to maintain any more. There's still a problem with building with the included libqof in that version mismatches with a system installed qof can wreak havoc. I've got a fixup for that but it needs some testing. (The RPM packages always use the system library so it never tests this route.)

Well, gnotime is compiling and advogato is up so it's time to write a brief update.

GnoTime

I recently packaged up GnoTime 2.2.1 and libqof for Fedora Extras. There were quite a few patches for that as GnoTime is shipped with an integrated qof that I had to move out. Works well now. Currently finishing a fix to the help system that Boris Goldowski pointed out. Soon as that compiles I'll upload the new packages for fedora.us quality assurance. (libqof QA is being done here.)

QA Assistant

Version 0.4 of QA Assistant is out now. Sourcecode is on sourceforge. I posted it to freshmeat as well and that's generated some traffic, which is nice to see. 0.4 has all the essential features of a Quality Assurance checklist for fedora.us. Load/save, nice reviews, custom review items, etc. There's still a lot of work to be done on two fronts:

One part is making it more generic. The current code has a few places that assume we're going to be QA'ing an SRPM package instead of being able to handle other checklist types. What would really help here would be for someone to tell me they have a checklist they'd like to see implemented. I only have the fedora.us checklist to test against right now, so there's no driving need to clean up that piece of the code. (Other than my need to do it right.) If anyone has a checklist they'd like to see implemented, drop me a line!

The other section is building more automated testing into the checklists. For the fedora.us checklist, at least, there's the opportunity for the computer to do some things to verify the checklist items. It does raise questions, though. This code probably needs to reside with the checklist to make it modular. But then we'll be running code in our app that can be in datafiles rather than program files. Do we automatically trust these files or should we be more careful? Do we write them in python only so they can be run in-process or do we allow them to be any language and then invoke them externally? Have to hack something up to experiment with and then rewrite it when I know more.

The 0.4 release is also a stable, bug fix branch. 0.5 will rewrite much of the core to make it more extensible and overcome some design limitations I found with my present code. In particular, I went a little overboard with my checklist, savefile, and properties objects. I think things would be better visualized as one checklist object with the other aspects being methods and properties of it. Tune in to my subversion tree if you want to see what I'm doing there.

Libungif/Giflib

Well, libungif and giflib are now at version 4.1.3 thanks to a few more bug fixes. Both libraries are now on sourceforge under the Libungif project page. I am not that excited about them since I have become an avid Python programmer. But I do need to do something with them. They need an API redesign to make them better suited for use in the modern world. Not sure if I'm qualified to do that, though. If anyone's interested in helping shoulder that burden, I'd be happy to hear from you.

Ahh... looks like gnotime's finally finished compiling so it's off to test, submit patches, and clean up in time for dinner!