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 <neum...@wu.ac.at> 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 <neum...@wu.ac.at> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> naviserver-devel mailing list
> naviserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
