4
$\begingroup$

I am running a very simple program that uses NotebookEvaluate to evaluate an open notebook that only has the context of saving and closing, and while it completes that task, the program gets stuck in evaluation. The evaluation is different than normal evaluation however, as indicated by a different cell bracket: any clarification on what this cell bracket means/why it occurs in general?

Stuck in Evaluation

$\endgroup$
2
  • 2
    $\begingroup$ That almost looks like what you get with Dialog[]. Do you have something like that in there? $\endgroup$
    – b3m2a1
    Commented Apr 19, 2019 at 18:14
  • $\begingroup$ @b3m2a1 I have looked into it a little more-- the best I can gather is that it means there is open evaluation in another notebook ?? The errors I was having arose from improper use of Notebook Evaluate and notebook open, but I am still unsure about the meaning of the dashed brackets-- nothing in there related to Dialog[]. $\endgroup$
    – BOUNCE
    Commented Apr 22, 2019 at 16:51

1 Answer 1

7
$\begingroup$

NotebookEvaluate is implemented using a dialog subsession. The implementation literally evaluates Dialog[] and then begins initiating the evaluation of the notebook. The reason for doing this is so that we can achieve the behavior of each cell of the target notebook going through the full main loop evaluation, without disrupting a main loop evaluation that NotebookEvaluate itself might have been a part of.

The funny bracket highlighting you're seeing is an indication that a dialog subsession is currently in effect, and that much of the behavior you're seeing is correct behavior. However, there is a bug here when the notebook is closed before NotebookEvaluate finishes its work.

The general thing that the FE does when closing a notebook is to try to cancel all outstanding queued evaluations or, if they cannot be canceled, at least convert them to a form that will evaluate quickly and without further side effects. So, e.g., if you are closing a notebook after selecting and evaluating all cells, but the cells haven't finished evaluating, you likely don't want the evaluations to continue after the notebook has closed. In this case, the FE was too aggressive, and it canceled not only any remaining cells to be processed by NotebookEvaluate, which is entirely reasonable, but also the corresponding call to Return[] which had been queued up to exit the dialog session. This leads to further downstream consequences which can cause the kernel and the FE's tracking of the kernel to be in a very bad state until you quit and restart the kernel.

I know the full details of what went wrong because I just spent part of today fixing this bug, and I expect the fix to be a part of the upcoming 12.1 release. In the mean time, the only really robust way to avoid the situation is to prevent the notebook from closing itself. Here are some options to consider:

  • Remove the NotebookClose[] command from the notebook being evaluated. Instead, call NotebookClose[] in the code that calls NotebookEvaluate[]. E.g.,
nb=NotebookOpen["file.nb"];
NotebookEvaluate[nb];
NotebookClose[nb];
  • Don't open the notebook at all. NotebookEvaluate will, if given a filename, and if that filename is not presently open, automatically open it invisibly, process it, and close it. If you specify InsertResults->True, it will even insert and save the results. This behavior is explicitly documented, and so guaranteed.
$\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.