trace doc confusion
Arnt
execution, specifically by what is highlighted by * below:
enterstep
Invoke command for every Tcl command which is executed inside the
procedure name, just before the actual execution takes place. For
example if we have 'proc foo {} { puts "hello" }', then an enterstep
trace would be invoked just before puts "hello" is executed. *Setting
an enterstep trace on a command will not result in an error and is
simply ignored.*
leavestep
Invoke command for every Tcl command which is executed inside the
procedure name, just after the actual execution takes place. *Setting
a leavestep trace on a command will not result in an error and is
simply ignored.*
What does it mean setting an enterstep/leavestep on a command will be
ignored? The only logical thing I can imagine is that the 'command' in
those parts are meant to be "Tcl Build-In commands", while 'commands'
in the sentences before that mean "Tcl Build-In commands or user-
defined procs", if I understand things correctly?
Arnt
Don Porter
> Hi, I'm confused when reading the trace documentation for trace add
> execution, specifically by what is highlighted by * below:
>
> enterstep
> Invoke command for every Tcl command which is executed inside the
> procedure name, just before the actual execution takes place. For
> example if we have 'proc foo {} { puts "hello" }', then an enterstep
> trace would be invoked just before puts "hello" is executed. *Setting
> an enterstep trace on a command will not result in an error and is
> simply ignored.*
If we replace "command" with "non-procedure," does it make sense to
you then?
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Roy Terry
> Arnt wrote:
>> Hi, I'm confused when reading the trace documentation for trace add
>> execution, specifically by what is highlighted by * below:
>>
>> enterstep
>> Invoke command for every Tcl command which is executed inside the
>> procedure name, just before the actual execution takes place. For
>> example if we have 'proc foo {} { puts "hello" }', then an enterstep
>> trace would be invoked just before puts "hello" is executed. *Setting
>> an enterstep trace on a command will not result in an error and is
>> simply ignored.*
>
> If we replace "command" with "non-procedure," does it make sense to
> you then?
is also used in the syntax description to name the user-supplied
script. So we have two competing meanings for the word:
trace add execution name ops command
"command" ==> user supplied script, or "script"
...setting an enterstep trace on a command will not ...
"command" ==> proc like thingy that has no Tcl source; it's likely
written in C or some non-tcl language.
>
Arnt
> Saying non-procedure helps except the that "command"
> is also used in the syntax description to name the user-supplied
> script. So we have two competing meanings for the word:
>
> trace add execution name ops command
> "command" ==> user supplied script, or "script"
>
> ...setting an enterstep trace on a command will not ...
> "command" ==> proc like thingy that has no Tcl source; it's likely
> written in C or some non-tcl language.
That is exactly the source of my confusion: command is used 3 times,
in 3 different meanings:
Invoke command for every Tcl command [..]
Setting an enterstep trace on a command will not [..]
So, if I understand this:
trace add execution name ops *script*
Invoke *script* for every Tcl command [..]
Setting an enterstep trace on a command that is not a proc ("Tcl Build-
In commands" or one provided by a compiled extension) will not [..]
Is that correct?
Roy Terry
>
Darren New
> In my understanding, yes. It is correct.
It's probably a good idea to report this at SourceForge as a
documentation improvement request.
--
Darren New / San Diego, CA, USA (PST)
I bet exercise equipment would be a lot more
expensive if we had evolved from starfish.
Arnt
> It's probably a good idea to report this at SourceForge as a
> documentation improvement request.
I have added it as a bug.
Arnt