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 <neum...@wu.ac.at
<mailto:neum...@wu.ac.at>> 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
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
