Time Traveling in Node.js Notebooks(blog.tonicdev.com)
blog.tonicdev.com
Time Traveling in Node.js Notebooks
http://blog.tonicdev.com/2015/09/10/time-traveling-in-node.js-notebooks.html
7 comments
Definitely interesting!
A few questions:
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?
A few questions:
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.
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'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.
CRIU is still an interesting project nonetheless.
CRIU is still an interesting project nonetheless.
http://research.microsoft.com/en-us/um/people/marron/selectp... has some interesting technical information about time-travel debugging.
Tonic looks very interesting. However, I'm much quicker sketching ideas in a REPL without all the extra syntax. Any chance for Coffeescript support?
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.