#4798 something in cmd name caching is very wrong

obsolete: 8.5.9
closed-fixed
9
2011-06-02
2011-02-18
No

In tclsh 8.6 (close to CVS HEAD)
% namespace eval ns {proc foo {} {}}
% namespace eval ns2 {proc foo {} {}}
% namespace path {ns ns2}
% namespace which foo
::ns::foo
% proc foo {} {}
% namespace which foo
::ns::foo
invoking [foo] does in fact invoke ::foo, not ::ns::foo
And retrying from scratch, without the first [namespace which foo] returns ::foo

% namespace eval ns {proc foo {} {}}
% namespace eval ns2 {proc foo {} {}}
% namespace path {ns ns2}
% proc foo {} {}
% namespace which foo
::foo

Sounds like some cache not being invalidated ?

/Ashok

Discussion

  • miguel sofer

    miguel sofer - 2011-05-08

    Bug is in 8.5 too

     
  • miguel sofer

    miguel sofer - 2011-05-08
    • milestone: 897381 --> obsolete: 8.5.9
     
  • miguel sofer

    miguel sofer - 2011-05-08
    • priority: 5 --> 9
    • summary: namespace which command returns wrong result --> something in cmd name caching is very wrong
     
  • miguel sofer

    miguel sofer - 2011-05-08

    Problem seems to happen only at the interactive shell. It is NOT a problem with [namespace which], as shown by:

    % namespace eval ns {proc foo {} {puts [namespace current]}}
    % namespace eval ns2 {proc foo {} {puts [namespace current]}}
    % namespace path {ns ns2}
    % puts [namespace which foo]
    ::ns::foo
    % proc foo {} {puts [namespace current]}
    % puts [namespace which foo]
    ::ns::foo
    % foo
    ::
    % eval [list foo]
    ::ns

     
  • miguel sofer

    miguel sofer - 2011-05-08

    Possible fix in branch bug-3185407. Assigning to the real NS expert for review (if approved, can commit and merge to trunk too)

     
  • miguel sofer

    miguel sofer - 2011-05-08
    • assigned_to: msofer --> dkf
     
  • Donal K. Fellows

    There does seem to be a performance hit, but I've yet to determine whether it matters (or even if it is a real effect or a nasty confounding cache problem on my machine).

     
  • Donal K. Fellows

    Despite the fact that I find it hard to grok just what's going wrong (or rather why it goes wrong in some places but not others) I still approve the change from bug-3185407; I can't see that it is wrong and it does appear to fix the problem. Performance impact appears minimal.

     
  • Donal K. Fellows

    Fix applied to relevant mainline branches, including a test (derived from bug report; thanks!)

     
  • Donal K. Fellows

    • status: open --> closed-fixed
     

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

Sign up for the SourceForge newsletter:





No, thanks