Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restore to previous state with copy-on-write #1236

Open
zmbc opened this issue May 7, 2024 · 2 comments
Open

Restore to previous state with copy-on-write #1236

zmbc opened this issue May 7, 2024 · 2 comments

Comments

@zmbc
Copy link

zmbc commented May 7, 2024

Apologies if this isn't the right place for this kind of feature request.

As a Jupyter user, I would find it incredibly helpful if there was an "undo" for kernels. Frequently, I run something, only to realize it was the wrong thing and I want to go back one cell. If the bad cell had any destructive effect, this means I need to restart my kernel and run all the cells above again. If those cells took 3 hours to run, I need to wait 3 hours again. Even if I don't think the bad cell had any destructive effect, if I fix up the notebook mid-stream others (and myself) won't be 100% sure that the notebook would work with a simple "restart and run all."

I wish there were a command like "Kernel -> Save Checkpoint" and then the ability to restore back to checkpoints. In Jupyter, if this worked in tandem with the checkpointing of the notebook file itself, it could create a seamless experience: I create a checkpoint, make a mistake, restore both kernel and notebook to the checkpoint, fix the mistake and keep running, and I end up with exactly the notebook I would have had if I hadn't made the mistake in the first place. (On the Jupyter side I'd also like an option that automatically checkpointed after each cell, and one that forks off into a console instead of checkpointing the notebook file.)

Technically, it seems like this could be achieved through fork's copy-on-write mechanism. For many notebooks that don't have much volatile state that is rewritten multiple times, even checkpoints after every cell could have near-zero memory overhead -- they would just be forks of the kernel process at that point, using the same pages in memory as the active kernel process unless they are subsequently modified.

@davidbrochart
Copy link
Collaborator

Thanks @zmbc, that's an interesting idea.
Would you like to experiment with this idea through a PR?

@maartenbreddels
Copy link
Contributor

Great idea, I worked a bit on this: #410 maybe it is helpful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants