Dossy,
Thanks for this help. I think we are getting close, but I'm still not
able to achieve the behavior I'm looking for.
I want to clear up some questions straight off regarding my proc def
before delving back into the ns_ictl stuff.
There was no real reason to use eval rather than just call "_proc
$proc_name $args $body." I think that's vestigial as a result of my
trying to distill my larger actual proc definition into something
suitable for posting as an example.
Also, the namespace stuff isn't stripping namespace away, but simply
making the namespace explicit when the proc was defined in one. For
some reason, _not_doing_this_ breaks code in namespaces. I plucked
that snippet from OACS's ad_proc.
Now, on to ns_itcl...
First, I want to make sure our terminology is matching. When you say
"master interp," you are referring to the interpreter that is
processing the private tcl library, correct? I actually _do_ want the
private library to load using the redefined proc. The only time I do
not want my version of proc to be used is during the "cloning" which
causes all the defined procs to be redefined with whatever is the
current proc command.
Next, I tried to use ns_ictl get/save, but it doens't seem to do
anything. E.g., I had this load early in my private tcl library, but
when I print out the value of [ns_ictl get] in a .tcl page, I don't see
my ns_log calls, and I never see the messages in the log itself,
either. If this worked, it would seem like it could take the place of
'oncreate' and the 'postcreate' which I am looking for.
--------
set new_script "
ns_log notice \"PROC: In new ictl script\"
[ns_ictl get]
ns_log notice \"PROC: Done with new ictl script\"
"
ns_ictl save $new_script
--------
If I set a log message in oncreate, however, I _do_ see it.
--------
set script {
ns_log notice "PROC: In oncreate"
}
ns_ictl oncreate $script
--------
I can potentially use oncreate to put the old proc (now _proc) back in
its place, but I would still need a postcreate to flip them back again.
Any more suggestions? I think I've tried every permutation of
definition and renaming possible, but I'm always up for more. :-)
--dan
----------------------------------------
dan chak
web: http://www.chak.org
On Feb 6, 2005, at 9:00 PM, Dossy Shiobara wrote:
On 2005.02.06, Dan Chak <[EMAIL PROTECTED]> wrote:
How can I get all my code to use my proc, and the faking-of-cloning
process to use the real proc?
That was the first example I gave that only registered the [ns_ictl
oncreate] script, without [eval]'ing it in the master interp. e.g.:
set script {
rename proc _proc
_proc proc {proc_name args} {
set proc_namespace [uplevel {::namespace current}]
if { $proc_namespace != "::" } {
regsub {^::} $proc_namespace {} proc_namespace
set proc_name "${proc_namespace}::${proc_name}"
}
ns_log notice "PROC: $proc_name"
set procdef [list _proc $proc_name]
eval [concat $procdef $args]
}
}
ns_ictl oncreate $script
Also, why does your version of [proc] change its signature? The
standard signature of [proc] is {name args body} -- if you use the same
signature, you could eliminate that [eval [concat]] weirdness:
set script {
rename proc _proc
_proc proc {name args body} {
ns_log notice "PROC: $name"
_proc $name $args $body
}
}
I'm also puzzled by your little namespace "::" stripper thingy. My
understanding of the code is, "if the caller isn't in the root
namespace, define the proc relative to the namespace it's in regardless
of if the proc was defined with an absolute namespace (i.e. the leading
"::")?" You do realize that will break existing Tcl code that uses
namespaces, right? You are doing this for some good, but mostly
unguessable reason which is unknown to me, right?
It would be great if there was a 'ns_ictl aftercreate' command so the
tcl-defined [proc] can be used for the cloning and the user-defined
proc gets used for everything else. Any ideas on how to fake this?
set script [ns_ictl get]
append script \n {your aftercreate script here}
ns_ictl save $script
Also, I'm using AOLServer 4.0.9 with Tcl 8.4.9, though I would hope
the
solution would not vary vastly from one version set to the next.
It shouldn't, but it could. It's just good to document (and, I
consider
this mailing list's archives a kind of documentation) what version was
used at the time, so others don't have to wonder and/or ask.
-- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
