---
otcl-1.14 Released Sat Oct 29 2011
(Major change is to update for tcl-8.5 changes, contributed from Amir
Habibi (habibi@uci.edu)) TCL 8.5.3 has several fundamental internal and
API changes that render OTCL's use of its low level data structures and
API syntactically and semnatically incompatible. The major changes are:
* Variables are kept in a new internal hashtable type named
VarInHash. Majority of hashtable API functions do not take this
into consideration and lead to segmentation faults. Unfortunately
majority of the potential API functions are defined as static in
original TCL code under generic/tclVar.c and we have to redefine
them in OTCL code.
CallFrame.varTablePtr doesn't any longer refer to a string based
hashtable. The new type is TclVarHashtable that encapsulates a
VarInHash type hashtable (table) along with a namespace
(nsPtr). It doesn't need to be initialized as TCL engin will
allocate it if a local variable is to be defined.
+ Commands are parsed into object-based and string-based
functions in Tcl_CmdInfo and clientData is not any longer
guaranteed to be iof (Proc *) type.
Changes made in otcl1-13 to make it compatible with TCL 8.5.3 and
hopefully later versions are as follows: (Referenced line numbers
are with regards to the new version)
+ 0059-0064: Modified to reflect the change in the CallFrame. it
also defines TCL_VERSION_8_5_OR_HIGHER to simplify changes.
+ 0069-0083: Define few Tcl_xxx macros to make the changes as
clean as possible. These macros are defined for pre and post
TCL 8.5.3
+ 0587-0597: AddMethod is supposed to keep a copy of a
Tcl_CmdInfo data structure after TCL engine has parsed the tcl
code. ocd input argument is addded to the prototype to deal
with object-based ClientData or the (Proc *) of the tcl
procedure. For internal Object and Class objects only
string-based information is needed by OTCL. Based on this
change, calls to AddMethod in the following lines are
modified: 1418-1423, 1845-1849, 1945, 1954
+ 0609-0612: Apparently TCL calls the delete function on the
Tcl_CmdInfo and we don't need to call it again otherwise glibc
panics b/c of double free call on the same pointer. (I didn't
dig into this one and my fix may cause a memory leak)
+ 0732-0737: ListKeys is used for dumping keys in all hashtables
and since the variables has is no longer a string hash, this
functions is slightly modified to reflect this change. Since
TCL doesn't make VarHash related functions available to
public, we can't automatically recognize a VarInHash type and
I resorted to adding a new input argument, isVarHash, to
explicitly pass the flag to this function. Based on this
change, calls to Listkeys in the following lines are modified:
1372, 1388, 1804
+ 0784: Modified to reflect object-based versus string-based
functions use of clientData and objClientData in Tcl_CmdInfo
respectively.
+ 0920: VarTablePtr doesn't need to be initialized in TCL 8.5.3
and the call to Tcl_InitHashTable for older versions is added
to Tcl_VarHashInitilize macro.
+ 0949-0952: Modified to initialize additional fields in
CallFrame.
+ 1004: Modified to cover the cases where varTablePtr remains
null during the lifetime of the object.
+ 1008-1015: Modified to reflect changes in varTablePtr
+ 1021-1035: This block of code is no longer needed as in TCL
8.5.3 hPtr is removed Var structure and instead VarInHash
encapsualtes Var and Tcl_HashEntry. (This may need further
investigation !!!)
+ 1036-137: Modified to cover the cases where varTablePtr
remains null during the lifetime of the object.
+ 1069-1071: Modified to use macros that deal with different
ways of initialization of varTablePtr in TCL 8.5.3 and older
versions.
+ 1208-1210: Modified to use macros that deal with different
ways of initialization of varTablePtr in TCL 8.5.3 and older
versions.
+ 1211: Modified to clarify the assignment. This is not related
to changes for TCL 8.5.3
06aaeb9678