Older blog entries for dajobe (starting at number 6)

Raptor

At last, got another release of raptor out the door after about 5 months and lots of changes (new RDF datatyping, collections, URI updates, internal improvements, bug fixes). It took a while till it had the features I wanted to add, the changes I wanted to make internally and after all that, to make it stable and working.

Releasing software is such a pain, especially in the free software / open source world. Since in particular, it is your reputation that is being demonstrated - "show me the code!" - and the source code you make available to the world is what counts.

Of course, talking about reputation on advogato is just asking for trouble. :)

Raptor

A short update on various code refactorings of my raptor RDF parser over the last month or so. I have been pulling apart an 140K C source file into chunks by functionality. This was needed for a bunch of reasons, mostly because it had been evolved rather than designed, and was getting embarassing to look at.

The result is that the API is smaller and more flexible and I can soon pull out the redland URI dependencies, so that the same raptor library can be used standalone in applications while working efficiently in redland.

Apart from moving the same code around I also got time to improve the XML error handling so that it can deal with XML it doesn't understand, so it now handles all the libxml XML tests without falling over. And killing a bunch of other bugs. The bug list is actually getting shorter.

Redland

A few weeks since last hacking update on my redland RDF library. I long wanted the (C) library to be able to return error messages and so on to the higher language interfaces (perl, python, java, tcl, ruby, ...). In this case, I've got my head around the C interfaces to callbacks for perl and python so that now any errors result in native perl and python subroutines / functions / exceptions working. This means that the CGI demo programs that used to just chuck errors to stderr can return them to the web interface.

Raptor

Most recently I've mostly been banging on my raptor RDF parser and writing test cases to find the bugs that have been known about but not diagnosed. I also took the opportunity to try to split out some code from the very large main source file. Tricky doing this from evolved code.

C99

I've been reading Linux kernel changes related to updating for C99 Designated Initializers (also called named struct initialisers). Does anyone know why these are a good idea and why you'd want to change / break your code to support these?

They work like this. A struct with two fields:

struct type_foo bar = {
  val1, 
  val2
};

is now (or can now be) written as

struct type_foo bar = {
  .field1 = val1,
  .field2 = val2
};

and I was just getting used to ignoring K&R C support ;)

I've mostly been working on the redland iterator changes needed for contexts that edd wanted. The current state is 'make check' works fine, except for memory leak, which I'm still hunting. I tried valgrind, but it gave false info which took yet more time to work that out.

After I get this fixed this, I'll have to consider changing streams to match this new model, however I'm a little worried since it may cause too much user-level change. Iterators are pretty internal and hardly leak out for non-C.

The changes for streams, like iterators are as follows: The two methods on stream are presently: is_end and get_next. is_end will remain the same, but get_next splits into get and next. It may be possible to hide this outside C. The general change is from:

while !stream.is_end { s=stream.get_next;blah blah }

to:

while !stream.is_end { s=stream.get; blah blah; stream.next() }

where the 's' is a shared pointer in C but could be a copy outside. After stream.next() the pointer moves and isn't valid.

(actually this makes things more efficent, there is less copying inside redland and things should work faster)

Last night a bit of success with redland preparing to add contexts. I took the previously static configuration of the hash indexing and made it work dynamically - the code was ready for this - although use the same configuration as the old static one. The next step is to allow users to pass in what indexes they want. I have to work out a good method of passing in appropriate paramters.

Hack hack hack on redland. Isn't libtool such a pain? And on OSX especially. Seems that tool needs a new release, it's been at 1.4.2.hidden versions for along time. At least the Debian version has the patches from CVS to fix some of the worst things.

Now don't get me started on the automake 1.4, 1.5, 1.6 mess