Ticket UUID: | 2d2a32124406e8494a9d73cf2b668dcddc75fdf6 | |||
Title: | info frame does not correct recognize current type of execution scope | |||
Type: | Bug | Version: | all | |
Submitter: | sebres | Created on: | 2019-03-15 14:18:16 | |
Subsystem: | 16. Commands A-H | Assigned To: | nobody | |
Priority: | 5 Medium | Severity: | Severe | |
Status: | Open | Last Modified: | 2019-03-15 19:21:45 | |
Resolution: | None | Closed By: | nobody | |
Closed on: | ||||
Description: |
If frame level is provided as value, it is confused:
If one gives the 0 (so as current frame level), it works correct:
But still worse, the things change also in this case if something else is involved around `info frame` additionally. % proc test {} { namespace eval ::test {puts ns:[info frame 0]} }; test ns:type eval line 1 cmd {info frame 0} level 0 % proc test {} { namespace eval ::test {puts ns:[set f [info frame 0]]} }; test ns:type proc line 1 cmd {info frame 0} level 0 So it looks like `info frame` is totally unusable at the moment (or at least pointing at the wrong frame, if one wants to retrieve the type of the scope). | |||
User Comments: |
sebres added on 2019-03-15 19:21:45:
Partially the behavior may be correct - the documentation about type "proc" says: proc means that the command is found in dynamically created procedure body. So I assume, in case it is constructed "statically" from source and compiled (like TCL_LOCATION_BC), info frame just searching the type up to the source and returns it wrapped to the origin type (e. g. using TclGetSrcInfoForPc). But the upper case (difference by [info frame 0] and [info frame [info frame]] may occur because of the in-place change of interpreter frame levels inside InfoFrameCmd, so it is correct by direct invocation (0) and wrong by 2 commands sequentially. Additionally this is ugly and should be rewritten. WiP. |