Archive for the ‘Beagle’ Category

Planet Beagle

Wednesday, April 13th, 2005

I’ve noticed that I’m now aggregated onto Planet Beagle. I have no idea who maintains this, but thanks! As a result of this, I’ve started writing more about my beagle work, see yesterdays and todays posts on the configuration system I’m working on. Comments welcome. I’ll hopefully post a basic and working implementation before the end of the week.

I finally recieved my exam timetable today. It’s mostly good news because it means that attending GUADEC is possible, even if I do have to take risks with a Java exam before I fly out, and fly back a day early in order to catch my maths exam. Also looks like I’ll get to meet Stefan while out there. If any other Gentoo’ers are thinking of attending, please let me know!

Why even use a schema at all?

Wednesday, April 13th, 2005

Most of yesterdays post was based around generating and installing a GConf schema.

After further thought, why even use a schema at all? We don’t really want to be relying on external tools such as gconftool-2 to install the default keys on a per-user basis, and gconfsharp-schemagen is too basic for our needs.

So the new plan is just to write a Beagle.Util.Conf class which makes reading and manipulating settings easy to the rest of the code, leaving a possible window of opportunity for some automation to create this at compile-time in the future.

As for installing default setting keys, this seems easy enough even without a schema. Monodoc contains this code snippet:

MyVal = (string) gconfClient.Get ("/apps/monoapps/SampleApp/setting1"));
catch (GConf.NoSuchKeyException)
gconfClient.Set ("/apps/monoapps/SampleApp/setting1", "sample");

…which pretty much tells me all I need to know.

Early work on GConf-based Beagle config system

Tuesday, April 12th, 2005

I’ve been continuing work on making a configuration system for Beagle. We’ve decided to go for a GConf-based system if things can work out. This is a learning experience for me as I’ve never dealt with GConf before.

A few notes on the design, which was mostly spurred from the XML-based system I drafted previously.

  • A new class, Beagle.Util.Conf, handles the configuration. Currently only reading, but eventually will also handle writing and live notification of updates.
  • We have a schema file, which contains the schemas for the keys we use. Our keys are kept under /apps/beagle
  • We use gconfsharp-schemagen to generate a couple of new classes, Beagle.Util.Settings and Beagle.Util.SettingKeys.
  • We use gconftool-2 to install the schema and default keys

Before I go much further, there’s a few issues that need to be addressed.

  1. gconftool-2 –makefile-install-rule seems to overwrite any previous settings. This would mean users losing their settings on every upgrade/recompile?
  2. I can’t find much documentation, but the purpose of gconfsharp-schemagen seems to aim at creating convenient access classes to the GConf settings. This is pretty much the same as the aim behind Beagle.Util.Conf – do we really need to duplicate?

To elaborate on point 2, the classes autogenerated by gconfsharp-schemagen are quite basic. Ideally we need to be aware of things like threading, e.g. using the code already written for Beagle.Daemon.GConfThreadHelper. It would also need to be extended for things such as the command line configuration tool, beagle-config.

Where to go from here? We could either ditch the gconfsharp-schemagen thing and rely on always hardcoding the schema paths and accessors into the hand-crafted Beagle.Util.Conf class, or we could write our own autogeneration tool to produce something like Beagle.Util.Conf from the schema file, with the detail and functionality that we need…

This almost of boils down to one important implementation detail: If we were to hand-craft Beagle.Util.Conf (maybe using gconfsharp-schemagen as a base) then it would be quite possible in the future to change our storage method to something else, simply by modifying the Beagle.Util.Conf methods. On the other hand, if we go for a purely automated way using automatic class generation from the schemas and other metadata, then it most likely means hardcoding GConf specifics into the areas of beagle which are to use these configuration values, making future changes to another system more difficult…

Beagle in the news

Thursday, March 24th, 2005

It seems that Beagle is kicking up some attention at Novell’s BrainShare conference, articles on theinquirer, yahoo, yahoo, and computerworld, while largely the result of the media speculation, give some good PR to the project :)

This timed well with the release of Beagle 0.0.8 – the result of a few weeks of rapid bugfixing. This is by far the most usable release that I’ve been involved in, and is being shipped as a “preview” in Novell’s next desktop release.

If the stability remains, I’ll work on getting Beagle into Portage soon. There are some prerequisites to be completed first but progress is being made.

Linux 2.6.11

Thursday, March 3rd, 2005

Linux 2.6.11 was released today. Seems like another high quality release incremental from the last one. Many people seem interested in “whats new in this release” and I rarely see any short summaries, so here’s mine:
(I’ve probably missed some important things, this is just what I have observed)

  • Support for SysKonnect Gigabit Ethernet
  • Lots more SATA device support
  • Support for more Promise ATA controllers
  • libata (the SATA driver set) now supports ATAPI (CD/DVD) devices out-of-the-box
  • Support for various components of Intel’s new ICH7 chipset
  • Big direct rendering rework (splitting core from personality)
  • Updated Usermode Linux support – hopefully no more external patches necessary
  • 4 level page tables – memory management improvements
  • Optimization for pipes
  • Kernel userspace events (kevent) – something I need to investigate more, but it allows the kernel to communicate with userspace better
  • Many other fixes, new features, and enhancements (full changelog). If you are having any trouble with your current kernel or have hardware which is unsupported, you should definately upgrade before filing bugs

gentoo-dev-sources-2.6.11 is in portage and any early testing would be appreciated. We are considering using this kernel to power our 2005.0 LiveCD’s, and assuming there are no major bugs early on, our only showstopper is Speakup – it seems that the large amount of changes since 2.6.10 have stopped this patch from applying, compiling, or functionally working. Fortunately one of the main developers, Kirk Reiser, is very responsive and is already on the case :)

Speaking of software releases, Beagle 0.0.7 came out yesterday. As you can see in the release announcement, I’ve been fairly successful at learning C#/Mono and contributing to the software. The core developers have been very helpful and have even granted me access to commit to the GNOME CVS repository, where the beagle sources are managed!
I have more Beagle contributions planned but uni and other work is eating all of my time right now :(

And a quick update on the Planet Gentoo situation. Ramereth says he is almost ready to set it up on the Gentoo infrastructure, hopefully we will get most of the way there tomorrow. Thanks Lance!

First impressions of Mono/C#

Saturday, February 19th, 2005

For a taste of something new I’ve recently been learning about Mono, an open source development platform which currently implements C# and a large part of .NET.

My first impressions of the language is that it’s a nice mix of the features of C, C++, and Java, with a decent standard library. Turns out that being forcefed Java at uni might actually be semi-useful here, as there are many close similarities with C#.
As well as having a lot in common with “older” languages, Mono/C# brings some new things such as properties (convenient accessor/mutator methods), and the entire environment is object oriented. There’s also a nice central documentation browser (monodoc) which is easily searchable and well structured, and even has collaboration features where you can edit the content and submit your changes for inclusion in later Mono releases. Best of all its open source and benefits greatly from the community surrounding such things. For such a young project, I’d say Mono has matured very quickly.

monodoc - The Mono documentation browser

My only complaints so far is that quite a bit of documentation is missing, and the memory footprint gets a bit out of hand (although this is greatly improved in the development releases).

Mono is being used to develop quite a few exciting desktop applications, such as Beagle, F-spot, Tomboy and Muine. Interestingly, Novell seem to be a major player behind Mono and software based upon it, and they seem to be very friendly and approachable about development of their projects. More on them some other time, I’ve got some beagle bugs I’d like to solve :)