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 [email protected] +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
