Tcl Source Code

When command delete traces fire,
the command is supposed to still
be there (even though you cannot
stop its deletion).  Like so:

% proc callback {old - -} {
    puts "$old exists: [namespace which $old]"
}
% proc bar {} {}
% trace add command bar delete callback
% rename bar {}
::bar exists: ::bar


However TclTeardownNamespace
deletes access to commands before
deleting the commands (and thus
firing their delete traces).  See:

% namespace eval foo {proc bar {} {}}
% trace add command foo::bar delete callback
% namespace delete foo
::foo::bar exists: 
unknown command "::foo::bar"

Some re-ordering in TTN() is needed.

Logged In: YES 
user_id=80530



Looks like we overlooked
closing this one.

Logged In: YES 
user_id=148712

Added test trace-34.5 to illustrate the the role of "ns in
callStack" in the ns's visibility during deletion traces.

Logged In: YES 
user_id=80530


sorry, mis-recalled the docs
for [namespace which].
Empty string return is correct
for non-existent command.

Logged In: YES 
user_id=80530


I don't like that at all.

At least before I had the choice
of a successful [namespace which]
or an error.  A [namespace which]
that apparently succeeds but returns
an empty string is unsettling.

How do we fix it?

Logged In: YES 
user_id=148712

To illustrate the difference between 'ns in stack' and 'ns
not in stack':

% info patch
8.5a4
% namespace eval foo {proc bar {} {}}
% trace add command foo::bar delete callback
% namespace delete foo
::foo::bar exists: ::foo::bar
%
% namespace eval foo {proc bar {} {}}
% trace add command foo::bar delete callback
% namespace eval foo {namespace delete [namespace current]}
::foo::bar exists:

Logged In: YES 
user_id=148712

Rats - forget about namespace-7.4 (completely unrelated,
looking in a buggy sandbox. Sorry.)

Comments still stand on their own merit.

Logged In: YES 
user_id=148712

This bug is not 100% fixed: witness the test namespace-7.4.

There seems to be an inconsistency here: during the call to
[namespace delete], the namespace is supposedly not
resolvable anymore (according to the man page). This seems
to disagree violently with the expectations in this bug report. 

The current implementation insures unresolvability if the
call to [ns delete] occurs when the namespace is not in the
call stack (ie, activationCount==0) [that it does only in
this case may be an independent bug]. Namespace-7.4 fails
not because the command does not exist, but because it can
not be resolved by name; I suppose that if it is imported to
another namespace, it does work when resolved there.

Not sure what the correct behaviour might be. I tend to
prefer that the command not be resolvable during a delete
trace triggered by the namespace deletion - because the
namespace itself is not resolvable.

Logged In: YES 
user_id=148712

Please note that the behaviour for delete traces on
variables is spec'ed differently: the variable is supposed
not to exist while the delete trace fires - see Bug #1338280

Is there some deep reason for this difference? I can't find
a related tip (tip62 mentions that "Tcl8.4 has already added
support for tracing rename or delete operations on Tcl
commands").

Logged In: YES 
user_id=80530

[12:07]dgpI don't think that's a problem.
[12:08]dgpcommand traces first arrived in Tcl 8.4, so
there's not going to be any ancient code involved.
[12:08]dgpand the 8.4.x patch releases are supposed to be
for fixing the 8.4 bugs.

patches committed.
Added a test based on the example in the report.

Logged In: YES 
user_id=148712

Patches look good.

Is it  possible that some code in the wild might be relying
on this behaviour (or using ad-hoc workarounds that this
could break)? I'm not sure if I'd risk fixing the 8.4 branch.

File Added - 140972: 1047286-84.patch

Logged In: YES 
user_id=80530


corresponding patch for 8.4

File Added - 140970: 1047286.patch

Logged In: YES 
user_id=80530


Attached patch is a simple
reordering of TclTeardownNamespace
that corrects the reported problem
and passes the test suite.

Needs further review.