We ran into this problem a while back. The way we ended up solving was to create a policy where all initialization code was moved into an init proc. The init procs were named init.<module>. So for example:
/tcl/mapquest/
public.tcl
private.tcl
init.tcl
...# init.tcl
proc mapquest.init {} {
nsv_set foo bar dork
....
}We then changed the way Tcl code was sourced so that after all files were sourced in the usual way, all of the init.* functions would be called:
foreach cmd [lsort [info commands *.init]] {
ns_log notice "loading $cmd..."
if [catch {set t [time {eval $cmd} 1]} err] {
ns_log error "$err"
} else {
set t [expr [lindex $t 0]/1000000]
if {$t > 2} {
ns_log warning "$cmd took $t seconds to load"
}
}
}A similar approach might help.
- Nathan
On Sunday, March 16, 2003, at 03:30 AM, Zoran Vasiljevic wrote:
Simple. The problem is inter-dependency of the code within scripts executed from shared/private library and the order how they are executed.
It is quite difficult, and in some circumstances impossible to desing the order of the execution to fit the alphabetical order. The problem gets even more complex when you're making changes to an existing installation (i.e adding and/ot removing files) and have intermixed shared/private setup of tcl loaders.
-- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
