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
