From: Kevin W. <kw...@co...> - 2012-10-02 02:13:09
|
Hi all, I just closed bug #3028676 (https://sourceforge.net/tracker/index.php?func=detail&aid=3028676&group_id=12997&atid=112997). This is my reference bug for the Tk-Cocoa event loop issues, because Lars Hellström (the OP) did a lot of investigating to isolate the source of the problem, and Daniel Steffen (das, the author of the Tk-Cocoa port) added some very useful points about his design intent. Let me quote from my comments there: --- Adding an "update" command to the core procedure in the sample script sidesteps the problem entirely. I realize that this script was put together to assemble the core issue, that is, incoming Tcl events overloading the Cocoa/Tk event loop and causing it to lock up, but the fact is that careful management of the event loop with occasional workarounds like "update" or "after" can avoid many of the issues that are commonly reported. I've spent a lot of time reading both das's code and the relevant docs (Tcl and CoreFoundation), and given the complexity of the task, I've concluded that the current implementation is good enough, albeit far from optimal. das had previously committed a significant update to the notifier, see https://sourceforge.net/mailarchive/message.php?msg_id=23324050, that addressed truly showstopper issues with its performance. Now it is slow and pone to occasional lockups, but in most cases these can be worked around. I seldom see any issues with the event loop in my own applications because I work around the most common issues; it's been a long time since I've had a user complaint about a lockup because of event loop issues. It seems clear that the Tk/Cocoa event loop is slower, more fragile, and more complex than the Carbon implementation; however, the ultimate responsibility for this lies with Apple's decision to deprecate Carbon and force Cocoa integration. Cocoa has many advantages, but it is not a natural fit for Tk the way that Carbon, which operated at the same low level of abstraction as Tk's C API, was. Therefore, I've decided to close this bug, and will spend a bit of time deciding how to document the limitations of Tk-Cocoa's event loop and best practices for working around them. --- At this point I don't think it's fruitful to try to improve the event loop integration. Frankly, given the enormity of the task, I think the work Daniel Steffen did single-handed on Tk-Cocoa is just amazing, and I'm grateful for his efforts. The event loop code is some of the gnarliest of the source tree, and based on bug reports, Daniel pushed it forward from showstopping slow/crashprone to Barely Good Enough. (That's not faint praise but rather high praise based on the difficulty of the task.) As I say in my comment above, I seldom see event loop issues in my own apps because I simply work around them wherever possible (calls to update, after, update idletasks, etc.). It takes some trial and error, but once I have a working solution, I don't have to revisit it. What I'd like to do, instead, is assemble some best practices. What do you all do to work around these issues? Perhaps we can assemble a thread here, and then post some ideas/code to the wiki. Or somewhere else? The Tk man pages? Or both? I'll start with a common solution in my apps: when an app has a sudden error and throws up an error dialog (via the "bgerror" command), earlier versions of Tk-Cocoa would lock up and prevent the dialog from drawing. My solution was to re-define the "bgerror" command to write errors to the console. (This is actually more useful in my view.) #handle errors in Tk proc bgerror {args} { exec syslog -s -l Error "PacketStream: An error occurred: $args" } This issue has since been fixed, but I stopped worrying about it after finding a viable workaround. Other comments on this issue are appreciated. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Adrian R. <adr...@gm...> - 2012-10-02 11:29:50
|
Hi Kevin, I really appreciate the work you are doing, and I understand wanting to clean up, cut losses, and move on, but I don't think it's good to sweep such bug reports under the rug. We might not have the combination of time and expertise right now to fix these problems, but hopefully sooner or later we will. At that time we'll want as clear descriptions of the issues as possible, and the simplest code available for reproducing them. Closing bugs only makes them less visible and less likely to be found. Duplicates will probably submitted, scattering useful information. Or worse, the "it's as good as it's going to get, we're not going to fix it" message will discourage people from submitting bugs, trying to fix them, or, ultimately, from using Tk at all as a cross-platform solution. I don't object to systematically documenting the best ways for working around Tk-Cocoa's problems, but let's leave open bugs open and put efforts into creating minimal reproduction scripts if nothing else. (Side note, I tried on and off for more than a year to "work around" Tk-Cocoa's bugs, before going the route of altering my application's functionality on the Mac platform to get it out the door.) -Adrian On 2012/10/01, at 22:12, Kevin Walzer <kw...@co...> wrote: > Hi all, > > I just closed bug #3028676 > (https://sourceforge.net/tracker/index.php?func=detail&aid=3028676&group_id=12997&atid=112997). > This is my reference bug for the Tk-Cocoa event loop issues, because > Lars Hellström (the OP) did a lot of investigating to isolate the source > of the problem, and Daniel Steffen (das, the author of the Tk-Cocoa > port) added some very useful points about his design intent. > > Let me quote from my comments there: > > --- > Adding an "update" command to the core procedure in the sample script > sidesteps the problem entirely. > > I realize that this script was put together to assemble the core issue, > that is, incoming Tcl events overloading the Cocoa/Tk event loop and > causing it to lock up, but the fact is that careful management of the event > loop with occasional workarounds like "update" or "after" can avoid many of > the issues that are commonly reported. > > I've spent a lot of time reading both das's code and the relevant docs (Tcl > and CoreFoundation), and given the complexity of the task, I've concluded > that the current implementation is good enough, albeit far from optimal. > das had previously committed a significant update to the notifier, see > https://sourceforge.net/mailarchive/message.php?msg_id=23324050, that > addressed truly showstopper issues with its performance. Now it is slow and > pone to occasional lockups, but in most cases these can be worked around. I > seldom see any issues with the event loop in my own applications because I > work around the most common issues; it's been a long time since I've had a > user complaint about a lockup because of event loop issues. > > It seems clear that the Tk/Cocoa event loop is slower, more fragile, and > more complex than the Carbon implementation; however, the ultimate > responsibility for this lies with Apple's decision to deprecate Carbon and > force Cocoa integration. Cocoa has many advantages, but it is not a natural > fit for Tk the way that Carbon, which operated at the same low level of > abstraction as Tk's C API, was. > > Therefore, I've decided to close this bug, and will spend a bit of time > deciding how to document the limitations of Tk-Cocoa's event loop and best > practices for working around them. > --- > > At this point I don't think it's fruitful to try to improve the event > loop integration. Frankly, given the enormity of the task, I think the > work Daniel Steffen did single-handed on Tk-Cocoa is just amazing, and > I'm grateful for his efforts. The event loop code is some of the > gnarliest of the source tree, and based on bug reports, Daniel pushed it > forward from showstopping slow/crashprone to Barely Good Enough. > (That's not faint praise but rather high praise based on the difficulty > of the task.) As I say in my comment above, I seldom see event loop > issues in my own apps because I simply work around them wherever > possible (calls to update, after, update idletasks, etc.). It takes some > trial and error, but once I have a working solution, I don't have to > revisit it. > > What I'd like to do, instead, is assemble some best practices. What do > you all do to work around these issues? Perhaps we can assemble a thread > here, and then post some ideas/code to the wiki. Or somewhere else? The > Tk man pages? Or both? > > I'll start with a common solution in my apps: when an app has a sudden > error and throws up an error dialog (via the "bgerror" command), earlier > versions of Tk-Cocoa would lock up and prevent the dialog from drawing. > My solution was to re-define the "bgerror" command to write errors to > the console. (This is actually more useful in my view.) > > #handle errors in Tk > proc bgerror {args} { > exec syslog -s -l Error "PacketStream: An error occurred: $args" > } > > This issue has since been fixed, but I stopped worrying about it after > finding a viable workaround. > > Other comments on this issue are appreciated. > > --Kevin > > -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
From: Kevin W. <kw...@co...> - 2012-10-02 14:02:49
|
Hi Adrian, > I really appreciate the work you are doing, and I understand wanting to clean up, cut losses, and move on, but I don't think it's good to sweep such bug reports under the rug. Fair enough. I've re-opened the bug in question so that it will reappear in searches and for comments, but I've left its status as "won't fix" because I'm not persuaded that it is, in fact, fixable. > We might not have the combination of time and expertise right now to fix these problems, but hopefully sooner or later we will. At that time we'll want as clear descriptions of the issues as possible, and the simplest code available for reproducing them. Closing bugs only makes them less visible and less likely to be found. Duplicates will probably submitted, scattering useful information. Or worse, the "it's as good as it's going to get, we're not going to fix it" message will discourage people from submitting bugs, trying to fix them, or, ultimately, from using Tk at all as a cross-platform solution. It is indeed unfortunate that there are only a handful of folks with the combination of time, interest, and expertise to actively work on Tk at a low level. It's understandable, though, because the barrier to entry in terms of expertise is very high: it took me four or five years to develop any competence at all with Tk and Cocoa at the C level. And on the other side, there are other folks in this community with more expertise than me, but with less time and/or interest: they just want Tk to work but don't want to have to dig deeply into its internals. In this regard I am especially grateful to you for the patches you've recently submitted. As far as choosing another cross-platform framework instead of Tk, I also understand this argument, but I choose Tk anyway because it's easier to extend than any other cross-platform framework. Adding Services support, AppleScript support, etc. is comparatively easy in Tk: imagine trying to do something similar with PyQt or wxPython. First you'd have to dig deeply into the C++ library, then you'd have to figure out how to wrap that functionality in the higher-level framework. Doable, but very, very hard, I imagine. It's why I've stayed with Tk despite its problems. It would certainly be wonderful if we got some new blood in the community to work on Tk. One reason I am pessimistic about this is, apart from Tk lacking the "cool factor" and the Mac-specific bugs being a turnoff, Tk's C API is increasingly becoming an undocumented "black art." The best extant resource on Tk's C API that I've seen is Brent Welch's book, which I learned a lot from, but which only goes through Tk 8.4 and is going on ten years old. The recent new edition of Osterhout's book skips over Tk's C API with the assertion that "since so few people work on it, it's not of interest here." Ridiculous. > I don't object to systematically documenting the best ways for working around Tk-Cocoa's problems, but let's leave open bugs open and put efforts into creating minimal reproduction scripts if nothing else. (Side note, I tried on and off for more than a year to "work around" Tk-Cocoa's bugs, before going the route of altering my application's functionality on the Mac platform to get it out the door.) > I'm sorry for the trouble you had with your own app. And yes, I'll leave the bug open. Thanks for the feedback, Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Kevan H. <ha...@br...> - 2012-10-02 15:20:03
|
Dear Kevin, > What I'd like to do, instead, is assemble some best practices. I find your argument convincing. As it is, my applications already have serious problems with the Tcl event loop, and the Tk/Carbon event loop, almost all of which I have worked around by trial and error through insertion of update, update idletasks, vwaits and after commands. These commands do not, in my experience, do exactly what the TclTk documentation tells me they should do, but they almost always seem to fix the problem. Every now and then, however, there comes an event-loop problem that I can't fix. The screen freezes during TCPIP communication, for example, and these I have submitted as bug reports and they have been fixed. So I imagine that the same thing will happen with the Tk/Cocoa event loop. If we have a list of best practices, then people like you, who end up doing the bug fixes, can first point to this list before you spend your time looking into something that is supposed to be a bug. Thus I think this list of best practices is a good idea, and I accept the compromise you propose. From your subsequent answer to Adrian: > And on > the other side, there are other folks in this community with more > expertise than me, but with less time and/or interest: they just want > Tk to work but don't want to have to dig deeply into its internals. Yup, that's me. You are maintaining this code and also using it yourself. Looking at your portfolio of applications, it seems to me that you are firmly invested in TclTk on the Mac. Your investment gives your proposal a guarantee in my mind. Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/ |