This is tangentially related at best, but several years ago, I worked on a 
project called Reinteract [1] that tried to do something similar. Working at 
the AST level, we were able to identify 99% of the mutations that would occur, 
allowing Reinteract to save and rewind to checkpoints. Unfortunately, that last 
1% proved to be essentially impossible to detect with this approach.

I'm happy to discuss this further if there's interest, but I'll hold off on 
further thread hijacking for now.

Robert

[1] http://www.reinteract.org/

On Nov 2 2017, at 4:16 pm, Brian Granger <[email protected]> wrote:
> JupyterLab has a "Code Console" that is similar to this Scratchpad,
> but allows more flexibility in terms of which kernel is used.
>
> As far as 1) and 2) are concerned, I don't know of any general way of
> forking, rewinding a full runtime without full blown process level
> checkpointing. I am guessing that would take you down a rabbit hole.
> You could begin to explore some of the immutable namespace ideas from
> my talk at UCSD though. But keep in mind, there a ton of subtleties in
> getting that to work robustly (have to serialize state to disk to
> avoid growing memory, not all objects are easy to serialize).
>
>
>
> On Thu, Nov 2, 2017 at 3:51 PM, Adam Rule <[email protected]> wrote:
> > I am modifying Min's Scratchpad extension and am wondering if there is a way
> > to make it so code executed in the scratchpad does not impact the main
> > notebook. As it is, if I mess with parameters in the scratchpad, it will
> > change those parameters in the notebook as both share the same kernel. Would
> > it be possible to either:
> >
> > Fork the kernel to start a new one for risk-free experimenting (this seems
> > to break the one kernel per notebook paradigm)
> > Revert the kernel to a prior state when the scratchpad is closed?
> >
> > I'll look through the kernel management source code in the meantime.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Project Jupyter" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [email protected].
> > To post to this group, send email to [email protected].
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/jupyter/7bc20957-5fc2-4442-97f2-aee3200d1660%40googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Brian E. Granger
> Associate Professor of Physics and Data Science
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> [email protected] and [email protected]
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jupyter/CAH4pYpTAJuVamp4zaU2rcYDDZiZ-NVGMZLLZu2pCRFBPCsJwUQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jupyter/local-bc6edb9e-9f58%40mando.
For more options, visit https://groups.google.com/d/optout.

Reply via email to