This is one of the things I love about CoqIde compared to other REPL-environment IDEs. You basically play your input file like a movie: scrubbing back and forth, rewinding to edit the past, skip to the end, etc. Half the screen is dedicated to a debugger-like display exposing information about the state of the program at that moment in time.
This has an entirely different mechanism of action but I can see it enabling the same excellent workflow and usability for imperative code with a filesystem, etc. and that's awesome.
1. Is there any structural sharing of the memory between snapshots? Persistent data structures make sharing state/rewindable state fairly cheap, but the bust is always when it comes time to serialize it - few functional languages have support for durable persistent datastructures. Irmin, Datomic, and a few others are what I've come across/played with so far, and each of them requires your app to be built around their model; nothing nearly as general as just "memory."
2. Does this handle socket connections, etc. that rely on an external party? Obviously Tonic can't rewind/replay state that it doesn't control, but where is the dividing line?
3. What's the expected use case for Tonic? Is it meant to be a Mathematica/IPython replacement, or a dev platform for applications?
1. CRIU is working on incremental checkpoints to allow for a similar sharing: http://criu.org/Incremental_dumps . On the filesystem layer, Docker's commits are definitely diffs I believe.
2. If you have internal sockets, they should be fully functional (for example, you spawn a child_process that you connect and talk to -- which is cool for debugging streams, etc). If the socket exists to the outside, I believe it should be fine as long as the checkpoint happens between messages. However, this is an area that both CRIU ( http://criu.org/TCP_connection ) and we are working on pretty heavily to make talking to the "outside world" reasonable (we'll be sharing more on this soon).
3. There are a bunch of uses cases (from a place to easily try new packages since Tonic actually out of the box has access to every version of every package on npm, to writing live documentation, etc). A large inspiration for me was noticing that most programmers seem to start their projects in a REPL, then at some point have to make the transition to a file. We're hoping Tonic can stretch out that time period you spend in the friendlier repl environment (since tonic is closer to using an actual file), and best of all, when you're done you can actually save the repl as a node module and so you have the beginnings of your project instead of starting over.
I've been thinking about a much simpler setup for a bash notebook — create a docker layer after every command.
Works for a shell since there are no active processes between commands. (Get's complicated if you want to run background jobs.)
The native format for such a notebook could be Dockerfile!
I'm not sure whether a rewindable shell is actually something I'd want for day-to-day work.
E.g. if the command was interactively editing a file, rewinding the world and re-launching the editor is not very useful! So I'd also want something like git rebase, or be careful about what I do inside the rewindable container vs outside.
Also, I would not want to rewind my whole computer.
Anyway, this setup checkpointing a live process is much more impressive.
I personally prefer DMTCP due to its nominal portability and the separation of low-level checkpointing (MTCP) from the higher level coordination. On the other hand, its unit of granularity is the computation as opposed to the process, so you have to start multiple coordinators to get the latter effect.
This has an entirely different mechanism of action but I can see it enabling the same excellent workflow and usability for imperative code with a filesystem, etc. and that's awesome.