Question

在我们的某个NaviServer / OpenACS实例中，我们经常遇到以下错误。重新启动后，错误消失了，但会重新出现（在我尚未理解的情况下）。在我看来，好像某些代码会搞乱消息目录或clock.tcl实现使用/看到的语言环境。但是，我不确定如何最好地调试。

expected integer but got "GREGORIAN_CHANGE_DATE"
    while executing
"GetDateFields $clockval  $TZData($timezone)  GREGORIAN_CHANGE_DATE"
    (procedure "::tcl::clock::formatproc'%Y-%m-%dT%H\:%M\:%SZ'c" line 4)
    invoked from within
"$procName $clockval $timezone"
    (procedure "::tcl::clock::format" line 34)
    invoked from within
"clock format [clock seconds] -timezone :UTC -format %Y-%m-%dT%H:%M:%SZ"

非常感谢任何想法！

Answer 1

既然你提到问题有时会发生，那就会敲响一声。问题可能是由NaviServer / AOLserver蓝图中的命令顺序引起的，该命令最终取决于哈希表中不可预测的顺序。我在2018-06-14 12:00 +0200 #1上提交给NaviServer源代码存储库的更改可能可以避免此问题，因为它排除了来自蓝图的:: tcl命名空间中的所有内容。它的缺点是，如果用户在:: tcl命名空间中添加内容，则不会将其包含在蓝图中....但是用户不应该这样做。

背景：NaviServer蓝图中的序列化顺序取决于从哈希表获得的（不稳定）顺序上的纯Tcl代码，因此它可能并不总是相同。如果msgcat和clock以任意顺序加载，那么这些组件的初始化可能会混淆。

Answer 2

我猜你的鼻子朝向正确的方向：

% package req msgcat
1.6.1
% ::msgcat::mclocale
de_at
% ::msgcat::mcset [::msgcat::mclocale] GREGORIAN_CHANGE_DATE 2299527 
2299527
% ::msgcat::mc GREGORIAN_CHANGE_DATE
2299527
% msgcat::mclocale dummy_locale
dummy_locale
% ::msgcat::mc GREGORIAN_CHANGE_DATE
GREGORIAN_CHANGE_DATE

但是，msgcat::mclocale似乎被“损坏”，因为没有匹配的GREGORIAN_CHANGE_DATE商品。或者，命名空间上下文可能会受到影响（在NaviServer蓝图中并非不可能）。但是，您需要在失败之前首先跟踪[msgcat::mclocale]的输出（如之前的评论中所述）。更不可能的是，在某些（实际）区域设置中，日历转换尚未完成，并且在clock.tcl中缺失;）

Answer 3

这可能对您有用：

set milliseconds [clock clicks]
variable time [format "%s_%03d" [clock format [clock seconds] -format %Y%m%d_%H%M%S] [expr {$milliseconds % 1000}] ]

puts $time

如何在clock.tcl中调试Tcl 8.6错误

3 个答案: