Last week marks the end of the summer and we noticed a significant increase in overall traffic and activity.
This adds more pressure to the ongoing Kubernetes rewrite of the SMC back-end.
We also started to collect a few courses teaching with SMC — if you are also teaching with SMC, please let us know!
Today – motivated by a challenge from a c9.io developer at a recent meetup in Seattle – I finally implemented multi-user sync-aware full
document undo/redo, at least for code editors, sage worksheets, and Jupyter notebooks. If you’ve ever edited a file, worksheet, or Jupyter notebook at the same time as somebody else, and you hit control+z (or click undo) right after they type something, you would have undid their last thing. That’s because the undo/redo would use the underlying Codemirror editor’s undo/redo functionality. I wrote a new implementation of undo/redo built on top of the realtime multiuser sync functionality. Instead of undoing the last change (or
changes if you undo or redo multiple times) to the document, it undoes only the changes that you made during this session.
For Jupyter notebooks in SageMathCloud this has an interesting side
effect. Vanilla Jupyter itself doesn’t have any global undo –
instead they have a local undo in each cell, which you could only use
via the keyboard. With this change, now Jupyter notebooks in SMC
have a global undo: make some changes in any cell(s), move cells
around, delete cells, etc., then click undo/redo or use the keyboard
to undo/redo, and the undo should undo everything you actually did
across all cells.
Today’s little usage tip is about resource usage and project restarts.
Each time you open up Sage Worksheets or Jupyter Notebooks,
the state of it needs to be stored in memory.
This can become quite costly if you open many of them after another!
They also continue to run in the background when you close the tab.
For example, you’re grading a lot of homework from your students,
or you’re torn apart working with many files at once.
The solution is to either explicitly stop each running instance with the stop button (available for both types of documents) after you’re finished with it,
or restart the entire project.
Restarting the project is like rebooting your computer.
Everything is cleaned up and you end up with a blank state.
Go to the project settings, and then click “restart project” in “project control”.
If there were still Jupyter Notebooks open, they might give you little error messages about being cut off abruptly.
Well, don’t worry, just close and re-open them.
Pro-tip: In these project settings, on the left hand side,
you can see the current memory usage and the quota.
At the latest when it does grow above the quota,
things might no longer work as well as they should.
By default, running a cell in a Sage worksheet causes the input to be run as Sage commands, with output from Sage written to the output of the cell. Mode commands in a Sage worksheet cause the input to be run through some other process to create cell output. For example,
Typing %md at the start of a cell causes cell input to be rendered as markdown in the cell output.
Typing %r causes cell input to be treated as statements in the R language, with corresponding output.
Typing %HTML causes cell input to be treated as HTML, rendered as the output.
There are many built-in modes (e.g. Cython, GAP, Pari, R, Python, Markdown, HTML, etc…)
Note: If it is not the default mode of your *.sagews worksheet, a mode command must be the first line of a cell. In other words, make sure the command %md, %r, or %HTML is the first line of a cell.
Alternatively, you can make any mode the default for all cells in the worksheet using %default_mode <some_mode>. Then all cells will be using that chosen mode. If you choose this approach, you may still explicitly use %sage for cells you want processed by the Sage interpreter (or %foo to explicitly switch to any non-default mode).