Say I have a cell where I ran a long running function, say, Users.get_unregistered
and went to grab a cup of coffee and forgot to assign it to a variable. My intention was to explore the data and get some information out of it.
I come back to a whole list of logs but no variable I can explore. What I’d like to know is, is there a way I can refer to a cell value (i.e. v
in iex
or In[x]
or Out[x]
in ipython?)?
This is not currently possible, I think the two main reasons are:
- It’s a major tradeoff, because storing the result of evaluation means it cannot be garbage collected, which can unnecessarily hold onto memory, which may be especially important on the GPU.
- We generally want Livebook source code to be executable outside of Livebook (i.e. when exported as .exs script), so we avoid code that is coupled to the notebook in this manner.
4 Likes
Interesting situation. Thinking about iex behavior, would it work to use a pipeline to “continue where the last cell left off”?
Like
Mod.slow_func()
|> then(fn value -> Kino.DataTable.new(value) end)
I guess this is also problematic as it requires sort of merging the two cells for execution, at which point the return value from the previous cell might be already gone. I don’t know how iex handles that, but it might build on top of having previous values stored.
For that to work, we would also need to store the value of each execution, so the same issue as 1. More importantly, each cell should be syntactically valid, otherwise formatting or other intellisense may not work, and this wouldn’t be valid.
2 Likes
Makes total sense!
For the original question, instead of trying to refer back to a cell value, the normal constructs to deal with avoiding to recompute state can to be used.
A simple one, but one I used recently is to split a slow data fetch from exploring the data: in one cell I run a query and store the result, then in another cell I build a pipeline to transform the results. I needed to iterate on the pipeline multiple times, adding or changing stages, so not having to recompute the query saved a lot of time.
Another approach is to store data in another process, maybe a GenServer.
A useful feature from LiveBook that comes to mind is the “branching sections”: livebook/lib/livebook/notebook/learn/intro_to_livebook.livemd at main · livebook-dev/livebook · GitHub.
Hope that helps, @code-shoily !
1 Like
Thanks. And you’re right the reason makes perfect sense.
Usually assigning it to a variable works (i.e ‘result = get_long_running_computation()’) and I can further process results in next cells. It’s the times I forget assigning where this becomes a thing. But it’s a very small thing considering the benefits I get to reap from LiveView.
Storing the data in a process would help, and I do have a set up for it (for another problem I will soon post) to query progress of a long running event and capture intermediate states, but that is too much work when exploring data sources quickly.
Thank you both of you for responding and suggesting. And thank you for LiveBook. I don’t think I would happily function working all these extra hours if it weren’t for LB and the creativity it gives its users.
2 Likes