#1353 info locals seems not to work properly

obsolete: 8.3.2
closed-fixed
8
2008-09-29
2000-10-26
Anonymous
No

OriginalBugID: 6131 Bug
Version: 8.3.2
SubmitDate: '2000-08-14'
LastModified: '2000-10-25'
Severity: MED
Status: UnAssn
Submitter: techsupp
OS: Linux-SuSE
OSVersion: SuSE 6.4
Machine: AMD K6
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'

Name:
Christian Eva

ReproducibleScript:
proc xloc {args} {
global Defaults LikeDictionaries env L1
global Dictionaries

foreach m $args {
set $m $m
}

puts "locals=[info locals]"

set L1 [info locals]
puts "L1=$L1"

unset args

foreach a [info locals {[a-zA-Z]?*}] {
puts "a=$a"
eval set v \$$a
set Dictionaries($a) $v
}
}

set L1 empty

xloc a aA b Ba ccc

puts "L1=$L1"

parray Dictionaries
# end

bash-2.03$ tclsh8.0 localtest
locals=args m L1 a ccc b aA Ba
L1=args m L1 a ccc b aA Ba
a=L1
a=ccc
a=aA
a=Ba
L1=args m L1 a ccc b aA Ba
Dictionaries(Ba) = Ba
Dictionaries(L1) = args m L1 a ccc b aA Ba
Dictionaries(aA) = aA
Dictionaries(ccc) = ccc
bash-2.03$

bash-2.03$ tclsh8.3 localtest
locals=args m L1 a Dictionaries ccc b aA Ba
L1=args m L1 a Dictionaries ccc b aA Ba
a=L1
a=Dictionaries
can't read "Dictionaries": variable is array
while executing
"set v $Dictionaries"
("eval" body line 1)
invoked from within
"eval set v \$$a"
(procedure "xloc" line 18)
invoked from within
"xloc a aA b Ba ccc "
(file "localtest" line 25)
bash-2.03$

ObservedBehavior:
First I do not understand why "info locals" does list the global variables. It seems to lists them as soon as they are referenced in the procedure.

Second: The example works in tcl8.0 but not in 8.3. If I put the line
global Dictionaries

down into the foreach loop it works as a workaround:
foreach a [info locals {[a-zA-Z]?*}] {
global Dictionaries
puts "a=$a"
eval set v \$$a
set Dictionaries($a) $v
}

This is an extract out of a running program since 7.6. In 8.0 the error does not cause trouble but under 8.3 it crashes.

DesiredBehavior:
I would expect the varables listed in the global statement not to be
listed by "info locals" at all.

Discussion

  • Donal K. Fellows

    • labels: 104246 --> 104240
     
  • Donal K. Fellows

    [info locals] lists the variables that are visible in the current context. All [global] does is create a local alias for each named global variable with the "same" name as the global variable (it doesn't work quite like that if you put in namespace qualifiers, but that's a separate story.) This is not a bug, or certainly not a functional one. Maybe a documentation change would help instead?

     
  • Donal K. Fellows

    • assigned_to: nobody --> dkf
    • status: open --> closed-fixed
     
  • Marc Ziegenhagen

    I have the same problem and can't understand the differences between info locals and info vars. In the release 8.3.2 there is not a difference.
    Marc Ziegenhagen

     
  • Donal K. Fellows

    There is a difference when you consider passing in search patterns with namespace qualifiers. [info locals] only finds variables in the current naming context, [info globals] only finds variables in the global naming context, and [info vars] finds variables in either the current naming context or any named one (with qualifiers added.) The difference is admittedly slight, but it is significant. The current behaviour is also correct and documented correctly.

     
  • Don Porter

    Don Porter - 2001-04-04
    • labels: 104240 --> 17. Commands I-L
     
  • Don Porter

    Don Porter - 2008-08-29

    Logged In: YES
    user_id=80530
    Originator: NO

    The doc change noted here (from a
    2000-11-21 commit!) has been flagged
    on comp.lang.tcl as incorrect.

    Is there any recollection beyond
    what's recorded here how that
    change came about, and how it came
    to be incorrect?

     
  • Don Porter

    Don Porter - 2008-08-29
    • status: closed-fixed --> open-fixed
     
  • Donal K. Fellows

    • assigned_to: dkf --> dgp
     
  • Donal K. Fellows

    Logged In: YES
    user_id=79902
    Originator: NO

    I've no idea; I've forgotten everything about this bug that I ever knew.

    At a guess, someone seems to be wanting [info locals] to not return linked variables. If they want stuff that's been brought in by [upvar] but not by [global], I don't want to know.

    I have no plans to do anything about this bug. The world hasn't ended.

     
  • Don Porter

    Don Porter - 2008-08-29
    • priority: 5 --> 8
     
  • Christian Knoepfel Eva

    Logged In: YES
    user_id=2176213
    Originator: NO

    Please close this ticket.

    I was the original submitter of this ticket.
    I understand the philosophy behind the behaviour as you explain it.
    It is just annoying as we still have the mentioned program running on 8.0,
    but I will eventually change it as we have the most of our programs now converted to run on 8.5.

    Christian Eva

     
  • Don Porter

    Don Porter - 2008-08-29

    Logged In: YES
    user_id=80530
    Originator: NO

    Ok the history is messy on this one.

    Tcl 8.1.0 had a bug in [info locals].
    That's the bug reported here, since
    it was still present in Tcl 8.3.2.

    The reaction was to (partially, vaguely)
    document the bug instead of fix it. That
    was the docs change added for Tcl 8.3.3.

    This got reported again as 567386. It
    was fixed in Tcl 8.4b1 and has been fixed
    ever since. [info locals] is once again
    compatible with Tcl 8.0 and Tcl 7.* behavior.
    Been fixed since the 2002-06-11 commit by
    Miguel Sofer.

    The remaining flaw is that we never yanked
    the documentation error back out. That's
    the task for us now.

     
  • Christian Knoepfel Eva

    Don,
    Thanks very much to dig that out and clarify, it is much appreciated!

    And the good thing is our program actually works fine now with Tcl8.4.19 and 8.5.2.

    I think I gave up on it when the first release of Tcl8.4 did not work.

    Christian Eva

     
  • Don Porter

    Don Porter - 2008-09-29
    • status: open-fixed --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks