Tcl Source Code

this is a patch for which i didn't see any related PR, so i'm not entirely certain if this patch will be a popular one or not...

as mentioned in patch#103420, my company's tools typically register a callback with Tcl_CreateTrace() so that we can automatically generate a command  "history log" or "replay script" of a tool's usage.  one of the problems we've had with the tcl trace involves the 'level' argument that gets passed to our trace callback function.  specifically, bracketed commands whose results are passed as arguments to another command is the issue.  

consider two tcl commands, 'a' and 'b', where the results of 'b' are commonly passed as an argument to 'a'.  ie, "a [ b ]".  with today's implementation, a tcl trace callback will be invoked twice, once with the 'command' argument equal to "b", and then again with 'command' equal to "a [ b ]".  the 'level' argument in both invocations is the *same* value, which presents a problem for me.  if the 'level' provided in the first invocation was 'X', i would expect the second invocation to be 'X-1'.  otherwise, i have no way of telling that the first invocation is merely being evaluated as another command's argument.

since the bracketed command cannot be distinguished from a regular command, our resulting command log is faulty in that it will first print 'b' and then print 'a [ b ]'.  

the fix for this involves wrapping an increment/decrement of iPtr->numLevels before/after a call to a bracketed command.  i'm not convinced the patch i've provided below is the absolute cleanest or best way to achieve our goal, but it seems to work just fine for us.

it'd be nice to see this patch encorporated into a future release of tcl, but i also realize there may be some argument to the contrary that i haven't seen yet...

Logged In: YES 
user_id=148712

This doesn't fit with tcl's way of seeing things: it is NOT
a who is calling b in the example.

The way it works and is documented is: b's result as an
argument to a. The level count is correct, the log's output
corresponds to the real evaluation order.

Logged In: YES 
user_id=148712

Related to: bug #219362, patch #403420

This might break other code - we ought to consult with the rest of the community on this...