To All:

Thank you very much to all of you for you comments and suggestions.  I find the
idea of a good build system very appealing.  Especially for 2 reasons;  1)  It is 
simply not my forte' ,  2) I think the person that has been doing that job has 
moved out of the HP Lab and I suspect he would like to pass the baton --
HP does has issues with Version 3 LGPL.  I do not understand much of your
talk about building methods.  I live on different planet.

I think many of your comments were right-on!  I will incorporate almost all
of them in the next Judy.

But now for the exciting part.  I decided to take a break from Judy1/L for awhile
and work on JudyHS, since that has been neglected for so long.  In the design
to add JudyHSNext/Prev/First/Last very interesting possibilites jumped off the page.
I need your help with suggested features that look very feasible.

1) An Index of arbitrary size in Bytes, Words, specifiable?
2) An arbitrary length of Value in Bytes, Words?
3) A new Create method:  JudyXXCreate(), would be necessary before the first JudyXXIns().
4) Instead of returning a pointer to Value, the pointer would be to a struct -- containing
    the Value(s) and possibly the length of the Value area.  This means that every Index
    could possibly have a different size Value area.  This leaves the possibilty of a 0 Value
    area, with improved speed than with non-zero to a max of ?? Bits/Bytes/Words?
4) The length of Value area would have to be specified in Create (static) or Insert (dynamic)?
5) The sort method (Dictionary(lexicographical order) or Binary) would have to be specified 
     during JudyXXCreate()
6) Endianess compensation parameter at XXCreate() if the Index is passed in array elements of
    1,2,4,8 byte elements.
    I.E.  suppose the Index is 10 bytes, but passed as  "uint32_t Indx[20];" , and passed like 
    "JudyXXIns(PArray, Indx, 10)", or  "JudyXXIns(PArray, Indx, 4, 10);"  The byte stream looks 
    different with Little and Big Endian machine.   Judy needs to know how many bytes to swap.  
    The Values would stay native Endianess.  Also if the Index is Left or Right justified?
7) The Sematics of XXIns() would need to know what to do if the size of Value area is different that
    a one that already exist.  Possibilities are stay same or grow?
8) Error returns from passive (non-array altering) calls would return the same as a 0 population array
     (no error codes -- no passed error parameter)
9) Leading zero deletion when in Binary sort mode -- perhaps specifiable at XXCreate()
10) I think the speed would be similar to JudyL + one Cache-fill for Value areas less that
      a cache-line in size (64bytes).
11) In the case of 0 length Value area, leave the return pointer to what?
12) I am sure I have I forgotten something.

doug
 
Doug Baskins <dougbaskins@yahoo.com>



From: john skaller <skaller@users.sourceforge.net>
To: Erick Tryzelaar <erick.tryzelaar@gmail.com>
Cc: Doug Baskins <dougbaskins@yahoo.com>; judy <judy-devel@lists.sourceforge.net>
Sent: Sun, February 6, 2011 6:26:33 PM
Subject: Re: Judy on 64-bit windows;


On 07/02/2011, at 6:57 AM, Erick Tryzelaar wrote:

> On Sun, Feb 6, 2011 at 2:20 AM, john skaller
> <skaller@users.sourceforge.net> wrote:
>>
>> Generating code in a build system is fraught with difficulties.
>> Such as "using make" or "using bash" to do it. Such as finding out
>> which compiler to use to actually build the tool that generates the
>> code. Best not to get into this! [Felix does it, but we have spent several
>> years developing portable technology to do it, written in Python]
>>
>> This is also what GNU tends to do. Although code generators are included
>> in the repository, so is the code it generates. In particular, "automake" can
>> be used to generate makefiles, but this is done by the original developer,
>> not the client.
>>
>> You can get our version from GitHub as erickt/judy [I'll leave it to Erick to
>> provide the details]
>
> Hey John,
>
> I have already partially modified felix's build system to compile judy
> straight from a tarball, so we won't have to deal with copying files
> around.


I'm not sure that's possible or desirable. Judy uses generated C code, namely
lookup tables.

There's no reason for this, there are exactly two variants: 32 and 64 bit,
there's no reason that Doug shouldn't generate them himself and put the
result in the repository.

What I'd like to see is that some other non-core-Judy-developers (i.e.
not Doug or Alan) take care of the build and docs some other peripheral stuff
so Doug can focus on R&D. Especially as we need Windows people for testing.

Worse, sad, I have OSX and it seems there will be no choice but to switch to CLANG/LLVM
since GNU stupidly screwed Apple up by introducing GPL 3, so it seems Apple will
no longer support gcc, and unfortunately their  OSX doesn't work with standard
Unix loaders (Xcode gcc is patched by Apple).

--
john skaller
skaller@users.sourceforge.net





------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Judy-devel mailing list
Judy-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/judy-devel