Re: making something autoexecute before normal execution
- To: mathgroup at smc.vnet.net
- Subject: [mg116916] Re: making something autoexecute before normal execution
- From: Armand Tamzarian <mike.honeychurch at gmail.com>
- Date: Fri, 4 Mar 2011 03:40:15 -0500 (EST)
- References: <ikns38$jvo$1@smc.vnet.net>
On Mar 3, 9:55 pm, John Fultz <jfu... at wolfram.com> wrote: > On Wed, 2 Mar 2011 04:35:02 -0500 (EST), David Bailey wrote: > > On 01/03/2011 10:25, David Bailey wrote: > > >> However, I find that there are a lot of circumstances in which > >> Mathematica seems frozen - too frozen to quit the kernel via the menu - > >> where it is possible to recover the FrontEnd by killing the kernel > >> process some other way. I have an icon to do this using the Windows > >> taskkill.exe program. Very occasionally this simply crashes the > >> FrontEnd, but I would say it is 95% successful. > > > As an example, execute the following line of code and press the button. > > > Button["Clear",If[ChoiceDialog["Are you sure?"],Print["Doing it"]]] > > > The FrontEnd will hang (for no obvious reason!), but you can recover if > > you kill the kernel as described. > > > David Bailey > >http://www.dbaileyconsultancy.co.uk > > David, I think, already knows this...but for those who don't, the way > to workaround this is to add the option > > Method->"Queued" > > to the Button expression. That totally erases any hangs which might > happen, but it also puts the evaluation in the same queue as Shift+Enter > evaluations, which means it may take a considerable time for the button > to respond if other activities are in the queue. > > The behavior in this case is not merely a minor implementation bug, but > springs from some core design decisions about how to do evaluations in > interfaces (Buttons, Dynamics, EventHandlers) which can interrupt ongoing > kernel evaluations and which should be resolved ASAP. The best that I > can say here is that we continue to think and ponder over these issues. > > As for the original email, if you can reproduce any cases where the FE > is hung or you're unable to kill the kernel, please report them to tech > support. Even in the worst cases of the sort that David describes, the > FE is supposed to wake up after a generous 6 seconds of waiting around > for the kernel to do these sorts of evaluations and clean things up. > If it doesn't, then that's definitely a bug we're interested in. On Mac OS X 10.6.6 running V8 the FE seems to struggle once the notebook size gets say 10MB or greater. By struggle I mean that even attempting simple things like scrolling down the notebook it is only slowly responsive. On occasions when there are some sort of computation errors I'd echo Davids observations and in those cases you cannot quit the kernel, you cannot quit the front end. You're left with hang that either ends by the application crashing or by having to exit it yourself. To be fair I'm talking about my own coding mistakes that have caused the application to "meltdown" but nevertheless I haven't seen a mandatory timeout in those cases. The inability to be able to force a quit of evaluations (the normal key strokes etc. are non responsive) when you see this starting is very frustrating. Mike > > Sincerely, > > John Fultz > jfu... at wolfram.com > User Interface Group > Wolfram Research, Inc.