Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

Am 19.08.13 15:55, schrieb David Osborne: > It still looks to me like something unintended is happening > internally. However, the clock code handles the error and falls back > to returning the correct result. So it may well be deemed as working > as designed! i guess we to assume this. we don'

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

Hi Gustaf, Ah yes, as we discussed before, using :localtime will not throw a hard error. But the same error is occurring under the covers - but but the clock code catches it, and falls back to using :localtime. If I change clock_test to examine and output ::errorInfo and ::tcl::clock::CachedSyste

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

David, Hmm, i guess you are using in clock_test still ns_log Notice [clock format [clock scan now] -format "%Y-%m-%d %H:%M:%S" -timezone :Tcl/Localtime] ...rather than ns_log Notice [clock format [clock scan now] -format "%Y-%m-%d %H:%M:%S" -timezone :localtime] The first one is not

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

Hi Gustaf, I made a build from current tip and retested as per the testing scenario you specified previously (/usr/local/ns/bin/nsd -c -u nsadmin -t /usr/local/ns/conf/nsd-config.tcl with the clock_test proc included as a module), and still see the error: % ns_schedule_proc -once 0 clock_test 1 %

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

Hi David, Jeffs commit with the ensemble-serializer has changed the situation of ::clock https://bitbucket.org/naviserver/naviserver/commits/10bf51a04b2fd746a871d2ef13b75a87a7101f6f This change adds an ensembles-create-commands to the blueprint for commands, which might refer to the ::tcl::*

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

Am 10.07.13 15:01, schrieb David Osborne: On 8 July 2013 17:16, Gustaf Neumann > wrote: The problem is not only the caches (otherwise it would have been sufficient to exclude the ::tcl::* namespaces from the blueprint), but also the definition of proc "cloc

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

On 8 July 2013 17:16, Gustaf Neumann wrote: > The problem is not only the caches (otherwise it would have been > sufficient to exclude the ::tcl::* namespaces from the blueprint), but > also the definition of proc "clock", which redefines itself in terms of > an ensemble. This makes it sensitive

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

Am 08.07.13 21:12, schrieb Jeff Rogers: > Sheer luck is definitely a possibility, what i called "luck" was the random order of entries as returned from the hash tables during serialization. > but also naviserver is missing > the ensemble serialization that aolserver has, so things defined (or > red

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

Gustaf Neumann wrote: > also the definition of proc "clock", which redefines itself in terms of > an ensemble. This makes it sensitive to the definition order. >> I notice the same test case doesn't raise an error in Aolserver. Seems >> after a ns_eval the ::tcl::clock:: vars left not populated

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

Am 08.07.13 15:21, schrieb David Osborne: > That certainly does the trick. Thanks. > > What's your opinion. Could this be considered a bug in Tcl? > Would seem a lot cleaner if ::clock::Initialize just ran > ::tcl::clock::ClearCaches before initialising the TZData array which > would allow ::tcl:

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

That certainly does the trick. Thanks. What's your opinion. Could this be considered a bug in Tcl? Would seem a lot cleaner if ::clock::Initialize just ran ::tcl::clock::ClearCaches before initialising the TZData array which would allow ::tcl::clock::Initalize to run multiple times. I notice the

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

Dear David, Now we exclude proc ::clock from the blueprint and this should solve this issue. By doing so, we are loosing some flexibility (namely to overload ::clock with a tailored version), but i think we can live with this. Please try again -gustaf neumann PS: Not sure, why ::clock is defi

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

Thanks again Gustaf, Have done what you suggested (a little downlevel): % info patchlevel 8.5.8 % ns_info patchlevel 4.99.5 And, yes, running on the main thread there is no problem % clock_test [05/Jul/2013:14:45:38][12827.7f1ea56ba700][-command-] Notice: 2013-07-05 14:45:38 true % ns_eval expr

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

Hi David, strange, the indicated modification did make the change for me (first broken as described in your email, and now fine). Can it be, that your installation is "manually" sourcing some tcl init files (such as clock.tcl)? Please try the following: - use a default configuration of naviserv

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

Thanks Gustaf. Makes sense. I can see how that change keeps the explicit calls to namespace eval ::tcl* out of the statescript. But in this case it doesn't resolve the problem for us. The clock::Initalization scripts still ends up being called after an ns_eval, and ::tcl::clock::CachedSystemTimeZ

Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

Hi David, tricky thing: naviserver collects in its blueprint all defined namepaces. With Tcl 8.5, several built-in commands went from C to scripted Tcl, such as the implementation of clock. Tcl uses the ::tcl namespace for that. It seems, as if the blueprint of Tcl (including ::tcl::* variables a