Tcl Source Code

Not sure if this is a bug, but it seems very strange to
me and there is no mention in the documentation.

Normally if you execute a command in an interp using
[interp eval] then that command is executed in global
context. However if it is executed as part of a
procedure in the parent interp that has been called by
alias from another procedure in the same slave interp,
then the command is executed in that slave interp
procedure's context. I would expect it to go back to
global context.

Here's an example:

/usr/local/ActiveTcl/bin/wish
% info patchlevel
8.4.6
% set foo [interp create]
interp0
% $foo eval set nodecount 100
100
% $foo eval set nodecount
100
% $foo alias bar bar
bar
% proc bar {} {global foo; $foo eval set nodecount}
% bar
100
% $foo eval bar
100
% $foo eval [list proc oink {} {bar}]
% $foo eval oink
can't read "nodecount": no such variable

# next bit shows that if slave is entered from a
different slave rather than itself, context is global

% set foo2 [interp create]
interp1
% $foo2 alias bar bar
bar
% $foo2 eval [list proc oink {} {bar}]
% $foo2 eval oink
100

Logged In: YES 
user_id=80530

backport?

Logged In: YES 
user_id=79902

Fixed in HEAD.

Logged In: YES 
user_id=72656

Agreed, this is just missing doc, as it has to be this way
by design.

Logged In: YES 
user_id=79902

This is a doc-fault at best.  [$foo eval] has to use the
child's current context since that is the only way to allow
access to the local variables in the child.  Without this,
you would be unable to sensibly override commands like
[while] or [for]...

Perhaps there should be a way to say that you want to
evaluate some code in a particular namespace, but that's
somewhat beside the point.

File Added - 85982: 926590.patch

Logged In: YES 
user_id=148712

I think this is a doc bug: the evaluation in the slave
occurs in whatever scope or context is current in the slave.
I am not sure of the possible security implications for safe
slaves.
Attaching a doc+test patch for review.

Logged In: YES 
user_id=148712

Confirmed that execution is in the context of 'oink': 
% $foo eval [list proc oink {} {set nodecount 200; bar}]
% $foo eval oink
200

Not sure yet if this is a bug in the docs or in the code;
investigating.