Hello!

This is the README file for
	glib-jmayer-000212-0.patch.gz

This patch adds a new glib datatype: GIntSpan.

GIntSpan represents a sparse set of integers.  Integers can be
added to the set, removed from the set, and tested for membership
in the set.  Additionally, a pair of handy functions are provided
to serialize/deserialze the GIntSpan object into the same format
used by, for example, .newsrc.

I've found this class to be useful for tracking and re-using unique
resource IDs for an object database system here at Cobalt.  There's
a somewhat obscure interface in the API called "g_intspan_get_any_avail"
that attempts to return the next available "unset" integer in an
efficient manner.

This patch updates glib.h, adds the "gintspan.c" source file, and
includes a thorough regression test for GIntSpan in the tests
directory.

I didn't get around to updating the documentation files.  .info and .tex
frighten me.  If somebody could tell me exactly what files I should
update, or point me to some useful instructional URLs, I'll get around
to writing the documentation soon.

A possible FIXME note: GIntSpan has one inconsistency -- the "0" value
is treated as the failure code, and can't be used in a set.  This is
a side-effect of storing my integers as gpointers inside the GTree.
(The lookup function doesn't distinguish between "I found a key equal
to zero" and "I found nothing.").  I can fix this if you really, really
want me to, but there will be a performance penalty.  My preference is
to leave it alone (and document it).

Have I mentioned how absolutely brilliant I think GLIB is?  As a C++/Perl
programmer forced by cruel coworkers into hacking C, GLIB makes C
programming fun again.  I just want to give something back.

"Oh, I'm sorry Mr. Manager, but I just _had_ to put my code changes into
this glib.h file, and as you can see this file is LGPL'ed, so I'm
_forced_ to release my code under the LGPL.  Ooh, the open source
community, they're twisting my arm, ouch ouch ouch."

I hope you find this code interesting,
Jonathan Mayer <jmayer@cobalt.com>

PS. I'm also starting to write serialization/unserialization code for a
number of the GLib datatypes (strings, basic types, lists, hashes, etc.).
Please let me know if anybody else has undertaken this effort yet so
we can combine forces, etc.etc.etc.