[Top][All Lists]
[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__/
- FYI: 13-gary-remove-redundant-traced-field.patch, Gary V. Vaughan, 2001/09/07
- Re: FYI: 13-gary-remove-redundant-traced-field.patch, Akim Demaille, 2001/09/10
- Re: FYI: 13-gary-remove-redundant-traced-field.patch, Gary V. Vaughan, 2001/09/13
- Re: FYI: 13-gary-remove-redundant-traced-field.patch, Akim Demaille, 2001/09/17
- Re: FYI: 13-gary-remove-redundant-traced-field.patch, Gary V. Vaughan, 2001/09/17
- Re: FYI: 13-gary-remove-redundant-traced-field.patch, Akim Demaille, 2001/09/18
- Re: FYI: 13-gary-remove-redundant-traced-field.patch, Gary V. Vaughan, 2001/09/18
- Re: FYI: 13-gary-remove-redundant-traced-field.patch, Akim Demaille, 2001/09/25
- Re: FYI: 13-gary-remove-redundant-traced-field.patch,
Gary V. Vaughan <=