# How do I clear all user defined symbols?

Is there some way to do this other than going to Evaluation -> Quit kernel and firing a new one up?

-
– Szabolcs Jan 28 '12 at 13:22

Maybe this ?

ClearAll["Global*"]

-
I've had trouble with ClearAll["Global*"] NOT removing definitions in my own packages (.m files) that I'm developing, but that's exactly what I need to do when I am iteratively refining some definitions -- try 'em in a notebook (.nb file), clean 'em out, try 'em again. The CleanSlate solution below works better for me in this scenario. – Reb.Cabin Mar 9 '12 at 21:09
JMO, but it would have been nicer for a simple ClearAll which accomplishes this. – JohnD Nov 24 '12 at 17:41

In the days when computers were slower, and the kernel took a long time to start up (in wall time), a little package was made to help with cleaning up without having to restart the kernel.

This package is still included with Mathematica, and is found in AddOns\ExtraPackages\Utilities\CleanSlate.m (within the Mathematica installation directory). It is more complete than ClearAll["Global*"] in that it also attempts to "unload" packages. The package documentation is within the package file (don't look for it in the help browser, just open that file).

<< UtilitiesCleanSlate


When the function CleanSlate[] is executed, it will attempt to restore the kernel to the state when the package was loaded. (This can't be done perfectly, but it's much faster than a full kernel restart.)

The package also has a ClearInOut[] function which will clear the previous input and outputs stored in the In and Out symbols (useful in case you are running out of memory and forgot to set $HistoryLength = 0 at the beginning). That said, I recommend Quit[] (or Exit[]) for the safest (and complete) kernel reset. It is worth stating explicitly that Mathematica consists of two separate processes: the Front End and the Kernel. The Front End is the GUI (the user interface you see on the screen) while the Kernel does the calculations. The Kernel can be closed and restarted independently of the Front End (also see Evaluation -> Quit Kernel -> Local) It is also possible to assign a keyboard shortcut to quitting the kernel. See here on how to do it. - @Nasser You can check the author and release date in the source. Well, if the kernel is started from the command line, it's pretty much the same: there's no separate process interface. But it's still easy to restart the kernel. – Szabolcs Jan 28 '12 at 15:51 @Szabolcs I've run into a (perhaps) weird behavior of CleanSlate. If i launch sub-kernels, distribute all definitions and evaluate CleanSlate[], then little memory is freed. If instead i evaluate ParallelEvaluate[CleanSlate[]], then much more memory is freed. What's going on? – Valerio Apr 5 '12 at 7:49 @Valerio: I guess the package was not updated for parallel kernels, and therefore only cleans up the kernel it runs on. If you use CleanSlate[] it runs on the main kernel and cleans up that. If you use ParallelEvaluate[CleanSlate[]] it runs on the subkernels and cleans up those. However in the initial state no subkernels are running, therefore running CloseKernels[] before CleanSlate[] probably is the closest to a kernel restart. – celtschk May 24 '12 at 19:12 @celtschk I remember that in v4 times, restarting the kernel could take quite a bit. CleanSlate was a fast alternative. Computers got much faster while the startup time didn't increase that much, so today Quit is probably the most convenient way to clear everything. So it's no wonder that CleanSlate is not maintained any more. – Szabolcs May 24 '12 at 19:35 I use a shortcut key Ctrl+Q for Quit[], allowing rapid clearing of all sessions variables. Here is how you can add this to Mathematica: You will be editing KeyEventTranslations.tr. This is an important system file so be careful. Start by copying the file you are going to edit from the $InstallationDirectory to $UserBaseDirectory in the same tree. This should look something like: \AppData\Roaming\Mathematica\SystemFiles\FrontEnd\TextResources\Windows\KeyEventTranslations.tr  Add this to that file being careful to respect commas:  Item[KeyEvent["q", Modifiers -> {Control, Option}], FrontEndExecute[ FrontEndToken[ SelectedNotebook[ ], "EvaluatorQuit", Automatic ] ] ]  For version 10 I am using: Item[KeyEvent["q", Modifiers -> {Control}], "EvaluatorQuit"]  If you do not want a confirmation dialog please see Rolf Mertig's code in: There are other keyboard shortcuts you may find useful. See these for more: Alternatively you may want to use a new context for a Cell or Notebook: In Mathematica, the current $Context defines what Context unqualified symbol names belong to. By giving a new Notebook (or Cell) a unique Context, which is easily done through the Evaluation menu, the symbols used in that Notebook will not collide with unqualified symbols in other Notebooks. See the following question for more detailed information:

-

I have the following commands in my init.m file, which can be found in $UserBaseDirectory/Kernel/init.m. eraseAll := ClearAll[Evaluate[$Context<>"*"]];
eraseAll::usage="eraseAll clears all values, definitions, attributes, messages and defaults associated with symbols in the current context"

removeAll := Remove[Evaluate[\$Context<>"*"]];
removeAll::usage="removeAll removes all symbols in the current context"


I typically use eraseAll to wipe my variables/functions and startover. removeAll is used when I want to remove all the symbols from the kernel.

Note the difference between ClearAll and Remove — the former clears all definitions, attributes, etc associated with the symbols, but not the symbols themselves, whereas the latter removes them completely, so that the kernel doesn't recognize them anymore. Here is an example:

-

I just found that doing Quit[] does what I want, too. It may not be the nicest way, but it is easy to remember. Another Mathematica kernel seems to be automatically started when the next command is run.

-
@Nasser To be precise, Quit restarts the kernel, which means that all kernel variables are cleared. Localized variables of a DynamicModule are owned by the front end, therefore they are not cleared (but then they are local, and will never conflict with anything). However, if you have Dynamic cells in some open notebooks, they might be auto-refreshed as soon as the kernel has restarted, possibly causing some new variables to be defined again. It all depends on what you put in your Dynamic expressions (it's a bad idea to change global variables from them). – Szabolcs Jan 28 '12 at 13:15
In this way simply opening a notebook may cause variables to be defined, if dynamic updating is enabled, and the notebook has Dynamic cells that change globals when refreshed. – Szabolcs Jan 28 '12 at 13:16