From: <ke...@cr...> - 2005-04-18 14:55:43
|
Miguel and Joe English have been engaging in a dialogue on the Bug Tracker (Tcl Bug 1178805) regarding what assumptions an extension is allowed to make about the internal representation of a Tcl_Obj. I thought it would be better to take the discussion to tcl-core; it is rather an issue of the general principles of Tcl. I rather agree with Miguel that we shouldn't consider 1178805 to be a Tcl bug, strictly speaking. We are dealing here with documentation that goes back to 8.0, and makes much stronger implications about internal representations than we now consider appropriate. With several years of bug-fixing under our belts, I think that it's time (at least in 8.5+) to make changes to the implications in the documents. We have found that it is never safe to go after the internal representation of a Tcl_Obj unless you're intimate with the code that put it there. Since everything is a string, the real implied contract of Tcl_CreateFooObj is to create an object whose eventual string representation will reconstruct the passed Foo if reconverted by Tcl_GetFooFromObj. Despite what the documentation says, there ought to be no implied contract that the internal representation will contain anything in particular. We have had a number of bugs resulting from overstepping these bounds. In particular, the numeric types have been vulnerable; there are a number of places where the Everything Is A String principle gets broken because the code behaves differently for objects that are identical as strings but have different internal representations. Moreover, these bugs have been sufficiently confusing to newcomers that they've led to serious proposals to exploit non-EIAS behaviours - one ill-advised proposal for argument expansion involved creating Tcl_Objs that would have magic properties when they arrived at the execution engine. Assuming that a Tcl_Obj is guaranteed to have a particular internal representation (unless your code put it there) also erodes the performance that we gain from having the internal reps in the first place. One example that was changed fairly recently was that 'doubleObjType' is now never used for an object whose string representation looks like an integer. This change is a speedup for the execution engine, which otherwise, every time that it is evaluating an expression involving impure double arguments, must go back to their string representations to make sure that they aren't integers. There are a number of other corner cases over which we stumble. Bugs 1006626 and 868489 are examples. It is worthy of note that the fix to 868489 also involved giving a Tcl_Obj an unexpectedly wide internal representation. Moving forward, I want to rationalize Tcl's treatment of integers so that they are always stored in a type just big enough to hold them; that is, integers smaller than the square root of the maximum wide-integer value will be stored as narrow ints; integers wider than that will be stored as bignums. (I don't see a compelling reason for a specific wide-int internal representation except as possibly a temporary result of Tcl_SetWideIntObj/Tcl_NewWideIntObj, both of which are documented to store the internal representation exactly as passed.) Again, this proposal will violate any implied contract that any particular operation on a Tcl_Obj will leave the internal rep in a given state. In short, I would like internal representations to be private to Tcl or to the extensions that implement them. An implied contract that any particular internal representation is stored is unwise. -- 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA |
From: Vince D. <vi...@sa...> - 2005-06-09 16:09:34
|
This TIP really doesn't currently contain enough information for it to be judged, IMHO. Can the author please add at least a definitive link to where Tile is documented, and preferably also a summary of the incompatibilities with Tk widgets, and preferably the rationale for those incompatibilities. Some links to the main Wiki pages discussing Tile might also be a good idea. I would be concerned that without a decent debate on all these issues, we'll be stuck with the deficiencies of Tile without having had a chance to even assess or know what those deficiencies are! I expect that some of those deficiencies ought to be rectified before Tile should be distributed with Tk. In particular I recall some very non-Tclish behaviour of the inability to redefine a style without exiting Tk. I expect there are many more such issues -- areas where Tile is slightly backwards incompatible without a good reason. cheers, -- Vince |
From: Donal K. F. <don...@ma...> - 2005-06-09 21:25:49
|
Vince Darley wrote: > This TIP really doesn't currently contain enough information for it to be > judged, IMHO. Can the author please add at least a definitive link to > where Tile is documented, and preferably also a summary of the > incompatibilities with Tk widgets, and preferably the rationale for those > incompatibilities. Some links to the main Wiki pages discussing Tile > might also be a good idea. Sorry for sounding contrary, but "why"? Gooooooooogle finds all... I would like to point out that the TIP merely proposes co-distribution of the Tile package and not the replacement of any Tk widgets with the Tile ones (I've ported a few apps, and often come across cases where converting to Tile was the wrong thing to do for some widgets.) Given that that is all the TIP proposes (plus a little bit of convenience stuff that will help some people without hindering anyone who doesn't poke their noses where they're not wanted), I really don't see your point on incompatibilities; the only problems will be for those people who explicitly take them on. > I would be concerned that without a decent debate on all these issues, > we'll be stuck with the deficiencies of Tile without having had a chance > to even assess or know what those deficiencies are! Have you tried asking on the mailing list? Or googling? Or reading the many threads on the topic in c.l.t over the past year? There has been a lot of discussion of this over many different fora. But summing up the main essence: * Tile widgets use a more sophisticated state model * Tile widgets do not allow direct control over most appearance settings By sacrificing these things, users of Tile widgets gain the considerable advantages of the new styled widgets (i.e. apps that really integrate with users' desktops.) > I expect that some of those deficiencies ought to be rectified before Tile > should be distributed with Tk. In particular I recall some very > non-Tclish behaviour of the inability to redefine a style without exiting > Tk. I expect there are many more such issues -- areas where Tile is > slightly backwards incompatible without a good reason. I would view such a thing as a bug, and therefore not something that would usually come up in this sort of discussion. After all, bugs are there to be fixed, but they are transient things and have little bearing on longer-term packaging and distribution issues (the primary topic of this TIP in my opinion). Donal. |
From: Vince D. <vi...@sa...> - 2005-06-10 08:39:40
|
On Thu, 9 Jun 2005, Donal K. Fellows wrote: [Lots of very sensible comments snipped] > Vince: > > I expect that some of those deficiencies ought to be rectified before Tile > > should be distributed with Tk. In particular I recall some very > > non-Tclish behaviour of the inability to redefine a style without exiting > > Tk. I expect there are many more such issues -- areas where Tile is > > slightly backwards incompatible without a good reason. > > I would view such a thing as a bug, and therefore not something that > would usually come up in this sort of discussion. After all, bugs are > there to be fixed, [...] I totally agree, but when I reported this bug to the Tile project I was told quite clearly that "quit and restart" _was_ considered an acceptable interactive development approach and therefore this bug was invalid. [*] Given this position, I hope you can understand why I'm somewhat more cautious about just giving Tile the stamp of approval as-is, without really understanding what its limitations/incompatibilities are, and which of those are considered 'bugs' and which are not. cheers, Vince. [*] http://sourceforge.net/tracker/index.php?func=detail&aid=1067353&group_id=11464&atid=111464 |
From: Donal K. F. <don...@ma...> - 2005-06-10 09:15:53
|
Vince Darley wrote: > I totally agree, but when I reported this bug to the Tile project I > was told quite clearly that "quit and restart" _was_ considered an > acceptable interactive development approach and therefore this bug was > invalid. [*] > > Given this position, I hope you can understand why I'm somewhat more > cautious about just giving Tile the stamp of approval as-is, without > really understanding what its limitations/incompatibilities are, and which > of those are considered 'bugs' and which are not. > > [*] > http://sf.net/tracker/?func=detail&aid=1067353&group_id=11464&atid=111464 Interesting bug, but having read it in full I'd say that the ability to dynamically modify all those sorts of things would be a feature request (Joe's points are valid, but he's made an anti-karmic decision there. Knowing Joe, I'm sure he's open to people who want to help fix things by writing code.) Where you are wrong though is in saying that the problem you describe in the bug is a show-stopper. The GUI situation is a serious enough structural threat to the long-term viability of Tk[*] (in my opinion, natch) that we *have* to take action in 8.5 to dispel the ugliness myth. Tile is definitely the best (and only) game in town for dealing with this and where it has problems, they should be fixed and not complained about. I'm sorry to argue like this, but at the level that this TIP is pitched at, your complaint does not register at all. It's just not on the map. (Yikes! I remind myself of some layers of management at my employer...) Donal. [* Tcl has other strings in its bow. ] |
From: <geo...@xm...> - 2005-06-11 01:03:25
|
Quoted "Donal K. Fellows" <don...@ma...>: > Where you are wrong though is in saying that the problem you describe in > the bug is a show-stopper. The GUI situation is a serious enough > structural threat to the long-term viability of Tk[*] (in my opinion, > natch) that we *have* to take action in 8.5 to dispel the ugliness myth. > Tile is definitely the best (and only) game in town for dealing with > this and where it has problems, they should be fixed and not complained > about. Not the "only." BLT has had its own tile abilities via the option resource database for its own custom (button/frame/label) widgets for years longer than tile, but for whatever reason it wasn't considered. Are you listening George Howlett? I wish that tile would just remove -fg/-foreground and friends if it's going to ignore them. I know that the argument is that BWidgets uses the ::label/::button (often ::ttk::* is imported into ::) commands to find the widget default colors, but patching tile to work around a BWidgets/general bug is not ideal. We need to fix BWidgets so that it uses some other global state rather than creating widgets to get defaults. I also think we should replace many of the static defaults that Tk widgets are compiled with. This would allow us to use something cleaner, and megawidgets wouldn't need to create temporary widgets. I'm not happy about the lack of at least foreground control for ttk::labels. It makes a big difference in cases where a big label should be red when there is a problem. Surely the Win32 and other platform APIs that Tk uses to draw native widgets can support some kind of control over label color. GPS |
From: <geo...@xm...> - 2005-06-11 01:20:24
|
Quoted Vince Darley <vi...@sa...>: > On Thu, 9 Jun 2005, Donal K. Fellows wrote: > [Lots of very sensible comments snipped] >> Vince: >> > I expect that some of those deficiencies ought to be rectified before Tile >> > should be distributed with Tk. In particular I recall some very >> > non-Tclish behaviour of the inability to redefine a style without exiting >> > Tk. I expect there are many more such issues -- areas where Tile is >> > slightly backwards incompatible without a good reason. > Given this position, I hope you can understand why I'm somewhat more > cautious about just giving Tile the stamp of approval as-is, without > really understanding what its limitations/incompatibilities are, and which > of those are considered 'bugs' and which are not. Not having the ability to redefine a style is problematic. For instance a person could someday create a Tile-style creation program for people that aren't programmers. This could be a case of a situation that is impossible to handle without starting a new wish for each minor style change. It would hurt interactivity in that case. I understand that Tile is complex, and some of the native APIs it uses are too, but it would be nice to allow for dynamic style redefinitions to enable such programs. Some of us also use editors that save and update running processes (via send or comm), so it could be useful in those situations too. GPS |
From: Donal K. F. <don...@ma...> - 2005-06-13 08:11:25
|
GPS wrote: > Not having the ability to redefine a style is problematic. For > instance a person could someday create a Tile-style creation program > for people that aren't programmers. This could be a case of a > situation that is impossible to handle without starting a new wish > for each minor style change. It would hurt interactivity in that > case. I understand that Tile is complex, and some of the native APIs > it uses are too, but it would be nice to allow for dynamic style > redefinitions to enable such programs. Some of us also use editors > that save and update running processes (via send or comm), so it > could be useful in those situations too. You're right that style redefinition is a highly desirable feature. But should the fact that it is not there *now* indicate that Tile should not be distributed with Tk starting with 8.5; that's 6 months away (says I in a wholly optimistic and not-justified-by-any-evidence way). I don't think so; at the strategic level, we need to start planning for the inclusion of Tile now, but the lead time on any action is enough that even significant missing features can be added with plenty of time. Or at least that's the way I (and I believe other TCTers) call it. Donal. |