On Friday 06 June 2003 04:28, you wrote:
> The implementation in AOLserver 4 is very, very different. The script is
> executed then the ENTIRE set of namespaces and procs are saved to the
> server's "tcl.script" pointer.
This effect is not exactly stated in the docs, right, but it is the way
the new mechanism (look at ns_ictl) is working, yes.
The purpose was to enable people to sync-up interps at runtime
allowing for dynamical load of packages and stuff, w/o bringing
the server down or doing some custom tcl sourcing.
>
> This means that when interpreters are updated (as happens when an
> interpreter's created for a new thread, for instance) ALL of the global
> variables in the new thread have the values in the old thread. ns_eval {
> ...script ... } , then, is really a "synch all interpreters" command that
> first evaluates the given script.
Yes, it is rather "sync all interpreters" and "in all threads" behaviour.
>
> One EVIL side effect of this is that some of the standard ns_* Tcl API is
> implemented in Tcl, in some cases using global variables. So, for
> instance, I have a test case in which the following code:
>
> set form_size [ns_set size [ns_getform]]
Well, this is kind of bad, I agree. Heh, "ns_evil", ... I like it :)
>
> fails because another script has done an ns_eval and _ns_form was set in
> that thread to "t3". In the failing thread [ns_getform] has never been
> called, yet it's seeing _ns_form with the value t3 - an ns_set which does
> not exist in its context, of course.
>
> This is ... non-intuitive. Especially if one RTFMs and expects the
> behavior to be at least someone like the behavior that's described ...
So much has changed in 4.0... were all trying to keep all pieces
fit together.
BTW, the FM's would love to see volunteers that would spend
an hour or two with some of them :)
>
> Now the one use of ns_eval in OpenACS that causes the above problem can be
> fixed by simply switching to nsvs (probably a good idea anyway) but the
> documentation for ns_eval should be changed, perhaps? I have a hard time
> seeing the new functionality being all that useful ...
After some thinking, I came to conclusion that actually both functionalities
are very useful. Sometimes I just want to sync-up the interps, for whatever
reason, with just one hit (as what new ns_eval does). Sometimes I may want
to run one single command in all interps not replicating the whole interp
enchilada over and over (like the older one does).
I would love to hear some other oppinions. But, I'm already thinking about
what we'd need to do so that both approaches are available.
Cheers,
Zoran
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/
