Re: A few gnu M4 extensions

[gwenael chailleu]

Hello,

Obviously, a gnu M4 V2.0 is currently simmering...

Where can we find more about it?

We are coding non-general purpose builtins (that is to say builtins dedicated to the Cawen langage needs) 

and we would like to know how to implement them in a way that would be similar to/compatible with the future V2.0 loadable modules management...

Thanks a lot!

Gwen

2012/10/20 gwenael chailleu <address@hidden>

Well, I feel relieved and ....totally stupid.

You say that "email can be a rather poor medium" but I am afraid my English is even poorer.

I suppose that this is how some wars began in the good old days ;-)...

Thanks for your detailed explanations. 

We are sorry we knew almost nothing about all the copyright subtilities you have to deal with.

Well, you said that you were not "married to m4's current choice of hash table", and we are not married either to Judy library.

What we are proposing is some kind of concept : "the new map should be ordered + its keys should be whatever binary buffers + it should offer a token recognition functionnality" 

Maybe such a map, whose code could be embedded, already exists and is faster than JudyBL ?

 

More generally, we do not cling to our implementations.

As far as the new builtins are concerned, their purpose can be deduced from their testing files. 

We found them usefull but are they really relevant ?

  

Anyway,we'll send the whole packet soon...;-)

Best regards (plus sincere apologies!)

Gwen

2012/10/19 Eric Blake <address@hidden>

On 10/19/2012 02:01 PM, gwenael chailleu wrote:
> 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

That's a lot of builtins; and I haven't yet opened the tarball you sent
in the first email to see what exactly you are proposing.  There may
indeed be things worth adding, but we have to be careful about new
additions not infringing on existing m4 clients.  This sounds something
that would fit better in the eventual m4 2.0 module idea, than in the
current m4 1.4 code base.

>
> 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...

Good, and if the new lookup backend offers any speedups, it may be worth
taking independently from new builtins.

>
> 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....

I'm by no means married to m4's current choice of hash table as the
optimal token lookup - it's just that I'm worried that m4's current role
as a pivotal member of the autotools will make acceptance of a relative
newcomer library more difficult if we don't make use of the new library
an optional choice of the distro.

>
>
> 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.

Oh dear, my apologies - I was not at all intending to come across as
rude.  In English, the term 'pollute' in relation to coding copyrights
has a non-offensive meaning.  Perhaps a more verbose rendering would be:
"I'm afraid that if I read your source code prior to ensuring that the
copyright status is clear, then someone down the road could accuse me of
using your code and violating whatever copyright you own, even if it was
not my intent.  Therefore, to avoid even the appearance of impropriety,
I don't mind reading your high-level descriptions (such as documentation
of what a new builtin would be named and how it is used) but I will
avoid reading your code in case it turns out that you don't assign
copyright to FSF after all.  That way, if I (re-)implement the same high
level description on my own, that implementation will be completely mine
without any risk of legal derivation."

> 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...

No, feel free to post your code to the list - there may be others that
are interested in reading it, even if I choose to wait a bit longer.
After all, while my reason for not reading the code is in the interest
of protecting the FSF's existing copyright on the current m4 code base,
the M4 package itself is open source and the GPL even guarantees you the
right to make your changes public, just as it guarantees me the right to
choose whether or not to read your changes.  I hope I'm not coming
across as rude, but email can be a rather poor medium in comparison to
face-to-face contact!

--
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org