egghelp/eggheads community

upvar

2008-02-25T07:34:37-04:00

You can also give upvar an absolute level number (#0 for the global scope)

Code:

upvar #0 globalvarName localvarName

...or a fully qualified variable name (making the level irrelevant)

Code:

upvar ::ns1::ns2::ns3::namespaceVar localVar

If you create a proc that gets the name of the variable to import from an external source, make sure you specify a level, or you could get in trouble (if the variable name is an integer)

Code:

proc myset {var val} {upvar 1 $var Var; set Var $val}

Statistics: Posted by user — Mon Feb 25, 2008 7:34 am

'static' vars, upvar and uplevel

2008-02-23T11:08:42-04:00

Upvar accesses variables in the proc that called the current one (or global if this is the first level of call). Uplevel executes a piece of tcl-code in the same level as above. Using the level argument with either allows you to move several levels upward in the function call stack.

A quick demonstration of upvar:

Code:

proc sub1 {} { set myvar "Foo" puts stdout "sub1: myvar is $myvar" sub2 puts stdout "sub1: myvar is $myvar"}proc sub2 {} { upvar myvar thevar if {[catch {puts stdout "sub2: myvar is $myvar"} error]} {  puts stdout "sub2: Could not read local \$myvar: $error" } puts stdout "sub2: thevar is $thevar" set thevar "Bar" puts stdout "sub2: Setting thevar to $thevar"}sub1

sub1: myvar is Foo
sub2: Could not read local $myvar: can't read "myvar": no such variable
sub2: thevar is Foo
sub2: Setting thevar to Bar
sub1: myvar is Bar

Here I use upvar in sub2 in order to access, and modify, the value of "myvar" which only exists in sub1. This is possible since sub2 was called by sub1, and moving one step upwards in the function call stack would place us in sub1, giving us access to the variables here. As sub2 exits, the link between sub1->myvar and sub2->thevar is broken while sub1->myvar retains its value. As sub1 exits, it's variablespace is wiped and myvar is lost.

Statistics: Posted by nml375 — Sat Feb 23, 2008 11:08 am

'static' vars, upvar and uplevel

2008-02-23T00:37:23-04:00

If you did something like..

Code:

proc myProc {} {  set last_result ""  # fails already, last_result is not going to be remembered}

The static proc does basically push variables into the namespace. It seems useful to me, but I do not understand upvar and uplevel so I'm not sure how it works, or it's the best solution.

Statistics: Posted by incith — Sat Feb 23, 2008 12:37 am

'static' vars, upvar and uplevel

2008-02-22T11:18:43-04:00

I'm not sure I get what you want. Do you want the variable to be saved, to keep its value even if the interpreter is restarted or are you just looking for a way to use global variables inside a namespace?

Statistics: Posted by user — Fri Feb 22, 2008 11:18 am

'static' vars, upvar and uplevel

2008-02-22T09:53:12-04:00

Well, all my scripts use namespaces and variables already. With this you don't have to setup variables for use later on at the beginning..

This works well for quick things, not that variables may or may not.

Other applicable uses for static variables might include something like:

Code:

# never send the same result twice, barebones examplestatic last_resultwhile {$::last_result eq $cur_result} {  cur_result = [fetch_result]}set "::last_result" $cur_result

Statistics: Posted by incith — Fri Feb 22, 2008 9:53 am

'static' vars, upvar and uplevel

2008-02-22T09:16:53-04:00

Why don't you just use variable?

AFAIK, variable isn't reset after a rehash.

Code:

namespace eval somens {    variable moo 1}

Statistics: Posted by metroid — Fri Feb 22, 2008 9:16 am

'static' vars, upvar and uplevel

2008-02-22T00:14:23-04:00

This post is meant for those that can explain this crap to me.

I wanted to make use of static variables in a script recently, that is, vars that will not get reset once the script is re-ran, etc. Basically I went and searched, discovered static vars do not exist in Tcl, and then found this code: http://phaseit.net/claird/comp.lang.tcl ... tml#static

Code:

    proc static {args} {      # set procName [lindex [info level [expr [info level]-1]] 0]      set procName "incith::test"      # putlog "procName is (${procName})\n"      foreach varName $args {        uplevel 1 "upvar #0 {$procName:$varName} $varName"      }    }

A quick usage example of this would be:

Code:

namespace eval incith {  namespace eval test {    proc myProc {} {      static count      if {![info exists "incith::test:count"]} {        set "incith::test:count" 1      }      incr "incith::test:count"      putlog "count is now ${count}\n"    }  }}

Declaring the 'static count' variable pushes the count var into the incith::test namespace and as such will not be forgotten.

As you can see I modified the set procName, which I'll now explain. When I first put it into a test script, the test script was under the same namespace above, namespace eval incith { namespace eval test {, and $procName became incith::test::PROC_NAME:var, where PROC_NAME was the calling procedure, e.g. incith::test::myProc:count based on the above example. Then I went and added proc static into my XRL script and procName would not fetch the namespace it was in, but instead it would only get the procedure name, and e.g. store the var as "myProc:count", this was baffling to me, which is why I just ended up forcing set procName to my namespaces.

The questions in all of this, is this really necessary? Is there some extra work being done? The point is just to not forget variables basically, so that when the proc is re-run it knows what a certain variable it's using was since the last call, and so on. It works, at least, but I can't help but feel that it's just plain wrong. It's also dang annoying to be typing out 60 char variable names with the namespaces etc. Discuss!

Statistics: Posted by incith — Fri Feb 22, 2008 12:14 am