Restore to previous state with copy-on-write
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- jupyter, python
- Ambito
- backend, operating-systems
Direzione di ricerca
L’issue non indica file, test o punti di ingresso. Inizia studiando come il processo del kernel Jupyter potrebbe utilizzare il meccanismo copy-on-write di fork per i checkpoint, inclusa la restaurazione dello stato del kernel e del notebook; una volta completato, questo fornirebbe un workflow affidabile di checkpoint e ripristino senza rieseguire le celle precedenti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Python
- Stelle
- 734
- Fork
- 411
- Merge medio
- 1g 2h
- PR unite (30g)
- 9
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ipython/ipykernel
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 68/100
-
ipython/ipykernel#1550 · 1 commento · 1 reazione · 1 assegnatario ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 66/100
Tutte le issue di ipython/ipykernel
Issue simili
-
Add: hunch Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
AbdelStark/awesome-typesafe#104 ·
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
DiamondLightSource/dodal#2211 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
openml/openml-python#1749 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
sipyourdrink-ltd/bernstein#6191 ·