[TCLCORE] Re: [trace execute] for [onexit callback]

[Vince D. <vin...@my...>]

(sorry for the delay in replying: this email is not really read often; please reply to 'vi...@bi...').

On Thu, 31 Aug 2000 08:49:16   Eric Melski wrote:
>
>On Thu, 31 Aug 2000, Donald G Porter wrote:
>
>> From: Brent Welch <we...@aj...>
>> > By the way, isn't the big picture here that we need an
>> > 
>> > onexit callback
>> > 
>> > command so that Tcl-level applications can take action on exit?
>> 
>> Couldn't this just be an application of Vince Darley's proposed
>> [trace execute] command?
>
>This depends on which vision of [trace execution] you are referring to.
>With Vince's original patch, no; with the latest stuff he sent to me,
>maybe.  Vince can probably answer better than I.

Eric is right, you can't quite do this with my patch.  However, Eric's suggestions has to how to modify my patch to make it more 'Tcl-like' would allow this behaviour.  The only remaining issues are the precise implementation and whether it should go into the core, or whether the core should have just a minimal patch so that this behaviour could go into an extension.

Right now, I've written such a minimal patch (which Eric has), so that Tcl 8.4a2 has the internal APIs which would allow this.

Given that, we need a new trace-command to provide execution traces from Tcl, so that a Tcl callback is called under one or more of the following circumstances.  For clarity lets assume 'foo' is the procedure being traced:

My callback should execute:

(i) just before 'foo' is called.
(ii) just after 'foo' is called.
(iii) just before each command _inside_ foo is called.
(iv) just after each command _inside_ foo is called.

Various flags/options must be given to differentiate between these possibilities.

(i,ii) are useful for profiling, 'atexit' functionality etc.
(iii,iv) are useful for debugging purposes.

(i,iii) should have access to both the command name and the arguments it receives.
(ii,iv) should have access to the result of the command which just executed.

That is my vision for 'execution traces'.  Various frills can be added (such as only trace if current stack level is < N or > M, or only trace 'inside' if current relative depth is < N, etc).  For this kind of purpose it may therefore be useful if the callback also had access to the current stack depth.

Assuming all of the above is sensible, we need to work out the commands to add and remove such traces.

Eric (and others) have suggested adding this to 'trace add|remove command ...', so that instead of 'rename', 'delete' as the only options, we now have 'execution' as another option.  Now we need to decide how to allow the user to declare items (i)...(iv).  These could be more options:

trace add|remove command foo {rename delete execution postexecution internal postinternal} tcl_callback

or something like that.  This would seem to work, except there is then perhaps some confusion over what argument 'tcl_callback' should receive.  In the 'rename/delete' cases, the behaviour in Tcl 8.4a2 at present seems eminently sensible ('tcl_callback foo rename').  However, execution traces would require different information:

tcl_callback foo execution argument_list stack_level

tcl_callback foo postexecution result stack_level

tcl_callback foo internal argument_list stack_level

etc.

Perhaps: 'tcl_callback {foo argument_list} execution stack_level' would be better?

An alternative (which I initially preferred, but am now in two minds about) is to decide execution traces are quite different to command traces, and to add:

trace {add|remove} execution {before after interal postinternal} tcl_callback

any thoughts on this?  Another alternative is to add another syntax such as '%p %a %l' to allow the callback to have substituted in the procedure name, arguments and stack level, as it seems fit.  I don't like this approach at all, since it just adds yet another weird sub-syntax to Tcl.  

It seems there are two main questions:

(1) does this need to go in the core?
    No: do we need a patch to allow an extension to do this?
    Yes: go to question 2.

(2) should this be implemented as more options to the existing command traces, or as a new 'execution' trace type? 

Vince.





--== Sent via Deja.com http://www.deja.com/ ==--
Before you buy.

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.