Re: outdated m4sugar

[Eric Blake]

-----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             address@hidden
-----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-----