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.
Am 05.07.13 16:04, schrieb David Osborne:
Thanks again Gustaf,
Have done what you suggested (a little downlevel):
% info patchlevel
8.5.8
% ns_info patchlevel
4.99.5
And, yes, running on the main thread there is no problem
% clock_test
[05/Jul/2013:14:45:38][12827.7f1ea56ba700][-command-] Notice:
2013-07-05 14:45:38
true
% ns_eval expr {1+1}
2
% [05/Jul/2013:14:45:48][12827.7f1ea1a82700][-ns_job_0-] Notice:
Starting thread: -ns_job_0-
% clock_test
[05/Jul/2013:14:45:56][12827.7f1ea56ba700][-command-] Notice:
2013-07-05 14:45:56
true
But if I try to run the proc on a different thread, the issue is present:
% ns_schedule_proc -once 0 clock_test
1
% [05/Jul/2013:14:46:23][12827.7f1ea2418700][-sched-] Notice:
2013-07-05 14:46:23
% ns_eval expr {1+1}
2
% ns_schedule_proc -once 0 clock_test
2
% [05/Jul/2013:14:46:36][12827.7f1ea2418700][-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 5)
invoked from within
"clock_test"
while executing callback
ns:tclschedproc clock_test
--
David Osborne
On 5 July 2013 13:52, Gustaf Neumann <neum...@wu.ac.at
<mailto:neum...@wu.ac.at>> wrote:
Hi David,
strange, the indicated modification did make the change for me
(first broken as described in your email, and now fine).
Can it be, that your installation is "manually" sourcing
some tcl init files (such as clock.tcl)?
Please try the following:
- use a default configuration of naviserver, e.g. in /usr/local/ns
- copy osborne-procs.tcl to
/usr/local/ns/modules/tcl/osborne-procs.tcl
where osborne-procs.tcl contains just the proc clock_test
from your last email.
- use the sample config as distributed with naviserver
/usr/local/ns/bin/nsd -c -u nsadmin -t
/usr/local/ns/conf/nsd-config.tcl
$ /usr/local/ns/bin/nsd -c -u nsadmin -t /usr/local/ns/conf/nsd-config.tcl
...
%
% clock_test
[05/Jul/2013:14:35:11][75910.101873000][-command-] Notice: 2013-07-05
14:35:11
true
% ns_eval expr {2+1}
3
% [05/Jul/2013:14:35:34][75910.101924000][-ns_job_0-] Notice: Starting
thread: -ns_job_0-
% clock_test
[05/Jul/2013:14:35:42][75910.101873000][-command-] Notice: 2013-07-05
14:35:42
true
% ns_eval expr {2+1}
3
% clock_test
[05/Jul/2013:14:36:27][75910.101873000][-command-] Notice: 2013-07-05
14:36:27
true
% set tcl_patchLevel
8.5.13
% ns_info patchlevel
4.99.6
We can certainly define a blacklist to avoid including e.g. "proc
clock"
in the blueprint, but first i want to understand that this is
really necessary.
as you can see, i am using on my notebook slightly newer versions,
but i doubt this makes a difference
-gustaf
Am 05.07.13 12:51, schrieb David Osborne:
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
<mailto: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
