Quit versus Clear["Global`*"]
Themis Matsoukas
Is there a command to quit the kernel, instead of selecting Quit/Local from there Evaluate menu?
Thanks
Murray Eisenberg
does not remove their Attributes, e.g., just their values. You might
want ClearAll instead.
Second, did you try evaluating one of the following?
?Quit
?Quit*
Or looking up Quit (or even "quit") in the Documentation Center? That
will answer your second question!
--
Murray Eisenberg mur...@math.umass.edu
Mathematics & Statistics Dept.
Lederle Graduate Research Tower phone 413 549-1020 (H)
University of Massachusetts 413 545-2859 (W)
710 North Pleasant Street fax 413 545-1801
Amherst, MA 01003-9305
DrMajorBob
Quit
You can't use it when the kernel is busy, however, which you CAN do from
the menus.
Bobby
On Sat, 03 Sep 2011 07:05:46 -0500, Themis Matsoukas <tmats...@me.com>
wrote:
> What is the difference between quitting the kernel and executing
> Clear["Global`*"]?
>
> Is there a command to quit the kernel, instead of selecting Quit/Local
> from there Evaluate menu?
>
> Thanks
>
Oleksandr Rasputinov
wrote:
Definitions can be made at run-time in other contexts apart from Global`.
For example, AutoLoad packages make their definitions mostly in the
System` context. Quitting the kernel removes all of these, as well as
closing all open streams and MathLink connections, unloading
LibraryFunctions, and so on. The command used to quit the kernel is simply
Quit or Quit[].
Bill Rowe
>What is the difference between quitting the kernel and executing
>Clear["Global`*"]?
Clear["Global`*"] clears things in the Global context. Clear out
other contexts, reset the history stack etc. as would occur by
quitting the kernel. For example:
In[1]:= a = 3;
In[2]:= Clear["Global`*"]
In[3]:= b = 3;
In[4]:= Quit[]
In[1]:= a = 4;
Notice the count of input cells increases after using Clear but
resets to 1 after using Quit
>Is there a command to quit the kernel, instead of selecting
>Quit/Local from there Evaluate menu?
Yes, Quit[]. See above.
It might be worth mentioning if your goal is to restore some
previous state of a session, the CleanSlate package offers more flexibility.
David Bailey
Obviously Clear["Global`*"] would not clear information that might end
up in other contexts, whereas Quit[] will clear everything.
I never clear the global context - I just quit the kernel one way or
another. Restarting the kernel used to be rather slow, but with the
speed of a modern PC, there really doesn't seem much point doing
anything else unless you specifically wish to preserve some information
that is not in Global`.
I tend to quit the kernel quite a lot - e.g. between successive runs of
a program - why risk the confusion that can arise when two function
definitions end up coexisting!
David Bailey
http://www.dbaileyconsultancy.co.uk
AES
Murray Eisenberg <mur...@math.umass.edu> wrote:
> First, Clear, whether for a single object or an entire list of objects,
> does not remove their Attributes, e.g., just their values. You might
> want ClearAll instead.
And how do either of those differ from Remove?
Murray Eisenberg
step tells you what Mathematica now knows about the symbol f.
f[x_] := Plot[x, {x, 0, 1}]
SetAttributes[f, Listable]
Clear[f]
??f
f[x_] := Plot[x, {x, 0, 1}]
SetAttributes[f, Listable]
ClearAll[f]
??f
f[x_] := Plot[x, {x, 0, 1}]
SetAttributes[f, Listable]
Remove[f]
??f
On 9/4/11 4:12 AM, AES wrote:
> In article<j3u7r6$a88$1...@smc.vnet.net>,
> Murray Eisenberg<mur...@math.umass.edu> wrote:
>
>> First, Clear, whether for a single object or an entire list of objects,
>> does not remove their Attributes, e.g., just their values. You might
>> want ClearAll instead.
>
> And how do either of those differ from Remove?
>
--
DrMajorBob
replacing x with Removed[x] and making those definitions useless. Clear[x]
removes definitions for x, but leaves alone other symbols that mention
it... which, to me, seems far more sensible.
After Clear[x], other symbols referring to x can still be used (with or
without new definitions for x). After Remove[x], all those symbols are
just trash, lying around waiting for Quit to clear them away.
Bobby
On Sun, 04 Sep 2011 03:12:58 -0500, AES <sie...@stanford.edu> wrote:
> In article <j3u7r6$a88$1...@smc.vnet.net>,
> Murray Eisenberg <mur...@math.umass.edu> wrote:
>
>> First, Clear, whether for a single object or an entire list of objects,
>> does not remove their Attributes, e.g., just their values. You might
>> want ClearAll instead.
>
> And how do either of those differ from Remove?
>
Themis Matsoukas
Themis
DrMajorBob
does not:
ClearAll[f]
f[x_] := Plot[x, {x, 0, 1}] SetAttributes[f, Listable]
Remove[x]
?? f
Remove[x] cripples f without mentioning it, which I'd call a very ugly
side-effect.
Bobby
On Sun, 04 Sep 2011 17:05:26 -0500, Murray Eisenberg
<mur...@math.umass.edu> wrote:
> Try the following little three-part experiment. In each part, the last
> step tells you what Mathematica now knows about the symbol f.
>
> f[x_] := Plot[x, {x, 0, 1}]
> SetAttributes[f, Listable]
> Clear[f]
> ??f
>
> f[x_] := Plot[x, {x, 0, 1}]
> SetAttributes[f, Listable]
> ClearAll[f]
> ??f
>
> f[x_] := Plot[x, {x, 0, 1}]
> SetAttributes[f, Listable]
> Remove[f]
> ??f
>
> On 9/4/11 4:12 AM, AES wrote:
>> In article<j3u7r6$a88$1...@smc.vnet.net>,
>> Murray Eisenberg<mur...@math.umass.edu> wrote:
>>
>>> First, Clear, whether for a single object or an entire list of objects,
>>> does not remove their Attributes, e.g., just their values. You might
>>> want ClearAll instead.
>>
DrMajorBob
Quit
Bobby
On Sun, 04 Sep 2011 17:06:32 -0500, Themis Matsoukas <tmats...@me.com>
wrote:
> So, if I use ClearAll["Global`*"] at the beginning of a notebook and
> execute all the cells, is it the same as running on a fresh kernel?
>
> Themis
>
Bill Rowe
>So, if I use ClearAll["Global`*"] at the beginning of a notebook and
>execute all the cells, is it the same as running on a fresh kernel?
No. This will not reset the evaluation history. Nor will it
remove any packages you may have loaded That is:
In[1]:= x = 4
Out[1]= 4
In[2]:= y = x^2
Out[2]= 16
In[3]:= ClearAll["Global`*"]
In[4]:= %1 + %2
Out[4]= 20
The closest way I know of to reset things to the initial start
up condition is to put a directive to load the CleanSlate
package into init.m. Then after a series of evaluations you can do
CleanSlate[]
which resets things to the point where the CleanSlate package
was loaded.
The last three lines of my init.m are:
<<PacletManager`;
<<Utilities`CleanSlate`;
SetOptions[CleanSlate,Verbose->False];
I explicitly load the PacletManager since I found in earlier
versions of Mathematica, the PackletManager was loading after
everything in init.m executed. I have not tested ver 8 to see if
this is still true. Assuming it is still true, if the
PackletManager is not loaded explicitly in this manner it will
be removed when CleanSlate[] is executed.
Oleksandr Rasputinov
wrote:
> So, if I use ClearAll["Global`*"] at the beginning of a notebook and
> execute all the cells, is it the same as running on a fresh kernel?
>
> Themis
>
No.
Oleksandr Rasputinov
removed. Retaining any references whatsoever will prevent the symbol from
being deleted from the symbol table due to Mathematica's
reference-counting garbage collection. When calling Remove, one explicitly
requests that the symbol be completely removed, and this is duly performed
along with all that it implies. If one only wishes to clear the
definitions on a symbol rather than destroying the symbol itself, the use
of Remove would be erroneous, since this quite separate operation is the
domain of ClearAll.
A situation in which Remove might be needed is where a function has
created temporary symbols and wishes to destroy them before returning in
order to avoid clogging up the symbol table (which would represent a
memory leak and may slightly worsen Mathematica's performance). Although
the Temporary attribute could be used instead, catching all the references
may not be easy, so Remove is helpful in that it automatically invalidates
any references that would otherwise have prevented garbage collection. In
other words, Remove is a specialised function with a specialised use, not
simply an alternative to Clear/Unset et al.
On Mon, 05 Sep 2011 12:07:23 +0100, DrMajorBob <btr...@austin.rr.com>
wrote:
>>>> First, Clear, whether for a single object or an entire list of
>>>> objects,
>>>> does not remove their Attributes, e.g., just their values. You might
>>>> want ClearAll instead.
>>>
Andrzej Kozlowski
?Quit
Quit[] terminates a Mathematica kernel session.
I thought you had made a mistake but I tired just Quit (without the
brackets) and was surprised (after all these years!) to see it work. I
am wondering if there are more cases like this?
Andrzej Kozlowski
On 5 Sep 2011, at 13:06, DrMajorBob wrote:
> No. For that, you need:
>
> Quit
>
> Bobby
>
> On Sun, 04 Sep 2011 17:06:32 -0500, Themis Matsoukas
<tmats...@me.com>
> wrote:
>
>> So, if I use ClearAll["Global`*"] at the beginning of a notebook and
>> execute all the cells, is it the same as running on a fresh kernel?
>>
>> Themis
>>
>
>
> --
> DrMaj...@yahoo.com
>
Murray Eisenberg
ClearAttributes doesn't do what I want, then typically I restart the kernel.
On 9/4/11 10:44 PM, DrMajorBob wrote:
> Your experiment makes Remove look useful (possibly), but here's one that
> does not:
>
> ClearAll[f]
> f[x_] := Plot[x, {x, 0, 1}] SetAttributes[f, Listable]
> Remove[x]
> ?? f
>
> Remove[x] cripples f without mentioning it, which I'd call a very ugly
> side-effect.
>
> Bobby
>
> On Sun, 04 Sep 2011 17:05:26 -0500, Murray Eisenberg
> <mur...@math.umass.edu> wrote:
>
>> Try the following little three-part experiment. In each part, the last
>> step tells you what Mathematica now knows about the symbol f.
>>
>> f[x_] := Plot[x, {x, 0, 1}]
>> SetAttributes[f, Listable]
>> Clear[f]
>> ??f
>>
>> f[x_] := Plot[x, {x, 0, 1}]
>> SetAttributes[f, Listable]
>> ClearAll[f]
>> ??f
>>
>> f[x_] := Plot[x, {x, 0, 1}]
>> SetAttributes[f, Listable]
>> Remove[f]
>> ??f
>>
>> On 9/4/11 4:12 AM, AES wrote:
>>> In article<j3u7r6$a88$1...@smc.vnet.net>,
>>> Murray Eisenberg<mur...@math.umass.edu> wrote:
>>>
>>>> First, Clear, whether for a single object or an entire list of objects,
>>>> does not remove their Attributes, e.g., just their values. You might
>>>> want ClearAll instead.
>>>
>>> And how do either of those differ from Remove?
>>>
>>
>
>
--
ten...@gmail.com
I agree whole-heartedly with this post. I've found it the only way
to stay out of trouble.
I have a related problem that I hope I can get some suggestions for.
GIF.exe has a memory leak (reported previously, acknowledged and is on
someone's todo list at Wolfram, hopefully) which makes a certain set
evaluations (which use ExportString[#,"GIF"]& extensively) unstable.
(i.e., MathKernel crashes randomly and unceremoniously, or worse).
What I would like to do is divide the set of evaluations into
segments, run them successively quitting the MathKernel after each,
and then restarting on the next segment. The Quit[] clears out the
buildup in GIF.exe. Obviously I can do this by babysitting and
restarting each segment by hand (which I do, at approximately 15
minute intervals, painfully wasting time).
[I've tried many things including Uninstall["path/GIF.exe"] 'ing
periodically and escaping to the shell to kill the process. Neither
improves stability. ]
How can I carry this out automatically?
DrMajorBob
I suppose it figures that if Quit kills the kernel, then also Quit[any
arguments or none] might also kill the kernel. (The other way 'round
doesn't necessarily "figure", on the other hand.)
Bobby
On Mon, 05 Sep 2011 07:44:17 -0500, Andrzej Kozlowski <ak...@mimuw.edu.pl>
wrote:
> Actually (as far as I can tell) Quit is undocumented but Quit[] is:
>
> ?Quit
> Quit[] terminates a Mathematica kernel session.
>
> I thought you had made a mistake but I tired just Quit (without the
> brackets) and was surprised (after all these years!) to see it work. I
> am wondering if there are more cases like this?
>
> Andrzej Kozlowski
>
> On 5 Sep 2011, at 13:06, DrMajorBob wrote:
>
>> No. For that, you need:
>>
>> Quit
>>
>> Bobby
>>
>> On Sun, 04 Sep 2011 17:06:32 -0500, Themis Matsoukas <tmats...@me.com>
>> wrote:
>>
>>> So, if I use ClearAll["Global`*"] at the beginning of a notebook and
>>> execute all the cells, is it the same as running on a fresh kernel?
>>>
>>> Themis
>>>
>>
>>
>> --
>> DrMaj...@yahoo.com
>>
>
Andrzej Kozlowski
Head[arguments] where the number of arguments could be 0. Quit is
therefore a Mathematica function, like Print[], Return[]. In fact,
Quit[n] where n is an integer also works "passing the integer n as an
exit code to the operating system" whatever that means. On the other
hand, expressions of the form Abracadabra are normally just symbols and
normally they do not perform any actions. In fact, do you know of any
other example (except Quit) when when evaluating a symbols actually does
more than return a value (that usually happens in the case of global
constants, whose names begin with $,
[1]:= $Version
Out[1]= 8.0 for Mac OS X x86 (64-bit) (February 23, 2011)
Note, by the way, that Abort[] works but Abort does not:
In[3]:= Print[a];Abort[];Print[b]
During evaluation of In[3]:= a
Out[3]= $Aborted
Print[a];Abort;Print[b]
a
b
Andrzej Kozlowski
DrMajorBob
yet another poster found that, if it is the first line in a cell with
other statements, Mathematica doesn't quit until those other statements
are done, hence wiping out their effect.
Quit[e] the conundrum.
Bobby
On Mon, 05 Sep 2011 13:15:07 -0500, Andrzej Kozlowski <ak...@mimuw.edu.pl>
wrote:
Andrzej Kozlowski
ClearAll[f]
f[x_] := Plot[x, {x, 0, 1}]; SetAttributes[f, Listable]
Remove[x]
then evaluate
f[y]
Andrzej Kozlowski
On 5 Sep 2011, at 13:05, DrMajorBob wrote:
> Your experiment makes Remove look useful (possibly), but here's one that
> does not:
>
> ClearAll[f]
> f[x_] := Plot[x, {x, 0, 1}] SetAttributes[f, Listable]
> Remove[x]
> ?? f
>
> Remove[x] cripples f without mentioning it, which I'd call a very ugly
> side-effect.
>
> Bobby
>
> On Sun, 04 Sep 2011 17:05:26 -0500, Murray Eisenberg
> <mur...@math.umass.edu> wrote:
>
>> Try the following little three-part experiment. In each part, the last
>> step tells you what Mathematica now knows about the symbol f.
>>
>> f[x_] := Plot[x, {x, 0, 1}]
>> SetAttributes[f, Listable]
>> Clear[f]
>> ??f
>>
>> f[x_] := Plot[x, {x, 0, 1}]
>> SetAttributes[f, Listable]
>> ClearAll[f]
>> ??f
>>
>> f[x_] := Plot[x, {x, 0, 1}]
>> SetAttributes[f, Listable]
>> Remove[f]
>> ??f
>>
>> On 9/4/11 4:12 AM, AES wrote:
>>> In article<j3u7r6$a88$1...@smc.vnet.net>,
>>> Murray Eisenberg<mur...@math.umass.edu> wrote:
>>>
>>>> First, Clear, whether for a single object or an entire list of objects,
>>>> does not remove their Attributes, e.g., just their values. You might
>>>> want ClearAll instead.
>>>
>>> And how do either of those differ from Remove?
>>>
>>
>
>
> --
DrMajorBob
evaluating initialization cells... you'll stop evaluating them. (Not so
surprising, really.)
So instead of Quit, add Clear and ClearAll for everything that needs it.
In the code of your example, there's nothing that needs it.
Whenever I define a function that could EVER need Clear, I precede that
definition with Clear. To start all over, I can go to the menus and select
Evaluate>Evaluate Initialization Cells. When in doubt, I quit the kernel
with Evaluation>Quit Kernel, particularly if evaluating code is in an
infinite (or very long?) loop.
spell and spell1 are Off by default at my machine, by the way. I'm not
sure what that would be so here, but not at your machine. I used to have
to turn them off manually, but that was a long time ago.
Bobby
On Mon, 05 Sep 2011 15:00:46 -0500, Kevin J. McCann <k...@kevinmccann.com>
wrote:
> I have to wait for Quit to finish executing, and then execute the rest.
>
> On 9/5/2011 1:40 PM, DrMajorBob wrote:
>> Put Quit in a cell by itself.
>>
>> Bobby
>>
>> On Mon, 05 Sep 2011 07:15:08 -0500, Kevin J. McCann
>> <k...@kevinmccann.com> wrote:
>>
>>> This is a related observation to the use of Quit.
>>>
>>> I have an initialization cell at the top of most of my notebooks that
>>> loads my favorite packages and sets options. If I put Quit at the top
>>> of all that, and then execute the whole section, the Quit seems to
>>> override everything, i.e. at the end nothing is defined.
>>>
>>> It appears that while Quit is executing, the other commands do, but
>>> then the Quit kills off the results. I am not explaining it well, so
>>> here is some abbreviated code from one of my nb's. Dump it all into an
>>> Input cell and execute. At the end you will see that x is not defined.
>>>
>>> Kevin
>>>
>>> Quit
>>> Off[General::spell];
>>> Off[General::spell1];
>>> bs = {FontFamily -> "Arial", FontSize -> 14, FontWeight -> Bold};
>>> SetOptions[Plot,
>>> Frame -> True,
>>> FrameStyle -> AbsoluteThickness[2],
>>> GridLines -> Automatic,
>>> PlotStyle -> {{Red, AbsoluteThickness[3]}, {Black,
>>> AbsoluteThickness[3]}, {Blue,
>>> AbsoluteThickness[3]}, {Darker@Green, AbsoluteThickness[3]}},
>>> BaseStyle -> bs
>>> ];
>>> SetOptions[ListPlot,
>>> Frame -> True,
>>> FrameStyle -> AbsoluteThickness[2],
>>> GridLines -> Automatic,
>>> PlotStyle -> {Blue, AbsolutePointSize[2]},
>>> BaseStyle -> bs
>>> ];
>>> $Post := (If[MatrixQ[#], MatrixForm[#], #] &)
>>> x = 22/7.;
Kevin J. McCann
Kevin
John Fultz
since before I started using Mathematica (1993, in case you were wondering), and it probably dates back all the way to v1. With such a long history, I don't see
the eccentricity as being so out of the norm as to merit correction now. I
don't know the history for sure, but I suspect you can chalk it up as a
convenience feature for the console version of Mathematica (which, on many
machines, was the only version available for many years).
In response to others...Quit really behaves just like any other function,
requiring function application to zero or one arguments, except in one very
special case...when it constitutes the entirety of a standalone input. The
argument-less version doesn't even quit when it's within a
CompoundExpression...i.e.,
In[1]:= Quit; (* doesn't quit *)
In[2]:= Quit (* quits *)
So, if In[$Line] were assigned the symbol Quit, then the kernel will terminate.
Otherwise, it evaluates Quit normally just as any other function. This may
appear a bit confusing when using a front end because it *does* quit (as has
been noted in this thread) when used in a series of multiple statements in the
front end as so:
2+2 (* first line of cell *)
Quit (* second line of same cell *)
4+4 (* third line of same cell *)
However, that doesn't at all violate the rule I set out above. The front end
treats newlines inside Input cells as terminating a complete In[] expression if
the expression up to that point is syntactically correct and complete. So, for
example, when violating the following inputs all in one cell:
2 +
2
3!
4*2
$Line increments three different times...once for "2+2", once for "3!", and once
for "4*2".
Sincerely,
John Fultz
jfu...@wolfram.com
User Interface Group
Wolfram Research, Inc.
On Tue, 6 Sep 2011 03:57:45 -0400 (EDT), DrMajorBob wrote:
> Quit appears to quit as soon as it is parsed, regardless of arguments...
> yet another poster found that, if it is the first line in a cell with
> other statements, Mathematica doesn't quit until those other statements
> are done, hence wiping out their effect.
>
> Quit[e] the conundrum.
>
> Bobby
>
> On Mon, 05 Sep 2011 13:15:07 -0500, Andrzej Kozlowski <ak...@mimuw.edu.pl>
> wrote:
>
>> Well, I see it differently. All Mathematica functions have the form
>> Head[arguments] where the number of arguments could be 0. Quit is
>> therefore a Mathematica function, like Print[], Return[]. In fact,
>> Quit[n] where n is an integer also works "passing the integer n as an
>> exit code to the operating system" whatever that means. On the other
>> hand, expressions of the form Abracadabra are normally just symbols and
>> normally they do not perform any actions. In fact, do you know of any
>> other example (except Quit) when when evaluating a symbols actually does
>> more than return a value (that usually happens in the case of global
>> constants, whose names begin with $,
>>
>> [1]:= $Version
>>
>> Out[1]= 8.0 for Mac OS X x86 (64-bit) (February 23, 2011)
>>
>> Note, by the way, that Abort[] works but Abort does not:
>>
>> In[3]:= Print[a];Abort[];Print[b]
>> During evaluation of In[3]:= a
>> Out[3]= $Aborted
>>
>> Print[a];Abort;Print[b]
>> a
>> b
>>
>> Andrzej Kozlowski
>>
>>
>> On 5 Sep 2011, at 19:44, DrMajorBob wrote:
>>
>>> I, on the other hand, never saw Quit[] until this thread began.
>>>
>>> I suppose it figures that if Quit kills the kernel, then also Quit[any
>>> arguments or none] might also kill the kernel. (The other way 'round
>>> doesn't necessarily "figure", on the other hand.)
>>>
>>> Bobby
>>>
>>> On Mon, 05 Sep 2011 07:44:17 -0500, Andrzej Kozlowski
>>> <ak...@mimuw.edu.pl> wrote:
>>>
>>>> Actually (as far as I can tell) Quit is undocumented but Quit[] is:
>>>>
>>>> ?Quit
>>>> Quit[] terminates a Mathematica kernel session.
>>>>
>>>> I thought you had made a mistake but I tired just Quit (without the
>>>> brackets) and was surprised (after all these years!) to see it
>>>> work. I
>>>> am wondering if there are more cases like this?
>>>>
>>>> Andrzej Kozlowski
>>>>
>>>> On 5 Sep 2011, at 13:06, DrMajorBob wrote:
>>>>
>>>>> No. For that, you need:
>>>>>
>>>>> Quit
>>>>>
>>>>> Bobby
>>>>>
>>>>> On Sun, 04 Sep 2011 17:06:32 -0500, Themis Matsoukas
>>>>> <tmats...@me.com>
>>>>> wrote:
>>>>>
>>>>>> So, if I use ClearAll["Global`*"] at the beginning of a
>>>>>> notebook and
>>>>>> execute all the cells, is it the same as running on a fresh
>>>>>> kernel?
>>>>>>
>>>>>> Themis
>>>>>
>>>>>
>>>>> --
>>>>> DrMaj...@yahoo.com
>>>>
>>>
>>> --
>>> DrMaj...@yahoo.com
Oleksandr Rasputinov
expected.)
Quit vs. Quit[] performing the same operation isn't a great mystery: one
can define
f := a
and
f[args___] := a
and get the same result regardless of whether f is called as f or f[...].
In general DownValues and OwnValues don't work like this, but providing
for such behaviour in a specific case is easy.
On Tue, 06 Sep 2011 09:03:47 +0100, DrMajorBob <btr...@austin.rr.com>
wrote:
Kevin J. McCann
least with Quit at the top, they are not carried out that way, but
perhaps in some parallel fashion. This is not documented anywhere, and I
don't think it is expected behavior. Further, I think it is not desirable.
Kevin
On 9/5/2011 4:23 PM, DrMajorBob wrote:
> OK, putting it in a separate cell didn't help, but if you Quit while
> evaluating initialization cells... you'll stop evaluating them. (Not
> so surprising, really.)
>
> So instead of Quit, add Clear and ClearAll for everything that needs
> it. In the code of your example, there's nothing that needs it.
>
> Whenever I define a function that could EVER need Clear, I precede
> that definition with Clear. To start all over, I can go to the menus
> and select Evaluate>Evaluate Initialization Cells. When in doubt, I
> quit the kernel with Evaluation>Quit Kernel, particularly if
> evaluating code is in an infinite (or very long?) loop.
>
> spell and spell1 are Off by default at my machine, by the way. I'm not
> sure what that would be so here, but not at your machine. I used to
> have to turn them off manually, but that was a long time ago.
>
> Bobby
>
> On Mon, 05 Sep 2011 15:00:46 -0500, Kevin J. McCann
> <k...@kevinmccann.com> wrote:
>
>> I have to wait for Quit to finish executing, and then execute the rest.
>>
>> On 9/5/2011 1:40 PM, DrMajorBob wrote:
>>> Put Quit in a cell by itself.
>>>
>>> Bobby
>>>
>>> On Mon, 05 Sep 2011 07:15:08 -0500, Kevin J. McCann
>>> <k...@kevinmccann.com> wrote:
>>>
DrMajorBob
rather than continuing to evaluate initialization cells. That appears
entirely sequential, to me.
Bobby
On Tue, 06 Sep 2011 05:13:30 -0500, Kevin J. McCann <k...@kevinmccann.com>
DrMajorBob
Amen. Other remedies are always a kludge.
Bobby
On Tue, 06 Sep 2011 02:57:01 -0500, ten...@gmail.com <ten...@gmail.com>
wrote:
>
> I agree whole-heartedly with this post. I've found it the only way
> to stay out of trouble.
>
> I have a related problem that I hope I can get some suggestions for.
>
> GIF.exe has a memory leak (reported previously, acknowledged and is on
> someone's todo list at Wolfram, hopefully) which makes a certain set
> evaluations (which use ExportString[#,"GIF"]& extensively) unstable.
> (i.e., MathKernel crashes randomly and unceremoniously, or worse).
>
> What I would like to do is divide the set of evaluations into
> segments, run them successively quitting the MathKernel after each,
> and then restarting on the next segment. The Quit[] clears out the
> buildup in GIF.exe. Obviously I can do this by babysitting and
> restarting each segment by hand (which I do, at approximately 15
> minute intervals, painfully wasting time).
>
> [I've tried many things including Uninstall["path/GIF.exe"] 'ing
> periodically and escaping to the shell to kill the process. Neither
> improves stability. ]
>
> How can I carry this out automatically?
>
DrMaj...@yahoo.com
Kevin J. McCann
and I would like the students to put a Quit at the top of each homework
they turn in; so, then I can just select all and execute. The Quit
would, of course, wipe out all previously defined things, so we start
with a clean slate. Apparently, though, this won't work for the
aforementioned reasons.
Kevin
Andrzej Kozlowski
all, you can also define
ContextPath := $ContextPath
and you will have global variables not beginning with $, etc. The
question is why: does WRI appear to violate what seem to be the logical
foundations of Mathematica's language.
Andrzej Kozlowski
On 7 Sep 2011, at 11:40, Oleksandr Rasputinov wrote:
> Quit[Abort[]] doesn't quit; instead it gives $Aborted. (I dare say as
> expected.)
>
> Quit vs. Quit[] performing the same operation isn't a great mystery:
one
> can define
>
> f := a
>
> and
>
> f[args___] := a
>
> and get the same result regardless of whether f is called as f or
f[...].
> In general DownValues and OwnValues don't work like this, but
providing
> for such behaviour in a specific case is easy.
>
> On Tue, 06 Sep 2011 09:03:47 +0100, DrMajorBob <btr...@austin.rr.com>
Kevin J. McCann
when would the kernel restart? Never? After we wait a few seconds?
Quit (* the kernel quits *)
x=1; (* shouldn't the kernel restart here? *)
Actually, it appears that Quit takes some time to execute, and in
parallel, further commands execute, but then their results are killed off.
Kevin
Bill Rowe
>Actually the code was just an example. I teach a class in
>Mathematica, and I would like the students to put a Quit at the top
>of each homework they turn in; so, then I can just select all and
>execute. The Quit would, of course, wipe out all previously defined
>things, so we start with a clean slate. Apparently, though, this
>won't work for the aforementioned reasons.
My method of achieving a clean slate to work with is as follows:
The last lines of my init.m file are as follows:
<<PacletManager`;
<<Utilities`CleanSlate`;
SetOptions[CleanSlate,Verbose->False];
The last line simply sets some options for CleanSlate I like.
The line before obviously loads the CleanSlate package. The
first line intentionally loads the PacletManager before the
CleanSlate package because I found this was loading after
commands in init.m were executing.
With this, simply doing
CleanSlate[];
prior to executing any commands in a notebook clears the Global
context, removes any packages loaded after the CleanSlate
package was loaded and resets the session history. That is, this
restores things to what they were when I first started a
Mathematica session without actually quitting the kernel.
I find this to be a very handy utility which is why I have it
loaded in my init.m file
DrMajorBob
kernels for that.
Bobby
Oleksandr Rasputinov
Personally I have always thought that referring to a symbol with delayed
evaluation semantics and without any explicit parameters (a.k.a. a
function with no arguments or options) as, for example, f[] is illogical,
ugly, and inconsistent when it appears in Mathematica because one can just
as well set OwnValues as DownValues, and doing the former more accurately
expresses the intended meaning. Along this line of argument, Abort[]
should indeed be Abort, especially since if actually called with any
arguments Abort prints messages complaining about it. Obviously the only
reason why there are such symbols is in a (probably misguided) effort to
try to act more like other languages or environments: a similar argument,
I suspect, explains Quit. Of course this doesn't excuse it, because Quit
does in fact take a parameter, and mixing up the two unrelated concepts of
functions vs. symbols with DownValues can only lead to confusion... but
nothing's perfect. At least you can ignore Quit if you like and use Quit[]
instead; not so, unfortunately, with the names and invocations of some of
the Parallel` functions, which were comprehensively mangled when Maeder's
Parallel Computing Toolkit became a part of Mathematica proper.
On Wed, 07 Sep 2011 13:29:39 +0100, Andrzej Kozlowski <ak...@mimuw.edu.pl>
wrote:
> Of course it is not a great mystery if you define it yourself. After
> all, you can also define
>
> ContextPath := $ContextPath
>
> and you will have global variables not beginning with $, etc. The
> question is why: does WRI appear to violate what seem to be the logical
> foundations of Mathematica's language.
>
> Andrzej Kozlowski
>
>
> On 7 Sep 2011, at 11:40, Oleksandr Rasputinov wrote:
>
>> Quit[Abort[]] doesn't quit; instead it gives $Aborted. (I dare say as
>
>> expected.)
>>
>> Quit vs. Quit[] performing the same operation isn't a great mystery:
> one
>> can define
>>
>> f := a
>>
>> and
>>
>> f[args___] := a
>>
>> and get the same result regardless of whether f is called as f or
> f[...].
>> In general DownValues and OwnValues don't work like this, but
> providing
>> for such behaviour in a specific case is easy.
>>
>> On Tue, 06 Sep 2011 09:03:47 +0100, DrMajorBob <btr...@austin.rr.com>
>
>> wrote:
>>