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

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

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

Am 10.07.13 15:01, schrieb David Osborne:
>
> On 8 July 2013 17:16, Gustaf Neumann <ne...@wu... 
> <mailto:ne...@wu...>> wrote:
>
>     The problem is not only the caches (otherwise it would have been
>     sufficient to exclude the ::tcl::* namespaces from the blueprint), but
>     also the definition of proc "clock", which redefines itself in
>     terms of
>     an ensemble. This makes it sensitive to the definition order.
>
>
> So should the exclusion of ::tcl from the blueprint mean there should 
> be no ::tcl::clock variables defined from the previous invocations of 
> ::tcl::clock commands in the interpreter after an ns_eval?
>
>
>     Btw, my impression is that when ":localtime" is used instead of
>     ":Tcl/Localtime" ....
>
>     proc clock_test {} {
>          ns_log Notice [clock format [clock scan now] -format
>     "%Y-%m-%d %H:%M:%S" -timezone :localtime]
>          return true
>     }
>
>     ... then everything is fine even when we do not exclude "proc clock"
>     from the blueprint. Can you check this?
>
>
> Yes. It's very easy to work around the error.
>
> If you call "clock format" with no timezone option at all, the same 
> error happens but is wrapped in a "catch".
> The timezone is defaulted to :Tcl/Localtime. This is set as 
> CachedSystemTimeZone. After a ns_eval, the clock code tries to lookup 
> :Tcl/Localtime in TZData, it's not there so it marks it as a 
> BadTimeZone. The difference is that it then proceeds to fall back to 
> using :localtime instead. But :Tcl/Localtime is still flagged as a 
> BadTimeZone.
>
> So we can operationally get round this. We were just concerned it was 
> exposing a bug.
> Whether or not it needs fixing, is definitely debatable!
>
> -- 
> David Osborne
>