-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Akim Demaille on 7/11/2008 2:38 AM: | |> the |> change from LIFO to FIFO m4wrap (done in order to make m4 obey POSIX) | | I have not understood why they made that choice :(
"they" being me (as m4 maintainer) or the Austin group (as the POSIX folks who documented m4wrap as FIFO)? At any rate, both the Solaris and BSD m4 implementations (and I'm assuming the older SysV, on which Solaris was based), did FIFO; GNU m4 1.4.x was the odd man out for doing LIFO. Fortunately, along with making the change, I also documented how to restore the 1.4.x LIFO behavior by defining the appropriate wrapper around m4wrap (and m4sugar, as of autoconf 2.62, uses that wrapper), such that it is possible to get portable and known wrap semantics (of either variety) regardless of whether the underlying m4 is FIFO or LIFO. |> ChangeLog- |> wise, bison's version looks like it forked from autoconf commit |> http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=cf3b3ede, |> |> then added the macro m4_prepend (which autoconf should also consider |> adding). | | It would be very nice, indeed, that m4sugar be unified again. I've just committed a patch to autoconf to add m4_prepend, such that all macros used by bison's fork are now present in autoconf's fork. Next I'll be experimenting with dropping in autoconf's version and seeing what (if anything) breaks in bison. | | Bison is paying its performance penalty too to m4, so any speed | improvement will be warmly accepted! I've been tackling speed issues from both the m4 and m4sugar side of things over the past year. | | The test suite is reasonably strong, and I would be very surprised | if semantic incompatibilities would be unnoticed. Good. However, before I even start with newer m4, it would be nice to get a clean test suite run on cygwin even when using m4 1.4.11 (I saw two failures when running on CVS cygwin, and haven't yet finished a test run with the latest released cygwin 1.5.25. I'll send more details separately; but one failure was due to trying to create a file with \ in the name, even though \ is a directory separator on cygwin; I'm not sure why the other was failing), before experimenting with the effects of m4sugar changes. | | Indeed, putting it in GNU m4 would be really great! And actually, | autom4te was also meant to be part of m4. I suppose that aclocal | is still part of Automake, and not of Autoconf, right? Moving | things to the right place might not be so easy :) It definitely needs thought, and may take a couple of years before the transfer happens cleanly, but we'll see how things go. | Bison 2.4 is basically ready, betas were sent and AFAIK there | are no bug reports. Maybe 2.4 could wait for the completed | conversion to a newer GNU M4? Or would you advise to publish | 2.4 as-is, and roll up a 2.5 for never M4s? If the changes aren't too invasive for bison 2.4 to cleanly support m4 1.6, then I'm in favor of waiting a bit longer to get the 2.4 release polished now rather than needing a bison 2.5 just for m4 1.6. | |> Also, I'm considering making m4 1.6 treat the -d command-line option in a |> position-dependent manner. | | Really? I have been bitten by positional handling of the arguments | before. What's the motivation? Explained in my previous post; but mainly due to the interaction with adding the ability to freeze trace and debugmode status, along with the notion that -d on the command line should be as powerful as the debugmode builtin within a file (the -D/--define command-line parameter was already positional, and as powerful as the define builtin within a file). | | The non-use of frozen files is probably just the result of laziness: | it's too hard to set up and use. If we had autom4te instead of m4 | directly, we would probably use frozen files. I have no idea what | the speed-up would be though. Here's some quick profiling numbers, executed on cygwin, using autoconf.git's current m4sugar with branch-1.6 of m4, and picking the best time from several runs each: $ time m4 /dev/null # Do nothing, for reference real 0m0.062s user 0m0.030s $ time m4 -I lib m4sugar/m4sugar.m4 /dev/null # Load m4sugar from scratch real 0m0.140s user 0m0.093s $ m4 -F f.m4f -I lib m4sugar/m4sugar.m4 # Freeze... $ time m4 -R f.m4f /dev/null # then load m4sugar from frozen real 0m0.063s user 0m0.030s The granularity of time on cygwin is not very accurate, and the startup time for a typical autoconf run is often dwarfed by the time parsing configure.ac (and not the initialization in loading m4sugar), but this shows that reloading a frozen file has very little overhead in relation to a fresh startup, compared to noticeable overhead when parsing m4sugar from scratch. I can try to repeat this on Linux if you'd like. |> But you |> can also argue that one of the features that will be introduced by GNU |> m4 1.6 |> (linear instead of quadratic execution speed on recursive macro |> expansion) | | Wow :) Where can we read about this? How about here, where I first posted a patch series to do this? I've since made even more speed tweaks for what will finally be in 1.6 (nothing will be as dramatic as my algorithmic improvement from the overall of recursive evaluation, but even reductions of the constant factor associated with an operation can improve overall execution time). http://lists.gnu.org/archive/html/m4-patches/2007-11/msg00014.html - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh3uwwACgkQ84KuGfSFAYAHWACfZN3PeD+MsoJYE9nrnkWM/y2o IWkAnRlkyKkoiKuAixaZyiL1lUS8nqu1 =GT1g -----END PGP SIGNATURE-----
