From: Gustaf N. <ne...@wu...> - 2013-07-08 19:44:09
|
Am 08.07.13 21:12, schrieb Jeff Rogers: > Sheer luck is definitely a possibility, what i called "luck" was the random order of entries as returned from the hash tables during serialization. > but also naviserver is missing > the ensemble serialization that aolserver has, so things defined (or > redefined) as ensembles would get lost. good catch. this is certainly needed regardless of the clock discussion. in the clock case, proc clock is defining the ensemble on the fly, 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 }] # Auto-loading stubs for 'clock.tcl' foreach cmd {add format scan} { proc ::tcl::clock::$cmd args { variable TclLibDir source -encoding utf-8 [file join $TclLibDir clock.tcl] return [uplevel 1 [info level 0]] } } return [uplevel 1 [info level 0]] } so a missing ensemble is created by proc clock on the fly. but without proc clock, everything is fine, since tcl-init creates the ensemble and naviserver does not touch it... so the situation is somewhere between tricky and wierd. > I've copied this code over from aolserver. I don't know if it will help > the clock problem, although it is possible clock was the motivating > issue for that code in the first place. > > In aolserver the code is wrapped to prevent it from executing on pre-8.5 > tcl. Is that still needed, or is 8.4 dead enough to have 8.5 as a > default requirement? so far, i have tried to keep non-optional stuff in naviserver tcl 8.4 compatible, but i have stopped testing against 8.4. so, i would not mind if we would require tcl 8.5, but i know there are naviserver + tcl 8.4 installations out there.... -g |