On 31/08/2012, at 11:09 AM, Doug Baskins wrote:
> I am very disappointed every time I hear of someone
> not using Judy because of a fear of "compromising" any code that links with
> Judy.
> This is simply not the intention of the LGPL license -- in my opinion. I
> also feel that
> if someone contributes/enhances Judy, then they should make those changes
> public and
> available to the whole programming community. I am also a critic of
> intellectual property.
I agree that's the intent of LGPL. The problem for tool makers like myself is
that
we're developing code for developers. So whereas I would certainly publish
any changes to Judy .. my clients may not wish to do so, and they're developers
too. In particular I would like to encourage commercial use of my product,
whether it is open source under any licence or closed source.
Judy is bundled with my product to make it easier for developers to build
my product: we have a universal build script that works on all platforms,
including Windows. Judy isn't the only third party library in the package.
Minimising dependencies and build problems is vital.
Oh well. My product depends on Judy. There are no possible
replacements. Nothing else can do what Judy does with similar
performance. Judy is the core of the garbage collector. It can identify
not only whether a pointer points at storage allocated by the
collector, but do so even if the pointer is interior to the object.
This cannot be done with a hash table. The algorithm is trivial:
look for the next lower or equal pointer in a JudySLArray
and retrieve the next lower object's pointer (the key)
and the length of the object (the data). The pointer is in that
block if
key <= p < key + length
and is otherwise a foreign pointer. Judy is just fantastic.
It would be super cool to have a purely functional variant of it.
It should be possible I think, though I'm not sure: purely functional
trees are used all the time, and Judy is a tree. My guess is that
a different tuning algorithm would be required though. Basically
every mutation has to be replaced by construction of a new object.
If I understand correctly on a 64 bit machine an insertion requires
at most 8 mutations. And, unlike conventional trees which require
occasional rebalancing for performance, Judy never needs to be
rebalanced. So it is probably the ideal functional data structure.
--
john skaller
[email protected]
http://felix-lang.org
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel
