From: Russell E. O. <ro...@ce...> - 2008-02-26 00:35:32
|
In article <47C...@ac...>, Jeff Hobbs <je...@ac...> wrote: > Kevin Walzer wrote: > > Jeff Hobbs wrote: > >> No, currently ActiveTcl goes to the effort of _not_ overwriting the > >> native OS X version. However, that may change in the future, as the > >> ActiveState one is binary compatible, and much more recent. > > > > Does this mean that ActiveTcl would install in /usr/bin and > > /System/Library? > > Yes and no. It would move aside (not remove) the /usr/bin binaries and > install frameworks and extensions, as always, in /Library. > > > That's a Bad Thing (TM). Apple strongly discourages the use of these > > directories by third-party developers. As others have noted, Apple > > updates might break your installation. It's also possible that ActiveTcl > > might break something unexpected, such as another program that depends > > on Apple-installed bits in those locations. (i.e. Apple's system > > installation of Python depends on Tk 8.4 for GUI apps, and will break if > > those binaries are updated to 8.5). > > You do realize that Daniel's installer replaces the core Apple binaries > in the way I suggest above? This would not affect something like > Python, as it would still have 8.4 libraries to link to, just newer ones > (or even the older ones, if that's hard-coded somehow). I can't speak to Daniel's installers. I very much like the way the current ActiveState Tcl/Tk installer works except for one thing: it appears that add-on packages go in the same directory for built in Tcl/Tk, the add-on Tcl/Tk 8.4 (and perhaps even 8.5?). On that score I prefer Python's installer; it keeps add-on packages in a directory that is separate for system vs add-on Python and for each major revision of Python. > > The current method of putting third-party Tcl installations in > > /Library/Frameworks and /usr/local/bin is very sane, and I see no need > > to change it. Making sure that you are getting ActiveTcl is a simple > > matter of making sure your PATH points to /usr/local before /usr/bin. > > and this is something we note, but does surprise some users. In > addition, consider the further implications of things like the security > fix for GIF handling in Tk 8.4.18. Why expose users unnecessarily? > > FWIW, I find the arguments so far weak on a couple of key points. > > 1. DAS's installer does this, and I'm not aware of pushback. > 2. Tcl is more compatible across installs and versions that most (all?) > other dynamic scripting languages. Interesting you should say that. I use Python as my main scripting language and I've found it much more compatible and reliable across installs than Tcl/Tk. (That said, the issues are probably mostly in Tk, not Tcl, and GUI libraries are very complicated so perhaps this is not surprising. Keeping that in mind...) I don't want to sound ungrateful, but MacOS X Tcl/Tk has had serious bugs for *years* that cause major problems for my application. Unfortunately I don't have the knowledge to do more than report bugs (I don't even really program in Tcl/Tk beyond learning just enough to report bugs, I just use it as a GUI front end). Worse, new versions of Tcl/Tk sometimes introduce nasty new bugs even as old ones are fixed. In fact I have not found a single version of Tcl/Tk that I can use reliably for my application that works on MacOS X 10.3.9 through 10.5! (Though 8.4.11 is pretty good on MacOS X 10.3.9 and 10.4; but not on 10.5). The worst problems for me are: * The mouse position is often lost in version of Tcl/Tk before 8.4.15 or so. This causes problems with pop-up menus appear in weird locations and click-based guider corrections being bizarrely wrong. 8.4.11 was the sole exception -- it rarely showed this serious problem. * 8.4.15 introduces a very large memory leak in the Text widget (still not fixed in 8.4.18; it works in 8.5 so it seems unlikely it will be fixed at all in the 8.4 series) * As of 8.4.14 the geometry reported for toplevels on MacOS X 10.3.9 (and only 10.3.9) is usually dead wrong (as in size=0 by 0). This breaks my code that restores toplevels to their saved position and size. * Widgets randomly don't show up on 10.5 (this is the only one I haven't reported; I haven't used 10.5 enough to pin down what is going on and on which versions of Tcl/Tk). Meanwhile Tcl/Tk 8.5 is not fully compatible with Python. Again, I don't want to sound ungrateful; Tk provides an amazing and lovely set of widgets and it's free. And 8.5 introduces fixes the most serious bugs I know of. Pity I can't use it yet. Compare that to Python itself: - My application has had NO bugs attributable to Python in all the years I have worked on it. Python has bugs, but I've just never personally stumbled on one. Again, I realize that some of this is due to the fact that GUI libraries are much more complex than other kinds of software; Tcl may be just as bug free as Python. - My application has had exactly one backwards compatibility issue on Python in all those years (a library I was (ab)using went away for good reasons). That is a remarkable record because the language has seen very significant evolution in that time (addition of generators and iterators, generator expressions, bools, function decorators, the with statement...). So I am grateful for Tcl/Tk but also frustrated at times. I really, really would like to find a version that I could use without known serious issues! I'm also very grateful for the ActiveState installers... My vote is to leave the ActiveState installer the way it is. I find it works perfectly, and is easy to back out if necessary (as it often is). Whatever you do please don't touch the system Tcl/Tk (not even to move it out of the way). That is a "no no" on Macs for a good reason. It's too dangerous! -- Russell |