Re: [MACTCL] How to move forward with Tk-Cocoa event loop issues

[Adrian R. <adr...@gm...>]

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