REPL Save/restore

General Usage
,
1

When using the REPL, is it possible to save the state (memory) of the session, and restore it?
(State being defined as all datastructures and functions loaded)

When prototyping I need to load large-ish datasets, with intermediate results, I need to interrupt at times my work to switch to other tasks, saving the state could allow (similar to R) to restore a session as-is and resume.

I try to keep my current workflows 100% reproducible, so in principle re-executing the script would allow me the same behavior (minus load/processing time), and Julia’s precompilation (with Revise, PreCompile, ..) has become so fast that package related latency is (for me) negligible.
However, the compute cost can be non trivial, when I want to switch between projects, having save/restore REPL state would be very powerful.
I realize I can serialize the datastructures, and resume, but I was wondering if there’s any interest in REPL save/restore behavior.
Or, if there are other ways to achieve the same results, e.g. serialize recursively and reload on start.

Similar thread Save/load REPL state - #8 by mkitti

Thanks!

2

AFAIK this not possible or better, available up to now.
Coming from R and being used to this feature I want to say, that even in R, it was nearly always better not to rely on it, and, over time, I am avoiding it completely and I am typically annoyed from the question if the session should be saved.
Not relying on it means, to code in that way, so that restarting from a intermediate state is explicitly coded by me. In Julia this is, in my opinion, much easier than in R.
So for me, I am not interested in such a feature.

1 Like
3

The default setting isn’ t ideal for this. You should set

 "julia.persistentSession.enabled": true,
    "julia.persistentSession.tmuxSessionName": "julia_vscode_${workspaceFolderBasename}",

to use project REPLs.

If you use a server and set this. The need to restore should be minimal.

And my branch of the vscode extension Looking for opinion on dot methods completion implementation contains saving and restore of inline results on switching devices that connect to the remote server.

1 Like
4

You can do

using JLD2
@save "foo.h5"

to save all of the variables in the interactive scope to a file foo.h5 and

using JLD2
# ...load other packages and struct definitions first...
@load "foo.h5"

to restore them in another session. (It doesn’t save certain things like functions and struct definitions, but those you can easily re-load.)

5 Likes
5

Some things just aren’t feasibly serialized and deserialized. Precompilation itself has limitations e.g. memory address-based hashes, and active code is a nightmare. Even if we make a reasonable limitation to only let the save function run in the global scope so we’re not trying to save in the middle of a function call, we can still have queued or running code in other tasks. Sysimages and package images from precompilation are the result of determining the limits of serializing Julia, and we wouldn’t want to do all that just to save data. After all, why shouldn’t we load that same data in a different environment with different packages and functions?

6

Thanks everyone for the replies/feedback, with the solutions from @stevengj and @xgdgsc I can achieve my use case of switching sessions and restoring the compute results without recomputing.
I realize that full save/restore is both non-trivial as @Benny notes, and can lead ot non-ideal workflows as @oheil note. and reflecting on what I really needed, made me realize the above 2 solutions achieve what I really needed.
Thanks!

1 Like