m4-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FYI: 13-gary-remove-redundant-traced-field.patch


From: Gary V. Vaughan
Subject: Re: FYI: 13-gary-remove-redundant-traced-field.patch
Date: Tue, 25 Sep 2001 20:14:55 +0100
User-agent: Mutt/1.3.22.1i

On Tue, Sep 25, 2001 at 09:27:45AM +0200, Akim Demaille wrote:
> 
> | > Gary> This means that we store the flag against whichever
> | > Gary> m4_token_data is stored in the named symbol when traceon is
> | > Gary> invoked, and can be turned off by traceoff with the name of some
> | > Gary> symbol that currently holds that m4_token_data.  I think there
> | > Gary> is one small wrinkle in this approach, in that the command line
> | > Gary> trace parameters will need to be stored for application a the
> | > Gary> end of command line processing... 
> | > 
> | > Agreed.  That's the list I was referring too.  Maybe more is needed to
> | > make sure a trace bit is not forgotten even if the macro is undefined.
> | 
> | That won't happen now (see the tests I committed).
> 
> Arg, we misunderstood each other, my bad :(
> 
> You successfully reimplemented the behavior of 1.4, which is insane
> IMHO.  To me it is really a bug that the trace bit be attached to a
> body instead of a name.
> 
> When I ask for -t define, I don't want to see m4_define.  That's why I
> was referring to a list of names.

Oh yes,  I understand now.

> But I do agree there are clearly two viable semantics: tracing a name,
> or tracing a body.

I think the tracing a name semantic needs some careful thought in
terms of a clean implementation before we plough in with a brute force
approach.  It definitely is not a good fit for the way the data
structures are currently laid out...

Perhaps we need a new type of m4_symbol (formerly m4_token_data) which
can be inserted into the symbol table (as a placeholder) against names
that need to be traced, but have no value attached.  Such symbols
would never be removed entirely while their trace bit is set.

Come to think of it, I should revert the patch I commited that removed
the old m4_symbol data type so that we can once again attach data to
the symbol without needing an actual value in place...

> Today's situation is OK for Autoconf, which is the most important
> thing.

Do you fancy making another TODO entry ;-)

Cheers,
        Gary.
-- 
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk       ,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'      `&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook   =`---d__/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]