Younès:

I am very interested in a "
clean set of
interaces(sp)". But be prepared, you will go
around the block many times with "throw aways".

As far as understanding the code, I can help.
First I suggest you read JudyGet.c and write
down every dumb question you can think of.

I am working on the next version of Judy. It
is still in a "skeleton" stage, with most
macro's removed and much of the complexity that
is not necessary removed too. I will send you
the source when I get your "stupid" questions.

What I mean by "skeleton" is a version that
is getting ready for the next major experiment
to improve performance.

To begin, you must understand what a "Trie" or
"digital tree" is. Ignore any binary versions
that are written up by some authors.

I suggest starting with a
base 10 sized nodes and try decoding decimal
numbers in the tree. It is really an easy
concept once you get the "hang of it". Judy is
a "virtual" digital tree with base 256 nodes
with the final node a "Leaf" of variable size
ranging from 31 to 256 elements (currently).
The term "virtual" comes from the fact that they
are logically 256 nodes wide, and exist
in 3 forms:
1) called a "linear branch",
2) called a "bitmap branch" and lastly
3) an "uncompressed branch" that really has 256
 nodes.
Linear and bitmap branches do not contain the
nodes that are empty. Each node can contain a
bounded "expanse" of possible numbers. I plan
on removing bitmap branches on the next version.

Once you think you understand the above concepts
I will help you "map" them into the JudyGet.c code.
JudyGet.c is the easiest way to understand the
data structures supporting Judy.

A digital tree has many properties that are not
intuitive, which is where the exciting parts of
Judy exist.

Doug Baskins


yjudy <yjudy@club-internet.fr> wrote:
Hi!

> On a different subject, you are not the only one to critique the
> API to Judy. The API was a result of many discussions and
> nobody was ever happy with it. So far I have not received a
> suggestion (with complete semantics) on a better way to do it.
> (Every challenge I have offered has been ignored).
>

I can help to make Judy code more portable, elegant with clean set of
interaces.
But for that, I need your help to understand the code.
Even I read "Alan" 3 hours Judy doc more than once, it remains very
hard to understand all the internals and dark magic behind it without
authors help.

> It has been on my wish-list for years to do a "thread-safe"
> version of Judy. That would require different semantics to the
> Judy API (you can't have pointers to the "Value" area outside
> a potential lock or modification of the array by some other
> thread.) Your help on this would be appreciated, especially
> for C++. None of the original Judy team used C++.
>

I wrote a lot of large programs in C (>150K LOC) and I never
need to use C++. Please, stick with C as there's a lot of interfaces
to Judy using the C API.


cheers
Younès



Doug Baskins <dougbaskins@yahoo.com>