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

[David O. <da...@qc...>]

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::CachedSystemTimeZone after the calls to clock (using
-timezone :localtime) you can see the same thing happened:

ns_schedule_proc -once 0 clock_test
1
% 2013-08-19 14:51:00
CachedSystemTimezone = :Tcl/Localtime
ns_eval {expr 1+1}
2
% [19/Aug/2013:14:51:32][16319.7fad07e38700][-ns_job_0-] Notice: Starting
thread: -ns_job_0-
ns_schedule_proc -once 0 clock_test
2
% 2013-08-19 14:51:37
CachedSystemTimezone = :Tcl/Localtime
time zone ":Tcl/Localtime" not found
    while executing
"SetupTimeZone $timezone"

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!



On 19 August 2013 13:03, Gustaf Neumann <ne...@wu...> wrote:

>  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 documented, the second one is.
> http://www.tcl.tk/man/tcl8.5/TclCmd/clock.htm
>
> At least, i can't reproduce the problem with :localtime, all the
> invocation patterns work fine for me.
> Do you still get same errors, when using ":localtime"?
>
>
> all the best
> -gustaf neumann
>
>
> Am 19.08.13 12:57, schrieb David Osborne:
>
>  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
> % 2013-08-19 11:35:33
> ns_eval expr {1+1}
> 2
> % [19/Aug/2013:11:35:40][16030.7fb130f43700][-ns_job_0-] Notice: Starting
> thread: -ns_job_0-
> ns_schedule_proc -once 0 clock_test
> 2
> % [19/Aug/2013:11:35:46][16030.7fb1318d9700][-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 2)
>     invoked from within
> "clock_test"
>     while executing callback
> ns:tclschedproc clock_test
>
> % info patchlevel
> 8.5.8
> % ns_info patchlevel
> 4.99.6
>
>
>
>
> --
> David
>
>
> On 16 August 2013 18:51, Gustaf Neumann <ne...@wu...> wrote:
>
>>  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::* namespace. This can happen for
>> ensembles in arbitrary namespaces, such as for ::info, ::string etc. If one
>> of the implementation subcommands is in ::tcl::*, we have a problem, when
>> at the time of the ensemble-recreation (in the blueprint) the subcommand is
>> not defined.
>>
>> It had now a similar problem as in your case with the current code, while
>> testing with a relative small blueprint, where suddenly "clock scan"
>> stopped working. The ::clock ensemble was loaded correctly, but the
>> underlying ::tcl::clock::scan not. It seems, at least for ::clock, we have
>> either to omit both, ::clock (the proc or ensemble) and ::tcl::* namespace,
>> or include both. Just omitting just ::tcl::* can cause harm.
>>
>> By including the ::tcl::* namespace again in the blueprint, these
>> problems are gone (commited just now).
>> Can you please recheck your problem case with clock with the current
>> code; in my testing, it works fine.
>>
>> Many thanks and all the best
>> -gustaf
>>
>>
>
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> naviserver-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
>
>
> --
> Univ.Prof. Dr. Gustaf Neumann
> Institute of Information Systems and New Media
> WU Vienna
> Augasse 2-6, A-1090 Vienna, AUSTRIA
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
>


-- 
David Osborne
Qcode Software Limited
http://www.qcode.co.uk
T: +44 (0)131 208 0151