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

[Gustaf N. <ne...@wu...>]

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 naviserver, e.g. in /usr/local/ns
- copy osborne-procs.tcl to /usr/local/ns/modules/tcl/osborne-procs.tcl
   where osborne-procs.tcl contains just the proc clock_test
   from your last email.
- use the sample config as distributed with naviserver
   /usr/local/ns/bin/nsd -c -u nsadmin -t /usr/local/ns/conf/nsd-config.tcl


$ /usr/local/ns/bin/nsd -c -u nsadmin -t /usr/local/ns/conf/nsd-config.tcl
...
%
% clock_test
[05/Jul/2013:14:35:11][75910.101873000][-command-] Notice: 2013-07-05 14:35:11
true
% ns_eval expr {2+1}
3
% [05/Jul/2013:14:35:34][75910.101924000][-ns_job_0-] Notice: Starting thread: -ns_job_0-
% clock_test
[05/Jul/2013:14:35:42][75910.101873000][-command-] Notice: 2013-07-05 14:35:42
true
%  ns_eval expr {2+1}
3
% clock_test
[05/Jul/2013:14:36:27][75910.101873000][-command-] Notice: 2013-07-05 14:36:27
true

% set tcl_patchLevel
8.5.13
% ns_info patchlevel
4.99.6

We can certainly define a blacklist to avoid including e.g. "proc clock"
in the blueprint, but first i want to understand that this is really 
necessary.

as you can see, i am using on my notebook slightly newer versions,
but i doubt this makes a difference

-gustaf

Am 05.07.13 12:51, schrieb David Osborne:
> 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::CachedSystemTimeZone stays set - hence 
> containing an undefined timezone.
>
> Looking at the statescript that is being saved during ns_eval, could 
> it be something to do with the way the clock ensemble is being declared?
>
> proc clock args {
>     namespace eval ::tcl::clock [list namespace ensemble create 
> -command  [uplevel 1 [list namespace origin [lindex [info level 0] 
> 0]]]  -subcommands {
>             add clicks format microseconds milliseconds scan seconds
>         }]
> ...snip...
>
>
>
> -- 
> David Osborne
>
> On 4 July 2013 21:12, Gustaf Neumann <ne...@wu... 
> <mailto:ne...@wu...>> wrote:
>
>     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
>     and commands) messes up initialization of the ::clock command.
>
>     The easiest fix is not to include the stuff from the ::tcl namespace
>     in the blueprint, since Tcl takes care about this during
>     initialization.
>
>     The fix is quite simple:
>     https://bitbucket.org/naviserver/naviserver/commits/a91fe6050ddba5ae5b42222f6c0dbc36acc004b2
>     you should be able to simply add that line to your 4.99.5
>     installation.
>
>     All the best
>     -gustaf neumann
>
>