On Thursday 05 June 2003 11:36 pm, Zoran Vasiljevic wrote: > 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.
Yes, I did look at ns_ictl and "ns_ictl update" (in effect) is what gets run after ns_eval copies all your namespaces to the server's interpreter tcl.script (for those who haven't dug in the code it builds a script that defines all procs and namespaces/variables with their current values and stores it in tcl.script, then runs it when each interpreter is updated or created) > > 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 :) Kinda bad, indeed, dude! > > 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 :) You spend two hours working on OpenACS documentation and I'll spend two hours working on AOLserver docs, how's that? :) I would love to have time to contribute to AOLserver (well, I did contribute the virtual server additions to ns_cache and did lots of work on the postgres driver once upon a time), but I don't I'm afraid. Lack of time's the only reason, though. > > 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. Yes, that's my thinking, too. An "ns_sync" tthat copies state and "ns_eval" that works as it did in AOLserver3 would probably both be useful. -- 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/
