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 <[email protected]> > 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 > >
