[Tcl-bugs] [ tcl-Bugs-967565 ] [info level] reports current interp's CallFrames only

[SourceForge.net <no...@so...>]

Bugs item #967565, was opened at 2004-06-06 13:15
Message generated for change (Comment added) made by dkf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=967565&group_id=10894

Category: 20. [interp]
Group: current: 8.4.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Mistachkin (mistachkin)
Assigned to: Jeffrey Hobbs (hobbs)
Summary: [info level] reports current interp's CallFrames only

Initial Comment:
Unless I have missed something in the docs (which is 
entirely possible at this hour), this behaviour is either a 
bug or a documentation oversight.  

Is there some bad interaction here between slave 
interps and [interp alias]?  Perhaps the combination of 
slave interps and namespaces triggers this problem?  

If this is NOT a bug, it is still downright confusing.  
Having [info level] "skip over" a caller in the stack is not 
ideal.

----

namespace eval ::test {
  proc procA { interp } {
    if {$interp} then {
      global i
      interp alias $i ::test::A::procB {} ::test::procB
      interp eval $i [list namespace eval ::test::A procC]
    } else {
      interp alias {} ::test::A::procB {} ::test::procB
      namespace eval ::test::A procC
    }
  }

  proc procB {} {
    set current [lindex [info level [info level]] 0]

    # should print "::test::procB"
    puts stdout "current ([info level]) == $current"

    if {$current == "::test::procB"} then {
      puts stdout "SUCCESS, current proc match."
    } else {
      puts stdout "FAILURE, current proc mismatch."
    }

    set parent [lindex [info level [expr {[info level] - 1}]] 
0]

    # should print "::test::A::procC" or "procC"
    puts stdout "parent ([info level] - 1) == $parent"

    if {[string match "*procC" $parent]} then {
      puts stdout "SUCCESS, parent proc match."
    } else {
      puts stdout "FAILURE, parent proc mismatch."
    }
  }
}


foreach this_interp [list 0 1] {
  puts stdout "Running test with use_new_interp set to 
$this_interp."

  if {$this_interp} then {
    set i [interp create]
    
    interp eval $i {
      namespace eval ::test::A {
        proc procC {} {
          procB
        }    
      }
    }
  } else {
    namespace eval ::test::A {
      proc procC {} {
        procB
      }    
    }
  }
  
  ::test::procA $this_interp
}


----------------------------------------------------------------------

>Comment By: Donal K. Fellows (dkf)
Date: 2004-06-08 22:22

Message:
Logged In: YES 
user_id=79902

It's possibly the case that we need [interp set], but it is
usually not to big a problem in practice.

Inter-interp [upvar] is deeply evil.  I don't want to be
that scared.

----------------------------------------------------------------------

Comment By: Joe Mistachkin (mistachkin)
Date: 2004-06-07 23:26

Message:
Logged In: YES 
user_id=113501

Actually, such a feature might be desirable in some 
circumstances (primarily when a safe interp calls a proc in a 
master interp that needs to modify variables in the calling 
child proc via upvar, etc).




----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2004-06-07 22:56

Message:
Logged In: YES 
user_id=80530


Note that the "level"s reported
on by [info level] are the same
ones which govern [uplevel] and
[upvar].  That might explain
why only the current interp's
CallFrames are tracked.  You would
not want an [uplevel] to cause 
substitution/evaluation in a different
interp.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2004-06-07 22:47

Message:
Logged In: YES 
user_id=80530


It's probably fair to say this
is underdocumented.

[info level] does not trace back
through the caller sequence,
weaving in and out of interps.
Instead, it reports the stack
of CallFrame's for the current
interp only.

This is intentional, though you
may need to consult with the
original [interp] creators to get
a best explanation of the reasons
why.  If Jacob Levy is available,
he might be able to fill in more
details.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=967565&group_id=10894