See the document A Busy Developer's Guide to Tcl/Tk 8.5 [L1 ] by Mark Roseman.
This topic also came up on comp.lang.tcl, initially in this thread [L2 ].
Some of the responses posted include:
I get (when pressing the exit button) bad variable name "geom(.xtemqd)": upvar won't create a scalar variable that looks like an array element while executing "global [set var]" (procedure "writeVarList2File" line 5) : (followed by more text that I won't quote) :
$ tclsh8.4 % list #123456 #123456 %^D $ tclsh8.5 % list #123456 {#123456} %
While from a Tcl point of view, the two are equivalent, there are coding situations where a string is needed. As always, in Tcl, be certain to specifically use strings and string functions when strings are required, and use list functions and lists where lists are required.
DGP No, they are not equivalent. Tcl 8.4 is buggy. In Tcl 8.5, the bug has been fixed. See TIP 148 [L3 ] for all the details.
PWQ 22 Aug 08, So now when I print out a list of four colour names using #rrggbb notation I can always expect the first colour to be braced and then rest unbraced, thanks for that, that is so much better. I am always wanting to eval comments as lists and I never want to use #rrggbb colour names in lists.
Other wiki pages related to Tcl 8.5 differences
LV 2008-08-21 I have had several developers who have been trying to bring up their Tcl 8.4 applications using Tcl 8.5. While the applications are coming up, the number one complaint that I get is that widgets are coming up with different colors. The primary example I have seen is the code sample I added over on iwidgets while trying to figure out a problem in one of the widgets. Besides the problem with the button placement, under Tcl 8.4, the code there comes up with the listbox having a grey background, but under Tk 8.5 it has a white background.
Is there something simple a developer can do to get this behavior reversed, other than changing lots of lines of code to hard code the color?
JH Use tk::classic::restore, although the new defaults are intended to be a strict improvement for modern UI conventions. This is not considered an incompatibility.
LV There is a minor different in glob in Tcl 8.5. I don't see it mentioned in the changes file and can't put my finger on any specific thing in the ChangeLogs for it. Basically, in Tcl 7.6 through 8.4, glob would normalize a path name, dropping the final slash of a directory name:
$ tclsh8.4 % glob /home/lwv27/ /home/lwv27 % ^D but now $ tclsh8.5 % glob /home/lwv27/ /home/lwv27/ % ^D DGP Bug reports like this belong in the Tracker, not here.
This minor difference actually resulted in a bug report over on [email protected] , where a function called listModules no longer works, because of the unexpected behavior. Look for the thread titled: recent TCL versions break "listModules" due to different "glob" behavior and result in // instead of / as directory-version separator
<rant> PWQ 22 Aug 08, There have been numerous requests for changes to the core that are rejected out of hand because they would make break existing code. However it seems that when the TCT thinks that the change is ok then f*k the existing applications and carry on regardless. Why is it the Application developers burdon to change his code when the Core is Changed? This is all very well for the TCT members who just write 10 line toy examples. When you have 20,000 lines of code to look through and another how much more in other peoples tcl extensions that are no longer in developent, this is just bullshit. Hasnt the TCT learned from the 8.0-8.1 debarkle. The application developer has no control over which version of Tcl is installed by the end user. Can't the TCT put some forward planning into the changes. For example, if an application executes:
package require Tcl 8.4
Then the init code for 8.5 automatically sources compatibility extensions to make the new interpreter function the same as the old 8.4 version. If this means some optimisations and special features are turned of , so be it. The application developer can then choose to upgrade/modify and now has time to adapt the code for these incompatibe changes. </rant>
DKF: The main reason we don't do that is because it is very difficult! When something subtle is changed, it's very hard to evaluate how much third-party code is affected since much code isn't available for public grepping and it's usually not possible to figure out what to search for anyway. And with the subtle stuff, it's often extremely difficult to do code to make things exactly compatible with previous versions (the grossly different stuff such as any extra commands are much simpler; old code should just ignore them). An example of this sort of subtlety is the changes to the font system on X11; it's been terrible for ages (really!) and so we finally got an improvement in to make things get up to the level of support that other platforms had been enjoying for a long time. Unfortunately, it changes what sets of fonts are supported by a system (that's totally outside our control, BTW) and that in turn hits a lot of GUI apps which were tuned to work around the horrible-ness, and which font system is used is a build-time option for Tk.
Similarly, the new ttk widgets aren't drop-in replacements for the old tk ones (and can't be; they're different in detail) so upgrading from old Tk widgets to new Ttk ones depends heavily on the degree of change needed. Unfortunately, it seems that many production Tk apps did heavy tweaking of widget options and as such, face quite a lot of pain going to the new widgets where everything is theme/style based; by contrast, toy scripts mostly "just work". I don't intend to apologize for this, especially as we kept the old widgets around so code can Just Work for the most part.
If you want to discuss the details of downgrading on [package require Tcl 8.4], talk to DGP; his understanding of the issues is more profound than mine.