Tcl Source Code

The core proc auto_reset is documented as follows:

# auto_reset --
#
# Destroy all cached information for auto-loading and
auto-execution,
# so that the information gets recomputed the next time
it's needed.
# Also delete any procedures that are listed in the
auto-load index
# except those defined in this file.
#
# Arguments: 
# None.

But it doesn't do that:

proc auto_reset {} {
    variable ::tcl::auto_oldpath
    global auto_execs auto_index 
    foreach p [info procs] {
if {[info exists auto_index($p)]} {
    rename $p {}
}
    }
    catch {unset auto_execs}
    catch {unset auto_index}
    catch {unset auto_oldpath}
}

'info procs' only returns procedures in the global
namespace. Presumably auto_reset should also delete
procs in _all_ namespaces, if it is to agree with its
documentation.

Logged In: YES 
user_id=80530

done.

Logged In: YES 
user_id=32170

No comments to the contrary - we certainly want Tcl 8.4.10+
to be stable and not introduce new subtle problems.

Logged In: YES 
user_id=80530


re-opening after more reports of trouble.

The issue is that this bug fix for the first
time causes [auto_reset] to force the
re-loading of commands in non-global
namespaces.  This means for the first
time, auto-loading is causing some files
to be [source]d twice that for many years
have only been [source]d once.

There are an unknown number of
(arguably buggy) files out there that
do not tolerate being [source]d more
than once.  It appears some of 
these files are part of Tk's script library. (!)

Given that, it's looking more and more
like this change -- though it is a bug fix --
is sufficiently disruptive that it ought only
happen in 8.5 development, and not
in a stable patch release.

Any contrary comments, Vince?

File Deleted - 139645:

Logged In: YES 
user_id=80530

bogus patch deleted;

corrected patch committed for
8.4.11 and HEAD.

Logged In: YES 
user_id=80530

ok, patch just misplaced a check,
and perhaps tbcload was needed
to tweak the brokennness.

Logged In: YES 
user_id=80530

um, no.

that patch appears to totally break
[auto_mkIndex].  Don't understand
why skherndon thought it worked.

re-opened.

Logged In: YES 
user_id=80530

fix committed for 8.4.11 and HEAD

Logged In: YES 
user_id=281759

The patch worked.

File Added - 139645: auto.patch

Logged In: YES 
user_id=80530


Please test whether the attached auto.test
solves the issue.

Logged In: YES 
user_id=80530


It's looking like [auto_mkindex] is
dependent on this bug.

I'll try to develop a proper fix for this,
but if that doesn't come together, I'll
at least add [auto_mkindex] (and
support) to the list of special case
commands in [auto_reset].

Logged In: YES 
user_id=281759

I've run into a problem after picking up this change related
to Itcl.

Once auto_reset is called, auto_mkindex no longer indexes
itcl::class and other itcl procedures.

To illustrate, I placed a puts statement in itcl.tcl and in
auto_mkindex_parser::command.

(bin) 49 % package require Itcl
itcl.tcl sourced
auto_mkindex_parser::command proc
auto_mkindex_parser::command namespace
auto_mkindex_parser::command itcl::class
auto_mkindex_parser::command itcl::body
auto_mkindex_parser::command itcl::configbody
auto_mkindex_parser::command itcl::ensemble
auto_mkindex_parser::command public
auto_mkindex_parser::command protected
auto_mkindex_parser::command private
3.3
(bin) 49 % auto_reset
(bin) 50 % package require Itcl
3.3
(bin) 51 % 

at this point, if I run auto_mkindex on a directory with
itcl classes in it, they will not be added to the tclIndex.
There is no mechanism in place to force Itcl to handle
auto_reset.

Logged In: YES 
user_id=80530

commited slightly different
fix for 8.4.10 that treads a
bit lighter on compatibility.

Logged In: YES 
user_id=80530

revised patch with added safety
committed to HEAD.

Logged In: YES 
user_id=32170

Ah, yes, that's a very nice way of doing things. It does
appear to work for me.

I suppose the [info library] bit is to ensure that the
auto_* procs can be reloaded in the future?

File Added - 116992: 1101670.patch

Logged In: YES 
user_id=80530

please review this patch
for Tcl 8.5.

Logged In: YES 
user_id=32170

The basic bug is in both 8.4 and 8.5, so I would assume a
fix would apply to both (I'm not sure of the purpose of the
differences between 8.4 and 8.5, but they definitely
disagree with the comments in auto.tcl in 8.5).  

However, I'm most interested in seeing fixes in 8.5.

Logged In: YES 
user_id=80530

Is there a goof in this submission?

The bug is reported on Tcl 8.4.9,
but the code cited comes from
the Tcl HEAD of development.

Is the submitter looking for fixes
just on the HEAD, or for 8.4.10 as well?

Logged In: YES 
user_id=32170

Well then [info commands] seems the way to go.

Vince.

p.s. another buglet is the clause "...except those defined
in this file." above, which is untrue. 'auto_reset' does in
fact delete itself, for example.

Logged In: YES 
user_id=80530

no trouble.  [load] remembers
what files it has dlopen()'d  (*)
and will not do so twice.  A
second [load] on the same file
will only lead to another
Foo_Init() call.

(*) [info loaded] will even tell you
what they are.

Logged In: YES 
user_id=32170

At first sight I would say, yes, that 'info commands' would
be better, but then the problem is this would result in a
piece of code being loaded twice, wouldn't it?

mycmd ; # causes 'auto_load mycmd' which causes 'load foo.dll'
auto_reset
mycmd ; # causes 'auto_load mycmd' which causes 'load foo.dll'

Won't that cause trouble?

Logged In: YES 
user_id=80530

thanks for the report.  Sure looks
like [auto_reset] never got an
update to deal with the arrival
of [namespace].

While I consider a fix for this,
what do you think about
expanding to [info commands]
instead of [info procs] ?  Just
because a command is
auto-loaded doesn't mean it's
a [proc].  The auto-load script
could call [load].