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

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

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 defined so wierd by Tcl.

Am 05.07.13 16:04, schrieb David Osborne:
> 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 {1+1}
> 2
> % [05/Jul/2013:14:45:48][12827.7f1ea1a82700][-ns_job_0-] Notice: 
> Starting thread: -ns_job_0-
>
> % clock_test
> [05/Jul/2013:14:45:56][12827.7f1ea56ba700][-command-] Notice: 
> 2013-07-05 14:45:56
> true
>
>
> But if I try to run the proc on a different thread, the issue is present:
>
> % ns_schedule_proc -once 0 clock_test
> 1
> % [05/Jul/2013:14:46:23][12827.7f1ea2418700][-sched-] Notice: 
> 2013-07-05 14:46:23
>
> % ns_eval expr {1+1}
> 2
> % ns_schedule_proc -once 0 clock_test
> 2
> % [05/Jul/2013:14:46:36][12827.7f1ea2418700][-sched-] Error: time zone 
> ":Tcl/Localtime" not found
> time zone ":Tcl/Localtime" not found
>     while executing
> "return -options $opts $retval"
>     (procedure "::tcl::clock::format" line 18)
>     invoked from within
> "clock format [clock scan now] -format "%Y-%m-%d %H:%M:%S" -timezone 
> :Tcl/Localtime"
>     (procedure "clock_test" line 5)
>     invoked from within
> "clock_test"
>     while executing callback
> ns:tclschedproc clock_test
>
>
> -- 
> David Osborne
>
>
> On 5 July 2013 13:52, Gustaf Neumann <ne...@wu... 
> <mailto:ne...@wu...>> wrote:
>
>     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
>>
>>