Ok, I volunteer to be a guinea pig. Maybe it will help spark my motivation
to get us running on 3.X; I have been dragging my feet because 2.3.3
basically works (although crashes several times/day).
We use this to redefine procedures:
# NOTE: next rename fails when file is sourced, 2nd rename fails
# on boot; this is correct
catch {rename ns_returnredirect aol_ns_returnredirect}
catch {rename ns_returnredirect {}}
rename rl_returnredirect ns_returnredirect
It works whether the file is sourced at boot time or after boot, saving
the current definition and making a new one. Perhaps the same thing
could be done with proc so I don't have to edit everything?? Or I
can redefine it just for our library ... think I know how.
Jim
>
> On Thursday, September 20, 2001, at 10:39 AM, Jim Wilcoxson wrote:
>
> > I think the idea of redefining the unknown command is good.
>
> OK, I'm sorry to do this to you, but you seem to be the best candidate to
> be an experimental subject for this. Can you make some changes to your
> Tcl libraries and report on the findings? The changes I have in mind are
> as follows:
>
> - define a new command called "rl_proc", which takes three arguments, and
> is used instead of "proc" to define your commands. In rl_proc, you would
> store the arg list and body in an nsv keyed by the proc name
>
> - define an unknown proc which consults the nsv for the command name, and
> if it's found, executes "proc" with the arg list and body from the nsv.
> If the proc is unknown, you can return an error
>
> This would allow you to simulate the dynamic proc definition without
> needing changes to AOLserver. If you do this, let us all know if this
> makes a difference in thread startup times, and in overall performance,
> and if there's a positive change, we can try to attack any necessary
> changes in AOLserver.
>
> In the absence of information about sharing compiled Tcl objects between
> interpreters, I can't see a way to address the memory footprint issue
> right now, but we could see if the thread startup issue helps in terms of
> time and maybe memory.
>
