Edd Dumbill's Weblog: 'mono' articles

New release of XmlIndexer search server

2006-11-24T15:37:33Z

About 18 months or so ago I released the first version of XmlIndexer, a general purpose XML indexing web service based on Mono and Lucene.Net.

I'm happy to announce now version 0.4 of this software which, thanks to improvements in Lucene.Net and patches from the Beagle hackers, is a lot more stable. Previous versions had some nasty locking issues that could kill the server quite dead.

XmlIndexer is a simple indexer. Given a rulefile that maps XPaths to Lucene keys, it can be taught to index any XML file you should care to give it. I use it to provide search functionality to legacy applications, which then need only to expose their data as XML and call a few simple web services to perform a search.

Of related interest is the new Apache Incubator Solr project, which provides a fancy search server based on Lucene, doing the same as my indexer, and much more.

XmlIndexer requires Lucene.Net version 1.9.1. For extra points, apply the locking patches from Beagle to Lucene.Net before building. As a courtesy I include a Lucene.Net DLL I made this way in the download.

Download: searchxml-0.4.tar.gz

Join the conversation about this post

New home for Monopod

2006-09-06T14:11:58Z

I'm pleased to report that Nickolay Shmyrev has taken over as the new maintainer of Monopod, my simple podcast client for the GNOME desktop.

Monopod now has a new home page, and a publicly available Subversion repository. My thanks to Nickolay for taking this on.

A new release is now available, which makes Monopod build with the latest ipod-sharp code. If you're in the market for a drop-dead simple podcast client, Monopod's still a great choice.

Join the conversation about this post

GObject subclassing in Ruby

2006-01-31T20:23:24Z

Thanks to everybody who wrote in with suggestions following on from my initial Ruby GNOME investigations yesterday.

After talking at cross purposes for some time in a bug report with a Ruby GNOME developer, I was pointed to a good example of how to do what I wanted: subclassing a GObject in Ruby.

This is something that the Mono Gtk# bindings do so well, I'd forgotten the required mechanics. Here's a simple subclass of button. I've highlighted the required magic in bold.

class MyButton < Gtk::Button
   attr_accessor :hitcount
   # tell the GLib object system this is a new type
   type_register
 
   def initialize(text)
     super("label" => text)
     self.hitcount = 0
   end
 
   # rather than overriding 'clicked', we must
   # override the signal_do_clicked method
   def signal_do_clicked(*args)
     self.hitcount+=1
     super
   end
 end

The type_register call registers the new class with the GLib type system (something the Mono bindings do for you automatically). The second key was knowing the name of the default signal handler, which turns out to be of the form signal_do_signalname.

So, to follow up yesterday, I hadn't found a bug, merely a gap in the documentation. Thanks to Masao Mutoh for taking the time to answer my questions.

For comparison, here's the same implementation in Gtk#. There are pros and cons of both languages. Ruby's succinct attr_accessor is balanced by the neat GObject-aware subclassing and the constructor inheritance of C#.

class MyButton : Button {
        private int hitcount;

        public MyButton (string text) : base (text)
        {
                hitcount = 0;
        }

        protected override void OnClicked ()
        {
                hitcount++;
                base.OnClicked ();
        }

        public int HitCount {
                get
                {
                        return hitcount;
                }
                set
                {
                        hitcount = value;
                }
        }
}

Join the conversation about this post