I am sure that this was here solved / asked before, but i have not found the answer.
I am playing with the idea of implementing a visual frontend for Mill / JsonGrinder, which will allow you to upload the training data, tweak a model, and then let you start training. I would like to delay a training, such that it will start after all the stuff like models is finished. Thus, I need something like a barrier. I wanted to implement it using a “Button”, where I would have a start button and the training will start if I change the button. But this does not work, because I cannot assign the value to the variable bind to the button.
Cell defining button
$(@bind go Button("Train!"))
Cell performing training
if go == "Train!"
Flux.Optimise.train!((x,y) -> loss(model, x, y), ps, repeatedly(minibatch, iterations), opt)
go = "finished"
Does anyone has an idea, how can I achieve this?
Thanks for an answer in advance.
I prefer to use
CheckBox for execution barriers - it’s a better fit for Pluto’s reactivity model.
Train! $(@bind cb CheckBox())
The functionality to delay execution of specific cells (and their dependencies) will be available in Pluto itself soon - you can try it out here (GUI not final, but should be fully operational):
My first works on #298
Still very WIP!
- give a method to prevent auto-update of cells which take too long to compute to keep the notebook reactive and/or save computational resources.
- step-by-step computations for educational purposes
- Allow the users to add execution barriers to Pluto cells from inside Pluto.
- These barriers block execution of the cell they are added to (i.e. located before the cell) if active.
- The barriers should be stored in the notebook.jl file, e.g. as comments.
- If the notebook.jl file is executed in Julia (without Pluto), the whole file should run, ignoring execution barriers (there would be no way to turn them off without Pluto anyhow).
- If an execution barrier is active, the cell and all cells depending on this cell should be marked gray in Pluto, so that it is obvious that they are not executed.
- When deactivating an execution barrier, the corresponding cell and all dependent cells are executed immediately and not grayed out anymore.
- [x] Execution barrier information (is there a barrier? is it active?) could be added to the Cell structs in the backend.
- [x] Save this information in notebook.jl files and load it from there
- [x] Based on which cells are deactivated and the cell dependency information, the backend decides which cells to evaluate in case of changes.
- [x] Pass the barrier information to the frontend
- [x] In the frontend, the information whether a cell is grayed out is determined based on the execution barrier information in the Cells and the cell dependency information from #891
- [x] Frontend functionality for activating and deactivating of execution barriers plus visualization of execution barrirers required.
- [x] Pass changes in barrier information back to the backend
- [x] Run cell if its execution barrier is deactivated and it does not depend on any activated barrier
- [ ] Tests?
- [x] Merge current master (currently not working for me out-of-the-box)
Note: this PR is based on #891, the first commit specific to this PR is 5975d25.
# Try it out!
pkg> activate --temp
pkg> add https://github.com/lungben/Pluto.jl#execution_barrier
julia> import Pluto; Pluto.run()
12:08PM - 09 Mar 21 UTC
For usage, you could take a look at my PlutoCon talk:
I was watching your talk and I was thinking about the solution. The checkbox is a neat idea. Thanks a lot.