That certainly does the trick. Thanks.
What's your opinion. Could this be considered a bug in Tcl?
Would seem a lot cleaner if ::clock::Initialize just ran
::tcl::clock::ClearCaches before initialising the TZData array which would
allow ::tcl::clock::Initalize to run multiple times.
I notice the same test case doesn't raise an error in Aolserver. Seems
after a ns_eval the ::tcl::clock:: vars left not populated so
::tcl::clock::Initialize runs cleanly. Couldn't ascertain from my limited
understanding of the internals why it should be different.
--
David Osborne
On 5 July 2013 19:19, Gustaf Neumann <neum...@wu.ac.at> wrote:
> Dear David,
>
> Now we exclude proc ::clock from the blueprint and this should solve this
> issue.
> By doing so, we are loosing some flexibility (namely to overload ::clock
> with a tailored version), but i think we can live with this.
>
> Please try again
> -gustaf neumann
>
> PS: Not sure, why ::clock is defined so wierd by Tcl.
>
------------------------------------------------------------------------------
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
