Hello, Maybe we should precise what we proposed exactly :
1) the builtin new functions --------------------------------------- among the 25 new builtins listed in our previous mail, only one depends on Judy, the other can be added straight ahead to src/builtin.c 2) the engine change (from hash-map to JudyBL) ---------------------------------------------------------------------- We protected it by with a --enable-optim=yes parameter in the configure script corresponding to preprocessors ifdef in the source and conditional link parameters.... As you can see, those two parts can be integrated separately... Judy Licence ---------------------- http://sourceforge.net/projects/judy/ talks about LGPL Judy availability ----------------------- We built it in cygwin, mac osx and freesbd without problems, I cannot tell you more.... In the case the engine change is accepted, but not Judy linking, how Judy could be replaced ? ----------------------------------------------------------------------------------------------------------------------------------- What is needed is an ordered map with binary buffers (data : uint8_t*/length : size_t) as keys and void* as value and that have this kind of feature (token recognition ) : What is the longuest key that can begin at position p in the source file ? We searched such a map for a looonnnng time before implementing our own.... Best regards, Gwen & Thom PS: As you may have guessed, we are french so that we don't know exactly if "pollute myself reading your code" is as insulting in English as it is in French. But what we know for sure is that we are very sensitive to environmental problems and that we don't want to pollute anybody, not even rude people.... So maybe we'd better eliminate the risk of contamination right now... 2012/10/19 Eric Blake <[email protected]> > On 10/19/2012 10:22 AM, gwenael chailleu wrote: > > Hello Eric, > > > > Well, we were very happy to discover and use gnu M4 and we will be happy > if > > our extension come to be accepted. > > > > Technically speaking, the main drawback is that our version needs to be > > linked to Judy Arrays library. > > What is the licensing of that library? [It wasn't listed at the link > you gave of http://judy.sourceforge.net/; I had to go hunting; even > http://sourceforge.net/projects/judy/ only gives an ambiguous statement > "GPL or LGPL" without mentioning which actual license or version of that > license; but it looks like > > http://judy.svn.sourceforge.net/viewvc/judy/trunk/COPYING?revision=59&view=markup > clears it up: LGPLv2+, so it is appropriate for linking into the GPLv3+ > m4 by invoking the 'or later' clause of LGPLv2+ and using the library as > LGPLv3+] > > Next, how popular is that library - is it already pre-compiled and > available on lots of distros, or would we be depending on something > unlikely to be present on must user's machines? [I at least found it > with 'yum install Judy' on my Fedora 17 box, but it wasn't pre-installed > by anything else I've ever done on that box] > > I'm very hesitant to mandate the library, so how hard would it be to > have a fallback if the library is not present? > > > > > there is an advantage associated to this drawback : each improvement of > > JudyL will have impact on m4. (gprof says that our token recognition > JudyL > > based function takes 16% of the execution time) > > > > We will let you evaluate what can be taken (for example there is no > > prerequisite for the integration of the new builtins) and what must be > left > > aside. > > > > What's next move ? > > Do you want a tgz of our directory ? > > Not yet. I don't want to pollute myself by reading your code until we > are certain that copyright considerations are taken care of first. > > -- > Eric Blake [email protected] +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > >
