Attachment "snit_bug.txt" to
ticket [1532791fff]
added by
andreas_kupries
2006-08-02 05:40:52.
Here is the session:
andreask@iguana:~/dbn/lba/night/builds/linux-ix86> ./out/linux-ix86/bin/tclkit
% info patchlevel
8.5a5
% lappend auto_path /home/andreask/dbn/lba/night/builds/linux-ix86/out/linux-ix86/lib
% lappend auto_path /home/andreask/dbn/lba/night/builds/linux-ix86/out/linux-ix86/lib/tcllib1.8
% lappend auto_path /home/andreask/dbn/lba/night/builds/linux-ix86/out/linux-ix86/lib/tklib0.4
% lappend auto_path /home/andreask/dbn/lba/night/builds/devkit/lib
% package require snit
2.0
% package require runwindow
1.0
% set x [runwindow %AUTO%]
unknown subcommand "%AUTO%": namespace ::runwindow does not export any commands
Ok, I do not know if this is a bug, or simply an incompatibility between 1.1 and 2.0
% set x [runwindow .r]
can't set "::runwindow::Snit_inst1::log": can't read "::runwindow::Snit_inst1::Snit_instance": no such variable
This is the problem I wish to report.
% set errorInfo
can't read "::runwindow::Snit_inst1::Snit_instance": no such variable
while executing
"set ${selfns}::Snit_instance"
(procedure "RT.ClearInstanceCaches" line 3)
invoked from within
"RT.ClearInstanceCaches $selfns"
(procedure "::snit::RT.ComponentTrace" line 22)
invoked from within
"::snit::RT.ComponentTrace ::runwindow ::runwindow::Snit_inst1 log ::runwindow::Snit_inst1::log {} write"
(write trace on "::runwindow::Snit_inst1::log")
invoked from within
"set ${selfns}::log {}"
(procedure "::runwindow::Snit_instanceVars" line 15)
invoked from within
"${type}::Snit_instanceVars $selfns"
(procedure "::snit::RT.widget.typemethod.create" line 22)
invoked from within
"runwindow .r"
During the widget creation a trace is triggered and an internal variable is accessed, at a time this variable does not exist.
% info body ::runwindow::Snit_instanceVars
set ${selfns}::run {}
trace add variable ${selfns}::run write [list ::snit::RT.ComponentTrace [list ::runwindow] $selfns run]
set ${selfns}::log {}
trace add variable ${selfns}::log write [list ::snit::RT.ComponentTrace [list ::runwindow] $selfns log]
set ${selfns}::hull {}
trace add variable ${selfns}::hull write [list ::snit::RT.ComponentTrace [list ::runwindow] $selfns hull]
set ${selfns}::log {}
set ${selfns}::run {}
My guess it is the second assignment to selfns::log in this generated procedure which bails out, as the trace exists at that time.
Going to "::snit::RT.widget.typemethod.create" ... It calls the generated code in line 1906 ... I believe that the Snit_instance variable on which we fail is created in MakeInstanceCommand, line 1989. For widgets this is called in "installhull". This is run by "::snit::RT.widget.typemethod.create" as well, after the Snit_instanceVars, in line 1922 to be precise.
So, the current code of snit 2.0 is inable to create widgets. We have an ordering issue.
Hm. Ok, the runwindow definition is a bit old ... It uses "delegate to log", and "variable log {}". One creates the assignment and trace, the other the second assignment.
Well, moving the variable definitions before the 'delegate' works around the problem.
And using 'component log' instead of 'variable log {}' works as well, even if used after the delegate.
I guess component and delegate have intelligence which prevents the creation of a superfluous assignment, whereas 'variable' does not have this intelligence.
Yep. Looking at the body of the gen'd code again
% info body ::runwindow::Snit_instanceVars
set ${selfns}::run {}
set ${selfns}::run {}
trace add variable ${selfns}::run write [list ::snit::RT.ComponentTrace [list ::runwindow] $selfns run]
set ${selfns}::log {}
trace add variable ${selfns}::log write [list ::snit::RT.ComponentTrace [list ::runwindow] $selfns log]
set ${selfns}::hull {}
trace add variable ${selfns}::hull write [list ::snit::RT.ComponentTrace [list ::runwindow] $selfns hull]
run, which I left as variable has double assignment, log has not.
