R: R: [AD] Allegro 5 new config routines, alpha 1

["Angelo Mottola" <a.mottola@xxxxxxxxxx>]

Ok, with all these arguments I'm starting to think having an unique
expandable table is a better solution. But I have a final doubt on this:
currently I've made that you can assign a read/write hook function to
each node, so for example you can assign an hook that updates internal
vars when accessing the directory "/keyboard/state/" (example directly
from Shawn's thoughts online, go reread the thing), so that you know the
current state of "/keyboard/state/AL_KEY_SPACE" for example, as to
access AL_KEY_SPACE the system first scans the /state/ dir, finds it has
an hook and calls it.
Having an unique table with each entry being a full path would make this
harder to manage. Unless hooks are stored into a separated table, with
which the entry is compared once it has been found. So the example above
would work this way: the user references "/keyboard/state/AL_KEY_SPACE";
look for the hash entry for this onto the table. Get the corresponding
entry and assure no collisions occur; now parse this into its parts
(subdirs and variable) and compare each part with the entries of the
hooks table (that for the purpose could be just a simple linked list).
When a part has an hook, call it. That's it.
This is what comes to my mind; if you have better solutions, let's talk
about them before I start coding alpha 2 :)

About a growable hash table, that's not yet implemented for ease, but
I'll make it growable in alpha 2. Having a growable hash table forces to
recalculate all the hash entries already set each time the table grows.
Currently my hash function works on 16bit values, and returns only the
lower bits to fit into 4096 entries; I can make it starting to return
the first 4 bits to lookover a 16 entries table, then I can keep track
on the number of entries set. If you set more than 16 entries, the table
is expanded to have 32 entries (1 more bit is taken from the hash
function result). As a result of this, all previous hash codes for
existing entries have to be recalculated, as with one more bit some
entries will belong to a different table position. So the system will
update the table on the growth, and will set the new threshold to 32
entries. When you'll set more than 32 entries the growing process will
start again, reallocating a new table of 64 entries, etc...

Now that I think of it, having an hooks list separated from the hash
table also saves much space, as each hash table entry will have 8 bytes
less to take care of. :)

Now your comments!

--
Angelo Mottola
a.mottola@xxxxxxxxxx
http://www.ecplusplus.com