[Date Index] [Thread Index] [Author Index]
Re: Sending an interrupt to the frontend?
In a case like the one you describe, which happens to me two or three times a day when using Mathematica, I first try the Interrupt command in the Evaluate Menu. This is by far the best option... if it works -- which is about 40% of the time. Next comes Quit Kernel, again in the Evaluation menu. Unless the Mac has run out of free RAM, this almost always works. (To monitor memory usage, I always keep the Mac's Activity Monitor program open and set it to display a RAM pie chart, of which the green segment indicates free memory). I currently have 8G RAM and plan to upgrade to 16G in the near future, which in my case means buying a new Mac -- just to run Mathematica more reliably. If Quit Kernel fails, I have to force-quit Mathematica, generally from the Dock. The easiest way to do this is with a right mouse click on the Mathematica (which incidentally seems odd to me, because most Macs only have a one-button mouse). To help prevent this annoying chain of events, I have started using a little message handler code patch I modified from one I found, either in this mailing list or at http://mathematica.stackexchange.com, I am not sure which. To use the message handler, put the following at the top of every source file, or include it as part of a startup file: (* Interrupt on Message *) messageHandler = If[Last[#], Interrupt] & ; Internal`AddHandler["Message", messageHandler]; This causes Mathematica to stop whenever it issues any message which you have not suppressed. I strongly recommend always using this during testing and debugging. As far as I know, it carries no performance penalty. I hope this helps! Ralph Dratman On Tue, Jul 10, 2012 at 3:18 AM, James Stein <mathgroup at stein.org> wrote: > > I have experienced the same (or similar) problem. > > For me, it usually occurs unexpectedly, in which case it is likely that I > have not recently saved the notebook(s) before the evaluation that goes > awry. After pressing command-period and the menu item "Quit Kernel" > repeatedly, to no effect, it seems there is no escape except the Macintosh > "Force Quit" Mathematica, which is always irritating because of the lost > work and time. > > With years of software experience, I understand why efficient computational > loops cannot be monitoring a flag or looking for an interrupt; nevertheless > it would be nice to have a mechanism to stop the kernel without stopping > the FrontEnd. This would -- I think -- resolve an occasional situtation I > experience where the Kernel is outputting information faster than the > FrontEnd can format and display it -- so the FrontEnd seems too busy to > accept an interrupt and the BackEnd (Kernel) seems unstoppable except via > the FrontEnd. > > Am I understanding the situation? Perhaps not... > > > > On Mon, Jul 9, 2012 at 9:40 PM, W Craig Carter <ccarter at mit.edu> wrote: > >> >> Hello Mathgroup, >> >> This is a question about frozen frontend behavior. >> >> In development stages, one of my frequent mistakes is to send the >> frontend something that takes forever to dynamically update---at least >> that is what I believe what is happening for most of the "freezing" >> occurrences. For MacOs, this is often signaled by a "Formatting >> Notebook Contents" window. >> >> I wonder if anyone has found a method to send the front end a message to >> stop dynamically updating while in an unresponsive state? I've various >> versions of kill -s signal (i.e., signal = INT) from a terminal in >> MacOSx, but never with success. >> >> I suppose that having the front end query the operating system for >> interrupt requests would create a lot of overhead. However, I wonder if >> a method to force the frontend to make an operating system query with a >> user-specified time interval might be possible? >> >> W Craig Carter >>