[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: |
Mon, 17 Sep 2001 23:54:19 +0100 |
User-agent: |
Mutt/1.3.22.1i |
On Mon, Sep 17, 2001 at 04:45:03PM +0200, Akim Demaille wrote:
> >>>>> "Gary" == Gary V Vaughan <address@hidden> writes:
>
> Gary> I'll look at this properly after the weekend when my chapter is
> Gary> done. In the mean time, do you think that there is a genuine
> Gary> need to track the traced flag on each `struct m4_token_data'
> Gary> *and* each symbol name?
>
> Well, I reversed the patch we are debating about, and nothing changes,
> it's coming from another one.
Indeed. The oldest m4 I have to hand is m4-1.4o, which also has the
bug you describe :-(
> I definitely understand your point, but at the origin that was the
> guarantee that you could follow a builtin even if renamed (define +
> defn).
This is the same as having the trace bit attached to `struct
m4_token_data'...
> Today, I am more and more convinced that what would be really clean is
> simply a list of macros to be traced, and each time a macro is
> defined, we look at this list.
Ugh. That sounds like a lot of unnecessary duplication in the
internal data, not to metion moving back towards keeping multiple
structures in synch.
> I.e., if I `m4 -t foo', then, what ever the number of define and
> undefine of foo, all invocation of the macro should be traced.
>
> Up to now, only the invocations before the first undefine are traced.
> This is really what I'm looking for, and it is also what I consider as
> the sanest semantics for traces.
You are saying that you are looking for the behaviour in the `I.e., if
I...' paragraph, right? This means that we store the flag against
whichever m4_token_data is stored in the named symbol when traceon is
invoked, and can be turned off by traceoff with the name of some
symbol that currently holds that m4_token_data. I think there is one
small wrinkle in this approach, in that the command line trace
parameters will need to be stored for application a the end of command
line processing... but we already do that with some flags anyway so I
don't think that is too onerous.
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 <=
- 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, 2001/09/25