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