11
$\begingroup$

I have found that despite Mathematica's numerous updates, each of which have added much functionality, one fundamental issue remains unaddressed: The unresponsiveness of the UI when I make a mistake (specifically, this is in Mac OS X, but the problem may exist in the other OSes). The problem has existed since at least Mathematica 4, and still exists in Mathematica 8.

If, for instance, I define a variable f through a function, and something goes wrong in that function, the error often cascades out of control, and every single bit of code that uses f subsequently will dump out dark orange colored error messages of the form Function::errorname : Error description here. If this is in a loop with thousands of iterations, the UI can be completely unresponsive, even to repeated presses of Command + Period or quitting the kernel via the menubar. Often times, Mathematica will eat up massive amounts of memory when this happens and eventually crash.

I was just wondering if people had a general strategy for avoiding this situation, aside from assiduous error checking at every stage in a program to ensure that outputs are always reasonable. My desired behavior would be to have Mathematica abort its currently-running calculation if even a single error message is produced (unless I turn them off using Off[]), but I have no idea if this is possible without explicit, repeated checks in the code to see if an error message has been thrown. Alternatively, if there is a way to say dump error messages to a file rather than attempting to store their contents within the notebook, that would perhaps avoid the memory overflows that often cause Mathematica to fail.

Does anyone have an ideas on how to alleviate this issue? Thanks!

Edit: One work-around seems to be changing the "KernelMessageAction" option within the MessageOptions folder to "PrintToConsole" instead of just "Print". This dumps the error messages to a separate window. The advantage of doing this is that the window has a "Delete All Messages" button which you can click to clear the messages from memory. I am not sure if this addresses the underlying problem of the UI becoming unresponsive, however.

Improve this question
$\endgroup$
4
  • $\begingroup$ Related: mathematica.stackexchange.com/q/2789/121 $\endgroup$
    – Mr.Wizard
    Commented Mar 22, 2012 at 0:14
  • $\begingroup$ Guillochon, welcome to Mathematica.SE. Please read the question I linked in a comment above, and try the solutions given there. That should at least remove the "eat up massive amounts of memory when this happens and eventually crash" part of your problem, and then this question can focus on what remains. $\endgroup$
    – Mr.Wizard
    Commented Mar 22, 2012 at 0:16
  • $\begingroup$ That question addresses the general concern with the memory usage, however it does not address the fact that the UI becomes unresponsive. In principle, I can wrap whatever I am doing in one of the Constrained functions to at least force Mathematica to Abort its calculation when it crosses some threshold, but I really would prefer to avoid the situation where the UI becomes unresponsive in the first place. One little bit I have found is the "KernelMessageAction" within the options, which allows me to at least dump the error messages to the console instead of the notebook itself. $\endgroup$
    – Guillochon
    Commented Mar 22, 2012 at 0:22
  • $\begingroup$ In many cases it's the memory usage that makes the FrontEnd unresponsive. Preventing mma from getting into swap hell will also prevent UI problems. $\endgroup$
    – Sjoerd C. de Vries
    Commented Mar 30, 2012 at 22:38

2 Answers 2

Reset to default
6
$\begingroup$

The main part of this question has been answered at

How to abort on any message generated?

However, in my mind there remains a very live issue: why should the front end ever crash at all? Its primary job is as a user interface. As such, there is no excuse for it to crash, ever.

By contrast, when I use a terminal program to connect with, say, a Linux console interface, one of my concerns is never that the terminal program itself would crash. Why should it?

Yet the Mathematica front end crashes or hangs several times a day during my work. I use the following sequence of ways to get out of an impending crash:

  1. If one responds quickly, the hangup can usually be stopped with the menu command "Interrupt Evaluation".

  2. If that doesn't work, pressing Cmd+. might halt the computation.

  3. If Cmd+. fails, sometimes it is possible to use the menu command "Quit Kernel".

  4. If I can't quit the kernel, sometimes I can quit Mathematica entirely by using the "Force Quit" command from the Dock.

  5. If "Force Quit" also fails, then I have to go into Activity Monitor and terminate the Mathematica process at the level of the operating system.

Only the last method is certain to work.

This sort of distracting search for the proper panic button is often necessary several times per day when I am working intensively with relatively large objects, such as an image of more than ten megapixels.

I find it very surprising that this glaring problem was not fixed a long time ago.

Improve this answer
$\endgroup$
1
  • $\begingroup$ FWIW, "interrupt evaluation" has never worked for me in such cases. I guess I am too slow at catching runaway programs. $\endgroup$
    – shrx
    Commented Jul 22, 2015 at 14:12
5
$\begingroup$

One of the significant issues is that the kernel is interruptable, but the UI is not once it begins to render the output. This issue has been there since at least version 3, most likely prior, too, but has improved significantly in recent versions.

That said, I know of only one way around the problem: end every statement with a semi-colon. This necessitates that results of every expression be set to a variable in order to be used, but this is good practice, in general.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.