Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-2898722 ] [namespace path] + [proc] resolution inconsistencies
|
From: SourceForge.net <no...@so...> - 2010-01-10 12:16:14
|
Bugs item #2898722, was opened at 2009-11-16 23:24 Message generated for change (Comment added) made by ferrieux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2898722&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 21. [namespace] Group: obsolete: 8.5.7 Status: Open Resolution: None Priority: 9 Private: No Submitted By: brad harder (bharder) Assigned to: Donal K. Fellows (dkf) Summary: [namespace path] + [proc] resolution inconsistencies Initial Comment: Interpretter seems "slow" to realize that a [proc] is available in current namespace that will satisfy a call for that command. Example is attached in test. Bug is manifested as bad/delayed interaction between [namespace path] and definition/call of a proc within a namespace. ---------------------------------------------------------------------- >Comment By: Alexandre Ferrieux (ferrieux) Date: 2010-01-10 13:16 Message: Sorry, "command name", not "procname". Mea maxima culpa, beat me up until dawn, but please please answer... ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-01-09 19:12 Message: I can't see why you're fixated on procedures. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2010-01-09 17:43 Message: Donal, can you comment on the idea of a hashtable keyed on the procname (tail) ? ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-01-09 16:49 Message: Distilled down to a single test that hits at least one of the bugs in this area, and hits it reliably. (Because the original report looked like it involves literal sharing, it's not entirely trivial to trigger on an entirely predictable basis.) ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2010-01-08 23:45 Message: Sorry, assigning to me is an exaggeration, I'm way above my usual flight level. Passing on to oxygen-tank-equipped dkf (see my last comment: statistics in TclOO etc) ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2009-12-11 01:05 Message: alex - can you take this one over? You seem to be way ahead of me :P ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2009-11-18 01:27 Message: For the record, a summary of a chat with Miguel: Mig first dichotomizes into two strategies: (a) on first alert, nuke all refs (b) look more closely and nuke only those that deserve it Then he argues that (a) is probably faster+better, since [proc]/[rename] are not done at time-critical runtime; (b) is costlier. However, as an afterthought to this discussion, I wonder about the feasibility of (a) short of nuking _all_ refs in the interp. Indeed, the concerned refs are not isolated by namespace, they can come from many namespaces (all those who have the current one in their path, plus extra ones with fully qualified procnames aiming directly at us). So unless we nuke all refs in the interp, (a) is identical to (b). Another approach would be to keep an interpreter-wide hashtable of refs; keyed on the tail of the procname (baz in ::foo::bar::baz). In that case, TclResetShadowed simplifies enormously. However I'm a bit uneasy about what happens to method creation/destruction in TclOO, where the rate of degeneracy on the key (name tail) is high... ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2009-11-17 23:57 Message: Closing in. It appears TclResetShadowedCmdRefs doesn't take into account the relatively new [namespace path]. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2009-11-17 23:30 Message: One fascinating thing in this : if you replace puts "mycmd" with puts "abcdef" or even puts "mycmd " ;# <- note the extra space then the effect disappears. So I suspect this is all related to shimmering of the mycmd literal between a cmdName and a String (when output to stdout with some nontrivial encoding). The shimmering explains why *after* executing the ::fu variant, the ::fu::bar gets activated. It doesn't explain though why the ::fu is called instead of the ::fu::bar after redefinition. To be continued. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2009-11-17 08:28 Message: Renamed. "Slow" means a perf problem -- this is a semantic bug. ---------------------------------------------------------------------- Comment By: Mark Janssen (mpc_janssen) Date: 2009-11-16 23:47 Message: For completeness (and to not require a tcltest script download) Seems likely that something with caching (implies epoch??) is at fault here. The following simple interactive session demonstrates this: % namespace eval ::fu { proc mycmd {} { puts "mycmd" }} % namespace eval ::fu::bar { namespace path ::fu; mycmd } mycmd % namespace eval ::fu::bar { proc mycmd {} { puts "fubar mycmd"}; mycmd } mycmd % namespace eval ::fu::bar { mycmd} fubar mycmd % namespace eval ::fu::bar { proc mycmd {} { puts "fubar mycmd"}; mycmd } mycmd % namespace eval ::fu::bar { mycmd} fubar mycmd % namespace eval ::fu::bar { proc mycmd {} { puts "fubar mycmd"}; mycmd } mycmd It seems that calling mycmd when it is still only defined in namespace ::fu is a necessary prerequisite to see this behaviour. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2009-11-16 23:27 Message: Likely an epoch check problem within the "cmdName" Tcl_ObjType. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2898722&group_id=10894 |