[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A few gnu M4 extensions
|
From: |
gwenael chailleu |
|
Subject: |
Re: A few gnu M4 extensions |
|
Date: |
Fri, 19 Oct 2012 22:01:12 +0200 |
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
----------------------
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
<address@hidden>
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.