Re: Looking for Stop
- To: mathgroup at smc.vnet.net
- Subject: [mg93127] Re: Looking for Stop
- From: Albert Retey <awnl at gmx-topmail.de>
- Date: Mon, 27 Oct 2008 03:14:29 -0500 (EST)
- References: <gdugb5$jq8$1@smc.vnet.net>
Hi, > Mathematica has two termination commands: > > Abort[] interrupts a computation > Exit[] or Quit[] returns control to OS > > I use Exit[] in some course-distributed application programs > that detect an irrecoverable error requiring user intervention > and program changes. This has an undesirable side effect: > all cells containing support modules have to be reinitialized. > Abort[] does not have that effect; however it doesnt stop > execution of whatever follows. I think you should understand that Quit or Exit do not only _stop_ the kernel in what it does, they exit/quit the kernel process. When you start the next evaluation, the frontend will start a new kernel and that of course needs to be initialized. > Is there a command "in between" that stops kernel > execution but leaves cells initialized? Constraint: > it has to work with versions >=4.1. I looked for > Stop[] but there isnt such a thing under versions 4 or 5. Actually from the kernel point of view Abort[] is doing exactly that. Your problem seems to be that once the kernel aborts the evaluation of one cell, the frontend will send it the next cell in its evaluation queue for evaluation. The kernel presumably doesn't know that this already was in the frontend's queue before the Abort[], so it will just treat it as any other evaluation that it will get from the frontend after an Abort[]. I think this makes clear that it is not the kernel that you need to manipulate, it is the frontend that needs to be informed that it should abort the command _and_ clear its evaluation queue. I just played around a little bit and think what you want can be done with: FrontEndTokenExecute["EvaluatorAbort"] but note that the frontend token "EvaluatorAbort" is marked as "not fully integrated yet", so it may change or go away. Also I have found some oddities after using it: the very next evaluation sometimes (always?) still returns $Aborted and only the second next will behave as usual. So you need to check whether that is o.k. for you. If not, you could go the hard way and do some FrontEnd-Programming to first remove all cells from the evaluation queue (select all cells, call "RemoveFromEvaluationQueue") before you call a Kernel-Abort. That said, I share the opinion of Jens that to produce robust code you really need to start early, and the decision to supply code in form of a Notebook that has to be evaluated from top to bottom is probably where you should start, because that approach has several problems when the notebooks is given away to users not familiar with your code and/or mathematica. You can do everything that can be done that way with one function definition, that will produce the various output that otherwise the cells in your notebook would create. When calling just one function from one cell an Abort[] works as you want, and several other possibilities like Catch/Throw give you even more control about how to react to unexpected results. And when the desire arises, you can build a gui for that function with Manipulate or the other Dynamic stuff... hth, albert