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

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

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
>
>