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 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.